Re: Distro packaging decisions and the non-public Enterprise source

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.
http://packages.ubuntu.com/gutsy/source/mysql-dfsg-5.0

> 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
> update

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 releases).

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. http://packages.debian.org/changelogs/pool/main/m/mysql-dfsg-5.0/current/changelog (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 breakages.

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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.mysql.com Links announce benchmarks bugs certification cluster commits dotnet gui-tools internals java maxdb myodbc mysql mysqldoc packagers perl plusplus replication win32 Request more information about Pantek

> 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
> applications.

Why are updates sparse, and who's definition of critical? Possible reasons for sparseness:
- Package maintainer has limited time available. Sucky maintainer. Add   more manpower.
- Upstream breaks compatibility too much. Ergo ship minor updates but   never majors.

> 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
> releases

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@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


application/pgp-signature attachment: stored