On 2008-01-02, 16:07 GMT, Greg DeKoenigsberg wrote: > Maybe. GNOME certainly tries this, as does Ubuntu. But > Ubuntu's triage situation isn't much better than ours, from > what I can tell. > > First, though, there needs to be someone who says "I Am The > Bugmaster For Fedora." If the right leader emerges, the rest > would probably follow quite naturally from that, I think. I am not the one, I can only say that I am *a* bugmaster for the Red Hat desktop team (employed by Red Hat). I can clearly see that there is a huge need for bug triaging team on our bugzilla, but let me add couple of notes here (actually is is getting pretty long): * I have no clue how to create the team -- it should be probably done by somebody how would be more skilled in actual team-building and stuff like that, than somebody able to plow through bugzilla. * There is a need to create a lot of documentation -- the stuff which is available inside our Bugzilla is mostly obsolete and/or misleading. Some stuff is available on gnome.org, but their problems are slightly different than ours, about which later. We tried inside of the desktop team to build some Bug Triaging policy. It is not finished yet (and it has desktop bias), so just as an information about what we are thinking about it is available at http://mcepl.fedorapeople.org/docs/bug-triaging-guide.xhtml Comments are more than welcome. * Gnome.org and their bug triaging is often used as an example how to do it. Certainly, Luis did a lot of great work, but when we were talking about it in summer (when he was interning in the Red Hat legal department), we came to the conclusion that the situation in our bugzilla is quite different. The biggest concern of their bug triaging is to deal with the flood of bug-buddy generated thousands of duplicates for crashes in Gnome programs. On the one hand the flood is intense, on the other hand, it is quite easily possible to diagnose and massage these bugs with some scripts (see http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates and related pages). Our bugs are all hand-written and very diverse in their formats, so there is probably not much any script can do. We have fewer duplicates than them, but each of them have to be really opened by humans, analyzed, and decided upon. That means that many strategies and ideas, they developed, is not directly applicable to us. * If I can judge by my almost-a-year-long experience with desktop (and especially xorg), it seems to me that the one of the biggest problems is lack of the bug retention policy. If our bugzilla is supposed to be a tool for developers, we must get keep cleaning our BZ for all bugs which will most likely be never dealt with and keep all remaining active bugs fresh all the time. See the above draft of the bug triaging policy for some ideas I have on this. * Other issue (which doesn't happen in Gnome bugzilla at all) is upstreaming -- what bugs should go upstream, and how to deal with them in our BZ. Again, although some improvement can be made by developing of some tools for doing the work, there is plenty of work which could be done by bug triagers -- if we just don't want to dump our trash over the fence to a neighbor's garden, we have to search upstream bugzillas (or other bug databases) for the upstream bugs, and to maintain the link between the state of them and our bug. Concerning the dealing with them in our BZ -- when we close them as UPSTREAM, it is kind of hypocritical situation. We just don't want to see them anymore. However, IMHO the proper solution would be to deal with the upstream bugzilla as a kind of developer -- the bug should be (kind of) ASSIGNED to it, and when the upstream generates a patch (or new release containing the fix) we should apply it and QA it (at least by asking reporter to test the new package) * And there is no magical solution -- “drastic measures” will IMHO not provide long term solution to our problems, and will (if they will make any change at all) just hide them and delay the proper solution. That's probably all what goes through my head just now. Any reactions? Matej _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
