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 :| -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
