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: