Bugzilla Ideas For 2008

[John Poelstra]

riley.marquis at tcsresearch.org said the following on 12/20/2007 07:05 PM 
Pacific Time:
> Greetings!
> I had a few ideas which I hope will be helpful to the Fedora Bug Squad, so
> I thought I would run them by everybody and get a discussion going to see
> exactly how helpful these ideas might be.
> 
> 1: Dedicated Fedora Bugzilla
> Should we copy all the Fedora bugs, incl. bugs for the Fedora Directory
> Server, to a new host, e.g. bugs.fedoraproject.org or
> bugzilla.fedoraprojhect.org?  I was thinking this might be one way to
> minimize strain on our Bugzilla servers.  I know this could be a very time
> consuming project, so we should only do this if it is worth the hassle.

What strain on our servers are you referring to?

> 2: Add An "Expired" Tag To Bugzilla
> Should both the Redhat and Fedora Bugzillas have a new tag added to the
> system, called "Expired" (or whatever name we wish) for all tickets which
> have had x amount of days with no activity, instead of simply calling it
> "Closed"?  I was thinking this might allow the bug squad to more easily
> find unresolved issues, esp. long-awaited features such as encrypted
> filesystems.

Red Hat could have different business rules for their products so 
discussion here should focus on Fedora.  I like your idea of some type 
of expiration.  With over 13,000 open Fedora bugs, something has to be done.

> 3: Old Bug Deletion/Archival
> Should we delete bugs that have been closed for x amount of time, esp. the
> ones that we will likely never again need to reference, such as fc6 and
> earlier bugs?  If deletion is not an option, perhaps we should setup a
> legacy server to store these old bugs, as it will be hardly used and make
> more resources available for new Fedora bugs?  If we can use it, perhaps
> bugs.fedoralegacy.org or bugzilla.fedoralegacy.org?

I don't believe space is a problem and bug history is important, 
particularly when changelog entries refer to them by number.  Having to 
search in two different systems doesn't make sense.


> 4: Contingency Plan
> I know Bugzilla is a very important part of our infrastructure, and
> without it we'd be FUBAR, so maybe we can make a duplicate copy of the
> bugzilla server on a test machine and make the proposed changes on this
> test machine first?  I always prefer having a separate development
> environment, since borking something during development won't make any
> changes to a production machine.  Maybe we can do a MySQL dump and write a
> script that would make the changes for us automatically?  For example, if
> we were using a MySQL script to make the changes:
> 	SELECT * FROM bugs WHERE daysopen > 90 etc.

This is a good idea, but Red Hat already has us covered here in terms of 
database replication, backups, and disaster recovery.

> Perhaps this script we write can simply give us statistics first, such as
> how many bugs would be set to "Expired" or moved to the legacy Bugzilla
> before making any changes.  Then we can mod the script to do the real
> thing once everyone approves of the new setup.

I think an analysis of bug aging is a good place to start, but I 
disagree that our focus should be on moving bugs between different 
instances of bugzilla as there is very little to gain by doing that.

Right now we would gain from a couple of things:

1) Creating new processes and procedures surrounding how we triage and 
resolve incoming bugs for only Fedora 8 and Rawhide.

2) Come to common agreement on how to close out the remaining bugs for 
Fedora(Core) 1 to 7.  Is it really realistic to think that we are *ever* 
going to be able to go through all 13,000 bugs, read the comments, and 
take action on each one?

These are my thoughts.  Thanks for starting this conversation.

John