* Re: Subject line processing in Gnats 4.0
2001-11-01 7:16 Subject line processing in Gnats 4.0 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-01 14:36 ` Subject line processing in Gnats 4.0 , Michael Richardson
` (2 subsequent siblings)
3 siblings, 2 replies; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ messages in thread
* Re: Subject line processing in Gnats 4.0 ,
2001-11-01 7:16 Subject line processing in Gnats 4.0 Dirk Bergstrom
2001-11-01 7:18 ` Paul Traina
@ 2001-11-01 14:36 ` Michael Richardson
2001-12-12 11:54 ` Michael Richardson
2001-11-02 5:50 ` Subject line processing in Gnats 4.0 Milan Zamazal
2001-12-11 18:12 ` Dirk Bergstrom
3 siblings, 1 reply; 18+ messages in thread
From: Michael Richardson @ 2001-11-01 14:36 UTC (permalink / raw)
To: Dirk Bergstrom; +Cc: Milan Zamazal, help-gnats
>>>>> "Dirk" == Dirk Bergstrom <dirk@juniper.net> writes:
Dirk> takes time and energy to close/expunge.
Dirk> these subjects do the Right Thing:
Dirk> *) re: compiler/9876: compiled code runs backwards
Dirk> *) serial-port/1234: cannot process frosted flakes
Dirk> but these subjects all do the Wrong Thing (create new PR, instead of
Dirk> appending):
Dirk> *) Re: FW: sw-kern-sanders/16543: kernel panic on gunshot
Dirk> *) PR 12345
Dirk> *) Fw: sw-rip-vnwnkl/10795: The routing subsystem is asleep
Dirk> *) RE: 2001-0821-021: hw-pr0n/16413 FPC shows pictures of naked ladies
Dirk> on reboot
Dirk> (basically, anything in front of the category that's not "re:" bombs.)
Thanks for this excellent diagnostic. I hadn't figured out why it sometimes
appended and it sometimes did not.
Dirk> does anyone see a reason to keep the restrictive regex?
I concur with all of what you write.
] 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] 18+ messages in thread
* Re: Subject line processing in Gnats 4.0 ,
2001-11-01 14:36 ` Subject line processing in Gnats 4.0 , Michael Richardson
@ 2001-12-12 11:54 ` Michael Richardson
0 siblings, 0 replies; 18+ messages in thread
From: Michael Richardson @ 2001-12-12 11:54 UTC (permalink / raw)
To: Dirk Bergstrom; +Cc: Milan Zamazal, help-gnats
>>>>> "Dirk" == Dirk Bergstrom <dirk@juniper.net> writes:
Dirk> takes time and energy to close/expunge.
Dirk> these subjects do the Right Thing:
Dirk> *) re: compiler/9876: compiled code runs backwards
Dirk> *) serial-port/1234: cannot process frosted flakes
Dirk> but these subjects all do the Wrong Thing (create new PR, instead of
Dirk> appending):
Dirk> *) Re: FW: sw-kern-sanders/16543: kernel panic on gunshot
Dirk> *) PR 12345
Dirk> *) Fw: sw-rip-vnwnkl/10795: The routing subsystem is asleep
Dirk> *) RE: 2001-0821-021: hw-pr0n/16413 FPC shows pictures of naked ladies
Dirk> on reboot
Dirk> (basically, anything in front of the category that's not "re:" bombs.)
Thanks for this excellent diagnostic. I hadn't figured out why it sometimes
appended and it sometimes did not.
Dirk> does anyone see a reason to keep the restrictive regex?
I concur with all of what you write.
] 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] 18+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-01 7:16 Subject line processing in Gnats 4.0 Dirk Bergstrom
2001-11-01 7:18 ` Paul Traina
2001-11-01 14:36 ` Subject line processing in Gnats 4.0 , Michael Richardson
@ 2001-11-02 5:50 ` Milan Zamazal
2001-11-02 5:57 ` Michael Richardson
` (3 more replies)
2001-12-11 18:12 ` Dirk Bergstrom
3 siblings, 4 replies; 18+ 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] 18+ messages in thread
* Re: Subject line processing in Gnats 4.0
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
` (2 subsequent siblings)
3 siblings, 1 reply; 18+ 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] 18+ 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; 18+ 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] 18+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-02 5:50 ` Subject line processing in Gnats 4.0 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; 18+ 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] 18+ 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; 18+ 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] 18+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-02 5:50 ` Subject line processing in Gnats 4.0 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ messages in thread
* Re: Subject line processing in Gnats 4.0
2001-11-02 5:50 ` Subject line processing in Gnats 4.0 Milan Zamazal
` (2 preceding siblings ...)
2001-11-06 7:43 ` Chad C. Walstrom
@ 2001-12-12 15:06 ` Milan Zamazal
3 siblings, 0 replies; 18+ 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] 18+ messages in thread
* RE: Subject line processing in Gnats 4.0
2001-11-01 7:16 Subject line processing in Gnats 4.0 Dirk Bergstrom
` (2 preceding siblings ...)
2001-11-02 5:50 ` Subject line processing in Gnats 4.0 Milan Zamazal
@ 2001-12-11 18:12 ` Dirk Bergstrom
3 siblings, 0 replies; 18+ 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] 18+ messages in thread