On Fri, 2011-04-22 at 12:06 +0200, Christoph Wickert wrote: Yup. Go / No-Go meetings are far too late, though. So, here's the deal with how it works. The key point to keep in mind is that bug reports are _central to the process_: keep bug reports in the right state at all times and things should work out. We don't review tag requests as tickets for rel-eng on a case by case basis any more; that system was too haphazard and arbitrary. We use the release blocker and NTH bug processes. Once we freeze for any release (Alpha, Beta, GA) then only packages which fix a bug accepted as a release blocker or NTH (nice-to-have) bug will be taken through the freeze, into that release compose. As you noted, Xfce cannot block the release per current policy - this is not QA's determination to make, we just roll with whatever the policy is. Currently, GNOME (in its capacity as the 'default desktop') and KDE can block the release; no other spin or desktop can. So Xfce doesn't need to worry about the blocker process, only the NTH process. Issues that are 'blockers' for the Xfce spin are by definition NTH for the project as a whole, so the Xfce blocker bugs should block the project *NTH* bugs, not the project blocker bugs. (F15Blocker-xfce should block F15-accepted, for instance). Executive summary so far, if you want a fix taken through a freeze, then you must propose a bug that it fixes as NTH - mark it as blocking F15-accepted (final release), F15Beta-accepted (Beta), F15Alpha-accepted (Alpha). Same names but 16 for F16, and so on. What happens once a bug is proposed is that it gets reviewed at the next blocker review meeting. These happen weekly on Fridays. If we (the review team is QA plus releng plus whoever else happens along, if you come to the meeting we'll take your views into account; usually we get a consensus for each bug) accept the bug as NTH, it'll get 'AcceptedNTH' added to its whiteboard field. Once a bug is in this state, if you build a fix for it, that fix can go through a freeze: but releng needs to know it exists. Again, we go via the bug reports for this - so you need to make sure you mark the update as fixing the bug in Bodhi, so the bug report gets automatically updated as the fix is pushed and tested. If there's a bug marked as AcceptedNTH but the bug report doesn't say anything about there being a package around to fix it, nothing will happen. If you *do* make sure the bug report has info about the fix, then the build should get listed in the releng trac ticket for the upcoming candidate build. For instance, here's the trac ticket for F15 Beta RC, listing all the packages that needed to be pulled in: https://fedorahosted.org/rel-eng/ticket/4538 So, again a broad summary of the process: * Propose a bug as NTH * Build a fix for it and make sure this info is available in the bug * Make sure the fix gets karma (we usually won't take a fix without karma) * Optionally, come to the blocker review meeting to make sure it gets accepted as NTH, and keep an eye on the trac ticket for the upcoming candidate build to make sure the fix gets listed there - but these two bits should happen even if you don't get involved The criteria ('principles') for NTH bugs are here: https://fedoraproject.org/wiki/QA:SOP_nth_bug_process As noted, we consider any release criteria-breaking bug in a non-blocking spin like Xfce to be automatically an NTH bug. Note that we won't do a re-spin *solely* for NTH issues: so if we have, say, an RC2 spin which fixes all known blockers, and then fixes arrive for a couple of NTH issues, we won't do an RC3 spin to include the NTH fixes. We only re-spin for blockers. The Go/No-go meeting only decides whether to bless the current candidate build for gold, or delay for a week; we would never delay for an NTH issue (that's the definition of the difference between NTH and blockers), so unless we happen to delay for some real blocker issues, go/no-go meeting is already too late for any NTH fixes to happen. For the above reasons, the TC builds are vital for non-blocking desktops; you know that there will be at least one RC build, but you're never guaranteed one more. So make sure to test the TC, mark any critical bugs you find in it as NTH, and get fixes in before we start spinning RCs, so you can be sure they'll make it in. Hope that helped! Let me know if you have any questions. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net