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
next prev parent 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).