[conspire] Sat, 1/10 Installfest/RSVP

[Rick Moen]

Quoting Nick Moffitt (nick at zork.net):

> No, but I have to take builds from developers and deploy them.  And
> "oops shit my libgubble is different from the one you tested on in a
> subtle way and that meant that the rollout turned into a 500-fest" isn't
> acceptable.

I'm unclear on how this would happen on a distribution with a functional
dependencies system and software packaging policy.  If I ever
encountered such a problem, I think I'd perform a few software removals
if not an exorcism.

> Likewise, being able to build custom packages strictly for Hardy
> *myself* is a great load off.

Well, I try to _avoid_ having locally built packages because of the
maintenance burden -- but, if I were to take that burden on for anything
more complex than leafnode (the only such choice, currently), I do
everything I could to make it buildable in scripted fashion against
arbitrary current and future versions of -devel libs.  Again, this
avoids entirely the need for a fixed _binary_ application interface.

> Do you unify which packages are from unstable and which are from testing
> across all boxes?

That's simply not necessary.  

By default, assume software is going to be available in -testing.  If
for arcane reasons of delay in clearing quarantine, it's temporarily not
available there, append "-t unstable".  Done.

I had a few dozen server boxes at recent $EMPLOYER managed that way.  It
scales, and it works..

> And all mail exits the mailman queues in an orderly fashion?

You know, come to think of it, I _usually_ haven't even bothered to
ensure that the queues were flushed, and still haven't lost anything.
I guess if I had a very-high-throughput Mailman system, I'd make a point
of shutting down the MTA before doing package upgrades, somehow making
sure qrunner caught up (maybe 'tail -f'ing some logs) before package
operations, then restarting the MTA.  It's just never been an issue, so
I hadn't spent time properly solving what hasn't been a problem.