Merging SRU and release team, leaving

[Clint Byrum]

Excerpts from Steve Langasek's message of Tue May 22 17:21:58 -0700 2012:
> On Tue, May 22, 2012 at 06:24:11AM +0200, Martin Pitt wrote:
> > > 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.

It certainly does sound like this is just a way to perhaps get more
people to chip in to the SRU team's work than a way to even out the
load. I have to agree that I'd rather see some more people sign on to
the SRU team than merge the teams. I don't really have the bandwidth
to do any of the things the release team is expected to do. I'm already
pretty bad about hitting the SRU queues more than once a week.

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

I've been somewhat consistent about requiring that there be a TEST CASE
in the bug description, and usually the full Impact and Regression
Potential as well. I definitely let it slide more than I should, and
I think we as a team should probably be more forceful about having the
required fields in the bug description before accepting.

I'd be interested in doing some analysis on past SRUs to see how much
more successful bugs w/ a TEST CASE are than those without.

> > > BTW, the etherpad for this UDS session
> > > (http://summit.ubuntu.com/uds-q/meeting/20699/other-q-release-team-meeting/)
> > > 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? ;)
> 

This thread was the first I heard of the team merge.