<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> 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: <h2>Updated Ubuntu Release Management proposal</h2> 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: <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <ul style="color: rgb(51, 51, 51); font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 17.3281px; orphans: 2; text-align: justify; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; background-color: rgb(255, 255, 255);"> <li>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.</li> <li>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.</li> <li>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.</li> </ul> 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 </body> </html>