Core dev requirement for developer membership board seats?

Mauricio Oliveira mauricio.oliveira at
Mon Jan 20 13:23:48 UTC 2020

On Fri, Jan 17, 2020 at 4:49 PM Dan Streetman
<dan.streetman at> wrote:
> On Fri, Jan 17, 2020 at 9:38 AM Robie Basak <robie.basak at> wrote:
> >
> > On Fri, Jan 17, 2020 at 09:18:51AM -0500, Dan Streetman wrote:
> > > The SRU process is most certainly not 'narrow' ;-)  It covers the vast
> > > majority of what coredevs need to know, at least IMHO.
> >
> > I disagree.
> It's ok for us to disagree.
> Since there have been significant issues in the past both with finding
> applicants to join the DMB, as well as reaching quorum during the
> fortnightly meetings, perhaps it would be prudent to open the
> eligibility pool to include ~ubuntu-sru-developers, but ask them to
> abstain from voting (or at least refrain from casting the deciding
> vote) when evaluating a candidate for ~ubuntu-core-dev.
> Additionally, based on history it seems quite likely that anyone
> joining the ~ubuntu-sru-developers team will move up to
> ~ubuntu-core-dev afterwards, and since the DMB membership period is
> currently (at least) 2 years, it's quite likely any
> ~ubuntu-sru-developers DMB member(s) would join ~ubuntu-core-dev
> during their term.
> After all, there have only been 3 members of ~ubuntu-sru-developers
> ever, and 2 of them joined ~ubuntu-core-dev (the last one joined
> ~ubuntu-sru-developers about 2 months ago).
> In any case, it seems currently entirely academic whether eligibility
> includes, or doesn't include, ~ubuntu-sru-developers members, since
> there is only 1 single person who is both a ~ubuntu-sru-developer but
> not a ~ubuntu-core-dev.  If he is in fact interested in applying for a
> DMB position, he can certainly speak up.

I'm not immediately interested in applying for a DMB position before
acquainting myself more with some other areas and processes in Ubuntu.

However, if suggestions for the process are welcome, at least on the
topic of quorum to vote for applicants, maybe a non-coredev can vote
for non-coredev nominations.
e.g., an sru-dev can vote on sru-dev nominations, as the
nominated/approved SRU developer should theoretically have the
knowledge for questions to/votes about the SRU developer applicant.
And of course, this could be extended for other permissions, e.g.,
folks with package upload rights could vote on other folks applying
for package upload rights, etc.

This might help with nominations for upload rights < coredev.


> >
> > Core devs and MOTUs need (at least) to be able to do package merges,
> > understand[1] the development release cycle, freeze milestones and
> > exception processes, proposed migration and transitions, and the
> > main/universe split and how it affects dependencies. Core devs
> > additionally need to understand[1] seed handling and MIRs.
> >
> > SRU developers don't need to know anything about those areas, nor even
> > know that they exist. When considering an SRU developer application, I
> > don't consider any of these areas. In fact that was the point of
> > creating the SRU developer team: to allow developers to make progress
> > _without_ having to learn or demostrate the wider stuff.
> >
> > [1] I don't necessarily expect detailed direct experience in all of
> > these, but I do expect to see direct and deep experience of at least
> > some of them and a general understanding of most of them.

Mauricio Faria de Oliveira

More information about the Devel-permissions mailing list