Control: tags -1 - moreinfo On Sat, Apr 03, 2021 at 08:00:20AM +0200, Paul Gevers wrote: > > This package contains a snapshot of the code and configuration used by the > > cloud team to generate the images for azure, aws, and openstack. The cloud > > team does not build directly from the packages in the archive, but rather > > from the salsa repository. So there is no risk of impact to the cloud > > images we generate if this package is updated. Keeping the archive package > > closer to what's actually used by the cloud team is beneficial to any users > > who might be generating their own images based on our configuration. > > So, I'm very uncomfortable with the union of this key packages tracking > package and the actual snapshot package. debian-cloud-images:all is a > new upstream release which doesn't follow our freeze policy at all, so I > think this should be a NACK. I'm also wondering, technically, do you > need the build dependencies of src:debian-cloud-images to be key too to > release the cloud images, or should is suffice to guarantee the Depends > of debian-cloud-images-packages to be in the next release? If I spot > correctly, of the three newly added Depends only fdisk is currently not > key yet, BD python3-yaml is also not a key package yet. It's a Debian-native package, so "new upstream release" isn't really accurate. But yes, it changes a lot of the package contents. It is sufficient for the Depends packages to be available in the next release. > Should the current package in testing be released with bullseye if we > don't update it? IMO, debian-cloud-images should never have been packaged in Debian in the first place, given that there was no plan to maintain it in the archive and that a "stable" packaged version of it bears only a passing relationship to the cloud images we actually ship, but it's too late for that. In an ideal world, the debian-cloud-images package in the stable release would match what generates the images for that release. However, it moves relatively quickly in order to keep up with changes implemented by the cloud services, so that would require us to update the stable package frequently. The ability to update cloud related packages for this reason was discussed with the SRMs some time ago, and I understand that they were supportive of allowing such updates in stable point releases. Practically speaking, we've only ever applied this agreement once, to update cloud-init in buster. If we can't keep the debian-cloud-images package up-to-date in stable releases, then it should not be included. It's the worst of both worlds and can only cause confusion for users. I'd be in favor of removing it from buster, too, if that's the case, where it's most definitely out of sync with what's generating the cloud images today. noah
Attachment:
signature.asc
Description: PGP signature