On Fri, Apr 08, 2022 at 03:37:11PM -0300, Lucas Kanashiro wrote: > Em 08/04/2022 14:30, Steve Langasek escreveu: > > Hi Lucas, > > > > On Thu, Apr 07, 2022 at 04:35:13PM -0300, Lucas Kanashiro wrote: > >> Hi release team, > >> A couple of days ago, I got runc SRU not accepted into focal-proposed > >> [1] because it is not following what was strictly described in the > >> docker.io group exception page [2]. After talking to mwhudson and tianon > >> (who were working on this stack before me), we noticed that this was > >> quite outdated and we have not been following what was described in the > >> Process section for a while. I made some changes to this section and the > >> content was approved by tianon. The idea behind the old process was to > >> avoid updating stable releases with docker.io version x.x.0 because the > >> upstream project at the time was not so mature, but nowadays there are > >> some pretty strong incentives to make sure their releases work (even .0 > >> releases). > >> I would like to get the approval from the SRU team to make those changes > >> official. To ease the review you can find the old and the proposed > >> sections here [3]. In order to avoid any confusion I added a sentence > >> here [4] to clarify that the current content of [2] is not yet approved > >> by the SRU team. > >> Thanks in advance! > >> [1] > >> https://bugs.launchpad.net/ubuntu/+source/containerd/+bug/1960449/comments/8 > >> [2] https://wiki.ubuntu.com/DockerUpdates > >> [3] https://paste.ubuntu.com/p/hg9d5rT63j/ > >> [4] https://wiki.ubuntu.com/StableReleaseUpdates#Docker.io_group > > While the new language reads much nicer, one nuance that's been lost in the > > process is the idea that we don't SRU the .0 releases but wait until they've > > had a chance to fix bugs and stabilize things with a .1. Is this a > > deliberate change, and if so, what has changed in terms of upstream practice > > or our QA that makes us think this is no longer a requirement?
> Yes, the change to also accept .0 releases is what triggered this > request (in this case a .0 release of runc). After talking to tianon, > the part to avoid .0 releases was meant to be for docker.io mostly, > which at the time was not stable enough, however, this made runc get not > approved. > Regarding docker.io QA, this is more an upstream work, they have > received multiple incentives to improve the quality of their release and > since a while they are quite stable. If we prefer we can keep that > policy to avoid the backport of .0 releases of docker.io, and relax this > for containerd and runc which are more stable in general than docker.io. If docker.io is still providing regular point releases such that waiting for the .1 will not be a big problem for SRUing, then the above would be my preference. > > If we have NOT been following the rules as stated, that is not something I > > was aware of. > Unfortunately we have not. If we get the proposed process accepted (with > some changes if needed) I'll make sure we follow it from now on. Well, I think it's on the SRU team for not following the process when accepting SRUs :) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
