followup to bug report not included in bug tracker; diverse automatic Subject lines; ACK noise

followup to bug report not included in bug tracker; diverse automatic Subject lines; ACK noise

[Drew Adams]

I sent the email below on 5/30/2008 as a reply to my earlier mail that reported
the bug, to provide some followup info. I see now at the bug-tracker Web site
that the mail below was apparently never added to the bug tracker. Seems like a
problem, to me. I replied to the original bug report mail, using the same
subject line.

Dunno how many other such followup mails that I've sent (or that others have
sent) never get included in the bug tracker.

Why does the generated ACK message say "If you wish to submit further
information on this problem, please send it to 117@emacsbugs.donarmstrong.com,
as before."? As before? There is no "as before" - I never sent anything to
117@emacsbugs.donarmstrong.com. I just used `M-x report-emacs-bug', as always.
Why can't one just reply to the original thread that reported the bug? Why
change the thread - subject line and email address, so the result is multiple
email threads for the same bug?

The bug tracker system is confusing to me. A bug report for Emacs 23 via `M-x
report-emacs-bug' goes to emacs-pretest, as always. But if someone replies to
such an email, it apparently doesn't get included in the tracker thread (report)
for that bug. Dunno if it's lost or it just starts its own new (ignored)
thread...

And the same bug report ends up with emails that have various kinds of Subject
lines - different automatic prefixes, such as "23.0.60; " and "bug#117: " - IOW,
multiple threads. Email sorting by subject, with my email client at least, will
not group subject "foo" anywhere near subject "bug#99: foo" or "23.0.60; foo". I
now have to use search to find matches for keywords ("foo") in the Subject. Why?

If you want to refer to the bug as bug #99 or attach the release info 23.0.60 to
it, why not do that in the message body? Or, if you really must change the
Subject line, append instead of prepend the extra identifying info.

There seems to be no such thing as a (single) thread for a given bug anymore.
And that's not to mention all of the generated ACK messages that constitute
essentially noise. Pretty silly. 

We all deal with this kind of thing (mail reports, tracking systems) in our jobs
everyday - support tickets, bug reports, build reports, QA reports, review
reports, meeting reservations, and so on - there's nothing special needed here,
AFAICT. Why not just keep the original subject (thread) and email address, and
include an http link in the mail body to the report on the bug-tracker site? CC
additional email addresses if you must, but at least keep the original reporting
address (emacs-pretest-bug or whatever).

In my work at least, that's always the way such mails are treated. I interact
with 10 or 12 different such automatic tracking systems at work, developed by
different people for use with completely different tools, but none of them
present any problem wrt email threads. They're just transparent - I never need
to pay attention to the email header fields. Keep it simple.


-----Original Message-----
From: Drew Adams Sent: Friday, May 30, 2008 3:55 PM
To: emacs-pretest-bug@gnu.org
Subject: RE: 23.0.60; messed up frame parameters

This has not changed. I get the same behavior in a Windows build from yesterday:

GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-05-29 on LENNART-69DE564

The frame parameters are wrong; there are duplicates, etc., both for the first
frame and for the special *Help* and *Completions* frames. See the detailed
descriptions and the screenshot sent previously. 

This has apparently not improved at all.


[mail replied to, from 2008-04-05, was quoted here]

Re: followup to bug report not included in bug tracker; diverse automatic Subject lines; ACK noise

[Stefan Monnier]

> I sent the email below on 5/30/2008 as a reply to my earlier mail that
> reported the bug, to provide some followup info. I see now at the
> bug-tracker Web site that the mail below was apparently never added to
> the bug tracker. Seems like a problem, to me. I replied to the
> original bug report mail, using the same subject line.

You sent it to emacs-pretest-bug@gnu.org, which at the time was not
going to the bug-tracker at all.  The bug#117 is probably the result of
my manually forwarding your original report to the bug-tracker.


        Stefan

Re: followup to bug report not included in bug tracker; diverse automatic Subject lines; ACK noise

[Don Armstrong]

On Wed, 18 Jun 2008, Drew Adams wrote:
> Why can't one just reply to the original thread that reported the
> bug?

You can.

> Why change the thread - subject line and email address, so the
> result is multiple email threads for the same bug?

You don't have to.

> I now have to use search to find matches for keywords ("foo") in the
> Subject. Why?

If people just use reply, it'll be in the same thread. If they don't,
it won't currently, but there's a wishlist bug open to automatically
join it to the thread.

> If you want to refer to the bug as bug #99 or attach the release
> info 23.0.60 to it, why not do that in the message body?

There needs to be some way of knowing which bug you're talking about.
Normally with debbugs this is done using
nnn@emacsbugs.donarmstrong.com mailing address. However, because emacs
has been using mailing lists to track bugs for a long time, the
decision was made to use the existing code in debbugs which is capable
of associating a mail with a specific bug based on the subject. MUAs
generally keep the subject intact, and the beginning of the subject is
the part that's least likely to be munged by anything, save adding Re:
or similar. 

Finally emailing bugs-gnu-emacs@ or nnn@emacsbugs.d.c is exactly the
same for bugs that are in emacs.

It's possible that this was the wrong decision, and we should disable
entirely messages sent directly to the mailing list, but that's how
it's set up now.

> Or, if you really must change the Subject line, append instead of
> prepend the extra identifying info.

The wishlist bug for automagic threading will resolve this; see above.
[And in any event, all messages that actually go through the bug
tracker will have the same leading bits of the subject anyway, so they
should sort together.]
 
> There seems to be no such thing as a (single) thread for a given bug
> anymore. And that's not to mention all of the generated ACK messages
> that constitute essentially noise. Pretty silly.

You can ditch the ack messages by adding "X-Debbugs-No-Ack: yes" or
similar to your headers; the ack messages are on by default primarily
for casual users.


Don Armstrong

-- 
"There's nothing remarkable about it. All one has to do is hit the    
right keys at the right time and the instrument plays itself."
 -- Bach 

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

RE: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Drew Adams]

> > If you want to refer to the bug as bug #99 or attach the release
> > info 23.0.60 to it, why not do that in the message body?
> 
> There needs to be some way of knowing which bug you're talking about.
> Normally with debbugs this is done using
> nnn@emacsbugs.donarmstrong.com mailing address. However, because emacs
> has been using mailing lists to track bugs for a long time, the
> decision was made to use the existing code in debbugs which is capable
> of associating a mail with a specific bug based on the subject. MUAs
> generally keep the subject intact, and the beginning of the subject is
> the part that's least likely to be munged by anything, save adding Re:
> or similar. 

I don't follow all of that, sorry.

Please keep the Subject line intact. It is annoying to have multiple different
strings of text prepended to the Subject line. Here is another example:

 bug#400: Acknowledgement (23.0.60; C-h v should pick up
 lispified name in Customize)

The actual Subject was this:

 C-h v should pick up lispified name in Customize

The (35-character!!) prefix "bug#400: Acknowledgement (23.0.60; " just
obfuscates things for the user and makes it difficult to group messages about
the same bug together in a mail client. 

Please put such metadata in the message body or other header fields. Preserve
the user's Subject line intact. Mail clients know about RE: and FW:. They don't
know about "bug#400: Acknowledgement (23.0.60; ".

The bug tracker might be more interested in the metadata, but users are more
interested in the data. It's not only about the tracker; it's also about the
users.

The implementation of the tracker might impose certain constraints, but every
effort should be made to make things easy for the user. Do whatever you need to
do under the covers, but the mail thread should remain intact. 

> > There seems to be no such thing as a (single) thread for a given bug
> > anymore. And that's not to mention all of the generated ACK messages
> > that constitute essentially noise. Pretty silly.
> 
> You can ditch the ack messages by adding "X-Debbugs-No-Ack: yes" or
> similar to your headers; the ack messages are on by default primarily
> for casual users.

No idea what that means. My mail client does not, AFAIK, let me do that. And it
is not the existence of the ACK messages that is annoying so much as it is their
content and Subject lines.

Re: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> The (35-character!!) prefix "bug#400: Acknowledgement (23.0.60; " just
> obfuscates things for the user and makes it difficult to group messages about
> the same bug together in a mail client. 

"bug#400: " doesn't seem too bad though.

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Stefan Monnier]

>> The (35-character!!) prefix "bug#400: Acknowledgement (23.0.60; " just
>> obfuscates things for the user and makes it difficult to group messages about
>> the same bug together in a mail client. 

> "bug#400: " doesn't seem too bad though.

Agreed.  Basically, each bug number gets its own mini mailing-list, and
prepending the list name (unless it's already in the subject, typically
right after "Re:") is standard practice.
But maybe it should be "[bug#400] ".


        Stefan

RE: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Drew Adams]

> > The (35-character!!) prefix "bug#400: Acknowledgement 
> (23.0.60; " just
> > obfuscates things for the user and makes it difficult to 
> group messages about
> > the same bug together in a mail client. 
> 
> "bug#400: " doesn't seem too bad though.

If it's truly impossible to use a different header field or the message body,
then append; don't prepend. Prepending junk throws off sorting by subject.

RE: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Drew Adams]

> >> The (35-character!!) prefix "bug#400: Acknowledgement 
> >> (23.0.60; " just obfuscates things for the user and makes
> >> it difficult to group messages about
> >> the same bug together in a mail client. 
> 
> > "bug#400: " doesn't seem too bad though.
> 
> Agreed.  Basically, each bug number gets its own mini 
> mailing-list,

Why should that happen? Why have two threads for the same bug? Some people might
reply to the original thread (sans label) and others might reply to the other
thread (with label). Mess; nothing gained.

I don't see why this is considered advantageous. It sounds like users
sacrificing for the sake of tools. The tools should make life easier for the
users, not the other way around.

> and prepending the list name (unless it's already in the subject, 
> typically right after "Re:") is standard practice.
> But maybe it should be "[bug#400] ".

It's hard for me to believe that changing the subject line would be standard
practice anywhere. Anyway, even if it is standard practice for you, it's not
what I'm used to or what I prefer. I don't see the need for it or the advantage.
The tools should be able to follow a thread without changing the Subject line.

Re: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Stefan Monnier]

>> Agreed.  Basically, each bug number gets its own mini mailing-list,
> Why should that happen? Why have two threads for the same bug?

Drew, please take a deep breath and think before posting: nowhere does
it say or even imply that the same bug (sh|w)ould get 2 threads.

> It's hard for me to believe that changing the subject line would be standard
> practice anywhere.

Yes, sometimes reality is hard to take.


        Stefan

Re: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Stefan Monnier]

> If it's truly impossible to use a different header field or the
> message body, then append; don't prepend. Prepending junk throws off
> sorting by subject.

The question is not whether it's possible: it's actually easy to change.


        Stefan

Re: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Jason Rumney]

Drew Adams wrote:
> Please put such metadata in the message body or other header fields.

Mail clients don't know about those either, so how will they be 
preserved when someone replies? And then there is the Usenet gateway to 
worry about, which is what really forces us to stick with having the bug 
number prepended to the Subject line, as even the reply address is lost 
when someone replies via usenet.

Re: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Jason Rumney]

Drew Adams wrote:
> Why should that happen? Why have two threads for the same bug? Some people might
> reply to the original thread (sans label) and others might reply to the other
> thread (with label). Mess; nothing gained.
>   

If there are still unlabelled reports making it through to the list, 
then there is a bug in the mailing list setup, or someone Cc'ed a 
different list - perhaps we need to change the text at the top of the 
bug reporting interface to discourage that.

RE: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Stephen J. Turnbull]

Drew Adams writes:

 > If it's truly impossible to use a different header field or the message body,
 > then append; don't prepend. Prepending junk throws off sorting by subject.

Sure, but all that's required to fix that is to update the junk-prefix
strippers provided by the major MUAs.  We already have to strip Re:,
Re[\d], Fwd:, AWT:, [listname: postnumber], etc etc.

As a data point, personally, for bug lists I *like* having the prefix,
as long as it's short.

RE: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Drew Adams]

> > Please put such metadata in the message body or other header fields.
> 
> Mail clients don't know about those either, so how will they be 
> preserved when someone replies? And then there is the Usenet 
> gateway to worry about, which is what really forces us to stick
> with having the bug number prepended to the Subject line, as
> even the reply address is lost when someone replies via usenet.

Yes, mail clients and Usenet can change or lose header info. And users can
change subject lines and message bodies. It happens.

Message body.
Or else append rather than prepend to the subject line.



Do others really think prepending stuff such as this to the subject line is
helpful?

 bug#431: closed by Stefan Monnier <monnier@iro.
 umontreal.ca> (Re:bug#431: 23.0.60;

ALL of that is prepended metadata. And it looks like we're now getting stuff
prepended to stuff that was prepended... (Press 1 if you want to see metadata.
Press 2 if you want to see metametadata. Press 3...) We all love Lisp, but we
don't need nested subject lines.

Where's the beef? Here's the real subject line:

 `display-buffer' opens vertical instead of horizontal windows

Kinda gets buried in the sauce:

 bug#431: closed by Stefan Monnier <monnier@iro.
 umontreal.ca> (Re:bug#431: 23.0.60; `display-buffer'
 opens vertical instead of horizontal windows)

RE: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Drew Adams]

>  > If it's truly impossible to use a different header field 
>  > or the message body, then append; don't prepend. Prepending
>  > junk throws off sorting by subject.
> 
> Sure, but all that's required to fix that is to update the junk-prefix
> strippers provided by the major MUAs.  We already have to strip Re:,
> Re[\d], Fwd:, AWT:, [listname: postnumber], etc etc.

I see; it's the user's problem. Each user should customize the mail client.

Guess I don't know how to do that in my mail client, Outlook, which is still
AFAIK one of the most commonly used clients. (Not necessarily among Emacs
developers, but in general.) Maybe it's possible, but I'm not crazy about having
to learn how.

And I certainly wouldn't want to try to deal with the entire (evolving?) panoply
of prepended annotations I've seen so far. This seems to be only the beginning:

 bug#431: closed by Stefan Monnier <monnier@iro.
 umontreal.ca> (Re:bug#431: 23.0.60; ...

Will we be representing whole workflows or bug metadiscussions in the subject
line?

RE: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Drew Adams]

> >> Agreed.  Basically, each bug number gets its own mini mailing-list,
> >
> > Why should that happen? Why have two threads for the same bug?
> 
> Drew, please take a deep breath and think before posting: 

Please lose the snottiness.

> nowhere does it say or even imply that the same bug
> (sh|w)ould get 2 threads.

Perhaps I should have used a different word from "thread": "subject". In my mail
client, at least, sorting by subject line is the closest thing I have to sorting
by thread.

You called it a "mini mailing-list". I mistakenly called it a "thread" this
once. But "subject" is the word I've been using over and over. Please don't
change the subject (in both senses): that's what I've been asking. At a minimum,
please don't change the beginning of the subject line.

> > It's hard for me to believe that changing the subject line 
> > would be standard practice anywhere.
> 
> Yes, sometimes reality is hard to take.

See above - lose it.

Peaceful Coexistence with an Issue Tracker

[Stephen J. Turnbull]

Drew Adams writes:

 > I see; it's the user's problem. Each user should customize the mail
 > client.

No, you clearly don't see *at all*.  You apparently have read a book
on HCI (and maybe written a half dozen), but that expertise is going
to be essentially irrelevant for maybe three months, until the system
itself has somewhat shaken down.  Your incessant complaints can at
best slow that process down.

Some useful principles in introducing an ITS:

1.  An issue tracking system (ITS) is in service to the *maintainers*.
    (For this purpose, the maintainers are Stefan and Yidong ex
    oficio, and those others such as Miles, Eli, Jason, Juanma, Glenn,
    Ken'ichi et al who have assumed reponsibility for one or more
    subsystems, and who are reliably available to deal with problems
    promptly as they arise.)  We "just users" should mostly just grin
    and bear it until they've decided what they want to do with it.

2.  An ITS is *not* a mailing list, although it manifests on certain
    mailing lists in various ways.  Trying to handle it in a standard
    mail client is not going to be terribly productive.[1]  Trying to
    force the ITS into a format that is friendly to Outlook and RMail
    (as it exists today) is a prioi a BadIdea[tm].

3.  ITS issues and mailing list threads need not be co-extensive, and
    often should not be.

4.  As a consequence to 1--3 inter alia, add-on software will be
    written to enable the maintainers and others to handle ITS traffic
    and ITS issues efficiently. Some is presumably already available
    from Debian, but that will need to be extended, I suspect.  For
    obvious reasons, that software will be written in Emacs Lisp.

I would recommend to users who prefer non-Emacs MUAs that they filter
ITS traffic into a separate mbox, and use an Emacs MUA to read it.  In
that way they can profit from the hacks of others, and maybe
contribute some themselves.

A good milestone for when HCI issues can usefully be raised would be
when Stefan and Yidong have figured out what kind of regular status
reports from the ITS are useful to them.  At that point the issue flow
has probably started to stabilize and the maintainers have a better
sense of what is and is not necessary to their usage of the ITS.

Footnotes: 
[1]  N.B. Outlook doesn't even qualify as a standard mail client here.
It has a myriad quirks, so that catering to Outlook means that you
cannot take advantage of a large fraction of the capabilities of
RFC2822- and RFC1035-conforming MUAs.

Re: followup to bug report not included in bug tracker; diverseautomatic Subject lines; ACK noise

[Don Armstrong]

On Sat, 21 Jun 2008, Drew Adams wrote:
> > There needs to be some way of knowing which bug you're talking about.
> > Normally with debbugs this is done using
> > nnn@emacsbugs.donarmstrong.com mailing address. However, because emacs
> > has been using mailing lists to track bugs for a long time, the
> > decision was made to use the existing code in debbugs which is capable
> > of associating a mail with a specific bug based on the subject. MUAs
> > generally keep the subject intact, and the beginning of the subject is
> > the part that's least likely to be munged by anything, save adding Re:
> > or similar. 
> 
> I don't follow all of that, sorry.

Understanding all of that is a prerequsite for demanding changes,
otherwise having a discussion about the desired functionality is a
waste of my time in its entirety.

> Please keep the Subject line intact. It is annoying to have multiple different
> strings of text prepended to the Subject line. Here is another example:
> 
>  bug#400: Acknowledgement (23.0.60; C-h v should pick up
>  lispified name in Customize)

This is an acknowledgement mail; it's only sent to the sender of a
bug, and no one else. Responding to it will keep the threading, so
it's no big deal.

> The (35-character!!) prefix "bug#400: Acknowledgement (23.0.60; " just
> obfuscates things for the user and makes it difficult to group messages about
> the same bug together in a mail client. 

If your mail client is incapable of threading using References: and
In-Reply-To:, then I submit that your MUA is broken, not debbugs.
Subjects change in threads, and informing the user in the subject as
to the action thbat was taken to a given message is useful and
informative, and enables users to deal with messages rapidly.
 
> The implementation of the tracker might impose certain constraints, but every
> effort should be made to make things easy for the user. Do whatever you need to
> do under the covers, but the mail thread should remain intact. 

Everything that the tracker does has been utilized for years in
Debian. All of those features do actually make it easier to.]
 
> > > There seems to be no such thing as a (single) thread for a given bug
> > > anymore. And that's not to mention all of the generated ACK messages
> > > that constitute essentially noise. Pretty silly.
> > 
> > You can ditch the ack messages by adding "X-Debbugs-No-Ack: yes" or
> > similar to your headers; the ack messages are on by default primarily
> > for casual users.
> 
> No idea what that means. My mail client does not, AFAIK, let me do that. 

What hideously broken mail client are we talking about here?

> And it is not the existence of the ACK messages that is annoying so
> much as it is their content and Subject lines.

So everything about them?


Don Armstrong

-- 
Fate and Temperament are two words for one and the same concept.
 -- Novalis [Hermann Hesse _Demian_]

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

Re: Peaceful Coexistence with an Issue Tracker

[Richard M Stallman]

    I would recommend to users who prefer non-Emacs MUAs that they filter
    ITS traffic into a separate mbox, and use an Emacs MUA to read it.

I have repeatedly asked for it to be sent to a separate mailing list.
That way, it won't require everyone to figure out how to filter mail
just to keep them separate.  They will BE separate unless you want
to combine them.