Re: concerns about Salsa
Colin Watson <cjwatson@debian.org> writes:
> My experience has been that if I'm working on a complex service then I
> want as little friction as possible for the fast-moving stuff that I'm
> working on directly and so often end up deploying that straight from git
> or whatever, but that I prefer to use packages for everything else below
> that layer.
My personal experience is that there is an interesting cycle of scale
here.
If you have a pretty small environment where you're not doing significant
local development, tracking the Git version of something, or trying to be
on the cutting edge, using packages for everything is best, since it
minimizes your risk and most of your attention is going to be on
configuration and content. (In other words, the software is just a tool
for something else you're doing.)
If you then start doing substantial amounts of local development, or are
aggressively tracking some upstream package, then it starts making sense
to run that one thing out of Git, since that is the thing you want to
spend time on and do really well, and possibly uniquely well. It makes
sense to use Debian packages for all the other things that form the
scaffolding on which it's built, since those things you want to be stable
and you don't want to have to think about them. But the thing that you're
actively working on you want to be as low-friction as possible. (At this
point, the software *is* your product.)
However, once you get beyond the scale of a few machines, this starts to
break down again because you need a deployment process with stage, canary,
and production, some rollback process, synchronization across lots of
nodes, and so forth. At this point, you end up having to reintroduce
packaging of everything to get those properties. However, it's more
common to use containers instead of OS packages once you reach this set of
problems, largely because it's often desirable to allow different
applications to use different underlying library stacks and not have to
upgrade everything in lockstep with dependencies. Once you hit this
scale, you often have a lot of stuff, and the tighter of coupling you have
between all your stuff, the more you get a combinatorial explosion of
problems during upgrades. So mechanisms like containers that can loosen
the coupling between your services are immensely valuable.
I think people's varying reactions on this thread may have a lot to do
with where they are in this hierarchy of scale, and what problems they
therefore anticipate. But the Debian Project infrastructure itself seems
to me to be firmly in that middle tier where it makes sense to run the
core thing out of Git and the supporting scaffolding from packages. We
have a lot of things that we're working on directly and intensely as the
core mission of that part of the project, but generally they're deployed
on one or two machines and don't need management at scale, canarying, and
rollback properties.
More broadly, one useful way to think about the mission of a Linux
distribution is to make all the things our users *don't* care about
effortless and simple, so that they can invest all of their energy and
attention into the one or two things they *do* care about. Trying to get
them to package those few things that they care about deeply is more
dubious and often doesn't add much value for them.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: