Hi, On Tue, Mar 12, 2013 at 01:33:05AM +0000, Mark Shuttleworth wrote: > Am writing to ask you to weigh in on an updated release management > proposal. Details are on Planet Ubuntu, salient portion of the proposal is:
Thanks for this proposal! > *1. Strengthening the LTS point releases.* > Our end-user community will be better served by higher-quality LTS > releases that get additional, contained update during the first two > years of their existence (i.e. as long as they are the latest LTS). > Updates to the LTS in each point release might include: > > * addition of newer kernels as options (not invalidating prior > kernels). The original LTS kernel would be supported for the full > duration of the LTS, interim kernels would be supported until the > subsequent LTS, and the next LTS kernel would be supported on the > prior LTS for teh length of that LTS too. The kernel team should > provide a more detailed updated straw man proposal to the TB along > these lines. IIUC, this is already in place. > * optional newer versions of major, fast-moving and important platform > components. For example, during the life of 12.04 LTS we are > providing as optional updates newer versions of OpenStack, so it is > always possible to deploy 12.04 LTS with the latest OpenStack in a > supported configuration, and upgrade to newer versions of OpenStack > in existing clouds without upgrading from 12.04 LTS itself. I would tend to agree with other people here: PPAs seem like the way forward for these "alternate" stacks of software. > * required upgrades to newer versions of platform components, as long > as those do not break key APIs. For example, we know that the 13.04 > Unity is much faster than the 12.04 Unity, and it might be possible > and valuable to backport it as an update. This is new; it would be a modified SRU that explicitly included features. > *2. Reducing the amount of release management, and duration of support, > for interim releases*. So, I would like to find another name for the releases between LTSes. I do not like the term "interim" as I feel it detracts from the importance of the 6-month release cadence. I think these releases are critical in stabilizing Ubuntu. I think the LTS is the "special case" release. It has been treated as "even more stable" that regular releases, and I think I'd prefer just using that term instead. "Regular Release" and "Long Term Support Release". If we allow ourselves to use the term "interim", I think we'll make the mistake of thinking these releases are less important. > Very few end users depend on 18 months support for interim releases. The > proposal is to reduce the support for interim releases to 7 months, > thereby providing constant support for those who stay on the latest > interim release, or any supported LTS releases. Our working assumption > is that the latest interim release is used by folks who will be > involved, even if tangentially, in the making of Ubuntu, and LTS > releases will be used by those who purely consume it. I have no problem with the idea of reducing the length of support available for regular releases. (I would also pick 8 months, but wouldn't be opposed to 7.) This frees up a lot of resources, and encourages people to upgrade. I've always been a big believer of staying on the current release of Ubuntu. The LTSes are mostly for people that can't withstand such frequent changes, but more nimble organizations and individuals have no problem with a 6-month release cycle. For people that want bleeding edge, we've still got the in-development release (obviously more on this later). Among other things, one of the primary distinguishing characteristics of Ubuntu is the 6-month release cycle. I would be extremely disappointed to see that disappear. Adjusting the support time-frame seems like the right way to shift support resources towards the LTS. (Frankly, I thought we shouldn't have kept the 18 month support on regular releases when we moved to having LTS releases.) The point of having a 6-month release cycle is to USE the 6-month release cycle, which means upgrading every 6 months. :) If you're not doing that, stay on the LTS. > *3. Designating the tip of development as a Rolling Release.* > Building on current Daily Quality practices, to make the tip of the > development release generally useful as a ‘daily driver’ for developers > who want to track Ubuntu progress without taking significant risk with > their primary laptop. We would ask the TB to evaluate whether it’s worth > changing our archive naming and management conventions so that one > release, say ‘raring’, stays the tip release so that there is no need to > ‘upgrade’ when releases are actually published. We would encourage PPA > developers to target the edge release, so that we don’t fragment the > ‘extras’ collection across interim releases. I would echo the other concerns about naming here -- this isn't a "release". It's an always-moving collection. It's a snapshot at the moment someone runs "dist-upgrade", and not a release. "Rolling Snapshot" I think would be more in line with what it is. I totally agree with the goal of making it stable, though. And here is as good a place as any to voice my concern over this concept. While I love the idea of a Rolling Snapshot, I am worried its difficulty is being underestimated. From time to time in the past, there have been murmurs about moving to a rolling snapshot. I feel these have coincided with Debian being frozen, and the Ubuntu archive giving the impression that the incoming package changes were slow and easy to deal with. As soon as Debian unfroze, these murmurs went away. We cannot control what will come flooding into the Ubuntu archive from Debian, which is why stabilization (via regular releases) is so critical to the success of Ubuntu. Improving the quality of the Ubuntu archive via automated testing is a great way to get out ahead of this, and those things are already in progress. However, I don't think they're nearly to the level of detecting regressions in DHCP lease delays, UI rendering glitches, streaming codec performance, etc. There are so many subtle and complex things that are hard to realistically automate tests for. Now, this should not stop us from attempting those tests. Every test added is another thing that we can throw a flag for if it goes wrong, but I think we're not there yet. I think opening the flood gates from Debian unstable will cause pain. However, that pain is still less than not opening those flood gates. Having those changes pour in is what we need to keep the regular releases coming. I think our cadence with Debian has been very successful. I think when there are end-to-end usability, performance, and regression tests in place, and there are people responding to those alerts, then we'll be in a much better place to have an automated Rolling Snapshot. I want this. It will be fantastic. I think it's a much longer road. > As a (possibly) separate matter, in the blog I mention that decoupling > platform and apps might help us go faster, and encourage app developers > to make the tough choices about which versions of their apps are > supported on which releases of the platform. I've left this bit out of > the core proposal but would think our community would be interested in > your collective take on that. What seems to create an App ecosystem is a stable API. If that can be provided, I think decoupling is almost automatic. (And if those Apps are closed-source, then you need a stable ABI, which is even harder than a stable API.) Regardless, I would agree: this is a separate matter. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
