[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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@tuxteam.de 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.

Indeed. 
 
> 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
> idiosyncrasy.)

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
> now.

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.

-- 
Brian.

-- 
Brian.


Reply to: