Michael Gilbert <mgilb...@debian.org> writes: > I disagree that there is something fundamentally wrong with how > development is done. The primary problems with this cycle were that > there were something like 400 or 500 extra rc bugs due to a concerted > effort to report all serious issues found via piuparts, and then the > existential problem of not enough rc squashers, which in and of itself > is not all that rewarding.
This is what we say every release, for various values of "piuparts" (archive-wide rebuilds, license audits, etc.). And then every release we have the same problem. Let's be sure that we're not just trying the same thing over and over again and expecting different results. > A certain freeze length is inevitable simply because it takes a certain > time minimum for people to test and find all of the significant > compatibility issues with the set of software chosen to be a part of the > release. Debian's high quality standard cannot be met with a two-week > testing period. Somewhere between 3 and 6 months is much more > reasonable. Six months would be an improvement, but I think it's still much too long, long enough to have negative distortive effects. I think three months is a better target to aim for. (That said, if we could reliably get the release freeze down to six months, that would certainly be a worthwhile improvement.) > There are simply too many rc bugs all the time. Jessie is already over > 500 after one week of development: > http://bugs.debian.org/release-critical Right. Which is why we should immediately (for definitions of immediately that involve the release team taking a much-deserved break, but not for definitions of immediately that mean "six months from now") freeze testing again until we're back down under 50-100 RC bugs, whether via fixes and transitions or whether by kicking out a bunch of packages. Now is also the ideal time to kick packages out of testing so that people are aware that they're in trouble very early in the release cycle. We always have this surge immediately after the release, but we don't stomp on it immediately. We therefore get up to 1000 RC bugs before we know it, and never get back on top of them without a long and horribly painful freeze. > That, I think is the real problem. How did testing go from a minimal > (70-ish) rc bug wheezy release to over 500 in one week? Why didn't > britney prevent the migration of all those rc-buggy packages? Because they're not from migrations. They're from transitions. They're all the "this is going to break with a new version of libc6" and the like bugs that were filed before the release at priority important and were mass-upgraded after the release. This is fine and normal, but it means that we should not now be diving into all new upstream, all the time development immediately. We should stop, take a breath, work through these transitions first, get that RC bug count down to something releasonable again, and then tackle the next thing that surges RC bug counts. That's going to require some discipline. We know from long experience with the release process that we can use the bully pulpit until we're blue in the face, but this is a huge project with a lot of developers, many of whom just don't read mailing lists. People will keep uploading unless we put something in place that actually prevents them from doing so, such as freezing testing migration right now except for pre-arranged transitions and RC bug fixes. (It's quite possible that, to implement this properly without drowning the release team in work, we'll need better tools to manage that sort of freeze and migration process.) -- 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/87sj1sdpvs....@windlord.stanford.edu
