Re: policy around 'wontfix' bug tag
- Date: Mon, 5 Feb 2018 18:47:51 +0000
- From: Brian <ad44@xxxxxxxxxxxxxxx>
- Subject: Re: policy around 'wontfix' bug tag
On Mon 05 Feb 2018 at 10:24:14 -0500, The Wanderer wrote:
> On 2018-02-05 at 10:09, tomas@xxxxxxxxxx wrote:
> > On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote:
> >> On 2018-02-05 at 09:32, David Wright wrote:
> > [...]
> >> > :0 Wh: $HOME/msgid.lock
> >> > | formail -D 199999 $HOME/msgid.cache
> >> >
> >> > I used it for years.
> >> I don't parse this well enough to understand what it would do, and I
> >> don't know where to find a procmail reference which would let me read up
> >> on it easily enough to understand quickly. Could you clarify?
> > The trick is in formail (contained in the package procmail). Formail is
> > a pretty generic mail parser which can be used to filter mails (or parts
> > of mails) according to different criteria. Option -D instructs it to set
> > up a Message-ID cache to drop duplicate mails (duplicate in the sense of
> > Message-ID, that is). The number after the -D limits the cache's length.
> That wouldn't produce the behavior I want, though. Whether or not a
> "duplicate" private copy (or probably not actually duplicate, since
> mailing lists tend to modify other headers while leaving Message-ID
> alone) is inappropriate depends on context, and specifically, primarily
> on the sender's intent.
Intent is something difficult to work out. I suspect many just hit
mutt's equivalent of the "g" key. Getting upset about it is the road
to a flame war.
> There can be legitimate reasons to send a message both to mailing list
> and to a named recipient who is also subscribed to that list.
> For example, consider a high-volume mailing list, where many subscribers
> read only part of the traffic.
Or, could we consider the BTS? Not Cc'ing a bug report submitter in a
reply runs a very high risk of leaving them out of the loop.
> If there's an ongoing discussion on that mailing list, and one of the
> participants wants to draw in a third person who also subscribes, it's
> entirely appropriate to CC a reply to that third party.
Definitely (whether they are known to subscribe or not).
Which brings us back to - how does one know someone is subscribed to a
Debian mailing list?
> However, if this were to happen with me, I would not want to receive
> *only* the mailing-list copy. I would want to receive both: the
> mailing-list copy to go into my local archive of the mailing list (and
> to be present in the mailing list's folder, so that it appears properly
> threaded with other replies), and the direct copy to draw my attention
> to the subject. (Although I would probably then seek out the
> mailing-list copy and reply to that. But that's a personal
Seeking out is time-consuming. A recipe for automation is given in
another post. It gives you everything you want.
> There are other possible complexifying scenarios, which distort the
> picture in other directions, but I don't have them ready to mind right
I've tried to point to some of them.
> What it boils down to is that dropping duplicate messages is only always
> appropriate when they are *complete* duplicates, in all headers (except
> possibly things like transmission path history). With a mailing list,
> that's rarely if ever the case.
(Transmission headers are not unimportant. You cannot have it both
ways; it's either a duplicate or it's not).
It's probably impossible. Determining a duplicate email solely on the
basis of an identical Message-Id: is a brain-dead idea.