Bodhi policy for pushing updates to stable

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 24 Jan 2015 11:05:52 -0800
Adam Williamson <adamwill at fedoraproject.org> wrote:

> 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.

I share the fear that we will never get to the point of the criteria
being met.

> 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.

This actually changes little and gives us more work.  for Alpha and
Beta we push updates daily to updates-testing and it is enabled for
users so they always get all potential bug fixes. At the point we hit
the final Freeze we disable updates-testing on users machines.  at this
point we could look at pushing out updates. and cherry picking in fixes
for the final release. The one place things would change if we pushed
stable updates during freeze is that build would land in the buildroot
a bit earlier.


> 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
We have this today for the most part except for final freeze.

> 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

There is always potential issues with upgrades. 
 
> 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.

This is a really tricky area. we would only use fedora for compose
process but we could have to pull in extra builds because they were
built against something newer. 

> 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.

There should be a good way to have enforcement. It will take extra
thought. knowing where we are in the release process can let us check
against different repos. Final Freeze is the tricky bit and perhaps we
just push stable updates and cherry pick in fixes.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUxBiMAAoJEH7ltONmPFDRXAIP/0JXyb++/es115dDrFuRiPFE
cosFMuotkPPpHRb/ekBl4oXWQHg0jLSSo42HLg+O7G8R3UldekmbJ8M6JEN2T6ob
3GLqT+snKXv9+H6Sq5qFkJ5umuoP+FEAzcxAFYL8RkBYguOTfmgbFM9Rm5BO/n6J
G7R4Un6AGMO16VXokqvJGtMoHHUu2EHkSsxhf4fjDrFV4tB5bxbuHHcBBF0GTUGf
WR113ueK2te3Dk3WTTrhW/wlTHi97Ns7xFplrNSp1aIocTal+gdayANeK19IWj5i
tEEOqY5AMToUcWBoa+l5fYDs9h5i9lkLNIl/egoEMSv8pDEc4fc8A0CwYqQN7ctT
468473iqlMD+NCmKAPgGhu+efZKBlOd6F0sFXmUIa+V0zZdgcC2PsXeoQqnbvkgT
BKj9hF0+nZsRsFAEi4jm6LjG9XVU+Zm10WE4NFTQnYouDc1nLuhPkWkttPs73S2P
eePu+oUjqP3AzGpXTSe0mAXiTwroggsF3ccrlR6WUAXoctA3w99oIEsV8WsZR5zR
+mngAmN+LAvfIK0fbaqsWRvyKlfUUex4e53PpFU8ENV3hdsap2Nszj6NcbKE3Rcz
Ubqtcx+T+W8GFKeFyB18pwdky2nfBxLOW67N2AGdVMeBAQAc3umNWwcePV0MEfPi
BvJ1RukvBrL1mw/+7ZFa
=Pr+y
-----END PGP SIGNATURE-----