pushes to stable during freeze - process question

[Adam Williamson]

On Mon, 2011-11-07 at 04:19 -0500, Kamil Paral wrote:
> > On Thu, 27 Oct 2011 07:59:12 -0400 (EDT)
> > Kamil Paral <kparal at redhat.com> wrote:
> > 
> > > Quick question,
> > > 
> > > how do rel-eng guys know which updates are OK to push to stable
> > > during freeze and which are not? For example we have the final
> > > freeze
> > > now. Some packages like this:
> > > https://admin.fedoraproject.org/updates/FEDORA-2011-14932 are
> > > needed
> > > to be pushed to stable repo, so they have an exception from the
> > > freeze. Blocker and NTH updates have also exception from the
> > > freeze.
> > > But other packages may be also requesting push to stable and not be
> > > eligible for an exception. How do the rel-eng guys know which
> > > packages to push and which not to?
> > 
> > QA files a ticket for each compose before it's made (ie, "we need
> > another RC" or 'We need another TC'). In this ticket are listed the
> > updates that are needed to be allowed into stable or used for the
> > compose.
> > 
> > So for example:
> > 
> > https://fedorahosted.org/rel-eng/ticket/4951
> > 
> > kevin
> 
> Thanks Kevin,
> 
> now it's clear.

This should probably be documented somewhere, but I'm not entirely sure
where.

The process is fairly simple, though. For raptor-proofing purposes:

When to request the *initial* TC is on the release schedule. When to
request further TCs is essentially a judgment call, there's no rule
about it. Usually it's worth requesting one when there are significant
changes in things like anaconda, kernel, lorax, plymouth etc compared to
the previous TC.

When to request the initial RC is also on the schedule, but there are
specific rules about composing RCs:

* They must happen after freeze (no image prior to freeze date can
possibly be an RC)
* They must address all accepted blocker bugs (no image which does not
address an accepted blocker bug can possibly be an RC)

So it's fairly straightforward to do RCs: you request the first one once
the freeze has happened and all open blockers are addressed (usually
this means fixes are available and have the necessary karma to go
stable, but there are sometimes unusual blockers which get 'addressed'
some other way - tell releng to block a certain package from compose,
for e.g.). You can't request an RC if all open blockers are not yet
addressed, even if it's 'due': you have to wait. You can, however, do a
new TC build on the RC date if it looks like all blockers won't be fixed
for a bit, but you want something out there for testing.

You do subsequent RC composes if further blockers emerge in the first
RC, and again, request them when fixes are available and push-able for
all currently known blocker bugs. Note that you *can't* request an RC2
if RC1 turned out to have two blockers, and only one has been fixed so
far. You have to have both new blockers fixed before spinning an RC2. In
theory you could spin a TC *after* an RC in a case like this, and we
came close to doing that for F16, but in the end we didn't, and never
have.

How you actually do a compose request is pretty simple: just go through
the blocker list and list out all the updates that must be pulled into
the compose to address all *accepted* blockers, and list any special
instructions like 'make sure you use the latest spin-kickstarts' or
'block package XXX from the compose' or whatever. Also go through the
NTH list and list any updates for *accepted* NTH bugs which have
sufficient karma. List NTH and blocker updates separately.

if you think of some other package that 'ought to' go in but isn't a fix
for an nth or blocker bug, don't just list it anyway: propose it as an
nth or blocker bug and get it voted in quickly by poking people on irc.
always good to have the paperwork in order.

trac syntax is horrible. for the record, to do a bullet list in trac,
the format is:

 * bullet 1
 * bullet 2

that's a space and then an asterisk. The space has to be there.

For each 'release point' - Alpha, Beta, Final - there's *one* TC request
ticket and *one* RC request ticket. rel-eng will close the ticket after
TC1 or RC1 is done; if a TC2 / RC2 is to be requested, re-open the
ticket to request it, it'll get closed again when that one's done, then
you can re-open it for TC3/RC3, and so on.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net