riley.marquis@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