Release management thoughts for Dapper Drake

[Ivan Krstic]

Scott James Remnant wrote:
> If we continue UVF then we _SHOULD_NOT_ update GNOME, or X.org -- those
> are the major changes that could break things.  You're picking on things
> that have either not changed anyway, or changed in minor ways that we
> probably want to pull anyway.

This is exactly what I've been saying. And if we do keep GNOME, X.org,
Firefox, KDE, and OO.o in their Breezy versions, then we *are*
sacrificing the minty freshness of the software in Ubuntu that we all
know and love. And then we're back to my original points.

I'm not at all sure that having an extended enterprise release cycle is
a good idea. I'm thinking out loud. But if we say we'll certify Dapper
as enterprise-ready [0], e.g. exactly three months after its regular
release, the advantages are:

 - no need for interference with the structure of the release cycle
that's been established

 - everything's the same as usual to our personal users

 - we still make good on our promise that Dapper (not some later
version) will be supported for 3/5 years - but starting from the date we
stamp 'enterprise-ready' on it

 - we get a low-fuss, minimal hassle "mini-release" half-way to
Dapper+1, getting some more media love and slashing in half the
'apparent time to release'

It would be helpful for someone deeply involved with release management
to throw in a comment here: is there concensus that maintaining UVF with
Jeff's proposed exceptions would, in fact, give us that much more time
to focus on stabilizing the release? If so, rock, let's go for it. Maybe
mdz or cjwatson can chime in?



[0] 'enterprise-ready' is stupid terminology, but I can't think of
anything better at the moment. concord-certified? poignantly-prepared?
hasslefree-harmony? ;)

-- 
Ivan Krstic <krstic at hcs.harvard.edu> | 0x147C722D