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
signature.asc
Description: Digital signature
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
