On Tue, Feb 27, 2007, Steve Langasek wrote: > > * we announced a bogus release date. I know not everyone agrees on > > who is responsible for that announcement, > > Who do you believe is responsible for that announcement?
The story as I understand it is that the press team slightly changed the release team's "12/4 confirmed as a realistic date" estimation to "12/4 confirmed as a release date", and apparently few efforts were made to take it back. > Only after the freeze is it possible to do certain kinds of systematic QA, > such as checking for build failures within testing. Have you taken that > into account when deeming that a decline of 10-20 bugs over two months > indicates too early of a freeze? Have you factored in the introduction of > new RC bugs into testing without detection, prior to the freeze? I was aware of all these parameters, but their potential impact on the RC bug evolution was all but clear. Again, I would have loved a graph of newly found bugs, downgraded ones, bugs fixed by a transition to testing, etc. to know the trend for all variables. And since our target was 0 RC bugs /in Etch/ I was under the impression that we should focus on the RC bug count /in Etch/, which was the main reason why I thought freezing at 116 bugs in Etch while it was planned to do it at 80 was a bit too early. > > I do think a release of high quality is more important than a timely > > release. However, I also think it should be possible to stick to a given > > date (with the usual two-month buffer, of course). > > If you think there's a "usual two-month buffer" that applies to release date > targets, why, before we'd even reached the original target release date, > were you publicly mocking the release team's efforts in your blog? My first "stress-o-meter" blog post was only four days before the target release date, but it was also two weeks after you announced the installer release process was three months behind schedule. And a quick look at sarge's RC bug graph made me foresee a 3- to 5-month delay. That said, a buffer does not mean we should no longer care about the schedule (like we more or less did) if the deadline is missed. The workplan should be updated to make up for the delay, priorities should be shifted and goals reconsidered. Unless of course we no longer care about the release date. > I appreciate your support as a maintainer in dealing with release-critical > bugs that affected your packages. But why should anyone who cares about > Debian's stable releases vote for you if that's the sort of support you're > going to show for the release team as a public figure? I know I hurt a few people with my blog entries (though I should mention I also got much positive feedback from people who were happy to have fun in an otherwise frustrating atmosphere) and I am sorry about that. It was my way not to leave the project during the dunc-tank controversy (for about a week I considered resigning). However, my platform says I'm serious, and I am not going to mock the release team or any of our teams as a project representative. > > By dealing with RC bugs by popularity contest instead of date or bug > > number, we can reach a higher quality faster. > > Judging by the number of people who stepped forward to help with the > release-critical bugs on the kernel, I guess the kernel isn't very popular > with developers. Is that the popularity contest you mean? No, by popularity contest I mean popcon.d.o: focus on bugs in packages that affect the most people first. Or did I misunderstand your objection? I hope I don't look like I dodged any questions. Let me know if I have been inaccurate. Regards, -- Sam.
signature.asc
Description: Digital signature
