Merging SRU and release team, leaving

[Brian Murray]

On Wed, May 23, 2012 at 01:28:03AM -0700, Clint Byrum wrote:
> 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.

I'm happy to do this work but how would you define success?  A quicker
turn-around time?  The package not being removed from -proposed?

Actually, how would we find the bugs that never had been verified and
the package removed from -proposed?

--
Brian Murray
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20120523/edb3b1ba/attachment.pgp>