Unblocking SRU uploader permissions

Thu Feb 2 10:41:55 UTC 2017

Hello,

Le 02/02/2017 à 08:09, Robie Basak a écrit :
> 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)
> 
> 
> 

Maybe I can share my experience, both as a member of Canonical's STS engineering
team, and as a Coredev that had to follow the full path.

Beforehand, let it be clear that Canonical's customer requirements are
independent of how the Ubuntu community should proceed. It is also important to
outline the fact that bug fixed following requests by Ubuntu Advantage customers
become available to the whole Ubuntu community through the SRU process.

My own motivation behind becoming a core developer was two fold :

 - Help out shorten the SRU turnaround time for our UA customers by having
   upload rights to the SRU queues. I am able to sponsor my teammate's SRU,
   foster best practices through sponsoring and teach Ubuntu development and
   debian packaging to colleagues who may eventually become interested in
   further participation.

 - Participate in the development of the Ubuntu distribution. I am also
   Debian Maintainer of a few packages, have done a few merges, helped out
   on FTBS and community bug fixes. I am also actively working on the
   development of sosreport and kdump-tools.

Only the later motivation requires full core dev upload rights.  Uploading to
the SRU queues also mean that further review will be done to the upload, a
stricter testing scheme will happen. In short, there will be more eyes on the code.

I also don't see any immediate requirements for being fluent in merges, builds
and the whole development ecosystem if only speeding up SRU resolution is the
ultimate goal. A expert understanding of packaging, upgrade path, testing and
regression is to be expected in order to respect the stable nature of the
releases. In other words, someone with upload rights to the stable releases
should be more concerned about the impact of our users and how their SRU upload
will impact the existing userbase than the enhancement of existing functionalities.

The Per-Package Upload rights already exist. Maybe enhancing this nomenclature
to add SRU queue upload rights would be sufficient. I also think that being at
least an Ubuntu Contributing member would allow for a minimal level of
understanding of the Ubuntu community requirements in order to gain access to
such rights.

Along with Robie's analysis, I don't think that going through MOTU is of any use
for STS engineering requirements, as we rarely touch Universe package. In those
cases, the standard sponsoring method is more than adequate.

HTH,

Kind regards,

...Louis

-- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer                       Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20170202/1500e042/attachment.pgp>