release cadence for Q and R

Scott Kitterman ubuntu at
Wed Jun 15 23:27:34 UTC 2011

Micah Gersten <micahg at> wrote:

>On 06/15/2011 05:58 PM, Steve Beattie wrote:
>> On Wed, Jun 15, 2011 at 02:48:58PM -0700, Allison Randal wrote:
>>> Very valuable perspective, thanks. To other upstreams, do you have
>>> similar or opposite needs?
>> Perhaps this is just me being naive, but with upstreams, shouldn't we
>> be emphasizing the Feature Freeze date rather than the actual Release
>> date? That's the merge window deadline they should be targeting, and
>> where the Ubuntu cadence should be most relevant. This is at least
>> the upstream I do release management for targets the Ubuntu releases.
>> Going back through the previous calendars, it seems that we've had
>> Feature Freeze be 9 weeks before release on non-LTS releases and 10
>> weeks prior on LTS releases (until you go back to Feisty where it
>> starts to deviate).
>> I also note that looking at the current draft Q schedule and R
>> schedules, Feature Freeze is tentatively marked in at 11 weeks and
>> 10 weeks prior to the respective releases. So even if the Q and R
>> release cycles were moved to straight 26 week cycles, unless the
>> Feature Freeze dates are also aligned, upstreams won't really have
>> a 26 week cadence to target for development.
>Indeed, but something to remember is that certain upstreams (KDE and
>GNOME amongst others), have a microrelease exception which allows the
>point releases to be included.  These were granted since no new
>are included in point releases.  I believe this is the point Scott K
>raising in that we get an extra round of bug fixes if we do a 26/26
>split on the fall release.

Yes. Exactly.

Scott K

More information about the ubuntu-devel mailing list