Hi, folks. I thought this mail might be helpful just to remind developers / packagers of a few points regarding the release freeze process and release blockers. We start the process of designating and monitoring release blockers quite a while before final freeze. What that means is that, right now, you may catch QA / releng team members arguing about whether or not one of your bugs is a release blocker and dropping comments containing assessments from blocker review meetings and so on. One key thing to remember right now is that at *this point*, that assessment has few practical consequences in terms of you fixing the bug in the F14 repo. We're just keeping on top of our processes. The final freeze is not in effect - it won't be until...well, according to the schedule, 2010-10-18, though TC is due 2010-10-12, and the freeze should usually be around the TC date. Regardless, it's not yet. :) So right now, you can still fix bugs the same way you can any time we're outside a freeze period: build a fixed package, submit it to updates-testing via Bodhi, pass the testing requirements, submit it to stable via Bodhi. The whole process of deciding whether a bug is a blocker does not matter at all in terms of pushing fixes until the freeze date. So don't worry overmuch about any release blocker-related chat in your bugs, right now, it doesn't mean a whole lot to you. Another thing I'd like to note is the 'nice-to-have' process. In practice, QA and releng have always taken fixes for some bugs that were not designated as blockers during freeze periods. For the F14 cycle, we've tried to formalize this process a bit. The full-fat documentation of it is still in draft form - see http://lists.fedoraproject.org/pipermail/test/2010-September/094067.html - but we're applying the practical process already, since anything is an improvement over random trac tickets and certain QA and releng folks keeping mental lists of packages that go into composes (which was the process up till now). If a bug is proposed and accepted as a 'nice-to-have' (NTH) bug, then we will accept a fix for that bug during the freeze period and include it in the RC builds, but we won't actually delay the release for that bug. So if we did an RC2 build, it failed validation, we were planning an RC3 build, and a fix for an NTH bug was made available during that window, the fix would be taken into the RC3 build. However, we would not trigger an RC3 build solely to include a fix for an NTH bug, and we would not delay the release because an NTH bug was not fixed. The proposal and acceptance process works much like the blocker process: to propose a bug as NTH it should be marked as blocking the F14-accepted tracker bug (for the future, there will be F15Alpha-accepted , F15Beta-accepted , F15-accepted and so on) and if it is reviewed and accepted it will have the whiteboard field AcceptedNTH added. So if you wind up with a bug that blocks F14-accepted and with the AcceptedNTH keyword, then you know that if you provide a tested fix for that bug during the freeze period, it will be accepted into the RC composes. After the freeze, fixes for bugs that aren't blocker or NTH bugs won't be taken into the RC composes and won't make the final release images, they'll go into the updates track. If you want to have a fix considered for final release after the freeze, propose the bug as a release blocker or NTH bug. Of course, as normal, if you have a bug marked as blocking F14Blocker and with the AcceptedBlocker keyword, it's a release blocker and we really *need* you to provide a tested fix for it, or the release won't go out. :) tl;dr summary: until freeze (2010-10-18), blocker / nice-to-have status doesn't affect you as a packager at all, ignore any debate about blocker status and just push fixes as normal. After freeze, only blocker / nice-to-have bug fixes will be taken into the release images, other fixes go out as updates. If you want your fix on the release images after freeze date, propose the bug as a blocker or NTH bug. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
