LTS and release methodology

Alexander Jones alex at
Mon Jul 7 22:14:59 UTC 2008

2008/7/7 Bryce Harrington <bryce at>:
> 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.  ;-)

It makes me wonder whether synchronised planning for a major cycle
every 2 years would be a good idea to pitch.

I tend to think (perhaps unfoundedly) that we have this problem where,
rarely are more than a few parts of the platform truly stable and
ready to receive ISV investment at any one time. With us regularly
digging up parts of the platform that "aren't quite" cutting it and
replacing them with entirely new components (Bonobo->D-Bus,
HAL->DeviceKit, GNOME-VFS->GVFS, ...), we effect a hidden and
immeasurable cost associated with keeping software in a buildable
state throughout its own lifecycle. I have zero qualification for
making this suggestion, though -- it's just my impression. Feel free
to put me in my place. *humble*


More information about the Ubuntu-devel-discuss mailing list