You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Tim Funk <fu...@apache.org> on 2009/09/17 18:28:07 UTC
Re: Bug workflow
Anyone can change a bug to any status. (Much like in wikipedia - anyone
can edit any page) Then the community would police people who dont
behave. Which doesn't happen often.
-Tim
Uwe Günther wrote:
> How does this work, if someone identifies a bug as NO BUG, does somebody
> set the status to "Resolved" in Bugzilla or better: How is the work flow
> here and who can close/resolve a bug?
>
> In my case, I did some research in 47760 and IMO it isn't a bug. I but a
> comment there, CC-ed myself but what is the next step?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bug workflow
Posted by Mark Thomas <ma...@apache.org>.
Uwe Günther wrote:
> So I wasn't so wrong with the first one. Unfortunately there was nothing
> to code at all.
>
> So I am gonna go for some odd ones and go on with the good things to do.
>
> How does this work for non commiters; if they have a patch? Ok, 1st
> attach the patch to the bug, 2nd...?
Give the committers a couple of days or so to look at it. Drop a note to
the dev list of it looks like it has been missed. It will either be
applied and/or proposed as appropriate or you'll get some feedback on
what needs improving.
A couple of tips:
- provide patches against trunk unless trunk isn't affected
- provide patches in diff -u format
- avoid having cosmetic changes and functional changes in the same patch
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bug workflow
Posted by Uwe Günther <uw...@cscc.de>.
William A. Rowe, Jr. wrote:
>
> Bugzilla keywords we added for httpd include PatchAvailable (and FAQ and
> a few other obvious ones). At httpd, we encourage people to mark the bug
> as PatchAvailable as soon as the patch is apparently worth applying. This
> provides a quick search for committers who are looking for low-hanging
> fruit :)
Thanks for the pointer William, found the keywords explained in Bugzilla
right now:
https://issues.apache.org/bugzilla/describekeywords.cgi
--
Kind Regards
Uwe Günther
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bug workflow
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Uwe Günther wrote:
> So I wasn't so wrong with the first one. Unfortunately there was nothing
> to code at all.
>
> So I am gonna go for some odd ones and go on with the good things to do.
>
> How does this work for non commiters; if they have a patch? Ok, 1st
> attach the patch to the bug, 2nd...?
Bugzilla keywords we added for httpd include PatchAvailable (and FAQ and
a few other obvious ones). At httpd, we encourage people to mark the bug
as PatchAvailable as soon as the patch is apparently worth applying. This
provides a quick search for committers who are looking for low-hanging
fruit :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bug workflow
Posted by Uwe Günther <uw...@cscc.de>.
So I wasn't so wrong with the first one. Unfortunately there was nothing
to code at all.
So I am gonna go for some odd ones and go on with the good things to do.
How does this work for non commiters; if they have a patch? Ok, 1st
attach the patch to the bug, 2nd...?
--
Kind Regards
Uwe Günther
Tim Funk wrote:
> It differs by the person. So here is a wild guess ..
>
> But I would guess bugs are usually fixed 1st by interest. For example:
> Crap that bug affects my stuff too, I should look at that.
>
> Other bugs are fixed by how interesting they. For example: hmmm .. that
> seems odd - I think I'll look at that.
>
> Other bugs are fixed because they are there and its a good thing to do.
>
> I'm not sure about everyone else, but I think the general concensus is
> priority is useful in distinguishing enhancement vs bug. But high
> priority vs low seems ignored.
>
> Security fixes typically don't go into bugzilla. They are reported
> privately to the security list.
>
> -Tim
>
> Uwe Günther wrote:
>> So I could set this one to resolved! Thanks Tim.
>>
>> Some other questions are popping up in my head right now:
>>
>> - How do you guys to choose which bugs to fix first?
>>
>> OK there are priorities, you are able to fix some bugs,
>> others are more difficult to you, some are security
>> relevant, ....
>>
>> - If you pick up a bug for fixing, do you flag that up
>> somewhere in Bugzilla?
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bug workflow
Posted by Tim Funk <fu...@apache.org>.
It differs by the person. So here is a wild guess ..
But I would guess bugs are usually fixed 1st by interest. For example:
Crap that bug affects my stuff too, I should look at that.
Other bugs are fixed by how interesting they. For example: hmmm .. that
seems odd - I think I'll look at that.
Other bugs are fixed because they are there and its a good thing to do.
I'm not sure about everyone else, but I think the general concensus is
priority is useful in distinguishing enhancement vs bug. But high
priority vs low seems ignored.
Security fixes typically don't go into bugzilla. They are reported
privately to the security list.
-Tim
Uwe Günther wrote:
> So I could set this one to resolved! Thanks Tim.
>
> Some other questions are popping up in my head right now:
>
> - How do you guys to choose which bugs to fix first?
>
> OK there are priorities, you are able to fix some bugs,
> others are more difficult to you, some are security
> relevant, ....
>
> - If you pick up a bug for fixing, do you flag that up
> somewhere in Bugzilla?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bug workflow
Posted by Uwe Günther <uw...@cscc.de>.
Mark Thomas wrote:
> Thank you. Help closing bugs is always much appreciated.
Thank you too.
> - security bugs (handled on a private list)
> - regressions
> - things I (or my employer*) care about
> - oldest open 5.5.x or 6.0.x bug without a patch
> - enhancements
>
> * This only applies during work hours :)
I am gonna pin this on my wall. :-)
> Normally no. Mainly, I think, because we rarely get clashes. Most bugs
> don't take that long to fix so the likelihood of clashes is small. As
> the number of open bugs decreases (there are now less than 50 open bugs
> against tc5 and tc6 without patches) the chances of a clash increase.
> I'd suggest if you find yourself spending more than an hour on a bug it
> is worth noting it. I'd also suggest you include a rough time frame for
> when you expect to have an update so other folks can tell if a bug is
> being worked on or not.
Thanks for pointing that out and makes sense to me. So we will see how
ti goes. :-)
--
Kind Regards
Uwe Günther
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bug workflow
Posted by Mark Thomas <ma...@apache.org>.
Uwe Günther wrote:
> So I could set this one to resolved! Thanks Tim.
Thank you. Help closing bugs is always much appreciated.
> Some other questions are popping up in my head right now:
>
> - How do you guys to choose which bugs to fix first?
As we say at the ASF - you scratch you own itch. We don't have a
community wide priority - each developer will prioritise them their own
my. My personal priority list is something like:
- security bugs (handled on a private list)
- regressions
- things I (or my employer*) care about
- oldest open 5.5.x or 6.0.x bug without a patch
- enhancements
* This only applies during work hours :)
There are, of course, some exceptions to my rules:
- A bug/enhancement with a patch and a good explanation (or better yet a
test case, including source code, that runs without any hassle) is
likely to get committed as soon as I see it.
- I am trying to balance bug fixing and Servlet 3 development so doing a
bit of each
> - If you pick up a bug for fixing, do you flag that up
> somewhere in Bugzilla?
Normally no. Mainly, I think, because we rarely get clashes. Most bugs
don't take that long to fix so the likelihood of clashes is small. As
the number of open bugs decreases (there are now less than 50 open bugs
against tc5 and tc6 without patches) the chances of a clash increase.
I'd suggest if you find yourself spending more than an hour on a bug it
is worth noting it. I'd also suggest you include a rough time frame for
when you expect to have an update so other folks can tell if a bug is
being worked on or not.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bug workflow
Posted by Uwe Günther <uw...@cscc.de>.
So I could set this one to resolved! Thanks Tim.
Some other questions are popping up in my head right now:
- How do you guys to choose which bugs to fix first?
OK there are priorities, you are able to fix some bugs,
others are more difficult to you, some are security
relevant, ....
- If you pick up a bug for fixing, do you flag that up
somewhere in Bugzilla?
--
Kind Regards
Uwe Günther
Tim Funk wrote:
> Anyone can change a bug to any status. (Much like in wikipedia - anyone
> can edit any page) Then the community would police people who dont
> behave. Which doesn't happen often.
>
> -Tim
>
> Uwe Günther wrote:
>> How does this work, if someone identifies a bug as NO BUG, does
>> somebody set the status to "Resolved" in Bugzilla or better: How is
>> the work flow here and who can close/resolve a bug?
>>
>> In my case, I did some research in 47760 and IMO it isn't a bug. I but
>> a comment there, CC-ed myself but what is the next step?
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org