On Tue, Sep 18, 2007 at 11:02:24PM +0200, Colin Charles wrote:
> Now, lets go to the mainstream/sensible Linux distribution list (70% of
> machines, according to robbat2, and from my experience with distributions
> and our bug count stats, they actually match up):
> * Debian
> * Ubuntu
> * Fedora/RHEL
> * SuSE
Ubuntu ships the Debian MySQL bundle, so that makes 3 distinct
mainstream paths only.
> Even *before* MySQL decided to release a source tarball every 3 months
> once, these distros never shipped every incremental release of MySQL. They
> did so when there was a security risk. Or when it seemed appropriate for an
If you're putting out the ES rapid updates every month, then let us pick
from those. I think you're doing the distros a world of injustice by
stating that distros don't ship every incremental release. That depends
entirely on the time available for the maintainer, and the quality of
each incremental release after some degree of testing. I know I've held
back incremental releases of some packages from the Gentoo tree, because
they had large issues that the relevant upstream guys didn't catch - but
as long as I have time available, I do get out every incremental release
to the Gentoo tree (however do note that the stable keywords of the
Gentoo tree move along more slower, and don't follow all the incremental
A quick examination shows the Debian guys shipped nearly every 5.0
release since 5.0.10beta was released. The first one they missed that
was definitely available was 5.0.25 (5.0.14 and 5.0.23 were never
released by MySQL AB), and another two releases while jumping around
ES->CS->ES->CS, but only by a matter of days.
(Congrats guys at Debian, your track record of keeping up with
incrementals for 5.0 is even better than mine at Gentoo)
> An update for an updates sake is a maintainers worst nightmare. I know,
> I've maintained software in a mainstream distribution before. Everytime you
> drop an update, you increase the bug/pain count
Simple bug count doesn't really reflect matters very well. Bug turnover
as a function of versions does. Eg, new release comes out, test it out,
do the usual sweep for packaging-specific changes/bugs, send it out,
close bugs, watch for new bugs, repeat from packaging-specific bugs, or
pass bugs to upstream as needed. The packaging specific bugs outnumber
upstream bugs, but a significant majority of them are enhancements, not
Decision tree for packaging an incremental release:
1. Is there a new upstream release available?
if yes, continue.
2. Does it fix issues that users have reported to us?
If yes, continue.
3. Does it cause more problems that are immediately obvious?
If no, continue
3. Package release.
> Typically, Linux distributions release a new version once every 6 months or
> 9 months, which seems normal. Updates are usually sparse (and if we really
> want to argue otherwise, we'll have to go back and mine relevant data,
> which isn't hard to do, but time consuming) especially for critical
Why are updates sparse, and who's definition of critical?
Possible reasons for sparseness:
- Package maintainer has limited time available. Sucky maintainer. Add
- Upstream breaks compatibility too much. Ergo ship minor updates but
> With the exception of Fedora, which might get a new kernel every couple of
> weeks once, the others in the list are a lot more conservative about
See the Debian stats that I summarized above, showing the Debian folk
doing an excellent job and keeping up with the releases.
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@stripped
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85