I never spoke with the DMB directly, I only know what Steve told me from when he spoke to them. Steve's comments on this bug are what I've been working of of:
https://bugs.launchpad.net/cupstream2distro/+bug/1459186 On Tue, Sep 22, 2015, 6:09 AM Łukasz 'sil2100' Zemczak < [email protected]> wrote: > Hey Robert! > > Excellent news in overall. Just a quick question I already asked on > multiple other occasions: is the DMB fine with such an approach? I know > it all sounds sane and safe as is but I just want to make sure the DMB > is fine with letting everyone unprivileged push out new versions of > packages (even if only those without any packaging changes). Did you or > Steve consult this with them? In the normal Ubuntu release process users > need sponsors for everything. In the past only the trainguards and/or > core-developers had this privilege in the CI Train. > > Cheers, > > W dniu 22.09.2015 o 09:21, Robert Park pisze: > > On Mon, Sep 21, 2015 at 9:59 PM Robert Park <[email protected]> > > wrote: > > > >> This means that if your silo does not touch any files under debian/, you > >> can publish your own silos totally by yourself, no trainguards required. > >> > > > > Ooops, this statement is not totally clear, as raised by some people on > > IRC. The official policy for publishing is as follows: > > > > The publish job now honors real archive upload permissions, that is, only > > core-dev can upload main packages, only MOTU+core-dev can upload universe > > packages, and also per-package uploaders can upload their packages. > > > > The exception is, in the case of projects that canonical owns, if the > silo > > contains a package that didn't touch any files under debian/, the > developer > > can publish by themselves without anybody else helping them along. This > > means only MPs, not source packages. > > > > So the new workflow should look like this: > > > > 1. You create your own ticket at https://requests.ci-train.ubuntu.com/ > > > > 2. You assign your own silo. > > > > 3. You build your own silo and do your own testing. > > > > 4. Submit your silo to QA and wait for them to approve it, if necessary > > (only necessary for overlay PPA releases, not necessary for wily) > > > > 5. You publish your own silo. If it works, great, if not it may say > you're > > not authorized, at that point you should find a core dev, show them the > > packaging diffs, and ask them to publish for you. When hassling your > > favorite core dev, best practice is to link to the publish job page with > > the build number at the end of the URL, like [0], as this will show the > > diffs and then easily allow the core dev to publish. If you just link the > > publish job page without the build number like [1], you get "last > > successful artifacts" which won't show the right diffs because the job > > technically failed. > > > > 6. The train will monitor the publication and once the package is > > successfully landed in ubuntu archive, it will automatically merge your > > merges and free the silo. > > > > [0] https://ci-train.ubuntu.com/job/ubuntu-landing-019-2-publish/97/ > > [1] https://ci-train.ubuntu.com/job/ubuntu-landing-019-2-publish/ > > > > > > > > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > [email protected] > www.canonical.com > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
