Core dev requirement for developer membership board seats?

Dan Streetman dan.streetman at
Fri Jan 17 19:48:28 UTC 2020

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.

> 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.

More information about the Devel-permissions mailing list