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