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

[Mark McLoughlin]

Hi,

On Wed, 2004-03-03 at 00:55, Jef Spaleta wrote:

> How: 
> Come to the #fedora-bugs channel on the freenode irc network tomorrow
> and be a part of the discussion. Instead of writing a very long drawn
> out explanation of what you should be doing as a package shepherd. I'll
> just point you to an example. 
> 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.

	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. 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.

	I think we need to figure out what we're trying to achieve with these
shepherding lists and then figure out a way to use bugzilla to
effectively achieve those goals. We could start with the following

  + Give package shepherds bugzilla permissions so they can actually 
    modify bugs.

  + Come up with a triage guide that explains to shepherds how they 
    should:
      - Try and reproduce the bug
      - If its in an older version of the package, identify whether
        it has been fixed in later versions.
      - Look for duplicates
      - Mark bugs as NEEDINFO if there isn't enough information
      - Track NEEDINFO bugs and re-open if there has been more 
        information reported or close if no more information has
        been given within a certain time.
      - Set the bug's priority/severity
      - Identify if the bug exists upstream and has already been
        reported there.
      - Set the right keywords etc.
      - Work closely with the package maintainer

   + I think Leonard was also trying to do was figure out which bugs
     should be fixed in an update to the current release and which bugs
     should be fixed in Raw Hide. I'm not sure if there's already a
     way to do it, but it would be good if bugs could be marked in some
     way as to indicate that.


	Just some random thoughts ..

Good Luck,
Mark.