LTS and release methodology

Bryce Harrington bryce at canonical.com
Mon Jul 7 21:46:52 UTC 2008


On Mon, Jul 07, 2008 at 06:04:14PM +0100, Matt Zimmerman wrote:
> > Stability in software
> > Why is it that 8.04 “LTS” has such a wave of new features and new
> > versions of software that have not been time-tested to be stable? LTS
> > releases (meant to be exceptionally stable) should not have so many
> > additions to its feature set.
> 
> We didn't choose Firefox 3 because we wanted the latest features---quite the
> opposite!  While Firefox 2 may have been more mature at the time of release,
> it's also nearing two years of age and is scheduled for mothballing in
> December, just eight months after Ubuntu 8.04.
> 
> With Ubuntu Desktop LTS scheduled for three years of maintenance, Firefox 3
> was the only reasonable choice, paradoxical though it may seem.  If you've
> read the source code for Firefox security patches, you'll understand why!
> 
> While the initial version we included may have had some rough edges, we're
> in better shape for the long term by staying aligned with Mozilla.

I suspect this situation holds true throughout nearly all open source
projects.  I run into the same dilemma myself a lot in X.org.
Frequently upstream decides $TECH is too horribly broken, so they create
$TECH+1 which is often a from-scratch rewrite, which often means trading
one set of bugs for another.  Unfortunately, upstream then takes the
step of dropping all ongoing support for $TECH (sometimes even making
the $TECH+1 incompatible with $TECH; or support for new hardware is
added only to $TECH+1 not $TECH; or bug reports we upstream get closed
as "plz reproduce with $TECH+1"), leaving us in a "damned if we do,
damned if we don't" situation.  At least, when we "do", upstream will
share the damnation load with us.  ;-)

Bryce




More information about the Ubuntu-devel-discuss mailing list