release cadence for Q and R

[Micah Gersten]

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 how
> 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 features
are included in point releases.  I believe this is the point Scott K was
raising in that we get an extra round of bug fixes if we do a 26/26
split on the fall release.

Micah