LTS and release methodology

[Bryce Harrington]

On Mon, Jul 07, 2008 at 11:14:59PM +0100, Alexander Jones wrote:
> 2008/7/7 Bryce Harrington <bryce at canonical.com>:
> > 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 think you've arrived at a point Shuttleworth has been making for some
time now.  ;-)
 
> 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.

It seems like with FOSS, the only stable code is obsolete, unmaintained
code.  ;-)

More seriously, it seems that the decisions relating to new techs are
made fairly early on, like around alpha-1/2/3.  That is the optimum time
to make go/no-go decisions on new techs because it costs little to rip
them out.  After about alpha-4/5, we've become fairly invested and
change is possible but hard.  By -beta it's almost too late, as
disabling the new feature could impose as many problems as it'd solve.

Ideally, testing effort levels should parallel this, with heaviest
testing occurring during those early phases, and be targeted exactly to
the newest introduced functionality, so we can make well-informed
go/no-good decisions.  Unfortunately, merging and testing have an
inverse relationship - most testing gets done after -beta, precisely
when major changes are the hardest to make, and we end up looking for
low-risk workarounds and ways to paper over issues.

Bryce