Release management thoughts for Dapper Drake

[Matthias Klose]

Jeff Waugh wrote:
>  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)

> 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.

While I second the goal, I'm unsure if that's the best thing we can do.

- Many components in breezy were not updated/synced during the breezy
release, so we start the Dapper release with packages which are over a
year old. That surely adds a higher maintainance burden on the team for
the time we support Dapper, if upstreams move on to newer versions and
don't support older versions anymore (just pointing out freetype and
xine-lib).

- You don't see the same components tested in breezy and dapper. Just
rebuild a package, which was last updated in June, and we have another
package which may show up other behaviour.

- New versions of the "desktop" packages will require new base libraries
as well, so we will touch more stuff than you want.

So I can completely agree, if the list of exceptions includes their
direct and indirect (build-)dependencies. ;-P  We'll find more
exceptions when we start defining more release goals, or wanting to
provide printing support for newer printers.

I agree, that an uncontrolled sync/version update is not desirable for
dapper, so let's make some rules for new versions for dapper.

- syncs for new debian releaeses, but no new upstream version, should be
allowed. rationale: fixing smaller bugs, getting packages in sync with
unstable to lower the number of packages which need to explicitely
maintained for ubuntu.

- allow new subminor/minor versions. that depends on how upstream
interprets these version numbers, what is done in these releases. maybe
needs a look at the changes made. upstreams which only do bug fixing in
these releases, could be handled that way, upstream's which do add stuff
in these (like samba) are another thing (but maybe in the case of samba
you want these changes).

- allow new versions from an exception list.

To have more time for testing, we can try to accelerate the
syncs/updates doing them with many people in parallel. As a plus we
don't have major soname and packaging changes, which require changes in
many other packages as well. This way we can stabilize earlier for testing.

  Matthias