Re: Include docker-{buildx, compose-v2} to the Docker.io group exception
Hi again :) On 15/09/2023 16:39, Andreas Hasenack wrote: Hi, On Fri, Sep 15, 2023 at 4:24 PM Lucas Kanashiro wrote: Hi, On 14/09/2023 10:20, Andreas Hasenack wrote: Hi, On Thu, Sep 14, 2023 at 9:54 AM Lucas Kanashiro wrote: Hi, On 14/09/2023 09:33, Andreas Hasenack wrote: Hi, On Thu, Sep 14, 2023 at 8:06 AM Lucas Kanashiro wrote: Hi Andreas, On 13/09/2023 11:58, Andreas Hasenack wrote: Hi Lucas, On Fri, Sep 1, 2023 at 6:14 PM Lucas Kanashiro wrote: Hi SRU team, I'd like to ask for an update of the Docker.io group SRU exception [1] to also include the two new Docker CLI plugins that are now in the archive (Mantic): - docker-buildx - docker-compose-v2 Sorry for taking to long to get to this request. No problem. They are self contained (no reverse dependencies). They will also considerably improve the experience of our Docker users across all releases. Those 2 new packages are really tightened to the Docker version we have and it would be great to keep it consistent everywhere. My idea is to not allow the backport of versions .0 of those packages as we do with docker.io-app. [1] https://wiki.ubuntu.com/DockerUpdates Approved on the condition that we have a few new DEP8 tests. I think But also please see my comment about docker-compose vs docker-compose-v2 at the end this is importand because, per SRU exception[1] for this group of packages, DEP8 tests are basically the only tests performed. Do you mean the current DEP-8 tests are not enough? There is no "docker build" in the current DEP-8 tests, much less with DOCKER_BUILDKIT=1 (I'm looking at mantic), and no test for docker compose, even to check its presence. You are asking to include two packages in an exception which relies on the DEP-8 tests, so yes, I think these two new packages should be tested. There is a call to "docker build" in line 24 of d/t/basic-smoke of docker-buildx. Ah, I was checking src:docker.io-app, sorry. Looking at the correct package now, src:docker-buildx, it uses "docker buildx" indeed. Ok then, we just need a normal build (not buildx) with and without the env var, like what triggered the regression report. Just be wary that this env var usage might disappear in the future I suppose, as buildkit becomes default. Then the test would be moot and could be removed. Something to keep an eye on. +1. The "docker compose" command is called multiple times in d/t/basic-smoke of docker-compose-v2. Same thing, sorry. I was looking at src:docker.io-app. ACK on docker-compose-v2, no further tests needed. AFAICS just the DOCKER_BUILDKIT=1 is not covered by the current tests. Correct, with a normal "docker build" command. Noted on the binary package. So what will happen to the old bin:docker-compose? TBH I plan to do nothing, it is sync'ed from Debian and it is a totally different package (even written in a different programming language). Ok, that's something for an AA to sort out when the time comes. Does this mean that the addition of those two packages to the exception is accepted under the condition of adding DOCKER_BUILDKIT=1 to the docker-buildx DEP-8 test in the next upload? Should I go ahead and Yes, DEP8 in next upload, and a manual run on this one. And a normal "docker build" (not buildx), unless I missed that one too and it's already being done. Right, I'll add the regular "docker build" as well. Both changes in the next uploads of docker-buildx. update the wiki page containing the exception? Do you want to do that instead? Please do it. Just did it, let me know if there is any issue. I'll be working on the backport of those packages to stable releases. Thank you very much! -- Lucas Kanashiro -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Include docker-{buildx, compose-v2} to the Docker.io group exception
Hi, On Fri, Sep 15, 2023 at 4:24 PM Lucas Kanashiro wrote: > > Hi, > > On 14/09/2023 10:20, Andreas Hasenack wrote: > > Hi, > > > > On Thu, Sep 14, 2023 at 9:54 AM Lucas Kanashiro > > wrote: > >> Hi, > >> > >> On 14/09/2023 09:33, Andreas Hasenack wrote: > >>> Hi, > >>> > >>> On Thu, Sep 14, 2023 at 8:06 AM Lucas Kanashiro > >>> wrote: > Hi Andreas, > > On 13/09/2023 11:58, Andreas Hasenack wrote: > > Hi Lucas, > > > > On Fri, Sep 1, 2023 at 6:14 PM Lucas Kanashiro > > wrote: > >> Hi SRU team, > >> > >> I'd like to ask for an update of the Docker.io group SRU exception [1] > >> to also include the two new Docker CLI plugins that are now in the > >> archive (Mantic): > >> > >> - docker-buildx > >> - docker-compose-v2 > > Sorry for taking to long to get to this request. > No problem. > > >> They are self contained (no reverse dependencies). They will also > >> considerably improve the experience of our Docker users across all > >> releases. Those 2 new packages are really tightened to the Docker > >> version we have and it would be great to keep it consistent everywhere. > >> > >> My idea is to not allow the backport of versions .0 of those packages > >> as > >> we do with docker.io-app. > >> > >> [1] https://wiki.ubuntu.com/DockerUpdates > > Approved on the condition that we have a few new DEP8 tests. I think > >>> But also please see my comment about docker-compose vs > >>> docker-compose-v2 at the end > >>> > >>> > > this is importand because, per SRU exception[1] for this group of > > packages, DEP8 tests are basically the only tests performed. > Do you mean the current DEP-8 tests are not enough? > >>> There is no "docker build" in the current DEP-8 tests, much less with > >>> DOCKER_BUILDKIT=1 (I'm looking at mantic), and no test for docker > >>> compose, even to check its presence. You are asking to include two > >>> packages in an exception which relies on the DEP-8 tests, so yes, I > >>> think these two new packages should be tested. > >> There is a call to "docker build" in line 24 of d/t/basic-smoke of > >> docker-buildx. > > Ah, I was checking src:docker.io-app, sorry. > > > > Looking at the correct package now, src:docker-buildx, it uses "docker > > buildx" indeed. Ok then, we just need a normal build (not buildx) with > > and without the env var, like what triggered the regression report. > > Just be wary that this env var usage might disappear in the future I > > suppose, as buildkit becomes default. Then the test would be moot and > > could be removed. Something to keep an eye on. > > +1. > > > > >> The "docker compose" command is called multiple times in d/t/basic-smoke > >> of docker-compose-v2. > > Same thing, sorry. I was looking at src:docker.io-app. ACK on > > docker-compose-v2, no further tests needed. > > > > > >> AFAICS just the DOCKER_BUILDKIT=1 is not covered by the current tests. > > Correct, with a normal "docker build" command. > > > >>> Noted on the binary package. So what will happen to the old > >>> bin:docker-compose? > >> TBH I plan to do nothing, it is sync'ed from Debian and it is a totally > >> different package (even written in a different programming language). > > Ok, that's something for an AA to sort out when the time comes. > > Does this mean that the addition of those two packages to the exception > is accepted under the condition of adding DOCKER_BUILDKIT=1 to the > docker-buildx DEP-8 test in the next upload? Should I go ahead and Yes, DEP8 in next upload, and a manual run on this one. And a normal "docker build" (not buildx), unless I missed that one too and it's already being done. > update the wiki page containing the exception? Do you want to do that > instead? Please do it. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Include docker-{buildx, compose-v2} to the Docker.io group exception
Hi, On 14/09/2023 10:20, Andreas Hasenack wrote: Hi, On Thu, Sep 14, 2023 at 9:54 AM Lucas Kanashiro wrote: Hi, On 14/09/2023 09:33, Andreas Hasenack wrote: Hi, On Thu, Sep 14, 2023 at 8:06 AM Lucas Kanashiro wrote: Hi Andreas, On 13/09/2023 11:58, Andreas Hasenack wrote: Hi Lucas, On Fri, Sep 1, 2023 at 6:14 PM Lucas Kanashiro wrote: Hi SRU team, I'd like to ask for an update of the Docker.io group SRU exception [1] to also include the two new Docker CLI plugins that are now in the archive (Mantic): - docker-buildx - docker-compose-v2 Sorry for taking to long to get to this request. No problem. They are self contained (no reverse dependencies). They will also considerably improve the experience of our Docker users across all releases. Those 2 new packages are really tightened to the Docker version we have and it would be great to keep it consistent everywhere. My idea is to not allow the backport of versions .0 of those packages as we do with docker.io-app. [1] https://wiki.ubuntu.com/DockerUpdates Approved on the condition that we have a few new DEP8 tests. I think But also please see my comment about docker-compose vs docker-compose-v2 at the end this is importand because, per SRU exception[1] for this group of packages, DEP8 tests are basically the only tests performed. Do you mean the current DEP-8 tests are not enough? There is no "docker build" in the current DEP-8 tests, much less with DOCKER_BUILDKIT=1 (I'm looking at mantic), and no test for docker compose, even to check its presence. You are asking to include two packages in an exception which relies on the DEP-8 tests, so yes, I think these two new packages should be tested. There is a call to "docker build" in line 24 of d/t/basic-smoke of docker-buildx. Ah, I was checking src:docker.io-app, sorry. Looking at the correct package now, src:docker-buildx, it uses "docker buildx" indeed. Ok then, we just need a normal build (not buildx) with and without the env var, like what triggered the regression report. Just be wary that this env var usage might disappear in the future I suppose, as buildkit becomes default. Then the test would be moot and could be removed. Something to keep an eye on. +1. The "docker compose" command is called multiple times in d/t/basic-smoke of docker-compose-v2. Same thing, sorry. I was looking at src:docker.io-app. ACK on docker-compose-v2, no further tests needed. AFAICS just the DOCKER_BUILDKIT=1 is not covered by the current tests. Correct, with a normal "docker build" command. Noted on the binary package. So what will happen to the old bin:docker-compose? TBH I plan to do nothing, it is sync'ed from Debian and it is a totally different package (even written in a different programming language). Ok, that's something for an AA to sort out when the time comes. Does this mean that the addition of those two packages to the exception is accepted under the condition of adding DOCKER_BUILDKIT=1 to the docker-buildx DEP-8 test in the next upload? Should I go ahead and update the wiki page containing the exception? Do you want to do that instead? Thanks again! -- Lucas Kanashiro -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Fw: MRE request: virtualbox
Hello, I found that an MRE request was acked in 2015 for virtualbox, but since then, the workflow has changed a lot, so I'm asking again for an MRE exceptiom related to virtualbox. I already created the wiki page with the process, I will try to update it to match the current expectation criteria https://wiki.ubuntu.com/VirtualboxUpdates thanks for considering it G. - Messaggio inoltrato - Da: Martin Pitt A: "costamagnagianfra...@yahoo.it" Cc: "technical-bo...@lists.ubuntu.com" ; "secur...@ubuntu.com" Inviato: mercoledì 4 novembre 2015 alle ore 02:26:02 CET Oggetto: Re: MRE request: virtualbox Hello Gianfranco, Gianfranco Costamagna [2015-10-29 18:50 +0100]: > I would like to apply for a micro release exception for Virtualbox Since [1] we actually did away with (most) explicit MREs, and adjusted the SRU policy to generalize those. [1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-September/001152.html > Upstream: > > - Micro releases happen from low-volume stable branches, > approximately once every two months. > > - Stable branches are supported with bug fixes for some years > (normally 5 years + 6 months or more). > > - Upstream commits are reviewed by members of the Virtualbox Server > Engineering team. > > - All commits to stable branches are evaluated wrt. potential > regressions and signed off by the Virtualbox team. > > - Unit tests and regression tests are run on multiple platforms per > push to the source code repository. In addition, there are more > extensive test suites run daily and weekly. > > - Each micro release receives extensive testing between code freeze > and release. This includes the full functional test suite, > performance regression testing, load and stress testing and > compatibility and upgrade testing from previous micro and > minor/major releases. > > - Tests are run on all supported platforms (currently amd64 and i386). This satisfies the current policy, so this looks fine for SRUing. Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.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
