RFC: auto-generated packageset for Canonical OEM enablement metapackages

Iain Lane laney at ubuntu.com
Tue Aug 11 13:56:59 UTC 2020


Thanks Robie and DMB. This is a step forward, much appreciated.

The script - or the purpose that drives my wanting it - is quite an 
important part of the proposal to me, because new source packages 
(equivalent to newly-enabled lines of hardware) are going to be one of 
the most frequent calls upon this OEM procedure, and I want that to be 
able to be self-served by the team that is driving the enablement within 
Canonical.

We can discuss how this should work in detail though, that's fine by me.  
I'd be happy to write a script and then hand it over to the DMB to run 
(on a timer), for example. I can imagine various safety guards 
additional to that, like the script emailing its modifications to this 
list.

Maybe we should take this thread in the direction of how to manage the 
packages contained in set now.

Cheers!

On Tue, Aug 11, 2020 at 02:12:44PM +0100, Robie Basak wrote:
> The DMB agreed to create the packageset at yesterday's meeting and I've
> now requested this action from the TB[1]. I've also created
> ~canonical-oem-metapackage-uploaders which will be the sole uploader for
> the packageset.
> 
> Rereading Iain's original request, I realise now that he did
> specifically want a script to automatically drive it from a staging PPA
> as a way of working around sponsorship for the first upload of a new
> package. Presumably this is the common case? We didn't agree to do this
> yesterday, but I've proceeded with what we did agree anyway as it's
> progress either way.
> 
> I'm not keen on driving automatic packageset modifications from a staging
> PPA outside the control of the DMB. It seems like it might lead to
> surprising or unwanted behaviour to me, even if I can't think up a
> specific case right now. I accept it might be what we have to do though
> in order to reduce friction.
> 
> [1] https://bugs.launchpad.net/ubuntu-community/+bug/1891166
> 
> On Fri, Jul 17, 2020 at 11:49:37AM +0100, Iain Lane wrote:
> > Hi,
> > 
> > A few of us at Canonical have recently been working on a project to 
> > enable people who buy Ubuntu-certified devices to have the "certified 
> > experience" whether they bought the device with Ubuntu preinstalled or 
> > installed Ubuntu later.
> > 
> > The way we've designed this is that parts of the installer / live 
> > environment / etc are able to match the running hardware and install a 
> > metapackage from the archive, that then goes on to do the necessary 
> > setup. We have an exception from the MIR team to allow these packages to 
> > be auto-promoted into main. This page also explains a few more technical 
> > details about how the packages work (they are rigidly/mechanically 
> > structured):
> > 
> >   https://wiki.ubuntu.com/MIRTeam/Exceptions/OEM
> > 
> > We've got a bit of a scaling problem here though. There is *one source 
> > package per SKU*. The way that Ubuntu's ACLs are set up is that 
> > membership of the ~motu team /or a matching packageset|PPU permission/ 
> > is required to be able to upload NEW source packages to the archive. The 
> > team that develops these packages is not really made up of Ubuntu 
> > developers, and so currently they are forced to hand over the packages 
> > to a sponsor who is in ~motu, which is a burden on the sponsors that it 
> > would be great to be able to relieve soon.
> > 
> > As a first step towards making this self service for that team, I'd like 
> > to ask the DMB to consider making a packageset for this purpose.  
> > Initially it'll have no uploaders apart from ~ubuntu-core-dev, so we're 
> > considering the set itself only right now. (Later on we'll be nudging 
> > people to apply to you for upload rights.) The Launchpad team tells me 
> > that packageset permissions can be added if a source package exists 
> > *anywhere* (i.e. in a PPA), not just in Ubuntu. So there would be a 
> > script which enumerates a staging PPA and adds packages found there 
> > which match the glob 'oem-*-meta' to the packageset. Then the eventual 
> > workflow would be to upload to the staging PPA, wait for the script to 
> > fix the packageset, and then they can copy/upload the package to devel 
> > and SRU it to the relevant releases.
> > 
> > The name could be something like canonical-oem-metapackages and the 
> > description along the lines of:
> > 
> >   Metapackages provided for hardware enablement for Canonical-certified 
> >   devices. This set is auto-generated by the script found at XXX.  
> >   Packages which end up in this set must at all times comply with the 
> >   MIR exception specified in 
> >   https://wiki.ubuntu.com/MIRTeam/Exceptions/OEM
> > 
> > Keen to hear your thoughts.
> > 
> > Cheers,
> > 
> > -- 
> > Iain Lane                                  [ iain at orangesquash.org.uk ]
> > Debian Developer                                   [ laney at debian.org ]
> > Ubuntu Developer                                   [ laney at ubuntu.com ]
> 
> 
> 
> > -- 
> > Devel-permissions mailing list
> > Devel-permissions at lists.ubuntu.com
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/devel-permissions
> 



-- 
Iain Lane                                  [ iain at orangesquash.org.uk ]
Debian Developer                                   [ laney at debian.org ]
Ubuntu Developer                                   [ laney at ubuntu.com ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/devel-permissions/attachments/20200811/bcc62f07/attachment.sig>


More information about the Devel-permissions mailing list