RFC: auto-generated packageset for Canonical OEM enablement metapackages
Robie Basak
robie.basak at ubuntu.com
Tue Aug 11 13:12:44 UTC 2020
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/devel-permissions/attachments/20200811/a466c3f4/attachment.sig>
More information about the Devel-permissions
mailing list