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

On Tue, Sep 18, 2007 at 11:02:24PM +0200, Colin Charles wrote:
> >>>I think this is the worst case for the user, and would hurt
> >>>not only the "commercial Enterprise users" but all users, as
> >>>they then get a much less-maintained version of MySQL with
> >>>more delayed bug fixes.
> >>Since distributions don't normally *ship* every month, how
> >>does this make it worse for our user base?
> >updates/
> And what is wrong with once every 3 months? Most sensible
> distribution maintainers ship updates conservatively

Hey, even Microsoft ships monthly batches, and sometimes would yield a hotfix even faster. I don't know which distro raves for slow updates when there's, unfortunately, a reason.

I don't exactly love to drop everything and work on an update but when it's a data corruption or code execution, there's no excuse to be "sensible" and "conservative". Those who prefer elephant cycles can elect to *not* apply updates in time, at least until either these are tested or getting pwned.

> and if you're updating core software, you do so *very*
> conservatively

I'm yet to think of MySQL as a core software, thanks. Very good when it just works, but core... glibc or kernel are, services might be but that depends a lot on the quality of upstream tarballs and the interest of the maintainer(s).

  BTW it's quite common mistake among mediocre schoolteachers   to consider their subject "a core discipline"... please   avoid that, the better ones do know that children differ ;-)

> Even *before* MySQL decided to release a source tarball every
> 3 months once, these distros never shipped every incremental
> release of MySQL.

Uh-oh. Apart from what's told regarding Debian elk, I'd suggest looking into any useful input from distros that's not related to versions included in releases (or when updates have to bump it).

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

It would be interesting but I'm afraid it's safe to presume that you need no free testing of just about everything in between, no?

> They did so when there was a security risk. Or when it seemed
> appropriate for an update

Regarding MySQL, that's every single version I've thoroughly read changelog of.

egrep -i 'security|crash|corrupt' would tell the story.

I'm not blaming anyone for *making* those *errors* in the first place, we're humans and we do err. I might blame those trying to find a reason to *withhold fixes*, especially when these are in fact available.

For the record, here's this year's changelog of MySQL package in our unstable -- not every minor but also not exactly trivial process:

• Thu Aug 09 2007 L.A. Kostis <lakostis@altlinux> 5.0.46-alt2 - fix a typo in alt-mysql_install_db.patch.
• Mon Aug 06 2007 L.A. Kostis <lakostis@altlinux> 5.0.46-alt1 - 5.0.46. - Update -alt-install-db.patch. - Update -alt-username-length patch. - Update documentation to 7319 revision.
• Wed Jun 20 2007 L.A. Kostis <lakostis@altlinux> 5.0.42-alt1 - 5.0.42.
• Mon May 28 2007 L.A. Kostis <lakostis@altlinux> 5.0.41-alt1 - 5.0.41 release. - Fix CVE-2007-2583 DoS (Failure to Handle Exceptional Conditions). - Added patches from BK: + BUG#28337 (NOT EXISTS with GROUP BY behaves different in 5.0.40). - Update ALTLinux patches: + install-db patch. + username-length patch. - Updated html help (to 6552 revision). - Allow custom nice setting for mysqld (fix ALT #10941). - Added mysqld-multi (fix ALT #5715). - Added several files for -server and client.
• Sun Feb 11 2007 L.A. Kostis <lakostis@altlinux> 5.0.34-alt1 - 5.0.34 release. - update html help (to 4891 revision). - Fix db_install in hasher (closes #10788). - Fix charset detection routes in init.d script. - Update install-db patch. - Remove obsoleted patches.

> 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

Packaging bug or upstream bug? I'm maintaining more than 150 packages, some of them for 5+ years, and so far rather disagree for the most part.

Do you need more 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

But then again I happen to maintain most actively nice software which is usually fixing bugs, not (re)introducing them with new releases. Apache 1.3 or enca are two nice examples of these ;-)

(these also tend to survive the next test added to automated QA in ALT without the need for band-aid; guess at least half of Fedora/RHEL or openSUSE/SLES package bases just wouldn't pass even non-distro-specific ones, maybe should check another day)

> Typically, Linux distributions release a new version once every
> 6 months or 9 months, which seems normal.

Heh.

There are "pop" distros which pop out every 6--9 months, there are enterprise ones which don't really do so, and there's something in between of them, like Debian (or ALT) where quality is honored more than fast schedule.

These tend to have unstable branches (one might put Gentoo here as well for continuous portage update cycle -- between 1/120 and 6 to 9 months between "releases"), and it's where the testing by competent occurs (or should occur).

IMO every sane upstream should run, not walk, to make sure their current versions are on major unstable branches -- including timely freshmeat announcements and/or public announce lists (I know lists.mysql.com does have one).

Those who could be in charge of decision to maintain distro-specific repositories of MySQL builds might be interested in this article:

Can we help you?

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

http://freshmeat.net/articles/view/992/

> Updates are usually sparse [...] especially for critical
> applications

It's sure good when there's no need to update. Sometimes there is, and it looks like better spent time to roll in another crash bug fix with the one which triggered an update (or errata) preparation and testing in the first place.

BTW distros tend to reconsider backporting vs current version these days, there was kernel-related discussion some month ago or so. It's easier for distros not to mess with backporting fixes (with a good chance to miss something fixed elsewhere), and it's considered better for upstream to have more vanilla and more current source to accept bugs against.

Desperate need for backporting is usually a sign of ugly upstream (as opposed to "nice" above). Many of these did grow up though to be bump-safe.

> 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

Fedora well might be just a primary kernel testbed, of course. But even "the" conservative Debian was shown to disagree with this particular paragraph (on unstable which breaks the idiom :).

PS: is it me only or it might really help to spell "we think" than "our users think" on behalf of those users?

-- 
 ---- WBR, Michael Shigorin 
  ------ Linux.Kiev 
http://www.linux.kiev.ua/

-- 
MySQL Packagers Mailing List
For list archives: 
http://lists.mysql.com/packagers
To unsubscribe:    
http://lists.mysql.com/packagers?unsub=lists@pantek.com

Can't find what you're looking for?

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