Release management thoughts for Dapper Drake

[Trent Lloyd]

On Sat, Oct 15, 2005 at 04:46:23AM +0100, Scott James Remnant wrote:
> On Sat, 2005-10-15 at 03:56 +0100, Jeff Waugh wrote:
> 
> > <quote who="Scott James Remnant">
> > 
> > > >     * GNOME 2.14, KDE
> > > >     * Firefox 1.5
> > > >     * Xorg 7
> > > >     * OpenOffice.org 2
> > > >     * Linux 2.6.new (probably 2.6.14)
> > >
> > > Which pretty much defines dapper main ... so exactly what do you want to
> > > freeze again?!
> > 
> > Whoa dude, main is much bigger than that.
> > 
> True, but the majority of the "rest of main" is actually the small tools
> that don't really change much.  In the past the majority of our
> release-to-release breakage has come directly from the items you've
> listed in the table above.
> 
> Nobody notices too much if the version of things like "vsftpd",
> "ttf-alee" and "sysfsutils" change a bit -- these don't change much
> anyway; and almost never introduce new breakage.
> 
> We get the new breakage by introducing things like major new releases of
> GNOME, KDE, Firefox, X.org, etc. which we push to new versions all the
> time.
> 
> If we want to introduce a stablisation phase, these should be the
> targets as they're the massive pieces of software that change
> fundamentally -- and we shouldn't target the little bits of software
> that will just be giving us minor bug fixes.
> 
> > > I think if we do want to do this "stable upstreams" release, the first
> > > things we should ditch are the above set and instead release with a
> > > known-good GNOME 2.12, Xorg 6.8, etc.
> > 
> > Nup, there are good, worthwhile reasons to continue with feature goals such
> > as these (remember, we're doing desktop support for 3 years, not 5 years).
> > 
> 3 years is still twice as long as our current support; are you saying
> you'd rather support the currently unknown major new versions of the
> star products for three years -- than the "known ok" versions we have
> now, after 6 months of bug fixing and selective backporting?
> 
> For the server, we've never had feature goals of getting in major new
> versions of the bits of software because they don't really introduce
> them that much.  There's a few we could choose from:
> 
>   * Exim into main
>   * PostgreSQL 8
>   * Zope, Python and Twisted
>   * there must be new PHP
> 
> Straight off the top of my head, but those are small in number compared
> to everything else.  We really just don't get that many new major
> releases through upstream.
> 
> > > And I still think it's a bad idea; we've built up our reputation and
> > > user-base on the idea of having 6-monthly releases of the latest software
> > > -- and to suddenly not do that for a release seems like a mistake to me.
> > 
> > Much of the software with immediate end-user benefit will be covered by
> > feature goals. The core system, and in particular server stuff, would not.
> > 
> But the "core system" doesn't change much, so exactly what would be the
> point again?  We'd be turning it off and ignoring a small pile of
> potentially useful bug fixes; nothing more.

It would seem to me that a better thing to do would be to simply "be
more caucious" e.g. don't just mass sync, go through and check things
otu ourselves (in main, obv) and "get things in early" and (as much as I
think this was great for breezy, and I'm not saying this was a bad idea
now or bagging anyone, but) not "put new kde releases in 2 days before release"
So we don't end up with things like the konsole bug or something worse

Trent

> 
> Scott
> -- 
> Scott James Remnant
> scott at ubuntu.com



> -- 
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


-- 
Trent Lloyd <lathiat at bur.st>
Bur.st Networking Inc.