Unblocking SRU uploader permissions

[Robie Basak]

I'm writing to ubuntu-devel with my DMB hat because I'd like to hear the
opinions of existing Ubuntu developers.

Eric and Dave both work for STS - Sustaining Engineering (L3 support), a
department within Canonical. They've both applied to the DMB recently.
Both are motivated primarily by the need to drive SRUs without
unnecessary review queue delays. Right now, they get blocked on needing
sponsorship for most of their work. What should be the path that we
suggest to STS staff who have the goal of no longer needing sponsorship
to drive SRUs?

For background, STS (Support and Technical Services) is responsible for
handling Ubuntu Advantage customer support requests. Most of their
contributions to Ubuntu are in the form of SRUs. The majority of these
SRUs are in main, but across desktop, server and cloud packages, and
include more "core" packages in no packageset. Currently, to fulfil the
STS goal, they either need sponsorship or need to be core devs.

If the answer is that they need to be core devs, then the problem
becomes "what is the appropriate path to get to core dev"? One
expectation seems to be to get MOTU first. But MOTU doesn't seem like
the right path to me. We get applications aiming down this path (like
Eric's), but universe uploads aren't really the goal for these
applicants. Being able to drive SRUs is the goal. It seems inappropriate
to me to force applicants to contribute through some fundamentally
unrelated path to get to their goal of directly driving SRUs. We don't
force other Ubuntu contributors to contribute in area B before they can
upload directly to unrelated area A. I think we should find a way to
allow proven contributors to area A to do that directly.

My understanding is that traditionally a large influencer of a DMB
decision is the consideration of what a successful application would
unblock. If a contributor is doing good work, we want to get out of the
way. So we'd usually grant an application for uploads in a particular
area if endorsers and other relevant people are happy with the
applicant's track record in that area (on quality, understanding of
process, team cooperation, etc). Conversely, not having a track record
of uploads in an area, or not having the intention of continuing uploads
in that area, has generally always been seen as a red flag. The one
exception is in the case of an application from the social aspect, but
this is rare and doesn't apply to my question today.

For this reason, I've been reluctant to vote to award core dev to
applicants with experience mainly limited to driving SRUs, or to vote to
award MOTU without seeing a corresponding level of contributions to
universe. This makes me quite torn with both Eric and Dave's
applications. I think that the quality of their SRUs is high, and think
that they should be able to upload SRUs directly (as well as their fixes
to the development release). But since they don't have a great deal of
experience apart from SRUs, I'm not sure if I should vote to grant core
dev to achieve this.

In my experience, STS staff are generally very good at understanding and
driving the SRU process well. To me, it's clear that if an individual
applicant has a proven track record of high quality sponsored SRU
uploads, it should be a no-brainer for the DMB to grant the applicant
the ability to upload further SRUs without sponsorship. Not doing so
blocks progress. I distinctly remember the pain of the triple wait
between the sponsorship review queue, the SRU review queue and the SRU
verification aging period. And how that increased time increases the
risk that a security upload will trump the SRU and the whole process
will have to go round again, which IIRC happened to me multiple times.

How should we unblock SRU sponsorees and get ourselves more SRU
uploaders? Some points for discussion:

* Is the DMB asking for too much from applicants before granting core
  dev and/or MOTU?

* Should we just give this category of applicants core dev, on the basis
  that we trust these applicants won't upload in other areas without
  seeking advice first? Though in that case, why does the DMB enforce
  per-package-group limits using ACLs at all? Why don't we make all
  successful applicants in any area core devs and ask them all to
  self-police?

* Should we require them to have some wider experience, but less than we
  might for a more generalist core dev applicant, on the basis that
  we're bending to unblock the SRUs as we have no other suitable ACL
  method? In other words, because we don't have an SRU-specific upload
  ACL, should we lower the bar to make progress?

* Should we maintain the bar and require potential SRU uploaders to
  obtain a more wide breadth of experience appropriate for a core dev,
  and only then grant them core dev to unblock their SRU uploads?
  Perhaps requiring them to go through MOTU and make substantial
  contributions to universe, or through other more limited packagesets
  first?

* Based on the tooling the DMB uses to grant upload access, it seems to
  me that Launchpad may be able to allow the DMB to adjust ACLs to
  permit upload to stable releases but not the development release.
  Would this work? It wouldn't help with the initial development release
  upload often required in an SRU, but would help with the subsequent
  SRU uploads, so would at least relieve some of the burden.

I'd appreciate feedback from the wider Ubuntu developer community on
what the DMB should do here.

Thanks,

Robie (acting for himself as a single DMB member)
-------------- 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/ubuntu-devel/attachments/20170202/174b29a9/attachment.pgp>