Key Ubuntu teams should have an open process for new members

[Steve Langasek]

On Wed, Jun 14, 2023 at 10:48:15AM +0930, Alex Murray wrote:
> > 5. Another anecdotal fact, 
> > https://launchpad.net/~ubuntu-release/+members shows only 3 members 
> > added in the last 6 years and they are all coming from the Canonical 
> > Foundation team.

> > I've been told one new member is being onboarded which isn't from 
> > Foundations (but from another Canonical team) but I don't think that 
> > change the picture and it does look like people wanting their group to 
> > be the only ones to have control and reflect bad on the project (unless 
> > you believe we don't have members outside of Canonical-foundations that 
> > would be suited for the job or wanting to do it, which I don't think is 
> > true)

> I can't help but think that this (3 new members, all from Foundations)
> is either evidence of the (unintended) gate-keeping in action -
> ie. since there is hardly any documentation on how to become a release
> team member in this case (https://wiki.ubuntu.com/ReleaseTeam has
> nothing to say about this) the only way to become one is to be close to
> those who are already on the team - which is primarily foundations. Or
> perhaps it is just evidence that the foundations team are best placed to
> handle release team tasks etc.

As a member of the Release Team, the Foundations Team, and the Technical
Board, I am trying not to be too biased or defensive here; if I miss the
mark, please reel me in :)

As mentioned in my previous mail, we are trying to grow the Release Team,
and in the process we are also explicitly trying to diversify the
"affiliations" of the members of the team.

I take the question of gatekeeping seriously.  There is certainly no
*intention* of gatekeeping on the part of the Release Team, but impact >
intent.

I'll lay out what I see as the structural factors here.

First, what is the function of the Release Team?
https://wiki.ubuntu.com/ReleaseTeam is mum on this as well, so if I were to
define a mission statement, it would be:  The Ubuntu Release Team ensures
the delivery of high-quality Ubuntu releases on a predictable schedule.

In terms of the work involved, I would break this down into two categories.

- driving the release milestones (beta releases, GA, point releases)
- managing freeze exceptions, including reviews of the unapproved upload
  queue during archive freeze and unblocking of packages in
  proposed-migration.

The first of these requires the ability to commit a sizeable amount of time
in a block.  It is mostly infeasible to ask community members to commit the
necessary amount of time to "own" a milestone; it's even a challenge to get
engineering managers within Canonical to commit such a large block of time
for one of their engineers, which is definitely a factor in the makeup of
the Release Team being biased towards Foundations, because the buck stops
here.  Also, there are parts of the release process that are privileged and,
with the existing implementation, can only be done by a Canonical employee
(moving release images around on an actual filesystem).

Approving freeze exceptions does not require committing a large block of
time in order to contribute, nor does it require the same level of
privilege.  It's also something that, over the years, we have often
delegated to flavor leads (the actual queue management still has to be done
by a member of ~ubuntu-release).

In trying to grow the Release Team back to a stable size, we have primarily
been focused on the first of these points, because that's where lack of
impact of capacity impacts us most within the team, and where it's harder to
grow capacity.  I think Seb is concerned more about the second point.

For flavors, I would like us to be able to be able to delegate decisions on
freeze exceptions to flavor leads as much as possible, so the Release Team
is less of a bottleneck.  For Ubuntu Desktop and Server, however, I don't
feel that can be delegated; I think we members of the Release Team have a
responsibility to our employer around the delivery of these products, and in
the case of Ubuntu Desktop, many of the packages in main that the Desktop
Team maintains are also shared by other flavors.  So growing capacity for
this is still going to be slow, because even if we discount the need for
members who can commit to running milestones, the onboarding process still
basically looks like a full release cycle.


I don't know where that leaves us on the question of gatekeeping.  What do
you see that we could do to improve this process?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20230614/2f8c9d29/attachment.sig>