Proposal: 1.8 release and development process changes
jg at freedesktop.org
Sun Sep 27 07:49:41 PDT 2009
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...
More information about the xorg-devel