[conspire] Sat, 1/10 Installfest/RSVP

[Nick Moffitt]

Rick Moen:
> Er, sorry, Nick.  That escaped before I had the rest of it edited.

No problem.  It seems we're talking past each other a little on a couple
of levels here :)

> Deirdre figured it out from pure logic:  IIRC, she reasoned that her
> code hadn't changed, so something that _did_ change must have caused
> the problem, 

Yes, well it always helps to have developers with cluebats of their own,
doesn't it!

[on "foolishness"]
> That word reflected my having seen the cost, at a prior employer that
> is still stuck on antique enterprise-Linux versions carried forward
> long past reason, notably RHEL3 Update 5 (and Update 8).  Red Hat was
> (perhaps still is; haven't checked) claiming to "support" that thing
> through selective package updates in RHN, but it had long become
> ridiculously creaky, and the only people who couldn't face facts were
> the company's management, whose policy decreed that RHEL3 would remain
> a "supported platform", and if facts such as broken key system calls
> stood in the way, so much the worse for the facts.

Ah, right.  And there were no more recent releases in the "supported
platform" list for you to run to safety?  That would be pretty
horrifying.

My specific trust of LTS is not "I'm going to stick with Dapper until
2011", but rather "There's three years in which I can upgrade all
straggling Dapper boxes to Hardy, and if I haven't done it before the
next LTS comes out I'm a damned fool."

In fact, there were many circumstances over the past two years where
systems were taken to Edgy or Feisty or Gutsy just because Dapper didn't
have what we needed.  We did what we could with Dapper, but that wasn't
worth the effort in some cases.

If you're having problems with RHEL3, FFS upgrade to whatever more
modern release you're willing to maintain!  But hey, if it still works
and you're still getting security fixes down a useful package-upgrade
pipeline, might as well let it be until the security attention is about
to vanish (or at least consider other priorities in that decision).  It
sounds like RHEL3 is a bit more creaky than that.

Dapper, too, was a rather mixed release for an LTS, and Hardy is vastly
better on a number of fronts.  I'm sure I won't have to work on any
Dapper systems during the sunset years of its security attention.  But
if there's an unimportant Dapper box still ticking away next year, I
won't be too worried so long as it has its security updates and hasn't
blocked any real work.

> The developers kept succeeding in blocking migration to neweer
> kernels, evne though there was no rational reason why their strictly
> userspace code should have kernel sensitivities.  They claimed their
> stuff might break.  We said, "If it does, it's embarrassingly broken
> and _that_ is the problem you should fix without delay."  They dug in
> their heels and claimed there would be lost revenue.  They won.
[...] (7-bit ascii this time!)
> Everything they wrote should have worked trivially on any X11-based
> Linux or BSD.  The refusal to clean up their code, and the resulting
> loss of rational decision-making, easily qualifies as "foolishness"
> and more.

Agreed.  And yes, I can see how a fetishistic "BEST PRACTICES" sort of
idiocy can flow from the long-term support horizons.  

> And damned near any codebase you can cite that can be rationally
> expected to break just from an orderly distro upgrade of something with
> a functional policy 

I still think that the difference in attention makes the difference
here: a package in the official repositories gets hammered on by the
Many Eyes, while an in-house codebase often makes its milestones by
making assumptions.  I do think that the MySQL scenario earlier didn't
depend on the informal environment described.  It could happen anywhere.

-- 
BitKeeper, how quaint.                         Nick Moffitt
                -- Alan Cox                   nick at zork.net