Release management thoughts for Dapper Drake

[HC Brugmans]

HC Brugmans wrote:
> 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
update: *force*
> 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
>