On Wed, Jan 31, 2018 at 7:59 PM, Simon Quigley <tsimo...@ubuntu.com> wrote: > 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?
My ideal would be that flavors determine what is highly coupled with their packages separately from what Gnome does. For example, hypothetically maybe Lubuntu is less coupled to Mesa and then Gnome. Lubuntu could choose to release their packages in the same month as Mesa instead of waiting for when Gnome does it's updates. > 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? I did cover LTS releases in my aside (in link), but basically I wouldn't want the freezes to impact Ubuntu Monthly. Instead the LTS would branch off of Ubuntu Monthly. >> 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? I'm open to this, I wasn't sure of the technical feasibility - especially for an experiment. > 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. That is an interesting idea. >> 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. ;) We can do a new image of every flavor every month. Sometimes there will be more GNOME changes, other times more KDE,etc. > On that point too, what if something big happens (take Meltdown and > Spectre for example) and releases get delayed? Security updates will take priority - but I don't see them generally delaying things too much. > Additionally, what about bugfix updates (that would normally be fit for > the SRU policy)? We'd want the current SRU policy to still apply (or something similar as we have less of a "dev" release in this) >> 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. Thanks! > 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?) I'd want a user to be able to migrate from the last LTS to Ubuntu Monthly. And set a setting to "get off" Ubuntu Monthly and get on the next LTS. > > Thanks, > -- > Simon Quigley > tsimo...@ubuntu.com > tsimonq2 on freenode and OFTC > 5C7A BEA2 0F86 3045 9CC8 > C8B5 E27F 2CF8 458C 2FA4 > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
