Readjusting SRU review process

Steve Langasek steve.langasek at ubuntu.com
Tue Jun 4 22:26:28 UTC 2013


On Mon, May 27, 2013 at 06:17:48PM +0200, Martin Pitt wrote:
> Steve Langasek [2013-05-24 13:19 -0700]:
> > 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.

> That's actually a very good point. It seems that over time we have
> become rather lenient about which kind of fixes we allow as SRUs. My
> gut feeling is that the current level is just about right for LTSes,
> but especially with the deemphasized role of the non-LTS releases we
> should perhaps set the bar much higher again for those?

I agree.

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

> We have done this in the past for cases where verification for other
> people proved hard/impossible, like for rare hardware. I don't think
> that self-verification is a bad thing when being documented properly.
> It's not even the primary concern for SRUs, as we most importantly
> need to avoid regressions in them, not necessarily be completely sure
> that all of the referenced bugs are 100% fixed (as we can always do a
> followup SRU).

> My feeling is that having fewer SRUs (for the non-LTSes) altogether
> would go a long way in raising motivation again; what's your feeling
> about this?

I think it will help some with motivation.  However, I'm not sure how to go
about achieving this result; for my part, pushing back on SRUs I think are
unnecessary doesn't seem to have had much impact on the overall flow of the
queue.  Do you have any suggestions?

-- 
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/20130604/7bc7a802/attachment.pgp>


More information about the technical-board mailing list