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

[Horst H. von Brand]

Kalev Lember <kalevlember at gmail.com> wrote:
> On 04/10/2012 09:04 AM, Adam Williamson wrote:
> > On Mon, 2012-04-09 at 22:15 -0500, Bruno Wolff III wrote:
> >> I think we want preupgrade to work for at least beta. I think just not
> >> blocking the composes, but requiring it to work for beta is better than
> >> waiting until final.
> > 
> > That's the intent of option 2). Though to be honest, we're not terribly
> > good at following through on it. When we've had preupgrade /
> > livecd-tools 'blockers' before, we've sometimes not managed to get the
> > fix pushed stable by release date.
> 
> I think it's a great idea to not block media composes for preupgrade
> issues. However, it is still a supported upgrade method and needs
> Beta testing. I would definitely not move preupgrade to only blocking
> final release; why else are we doing Beta releases if not to get testing?

AFAIU, proper testing requires having some stable(ish) package collection
to preupgrade against, and that isn't given right now.

> What I would do is treat preupgrade bugs at Go/No-Go meetings as release
> blockers, but at the same time not require install media respin for
> preupgrade fixes. This should allow more flexibility and faster turnover
> for validation. As long as there is a process to accept Anaconda builds
> to stable during the freeze without doing composes, I believe this
> should work.

In any case, as the preupgrade has to be installed on the _old_ system, it
doesn't help much having it on the (pre-final) installation media. Perhaps
a separate small repo for rolling update of preupgrade while testing?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  +56 32 2797513