On Mon, Oct 22, 2018 at 07:12:54PM +0000, Luca Filipozzi wrote: > Is this true: the goal of the Debian Cloud Team is to make roughly equievalent > Debian Cloud Images for the various cloud providers so that > Debian users have a consistent (to the degree possible) experience with > Debian in each cloud? That is a goal. > If true, is it also true for Debian LTS Cloud Images? I can accept that > it might not be, especially if the Debian Cloud Team _isn't_ taking > accountability for these LTS images (regardless of who is responsible > for the work: Credative for Azure, etc.). As a user, I wouldn't expect there to be any visible differences, aside from package updates to address issues, between an oldstable image generated during the security team's support window and an LTS image generated after the handoff. So I don't know that I see a reason why this *shouldn't* be a goal for the cloud team. To a very large degree, all I would expect as a user of the LTS images is that I have fewer pending updates on first boot than I would if I launched the latest 8.x images generated during its oldstable window. Clearly the project as a whole is still trying to figure out how the LTS effort relates to the rest of the project. With a relatively small number of people being paid to work on it, and potential a lack of interest among the developer community in general in supporting such old software, I can see how it might not be sustainable. However, there is clear user demand for it, or we wouldn't be having this conversation. So I think we're better served by figuring out how to make LTS work (in cloud environments and more generally) than by trying to figure out how we can say no. > > Note that I'm not necessarily proposing that we provide regularly > > updates LTS images for the full duration of the LTS lifecycle. > > This, combined with the per-provider approach, suggests that the Debian > Cloud Team isn't accountable for the LTS images? Which would then lead > to a question about how to publish the LTS images. jessie is somewhat a special case, since it completely predates the use of FAI for our image construction, and largely predates the existence of the cloud team in its current form. As a result, it would require additional work on the cloud team's part in order to support it at the same level as stretch and future releases. It's unlikely that anybody is going to do the work to fully integrate it with the rest of the gitlab-driven CI pipeline, so image generation may be somewhat more manual. So today, there is additional ongoing effort required. Nobody is required to put in that effort, but I am willing to do so in order to support our users, and others may be as well. For future LTS releases, ongoing support after the LTS handoff is probably relatively easy, since we'll already have all the automation built out and the ongoing effort will be small. Is there any reason to expect that the LTS team will not support the cloud team or cloud users, should we (or our members individually) decide to continue to publish images on one or more cloud platforms? noah
Attachment:
signature.asc
Description: PGP signature