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 _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
