quick reminders on release blocker process

[Adam Williamson]

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