Bug#986311: SRM input requested: Re Bug#986311: unblock: debian-cloud-images/0.0.4
Dear SRM colleagues, Your input/confirmation is appreciated on the following issue. tl;dr; are you OK with updating debian-cloud-images in the stable release? On 03-04-2021 21:29, Paul Gevers wrote: > Hi Noah, > > On 03-04-2021 17:44, Noah Meyerhans wrote: >> It is sufficient for the Depends packages to be available in the next >> release. > > Unfortunately, our package handling goes per source package, not by > binary packages. > >>> 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. > > What do you mean with "it's too late for that"? We *could* (not saying > we should) drop the package. > >> 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. > > If the SRM's are fine with updating the package in stable, I'm happy to > unblock it. I'll point them to this bug to have them weight in. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#986311: unblock: debian-cloud-images/0.0.4
Hi Noah, On 03-04-2021 17:44, Noah Meyerhans wrote: > It is sufficient for the Depends packages to be available in the next > release. Unfortunately, our package handling goes per source package, not by binary packages. >> 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. What do you mean with "it's too late for that"? We *could* (not saying we should) drop the package. > 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. If the SRM's are fine with updating the package in stable, I'm happy to unblock it. I'll point them to this bug to have them weight in. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#986311: unblock: debian-cloud-images/0.0.4
Hi Bastian, On 03-04-2021 21:08, Bastian Blank wrote: > On Sat, Apr 03, 2021 at 08:00:20AM +0200, Paul Gevers wrote: >> So, I'm very uncomfortable with the union of this key packages tracking >> package > > Then please drop the UUD entry that forces it to be a key package and > drop the package from testing. After that we'll stop updating packages > in stable and just fake them into official Debian releases without any > chance of security updates. Would you consider that a better solution? You sound a bit harsh, please assume good faith. Let me at least point out that I was not aware of earlier discussions about uploading the package to stable releases. I'm just wondering what's the best course of action, and remarks in the original request made me wonder if we should ship the debian-cloud-images in stable releases. We *made* src:debian-cloud-images a key package because of the debian-cloud-images-packages binaries, not because of the debian-cloud-images binary. So, if they seem (maybe just for someone that looks for the first time at it) an ill fit together, maybe we can find a better solution (now or in the future). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#986311: unblock: debian-cloud-images/0.0.4
On Sat, Apr 03, 2021 at 08:00:20AM +0200, Paul Gevers wrote: > So, I'm very uncomfortable with the union of this key packages tracking > package Then please drop the UUD entry that forces it to be a key package and drop the package from testing. After that we'll stop updating packages in stable and just fake them into official Debian releases without any chance of security updates. Would you consider that a better solution? Regards, Bastian -- Most legends have their basis in facts. -- Kirk, "And The Children Shall Lead", stardate 5029.5
Bug#986311: unblock: debian-cloud-images/0.0.4
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 signature.asc Description: PGP signature
Bug#986311: unblock: debian-cloud-images/0.0.4
Control: tags -1 moreinfo Hi Noah, On 02-04-2021 22:00, Noah Meyerhans wrote: > Please unblock package debian-cloud-images 172 files changed, 3798 insertions(+), 1365 deletions(-) > Primarily I'm requesting this because this source package provides the > debian-cloud-images-packages package that is a key package (see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929214) and updating the > package in bullseye will update the Depends list to match what is actually > required to build cloud images today. Ack. > 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. Should the current package in testing be released with bullseye if we don't update it? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#986311: unblock: debian-cloud-images/0.0.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package debian-cloud-images Primarily I'm requesting this because this source package provides the debian-cloud-images-packages package that is a key package (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929214) and updating the package in bullseye will update the Depends list to match what is actually required to build cloud images today. 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. Thanks noah unblock debian-cloud-images/0.0.4
