cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luigi Bai <lpb+coc...@focalpoint.com>
Subject Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)
Date Wed, 27 Oct 2004 00:03:08 GMT
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
>
>

Mime
View raw message