On Tue, 2006-12-05 at 00:44 +0000, Adam D. Barratt wrote: > No, I'm not a developer. I have however being triaging ftp.d.o bugs for > some time now.
Cool; I know that bug triage is a hugely important thing and I am very appreciative of those who help me out with my packages doing that. > The address in From: works perfectly. :-) (as hundreds of spammers > endeavour to prove each day :() It looks all too like a way to avoid getting the mail. ;) Sorry for misunderstanding, or I would just have emailed first. > > > My reason for marking it serious is that it is > > preventing lilypond from making a crucial transition > > into testing, and that this bug report is exactly what > > Steve Langasek, the chief release manager, said > > was what I should do. > > (I read -release). I don't remember Steve suggesting you file the bug at > a release-critical severity, but apologies if I missed that. Sorry, I wasn't trying to imply that. Steve said I should file the bug report as the right way to address the case. My reason for upping the severity was because Steve said I should file the bug (so it's more likely to be right) and it is blocking a crucial transition (which is the real thing). > 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. > 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 would be a disaster for the lilypond package for etch to go out with the old version of lilypond. It would be a dark embarrassment. There is no *reason* why we should do so, except the risk that inertia will kick in. In other words, it is much more important that this removal happen than most other removals, because this removal, unlike most, is blocking a very important transition for the package concerned. Most removals do not have that character. 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? Thomas
signature.asc
Description: This is a digitally signed message part
