On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote: > Michael Gilbert 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.
I am not saying that is going away with jessie. In fact, I am totally expecting another 400-500 serious or more piuparts bugs. The reason that I mention that as the biggest issue is that for one the concerted effort to report all of those bugs is new, and could possibly be identified as the catalyst for the +4 months compared to squeeze. That is why I think the automated testing infrastructure needs to be implement (as soon as possible) this cycle, in order to keep all piuparts-broken packages from ever migrating to testing, resulting in a later large amount of the rc count. >> 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. People just spent 10 months fixing issues in packages that were not their own. I don't think they want to be pulled away from the fun stuff so quickly. > 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. That would be good. >> 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. But those shouldn't affect testing yet, right? All of that stuff needs staging in unstable first. Are bug filers not tagging their reports correctly? If so, that's quite misleading, and actually should be quite easy although tedious to fix. Best wishes, Mike -- 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/CANTw=MMMXsirPPYLbhSe3Nwf5wEkb=5cdt5As=j3dmfy+bc...@mail.gmail.com
