[conspire] Sat, 1/10 Installfest/RSVP

[Nick Moffitt]

Rick Moen:
> Quoting Nick Moffitt (nick at zork.net):
> > Again, the power of apt is the result of a policy process, not a magic
> > piece of technology.
> 
> Quite.  And functional policy is what tends to prevent exactly the sort
> of theoretically-possible libs problem you mentioned.

Again, I referred to "ABI" as a hand-wave to the entire runtime.  It's
true that binary .so packages have a nicely stable defined interface.
But I'm not living in a world where all my software comes from outside.
I'm not dealing with nothing but debs and the odd source tarball.
Subtle differences like your MySQL story become more and more important.

I'm trying to think what I'd do if I encountered a big warning about
MySQL explicit COMMITs during an upgrade on a DB server supporting
in-house developers.  Would I just leave the upgrade hanging in a
half-installed state while I conversed with the developers?  Would I
just plow ahead?  Roll back in a hurry?  Fortunately, right now I am
confident that if I'm upgrading a system, it's to a specific state that
the developers have already tested with.  I can just plow ahead through
a warning like that with confidence.

> Anyway, I stay on testing/unstable in part to obviate the most obvious
> source of madness you describe:  backporting, which you cited in one
> of your original messages.  Man, what a time sink, and so easily
> avoidable in its entirety.

It's trivial compared to the time spent upgrading hundreds of machines
per week.  And there isn't much work to it usually: just upload the
package to our queues and it lands in our repos shortly after.  The only
horror there is things like the pycentral barrier (which fortunately
we're long past).

> And I carefully stay away from problem code that I don't need.
> rdiff-backup?  No thanks.  

Yeah, well let me know when a system comes along that is as efficient as
the rsync protocol and gives you reverse incrementals (SO FABULOUS) for
free.  Fantastic software: shitty upstream release policies.

> The server machines I ran at $EMPLOYER were a different matter
> entirely.  And there, I _did_ have pretty tight SLAs -- and met them,
> and was confident of doing so.

Yeah, and this is the difference between you and me: you characterize my
approach as "foolishness", while I accept your approach as valid given
the constraints you work in.  You speculated on what you'd do given
*one* of the factors that I mentioned working with (large numbers of
machines) but appear to have dismissed the rest of my situation as
either uninteresting or impossibly wrongheaded.

I've known you long enough that I'm confident that you could implement
what you describe in a larger organization.  I'm not arguing *against*
your approaches flat-out.  I'm purely on the defensive here: I just
don't think it's such a bad idea to isolate variables by keeping things
somewhat fixed for a period of months, rather than days.  But you
offhandedly dismissed that as some sort of blind idiocy.

One final point that I feel is worth mentioning: since lots of other
people are sticking to LTS releases in big production environments, it
gets a lot of bug-fixing attention without unnecessary new release
motion.  If I file a bug against Hardy, it will tend to get a lot more
corroboration and action than if I'd filed a bug against a
blink-and-you-missed-it release of a package in the latest
crack-of-the-day stream.

-- 
Man, I love how everyone is like "In my blog, which is       Nick Moffitt
a blog on the Internet, which you all may be interested     nick at zork.net
in visiting, I talked about what I am now saying here."
                            -- George Moffitt