Proposal: 1.8 release and development process changes

[Jim Gettys]

Peter Hutterer wrote:

> 
> Applying a patch from bugzilla is less convenient than cherry-picking it,
> but the general bugzilla interface is superior to the wiki. Per-bug emails,
> bug states and a formal method + history of discussion. From a social point
> or view we behave better too: in general, we tend to stick explanations why
> a bug is accepted or rejected into the bugreports but this isn't necessarily
> the case on the wiki. For example, I don't know why
> 09df7cc5ad7b72d8a23c3e22fc718aad8c16f4d3 was rejected for 1.6.x just by
> looking at the wiki page
> 

There are other systems than Bugzilla, which have wiki facilities that 
can be useful (though it isn't clear they are competitive as wiki's). 
At OLPC we used trac; it left a mixed taste in my mouth.  From the 
developer's perspective, it's ui was better, and it has a good plug in 
system that was quite useful (think of it as a giant swiss army knife, 
but it's an "assemble yourself" swiss army knife).

But having one sea of bugs when there are many subprojects makes it 
difficult to see the forest for the trees as the number of bugs go up 
(true for both Bugzilla and for Trac).  Managing a release with a large 
number of bugs and contributors was difficult when the traffic grew more 
than I could deal with in a day: trac is too centralized.  And it is not 
good to be able to delegate control of a project to others; it has no 
project support, and that is quite important, IMHO.

For Bell Labs, I've just taken yet another look at this whole area: I'm 
about to install redmine and see how that goes.  It is much more than a 
bug tracking system, and has (sub)project support.  I installed an 
instance at home and have been using it for my "honeydew" list; the 
items that drove me batty with trac seem to have good solutions.  It has 
subproject support with good adminstrative control delegation.

I might have stayed with trac, but as a project, trac doesn't seem to 
have mastered the "regular release" mantras, and project support, 
extensively  discussed a year ago on their mailing list, still is a 
"someday" feature.  A feature I asked for several years ago to allow 
operating on sets of bugs simultaneously is also sitting on a branch, 
unmerged. I can't live with those lacks any longer. These tools always 
get modified by serious downstream projects ultimately, and if the 
upstream isn't responsive, the next time you need to upgrade  or have a 
serious problem (usually in the middle of trying to do a release) having 
to integrate local changes is a PITA.  And with irregular, long 
releases, one starts getting very nervous about upgrades as well.

The downside of redmine (which is also a swiss army knife, but one where 
you can turn on blades at the click of a button, rather than assembling 
them from a pile of metal parts on the table), is that it's a Ruby on 
Rails application; yet another language...

See: http://www.redmine.org/

			- Jim