ANNOUNCE: Review requests

[Matthew Miller]

On Thu, Mar 17, 2005 at 03:51:12PM -0500, Dave Lawrence wrote:
> Is this system externally accessible and if so, may I see how you have 
> it set up?

Yes, it's externally accessible -- you can pretty quickly find it from the
address in my .sig. I don't want it pounded on too much though, since we're
tryin' to get work done too. :)

Here's how our basic workflow goes:

 Each bug has three associated roles: Assignee, QA Contact, and
 Repository Wrangler. (Well, four, counting Reporter.)

 There is a 'fake' user named 'unassigned', who is the currently the default
 for all of these. That user's mail is forwarded to the project management
 team, and when a new bug comes in, the various roles are assigned.

 Generally, one Repo Wranger is associated with one tree in our (AFS-based)
 repository. I need to hack up bugzilla a bit further to make it able to
 have release-based defaults rather than just package-based. In our
 situation, Assignee and QA Contact are rather fluid, as we try to balance
 out knowledge, but in general it probably makes sense to have default
 per-package assignees (and maybe a team of QA Contacts assigned new work
 based on current workload?).

 We use the default list of Statuses, and each is associated with a
 clearly-defined state:

 Open bugs:

   UNCONFIRMED: new bug filed by someone outside of the project
   NEW:         new bug filed or confirmed by someone in the project
   ASSIGNED:    in progress
   REOPENED:    rejected by QA

  Awaiting QA:

   RESOLVED:    when the assignee finishes, the bug gets a comment
                with the relevant changelog entries and the new package
                version. The src rpm (with binaries in the special case
                of upstream updates which we don't rebuid) gets passed on
                to the QA contact via a "dropbox" directory in AFS. (which
                is restricted via AFS acls).

  Awaiting Release:

   VERIFIED:    QA contact inspects package (and particularly, the most
                recent changes) and makes sure that it still looks sane.
                We don't generally spend time regression-testing all 
                features of every package -- I wish we could. If it doesn't
                pass muster, it gets reopened. Otherwise, it gets marked
                as VERIFIED, and the src rpm is copied to a for-release
                area in AFS.

  Released to tree:

   CLOSED:      Repo Wrangler does final rebuild (currently, using dedicated
                build machines and a simple rebuildrpm script) of the
                package from for-release, signs the package, and copies
                it into the devel or updates or whatever tree, and marks
                the bug closed.


We could probably do with some more interim package signing along the way,
but basically we trust to the security of kerberos/AFS for in-progress
packages.

Also, all bugzilla-generated e-mail is tagged with custom X- headers
indicating the current state and various bug roles and so on, which makes it
easy to flag e-mail about, for example, bugs for which you are the QA
Contact which are RESOLVED, while ignoring work which isn't ready for you
yet or which has passed beyond where you're involved.

Bugs which are filed against a package for which no component currently
exists use the component "~ unlisted". I get these, and manually add the
component to bugzilla. (If there's a lot, I have simple script which does
this for multiple packages based on the output of "rpm -qip *".)

I also manage the priority field pretty closely, so it's actually
meaningful. (Another thing I want to do is restrict the set of people who
can change this.)


-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>