What: Fedora Bug Day: Learn to be a package shepherd Help us out with Fedora Core triage by picking your favorite Fedora Core package and acting as its community shepherd, by helping the package maintainer keep up with bug reports and submitted patches and so on and so forth.
Alan Cox I think said it best: "Track the bugs in your favorite package/component: * try to make a few minutes everyday to look through the new bugs filed in the last day for the package you want to watch. * Sign up for the upstream mailing lists and bug tracking system, so you can more effectively be able to move bugs reported to Fedora upstream where they are more likely to be fixed."
And to put a finer point on it Warren Togami adds: "Most projects don't have anything like an effective bug tracker of their own. Because of that, what we need are volunteers to serve as liaison to upstream projects. They should be members of those upstream mailing lists and pay attention to news/patches/security alerts there. Such helpers if they are diligent would be like assistants to the package maintainers, and learn things as they go as well as gain trust in the process"
When: March 3rd, starting at 14:00 UTC (09:00 EST)
Where: #fedora-bugs channel on freenode irc network
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. Poor Mark, he had to be the guinea pig package maintainer for leonardjo's proactive shepherding experiment. So instead of just picking on Mark, maybe its time to pick on..err i mean help...a few more package maintainers as well. So come on over to the #fedora-bugs channel tomorrow, pick a fedora core package you would like to start shepherding and start digging into the steaming pile of bugs waiting for you in bugzilla.
What else: And if you can't be a package shepherd just yet, you're you can still be useful for general Fedora Core Triage, and help clean out the cobwebs in bugzilla so developers can find the bugreports that need attention.
Huh: No Clue What I'm talking about when I say the phrase Fedora Triage? Take a quick look at the fedora-triage-list archives: https://lists.dulug.duke.edu/pipermail/fedora-triage-list/ These messages should hopefully tell you what its all about in more detail: http://tinyurl.com/ywma3 - Summary of my vision for Fedora Triage http://tinyurl.com/23alw - My short term goals and long term plan
-jef"black belt cat herder"spaleta
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.
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.
On Wed, 2004-03-03 at 04:28, Mark McLoughlin wrote:
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.
I've done the text file thing before too. I think the basic problem is that bugzilla is overcomplex and bloated and needs some top-down interaction design...
This isn't a productive suggestion for the short term ;-)
Alex's pygtk frontend to bugzilla may be the right approach; a non-web UI might cache enough locally to be a lot faster, and be able to e.g. keep multiple query results and bug lists at a time. It could also have hardcoded awareness of certain keywords and tracking bugs, and maybe have nice UI for dealing with milestones and things.
Havoc
-
Havoc Pennington -
Jef Spaleta -
Leonard den Ottolander -
Mark McLoughlin