Thanks Martin,
We of course are in the process of migrating on from Jessie but due to LTS the timescales were deliberately left quite loose.
Re your timeline email - I think it's a good idea having such a timeline prominently reiterated. It certainly hadn't occurred to me that support for debian-cloud would vary from LTS but I'm learning that one does not necessarily follow the other.
As for LTS security support, we've found it to be excellent. The only thing I would say (which has been mentioned already) is it wasn't a particularly seamless transition as far as the mailing list goes.
On Tue, 23 Oct 2018 at 12:14, Martin Zobel-Helas <
zobel@ftbfs.de> wrote:
Hi David,
My understanding is that removing the images from the vendors market places is to make the images less easy discoverable and to discourage users from spinning new instances from an old image type. I don’t know the exact details for AWS but my guess is those AMI IDs will NOT remain indefinitely but at least longer.
Also be aware that we will release Debian Buster hopefully in the middle of next year. Maybe it is time to switch away from Debian Jessie at one point... Rather sooner than later...
Best regards,
Martin
Thank you... so the amis themselves should remain indefinitely?
On Tue, 23 Oct 2018 at 11:47, Martin Zobel-Helas <
zobel@ftbfs.de> wrote:
>From my understanding Noah only removed the links from the market place, but did not remove the images from the storage. This means by knowing the image AMI IDs you should still be able to rebuild your images on top of our Debian images.
Best regards,
Martin
This whole thing where there's two teams with similar or overlapping technically responsibilities (building cloud images), but who don't talk to each other much, don't integrate technically, and in fact might make snarky gossip asides towards each other (really people???). In the devops world that's called siloing.
And it's something that needs to be fixed at a pretty high level of the organization.
I'm just going to say it.
1. We should not have different mechanisms for building LTS and non LTS images. That's so obviously technically redundant. (ie gcloud lts images use packer, but gcloud current images use diasy, yes that's a contrived and oversimplified example)
2. Yes Debian should maintain cloud images for releases that are in the LTS phase.
3. LTS and cloud obviously should work on this together in harmony, rather than tossing the football over the wall of their silo constantly.
4. I have no idea how to get this to happen, especially for a volunteer project. It's above my paygrade!