package shepherding (was Re: Fedora Bug Day Tomorrow: March 3rd 2004: Don't Bug Mark Day)

[Leonard den Ottolander]

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