Release management thoughts for Dapper Drake

[Martin Pitt]

Hi Jeff!

Jeff Waugh [2005-10-14 13:18 +0100]:
>  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.

To understand the strictness of this rule better, let's take a random
server package - let's say "PostgreSQL" (who could accuse me about
being biased :-) ). 

In Breezy, we currently have 7.4.8 and 8.0.3. New microreleases have
recently been released. PostgreSQL's microreleases are exemplary in
terms of "minimal patches" - they only fix security and data loss
bugs. I assume that these are perfectly valid to be included into
Dapper, right? But stopping autosyncs for these packages would be a
bit silly: I only ever do bug fixing to the Debian packages, since
there is not much "bling" you could add to them. I think this is
equally true for other packages like PHP, Apache, and so on. I think
the majority of Debian action in these packages is bug fixing, so I
think monitoring Debian activity and manually asking for syncs would
drain many resources from us which we could rather spend on other
targets.

And then there is PostgreSQL 8.1. It is currently in the beta-3 phase
and will likely be released in a couple of weeks. It has great
improvements in terms of performance, and many folks cry for it (that
includes the launchpad team!). How would you handle this case? (I'm
not suggesting that including/not including it would be right, I just
wonder how you would decide with your proposed strategy).

Frankly, I do not believe that the majority of breakage that users see
was introduced by Debian bug fixes and server/base package syncs; it's
the desktop, user profile migration, and hardware support that cause
the major breakage, so we should concentrate on fixing those instead
of spending a lot of work in reviewing Debian revisions (we should
automatically sync those and only take a look in the changelog if
there is a new upstream version).

From my experience, a lot of effort that was spent for Breezy went in
(1) the gcc transition, which should not be an issue for Dapper, and
(2) implementing a really high number of specifications. So I feel
that if we want to get something more stable than Breezy in Dapper, we
should completely avoid implementing specs and rather concentrate our
full development capacity on bug fixing. If we also narrow down the
window for autosyncs and new upstream versions, we have much more time
for bug fixing than we had for Breezy.

Just my 0.02 €,

Martin
-- 
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20051017/4c1fcb1c/attachment.pgp