Merging SRU and release team, leaving

Steve Langasek steve.langasek at
Wed May 23 00:21:58 UTC 2012

On Tue, May 22, 2012 at 06:24:11AM +0200, Martin Pitt wrote:

> >  - Dilution of responsibility: if everyone is responsible, no one is
> >    responsible.  The finer-grained teams are a useful division of labor,
> >    helping to ensure that someone is responsible for day-to-day tasks.  Who
> >    is making sure we keep up on these tasks in the new scheme?

> I agree, we need to figure this out as a prerequistite, if and when we
> do the merge. To a smaller degree this is already a problem with the
> two existing teams, though (e. g. reviewing FFEs for ~release or doing
> SRU reviews for ~sru).

Well, it's because it's already a problem that I'm concerned about the
impact of merging the teams...  I think that will make the problem worse,
unless we have a specific plan to solve it.

> > I also don't see what problem we're trying to solve by merging the teams.

> I do not have a strong opinion about it, but it would simplify the
> structure a bit and provide a more even distribution of workload
> (assuming that we solve the "who is responsible today" problem), as
> well as increasing the chance of catching an active member on IRC.

I guess I don't agree that putting everyone in one pool results in a more
even distribution of workload.  It might play out that way, or it might
result in a subset of people now doing all the work for *both* sets of
tasks. ;)

It sounds like we aren't actually planning on levelling this out anyway
("Chris and Clint will focus on SRUs").  I think that's a good thing, but it
does call into question the rationale for merging the teams, IMHO.

> > I have certainly never gotten the impression that we're understaffed
> > on the ubuntu-sru team - the parts of the SRU process that actually
> > fall to the SRU team seem to be adequately covered, and where things
> > fall apart is for SRU verification.

> ~ubuntu-sru does not actually do verification. We expect users and in
> some cases ~sru-verification to do that. So far ~sru is reasonably
> well staffed, but if I'm leaving the team there might be a gap (I'm
> still doing the majority of processing at the moment). Also, Clint and
> Chris do not have cocoplum access, so they cannot process kernel SRUs
> which bump ABI.

Well, solving that would seem to require merging the SRU team with the
archive admin team, not with the release team.  Now that you mention it, I
do see this potentially being a big problem given that the kernel SRU
cadence needs an SRU team member to be available for this step in a timely
manner.  But we should really sort out on an individual level who will be
taking responsibility for this.  Maybe we'll find there are other volunteers
not on the release team who could help pick up some of the slack, too.

> > I don't think we need more SRU team members to accomplish that, I
> > think we need better enforcement of the SRU requirements (i.e., make
> > uploaders provide test cases before we accept packages).

> It sounds you would like to move the testing responsibility more
> towards Ubuntu's/Canonical's QA team?

No, not at all.  I'm saying that the SRU team should be enforcing the stated
requirements for the SRU process before we accept packages into
-proposed, as a gating requirement to prevent SRUs from getting in that
aren't actually going to get tested.  If we're consistent about applying the
rule, we can expect uploaders to comply, simultaneously reducing the SRU
team's workload and increasing our SRU success rate.

> > BTW, the etherpad for this UDS session
> > (
> > also says:
> > 
> >       - adding ubuntu-release to ubuntu-sru, and remove the other members
> > 
> > Do we really intend to remove Clint and Chris from the SRU team?  Why?  As I
> > understand it, they're the two most active members of the SRU team right
> > now...

> The idea was certainly to add them to ~release instead, but they would
> continue to focus on SRUs.

Have they been warned what they're signing up for? ;)

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                          
slangasek at                                     vorlon at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <>

More information about the Ubuntu-release mailing list