Opening backports pre-release

Colin Watson cjwatson at
Wed Jan 11 15:13:05 UTC 2012

On Thu, Nov 17, 2011 at 07:05:53PM -0800, Evan Broder wrote:
> On Wed, Nov 2, 2011 at 2:11 PM, Evan Broder <evan at> wrote:
> >  - Archive admin workload. All backports currently require some action
> > from archive admins. For no-source-change uploads, an archive admin
> > runs a script on the archive master. For source-change uploads,
> > because they are uploaded post-release, they are automatically put
> > into the unapproved queue. Additionally, new packages have to go
> > through sourceNEW and binNEW. Our proposal would create additional
> > work for the archive admins near release time, which may be
> > problematic.
> >
> >  - Upload privileges. I believe that currently anybody on ~ubuntu-dev
> > can upload any package to the backports pocket, and backporters can
> > approve backports of packages they otherwise would not be able to
> > upload. The backports team would prefer to maintain that - would it be
> > sufficient to ensure that manual backports uploads always go through
> > unapproved?
>  * Privileges to upload source-change backports will be changed to
> match the rest of the archive, as opposed to the current configuration
> where any member of MOTU or Core Dev can upload any package. However,
> all uploads would still require approval from ubuntu-backporters.

We talked about this a bit in #ubuntu-motu today.  The background is
that I'm intending to get rid of all cases where archive administration
work requires sshing to ftpmaster
and backporting is one of these things.  The obvious answer is to simply
use backportpackage and sign and upload the results.  There are two ways
this might work:

 (1) We could adapt the archive admin scripts that process backport
     request bugs to run backportpackage, and then we'd sign and upload
     the results.

 (2) ubuntu-backporters could run backportpackage directly and sign and
     upload the results themselves.

Once backporters have queue admin privileges for the backports pocket
(as I explained in the 2011-11-17 meeting), I favour the second option,
on the basis that my understanding of the TB consensus position here is
that we trust ubuntu-backporters to manage the backports pocket
sensibly.  However, Evan pointed out that this contradicts the position
as written up above, so I'd like to lay out the specifics a bit and make
sure we're all in agreement.

Firstly, there's a premise above that turns out not to be true: "as
opposed to the current configuration where any member of MOTU or Core
Dev can upload any package".  I've verified by code inspection, and Iain
Lane has verified by experiment, that a developer who is a member of
MOTU but not a core developer cannot upload a package in main to the
backports pocket.

Secondly, I think it's bizarre in general to have a position where
somebody can approve an action but not perform it themselves (aside from
social requirements for peer-review and the like, which aren't really
the same thing).  We've agreed that we're going to aim for backporters
being able to administer queues for the backports pocket, so I think
it's clear that they should be able to upload to it directly as well.

Therefore, I believe that the ACLs should be as follows:

 * Uploads to all pockets: ~ubuntu-core-dev for all components, ~motu
   for universe/multiverse, teams for package sets, etc. (unchanged)

 * Uploads to backports pocket: ~ubuntu-backporters (new)

 * Possibly other new ACLs for teams such as ~ubuntu-security, ideally
   replacing current hardcoded hacks in LP

Iain has filed for
this.  Does the TB think this is OK?

Option (1) is a reasonable fallback for the moment that still allows us
to reduce our dependency on shell access to ftpmaster (in fact, this
should allow us to drop our sudo access to lp_queue in the near future).
It's worth noting, though, that this will only work for archive admins
who are also core developers, and it still leaves archive admins
rubber-stamping the work done by backporters, often with a delay, rather
than just letting them do it themselves.


Colin Watson                                       [cjwatson at]

More information about the technical-board mailing list