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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
-- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board