ubuntu-phone team mailing list archive

[Robert Park <robert.park@xxxxxxxxxxxxx>]

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 <
lukasz.zemczak@xxxxxxxxxxxxx> 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 <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
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>