Re: Confusing our users - who is supporting LTS?
Hi Steve!
On 2018-10-23 04:26:18, Steve McIntyre wrote:
> So I'm worried that those of us who have *not* volunteered to support
> LTS are being pressured into spending our time on it anyway. What can
> we do to fix that? How/where do we clarify for our users (and
> developers!) what LTS means, and what expectations are fair?
TL;DR: Why not just delegate image management to the LTS team once
oldstable because LTS just like we do with security? Zobel also provided
a good template for the images life cycle which could clarify this on
debian-cloud@, which I fully support.
I acknowledge this is, indeed, a problem Debian volunteers have
sometimes mentioned. It's a broader issue than just the cloud team of
course, but if I may, I would like to try and fix that specific issue in
itself. I know there's the larger debate of separation of duty and
infrastructure, paid-vs-unpaid work and other questions, but I do not
think it's productive to fix that particular issue by addressing the
larger ones up front, as they seem intractable unless we address
specific cases.
In this case, it seems to me we have a flawed assumption in the way we
handle Debian LTS: we assume people will not actually install it and
instead just upgrade machines installed when LTS was "stable". It's a
fair assumption in the case of workstations and long-lived, "pet"
servers. I know I wouldn't install a new bare-metal server with an
unsupported release: I would install stretch, if not buster, not jessie.
But in the cloud infrastructure, things are slightly different. The base
image isn't as important as the application and/or data that runs on
top. In the cloud, we install new "machines" all the time, sometimes as
part of CI/CD processes and those machines are not "pets", they are
"cattle" and recycled constantly. In that sense, switching the base OS
is, paradoxically, a big deal so it actually makes sense to install an
older release for newer machines. This is why Travis CI still supports
Ubuntu LTS Precise (12.04) and Trusty (14.04), the former which isn't
supported by Canonical, and it's missing *two* more recent LTS releases,
Xenial (16.04) and Bionic (18.04).
So while we haven't taken up the work of managing the debian-installer
parts of Debian LTS (because there was no need or demand for it), it
seems to me like a fair request that the Debian LTS team should manage
the Debian Cloud images once the official support window closes. Just
like the security team delegates oldstable to LTS, the cloud team could
hand off unsupported images to the LTS team. In a way, just like APT and
the normal archive, "cloud images" are just another way to "upgrade" an
existing Debian install.
It seems like a nice, symmetrical approach to solve the problem: just
punt this over to the LTS team. We have some capacity and knowledge. I
know I would be happy to work on those images.
That's for the expectations part of the question. As for how to clarify
this to our users, Martin Zobel-Helas made a good proposal for a
workflow of how and when the team updates the images and when they
become unsupported. The /etc/motd in the images could mention this, for
example and the last build could add a warning pointing to it. If we
agree to delegate to the LTS team, the document should also mention that
transition.
Sorry for the long email, I hope it's useful!
a.
--
We have to talk about liberating minds as well as liberating society.
- Angela Davis
Reply to: