Readjusting SRU review process

[Steve Langasek]

On Fri, May 24, 2013 at 08:04:53AM -0700, Brian Murray wrote:
> On Mon, May 13, 2013 at 11:18:01PM +0200, Martin Pitt wrote:
> > Hello SRU team,

> > the Tech board recently received a proposal to forego the review of
> > -proposed uploads and directly accept them into -proposed:
> > https://lists.ubuntu.com/archives/technical-board/2013-May/001613.html
> > https://lists.ubuntu.com/archives/technical-board/2013-May/001618.html

> > In today's TB meeting there was unanimous agreement that this is not a
> > flaw in the defined SRU process, but a flaw in its execution. We do
> > not want to give up peer review for what goes into stable releases,
> > and rather want to address the workflow problem in the SRU team. Does
> > that match your feeling as well, or do you feel differently?

> > There are obviously problems with getting timely reviews at the
> > moment: many items in the precise and quantal queue are one to two
> > months old already, and even raring's queue has rather simple SRUs
> > which are already three weeks old.

> > It seems the regular reviewing days got dropped some time ago. How is
> > the reviewing process currently meant to work, and what do you see as
> > the reasons that it doesn't? Would reintroducing regular review days
> > help against them never turning into your focus otherwise, or have
> > they been ineffective as well? Mabye the team is even too big now for
> > anyone to feel sufficient responsibility for doing reviews?

> While I'm not personally affected by this too much, I can imagine that
> it is demotivating to some SRU team members to spend time reviewing
> debdiffs and SRU bugs only to have the package sit in -proposed
> unverified for weeks.

There are definitely times when I have a sense that the SRUs in the queue
are not the best use of our time.  Every developer has their own idea of
what's important enough to SRU, and it's difficult as an SRU team member to
be in the position of arbitrating, and rejecting uploads because /you/ don't
think they're important.  It's also difficult to actually /know/ what's
important enough for an SRU when it's sitting in front of you in the queue -
some of this only shows up in aggregate after the fact, when we see that
-proposed is full of packages that no one has bothered to verify.

We've tried to mitigate this with stricter enforcement of the requirements
around test cases, but it seems there is still a big gap between the
resources for preparing SRUs and the resources for validating them.  Maybe
we need to start pushing for self-verification of SRUs more aggressively?
With defined test cases, this is less risky than in the past, and if SRU
uploaders were explicitly expected to do the verification (if no one else
does), then that could help reduce the problem of fire-and-forget SRUs
clogging up -proposed with no one to verify them.

-- 
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                                    http://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: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20130524/eb90ec77/attachment.pgp>