handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[David Crossley <cr...@apache.org>]

Luigi Bai wrote:
> Stefano Mazzocchi wrote:
> >> 
> >> Maybe it is more precise to say "When shit works /mostly/ well...". The 
> >> presence of a large number of outstanding Bugzilla issues, especially ones 
> >> with [PATCH]es attached, implies that things work well for committers, less 
> >> well for those of us who have to wait until "someone just gets around to 
> >> it". Fixing bugs isn't sexy, like Flow or Forms or Real Blocks. But it 
> >> should happen every once in a while, especially when other people have 
> >> already proposed the patches.
> >
> > If you have ideas on how to make it better, we are wide open to suggestions.
> 
> Okay, assuming your sincerity - what is the current method for committers 
> to find/fix/close issues in Bugzilla? Are votes used, or longest time 
> open, number of comments? How often are these criteria applied 
> (periodically, only FirstFriday, only before release)?
> 
> Knowing these, we can figure out a way to improve the system, or the 
> users's expectations (or both!).

None of the things that you mentioned are really criteria.
Bugs get addressed and patches applied when a committer
finds some spare time and jumps in to address them.

Contributers can ease this process by clearly describing
their issues and using sensible bug titles to attract attention.

All of us, committers and contributers, need to review the
contributions. Don't just leave it up to the poor overworked
committers. When other developers review the patches and issues,
then add constructive comments, that would help immensely.
A side-effect of that is to send an automated message
to the dev list, which reminds committers of the importance.

-- 
David Crossley

Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[Antonio Gallardo <ag...@agssa.net>]

Jorg Heymans dijo:
> Vadim Gritsenko wrote:
>> Jorg Heymans wrote:
>>
>>>
>>> First of all, thanks Luigi for bringing up something that has been on
>>> my mind for a long time! Cocoon's patch queue is nothing to be proud
>>> of to be honest, both in size and age.
>>>
>>> The only way to get an overworked committer off the hook in the long
>>> run is to guide and nurture people who are willing to provide patches.
>>> And this is not about sending automated emails, bugzilla voting or
>>> anything else, it's all about guiding that person until the patch gets
>>> applied or rejected. This can be done by reviewing it, commenting on
>>> it or improving it.
>>>
>>>
>>> How about assigning a queue-walker who's sole task is to review
>>> incoming patches ?
>>
>>
>> Thanks for volunteering! I hope with your help we will have more and
>> better patches :-D
>>
>
> Nice one :) I actually thought this would be more something for an
> overworked committer who would like to take it easy for a while.
>
> But i'll see what i can do, point taken ;)

You are welcome!  ;-)

Best Regards,

Antonio Gallardo

Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[Jorg Heymans <jh...@domek.be>]

Vadim Gritsenko wrote:
> Jorg Heymans wrote:
> 
>>
>> First of all, thanks Luigi for bringing up something that has been on 
>> my mind for a long time! Cocoon's patch queue is nothing to be proud 
>> of to be honest, both in size and age.
>>
>> The only way to get an overworked committer off the hook in the long 
>> run is to guide and nurture people who are willing to provide patches. 
>> And this is not about sending automated emails, bugzilla voting or 
>> anything else, it's all about guiding that person until the patch gets 
>> applied or rejected. This can be done by reviewing it, commenting on 
>> it or improving it.
>>
>>
>> How about assigning a queue-walker who's sole task is to review 
>> incoming patches ?
> 
> 
> Thanks for volunteering! I hope with your help we will have more and 
> better patches :-D
> 

Nice one :) I actually thought this would be more something for an 
overworked committer who would like to take it easy for a while.

But i'll see what i can do, point taken ;)

> Vadim
Jorg

Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[Vadim Gritsenko <va...@reverycodes.com>]

Jorg Heymans wrote:
> 
> First of all, thanks Luigi for bringing up something that has been on my 
> mind for a long time! Cocoon's patch queue is nothing to be proud of to 
> be honest, both in size and age.
> 
> The only way to get an overworked committer off the hook in the long run 
> is to guide and nurture people who are willing to provide patches. And 
> this is not about sending automated emails, bugzilla voting or anything 
> else, it's all about guiding that person until the patch gets applied or 
> rejected. This can be done by reviewing it, commenting on it or 
> improving it.
> 
> 
> How about assigning a queue-walker who's sole task is to review incoming 
> patches ?

Thanks for volunteering! I hope with your help we will have more and better 
patches :-D

Vadim

Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[Jorg Heymans <jh...@domek.be>]

Luigi Bai wrote:
> On Tue, 27 Oct 2004, David Crossley wrote:
> 
>> Luigi Bai wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>>>>
>>>>> Maybe it is more precise to say "When shit works /mostly/ well...". 
>>>>> The
>>>>> presence of a large number of outstanding Bugzilla issues, 
>>>>> especially ones
>>>>> with [PATCH]es attached, implies that things work well for 
>>>>> committers, less
>>>>> well for those of us who have to wait until "someone just gets 
>>>>> around to
>>>>> it". Fixing bugs isn't sexy, like Flow or Forms or Real Blocks. But it
>>>>> should happen every once in a while, especially when other people have
>>>>> already proposed the patches.
>>>>
>>>>
>>>> If you have ideas on how to make it better, we are wide open to 
>>>> suggestions.
>>>
>>>
>>> Okay, assuming your sincerity - what is the current method for 
>>> committers
>>> to find/fix/close issues in Bugzilla? Are votes used, or longest time
>>> open, number of comments? How often are these criteria applied
>>> (periodically, only FirstFriday, only before release)?
>>>
>>> Knowing these, we can figure out a way to improve the system, or the
>>> users's expectations (or both!).
>>
>>
>> None of the things that you mentioned are really criteria.
>> Bugs get addressed and patches applied when a committer
>> finds some spare time and jumps in to address them.
>>
>> Contributers can ease this process by clearly describing
>> their issues and using sensible bug titles to attract attention.
>>
> 
> The system you describe seems very subjective; there's no way to measure 
> how much attention can be brought to an issue. Would it be helpful to 
> more aggressively use the "voting" system in Bugzilla? In that way, 
> users and developers can "lobby" for issues they are most concerned 
> with; and then committers can better know what things the community 
> considers a priority. Right now it doesn't seem that many people use 
> (know about?) the voting facility.
> 
>> All of us, committers and contributers, need to review the
>> contributions. Don't just leave it up to the poor overworked
>> committers. When other developers review the patches and issues,
>> then add constructive comments, that would help immensely.
>> A side-effect of that is to send an automated message
>> to the dev list, which reminds committers of the importance.
>>
> 
> Many of the open issues have a subject line of [PATCH] - this implies to 
> me that someone has taken the time and effort to track down a problem 
> and provide a solution. It seems to me that those should certainly get 
> priority from a committer, if only to validate the work of the 
> individual and to provide feedback so a final solution can be put in place.
> 
> And the issue of "poor overworked committers" can be partially 
> alleviated by increasing the number of people deputized to commit bug 
> fixes. This will likely get even easier to administer when "real blocks" 
> become a reality; then individuals can be deputized "per block" (they 
> can be separate projects) without necessarily having commit access to 
> "core cocoon". Even now, with svn, if a committer puts crummy code in, 
> it can always be rolled back, so it seems that there's a net benefit 
> (less the potential risk of bad code) to having more committers.
> 

First of all, thanks Luigi for bringing up something that has been on my 
  mind for a long time! Cocoon's patch queue is nothing to be proud of 
to be honest, both in size and age.

The only way to get an overworked committer off the hook in the long run 
is to guide and nurture people who are willing to provide patches. And 
this is not about sending automated emails, bugzilla voting or anything 
else, it's all about guiding that person until the patch gets applied or 
rejected. This can be done by reviewing it, commenting on it or 
improving it.


How about assigning a queue-walker who's sole task is to review incoming 
patches ?


Regards
Jorg

Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[Ralph Goers <Ra...@dslextreme.com>]

Leszek Gawron said:

>
> May I ask what is the current procedure to become a commiter? From what
> I've seen on the list the only way to become one is to be introduced by
> another commiter? Is that right?

"With great power comes great responsibility"

 or

 "From those to whom much is given, much is expected."

I'd be interested in the answer too.

Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[Torsten Curdt <tc...@apache.org>]

> May I ask what is the current procedure to become a commiter? From what 
> I've seen on the list the only way to become one is to be introduced by 
> another commiter? Is that right?

Yepp!

Contribution in discussions, code and/or documentation
qualify for a nomination. If people are active and
demonstrate they would like to help ...and they also
show a good sense of community spirit...

...be sure people will notice!

cheers
--
Torsten

Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[Vadim Gritsenko <va...@reverycodes.com>]

Leszek Gawron wrote:
> 
> May I ask what is the current procedure to become a commiter? From what 
> I've seen on the list the only way to become one is to be introduced by 
> another commiter? Is that right?

Yes. Read more here

http://www.apache.org/foundation/how-it-works.html#meritocracy


Vadim

Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[Leszek Gawron <lg...@mobilebox.pl>]

Luigi Bai wrote:
> And the issue of "poor overworked committers" can be partially 
> alleviated by increasing the number of people deputized to commit bug 
> fixes. This will likely get even easier to administer when "real blocks" 
> become a reality; then individuals can be deputized "per block" (they 
> can be separate projects) without necessarily having commit access to 
> "core cocoon". Even now, with svn, if a committer puts crummy code in, 
> it can always be rolled back, so it seems that there's a net benefit 
> (less the potential risk of bad code) to having more committers.

May I ask what is the current procedure to become a commiter? From what 
I've seen on the list the only way to become one is to be introduced by 
another commiter? Is that right?

-- 
Leszek Gawron                                      lgawron@mobilebox.pl

Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[Luigi Bai <lp...@focalpoint.com>]

On Tue, 27 Oct 2004, David Crossley wrote:

> Luigi Bai wrote:
>> Stefano Mazzocchi wrote:
>>>>
>>>> Maybe it is more precise to say "When shit works /mostly/ well...". The
>>>> presence of a large number of outstanding Bugzilla issues, especially ones
>>>> with [PATCH]es attached, implies that things work well for committers, less
>>>> well for those of us who have to wait until "someone just gets around to
>>>> it". Fixing bugs isn't sexy, like Flow or Forms or Real Blocks. But it
>>>> should happen every once in a while, especially when other people have
>>>> already proposed the patches.
>>>
>>> If you have ideas on how to make it better, we are wide open to suggestions.
>>
>> Okay, assuming your sincerity - what is the current method for committers
>> to find/fix/close issues in Bugzilla? Are votes used, or longest time
>> open, number of comments? How often are these criteria applied
>> (periodically, only FirstFriday, only before release)?
>>
>> Knowing these, we can figure out a way to improve the system, or the
>> users's expectations (or both!).
>
> None of the things that you mentioned are really criteria.
> Bugs get addressed and patches applied when a committer
> finds some spare time and jumps in to address them.
>
> Contributers can ease this process by clearly describing
> their issues and using sensible bug titles to attract attention.
>

The system you describe seems very subjective; there's no way to measure 
how much attention can be brought to an issue. Would it be helpful to more 
aggressively use the "voting" system in Bugzilla? In that way, users and 
developers can "lobby" for issues they are most concerned with; and then 
committers can better know what things the community considers a priority. 
Right now it doesn't seem that many people use (know about?) the voting 
facility.

> All of us, committers and contributers, need to review the
> contributions. Don't just leave it up to the poor overworked
> committers. When other developers review the patches and issues,
> then add constructive comments, that would help immensely.
> A side-effect of that is to send an automated message
> to the dev list, which reminds committers of the importance.
>

Many of the open issues have a subject line of [PATCH] - this implies to 
me that someone has taken the time and effort to track down a problem and 
provide a solution. It seems to me that those should certainly get 
priority from a committer, if only to validate the work of the individual 
and to provide feedback so a final solution can be put in place.

And the issue of "poor overworked committers" can be partially alleviated 
by increasing the number of people deputized to commit bug fixes. This 
will likely get even easier to administer when "real blocks" become a 
reality; then individuals can be deputized "per block" (they can be 
separate projects) without necessarily having commit access to "core 
cocoon". Even now, with svn, if a committer puts crummy code in, it can 
always be rolled back, so it seems that there's a net benefit (less the 
potential risk of bad code) to having more committers.

> -- 
> David Crossley
>
>