Latest Fedora Core 3 status: kernel testing needed
mwiktowy at gmx.net
Fri Oct 22 04:44:46 UTC 2004
> Date: Thu, 21 Oct 2004 21:23:36 -0400
> From: Jeff Spaleta <jspaleta at gmail.com>
> On Thu, 21 Oct 2004 14:41:31 -0600, Garrett Serack <gserack at gmail.com> wrote:
> > I'm wondering what kind of volume that there is in the Bugzilla
> > Database. I've got (a few) free cycles, and wouldn't mind doing some
> > of that, and maybe could pitch in on an adhoc/volunteer basis.
> > Either that, or a small cadre of volunteer bug sorters? :)
> > It may not be perfect, but certainly better than nothing?
> Lots of volume unfortunately.... there are several issues that extra
> manpower in Core bugzilla could help resolve. There is a way for
> community to gain some limited access to bugzilla operations once they
> have shown they have a good grasp on triaging. But initially if you
> want to help out tracking down bugs to close out, you can get a hold
> of me on irc (or another person with bugzilla editting rights,
> #fedora-bugs on freenode if you want to talk about a bugs to close
> *cleaning out OLD rhl bugs:
> This is not an obvious case of just closing everything out and
> starting afresh. I've talk to some developers...all the developers who
> are dumb enough to end up in irc channels where I sit... about how
> they want triage to handle old bugs for packages they maintain. And
> guess what.. there is no concensus among package maintainers as to
> what to do.. This makes it troublesome for outside community to dig in
> and make headway here. This sort of thing is going to take community
> experts into different subsystems and not just someone with spare
> cycles to make significant gains here.
> And its definitely going to take each and every package maintainer to
> take a second and describe how they want community triagers to help
> deal with old bugs for each component.
> *refiling old crasher bugs for fedoralegacy.org:
> This is actually doable for someone in the community, it just takes
> cycles and from someone interested in getting important stale bugs
> over to legacy's bugzilla. There was some consensous reached as to how
> to handle this. I need to write the instructions down in the
> fedoraproject wiki.
> *marking bugs as duplicates
> Not difficult to do, but its very very easy to mark something as a
> duplicate in error. Something you can discuss in irc to cut your teeth
> for triage. If you take the time to find the duplicates I'll find the
> time to mark them as such in bugzilla for you.
> *dealing with needsinfo/worksforme situations
> lots of bug reports coming in don't have nearly enough information to
> be useful to anyone. As a triager you can respond via a comment to
> encourage the original report to include more information about the
> problem, if you can't reproduce it yourself. OR you can reproduce it
> and provide the additional log and configuration information to move
> things along. The problem here is, we need to build up a body "things
> that are useful to know" for different components as a resource, not
> unlike this page:
> *Using and writing 'nice' standard comment blocks for different situations.
Is it considered proper Bugzilla etiquette for an average user (i.e.
non-developer) to close bugs that that same user opened? I personally
have bugs that I have opened that have been fixed (either collaterally
or directly ... regardless, what was broken worksforme now) with no
comment in the bug from anyone. It seems fairly benign to me to be able
to close them or revoke them in some way. It would likely go a long way
in cleaning up some of the falsely open bugs in a way that distributes
the triaging accurately. I have not tried to do such a thing due to
developers freaking out (justifiably) in other bugs when someone goes
and messes with the bug header info. It seems to me that if you are the
source of the bug report, you are qualified to know when whatever was
buggy works now. Maybe even just a "Revoked" status that would make it
easier for official triagers to sort through the massive volume of false
More information about the test