ubuntu-phone team mailing list archive

[Łukasz 'sil2100' Zemczak <lukasz.zemczak@xxxxxxxxxxxxx>]

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 <robert.park@xxxxxxxxxxxxx>
> 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
 lukasz.zemczak@xxxxxxxxxxxxx
 www.canonical.com