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