On Thu, Feb 02, 2017 at 07:09:57AM +0000, Robie Basak wrote:
> 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?
MOTU shouldn't be required for coredev applications and we have quite a
few examples where non-MOTU got coredev status in the past.
That being said, it is expected that coredev have broader experience
than SRU-only and I'm not suggesting that we lower that standard.
> * 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?
We can create an ACL which allows archive upload to all released series.
That'd be identical to the "ubuntu-sru" ACL but for upload rather than
queue admin.
> * 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.
Right and that seems to me like the way to go to deal with those applications.
> 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)
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
