On Mon, Jul 07, 2008 at 11:14:59PM +0100, Alexander Jones wrote: > 2008/7/7 Bryce Harrington <[EMAIL PROTECTED]>: > > 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 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
