public inbox for gnats-devel@sourceware.org
 help / color / mirror / Atom feed
From: "Paul Traina" <pst@juniper.net>
To: "Dirk Bergstrom" <dirk@juniper.net>,
	"Milan Zamazal" <pdm@zamazal.org>,
	"Michael Richardson" <mcr@sandelman.ottawa.on.ca>
Cc: <help-gnats@gnu.org>
Subject: Re: Subject line processing in Gnats 4.0
Date: Thu, 01 Nov 2001 07:18:00 -0000	[thread overview]
Message-ID: <004101c182cf$d703b4b0$2b6b6fc0@shockwave.org> (raw)
In-Reply-To: <C53744A44FBC9B4BAE90EB41D2C09AC205223F@proton.jnpr.net>

Negative Dirk,
I had it behave that way before, and it sucked.  Every time someone sent in
anything like "OS/2" it would append it to PR #2.
Instead, I wrote a script called refile_pr (I think it may still be in my
home directory or under bin/... that solved this problem).
If it's gone, I can tell you how to recreate it.  WIth gnats 4.0, it's
trivial, about 5 lines of real code.

----- Original Message -----
From: "Dirk Bergstrom" <dirk@juniper.net>
To: "Milan Zamazal" <pdm@zamazal.org>; "Michael Richardson"
<mcr@sandelman.ottawa.on.ca>
Cc: <help-gnats@gnu.org>
Sent: Tuesday, December 11, 2001 6:10 PM
Subject: RE: Subject line processing in Gnats 4.0


> i've been wrestling with this problem for some time (we've been running
> 4.0a for over a year...), and i've been meaning to send this to the list
> for a while:
>
> summary:
> at my company, we have been having some difficulties with gnats'
> handling of email replies to PRs.  gnats checks the subject of incoming
> mail, and if it matches a fairly restrictive pattern (must look like a
> reply), the message is appended to the relevant PR.  if there is no
> match, a new PR is created.  this often leads to creation of bogus PRs,
> because the matching expression is too restrictive.  i propose that we
> remove the restriction, and append *all* messages with subjects matching
>
> a PR to that PR.
>
> detailed explanation:
> when a message is filed by queue-pr (via file-pr), gnats scans the
> subject line for the following regex (line 575 in file-pr.c):
>
> "(.*re[ \t]*(\\[[0-9]+\\])?:)?[ \t]*([-a-z0-9_+.]*[:/][ \t]*([0-9]+))"
>
> which (sort of) translates to a regex of /.*(re:)? <category>/<pr_num>/.
> if it
> finds this pattern, the message is appended to pr_num; if not, gnats
> creates a new PR, using the subject as synopsis, and body as
> description.
>
> this only works if people using gnats pay close attention to the subject
>
> of their emails.  in the real world, however, developers forward
> messages, they use mailers that insert extra cruft in the subject line
> (email addresses, names, etc), and sometimes gnats is used in concert
> with a different bug-tracking system, which inserts it's own tracking
> number in the subject.  whatever the cause, the result is a bogus PR,
> which clutters up the system, confuses developers and support staff, and
>
> takes time and energy to close/expunge.
>
> these subjects do the Right Thing:
>
> *) re: compiler/9876: compiled code runs backwards
> *) serial-port/1234: cannot process frosted flakes
>
> but these subjects all do the Wrong Thing (create new PR, instead of
> appending):
>
> *) Re: FW: sw-kern-sanders/16543: kernel panic on gunshot
> *) PR 12345
> *) Fw: sw-rip-vnwnkl/10795: The routing subsystem is asleep
> *) RE: 2001-0821-021: hw-pr0n/16413 FPC shows pictures of naked ladies
> on reboot
>
> (basically, anything in front of the category that's not "re:" bombs.)
>
> i believe that the current behavior violates the principle of least
> surprise -- if i send a message to bugs with a subject "re: fw:
> sw-foo/1234", i expect that gnats will append it to PR 1234.  opening a
> new PR is *not* what i intend.
>
> solution:
> it's not clear to me why the regex is so restrictive.  i think it would
> make more sense for gnats to assume that any message with a parseable PR
>
> identifier (<category>/<pr_num>) in the subject should be appended to
> that PR.  that would allow for all the real-world messages to be
> processed in a manner that would not surprise the sender.
>
> furthermore, i think it should also accept "PR<pr_num>", if it is the
> first reasonable text in the subject, a regex along the lines of "^[
> \t]*((re|fw):)?[ \t]*pr([0-9]+)".  i often see bogus PRs with this
> synopsis, which were clearly intended to be part of <pr_num>, not
> separate PRs.  however, this would be a more extreme change, and might
> have unforseen consequences...
>
> does anyone see a reason to keep the restrictive regex?
>
> --
> Dirk Bergstrom               dirk@juniper.net
> _____________________________________________
> Juniper Networks Inc.,          Computer Geek
> Tel: 707.433.0564           Fax: 707.433.0769
>
> > -----Original Message-----
> > From: Milan Zamazal [mailto:pdm@zamazal.org]
> > Sent: Saturday, December 08, 2001 3:23 PM
> > To: Michael Richardson
> > Cc: help-gnats@gnu.org
> > Subject: Re: Subject line processing in Gnats 4.0
> >
> >
> > >>>>> "MR" == Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
> >
> >     MR>   Following the code through, it calls sends SUBM to the
> >     MR> server... and there is some heuristic in the gnatsd that sees
> >     MR> the subject line. And this has worked... sometimes.
> > But I have a
> >     MR> number of times it hasn't worked, and new PRs were created. I
> >     MR> can share them if this isn't a known problem.
> >
> > The problem is not known to me.  Please provide me with the details.
> >
> > Thanks,
> >
> > Milan Zamazal
> >
> > --
> > It's amazing how much better you feel once you've given up hope.
> >                                                 (unknown source)
> >
> > _______________________________________________
> > Help-gnats mailing list
> > Help-gnats@gnu.org
> > http://mail.gnu.org/mailman/listinfo/help-gnats
> >
>
> _______________________________________________
> Help-gnats mailing list
> Help-gnats@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-gnats
>
>


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

WARNING: multiple messages have this Message-ID
From: "Paul Traina" <pst@juniper.net>
To: "Dirk Bergstrom" <dirk@juniper.net>,
	"Milan Zamazal" <pdm@zamazal.org>,
	"Michael Richardson" <mcr@sandelman.ottawa.on.ca>
Cc: <help-gnats@gnu.org>
Subject: Re: Subject line processing in Gnats 4.0
Date: Tue, 11 Dec 2001 21:45:00 -0000	[thread overview]
Message-ID: <004101c182cf$d703b4b0$2b6b6fc0@shockwave.org> (raw)
Message-ID: <20011211214500._EROfZY9nhAlCNbZRl4RrBk18fQlNAS9UOp6gZL5YHY@z> (raw)
In-Reply-To: <C53744A44FBC9B4BAE90EB41D2C09AC205223F@proton.jnpr.net>

Negative Dirk,
I had it behave that way before, and it sucked.  Every time someone sent in
anything like "OS/2" it would append it to PR #2.
Instead, I wrote a script called refile_pr (I think it may still be in my
home directory or under bin/... that solved this problem).
If it's gone, I can tell you how to recreate it.  WIth gnats 4.0, it's
trivial, about 5 lines of real code.

----- Original Message -----
From: "Dirk Bergstrom" <dirk@juniper.net>
To: "Milan Zamazal" <pdm@zamazal.org>; "Michael Richardson"
<mcr@sandelman.ottawa.on.ca>
Cc: <help-gnats@gnu.org>
Sent: Tuesday, December 11, 2001 6:10 PM
Subject: RE: Subject line processing in Gnats 4.0


> i've been wrestling with this problem for some time (we've been running
> 4.0a for over a year...), and i've been meaning to send this to the list
> for a while:
>
> summary:
> at my company, we have been having some difficulties with gnats'
> handling of email replies to PRs.  gnats checks the subject of incoming
> mail, and if it matches a fairly restrictive pattern (must look like a
> reply), the message is appended to the relevant PR.  if there is no
> match, a new PR is created.  this often leads to creation of bogus PRs,
> because the matching expression is too restrictive.  i propose that we
> remove the restriction, and append *all* messages with subjects matching
>
> a PR to that PR.
>
> detailed explanation:
> when a message is filed by queue-pr (via file-pr), gnats scans the
> subject line for the following regex (line 575 in file-pr.c):
>
> "(.*re[ \t]*(\\[[0-9]+\\])?:)?[ \t]*([-a-z0-9_+.]*[:/][ \t]*([0-9]+))"
>
> which (sort of) translates to a regex of /.*(re:)? <category>/<pr_num>/.
> if it
> finds this pattern, the message is appended to pr_num; if not, gnats
> creates a new PR, using the subject as synopsis, and body as
> description.
>
> this only works if people using gnats pay close attention to the subject
>
> of their emails.  in the real world, however, developers forward
> messages, they use mailers that insert extra cruft in the subject line
> (email addresses, names, etc), and sometimes gnats is used in concert
> with a different bug-tracking system, which inserts it's own tracking
> number in the subject.  whatever the cause, the result is a bogus PR,
> which clutters up the system, confuses developers and support staff, and
>
> takes time and energy to close/expunge.
>
> these subjects do the Right Thing:
>
> *) re: compiler/9876: compiled code runs backwards
> *) serial-port/1234: cannot process frosted flakes
>
> but these subjects all do the Wrong Thing (create new PR, instead of
> appending):
>
> *) Re: FW: sw-kern-sanders/16543: kernel panic on gunshot
> *) PR 12345
> *) Fw: sw-rip-vnwnkl/10795: The routing subsystem is asleep
> *) RE: 2001-0821-021: hw-pr0n/16413 FPC shows pictures of naked ladies
> on reboot
>
> (basically, anything in front of the category that's not "re:" bombs.)
>
> i believe that the current behavior violates the principle of least
> surprise -- if i send a message to bugs with a subject "re: fw:
> sw-foo/1234", i expect that gnats will append it to PR 1234.  opening a
> new PR is *not* what i intend.
>
> solution:
> it's not clear to me why the regex is so restrictive.  i think it would
> make more sense for gnats to assume that any message with a parseable PR
>
> identifier (<category>/<pr_num>) in the subject should be appended to
> that PR.  that would allow for all the real-world messages to be
> processed in a manner that would not surprise the sender.
>
> furthermore, i think it should also accept "PR<pr_num>", if it is the
> first reasonable text in the subject, a regex along the lines of "^[
> \t]*((re|fw):)?[ \t]*pr([0-9]+)".  i often see bogus PRs with this
> synopsis, which were clearly intended to be part of <pr_num>, not
> separate PRs.  however, this would be a more extreme change, and might
> have unforseen consequences...
>
> does anyone see a reason to keep the restrictive regex?
>
> --
> Dirk Bergstrom               dirk@juniper.net
> _____________________________________________
> Juniper Networks Inc.,          Computer Geek
> Tel: 707.433.0564           Fax: 707.433.0769
>
> > -----Original Message-----
> > From: Milan Zamazal [ mailto:pdm@zamazal.org ]
> > Sent: Saturday, December 08, 2001 3:23 PM
> > To: Michael Richardson
> > Cc: help-gnats@gnu.org
> > Subject: Re: Subject line processing in Gnats 4.0
> >
> >
> > >>>>> "MR" == Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
> >
> >     MR>   Following the code through, it calls sends SUBM to the
> >     MR> server... and there is some heuristic in the gnatsd that sees
> >     MR> the subject line. And this has worked... sometimes.
> > But I have a
> >     MR> number of times it hasn't worked, and new PRs were created. I
> >     MR> can share them if this isn't a known problem.
> >
> > The problem is not known to me.  Please provide me with the details.
> >
> > Thanks,
> >
> > Milan Zamazal
> >
> > --
> > It's amazing how much better you feel once you've given up hope.
> >                                                 (unknown source)
> >
> > _______________________________________________
> > Help-gnats mailing list
> > Help-gnats@gnu.org
> > http://mail.gnu.org/mailman/listinfo/help-gnats
> >
>
> _______________________________________________
> Help-gnats mailing list
> Help-gnats@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-gnats
>
>


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

  reply	other threads:[~2001-12-12  5:45 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-01  7:16 Dirk Bergstrom
2001-11-01  7:18 ` Paul Traina [this message]
2001-11-01 14:36   ` Michael Richardson
2001-12-12 11:55     ` Michael Richardson
2001-12-11 21:45   ` Paul Traina
2001-11-01 14:36 ` Subject line processing in Gnats 4.0 , Michael Richardson
2001-12-12 11:54   ` Michael Richardson
2001-11-02  5:50 ` Subject line processing in Gnats 4.0 Milan Zamazal
2001-11-02  5:57   ` Michael Richardson
2001-12-12 15:43     ` Michael Richardson
2001-11-04  0:17   ` Yngve Svendsen
2001-12-13 12:30     ` Yngve Svendsen
2001-11-06  7:43   ` Chad C. Walstrom
2001-11-10  8:07     ` Milan Zamazal
2001-12-15  7:24       ` Milan Zamazal
2001-12-13 21:36     ` Chad C. Walstrom
2001-12-12 15:06   ` Milan Zamazal
2001-12-11 18:12 ` Dirk Bergstrom
  -- strict thread matches above, loose matches on Subject: below --
2001-11-06  5:58 Dirk Bergstrom
2001-11-09 14:17 ` Milan Zamazal
2001-11-19  0:36   ` Milan Zamazal
2001-12-23 12:36     ` Milan Zamazal
2001-12-15  7:24   ` Milan Zamazal
2001-12-13 15:09 ` Dirk Bergstrom
2001-11-02  5:49 Dirk Bergstrom
2001-11-03  1:41 ` Paul Traina
2001-12-13  9:50   ` Paul Traina
2001-11-06  5:19 ` Milan Zamazal
2001-12-13 14:39   ` Milan Zamazal
2001-12-12 14:20 ` Dirk Bergstrom
2001-11-01 15:18 Dirk Bergstrom
2001-12-12 13:03 ` Dirk Bergstrom
2001-10-28 13:34 Michael Richardson
2001-10-29 17:36 ` Milan Zamazal
2001-12-09  6:33   ` Milan Zamazal
2001-12-07 14:27 ` Michael Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='004101c182cf$d703b4b0$2b6b6fc0@shockwave.org' \
    --to=pst@juniper.net \
    --cc=dirk@juniper.net \
    --cc=help-gnats@gnu.org \
    --cc=mcr@sandelman.ottawa.on.ca \
    --cc=pdm@zamazal.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).