Ubuntu Monthly Update Cadence Proposal

[Simon Quigley]

Hello Bryan,

On 01/31/2018 06:07 PM, Bryan Quigley wrote:
> Hi,
> 
> Instead of releasing a version of Ubuntu every 6 months, we release
> select core components of Ubuntu every month.  Updates to core
> components would need to be staggered so that no closely coupled
> components would see a major release within the same month.
> 
> We'd provide a newsletter every month before the core components land
> and provide possible plans for the next 2 months.

From a flavor perspective, how would this work? Would they get a release
that often as well? What would happen to flavors who don't get things
tested in time?

Also, what about freezes that normally happen during a release cycle?
Would they only occur leading up to an LTS release, and if so, does that
change from the traditional six month cycle?

> There would be at least one additional place (PPA) to test every core
> component update before it gets to -proposed.

Instead of using PPAs, if this is going to be widely deployed, why not
create an additional pocket in the archive that would serve as a buffer
for this?

And if such a situation were to be deployed, adding to the point of
flavors above, two month release cycles can go by super fast. I propose
something like this (from the perspective of a new package update)
should it be implemented:

New package uploads go to devel-proposed. Should they pass automated
testing (like we normally have in place to advance a package from
devel-proposed to devel-release (which is invisible, so devel)), they
would advance to the devel-unstable pocket. This is a direct landing
pocket that does not have any sort of freeze on it. It's a good testing
ground for people who want the very latest things. From there, Ubuntu
Developers (who have upload access to the packages) could cherry-pick
updates into devel-stable-proposed where they would have to pass the
automated testing and pass a round of manual testing (like the SRU
process but minus the need for the updates to be "high priority").
Should they pass this, they get ushered into devel-stable, and ISOs
would be built off of this. If they fail testing or exist for more than,
let's say, 21 days (three weeks) with no result, they automatically get
removed.

(or instead of pockets like -stable*, we could get new codenames every
month; I think that would be great ;) )

Of course, if you're thinking this looks familiar, I agree; it reminds
me a lot of what Debian (and I think openSUSE?) does (and it also has
similarities to what Solus does I believe, but on a more frequent
(weekly) basis).

(If we wanted to be like Solus, once an image is released, devel-stable
could be "synced" to a devel pocket and we could do critical updates
there, then just "sync" every time a release is done.)

> My hypothesis is that this will help create stability and make the
> monthly releases predictable enough that we will get more users than
> we currently have on our non-LTS releases.

I agree on the points that it could help create stability, given that
testing of very specific components could be done, and it could attract
more users as well. Where I think it gets a bit fuzzy is where we have
things like flavors and other images we release; I'm curious to see if
you have a solution for that.

Also, I think this is a bit of a misc thing, but if all of the flavors
get a monthly release (as part of this schedule) based off of the GNOME
release schedule, I know for a fact that sometimes things like like the
KDE release cycle conflict with that, making it really bad timing. So I
disagree with the point of having a specific monthly that is designed
for the GNOME releases, but rather, if there is a way to update systemd
then the parts of GNOME that depend on systemd, do that instead.
And if you're really set on doing a monthly for a new release of GNOME,
then where's one for KDE? Or LXQt? Or whenever a flavor wants do to an
image? Just saying. ;)

On that point too, what if something big happens (take Meltdown and
Spectre for example) and releases get delayed?

Additionally, what about bugfix updates (that would normally be fit for
the SRU policy)?

> It would be possible to try this process for 18.10.  If it shows
> itself to be an improvement, we can keep doing it indefinitely.  If
> not, we can call it a failed experiment and release 18.10.

Sure; should my pocket proposal be adopted, I think we can go without it
should we choose to give it a try for the 18.10 cycle, and if adopted,
go for a similar model.

> I wrote a good bit more about this proposal, including a possible list
> of some core components and how the schedule would have worked for the
> past year - https://bryanquigley.com/pages/papers/ubuntu-monthly-update-cadence.html

Awesome; I think there's a lot of questions that need to be answered and
a lot of rough edges to work out, but generally I think it's a good
idea, and if things were worked out, I would +1 this.


One more thing to consider would be an upgrade path from LTS -> this
model. Testing would have to be done (possibly as part of the manual
testing procedure I proposed above to get things into -stable) to ensure
this doesn't break (unless we don't care? Thoughts on this?)

Thanks,
-- 
Simon Quigley
tsimonq2 at ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20180131/23589338/attachment.sig>