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
