Paul Wise <p...@debian.org> writes: > On Fri, May 10, 2013 at 3:49 AM, Lars Wirzenius wrote:
>> * Keep testing free of RC bugs. > I keep packages I (co-)maintain free of RC bugs. The point isn't what individual developers do, particularly developers who are extremely well-engaged with the project. The point is to find ways to do this at another level up. Obviously, given the number of RC bugs that we had to fix *after* the freeze, this isn't already being done at the level required for a timely release process. I don't think we can solve that problem by saying "well, developers really *should*." >> * We should limit the number of packages we strongly care about for >> a release. > I don't agree with this. Care to expand the thought? >> * Remove RC buggy packages sooner rather than later. An RC buggy >> package should be removed at soon as possible: when the bug > The release team already do this using a semi-automated method. But by and large they only do this on a large scale during the freeze, at which point, in a way, it's too late. We've already built a huge backlog of work, and everyone is anxious to release. I think we should be doing this continuously during the release and much more aggressively than we've been willing to do in the past. I suspect, though, that mini-freezes whenever the RC bug count rises above a certain level will be as effective or more so, since I know that package removal very quickly involves deeply tangled dependencies, and one has to sometimes remove vast swathes of packages to remove a particular RC-buggy package. >> We should have an explicit list of such reference installations and >> declare them as crucial for the release: > How about: > all the tasks > all the blends That's certainly a good start, although I think it's worth asking the blends maintainers whether all of the packages they include are release-critical. I don't think it captures all of the interesting use cases, though; there are common patterns that we want Debian to support that aren't captured in a task or a blend. >> if they work, we can release, and if they don't, we can't. > How would you define "work"? > Presumably: no RC bugs, no piuparts issues? I would limit it to just no RC bugs (and therefore no test failures where we're pretty sure that test failure would indicate an RC bug). If we feel that piuparts is testing things that should be RC, that would certainly include piuparts. Bear in mind, however, that the core problem is that we don't keep testing sufficiently free of RC bugs to be able to release in a timely fashion after a freeze. That means we're not dealing well with the bugs we already have, so I would be a bit hestitant to create new classes of RC bugs until we have that situation under control. While looking for new classes of bugs is something that we should always be open to, I think the most important step is to try to catch the bugs we were already catching earlier in the process and to be more aggressive about dealing with them. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc6qrh7k....@windlord.stanford.edu
