Bug tracker breaks rmail-next-same-subject

Bug tracker breaks rmail-next-same-subject

[Eli Zaretskii]

The bug tracker modifies the Subject lines, which breaks
`rmail-next-same-subject' and `rmail-previous-same-subject'.

I understand why it tries to do that, but perhaps we can find a better
way of signalling important status changes without breaking Rmail?
I'd hate to modify `rmail-current-subject-regexp' to compensate for
that: I think it's not clean to depend on Subject mangling by specific
servers.

Ideas and suggestions are welcome.

Re: Bug tracker breaks rmail-next-same-subject

[Stefan Monnier]

> The bug tracker modifies the Subject lines, which breaks
> `rmail-next-same-subject' and `rmail-previous-same-subject'.

> I understand why it tries to do that, but perhaps we can find a better
> way of signalling important status changes without breaking Rmail?

Could you show some examples, to make sure we talk about the same kinds
of changes?


        Stefan

Re: Bug tracker breaks rmail-next-same-subject

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: don@armstrong.com, owner@emacsbugs.donarmstrong.com, emacs-devel@gnu.org
> Date: Fri, 12 Dec 2008 14:10:40 -0500
> 
> > The bug tracker modifies the Subject lines, which breaks
> > `rmail-next-same-subject' and `rmail-previous-same-subject'.
> 
> > I understand why it tries to do that, but perhaps we can find a better
> > way of signalling important status changes without breaking Rmail?
> 
> Could you show some examples, to make sure we talk about the same kinds
> of changes?

A bug report starts with a Subject such as this:

  Subject: bug#NNNN: 23.0.60; FOO

then it can be modified into this:

  Subject: Processed: Re: bug#NNNN: 23.0.60; FOO

or this:

  Subject: bug#NNN: marked as done (23.0.60; FOO)

or this:

  Subject: bug#NNNN: Info received (bug#NNNN: 23.0.60; FOO)

I'm not sure this is an exhaustive list of all the transformations,
it's just what I found in my INBOX this morning, but Don can
undoubtedly provide more examples, if they exist.

By contrast, rmail-current-subject-regexp allows only for typical
reply prefixes, such as "Re:", and arbitrary whitespace changes, such
as adding or removing newlines.

Re: Bug tracker breaks rmail-next-same-subject

[Don Armstrong]

On Fri, 12 Dec 2008, Eli Zaretskii wrote:
> The bug tracker modifies the Subject lines, which breaks
> `rmail-next-same-subject' and `rmail-previous-same-subject'.

These commands have a fundamental problem; they really should be
rmail-next-in-thread, rmail-previous-in-thread.

> I think it's not clean to depend on Subject mangling by specific
> servers.

That's why References: and In-Reply-To: exist.


Don Armstrong

-- 
I learned really early the difference between knowing the name of
something and knowing something
 -- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug tracker breaks rmail-next-same-subject

[Eli Zaretskii]

> Date: Fri, 12 Dec 2008 13:47:56 -0800
> From: Don Armstrong <don@donarmstrong.com>
> 
> On Fri, 12 Dec 2008, Eli Zaretskii wrote:
> > The bug tracker modifies the Subject lines, which breaks
> > `rmail-next-same-subject' and `rmail-previous-same-subject'.
> 
> These commands have a fundamental problem; they really should be
> rmail-next-in-thread, rmail-previous-in-thread.

Threads are not guaranteed to exist in mailing lists, AFAIK.

> > I think it's not clean to depend on Subject mangling by specific
> > servers.
> 
> That's why References: and In-Reply-To: exist.

You are evidently assuming that everybody uses MUA that preserve these
headers as they should.  The reality is a bit different.

Anyway, these two commands served me well until now; it sounds a bit
ironic, to say the least, that an Emacs bug tracker would break their
utility.

Re: Bug tracker breaks rmail-next-same-subject

[Don Armstrong]

On Fri, 12 Dec 2008, Eli Zaretskii wrote:
> From: Don Armstrong <don@donarmstrong.com>
> > These commands have a fundamental problem; they really should be
> > rmail-next-in-thread, rmail-previous-in-thread.
> 
> Threads are not guaranteed to exist in mailing lists, AFAIK.

They're not guaranteed to exist anywhere.
 
> > That's why References: and In-Reply-To: exist.
> 
> You are evidently assuming that everybody uses MUA that preserve
> these headers as they should. The reality is a bit different.

There are loads of broken MUAs; that doesn't change the fact that
they're broken. References: and In-Reply-To: are the primary way of
tracking threads. In the absence of them, you can try to track threads
using subject, but that's never the first option.

If you want to follow a thread, References: and In-Reply-To: are the
way to do that; Subject: may approximate it, but it's never as
accurate.


Don Armstrong

-- 
Whatever you do will be insignificant, but it is very important that
you do it.
 -- Mohandas Karamchand Gandhi

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug tracker breaks rmail-next-same-subject

[Eli Zaretskii]

> Date: Fri, 12 Dec 2008 15:25:51 -0800
> From: Don Armstrong <don@donarmstrong.com>
> 
> > > That's why References: and In-Reply-To: exist.
> > 
> > You are evidently assuming that everybody uses MUA that preserve
> > these headers as they should. The reality is a bit different.
> 
> There are loads of broken MUAs; that doesn't change the fact that
> they're broken. References: and In-Reply-To: are the primary way of
> tracking threads. In the absence of them, you can try to track threads
> using subject, but that's never the first option.

I don't want to memorize two different ways of following a subject.  I
have things to do with my time other than read emacs-devel and
bug-gnu-emacs.  As long as there are loads of broken MUAs, using the
Subject line will always be more reliable than references.  Until now.

Btw, the bug tracker seems to keep only one reference in References:,
which doesn't help too much to follow a thread by that.

> If you want to follow a thread, References: and In-Reply-To: are the
> way to do that; Subject: may approximate it, but it's never as
> accurate.

What other use cases will break it?  Until now, I didn't see any.

Re: Bug tracker breaks rmail-next-same-subject

[Don Armstrong]

On Fri, 12 Dec 2008, Eli Zaretskii wrote:
> From: Don Armstrong <don@donarmstrong.com>

> > In the absence of them, you can try to track threads using
> > subject, but that's never the first option.
> 
> I don't want to memorize two different ways of following a subject. 

So follow threads instead of subjects. I don't use Rmail, so I can't
tell you how to get it to do that. Try trmail or perhaps someone else
knows. I use mutt which handles this all perfectly.

> As long as there are loads of broken MUAs, using the Subject line
> will always be more reliable than references. Until now.

No, it's always less reliable. You can use the Subject: as a fallback
when you don't have References: or In-Reply-To:, but Subject: doesn't
tell you which message a message is in response to, nor how to elide a
subthread, or any of a huge number of things you can do with threads
that aren't possible when you "group" by subject.

> Btw, the bug tracker seems to keep only one reference in
> References:, which doesn't help too much to follow a thread by that.

It works perfectly fine if your MUA is sane.

> > If you want to follow a thread, References: and In-Reply-To: are
> > the way to do that; Subject: may approximate it, but it's never as
> > accurate.
> 
> What other use cases will break it? Until now, I didn't see any.

Any time someone changes the subject, or uses a method of quoting that
doesn't keep it intact.
 

Don Armstrong

-- 
The beauty of the DRUNKENNESS subprogram was that you could move your
intoxication level up and down at will, instead of being caught on a
relentless down escalator to bargain basement philosophy and the
parking garage.
 -- Rudy von Bitter _Software_ p124

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug tracker breaks rmail-next-same-subject

[Eli Zaretskii]

> Date: Fri, 12 Dec 2008 15:57:51 -0800
> From: Don Armstrong <don@donarmstrong.com>
> 
> So follow threads instead of subjects. I don't use Rmail, so I can't
> tell you how to get it to do that.

There is no such functionality in Rmail, so the only way is to code
it first.

> > As long as there are loads of broken MUAs, using the Subject line
> > will always be more reliable than references. Until now.
> 
> No, it's always less reliable. You can use the Subject: as a fallback
> when you don't have References: or In-Reply-To:, but Subject: doesn't
> tell you which message a message is in response to, nor how to elide a
> subthread, or any of a huge number of things you can do with threads
> that aren't possible when you "group" by subject.

You are talking about treating email as news group discussions.  I
don't need to go that far; if I did, I'd probably switch to Gnus.

All I want is to find the messages related to a certain subject.  I
don't care much to build a tree-like structure out of them, because
the body of the messages has that information, and that is normally
enough for my needs.

> > > If you want to follow a thread, References: and In-Reply-To: are
> > > the way to do that; Subject: may approximate it, but it's never as
> > > accurate.
> > 
> > What other use cases will break it? Until now, I didn't see any.
> 
> Any time someone changes the subject, or uses a method of quoting that
> doesn't keep it intact.

Well, I have yet to find such cases, then.

Anyway, we are repeating ourselves.  It is quite clear that you don't
see a problem in what the tracker does, while I do, because it
interferes with the way I'm used to read mail for many years.  I guess
we will have to agree to disagree on that.

Re: Bug tracker breaks rmail-next-same-subject

[Don Armstrong]

On Fri, 12 Dec 2008, Eli Zaretskii wrote:
> You are talking about treating email as news group discussions. I
> don't need to go that far; if I did, I'd probably switch to Gnus.

There's no difference. It's your choice how you decide to read your
email, but the information that you need to do what you want to do is
there. Best of luck.


Don Armstrong

-- 
Leukocyte... I am your father.
 -- R. Stevens http://www.dieselsweeties.com/archive.php?s=1546

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bug tracker breaks rmail-next-same-subject

[Glenn Morris]

I would very much appreciate some response to the bugs I have filed
against emacsbugs. Thank you.

http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?pkg=emacsbugs.donarmstrong.com

(Especially 749 and 897.)

If there are not going to be any changes until it migrates to a GNU
server, that is also useful to know.

Bugs against emacsbugs.donarmstrong.com

[Don Armstrong]

On Sat, 13 Dec 2008, Glenn Morris wrote:
> I would very much appreciate some response to the bugs I have filed
> against emacsbugs. Thank you.

Haven't looked at any of those, sorry.
 
> http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?pkg=emacsbugs.donarmstrong.com
> 
> (Especially 749

This requires a total revamp of how we're handling mail to
bugs-gnu-emacs; I have to talk with the mailman people to configure
this. [Basically, we'll send everything to one list, and then fork out
the messages that only should go to bug-gnu-emacs to it, and vice
versa for the control messages.

and 897.)

This would require serious tracking of message-ids, which is kind of a
PITA. A procmail msgid replay cache would handle this particular
sillyness.

> If there are not going to be any changes until it migrates to a GNU
> server, that is also useful to know.

Migrating is one of the first things that I need to do, but a whole
host of things have been higher on my priority list.


Don Armstrong

-- 
"I was thinking seven figures," he said, "but I would have taken a
hundred grand. I'm not a greedy person." [All for a moldy bottle of
tropicana.]
 -- Sammi Hadzovic [in Andy Newman's 2003/02/14 NYT article.]
 http://www.nytimes.com/2003/02/14/nyregion/14EYEB.html

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bugs against emacsbugs.donarmstrong.com

[Glenn Morris]

Don Armstrong wrote:

> Haven't looked at any of those, sorry.

If that means "haven't had time", that's OK. If it means "haven't seen
them", there's a problem, since you are registered as maintainer of
that package (?).

> [Basically, we'll send everything to one list, and then fork out the
> messages that only should go to bug-gnu-emacs to it, and vice versa
> for the control messages.

Presumably this means debbugs can't (easily) be changed internally to DTRT.

Couldn't you just use something@donarmstrong.com to receive all
debbugs output, then use procmail to send them on to bug-gnu-emacs or
emacs-bug-tracker? (Probably depends on the details of the forwarding
of bug-gnu-emacs to donarmstrong.com in the first place, of which I am
ignorant.)

> and 897.)
>
> This would require serious tracking of message-ids, which is kind of a PITA.

So my simple suggestion does not work?

  If emacsbugs sees that bug-gnu-emacs or emacs-pretest-bug is already
  Cc'd on a reply to bug, it should avoid sending out another copy to
  the list. Ie, it treats it as a "quiet" submission only to be entered
  in the tracker.

(Again, I suppose it might depend on how that forwarding works.)

And #430 (which you said was doable) might help a bit.

Re: Bugs against emacsbugs.donarmstrong.com

[Don Armstrong]

On Sat, 13 Dec 2008, Glenn Morris wrote:
> Don Armstrong wrote:
> > Haven't looked at any of those, sorry.
> 
> If that means "haven't had time", that's OK. If it means "haven't
> seen them", there's a problem, since you are registered as
> maintainer of that package (?).

I've seen most of them, but haven't thought about or reassigned them.

> > [Basically, we'll send everything to one list, and then fork out the
> > messages that only should go to bug-gnu-emacs to it, and vice versa
> > for the control messages.
> 
> Presumably this means debbugs can't (easily) be changed internally
> to DTRT.

Not without making an ugly hack, no.
 
> Couldn't you just use something@donarmstrong.com to receive all
> debbugs output, then use procmail to send them on to bug-gnu-emacs
> or emacs-bug-tracker? (Probably depends on the details of the
> forwarding of bug-gnu-emacs to donarmstrong.com in the first place,
> of which I am ignorant.)

Sure; I'd just like to avoid having more hackish stuff on my servers
that I'll have to remember to migrate.
 
> > and 897.)
> >
> > This would require serious tracking of message-ids, which is kind
> > of a PITA.
> 
> So my simple suggestion does not work?
> 
>   If emacsbugs sees that bug-gnu-emacs or emacs-pretest-bug is already
>   Cc'd on a reply to bug, it should avoid sending out another copy to
>   the list. Ie, it treats it as a "quiet" submission only to be entered
>   in the tracker.

There's no way to know whether such a message is going to actually
through, and it's still pretty hackish anyway. People really need to
stay away from the "reply-to-all" crack.

> And #430 (which you said was doable) might help a bit.

Yeah, someone else asked for it in debbugs proper; I can add it, it
just didn't make much sense to me to change it since Reply-To: is
already set that way. The right thing is for mailman to stop setting
MFT; I don't know if that's a configurable setting or not.


Don Armstrong

-- 
There are two types of people in this world, good and bad. The good
sleep better, but the bad seem to enjoy the waking hours much more.  
 -- Woody Allen

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bugs against emacsbugs.donarmstrong.com

[Stefan Monnier]

> There's no way to know whether such a message is going to actually
> through, and it's still pretty hackish anyway. People really need to
> stay away from the "reply-to-all" crack.

I don't think that's right: "reply to all" should include NNN@bugs, but
not submit@bugs, not bug-gnu-emacs, not emacs-pretest-bug, not
bug-submit-list, ... so the problem is in the headers of the messages
sent by Debbugs which doesn't strip some of those addresses (tho it does
seem to strip submit@bugs properly).

If "reply-to-all" sends to addresses to which the reply should *never*
be sent, then the error is not in the use of rely-to-all, but in the
headers of the email to which the user is replying.

>> And #430 (which you said was doable) might help a bit.
> Yeah, someone else asked for it in debbugs proper; I can add it, it
> just didn't make much sense to me to change it since Reply-To: is
> already set that way. The right thing is for mailman to stop setting
> MFT; I don't know if that's a configurable setting or not.

Oh, right, some of the addresses get added after they leave Debbugs, so
it's arguably not Debbugs's fault in that case, indeed.
Maybe bug-gnu-emacs's Mailman can be configured not to add MFT, or else
maybe Debbugs can add its own MFT in the hope to preempt Mailman's (not
sure if that will work).


        Stefan

Re: Bugs against emacsbugs.donarmstrong.com

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Oh, right, some of the addresses get added after they leave Debbugs, so
 > it's arguably not Debbugs's fault in that case, indeed.
 > Maybe bug-gnu-emacs's Mailman can be configured not to add MFT, or else
 > maybe Debbugs can add its own MFT in the hope to preempt Mailman's (not
 > sure if that will work).

Erm, dunno about bug-gnu-emacs's Mailman, but vanilla Mailman doesn't
touch Mail-Followup-To, ever.  Are you talking about Reply-To?  Or is
BGE's Mailman hacked up?  Or maybe some people have MFT set in their
Gnus configs?

Re: Bugs against emacsbugs.donarmstrong.com

[Don Armstrong]

On Sat, 13 Dec 2008, Stefan Monnier wrote:
> > There's no way to know whether such a message is going to actually
> > through, and it's still pretty hackish anyway. People really need to
> > stay away from the "reply-to-all" crack.
> 
> I don't think that's right: "reply to all" should include NNN@bugs,
> but not submit@bugs, not bug-gnu-emacs, not emacs-pretest-bug, not
> bug-submit-list, ... so the problem is in the headers of the
> messages sent by Debbugs which doesn't strip some of those addresses
> (tho it does seem to strip submit@bugs properly).

The Reply-To: is set to the From:/Reply-To: of the incoming message
and the bug itself, no matter how the bug came in.
 
> If "reply-to-all" sends to addresses to which the reply should
> *never* be sent, then the error is not in the use of rely-to-all,
> but in the headers of the email to which the user is replying.

No, the error is in the use of reply-to-all which include To: in
addition to addresses listed in Reply-To:. The only way to work around
these sorts of idiocies is to totally strip the To: header entirely,
which is fundamentally broken.


Don Armstrong

-- 
If I had a letter, sealed it in a locked vault and hid the vault
somewhere in New York. Then told you to read the letter, thats not
security, thats obscurity. If I made a letter, sealed it in a vault,
gave you the blueprints of the vault, the combinations of 1000 other
vaults, access to the best lock smiths in the world, then told you to
read the letter, and you still can't, thats security.
 -- Bruce Schneier

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bugs against emacsbugs.donarmstrong.com

[Glenn Morris]

Don Armstrong wrote:

> No, the error is in the use of reply-to-all which include To: in
> addition to addresses listed in Reply-To:. The only way to work around
> these sorts of idiocies is to totally strip the To: header entirely,
> which is fundamentally broken.

It's not fair to call people idiotic for following what is the correct
behaviour on all other Emacs lists, and what used to be the correct
behaviour on the bug list too. There is no doubt in my mind that the
system needs to be changed to adapt to the way people work, not vice
versa. But this has all been said before, so it seems unproductive to
keep restating the same positions.

BTW, since the tracker was upgraded yesterday, it seems to have fallen
silent (I have had no response to commands issued yesterday).

Re: Bugs against emacsbugs.donarmstrong.com

[Stefan Monnier]

>> I don't think that's right: "reply to all" should include NNN@bugs,
>> but not submit@bugs, not bug-gnu-emacs, not emacs-pretest-bug, not
>> bug-submit-list, ... so the problem is in the headers of the
>> messages sent by Debbugs which doesn't strip some of those addresses
>> (tho it does seem to strip submit@bugs properly).

> The Reply-To: is set to the From:/Reply-To: of the incoming message
> and the bug itself, no matter how the bug came in.

This is not related to what I wrote.  For what it's worth, I'd much
rather prefer you don't touch reply-to unless really necessary, so
I wonder what is the reason for fiddling with reply-to.
 
>> If "reply-to-all" sends to addresses to which the reply should
>> *never* be sent, then the error is not in the use of rely-to-all,
>> but in the headers of the email to which the user is replying.

> No, the error is in the use of reply-to-all which include To: in
> addition to addresses listed in Reply-To:. The only way to work around
> these sorts of idiocies is to totally strip the To: header entirely,
> which is fundamentally broken.

Reread what I wrote and think about it.  There is a useful distinction
between "reply to author" and "reply to all" (and a few others
in-between).  They should all behave slightly differently, and they all
make sense in some circumstances that depend on the intention of the guy
who replies.  But in *no* circumstance is it right to reply to a Debbugs
message by sending the reply to bug-gnu-emacs or submit@bugs or
emacs-pretest-bug or bug-submit-list, so clearly these addresses should
not appear in any of the headers that might be used by "reply to all".

The error is in the email message's headers, not in the user's decision to
"reply to all".


        Stefan

Re: Bugs against emacsbugs.donarmstrong.com

[Don Armstrong]

On Sun, 14 Dec 2008, Stefan Monnier wrote:
> For what it's worth, I'd much rather prefer you don't touch reply-to
> unless really necessary, so I wonder what is the reason for fiddling
> with reply-to.

Because a reply shouldn't go anywhere else but to the user who sent it
and the bug itself.
  
> >> If "reply-to-all" sends to addresses to which the reply should
> >> *never* be sent, then the error is not in the use of rely-to-all,
> >> but in the headers of the email to which the user is replying.
> 
> > No, the error is in the use of reply-to-all which include To: in
> > addition to addresses listed in Reply-To:. The only way to work
> > around these sorts of idiocies is to totally strip the To: header
> > entirely, which is fundamentally broken.
> 
> But in *no* circumstance is it right to reply to a Debbugs message
> by sending the reply to bug-gnu-emacs or submit@bugs or
> emacs-pretest-bug or bug-submit-list, so clearly these addresses
> should not appear in any of the headers that might be used by "reply
> to all".

That would require ripping out To: from the message, and setting it to
something entirely bogus, as I said originally. It's not like I don't
understand what the problem is here, why it's caused, or what it would
take to work around broken assumptions by users.


Don Armstrong

-- 
Only one creature could have duplicated the expressions on their
faces, and that would be a pigeon who has heard not only that Lord
Nelson has got down off his column but has also been seen buying a
12-bore repeater and a box of cartridges.
 -- Terry Pratchet _Mort_

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bugs against emacsbugs.donarmstrong.com

[Stefan Monnier]

>> For what it's worth, I'd much rather prefer you don't touch reply-to
>> unless really necessary, so I wonder what is the reason for fiddling
>> with reply-to.
> Because a reply shouldn't go anywhere else but to the user who sent it
> and the bug itself.

You don't know that.  Only the person replying knows where that reply
should go.

Besides, I don't see why getting this result requires fiddling with the
reply-to header.  Can you give an example?
  
>> >> If "reply-to-all" sends to addresses to which the reply should
>> >> *never* be sent, then the error is not in the use of rely-to-all,
>> >> but in the headers of the email to which the user is replying.
>> 
>> > No, the error is in the use of reply-to-all which include To: in
>> > addition to addresses listed in Reply-To:. The only way to work
>> > around these sorts of idiocies is to totally strip the To: header
>> > entirely, which is fundamentally broken.
>> 
>> But in *no* circumstance is it right to reply to a Debbugs message
>> by sending the reply to bug-gnu-emacs or submit@bugs or
>> emacs-pretest-bug or bug-submit-list, so clearly these addresses
>> should not appear in any of the headers that might be used by "reply
>> to all".

> That would require ripping out To: from the message, and setting it to
> something entirely bogus, as I said originally.

?? I don't understand.  It does mean removing those addresses from
pretty much all headers (not just To:), but I don't see why it should
require replacing it with something bogus, or why it should be
a big problem.  Can you restate the problem?


        Stefan

Re: Bugs against emacsbugs.donarmstrong.com

[Don Armstrong]

On Wed, 17 Dec 2008, Stefan Monnier wrote:
> You don't know that.

Of course I know where the most ordinary form of a reply should go:
the bug, and the person sending the message.

> Only the person replying knows where that reply should go.

Enough people replying clearly have no clue where they should go;
hence this entire thread.
 
> Besides, I don't see why getting this result requires fiddling with
> the reply-to header. Can you give an example?

To: submit@bugs
From: bar
Subj: Bug #1234: blah

Causes the following message to be sent to anyone who should get mail
involving bug 1234:

To: submit@bugs
From: bar
Subj: Bug #1234: blah
Reply-To: 1234@bugs, bar

> ?? I don't understand. It does mean removing those addresses from
> pretty much all headers (not just To:), but I don't see why it
> should require replacing it with something bogus, or why it should
> be a big problem. Can you restate the problem?

It'd require changing To: in the above message to some address other
than the address the message was actually sent to, like 1234@bugs.
Thus, a bogus value.

Debbugs is basically a huge wrapper around a mailing list per bug; the
issue we have now is that there are multiple aliases for the same
mailing list, and neither debbugs nor emacs-bugs does message-id
caching and /dev/null-ing, save on display of messages for debbugs.


Don Armstrong

-- 
There is no such thing as "social gambling." Either you are there to
cut the other bloke's heart out and eat it--or you're a sucker. If you
don't like this choice--don't gamble.
 -- Robert Heinlein _Time Enough For Love_ p250

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Bugs against emacsbugs.donarmstrong.com

[Stefan Monnier]

>> You don't know that.
> Of course I know where the most ordinary form of a reply should go:
> the bug, and the person sending the message.
>> Only the person replying knows where that reply should go.
> Enough people replying clearly have no clue where they should go;
> hence this entire thread.
>> Besides, I don't see why getting this result requires fiddling with
>> the reply-to header. Can you give an example?
> To: submit@bugs
> From: bar
> Subj: Bug #1234: blah

> Causes the following message to be sent to anyone who should get mail
> involving bug 1234:

> To: submit@bugs
> From: bar
> Subj: Bug #1234: blah
> Reply-To: 1234@bugs, bar

And this is wrong, because if I want to reply only to the author, most
MUAs will force me to copy&paste emails by hand, since a simply "reply
to author" will probably take the address from the "reply-to" rather
than from "From:".

So this header makes "reply to author" behave in the way appropriate for
"reply-to-all", and make "reply-to-all" misbehave (it sends both to
1234@bugs and submit@bugs, which is somewhat hacked around by Debbugs).

A good header for the email sent by Debbugs would be:

   To: 1234@bugs
   From: bar
   Subj: Bug #1234: blah

> It'd require changing To: in the above message to some address other
> than the address the message was actually sent to, like 1234@bugs.
> Thus, a bogus value.

That's not a bogus value at all.  It's The Right Thing.
What's the problem with it?

> Debbugs is basically a huge wrapper around a mailing list per bug; the
> issue we have now is that there are multiple aliases for the same
> mailing list, and neither debbugs nor emacs-bugs does message-id
> caching and /dev/null-ing, save on display of messages for debbugs.

If you got the headers right, there wouldn't be much need for such
message-id caching.


        Stefan

Re: Bugs against emacsbugs.donarmstrong.com

[Stephen J. Turnbull]

Don Armstrong writes:

 > People really need to stay away from the "reply-to-all" crack.

That's a non-starter, Don.  People are not going to change their basic
MUA usage patterns to cater to a BTS they haven't really bought into
yet anyway.

Re: Bugs against emacsbugs.donarmstrong.com

[Stefan Monnier]

>   If emacsbugs sees that bug-gnu-emacs or emacs-pretest-bug is already
>   Cc'd on a reply to bug, it should avoid sending out another copy to
>   the list. Ie, it treats it as a "quiet" submission only to be entered
>   in the tracker.

Along the same lines, Debbugs should be *very* careful to remove
all/most mentions of bug-gnu-emacs and emacs-pretest-bug (and a few
others that seem to show up) from the mails it sends.
Most of those duplicates come from people's replies which should only go
to NNN@emacs.* but where bug-gnu-emacs and/or emacs-pretest-bug somehow
gets put back into the header.


        Stefan