reassign 245504 discover-data reassign 247750 installation-reports thanks On Mon, May 10, 2004 at 05:07:00PM -0500, Branden Robinson wrote: > reassign 245504 installation-reports > thanks
Let's reassign the correct one of the set of cloned bugs instead. Bug researchers, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245504&msg=47 for Branden's reassignment. > This is almost as bad as just dumping a bug in someone else's lap > with no explanation all. PLEASE STOP DOING THIS. I've asked the BTS > guys to CC the package address of reassigned bugs by default for > years. They either will not do it or it's not a high enough priority > to get done. It's not at all trivial to do. The BTS gets two messages: * A message to nnnnnn@, which typically gets processed first. This is sent to the maintainer etc. The script processing these messages does not know how to process control commands at the top. * A message to control@, which is parsed for control commands and then the rest thrown away. This does not forward the complete mail in any way to anyone, reassigned maintainer or not. I believe that copying the reassigned maintainer would involve either an ugly and hard-to-maintain kludge or a significant refactoring, neither of which is likely to happen soon (and I'd hope that the former doesn't happen at all). The only way I can think of to do it cleanly in the current design involves not mailing the original maintainer, which hardly seems like an improvement, and it wouldn't be a reliable approach anyway. [For future reference in bug #197304, the most plausible refactoring would seem to be moving the mail-sending intelligence from process to some library module and having service use it to forward on the original control mail. However, we'd have to be somewhat careful about when this should be done with control mails, since if there were no other content in the control mail other than the commands then maintainers would be justifiably annoyed at getting effectively two copies of it for no good reason.] There is, however, a reason that I arranged over a year ago for the text of # comments to be included in acks, per bug #93408: it can be used for short explanations of the reasons for a control command. I've even documented this behaviour now. :-) Please keep further discussion of this topic in #197304. I'm only copying -boot and -x because I'm following up to a message sent to both lists, and because it may be useful advice for people processing installation reports. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
