riley.marquis@xxxxxxxxxxxxxxx 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
--
fedora-triage-list mailing list
fedora-triage-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-triage-list
