[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: [PROPOSAL] Debian Release Plan
From:       Nathanael Nerode <neroden () twcny ! rr ! com>
Date:       2003-08-02 17:15:53
[Download RAW message or body]

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.  :-/


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[prev in list] [next in list] [prev in thread] [next in thread]