You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Ryan Ollos <ry...@wandisco.com> on 2013/04/11 10:30:43 UTC
Ticket for Bloodhound created on trac.edgewall.org
There was a Bloodhound ticket reported to Trac yesterday [1]. I was
thinking to ask the Trac devs to CC dev@bloodhound.apache.org on Bloodhound
issues that are incorrectly reported to trac.edgewall.org. That way, we
will see the issue even if the reporter never follows up by reporting the
issue to Bloodhound. Does anyone foresee a problem with this?
[1] http://trac.edgewall.org/ticket/11147
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Gary Martin <ga...@wandisco.com>.
On 11/04/13 09:51, Joe Dreimann wrote:
> No objection to that.
>
> Two questions:
> 1) Was it the error report that got the user to think it is a Trac problem? Do we need to amend this?
Given the text "While doing a GET operation on /admin/accounts/users,
Trac issued an internal error." it looks like we have missed some places
to specify that it is an error with bloodhound.
> 2) Should we encourage people using bloodhound to raise all issues to us (incl likely Trac ones)?
>
> I would say yes to the second one because so far we've always kept tickets like that open as a reference and raised one upstream. For users that makes our site a single point of contact, and we know what it is upstream that affects them.
Yes. By definition these are issues for Bloodhound regardless of whether
it is in Trac, bloodhound or plugins that we include.
Cheers,
Gary
nginx setup (Was: Re: Ticket for Bloodhound created on trac.edgewall.org)
Posted by Gary Martin <ga...@wandisco.com>.
Hi,
I've been having a quick look at getting some quick instructions
together for installing more or less from scratch using nginx as the
webserver and making use of gunicorn to run trac as a wsgi application.
The results of this so far are here:
https://issues.apache.org/bloodhound/wiki/BloodhoundInstallNginx
As far as I can tell, the instructions work for the last release but
there may be issues with staying authenticated on trunk. I'll look into
this further in a bit to see if there are any tickets to raise for us.
Otherwise, if anyone wants to make improvements to the instructions,
that would be great.
Has anyone tried MySQL recently with Bloodhound?
Cheers,
Gary
On 16/04/13 18:43, Joe Dreimann wrote:
> On 16 Apr 2013, at 18:31, Ryan Ollos <ry...@wandisco.com> wrote:
>
>> On Tue, Apr 16, 2013 at 9:07 AM, Olemis Lang <ol...@gmail.com> wrote:
>>
>>> As a side note to this thread in the last few days there are a
>>> significant number of messages about Bloodhound sent to trac-users ML
>>> (which is nice ... USERS ... hehe ! ;) . I've noticed that only
>>> @rjollos and me have ever replied . So maybe it's a good idea to
>>> subscribe to that list too (if not already done) and browse list
>>> archive for recent messages . Alternately we could activate
>>> users@bloodhound.apache.org too .
>>>
>>> Summarizing users have been requesting :
>>>
>>> - Migration from Trac>=0.11 to Bloodhound
>>> - MySQL as DB backend
>>> - Installation procedure using nginx
>>> - Documentation about all this .
> I believe our list is called user@b.a.o, not users@ and it is already active, I am subscribed to it at least.
>
> - Joe
>
>> I'm not sure if there is a good way to move the discussion over to a
>> Bloodhound mailing list from the start, but I tried CC'ing
>> dev@bloodhound.apache.org on a post just now and it seems to have at least
>> gone through.
>>
>> Perhaps we can CC dev@ or users@ on the first reply, and ask users to
>> subscribe to the bloodhound.apache.org list and then remove
>> trac-users@googlegroups.com on their first subsequent "reply all".
>
>
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Joe Dreimann <jo...@wandisco.com>.
On 16 Apr 2013, at 18:31, Ryan Ollos <ry...@wandisco.com> wrote:
> On Tue, Apr 16, 2013 at 9:07 AM, Olemis Lang <ol...@gmail.com> wrote:
>
>> As a side note to this thread in the last few days there are a
>> significant number of messages about Bloodhound sent to trac-users ML
>> (which is nice ... USERS ... hehe ! ;) . I've noticed that only
>> @rjollos and me have ever replied . So maybe it's a good idea to
>> subscribe to that list too (if not already done) and browse list
>> archive for recent messages . Alternately we could activate
>> users@bloodhound.apache.org too .
>>
>> Summarizing users have been requesting :
>>
>> - Migration from Trac>=0.11 to Bloodhound
>> - MySQL as DB backend
>> - Installation procedure using nginx
>> - Documentation about all this .
>
I believe our list is called user@b.a.o, not users@ and it is already active, I am subscribed to it at least.
- Joe
>
> I'm not sure if there is a good way to move the discussion over to a
> Bloodhound mailing list from the start, but I tried CC'ing
> dev@bloodhound.apache.org on a post just now and it seems to have at least
> gone through.
>
> Perhaps we can CC dev@ or users@ on the first reply, and ask users to
> subscribe to the bloodhound.apache.org list and then remove
> trac-users@googlegroups.com on their first subsequent "reply all".
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Ryan Ollos <ry...@wandisco.com>.
On Tue, Apr 16, 2013 at 9:07 AM, Olemis Lang <ol...@gmail.com> wrote:
> As a side note to this thread in the last few days there are a
> significant number of messages about Bloodhound sent to trac-users ML
> (which is nice ... USERS ... hehe ! ;) . I've noticed that only
> @rjollos and me have ever replied . So maybe it's a good idea to
> subscribe to that list too (if not already done) and browse list
> archive for recent messages . Alternately we could activate
> users@bloodhound.apache.org too .
>
> Summarizing users have been requesting :
>
> - Migration from Trac>=0.11 to Bloodhound
> - MySQL as DB backend
> - Installation procedure using nginx
> - Documentation about all this .
I'm not sure if there is a good way to move the discussion over to a
Bloodhound mailing list from the start, but I tried CC'ing
dev@bloodhound.apache.org on a post just now and it seems to have at least
gone through.
Perhaps we can CC dev@ or users@ on the first reply, and ask users to
subscribe to the bloodhound.apache.org list and then remove
trac-users@googlegroups.com on their first subsequent "reply all".
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Olemis Lang <ol...@gmail.com>.
As a side note to this thread in the last few days there are a
significant number of messages about Bloodhound sent to trac-users ML
(which is nice ... USERS ... hehe ! ;) . I've noticed that only
@rjollos and me have ever replied . So maybe it's a good idea to
subscribe to that list too (if not already done) and browse list
archive for recent messages . Alternately we could activate
users@bloodhound.apache.org too .
Summarizing users have been requesting :
- Migration from Trac>=0.11 to Bloodhound
- MySQL as DB backend
- Installation procedure using nginx
- Documentation about all this .
--
Regards,
Olemis.
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Gary Martin <ga...@wandisco.com>.
On 16/04/13 16:36, Ryan Ollos wrote:
> On Thu, Apr 11, 2013 at 9:56 AM, Andrej Golcov <an...@digiverse.si> wrote:
>
>>> Can we pass a key or something similar along in the URL that allows users
>>> to anonymously create tickets? I'm aware that this is a potential avenue
>>> for spam bots, but I still firmly believe that spam bots are
>>> technical/management issues for us to solve, and we should not to
>>> discourage users with our prevention methods as we're doing at the
>> moment.
>> Just one note, http://trac.edgewall.org allow ticket creation anonymous
>> users.
>> We can aslo add capture for anonymous users.
>
> Right, I think you mean Captcha, and it's a component of the previously
> mentioned SpamFilterPlugin that is hosted on t.e.o. It's probably worth
> considering.
>
> http://trac.edgewall.org/wiki/SpamFilter
>
It is worth investigating both of these though I am not particularly
keen on captchas myself. Given that we have ambitions to host more asf
projects, it might be good to get opinions from infra on this. Has Gavin
got any advice for example?
Cheers,
Gary
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Ryan Ollos <ry...@wandisco.com>.
On Thu, Apr 11, 2013 at 9:56 AM, Andrej Golcov <an...@digiverse.si> wrote:
> > Can we pass a key or something similar along in the URL that allows users
> > to anonymously create tickets? I'm aware that this is a potential avenue
> > for spam bots, but I still firmly believe that spam bots are
> > technical/management issues for us to solve, and we should not to
> > discourage users with our prevention methods as we're doing at the
> moment.
> Just one note, http://trac.edgewall.org allow ticket creation anonymous
> users.
> We can aslo add capture for anonymous users.
Right, I think you mean Captcha, and it's a component of the previously
mentioned SpamFilterPlugin that is hosted on t.e.o. It's probably worth
considering.
http://trac.edgewall.org/wiki/SpamFilter
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Andrej Golcov <an...@digiverse.si>.
> Can we pass a key or something similar along in the URL that allows users
> to anonymously create tickets? I'm aware that this is a potential avenue
> for spam bots, but I still firmly believe that spam bots are
> technical/management issues for us to solve, and we should not to
> discourage users with our prevention methods as we're doing at the moment.
Just one note, http://trac.edgewall.org allow ticket creation anonymous users.
We can aslo add capture for anonymous users.
Andrej
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Olemis Lang <ol...@gmail.com>.
On 4/16/13, Gary Martin <ga...@wandisco.com> wrote:
> On 16/04/13 22:53, Olemis Lang wrote:
>> On 4/16/13, Gary Martin <ga...@wandisco.com> wrote:
>>> On 16/04/13 17:17, Olemis Lang wrote:
[...]
>>> I think I have already mentioned that I am not a fan of capchas but that
>>> is just me and clearly I will not have to be dealing with it!
>>>
>> /me neither . If you ask me I suggest granting read only access to
>> anonymous user .
>>
>
> I take that to mean that you would be relatively happy with the access
> policy taken from apache's jira instance as long as it used OpenId.
Well , I actually do not know what to say since I'm not familiar with
Apache JIRA access policies . However , considering the fact that
recently commit policies have been 'relaxed' for ASF members to work
across projects then maybe it'd be useful to consider them as
«developers» and grant them with «enhanced» write access too .
[...]
--
Regards,
Olemis.
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Gary Martin <ga...@wandisco.com>.
On 16/04/13 22:53, Olemis Lang wrote:
> On 4/16/13, Gary Martin <ga...@wandisco.com> wrote:
>> On 16/04/13 17:17, Olemis Lang wrote:
> [...]
>>> right now it's incredibly important for us to attract user interest
>>> than dealing with «non-significant» spamming threats .
>>>
>> It is impossible to know whether the non-significance of spam threats is
>> a result of the current policy.
> It's good that you mention that . I'll clarify my statement . Even if
> our time will be wasted , it will always be possible to remove
> different kinds of spam . It will be much harder to make interested
> parties return after giving up because of the disappointing
> interaction with the site ... and we should focus on fostering user
> interest on Bloodhound . That's top priority now. Should spam become a
> serious issue then we apply further measures . That's what I meant .
> Notice that «non-significant» word is highlighted ;)
I'm afraid that my eyes strip out all markup in emails; it is lost on me.
> [...]
>> I think I have already mentioned that I am not a fan of capchas but that
>> is just me and clearly I will not have to be dealing with it!
>>
> /me neither . If you ask me I suggest granting read only access to
> anonymous user .
>
I take that to mean that you would be relatively happy with the access
policy taken from apache's jira instance as long as it used OpenId. If
possible I would prefer something even more open if we could balance
ease of raising issues with encouragement to be involved and limited
worry about abuse. I am not entirely sure where that balancing point is
at the moment so it is nice to see other opinions and ideas.
Cheers,
Gary
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Olemis Lang <ol...@gmail.com>.
On 4/16/13, Gary Martin <ga...@wandisco.com> wrote:
> On 16/04/13 17:17, Olemis Lang wrote:
[...]
>> right now it's incredibly important for us to attract user interest
>> than dealing with «non-significant» spamming threats .
>>
>
> It is impossible to know whether the non-significance of spam threats is
> a result of the current policy.
It's good that you mention that . I'll clarify my statement . Even if
our time will be wasted , it will always be possible to remove
different kinds of spam . It will be much harder to make interested
parties return after giving up because of the disappointing
interaction with the site ... and we should focus on fostering user
interest on Bloodhound . That's top priority now. Should spam become a
serious issue then we apply further measures . That's what I meant .
Notice that «non-significant» word is highlighted ;)
[...]
>
> I think I have already mentioned that I am not a fan of capchas but that
> is just me and clearly I will not have to be dealing with it!
>
/me neither . If you ask me I suggest granting read only access to
anonymous user .
--
Regards,
Olemis.
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Gary Martin <ga...@wandisco.com>.
On 16/04/13 17:17, Olemis Lang wrote:
> On 4/16/13, Joachim Dreimann <jo...@wandisco.com> wrote:
>> On 16 April 2013 16:34, Ryan Ollos <ry...@wandisco.com> wrote:
>>> On Thu, Apr 11, 2013 at 9:01 AM, Joachim Dreimann <
>>> joachim.dreimann@wandisco.com> wrote:
>>>
> [...]
>>> Yes, I think that we should be concerned that our barrier to posting an
>>> issue or other contribution may be too high at the moment. If I came to
>>> the
>>> site and couldn't immediately register and create a ticket, I may go away
>>> and never report the issue.
>>>
>> I am very concerned by this and would probably do the same as you. In fact
>> I may not even bother to register. If registration is required I usually
>> look for a project twitter account and send them a tweet reporting the bug.
>>
> I second that . I've been concerned about this for a long while . In
> my real life connected experience
>
> 1. I do not fill sign up forms in web sites . That's what
> OpenId is for . Bloodhound has been the exception
> since many years ago .
> 2. Forbid users to send us bug reports is something I
> do not understand . The way I see it users are contributing
> back to us . That makes no sense to me . IMO authenticated
> users should be granted with permissions to
> interact with the i.a.o/bh web site .
>
>> If they reply to me with something like "Thanks, but we won't take action
>> unless you resubmit via our website after registration" I know they value
>> process over action and will avoid dealing with them in future.
>>
> Definitely sure . Besides *they* are deliberately wasting your time
> ... I'd rather send them a message saying «welcome to the new open web
> fellows»
Whether or not it seems silly, as far as I am concerned we pick up bug
reports however they are posted. I haven't noticed any bugs sent through
twitter but I strongly suspect that we would at least take some notice!
Sending reports to the dev or user mailing lists is fine after all.
>
>>> I'll look into what we might do and propose some additional suggestions
>>> as
>>> part of the work on #503.
>>>
>>> The guys who setup trac-hacks felt that registration was even too high of
>>> a
>>> barrier, so it's possible to create an anonymous ticket on that site.
>>> That
>>> comes with other problems that I won't go into here, but I'll just say
>>> that
>>> spam is not a significant problem on trac-hacks.org, even though we are
>>> still running a very old version of SpamFilterPlugin. I monitor the RSS
>>> feed for both trac-hacks.org and trac.edgewall.org and see only a dozen
>>> or
>>> so instances of spam per week on each site; sometimes more, sometimes
>>> none.
>>> Cleaning up the spam on the former doesn't take up much of my time - I
>>> just
>>> spend a few minutes reviewing the RSS feed each morning and delete any
>>> spam
>>> that has come through.
>>>
>> I also review ticket changes / user registrations for spam. I haven't seen
>> any evidence of it in significant numbers. That includes spam registrations
>> that our current system doesn't prevent.
>>
>> I would grant every new registration permissions to create and comment on
>> tickets by default and try to catch out bots using some basic techniques
>> that users would never see (ie no captcha).
>>
> fwiw +
> right now it's incredibly important for us to attract user interest
> than dealing with «non-significant» spamming threats .
>
It is impossible to know whether the non-significance of spam threats is
a result of the current policy. However, I am not particularly happy
with the situation either.
The current situation on https://issues.apache.org/jira/ is that:
"Anyone is free to find issues. You must register and login if you
want to create, comment, vote, or watch issues. Only developers can
edit, prioritize, schedule and resolve issues."
The last part of that seems completely reasonable and we should probably
be enforcing that anyway. As for registration there, it does require a
capcha and we can clearly replicate that, allowing accounts to raise and
comment on tickets. It would be even better if we could allow tickets to
be raised and commented on by anonymous users and it also appears to be
possible to do this with a capcha if we like. The advantage of
registering an account may then just be to stop having to answer capchas!
I think I have already mentioned that I am not a fan of capchas but that
is just me and clearly I will not have to be dealing with it!
Cheers,
Gary
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Olemis Lang <ol...@gmail.com>.
On 4/16/13, Joachim Dreimann <jo...@wandisco.com> wrote:
> On 16 April 2013 16:34, Ryan Ollos <ry...@wandisco.com> wrote:
>> On Thu, Apr 11, 2013 at 9:01 AM, Joachim Dreimann <
>> joachim.dreimann@wandisco.com> wrote:
>>
[...]
>>
>> Yes, I think that we should be concerned that our barrier to posting an
>> issue or other contribution may be too high at the moment. If I came to
>> the
>> site and couldn't immediately register and create a ticket, I may go away
>> and never report the issue.
>>
>
> I am very concerned by this and would probably do the same as you. In fact
> I may not even bother to register. If registration is required I usually
> look for a project twitter account and send them a tweet reporting the bug.
>
I second that . I've been concerned about this for a long while . In
my real life connected experience
1. I do not fill sign up forms in web sites . That's what
OpenId is for . Bloodhound has been the exception
since many years ago .
2. Forbid users to send us bug reports is something I
do not understand . The way I see it users are contributing
back to us . That makes no sense to me . IMO authenticated
users should be granted with permissions to
interact with the i.a.o/bh web site .
> If they reply to me with something like "Thanks, but we won't take action
> unless you resubmit via our website after registration" I know they value
> process over action and will avoid dealing with them in future.
>
Definitely sure . Besides *they* are deliberately wasting your time
... I'd rather send them a message saying «welcome to the new open web
fellows»
>
>>
>> I'll look into what we might do and propose some additional suggestions
>> as
>> part of the work on #503.
>>
>> The guys who setup trac-hacks felt that registration was even too high of
>> a
>> barrier, so it's possible to create an anonymous ticket on that site.
>> That
>> comes with other problems that I won't go into here, but I'll just say
>> that
>> spam is not a significant problem on trac-hacks.org, even though we are
>> still running a very old version of SpamFilterPlugin. I monitor the RSS
>> feed for both trac-hacks.org and trac.edgewall.org and see only a dozen
>> or
>> so instances of spam per week on each site; sometimes more, sometimes
>> none.
>> Cleaning up the spam on the former doesn't take up much of my time - I
>> just
>> spend a few minutes reviewing the RSS feed each morning and delete any
>> spam
>> that has come through.
>>
>
> I also review ticket changes / user registrations for spam. I haven't seen
> any evidence of it in significant numbers. That includes spam registrations
> that our current system doesn't prevent.
>
> I would grant every new registration permissions to create and comment on
> tickets by default and try to catch out bots using some basic techniques
> that users would never see (ie no captcha).
>
fwiw +
right now it's incredibly important for us to attract user interest
than dealing with «non-significant» spamming threats .
--
Regards,
Olemis.
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 16 April 2013 16:34, Ryan Ollos <ry...@wandisco.com> wrote:
> On Thu, Apr 11, 2013 at 9:01 AM, Joachim Dreimann <
> joachim.dreimann@wandisco.com> wrote:
>
> > [...]
> >
> > Can we pass a key or something similar along in the URL that allows users
> > to anonymously create tickets? I'm aware that this is a potential avenue
> > for spam bots, but I still firmly believe that spam bots are
> > technical/management issues for us to solve, and we should not to
> > discourage users with our prevention methods as we're doing at the
> moment.
> >
>
> Yes, I think that we should be concerned that our barrier to posting an
> issue or other contribution may be too high at the moment. If I came to the
> site and couldn't immediately register and create a ticket, I may go away
> and never report the issue.
>
I am very concerned by this and would probably do the same as you. In fact
I may not even bother to register. If registration is required I usually
look for a project twitter account and send them a tweet reporting the bug.
If they reply to me with something like "Thanks, but we won't take action
unless you resubmit via our website after registration" I know they value
process over action and will avoid dealing with them in future.
>
> I'll look into what we might do and propose some additional suggestions as
> part of the work on #503.
>
> The guys who setup trac-hacks felt that registration was even too high of a
> barrier, so it's possible to create an anonymous ticket on that site. That
> comes with other problems that I won't go into here, but I'll just say that
> spam is not a significant problem on trac-hacks.org, even though we are
> still running a very old version of SpamFilterPlugin. I monitor the RSS
> feed for both trac-hacks.org and trac.edgewall.org and see only a dozen or
> so instances of spam per week on each site; sometimes more, sometimes none.
> Cleaning up the spam on the former doesn't take up much of my time - I just
> spend a few minutes reviewing the RSS feed each morning and delete any spam
> that has come through.
>
I also review ticket changes / user registrations for spam. I haven't seen
any evidence of it in significant numbers. That includes spam registrations
that our current system doesn't prevent.
I would grant every new registration permissions to create and comment on
tickets by default and try to catch out bots using some basic techniques
that users would never see (ie no captcha).
- Joe
--
Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/>
@jdreimann <https://twitter.com/jdreimann>
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Ryan Ollos <ry...@wandisco.com>.
On Thu, Apr 11, 2013 at 9:01 AM, Joachim Dreimann <
joachim.dreimann@wandisco.com> wrote:
> [...]
>
> Can we pass a key or something similar along in the URL that allows users
> to anonymously create tickets? I'm aware that this is a potential avenue
> for spam bots, but I still firmly believe that spam bots are
> technical/management issues for us to solve, and we should not to
> discourage users with our prevention methods as we're doing at the moment.
>
Yes, I think that we should be concerned that our barrier to posting an
issue or other contribution may be too high at the moment. If I came to the
site and couldn't immediately register and create a ticket, I may go away
and never report the issue.
I'll look into what we might do and propose some additional suggestions as
part of the work on #503.
The guys who setup trac-hacks felt that registration was even too high of a
barrier, so it's possible to create an anonymous ticket on that site. That
comes with other problems that I won't go into here, but I'll just say that
spam is not a significant problem on trac-hacks.org, even though we are
still running a very old version of SpamFilterPlugin. I monitor the RSS
feed for both trac-hacks.org and trac.edgewall.org and see only a dozen or
so instances of spam per week on each site; sometimes more, sometimes none.
Cleaning up the spam on the former doesn't take up much of my time - I just
spend a few minutes reviewing the RSS feed each morning and delete any spam
that has come through.
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 11 April 2013 11:27, Ryan Ollos <ry...@wandisco.com> wrote:
> On Thu, Apr 11, 2013 at 3:10 AM, Ryan Ollos <ry...@wandisco.com>wrote:
>
>> On Thu, Apr 11, 2013 at 1:51 AM, Joe Dreimann <
>> joachim.dreimann@wandisco.com> wrote:
>>
>>> No objection to that.
>>>
>>> Two questions:
>>> 1) Was it the error report that got the user to think it is a Trac
>>> problem? Do we need to amend this?
>>>
>>
>> I suspect most users don't look very closely at the content of the error
>> report. The Internal Error page has a link for opening an issue on
>> trac.edgewall.org, which populates the ticket description with the
>> user's Trac configuration. The user only has to click two buttons to create
>> a ticket on trac.edgewall.org. I suspect that in most cases, the user
>> doesn't carefully consider where the ticket should be reported, but just
>> clicks the two buttons to create a ticket. However, we can change where
>> that ticket is created with a small change to the Trac source.
>>
>
This sounds like an important thing for us to do. Great suggestion Ryan.
>>
>>> 2) Should we encourage people using bloodhound to raise all issues to us
>>> (incl likely Trac ones)?
>>>
>>
>> There is some relevant discussion about that in [1]. It appears to be
>> possible to change where the `Create` button direct to. I tried modifying
>> the `default_tracker` variable [2], and it appears to work as advertized.
>> In the case that the reporter has an account on
>> issues.apache.org/bloodhound and is already logged-in, the ticket would
>> be easily created in the Bloodhound issue tracker. If the user is not
>> logged-in to i.a.o/bloodhound, they land on the login page, however even
>> after logging-in they are not redirected to the /newticket page with a
>> populated form. That may just be a separate issue we need to address to
>> make the error reporting process go more smoothly.
>>
>
Can we pass a key or something similar along in the URL that allows users
to anonymously create tickets? I'm aware that this is a potential avenue
for spam bots, but I still firmly believe that spam bots are
technical/management issues for us to solve, and we should not to
discourage users with our prevention methods as we're doing at the moment.
After changing the `default_tracker` variable, there may still be some
>> cases that the `Create` button causes issues to be reported to trac-hacks
>> [3].
>>
>>
>>> I would say yes to the second one because so far we've always kept
>>> tickets like that open as a reference and raised one upstream. For users
>>> that makes our site a single point of contact, and we know what it is
>>> upstream that affects them.
>>>
>>> Cheers,
>>> Joe
>>>
>>
>> That sounds good to me as well. The argument for single point of contact
>> seems like a good one.
>>
>> [1] http://trac.edgewall.org/ticket/10898
>> [2]
>> http://trac.edgewall.org/browser/tags/trac-1.0.1/trac/web/main.py?marks=55-58#L53
>> [3]
>> http://trac.edgewall.org/browser/tags/trac-1.0.1/trac/web/main.py?marks=554#L546
>>
>
>
> A comment in t.e.o #11147 also suggests setting [project] admin_trac_url
> to point to the Bloodhound issues tracker.
> http://trac.edgewall.org/wiki/TracIni#project-section
>
Cheers,
Joe
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Ryan Ollos <ry...@wandisco.com>.
On Thu, Apr 11, 2013 at 3:10 AM, Ryan Ollos <ry...@wandisco.com> wrote:
> On Thu, Apr 11, 2013 at 1:51 AM, Joe Dreimann <
> joachim.dreimann@wandisco.com> wrote:
>
>> No objection to that.
>>
>> Two questions:
>> 1) Was it the error report that got the user to think it is a Trac
>> problem? Do we need to amend this?
>>
>
> I suspect most users don't look very closely at the content of the error
> report. The Internal Error page has a link for opening an issue on
> trac.edgewall.org, which populates the ticket description with the user's
> Trac configuration. The user only has to click two buttons to create a
> ticket on trac.edgewall.org. I suspect that in most cases, the user
> doesn't carefully consider where the ticket should be reported, but just
> clicks the two buttons to create a ticket. However, we can change where
> that ticket is created with a small change to the Trac source.
>
> [image: Inline image 1]
>
>
>
>
>> 2) Should we encourage people using bloodhound to raise all issues to us
>> (incl likely Trac ones)?
>>
>
> There is some relevant discussion about that in [1]. It appears to be
> possible to change where the `Create` button direct to. I tried modifying
> the `default_tracker` variable [2], and it appears to work as advertized.
> In the case that the reporter has an account on
> issues.apache.org/bloodhound and is already logged-in, the ticket would
> be easily created in the Bloodhound issue tracker. If the user is not
> logged-in to i.a.o/bloodhound, they land on the login page, however even
> after logging-in they are not redirected to the /newticket page with a
> populated form. That may just be a separate issue we need to address to
> make the error reporting process go more smoothly.
>
> After changing the `default_tracker` variable, there may still be some
> cases that the `Create` button causes issues to be reported to trac-hacks
> [3].
>
>
>> I would say yes to the second one because so far we've always kept
>> tickets like that open as a reference and raised one upstream. For users
>> that makes our site a single point of contact, and we know what it is
>> upstream that affects them.
>>
>> Cheers,
>> Joe
>>
>
> That sounds good to me as well. The argument for single point of contact
> seems like a good one.
>
> [1] http://trac.edgewall.org/ticket/10898
> [2]
> http://trac.edgewall.org/browser/tags/trac-1.0.1/trac/web/main.py?marks=55-58#L53
> [3]
> http://trac.edgewall.org/browser/tags/trac-1.0.1/trac/web/main.py?marks=554#L546
>
A comment in t.e.o #11147 also suggests setting [project] admin_trac_url to
point to the Bloodhound issues tracker.
http://trac.edgewall.org/wiki/TracIni#project-section
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Ryan Ollos <ry...@wandisco.com>.
On Thu, Apr 11, 2013 at 1:51 AM, Joe Dreimann <joachim.dreimann@wandisco.com
> wrote:
> No objection to that.
>
> Two questions:
> 1) Was it the error report that got the user to think it is a Trac
> problem? Do we need to amend this?
>
I suspect most users don't look very closely at the content of the error
report. The Internal Error page has a link for opening an issue on
trac.edgewall.org, which populates the ticket description with the user's
Trac configuration. The user only has to click two buttons to create a
ticket on trac.edgewall.org. I suspect that in most cases, the user doesn't
carefully consider where the ticket should be reported, but just clicks the
two buttons to create a ticket. However, we can change where that ticket is
created with a small change to the Trac source.
[image: Inline image 1]
> 2) Should we encourage people using bloodhound to raise all issues to us
> (incl likely Trac ones)?
>
There is some relevant discussion about that in [1]. It appears to be
possible to change where the `Create` button direct to. I tried modifying
the `default_tracker` variable [2], and it appears to work as advertized.
In the case that the reporter has an account on
issues.apache.org/bloodhoundand is already logged-in, the ticket would
be easily created in the
Bloodhound issue tracker. If the user is not logged-in to i.a.o/bloodhound,
they land on the login page, however even after logging-in they are not
redirected to the /newticket page with a populated form. That may just be a
separate issue we need to address to make the error reporting process go
more smoothly.
After changing the `default_tracker` variable, there may still be some
cases that the `Create` button causes issues to be reported to trac-hacks
[3].
> I would say yes to the second one because so far we've always kept tickets
> like that open as a reference and raised one upstream. For users that makes
> our site a single point of contact, and we know what it is upstream that
> affects them.
>
> Cheers,
> Joe
>
That sounds good to me as well. The argument for single point of contact
seems like a good one.
[1] http://trac.edgewall.org/ticket/10898
[2]
http://trac.edgewall.org/browser/tags/trac-1.0.1/trac/web/main.py?marks=55-58#L53
[3]
http://trac.edgewall.org/browser/tags/trac-1.0.1/trac/web/main.py?marks=554#L546
Re: Ticket for Bloodhound created on trac.edgewall.org
Posted by Joe Dreimann <jo...@wandisco.com>.
No objection to that.
Two questions:
1) Was it the error report that got the user to think it is a Trac problem? Do we need to amend this?
2) Should we encourage people using bloodhound to raise all issues to us (incl likely Trac ones)?
I would say yes to the second one because so far we've always kept tickets like that open as a reference and raised one upstream. For users that makes our site a single point of contact, and we know what it is upstream that affects them.
Cheers,
Joe
________________________
@jdreimann - Twitter
Sent from my phone
On 11 Apr 2013, at 09:30, Ryan Ollos <ry...@wandisco.com> wrote:
> There was a Bloodhound ticket reported to Trac yesterday [1]. I was
> thinking to ask the Trac devs to CC dev@bloodhound.apache.org on Bloodhound
> issues that are incorrectly reported to trac.edgewall.org. That way, we
> will see the issue even if the reporter never follows up by reporting the
> issue to Bloodhound. Does anyone foresee a problem with this?
>
> [1] http://trac.edgewall.org/ticket/11147