[(Hopefully) obvious caveat - I am a member of neither the ftp team nor the release team. The following is personal opinion and observation - if you want an official answer, ask someone official]
On Mon, 2006-12-04 at 21:21 -0800, Thomas Bushnell BSG wrote: > On Tue, 2006-12-05 at 00:44 +0000, Adam D. Barratt wrote: [...] > > The main reason for doing so that is that the ftp team (at least those > > regularly processing removals) don't use severities for that processing. > > Curious. Why not? It seems to me that developers are not just random > in the severities they assign (and they can be changed by helpful bug > triagers when they are wrong!) It seems to me that such information > would be helpful. I've always presumed that it's due to the key word "release" in release-critical, and how that affects testing and unstable. If a bug is sufficiently "bad" to prevent the package forming part of the next stable release then the package needs to be removed from testing in case that were to become stable before the package was fixed. Conversely, the presence of the package in unstable (and/or experimental to a lesser degree) is purely a matter of whether the package should be present on Debian's mirrors. There are a very small number of situations (e.g. incredibly nasty licencing issues) that could lead to a package needing to be removed from Debian entirely very quickly. On the whole, however, that's not the case. Removing packages from unstable and letting the change propagate to testing is one means of ensuring the package is not in the release but it's not the only, nor necessarily the best, method of achieving that. Partial removals tend to be processed more regularly and speedily than full removals as the release team doesn't have the option to remove the individual binaries from testing themselves (or if they do they won't use it). In a majority of cases the first step in that processing involves gathering more information from the maintainer - e.g. why the regression in architecture support has occurred, what steps have been taken with regard to asking porters for help fixing the regression. They're more of a grey area than full removals, but I'd still argue they're not RC as it /is/ possible to fix the RC bug via a full removal from testing - it's not pretty, but it's possible. (Not that I'm suggesting that it should be done, just that it can be). > > In fact, as has been pointed out by Steve himself and at least one other > > member of the release team (on IRC, admittedly), removals from unstable > > can (almost) never be release-critical. > > In this case, actually, I think it is. [...] > It is extremely unclear to me if there is any other way to communicate > this message besides bug severities. That is, at any rate, the standard > way to communicate such information. Is there some other way, or are > the relevant people just entirely unconcerned the relative urgency of > various requests? In my experience, 95% (at least) of removals could just have legitimately have been filed at wishlist rather than normal or higher. If one of the few that remain affects a package or transition that the release team is concerned about or would like to be fixed more rapidly than it would otherwise be then a member of the release team will ask an ftp-master/-assistant to do so. The key point is that removals from unstable aren't release- or time-critical for the reasons outlined above. I suspect you may disagree with at least some of the reasoning, but it's a point that the ftp and release teams seem to agree on. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
