Hi Mark, > > http://www.ottolander.nl/gnome-panel/ > > > > I think leonardjo created a very useful shepherding tool with this > > simple static table. I think people might be able to do a lot of good > > taking this static table summary example and reusing it for other > > packages in Fedora Core. > > Hmm, I'm not creating a separate list of bugs outside of bugzilla is > such a great idea. It requires a lot of work to keep the two in sync, > and it actually tends to be more awkward than just using bugzilla > itself. The amount of work to keep such scratch lists in sync with bugzilla is minimal. I already have a working perl script that gets new bugs (currently only open issues, and possibly also UPSTREAM and DEFERRED issues) from bugzilla (by component) and adds them to a database. It will not overwrite edited entries, but it will fill in empty ones. New bugs will be added to the default "uncategorized bugs" category. Categorized bugs will remain in their category even if fields are updated. This script can be run in a daily cron job (or as an hourly cron job for 100 packages at a time). I am not sure if it is easy to create such scratch lists from bugzilla. What makes this example useful is that it enables you to create arbitrary categories, and sort bugs accordingly. That is what allowed me to get a grip on them. Also there is the (minor) fact that packages could exist in two scratch list. Fe, in the above list there are still references to bugs that were moved to other components. Since the filling of the scratch list and the removing of components by the shepherd are not in sync you could have duplicate entries for a while. I solve this by having the primary index on packageID/bugID. Not sure if that would work in bugzilla. > I've tried doing similar things myself in the past, but I always find > that the list becomes quickly out of date and I just go back to bugzilla > again. Resolved issues can be deleted from the list by the package catherd. Since the perl script only imports open issues they will not reappear after the next cron job. What I am working on now is a way to reorder the categories and bugs within a category. Oh, and you don't need to tell me not to waste my time on this, as I can probably put such reorderable lists to good use any way. > Another example is that the GTK+ team currently has a list of > "willfix" issues for the 2.4.x release, but they're still finding it > more useful to work directly from bugzilla. Of course bugzilla is the central place where the bug handling should take place. The example is a scratch list, and should be considered as such. Leonard. -- mount -t life -o ro /dev/dna /genetic/research
