Wednesday 1 February 2017

Unblocking SRU uploader permissions

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)