Re: Processed: Re: Bug#245504: Close bug? (was: Dell GX270 installation report)
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 [cjwatson@flatline.org.uk]
Reply to: