Bodhi policy for pushing updates to stable

[Adam Williamson]

On Sat, 2015-01-24 at 17:42 +0100, Kevin Kofler wrote:
> Kamil Paral wrote:
> > So, enforcing upgrade path for stable releases sounds good. But 
> > when we add development releases into the mix, we need to break 
> > upgrade path in certain cases. And we probably need to come up 
> > with a different solution to ensure you can correctly upgrade to 
> > it on the release day (maybe by using yum distro-sync-like 
> > approach instead of yum-update-like approach?).
> > We will need to deal with these problems as our automation 
> > coverage increases.
> 
> IMHO, we should
> 1. abolish the Alpha and Beta freezes (just take ALL new builds 
> until the
>    criteria are met),

This is worth considering, at least, as the milestone freezes have 
(obviously, the clue's in the name) been around since *before* No 
Frozen Rawhide. In a sense, they and NFR aim to address the address 
the same problem: the tension between doing development work, and 
stabilizing a release. So I think it's at least worth considering.

My instinct is still to oppose it, though, because we *do* still have 
potentially destabilizing changes landing in Branched during freezes. 
We quite often get an entire new GNOME build during freeze; sometimes 
we consider these and freeze-override them in, but we probably don't 
want one landing on the Wednesday we're trying to polish up an RC for 
approval on Thursday.

Same applies to the kernel, and various other bits like dracut and 
parted which affect the install-and-firstboot critpath parts 
especially.

> 2. open up the 0-day updates immediately on Final freeze,
> 3. in Final freeze periods, distinguish between freeze overrides and 
> normal
>    stable updates in Bodhi, instead of the current "stable = freeze
>    override" setup.

So there was some discussion of this whole issue on test@ around the 
F21 release time and I was a bit curt - retrospective apologies for 
that, release times are always a bit stressful.

Someone proposed that using the 'updates' repository during the 
Branched period could help solve quite a few things here, and I think 
that's an interesting idea.

To recap, at present, we don't use 'updates' for Branched at all until 
the few days between the Final "Go" decision and the actual release 
date, when we populate it with the '0-day' update set. Once we hit the 
'Bodhi enablement point', builds go to updates-testing first, then 
when they're marked as 'stable' (either manually or via autokarma), 
they are pushed directly to 'fedora', not to 'updates'.

Someone - I forget who, I'm sorry - suggested that we could push 
updates marked as 'stable' during milestone freezes into 'updates'. 
For Alpha and Beta, we'd then flush them from 'updates' back into 
'fedora' immediately following the milestone release; for Final they'd 
just stay there and become 0-days.

With a bit of time to think about it, I think this is actually 
potentially a very good idea. It gives us two solid improvements:

1. We can keep pushing out new builds to a place where users will 
actually get them, without destabilizing the image composes
2. It would address the problem kparal identifies - when sending an 
update to a stable release would break the upgradepath because 
Branched is frozen, but we do really want the upgrade out for stable 
users

One issue I can see with it is, what do we do with the buildroot? If 
we have 'updates' in the buildroot then builds getting pushed to 
updates could *indirectly* affect the image composes by causing issues 
in package builds to fix blocker/FE bugs. So I'd probably prefer to 
see only 'fedora' used as the buildroot for Branched.

With a change along those lines, I think we could plausibly look at 
hard enforcement of the upgrade path, and it would be a good 
improvement. It may be necessary to have *some* kind of override 
mechanism for the case where we have a major security issue we really 
need to fix in stable ASAP, and karma for Branched is lagging behind.


-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net