* RE: Subject line processing in Gnats 4.0
@ 2001-11-02 5:49 Dirk Bergstrom
2001-11-03 1:41 ` Paul Traina
` (2 more replies)
0 siblings, 3 replies; 34+ messages in thread
From: Dirk Bergstrom @ 2001-11-02 5:49 UTC (permalink / raw)
To: help-gnats
paul traina writes:
> 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.
mr. traina makes a good point (he does that rather often). i had been wrestling with this, with no great success. it's why the idea had been sitting in my files for months. now that my memory has been jogged, i remember a couple of solutions i'd had in mind. in order of increasing radicalism:
*) accept FW: as well as RE: -- change the subject pattern thusly:
- "(.*re[ \t]*(\\[[0-9]+\\])?:)?[ \t]*([-a-z0-9_+.]*[:/][ \t]*([0-9]+))"
+ "(.*(re|fwd?)[ \t]*(\\[[0-9]+\\])?:)?[ \t]*([-a-z0-9_+.]*[:/][ \t]*([0-9]+))"
this will require adjusting what parenthetical expression is saved out of the match.
*) gnats currently accepts things like "sw-foo: 1234" instead of "sw-foo/1234". i'm guessing that the former is an antiquated form, since gnats doesn't emit it anymore. people don't use it, but they *do* use "PR1234". adjust the regex appropriately:
+ "(.*(re|fwd?)[ \t]*(\\[[0-9]+\\])?:)?[ \t]*(([-a-z0-9_+.]*/)|pr)([0-9]+))"
this will require some futher munging of code, since the stuff that pulls out and uses <category>/<number> will have to learn to contend with PR<number>. since it really isn't necessary to use category to pull up the PR, it might be best to change the regex to save only the number, and not the category/number pair. then we could just hack out the additional parsing code.
i think that the first change is the minimum we should do.
--
Dirk Bergstrom dirk@juniper.net
_____________________________________________
Juniper Networks Inc., Computer Geek
Tel: 707.433.0564 Fax: 707.433.0769
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: Subject line processing in Gnats 4.0
2001-11-02 5:49 Subject line processing in Gnats 4.0 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-12 14:20 ` Dirk Bergstrom
2 siblings, 1 reply; 34+ messages in thread
From: Paul Traina @ 2001-11-03 1:41 UTC (permalink / raw)
To: Dirk Bergstrom, help-gnats
Funny, because I *did* change the regexp to accept PR/ as a generic
category. Did that code get lost in 4?
By the way, refile-pr was written for 4.
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-02 5:49 Subject line processing in Gnats 4.0 Dirk Bergstrom
2001-11-03 1:41 ` Paul Traina
@ 2001-11-06 5:19 ` Milan Zamazal
2001-12-13 14:39 ` Milan Zamazal
2001-12-12 14:20 ` Dirk Bergstrom
2 siblings, 1 reply; 34+ messages in thread
From: Milan Zamazal @ 2001-11-06 5:19 UTC (permalink / raw)
To: Dirk Bergstrom; +Cc: help-gnats
>>>>> "DB" == Dirk Bergstrom <dirk@juniper.net> writes:
DB> *) accept FW: as well as RE: -- change the subject pattern
DB> thusly:
This is insufficient, since my mail client generates something
completely different of "FW" on forwarding and some other software
authors think it's a good idea to replace "Re:" with its "translation"
to the users' language.
DB> *) gnats currently accepts things like "sw-foo: 1234" instead of
DB> "sw-foo/1234". i'm guessing that the former is an antiquated
DB> form, since gnats doesn't emit it anymore.
I agree we could/should drop the colon form.
DB> people don't use it, but they *do* use "PR1234". adjust the
DB> regex appropriately:
DB> + "(.*(re|fwd?)[ \t]*(\\[[0-9]+\\])?:)?[ \t]*(([-a-z0-9_+.]*/)|pr)([0-9]+))"
OK. How about the spaces between "PR" and the number?
DB> this will require some futher munging of code, since the stuff
DB> that pulls out and uses <category>/<number> will have to learn
DB> to contend with PR<number>. since it really isn't necessary to
DB> use category to pull up the PR, it might be best to change the
DB> regex to save only the number, and not the category/number pair.
DB> then we could just hack out the additional parsing code.
>>>>> "PT" == Paul Traina <pst@juniper.net> writes:
PT> Funny, because I *did* change the regexp to accept PR/ as a
PT> generic category. Did that code get lost in 4?
The current regexp contains the fragment
([-a-z0-9_+.]*[:/][ \t]*([0-9]+))
that matches "PR/" automatically. Dirk's point is to include "PR"
without the slash as well.
PT> By the way, refile-pr was written for 4.
Very well. :-)
Well, to summarize, I suggest the following:
- Not to try to match "re", "fw", etc. and simply look for a substring
as stated below.
- Accept "\<CATEGORY/NUMBER" where CATEGORY is a valid category name and
PR NUMBER is present in CATEGORY.
- Accept "\<PR[ \t/]*NUMBER" where "PR" must be all capitals and NUMBER
corresponds to an existing PR number.
Would it serve the purpose in an acceptable way?
Regards,
Milan Zamazal
--
Omigod, it's a flame war about a flame war. You know, a meta-flame war!
Kenny Tilton in comp.lang.lisp
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: Subject line processing in Gnats 4.0
2001-11-06 5:19 ` Milan Zamazal
@ 2001-12-13 14:39 ` Milan Zamazal
0 siblings, 0 replies; 34+ messages in thread
From: Milan Zamazal @ 2001-12-13 14:39 UTC (permalink / raw)
To: Dirk Bergstrom; +Cc: help-gnats
>>>>> "DB" == Dirk Bergstrom <dirk@juniper.net> writes:
DB> *) accept FW: as well as RE: -- change the subject pattern
DB> thusly:
This is insufficient, since my mail client generates something
completely different of "FW" on forwarding and some other software
authors think it's a good idea to replace "Re:" with its "translation"
to the users' language.
DB> *) gnats currently accepts things like "sw-foo: 1234" instead of
DB> "sw-foo/1234". i'm guessing that the former is an antiquated
DB> form, since gnats doesn't emit it anymore.
I agree we could/should drop the colon form.
DB> people don't use it, but they *do* use "PR1234". adjust the
DB> regex appropriately:
DB> + "(.*(re|fwd?)[ \t]*(\\[[0-9]+\\])?:)?[ \t]*(([-a-z0-9_+.]*/)|pr)([0-9]+))"
OK. How about the spaces between "PR" and the number?
DB> this will require some futher munging of code, since the stuff
DB> that pulls out and uses <category>/<number> will have to learn
DB> to contend with PR<number>. since it really isn't necessary to
DB> use category to pull up the PR, it might be best to change the
DB> regex to save only the number, and not the category/number pair.
DB> then we could just hack out the additional parsing code.
>>>>> "PT" == Paul Traina <pst@juniper.net> writes:
PT> Funny, because I *did* change the regexp to accept PR/ as a
PT> generic category. Did that code get lost in 4?
The current regexp contains the fragment
([-a-z0-9_+.]*[:/][ \t]*([0-9]+))
that matches "PR/" automatically. Dirk's point is to include "PR"
without the slash as well.
PT> By the way, refile-pr was written for 4.
Very well. :-)
Well, to summarize, I suggest the following:
- Not to try to match "re", "fw", etc. and simply look for a substring
as stated below.
- Accept "\<CATEGORY/NUMBER" where CATEGORY is a valid category name and
PR NUMBER is present in CATEGORY.
- Accept "\<PR[ \t/]*NUMBER" where "PR" must be all capitals and NUMBER
corresponds to an existing PR number.
Would it serve the purpose in an acceptable way?
Regards,
Milan Zamazal
--
Omigod, it's a flame war about a flame war. You know, a meta-flame war!
Kenny Tilton in comp.lang.lisp
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Subject line processing in Gnats 4.0
2001-11-02 5:49 Subject line processing in Gnats 4.0 Dirk Bergstrom
2001-11-03 1:41 ` Paul Traina
2001-11-06 5:19 ` Milan Zamazal
@ 2001-12-12 14:20 ` Dirk Bergstrom
2 siblings, 0 replies; 34+ messages in thread
From: Dirk Bergstrom @ 2001-12-12 14:20 UTC (permalink / raw)
To: help-gnats
paul traina writes:
> 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.
mr. traina makes a good point (he does that rather often). i had been wrestling with this, with no great success. it's why the idea had been sitting in my files for months. now that my memory has been jogged, i remember a couple of solutions i'd had in mind. in order of increasing radicalism:
*) accept FW: as well as RE: -- change the subject pattern thusly:
- "(.*re[ \t]*(\\[[0-9]+\\])?:)?[ \t]*([-a-z0-9_+.]*[:/][ \t]*([0-9]+))"
+ "(.*(re|fwd?)[ \t]*(\\[[0-9]+\\])?:)?[ \t]*([-a-z0-9_+.]*[:/][ \t]*([0-9]+))"
this will require adjusting what parenthetical expression is saved out of the match.
*) gnats currently accepts things like "sw-foo: 1234" instead of "sw-foo/1234". i'm guessing that the former is an antiquated form, since gnats doesn't emit it anymore. people don't use it, but they *do* use "PR1234". adjust the regex appropriately:
+ "(.*(re|fwd?)[ \t]*(\\[[0-9]+\\])?:)?[ \t]*(([-a-z0-9_+.]*/)|pr)([0-9]+))"
this will require some futher munging of code, since the stuff that pulls out and uses <category>/<number> will have to learn to contend with PR<number>. since it really isn't necessary to use category to pull up the PR, it might be best to change the regex to save only the number, and not the category/number pair. then we could just hack out the additional parsing code.
i think that the first change is the minimum we should do.
--
Dirk Bergstrom dirk@juniper.net
_____________________________________________
Juniper Networks Inc., Computer Geek
Tel: 707.433.0564 Fax: 707.433.0769
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Subject line processing in Gnats 4.0
@ 2001-11-06 5:58 Dirk Bergstrom
2001-11-09 14:17 ` Milan Zamazal
2001-12-13 15:09 ` Dirk Bergstrom
0 siblings, 2 replies; 34+ messages in thread
From: Dirk Bergstrom @ 2001-11-06 5:58 UTC (permalink / raw)
To: Milan Zamazal; +Cc: help-gnats
> DB> *) accept FW: as well as RE: -- change the subject pattern
> DB> thusly:
> This is insufficient, since my mail client generates something
> completely different of "FW" on forwarding and some other software
> authors think it's a good idea to replace "Re:" with its "translation"
> to the users' language.
yes yngve pointed this out as well. I18N rears it's head. i agree that
it's insufficient.
> - Accept "\<CATEGORY/NUMBER" where CATEGORY is a valid
> category name and
> PR NUMBER is present in CATEGORY.
i think this will cause problems -- as yngve pointed out, PRs often
change categories, and someone might reply to a PR that has since
changed. i think the rule should be:
Accept "\<CATEGORY/NUMBER" where CATEGORY is a valid category
name and NUMBER is a valid PR number (in any category).
let's not worry about deleted categories -- that's probably a very
infrequent occurrence, and it could get ugly to code around...
> - Accept "\<PR[ \t/]*NUMBER" where "PR" must be all capitals
> and NUMBER
> corresponds to an existing PR number.
this is good.
> Would it serve the purpose in an acceptable way?
hmmm, we need to make sure that the edge-cases are covered. for
instance, what happens with this subject "re: sw-foo/1234: Compilation
fails on OS/2"? what about some strange situation where the false hit
came *before* the category/number pair, like a mailing list post: "FW:
[OS/2 users] Re: sw-foo/1234: bar baz quux"? yes, these are unlikely,
but it's going to be *very* confusing to the gnats-admin that has to
figure out why nobody can reply to one of their PRs...
other than that, i'm all for the change.
--
Dirk Bergstrom dirk@juniper.net
_____________________________________________
Juniper Networks Inc., Computer Geek
Tel: 707.433.0564 Fax: 707.433.0769
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-06 5:58 Dirk Bergstrom
@ 2001-11-09 14:17 ` Milan Zamazal
2001-11-19 0:36 ` Milan Zamazal
2001-12-15 7:24 ` Milan Zamazal
2001-12-13 15:09 ` Dirk Bergstrom
1 sibling, 2 replies; 34+ messages in thread
From: Milan Zamazal @ 2001-11-09 14:17 UTC (permalink / raw)
To: Dirk Bergstrom; +Cc: help-gnats
>>>>> "DB" == Dirk Bergstrom <dirk@juniper.net> writes:
>> - Accept "\<CATEGORY/NUMBER" where CATEGORY is a valid category
>> name and PR NUMBER is present in CATEGORY.
DB> i think this will cause problems -- as yngve pointed out, PRs
DB> often change categories, and someone might reply to a PR that
DB> has since changed. i think the rule should be: Accept
DB> "\<CATEGORY/NUMBER" where CATEGORY is a valid category name and
DB> NUMBER is a valid PR number (in any category).
Yes, Yngve has made a good point, I agree.
DB> let's not worry about deleted categories -- that's probably a
DB> very infrequent occurrence, and it could get ugly to code
DB> around...
OK.
DB> hmmm, we need to make sure that the edge-cases are covered. for
DB> instance, what happens with this subject "re: sw-foo/1234:
DB> Compilation fails on OS/2"?
This is only a problem when there's the category `os' and there's an
especially important PR #2 that can't be deleted. Not much serious
problem, IMO.
DB> what about some strange situation where the false hit came
DB> *before* the category/number pair, like a mailing list post:
DB> "FW: [OS/2 users] Re: sw-foo/1234: bar baz quux"?
We should probably consider all possible matches and use the first valid
one.
Regards,
Milan Zamazal
--
The world is not something you can wrap your head around without needing years
of experience. -- Kent M. Pitman in comp.lang.lisp
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: Subject line processing in Gnats 4.0
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
1 sibling, 1 reply; 34+ messages in thread
From: Milan Zamazal @ 2001-11-19 0:36 UTC (permalink / raw)
To: Dirk Bergstrom; +Cc: help-gnats
The matching was adjusted according to our consensus, except that I
didn't bother with the matching cycle, only the first possible match is
considered. I haven't tested it, would you like to do it?
Regards,
Milan Zamazal
--
http://www.zamazal.org
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-09 14:17 ` Milan Zamazal
2001-11-19 0:36 ` Milan Zamazal
@ 2001-12-15 7:24 ` Milan Zamazal
1 sibling, 0 replies; 34+ messages in thread
From: Milan Zamazal @ 2001-12-15 7:24 UTC (permalink / raw)
To: Dirk Bergstrom; +Cc: help-gnats
>>>>> "DB" == Dirk Bergstrom <dirk@juniper.net> writes:
>> - Accept "\<CATEGORY/NUMBER" where CATEGORY is a valid category
>> name and PR NUMBER is present in CATEGORY.
DB> i think this will cause problems -- as yngve pointed out, PRs
DB> often change categories, and someone might reply to a PR that
DB> has since changed. i think the rule should be: Accept
DB> "\<CATEGORY/NUMBER" where CATEGORY is a valid category name and
DB> NUMBER is a valid PR number (in any category).
Yes, Yngve has made a good point, I agree.
DB> let's not worry about deleted categories -- that's probably a
DB> very infrequent occurrence, and it could get ugly to code
DB> around...
OK.
DB> hmmm, we need to make sure that the edge-cases are covered. for
DB> instance, what happens with this subject "re: sw-foo/1234:
DB> Compilation fails on OS/2"?
This is only a problem when there's the category `os' and there's an
especially important PR #2 that can't be deleted. Not much serious
problem, IMO.
DB> what about some strange situation where the false hit came
DB> *before* the category/number pair, like a mailing list post:
DB> "FW: [OS/2 users] Re: sw-foo/1234: bar baz quux"?
We should probably consider all possible matches and use the first valid
one.
Regards,
Milan Zamazal
--
The world is not something you can wrap your head around without needing years
of experience. -- Kent M. Pitman in comp.lang.lisp
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Subject line processing in Gnats 4.0
2001-11-06 5:58 Dirk Bergstrom
2001-11-09 14:17 ` Milan Zamazal
@ 2001-12-13 15:09 ` Dirk Bergstrom
1 sibling, 0 replies; 34+ messages in thread
From: Dirk Bergstrom @ 2001-12-13 15:09 UTC (permalink / raw)
To: Milan Zamazal; +Cc: help-gnats
> DB> *) accept FW: as well as RE: -- change the subject pattern
> DB> thusly:
> This is insufficient, since my mail client generates something
> completely different of "FW" on forwarding and some other software
> authors think it's a good idea to replace "Re:" with its "translation"
> to the users' language.
yes yngve pointed this out as well. I18N rears it's head. i agree that
it's insufficient.
> - Accept "\<CATEGORY/NUMBER" where CATEGORY is a valid
> category name and
> PR NUMBER is present in CATEGORY.
i think this will cause problems -- as yngve pointed out, PRs often
change categories, and someone might reply to a PR that has since
changed. i think the rule should be:
Accept "\<CATEGORY/NUMBER" where CATEGORY is a valid category
name and NUMBER is a valid PR number (in any category).
let's not worry about deleted categories -- that's probably a very
infrequent occurrence, and it could get ugly to code around...
> - Accept "\<PR[ \t/]*NUMBER" where "PR" must be all capitals
> and NUMBER
> corresponds to an existing PR number.
this is good.
> Would it serve the purpose in an acceptable way?
hmmm, we need to make sure that the edge-cases are covered. for
instance, what happens with this subject "re: sw-foo/1234: Compilation
fails on OS/2"? what about some strange situation where the false hit
came *before* the category/number pair, like a mailing list post: "FW:
[OS/2 users] Re: sw-foo/1234: bar baz quux"? yes, these are unlikely,
but it's going to be *very* confusing to the gnats-admin that has to
figure out why nobody can reply to one of their PRs...
other than that, i'm all for the change.
--
Dirk Bergstrom dirk@juniper.net
_____________________________________________
Juniper Networks Inc., Computer Geek
Tel: 707.433.0564 Fax: 707.433.0769
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Subject line processing in Gnats 4.0
@ 2001-11-01 15:18 Dirk Bergstrom
2001-12-12 13:03 ` Dirk Bergstrom
0 siblings, 1 reply; 34+ messages in thread
From: Dirk Bergstrom @ 2001-11-01 15:18 UTC (permalink / raw)
To: help-gnats
paul's refile-pr script may be found here:
http://www.otisbean.com/gnats/refile-pr.sh
you give it the number of a PR to append to, and a list of mistakenly created PRs, and it appends the relevant info from each bogus PR to the master PR, deleting each bogus PR in the process. as written, the script is a bit dangerous -- get your args out of order, and you've put a big hole in your foot -- but it's the right tool for the job.
--
Dirk Bergstrom dirk@juniper.net
_____________________________________________
Juniper Networks Inc., Computer Geek
Tel: 707.433.0564 Fax: 707.433.0769
> -----Original Message-----
> From: Paul Traina
> Sent: Tuesday, December 11, 2001 9:43 PM
> To: Dirk Bergstrom; Milan Zamazal; Michael Richardson
> Cc: help-gnats@gnu.org
> Subject: Re: Subject line processing in Gnats 4.0
>
>
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Subject line processing in Gnats 4.0
2001-11-01 15:18 Dirk Bergstrom
@ 2001-12-12 13:03 ` Dirk Bergstrom
0 siblings, 0 replies; 34+ messages in thread
From: Dirk Bergstrom @ 2001-12-12 13:03 UTC (permalink / raw)
To: help-gnats
paul's refile-pr script may be found here:
http://www.otisbean.com/gnats/refile-pr.sh
you give it the number of a PR to append to, and a list of mistakenly created PRs, and it appends the relevant info from each bogus PR to the master PR, deleting each bogus PR in the process. as written, the script is a bit dangerous -- get your args out of order, and you've put a big hole in your foot -- but it's the right tool for the job.
--
Dirk Bergstrom dirk@juniper.net
_____________________________________________
Juniper Networks Inc., Computer Geek
Tel: 707.433.0564 Fax: 707.433.0769
> -----Original Message-----
> From: Paul Traina
> Sent: Tuesday, December 11, 2001 9:43 PM
> To: Dirk Bergstrom; Milan Zamazal; Michael Richardson
> Cc: help-gnats@gnu.org
> Subject: Re: Subject line processing in Gnats 4.0
>
>
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Subject line processing in Gnats 4.0
@ 2001-11-01 7:16 Dirk Bergstrom
2001-11-01 7:18 ` Paul Traina
` (2 more replies)
0 siblings, 3 replies; 34+ messages in thread
From: Dirk Bergstrom @ 2001-11-01 7:16 UTC (permalink / raw)
To: Milan Zamazal, Michael Richardson; +Cc: help-gnats
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
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: Subject line processing in Gnats 4.0
2001-11-01 7:16 Dirk Bergstrom
@ 2001-11-01 7:18 ` Paul Traina
2001-11-01 14:36 ` Michael Richardson
2001-12-11 21:45 ` Paul Traina
2001-11-02 5:50 ` Milan Zamazal
2001-12-11 18:12 ` Dirk Bergstrom
2 siblings, 2 replies; 34+ messages in thread
From: Paul Traina @ 2001-11-01 7:18 UTC (permalink / raw)
To: Dirk Bergstrom, Milan Zamazal, Michael Richardson; +Cc: help-gnats
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-01 7:18 ` Paul Traina
@ 2001-11-01 14:36 ` Michael Richardson
2001-12-12 11:55 ` Michael Richardson
2001-12-11 21:45 ` Paul Traina
1 sibling, 1 reply; 34+ messages in thread
From: Michael Richardson @ 2001-11-01 14:36 UTC (permalink / raw)
To: Paul Traina; +Cc: Dirk Bergstrom, Milan Zamazal, help-gnats
>>>>> "Paul" == Paul Traina <pst@juniper.net> writes:
Paul> I had it behave that way before, and it sucked. Every time someone sent in
Paul> anything like "OS/2" it would append it to PR #2.
Simple suggestion - make the PR#s have leading zeros.
Or include more stuff to match on.
The nonsense with leading stuff before the Re: really is a serious problem.
Paul> Instead, I wrote a script called refile_pr (I think it may still be in my
Paul> home directory or under bin/... that solved this problem).
Paul> If it's gone, I can tell you how to recreate it. WIth gnats 4.0, it's
Paul> trivial, about 5 lines of real code.
Please post it.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: Subject line processing in Gnats 4.0
2001-11-01 14:36 ` Michael Richardson
@ 2001-12-12 11:55 ` Michael Richardson
0 siblings, 0 replies; 34+ messages in thread
From: Michael Richardson @ 2001-12-12 11:55 UTC (permalink / raw)
To: Paul Traina; +Cc: Dirk Bergstrom, Milan Zamazal, help-gnats
>>>>> "Paul" == Paul Traina <pst@juniper.net> writes:
Paul> I had it behave that way before, and it sucked. Every time someone sent in
Paul> anything like "OS/2" it would append it to PR #2.
Simple suggestion - make the PR#s have leading zeros.
Or include more stuff to match on.
The nonsense with leading stuff before the Re: really is a serious problem.
Paul> Instead, I wrote a script called refile_pr (I think it may still be in my
Paul> home directory or under bin/... that solved this problem).
Paul> If it's gone, I can tell you how to recreate it. WIth gnats 4.0, it's
Paul> trivial, about 5 lines of real code.
Please post it.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-01 7:18 ` Paul Traina
2001-11-01 14:36 ` Michael Richardson
@ 2001-12-11 21:45 ` Paul Traina
1 sibling, 0 replies; 34+ messages in thread
From: Paul Traina @ 2001-12-11 21:45 UTC (permalink / raw)
To: Dirk Bergstrom, Milan Zamazal, Michael Richardson; +Cc: help-gnats
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-01 7:16 Dirk Bergstrom
2001-11-01 7:18 ` Paul Traina
@ 2001-11-02 5:50 ` Milan Zamazal
2001-11-02 5:57 ` Michael Richardson
` (3 more replies)
2001-12-11 18:12 ` Dirk Bergstrom
2 siblings, 4 replies; 34+ messages in thread
From: Milan Zamazal @ 2001-11-02 5:50 UTC (permalink / raw)
To: Dirk Bergstrom; +Cc: Michael Richardson, help-gnats
[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]
>>>>> "DB" == Dirk Bergstrom <dirk@juniper.net> writes:
DB> solution: it's not clear to me why the regex is so restrictive.
DB> i think it would make more sense for gnats to assume that any
DB> message with a parseable PR identifier (<category>/<pr_num>) in
DB> the subject should be appended to that PR. that would allow for
DB> all the real-world messages to be processed in a manner that
DB> would not surprise the sender.
I agree, with an additional restriction described below.
DB> furthermore, i think it should also accept "PR<pr_num>", if it is the
DB> first reasonable text in the subject, a regex along the lines of "^[
DB> \t]*((re|fw):)?[ \t]*pr([0-9]+)". i often see bogus PRs with this
DB> synopsis, which were clearly intended to be part of <pr_num>, not
DB> separate PRs.
I don't like this one. I can imagine the following subject:
PR 1234 at foo.org provides the fix for the PR 567
Generally, I think it's better to create a new PR than to have an answer
in a wrong place.
>>>>> "PT" == Paul Traina <pst@juniper.net> writes:
PT> Negative Dirk, I had it behave that way before, and it sucked.
PT> Every time someone sent in anything like "OS/2" it would append
PT> it to PR #2.
I don't think it's an unsolvable problem. The \<CATEGORY/NUMBER
expression should be accepted only if CATEGORY matches an existing
category (case-insensitive match) and NUMBER matches a PR in that
category. Then the unlucky administrator, who created the `os'
category, could simply remove/renumber its PR #2 and the problem is
gone.
PT> Instead, I wrote a script called refile_pr (I think it may still
PT> be in my home directory or under bin/... that solved this
PT> problem). If it's gone, I can tell you how to recreate it.
PT> WIth gnats 4.0, it's trivial, about 5 lines of real code.
The script is waiting in my long and old queue of GNATS mails for future
processing. :-( Here it is (it was sent by Paul to this mail list some
time ago):
[-- Attachment #2: refile-pr --]
[-- Type: application/octet-stream, Size: 3271 bytes --]
#!/bin/sh
# Program to submit problem reports for GNATS.
# Copyright (C) 1999 Free Software Foundation, Inc.
# Contributed by Bob Manson (manson@juniper.net).
#
# This file is part of GNU GNATS.
#
# GNU GNATS is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# GNU GNATS is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU GNATS; see the file COPYING. If not, write to
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
debug_print=false # or echo to get output.
LIBEXECDIR=/usr/local/libexec
BINDIR=/usr/local/bin
EDIT_USER=
EDIT_PASSWD=
version=4.0-alpha
usage="
Usage: refile-pr [-V|--version] [-h|--help] [-d|--database database_name]
[-H|--host hostname] [-P|--port port_number]
[-v|--user userid] [-w|--passwd password]
-o|--original pr-to-attach-to <pr> [<pr> ...]
"
# Parse command line. We don't really need to do this, but that's ok.
while [ $# -gt 0 ]; do
case "$1" in
-V|--version|--ve*)
echo "$version"; exit 0
;;
-d | --database)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; GNATS_DB="--database=$1" ;;
-d=* | --database=*) GNATS_DB="$1" ;;
-H | --host)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; GNATS_HOST="--host=$1" ;;
-H=* | --host=*) GNATS_HOST="$1" ;;
-P | --port)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; GNATS_PORT="--port=$1" ;;
-P=* | --port=*) GNATS_PORT="$1" ;;
-v | --user)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; EDIT_USER="--user=$1" ;;
-v=* | --user=*) EDIT_USER="$1" ;;
-w | --passwd)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; EDIT_PASSWD="--passwd=$1" ;;
-w=* | --passwd=*) EDIT_PASSWD="$1" ;;
-o|--original*)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; ORIGINAL="$1" ;;
-h|--help*)
echo "$usage"; exit 0
;;
-*)
echo "$usage"; exit 1
;;
*)
break
;;
esac
shift
done
if [ $# = 0 ] ; then
echo "$0: missing PR's to refile under original PR" 1>&2
exit 1
fi
# set command here to always pass host and port, and directory if supplied
PR_EDIT="$LIBEXECDIR/gnats/pr-edit ${GNATS_HOST} ${GNATS_PORT} ${EDIT_USER} ${EDIT_PASSWD} ${GNATS_DB}"
QUERY_PR="$BINDIR/query-pr ${GNATS_HOST} ${GNATS_PORT} ${EDIT_USER} ${EDIT_PASSWD} ${GNATS_DB}"
QUERY_FMT='"Date: %s\nFrom: %s\nSubject: %s\n\n%s" Date: From: Subject: Description'
if [ "$ORIGINAL" = "" ]; then
echo "$0: original PR to refile under required" 1>&2
exit 1
fi
# Get data from bogus PRs
$QUERY_PR --format "$QUERY_FMT" "$@" | \
$PR_EDIT --append audit-trail $ORIGINAL && \
for pr in "$@" ; do
$PR_EDIT --user gnats --delete $pr
done
[-- Attachment #3: Type: text/plain, Size: 477 bytes --]
Could someone port/test it with GNATS 4, please? I could include it
into the distribution then.
>>>>> "MR" == Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
MR> Simple suggestion - make the PR#s have leading zeros.
That would be ugly, let's try nicer solutions first. :-)
Regards,
Milan Zamazal
--
When you're in a fight with an idiot, it's difficult for other people to tell
which one the idiot is. -- Bruce Perens in debian-devel
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: Subject line processing in Gnats 4.0
2001-11-02 5:50 ` Milan Zamazal
@ 2001-11-02 5:57 ` Michael Richardson
2001-12-12 15:43 ` Michael Richardson
2001-11-04 0:17 ` Yngve Svendsen
` (2 subsequent siblings)
3 siblings, 1 reply; 34+ messages in thread
From: Michael Richardson @ 2001-11-02 5:57 UTC (permalink / raw)
To: Milan Zamazal; +Cc: Dirk Bergstrom, help-gnats
-----BEGIN PGP SIGNED MESSAGE-----
Milan> Could someone port/test it with GNATS 4, please? I could include it
Milan> into the distribution then.
yes, I'll do that. I have more than a dozen PRs that are misfiled that I
have to fix. Back in a couple of hours.
>>>>> "MR" == Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
MR> Simple suggestion - make the PR#s have leading zeros.
Milan> That would be ugly, let's try nicer solutions first. :-)
But, it would work very easily :-)
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBPBfobYqHRg3pndX9AQG1bgP/VppRYDrIT6vKBDbHQxm+MzdapgdFqGe+
/mMxJE4M0HOrInPMvHFd9dxgoqyAn30t6XFFOUcWJJG8aKDVF3sfCwKNQXkhh4HQ
ryqY/1sEVJUyrDPi6pgyM8RlRVWRpr8cG7gC5EW++UUD/hNLzqPRIX1+IPINOvAX
KnvvC/ZOMkw=
=/yE1
-----END PGP SIGNATURE-----
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: Subject line processing in Gnats 4.0
2001-11-02 5:57 ` Michael Richardson
@ 2001-12-12 15:43 ` Michael Richardson
0 siblings, 0 replies; 34+ messages in thread
From: Michael Richardson @ 2001-12-12 15:43 UTC (permalink / raw)
To: Milan Zamazal; +Cc: Dirk Bergstrom, help-gnats
-----BEGIN PGP SIGNED MESSAGE-----
Milan> Could someone port/test it with GNATS 4, please? I could include it
Milan> into the distribution then.
yes, I'll do that. I have more than a dozen PRs that are misfiled that I
have to fix. Back in a couple of hours.
>>>>> "MR" == Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
MR> Simple suggestion - make the PR#s have leading zeros.
Milan> That would be ugly, let's try nicer solutions first. :-)
But, it would work very easily :-)
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBPBfobYqHRg3pndX9AQG1bgP/VppRYDrIT6vKBDbHQxm+MzdapgdFqGe+
/mMxJE4M0HOrInPMvHFd9dxgoqyAn30t6XFFOUcWJJG8aKDVF3sfCwKNQXkhh4HQ
ryqY/1sEVJUyrDPi6pgyM8RlRVWRpr8cG7gC5EW++UUD/hNLzqPRIX1+IPINOvAX
KnvvC/ZOMkw=
=/yE1
-----END PGP SIGNATURE-----
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-02 5:50 ` Milan Zamazal
2001-11-02 5:57 ` 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-12-12 15:06 ` Milan Zamazal
3 siblings, 1 reply; 34+ messages in thread
From: Yngve Svendsen @ 2001-11-04 0:17 UTC (permalink / raw)
To: Milan Zamazal, Dirk Bergstrom; +Cc: Michael Richardson, help-gnats
At 23:01 12.12.01 +0100, Milan Zamazal wrote:
> >>>>> "DB" == Dirk Bergstrom <dirk@juniper.net> writes:
>
> DB> solution: it's not clear to me why the regex is so restrictive.
> DB> i think it would make more sense for gnats to assume that any
> DB> message with a parseable PR identifier (<category>/<pr_num>) in
> DB> the subject should be appended to that PR. that would allow for
> DB> all the real-world messages to be processed in a manner that
> DB> would not surprise the sender.
>
>I agree, with an additional restriction described below.
I agree too, with the additional restriction that you propose, namely that
<category> should be an existing category name. We do need to be certain
not to attach any significance to the actual value of <category>, as long
as it is an existing category, since people may send follow-ups to PRs that
have since changed category.
This also allows us to get rid of the far-too-restrictive matching on "Re:"
at the start of the subject, since some internationalized e-mail clients
(at least MS Outlook) use localized equivalents, such as AW: (German) and
SV: (Norwegian).
Yngve Svendsen
GNATS doc guy
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-04 0:17 ` Yngve Svendsen
@ 2001-12-13 12:30 ` Yngve Svendsen
0 siblings, 0 replies; 34+ messages in thread
From: Yngve Svendsen @ 2001-12-13 12:30 UTC (permalink / raw)
To: Milan Zamazal, Dirk Bergstrom; +Cc: Michael Richardson, help-gnats
At 23:01 12.12.01 +0100, Milan Zamazal wrote:
> >>>>> "DB" == Dirk Bergstrom <dirk@juniper.net> writes:
>
> DB> solution: it's not clear to me why the regex is so restrictive.
> DB> i think it would make more sense for gnats to assume that any
> DB> message with a parseable PR identifier (<category>/<pr_num>) in
> DB> the subject should be appended to that PR. that would allow for
> DB> all the real-world messages to be processed in a manner that
> DB> would not surprise the sender.
>
>I agree, with an additional restriction described below.
I agree too, with the additional restriction that you propose, namely that
<category> should be an existing category name. We do need to be certain
not to attach any significance to the actual value of <category>, as long
as it is an existing category, since people may send follow-ups to PRs that
have since changed category.
This also allows us to get rid of the far-too-restrictive matching on "Re:"
at the start of the subject, since some internationalized e-mail clients
(at least MS Outlook) use localized equivalents, such as AW: (German) and
SV: (Norwegian).
Yngve Svendsen
GNATS doc guy
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-02 5:50 ` Milan Zamazal
2001-11-02 5:57 ` Michael Richardson
2001-11-04 0:17 ` Yngve Svendsen
@ 2001-11-06 7:43 ` Chad C. Walstrom
2001-11-10 8:07 ` Milan Zamazal
2001-12-13 21:36 ` Chad C. Walstrom
2001-12-12 15:06 ` Milan Zamazal
3 siblings, 2 replies; 34+ messages in thread
From: Chad C. Walstrom @ 2001-11-06 7:43 UTC (permalink / raw)
To: help-gnats
[-- Attachment #1: Type: text/plain, Size: 531 bytes --]
About PR's and subject line recognition. I think it'd be far more
useful to supply a "Reply-To:" of prnumber@bugs.domain.tld than to rely
upon the subject line. No ambiguity can be taken from that. Of course,
that requires a slight customization to both your email server and
gnats, but well worth it.
--
Chad Walstrom <chewie@wookimus.net> | a.k.a. ^chewie
http://www.wookimus.net/ | s.k.a. gunnarr
Get my public key, ICQ#, etc. $(mailx -s 'get info' chewie@wookimus.net)
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
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
1 sibling, 1 reply; 34+ messages in thread
From: Milan Zamazal @ 2001-11-10 8:07 UTC (permalink / raw)
To: Chad C. Walstrom; +Cc: help-gnats
>>>>> "CCW" == Chad C Walstrom <chewie@wookimus.net> writes:
CCW> About PR's and subject line recognition. I think it'd be far
CCW> more useful to supply a "Reply-To:" of prnumber@bugs.domain.tld
CCW> than to rely upon the subject line. No ambiguity can be taken
CCW> from that. Of course, that requires a slight customization to
CCW> both your email server and gnats, but well worth it.
I agree this works very well in many situations, however it's enough
non-trivial change to be made before 4.0. Right now, one can use the
scheme by subject checking and modifying in the script processing
@bugs.domain.tld.
Regards,
Milan Zamazal
--
Omigod, it's a flame war about a flame war. You know, a meta-flame war!
Kenny Tilton in comp.lang.lisp
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: Subject line processing in Gnats 4.0
2001-11-10 8:07 ` Milan Zamazal
@ 2001-12-15 7:24 ` Milan Zamazal
0 siblings, 0 replies; 34+ messages in thread
From: Milan Zamazal @ 2001-12-15 7:24 UTC (permalink / raw)
To: Chad C. Walstrom; +Cc: help-gnats
>>>>> "CCW" == Chad C Walstrom <chewie@wookimus.net> writes:
CCW> About PR's and subject line recognition. I think it'd be far
CCW> more useful to supply a "Reply-To:" of prnumber@bugs.domain.tld
CCW> than to rely upon the subject line. No ambiguity can be taken
CCW> from that. Of course, that requires a slight customization to
CCW> both your email server and gnats, but well worth it.
I agree this works very well in many situations, however it's enough
non-trivial change to be made before 4.0. Right now, one can use the
scheme by subject checking and modifying in the script processing
@bugs.domain.tld.
Regards,
Milan Zamazal
--
Omigod, it's a flame war about a flame war. You know, a meta-flame war!
Kenny Tilton in comp.lang.lisp
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-06 7:43 ` Chad C. Walstrom
2001-11-10 8:07 ` Milan Zamazal
@ 2001-12-13 21:36 ` Chad C. Walstrom
1 sibling, 0 replies; 34+ messages in thread
From: Chad C. Walstrom @ 2001-12-13 21:36 UTC (permalink / raw)
To: help-gnats
About PR's and subject line recognition. I think it'd be far more
useful to supply a "Reply-To:" of prnumber@bugs.domain.tld than to rely
upon the subject line. No ambiguity can be taken from that. Of course,
that requires a slight customization to both your email server and
gnats, but well worth it.
--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8GOicDMcLGCBsWv0RAoz8AJ9mfeELWvr5Y04LEo8ouMhbWt4tEQCgo+k3
j8dXXqudhlQDlaemPigDygs=
=Tt8n
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-02 5:50 ` Milan Zamazal
` (2 preceding siblings ...)
2001-11-06 7:43 ` Chad C. Walstrom
@ 2001-12-12 15:06 ` Milan Zamazal
3 siblings, 0 replies; 34+ messages in thread
From: Milan Zamazal @ 2001-12-12 15:06 UTC (permalink / raw)
To: Dirk Bergstrom; +Cc: Michael Richardson, help-gnats
[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]
>>>>> "DB" == Dirk Bergstrom <dirk@juniper.net> writes:
DB> solution: it's not clear to me why the regex is so restrictive.
DB> i think it would make more sense for gnats to assume that any
DB> message with a parseable PR identifier (<category>/<pr_num>) in
DB> the subject should be appended to that PR. that would allow for
DB> all the real-world messages to be processed in a manner that
DB> would not surprise the sender.
I agree, with an additional restriction described below.
DB> furthermore, i think it should also accept "PR<pr_num>", if it is the
DB> first reasonable text in the subject, a regex along the lines of "^[
DB> \t]*((re|fw):)?[ \t]*pr([0-9]+)". i often see bogus PRs with this
DB> synopsis, which were clearly intended to be part of <pr_num>, not
DB> separate PRs.
I don't like this one. I can imagine the following subject:
PR 1234 at foo.org provides the fix for the PR 567
Generally, I think it's better to create a new PR than to have an answer
in a wrong place.
>>>>> "PT" == Paul Traina <pst@juniper.net> writes:
PT> Negative Dirk, I had it behave that way before, and it sucked.
PT> Every time someone sent in anything like "OS/2" it would append
PT> it to PR #2.
I don't think it's an unsolvable problem. The \<CATEGORY/NUMBER
expression should be accepted only if CATEGORY matches an existing
category (case-insensitive match) and NUMBER matches a PR in that
category. Then the unlucky administrator, who created the `os'
category, could simply remove/renumber its PR #2 and the problem is
gone.
PT> Instead, I wrote a script called refile_pr (I think it may still
PT> be in my home directory or under bin/... that solved this
PT> problem). If it's gone, I can tell you how to recreate it.
PT> WIth gnats 4.0, it's trivial, about 5 lines of real code.
The script is waiting in my long and old queue of GNATS mails for future
processing. :-( Here it is (it was sent by Paul to this mail list some
time ago):
[-- Attachment #2: refile-pr --]
[-- Type: text/x-shellscript, Size: 3271 bytes --]
#!/bin/sh
# Program to submit problem reports for GNATS.
# Copyright (C) 1999 Free Software Foundation, Inc.
# Contributed by Bob Manson (manson@juniper.net).
#
# This file is part of GNU GNATS.
#
# GNU GNATS is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# GNU GNATS is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU GNATS; see the file COPYING. If not, write to
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
debug_print=false # or echo to get output.
LIBEXECDIR=/usr/local/libexec
BINDIR=/usr/local/bin
EDIT_USER=
EDIT_PASSWD=
version=4.0-alpha
usage="
Usage: refile-pr [-V|--version] [-h|--help] [-d|--database database_name]
[-H|--host hostname] [-P|--port port_number]
[-v|--user userid] [-w|--passwd password]
-o|--original pr-to-attach-to <pr> [<pr> ...]
"
# Parse command line. We don't really need to do this, but that's ok.
while [ $# -gt 0 ]; do
case "$1" in
-V|--version|--ve*)
echo "$version"; exit 0
;;
-d | --database)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; GNATS_DB="--database=$1" ;;
-d=* | --database=*) GNATS_DB="$1" ;;
-H | --host)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; GNATS_HOST="--host=$1" ;;
-H=* | --host=*) GNATS_HOST="$1" ;;
-P | --port)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; GNATS_PORT="--port=$1" ;;
-P=* | --port=*) GNATS_PORT="$1" ;;
-v | --user)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; EDIT_USER="--user=$1" ;;
-v=* | --user=*) EDIT_USER="$1" ;;
-w | --passwd)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; EDIT_PASSWD="--passwd=$1" ;;
-w=* | --passwd=*) EDIT_PASSWD="$1" ;;
-o|--original*)
if [ $# -eq 1 ]; then echo "$usage"; exit 1; fi
shift ; ORIGINAL="$1" ;;
-h|--help*)
echo "$usage"; exit 0
;;
-*)
echo "$usage"; exit 1
;;
*)
break
;;
esac
shift
done
if [ $# = 0 ] ; then
echo "$0: missing PR's to refile under original PR" 1>&2
exit 1
fi
# set command here to always pass host and port, and directory if supplied
PR_EDIT="$LIBEXECDIR/gnats/pr-edit ${GNATS_HOST} ${GNATS_PORT} ${EDIT_USER} ${EDIT_PASSWD} ${GNATS_DB}"
QUERY_PR="$BINDIR/query-pr ${GNATS_HOST} ${GNATS_PORT} ${EDIT_USER} ${EDIT_PASSWD} ${GNATS_DB}"
QUERY_FMT='"Date: %s\nFrom: %s\nSubject: %s\n\n%s" Date: From: Subject: Description'
if [ "$ORIGINAL" = "" ]; then
echo "$0: original PR to refile under required" 1>&2
exit 1
fi
# Get data from bogus PRs
$QUERY_PR --format "$QUERY_FMT" "$@" | \
$PR_EDIT --append audit-trail $ORIGINAL && \
for pr in "$@" ; do
$PR_EDIT --user gnats --delete $pr
done
^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Subject line processing in Gnats 4.0
2001-11-01 7:16 Dirk Bergstrom
2001-11-01 7:18 ` Paul Traina
2001-11-02 5:50 ` Milan Zamazal
@ 2001-12-11 18:12 ` Dirk Bergstrom
2 siblings, 0 replies; 34+ messages in thread
From: Dirk Bergstrom @ 2001-12-11 18:12 UTC (permalink / raw)
To: Milan Zamazal, Michael Richardson; +Cc: help-gnats
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Subject line processing in Gnats 4.0
@ 2001-10-28 13:34 Michael Richardson
2001-10-29 17:36 ` Milan Zamazal
2001-12-07 14:27 ` Michael Richardson
0 siblings, 2 replies; 34+ messages in thread
From: Michael Richardson @ 2001-10-28 13:34 UTC (permalink / raw)
To: help-gnats
In Gnats 3.0, one can append to a PR by sending email to gnats with the
category/XX PR number in the subject line. This just creates new PRs.
Following the code through, it calls sends SUBM to the server... and there
is some heuristic in the gnatsd that sees the subject line. And this has
worked... sometimes. But I have a number of times it hasn't worked, and new
PRs were created. I can share them if this isn't a known problem.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: Subject line processing in Gnats 4.0
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
1 sibling, 1 reply; 34+ messages in thread
From: Milan Zamazal @ 2001-10-29 17:36 UTC (permalink / raw)
To: Michael Richardson; +Cc: help-gnats
>>>>> "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
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: Subject line processing in Gnats 4.0
2001-10-29 17:36 ` Milan Zamazal
@ 2001-12-09 6:33 ` Milan Zamazal
0 siblings, 0 replies; 34+ messages in thread
From: Milan Zamazal @ 2001-12-09 6:33 UTC (permalink / raw)
To: Michael Richardson; +Cc: help-gnats
>>>>> "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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Subject line processing in Gnats 4.0
2001-10-28 13:34 Michael Richardson
2001-10-29 17:36 ` Milan Zamazal
@ 2001-12-07 14:27 ` Michael Richardson
1 sibling, 0 replies; 34+ messages in thread
From: Michael Richardson @ 2001-12-07 14:27 UTC (permalink / raw)
To: help-gnats
In Gnats 3.0, one can append to a PR by sending email to gnats with the
category/XX PR number in the subject line. This just creates new PRs.
Following the code through, it calls sends SUBM to the server... and there
is some heuristic in the gnatsd that sees the subject line. And this has
worked... sometimes. But I have a number of times it hasn't worked, and new
PRs were created. I can share them if this isn't a known problem.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2001-12-23 20:36 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-02 5:49 Subject line processing in Gnats 4.0 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
-- 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-01 15:18 Dirk Bergstrom
2001-12-12 13:03 ` Dirk Bergstrom
2001-11-01 7:16 Dirk Bergstrom
2001-11-01 7:18 ` Paul Traina
2001-11-01 14:36 ` Michael Richardson
2001-12-12 11:55 ` Michael Richardson
2001-12-11 21:45 ` Paul Traina
2001-11-02 5:50 ` 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
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
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).