Re: spam (Re: Bug#202373: traitor offstage)
20-07-2007, Don Armstrong <don@debian.org> пишет:
> On Fri, 20 Jul 2007, Oleg Verych wrote:
>> Note, that i'm talking about forwarded messages.
>
> There's no real difference. Messages come into the bts, are stored.
> Messages go out of the bts, and are also stored. The same message goes
> to -dist, the maintainer, the pts, and anyone who is subscribed to the
> bug.
-dist is here and i'm anyone who can actually help with things i know.
>> OK, let me show how it looks:
>>
>> #433834: curl: Should run tests on hurd-i386 either
>> ->33836: nautilus: No documentation on which volumen devices icons are shown and
>> #433837: nautilus: Unusable "unmount volume" option
>> #432614: dvgrab: uses unsupported isochronous request types
>> #433285: found 433285 in 0.4.0b-10, closing 433285
>>
>> See last one? It's without context, while previous have one.
>> And this is currenty depends: or it's generated by reportbug, or pkg
>> name added by hand by developer who answered. I'm asking about making
>> all them look same.
>
> The all look the same; the only thing that debbugs adds is the #NNN:;
> every other bit is the subject of the message which was sent to bug
> NNN or affected bug NNN.
>
> Control transcripts can affect hundreds or thousands of bugs, so
> there's no way that all of the packages will ever be listed in the
> subject.
But NNN is unique for one particular pkg,
>> Second thing's threading (combining above):
>>
>> #433834: curl: Should run tests on hurd-i386 either
>> ->33836: nautilus: No documentation on which volumen devices icons are shown and
>> #433837: nautilus: Unusable "unmount volume" option
>> `| (empty means same subject)
>> `- #433837: nautilus: found XYZ in 0.4.0b-10, closing XYY
>> `- #433837: nautilus: Done....
thus i've added pkg name here.
>> That's what i'm talking about.
>
> That's not reasonable either, because you're assuming a message is in
> reply to another message, when it isn't neccessarily a reply.
>
> Making it easier for people to include the appropriate References: and
> In-Reply-To: is the way forward, which will resolve most cases of this
> for actual messages. I'm willing to apply appropriate patches for
> that, but I'm not planning on faking References: or In-Reply-To: for
> the above reasons.
If not "References" i'm will be OK with "X-Resent-References" or
whatever else.
This kind of thing is much easy to implement and maintain, than all
that subscribe/unsubscribe kind of things.
Thanks for conversation.
____
Reply to: