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

Re: [PROPOSAL] Debian Release Plan

Matt Zimmerman said:
>I disagree. If I'm not mistaken, this is the definition of an RC bug. >If
>the package has an RC bug, it is not releasable.  If there is an RC bug
>which does not imply that the package is unreleasable, it has been >assigned
>the wrong severity.

So you're saying bug #196564 should be downgraded then? I don't think that *possibly* causing a segfault in another package (it's not clear that it still does), on *one* architecture (m68k), when it's *probably* a toolchain issue, and the m68k people don't have the time or interest to reproduce it or track it down, should imply that the package is unreleasable!

For that matter, I can't seriously believe that new XFree86 should not be released because of bugs which are pre-existing in old XFree86 (#143825, #185936, #190323). This is actually a *very* common problem; a lot of RC bugs existed in older (released) versions, and so shouldn't be considered blocking if they happen to still be present in newer versions, but the 'testing' scripts don't realize this because the bugs weren't *reported* earlier. (Actually, rumor has it that there's a 'sarge-ignore' tag available now, which may do the right thing for supposedly RC bugs which shouldn't really block release; I don't know much about it though.)

Also, you're not taking dependency issues into account. You're also not taking architecture differences into account. KDE 3 has been releasable on i386 for a long time. It has been held up by toolchain issues on various other architectures, one at a time generally.

Perhaps the time has come to reconsider the requirement that, to be releaseable, all packages must be release-ready on all 11 previously-released architectures, and in sync on all 11 architectures. That's a lot to keep in sync, especially when upstream doesn't care about some of the architectures. :-( Of course, there are already options individual maintainers can use to deal with such issues, such as declaring their packages to be non-m68k or non-s390 (for instance). Perhaps this should be used more aggressively. :-/

Reply to: