Release management thoughts for Dapper Drake

[HC Brugmans]

Jeff Waugh wrote:
> Hi all,
> 
> I've put a couple of release management ideas to a few people on the team,
> and had a positive response, so now that breezy's "done", I figured it's
> high time I hit the mailing list with them. :-)
> 
>  1. Maintain breezy's UpstreamVersionFreeze for main, with exceptions
> 
>     I suggest we maintain breezy's UpstreamVersionFreeze for dapper main, to
>     combine testing exposure and work towards better stability for our long
>     term supported release. In practice, this means halting our autosync
>     with Debian sid, and only accepting uploads and syncs for approved fixes
>     and feature goals - except for universe, which we should continue to
>     sync, otherwise the MOTUs and our archive/buildd admins will drive each
>     other crazy.
>     
>     What's not covered by exceptions are boring things we expect to be rock
>     solid, such as core system components and server software (apache,
>     dovecot, postfix, squid, etc). Some of the more obvious feature goal
>     exceptions I imagine we'll accept at UbuntuBelowZero include:
> 
>     * GNOME 2.14, KDE
>     * Firefox 1.5
>     * Xorg 7
>     * OpenOffice.org 2
>     * Linux 2.6.new (probably 2.6.14)
> 
> 
>  2. Ship both Linux 2.6.12 and 2.6.new
> 
>     I suggest we ship two kernels with dapper: A well tested and stabilised
>     2.6.12 for servers and a nicely up-to-date 2.6.new (probably 2.6.14) for
>     desktops. This does mean extra work, but while we're tracking the fresh
>     branch, we can fold fixes back into the 2.6.12 branch. Potential gotchas
>     include: incompatible inotify and udev changes (kernel/userland combos
>     elsewhere, too), desireable new stuff for servers such as the upcoming
>     SCSI changes not being backportable to our stable branch (thanks to
>     James Troup and Daniel Silverstone for pointing these out).
> 
> 
> Both suggestions will increase the testing exposure of the stable components
> as they'll see active use in both breezy *and* dapper. I think it would suck
> to ship a long-term supported release with only the testing it will receive
> during its six-month development cycle - that's not going to be enough.
> 
> Thanks,
> 
> - Jeff
> 

Jeff, guys,

While I am not a developer, I'd like to make a piont here.
Ubuntu built it's reputation on the combination of "latest and greatest"
  and polish.

It will seem very odd to ubuntu users that they suddenly do not have the
newest app in ubuntu, but debian does have the new stuff. This will
create a problem on two pionts:

1. Those that have given Ubuntu a high profile by massively 		switching
too it because of the "latest, greatest, coolest new kid in town" factor
 will start rumbling, or move away. In any case, they'll not be happy.

2, Those that are looking for evidence that Ubuntu is out to first kill,
then be debian (don't ask). There was already an uproar about binary
stability as the holy grail, ubuntu not joining the DCC, etc, jaddajadda.
We basicly said "we don't do debian stable, so joining DCC would allow
us to fundamentally change" And "while we don't garuantee binary
compatibility with debian, we sync from it every six months."

This move might cause a lot of flak on both pionts, and while "we" are
better educated, and I think being more cautious in getting syncs from
debian is basically a good thing, we have to consider the effect this
will have on the media coverage that made ubuntu massively popular.

Whatever is decided, this will have to be communicated in a way so as to
adress the above pionts, keep on the good side of the geeks, not to give
ubuntu-haters ammo, and be presented to the press as a "good thing(tm)",
while watching out for raising the DCC issue again.


--Hidde