Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases

[Adam Williamson]

Hey, folks.

So, it occurred to me while testing the multiple preupgrade bugs we've
hit this cycle that - as I understand the process - there's actually no
reason we need to hold Alpha and Beta composes for preupgrade bugs.

This is how preupgrade works: it pulls
https://mirrors.fedoraproject.org/releases.txt , and that's the list of
releases it shows you at the first step. It uses the locations defined
in that file to retrieve everything - both the packages it downloads and
feeds to anaconda, and the actual anaconda that it uses.

releases.txt points out to our mirrors.fedoraproject.org mirror lists,
and I'm reliably informed (by nirik) that, for pre-releases, the mirror
list points to the development tree - that is,
http://fedora.mirror.iweb.ca/development/17/x86_64/os/ , for example. It
does not point to the frozen tree of the last 'official' pre-release (of
which there is also one on the mirrors - it's at
http://fedora.mirror.iweb.ca/releases/test/17-Alpha/ ).

Since preupgrade for development releases uses the development tree,
this means there's actually no relationship between preupgrade and the
Alpha / Beta releases. If you run preupgrade from F16 to F17 right now,
it doesn't use the anaconda from Alpha. It doesn't necessarily use
whatever anaconda is in the latest Beta RC. What it uses is whatever
anaconda was last pushed 'stable' via bodhi.

Since we can push a new anaconda stable whenever we want, there's no
reason I can see to hold Alpha or Beta composes for preupgrade issues.
Putting the anaconda that 'fixes' a preupgrade problem into an Alpha or
Beta release doesn't really achieve anything in and of itself. All we
have to do is make sure the working anaconda is pushed 'stable' via
Bodhi as quickly as possible, whenever the Alpha or Beta release point
is.

The situation for final releases is a bit different. For final releases,
mirrorlist points to the 'frozen' release tree - for e.g.
http://fedora.mirror.iweb.ca/releases/16/Fedora/x86_64/os/ . This tree
is frozen in time at the state when the release went final. If we push
an anaconda update stable for a final release, preupgrade to that final
release does *not* use the new anaconda. So if right now we push an
update to Fedora 16's anaconda stable, you won't get that anaconda when
preupgrading from F15 to F16; you get the one from F16 release time. So
for final release, we *do* need to make sure the anaconda in the frozen
release package set is working for preupgrade.

So, I'm proposing one of two options:

1) Simply bump preupgrade to the Final release criteria

2) Keep preupgrade in the Beta criteria, but treat all preupgrade issues
- even those that are in the anaconda package - the way we currently
treat blocker issues in livecd-tools or the preupgrade package itself:
consider them as not blocking image compose. Rather, we require the
maintainer to push out an update before the release date. We could put
issues in anaconda that only affect preupgrade into the same category.

We had a preliminary discussion about this at today's meeting, and
agreed I'd make a formal proposal to the list - this is that proposal.
Any concerns, questions, improvement suggestions or corrections are
greatly welcomed! Please chip in your thoughts, and votes for 1), 2) or
neither of the above. Thanks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net