FYI: bugzilla POST state for virt bugs & relation to bug triage

[Daniel P. Berrange]

The Fedora bug triage team has previously outlined a preferred workflow
for bugs:

  http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

Since this process has been documented and the bug triage team started
processing Fedora bugs, there has been some confusion wrt to certain bugs
which are in the "POST" state. That wiki page says maintainers are free
to adapt this workflow, and so this mail intends to clarify what the 
virtualization team have done with the POST state, and thus what the
Fedora bug triage team should do if they see bugs in this POST state. 

You may or may not know that there is a large team of Red Hat people working
on virtualization (upstream, in Fedora & in RHEL), and thus for any single
package there are a large number of people sharing responsibility for processing
bugs and producing fixes. At any point in time though, one person will be
designated 'committer' (or perhaps 'gate keeper') and they are responsibl
for actually applying the patches to the RPM. Before a patch gets applied
it also has to be reviewed & ACK'd by at least 3 people, and (if applicable)
accepted / merged by the upstream project.

The process a 'normal' bug follows according to the Fedora bug workflow
in the wiki page above is

   NEW -> ASSIGNED -> MODIFIED -> ON_QA -> CLOSED

This is insufficient for the 'gate keeper' model of applying patches to a
package. We thus make use of the further POST state. The person assigned
to a bug will prepare a patch and mail it to an upstream project and also
for review by other team members. At this point the bug is moved to the
POST state and the patch typically attached to the BZ. The 'gate keeper'
of the package will periodically look at all bugs in POST state and check
if they've been ACK'd by 3 people, apply the patch to the RPM  and move 
the bug to the MODIFIED state. So you can see the process used is only 
slightly changed to:

   NEW -> ASSIGNED -> POST -> MODIFIED -> ON_QA -> CLOSED

NB, we do *not* change the 'assigned to' contact when moving from the
ASSIGNED to POST state, because often the 'gate keeper' will reject a
patch requesting further work & thus even in the POST state the bug is
still the repsonsiblity of the person actually writing the patch.

In summary, "POST" means  'a patch is ready, but not yet applied'

Although this process was initiated for our RHEL product, we also follow
the same process for Fedora bugs in virtualization related components[1], 
since a consistent workflow is very important & we have same people working
on both RHEL & Fedora virt stuff. That said we do relax the 3-ack rule for
Fedora, and mostly focus on the requirement that it be accepted by the
appropriate upstream project.

So what does this mean for the Fedora triage team...

Basically this should have little-to-no impact on triage team's work. Simply
treat "POST" in the same way you would treat "ASSIGNED". ie, don't touch any
bugs in "POST" state, aside from closing those which are against end-of-life
Fedora  products.

Hope this clarifies any confusion there may be..

Regards,
Daniel

[1] virtualization components include at least xen, kernel-xen, libvirt,
    python-virtinst, virt-manager and kvm.
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|