Change request in the SRU process of docker.io group

[Lucas Kanashiro]

Em 08/04/2022 15:59, Steve Langasek escreveu:
> 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.

Awesome. I edited the DockerUpdates wiki page to clarify that .0
releases of docker.io will not be backported but .0 releases of
containerd and runc are eligible for backporting. Could you check if it
is good enough now?

>>> 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 :)
Fair enough :) but I was not following the defined process in the
development series as well, so it is partially on me. Sorry for that.

-- 
Lucas Kanashiro