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 -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
