List:Packagers« Previous MessageNext Message »
From:Michael Shigorin Date:September 19 2007 9:10pm
Subject:Re: Distro packaging decisions and the non-public Enterprise source
View as plain text  
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).

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.

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:

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 <mike@stripped>
  ------ Linux.Kiev http://www.linux.kiev.ua/
Thread
Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson10 Sep
  • Re: Distro packaging decisions and the non-public Enterprise sourceJoerg Bruehe10 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson11 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin11 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin18 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole19 Sep
          • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles19 Sep
          • Re: Distro packaging decisions and the non-public Enterprise sourceJoerg Bruehe20 Sep
            • Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole20 Sep
              • Re: Distro packaging decisions and the non-public Enterprise sourceJoerg Bruehe20 Sep
            • Re: Distro packaging decisions and the non-public Enterprise sourceCristian Gafton21 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson19 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin11 Sep
  • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson19 Sep
Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole11 Sep
  • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin18 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson19 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin19 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole19 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles19 Sep
Re: Distro packaging decisions and the non-public Enterprise sourceCristian Gafton21 Sep