On Wed, Jun 01, 2005 at 12:27:08AM +0200, Adrian Bunk wrote: > On Tue, May 31, 2005 at 04:29:31AM -0700, Steve Langasek wrote: > > On the contrary, I found your answer reasonably satisfactory, and as a > > result had postponed replying to you in favor of dealing with more directly > > pressing release issues. > > You indicated that as of two weeks ago, you'd been through the "middle > > seventh" of update_excuses checking for unidentified RC bugs, and that most > > of the packages below this range were not in testing and therefore wouldn't > > hold many hidden RC bugs; and I've been tracking the status of RC bugs > > closed since the freeze began, which accounts for many (though not all) of > > the more recent uploads. > What's the current number of RC bugs you've tracked this way? I haven't distinguished between RC bugs tracked this way, and RC bugs tracked by other means. The complete record of packages I've hinted into sarge since the beginning of the freeze is available at <http://ftp-master.debian.org/testing/hints/vorlon>. > Am I right to assume that you count them when looking whether you reach > your 15 RC bugs in your metric you want to achieve today? The existence of such closed-but-not-finished RC bugs was factored into the estimates of how many open RC bugs we needed to be down to at each point in the timeline. > Why are there always extremely aggressive timelines (with at least three > publically announced release dates for sarge already passed) instead of > making everything more relaxed for being able to improve sarge without > being in a big hurry? I think you're the only person on the planet arguing that sarge's release cycle should be slower... There is always room for improvement, but you have to decide which axis you want to improve on. Do you want a release, or do you want a perpetual freeze that asymptotically approaches perfection because there's always one more RC bug to be closed in one little package that has a userbase of a dozen or less? This is the tradeoff of hunting down all the RC bugs that have been reported in the BTS. It's a diminishing-returns tradeoff, and I don't think the decision we're making is the wrong one. > > For my part, I have explicitly *not* given a free pass to packages with RC > > bugs that were filed a long time ago but only recently raised to their > > proper severity. It's great if bug submitters know what severity a bug > > should be filed at, but it's the *responsibility* of the maintainer to > > adjust the severity if it's wrong -- even if that means raising the > > severity, something none of us want to do. Even more, it's the maintainer's > > responsibility to *deal with* such bugs at the proper severity even if they > > were filed wrong. It simply can't be the responsibility of any central > > group to babysit the severities of bugs filed: that's not scalable in the > > least. > > > > So yes, sarge will ship with bugs that should have been considered RC. But > > this is inevitable in any case because of the many RC bugs that are never > > *identified* by our testing, so there's no reason for the release team to > > treat these bugs as blocking issues if no one cares enough to make sure > > they're brought to our attention. This doesn't mean that your work to > > identify overlooked RC bugs is any less valuable, Adrian, or that I'm any > > less grateful to you for it (in spite of the visceral irritation sometimes > > at seeing the bug count moving in the wrong direction ;). It just means > > having a pragmatic, big-picture view of what it means to release, and > > whether the improvement to sarge is worth it to our users every time we > > delay another week to fix a handful of bugs. After all, let's not forget > > that sarge is already quite good, and nothing to be ashamed of! > As said above, I still don't see why such a hurry was required. > Yes, woody is completely outdated. But a few weeks more or less until > sarge is released doesn't make the big difference. Well, I'm sorry, but whereas it may not make a big difference to most of our users or developers whether the release is delayed by a few weeks, as the one in the hot seat, a prolonged freeze does have a significant impact on *my* quality of life. Keeping up on the status of RC issues, coordinating with maintainers, coordinating bugfixers, submitting packages, doing NMUs, reviewing and/or handholding packages containing fixes that need to get into the release, watching one autobuilder after another off-line itself due to hardware issues and trying to manage the resulting increase in pending issues, getting the timing right so that all the teams involved in a release can be available to do their part at the right time in the right order, making sure that none of the last-minute problems (there are *always* last-minute problems) derail that timing... I challenge anyone to do volunteer release management for a project with Debian's size and complexity and come away with the opinion that longer freezes are a good thing. I'm sure that there have been cases where my own inexperience has led me to take more work on directly than I should have; but I don't think this is so great a factor that it invalidates the underlying sentiment. > And if 6 June 2005 will be the fourth missed officially announced > release date for sarge the negative effect on the reputation of Debian > will most likely be bigger compared to the situation if you'd have > planned and announced a longer freeze. Anyone who can't distinguish between an "officially announced release date" and a projected target release date isn't worth wasting my breath on. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature