Pierre-Elliott Bécue writes ("Re: concerns about Salsa"):
> Le lundi 04 juin 2018 à 12:54:32+0100, Ian Jackson a écrit :
> > In practice, I have found that it is much easier to deploy a
> > production service directly from its git tree. This makes it much
> > easier to make changes.
>
> I've always found otherwise, ie that packaged stuff makes the administrator
> of a service spare a lot of time.
I wanted to add that of course it is OK that different people have
different opinions about this. (And that the same people have
different opinions at different times and in different situations.)
However, I don't think it reasonable to criticise the Salsa team for
this deployment strategy. Do you criticise the ftpmaster team, and
indeed me as dgit server operator, for the same reasons ?
We have done what we think is easiest for us. And at least the way
the Salsa team have done it, and the way I have done it, do not
compromise our or anyone else's software freedom: the arrangements
ensure that source of the version we are actually running is always
published. The same deployment strategy as we chose ourselves is
available to everyone else.
You may well say that it would be nice if deploying a service produced
good packages of that service as a side effect. But I don't think
it's fair to demand that the operators of a service also to take on
the packaging work, if the service operators don't think that's an
effective strategy.
I think if it bothers you that service operators are deploying from
vcs, rather than from packages, you should consider helping to remove
or mitigate the reasons for that decision, which can include:
* The service software is not sufficiently mature or complete,
so it keeps changing and it is necessary or desirable to keep
up to date with very recent upstream versions.
* Vulnerabilities are often discovered in the service software
so it needs to be frequently updated, perhaps with ad-hoc patches.
* The service software is not sufficiently mature and stable,
so it is sometimes necessary to urgently deploy local ad-hoc
fixes (bodges, even) to address operational issues.
* The packaging work is difficult (for one reason or another).
* The service operators sensibly do not have root on the host system,
so updating it via ad-hoc packages is not appropriate (and
ad-hoc updates wouldn't be in sid anyway).
* Updates via testing are too slow because of NEW or testing
propagation.
* The dependencies of the testing version are not satisfiable on
stable (and of course a production system ought probably to be
running stable).
Many of these reasons are not even really bugs in their own right;
they are consequences of well-considered design and process decisions.
Or they are consequences of wanting shiny new software, or of a lack
of effort upstream.
Nevertheless, I'm sure everyone would applaud you working on making it
easier and better to run more Debian's infrastructure off Debian
packages - *PROVIDED* that your measure of success is that service
operators spontaneously choose to use packaged software because they
find it easier and better.
For my own part: if you discover that git.dgit.debian.org is running a
newer version of dgit-infrastructure than is available in packages in
Debian unstable, and I seem to have dropped off the face of the
planet, you might want to consider an NMU. (If I haven't dropped off
the face of the planet then I would probably be doing an upload of the
delta at some point soon anyway, because having multiple diverging
branches avoidable pain.) Maybe in another half-decade I or my
successors will hand more of it to DSA, asking them to please just
install dgit-infrastructure.deb from stable.
Personally I think that a more important use of effort would be to
tackle services where *the source code is not published at all*!
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
