Hi team, A while ago, Martin Zobel-Helas proposed documenting the cloud image lifecycle. The initial thread is at [1]. Bastian and I discussed this at the team meeting and agreed it'd be good to publish something. But it should be discussed with more of the team. The (I think) easy question: do we all agree this is worth doing? The harder question: assuming so, what should the policy say? zobel's email includes an example proposal. He didn't mean to defend the details, but it's worth considering as a starting point. Roughly, it says that stable images will be: 1. provided through the usual download & cloud-appropriate channels 2. announced at release via debian-cloud-announce@lists.d.o 3. rebuilt either in the event of a significant security update or ~8weeks. 4. supported though the end of stable security support 5. announced at end of security support via debian-cloud-announce@lists.d.o 6. be removed 180 days after EoS announcement 7. cloud providers will announce the removal via their preferred means 10 days before the removal My thoughts: - #1-5 sound good. I don't think we all agree on periodic rebuilds when there's no security update, but that seems okay to leave out. - #6-7 sound too risky to users. I'd rather see images stick around indefinitely, especially once we have guidance about security support. If the cloud marketplaces can mark an image as deprecated, that might be useful. But the underlying image should still be available to users that depend on it. - When stretch transitioned to LTS, the azure, ec2, gce, and openstack folks all agreed to keep delivering images (see [2]). So I think we have good consensus for supporting stable releases through their LTS period. - It'd be great to have something ready for the bullseye release, even if it says less than we would otherwise want. Thoughts? Ross [1] - https://lists.debian.org/debian-cloud/2018/10/msg00083.html [2] - https://lists.debian.org/debian-cloud/2020/06/msg00068.html
Attachment:
signature.asc
Description: PGP signature