cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans ...@domek.be>
Subject Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)
Date Wed, 27 Oct 2004 07:36:19 GMT


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


Mime
View raw message