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
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
