Fedora Bugzilla Statistics 2009-05-26 - 2009-06-01

Adam Williamson awilliam at redhat.com
Tue Jun 2 16:53:24 UTC 2009


On Tue, 2009-06-02 at 08:28 -0800, Jeff Spaleta wrote:
> On Mon, Jun 1, 2009 at 11:32 PM, Brennan Ashton
> <bashton at brennanashton.com> wrote:
> > There is much more information that can be pulled via a turbogrears
> > app we are running.  But I am looking to see what is useful in terms
> > of a weekly report.  I have the date tuesday to tuesday as it matches
> > up with the Bugzappers meeting time.
> 
> Are you geared up for component by component reporting or perhaps
> groups of components?  

Yes, we can do this.

> How do triagers currently organize their time
> when picking components? 

We have a page:

https://fedoraproject.org/wiki/BugZappers/Components_and_Triagers

which lists what we consider the most important components (they're
basically the ones for which the most reports are filed). Triagers are
encouraged to specialize in one or a few of these components, in order
that they will have a good knowledge base for the issues they're
triaging and won't just be doing 'drive-by triaging' of bugs they don't
really understand.

> Would component-by-component reporting help
> spread/grow  triage manpower into hot spot areas of the repository?

It could do, but on the other hand, we're mostly getting to the point
where the components that lack coverage are ones which need a triager
who's already knowledgeable about that component: we can't just
parachute someone in. (see e.g. anaconda and kernel).

> And the flipside, can you visualize how triage manpower is actually
> spread through the repository currently? Are our expert smoke jumpers
> landing near the hotspots without a lot of coordinated effort? or is
> triage being done mostly by maintainers, fighting the local fires in
> their back yards?

I'll leave this one mostly to Brennan, but I think the position is that
we don't currently have a report that tracks this really well, but it
could be done.

> And in the future I'd like to see weekly reporting  feature by feature
> that gives a sense of progress on bugs loosely associated with a
> feature proposal.  Can we visualize the effect that feature specific
> test days have on the bug lifecycle for that feature?

It may be hard to use this system to specifically track test day-related
bugs with any detail. James Laska and I are interested in doing better
statistical tracking of the impact of test days; I did some preliminary
stuff on this for the graphics test days for F11, we will try and do
this in a more organized way, for more test days, for F12.

> Also reporting on tracking the aggregate progress on tracker/blocker
> bugs for the next release.  Can you highlight work or drive interest
> in working on release target and blocker bugs in some way in the
> reporting?

For the F12 cycle we should have the new severity assessment process in
place, so we should be able to generate some numbers which take the
severity rating of the bugs assigned by the Bugzappers team into
account.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net




More information about the devel mailing list