Thanks to Mark for brining this forward. I think this proposal does an excellent job of capturing the gestalt of the conversations about our release cadence and support models. It also seems reasonably iterative and implementable.
Point #2 sounds *very* similar to what came out of discussions in UDS. Such a support scheme was favoured by many members of the community I talked to last week during UDS, including the Xubuntu community members I talked to in their session. In fact, one of them was to be taking the lead to describe a similar proposal to yours here: https://wiki.ubuntu.com/ReleaseCadence/SixMonthInterimRelease though clearly he has not gotten far in making the actual definition. Would it make sense to begin refining the proposal there? I chatted with him last night on irc after you posted yor proposal. He has some refinements that he would make to your proposal, but in general was satisfied, because, as I said, this was the sort of solution that the Xubuntu community strongly supported. In terms of making the development release the "rolling release" (Point #3), I think the point is actually pretty elegant. For the notion that you can use the very bleeding edge or be slightly buffered from it, we do have a tool in our toolbox that we can/should deploy for this, Phased Updates: https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-phased-updates . xnox (Dmitrijs Ledkovs on the foundations team) proposed that we turn this on for the development release for non developers. In this way, whoopsie-daisey would provide an automated buffer zone for people who wanted to ride tip but wanted a degree of protection as well. If developers were experiencing bugs from a package, daisey would know and would stop the update from going to the next set of users. Cheers, Rick On Mon, Mar 11, 2013 at 6:33 PM, Mark Shuttleworth <m...@ubuntu.com> wrote: > TB, > > 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: > > Updated Ubuntu Release Management proposal > > In order to go even faster as the leading free software platform, meet the > needs of both our external users and internal communities (Unity, Canonical, > Kubuntu, Xubuntu and many many others) and prepare for a wider role in > personal computing, Ubuntu is considering: > > 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. > 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. > 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. > > 2. Reducing the amount of release management, and duration of support, for > interim releases. > 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. > > 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. > > 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. > > Thank you! > Mark -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
