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 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* Alex -- 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
