[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Latest Fedora Core 3 status: kernel testing needed

On Thu, 21 Oct 2004 14:41:31 -0600, Garrett Serack <gserack 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]