[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Questions to all candidates: Release importance, release blockers, release quality



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.

Attachment: signature.asc
Description: Digital signature


Reply to: