As Sean Michael Kerner puts it on his blog, Mark Shuttleworth's "The Art of Release".. erm... "vision"/wish/dream/strategy is nether a good nor a realistic thing. Shuttleworth's "vision" just won't work. You can't force 10-20 big upstream projects (KDE, GNOME, kernel, OpenOffice.org, Firefox, GCC, etc...) to sync their release schedule. And you wouldn't want to do that either. One of the reasons why FOSS is usually better in terms of quality is that releases, focus and features are typically driven by quality, by developers, not by marketing and competitors. Things are released when they're ready, when the maintainer thinks it's good enough. Having a synched release plan for many large and complex projects means a huge burden on upstream. I can't imagine Mark Shuttleworth could be that clueless about the reality of software development and how the whole ecosystem around a distribution actually works. He isn't. Can't be. So what agenda is he having/endorsing when he pushes that idea so loudly (arguably, even when he whispers, it does make a lot of noise
;)) ? I don't know. Except, maybe, because Canonical doesn't have much developers working directly on upstream projects that aren't 100% Ubuntu specific (at least compared to Fedora and openSUSE) and hence they're not really in a position to push for certain things to be fixed before others. Well, just thinking out loud, maybe there's no hidden motivation behind it at all. Sean wrote that he rather wished "common packaging across distributions", but:
- PackageKit is definitely a good initiative and project, but it doesn't solve anything with regards to that as it's "merely" a frontend to different package management stacks, so it can give users of several distros the same frontends and user experience, but not access to the same packages;
- it isn't about the package format (RPM vs deb vs whatnot), RPM and dpkg are pretty much equal in terms of features, performance, stability anyway; even if everyone was using RPM, it wouldn't help because the real problem is what dependencies packages are built against, especially their respective versions
;)Whatever your distribution of choice is, and regardless about how religious you are about it, I think we all agree that would be a terrible thing, whatever that distribution would be (including openSUSE). In order to accomplish that partially (which should be feasible in theory, certain dependencies are very stable and have a strong record on backward/forward compatibility, e.g. KDE 3), we'd first need to have everyone or at least the "big players" work together on LSB and actually implement it (Debian/Ubuntu don't, or only partly, even without considering RPM), and have LSB evolve at a much faster pace to encompass more standards. If package naming differences and init scripts incompatibilities were addressed and implemented by many distributors, it could be done for a certain amount of packages. Having major upstream projects follow strong guidelines on SONAMEs and ABI compatibility would be a lot more interesting than synching release cycles. But, again, it has a high cost on upstream development, is very complex to accomplish, and clearly takes a lot of fun, drive and "innovation" out of FOSS development. Not sure we'd want that either. I certainly don't. I'd already be really happy if all upstream projects written in C or C++ would know how to properly handle SONAME, bumping the major version number when ABI incompatibilities arise, in order to package and install several major versions of libraries side-by-side (a train openSUSE arguably catched quite late but works for most library packages nowadays). As said, it isn't trivial though, assessing and verifying ABI compatibility through regression tests isn't always that easy -- at least not as easy as with Clirr and/or JDiff when using Java.