RE: Subject line processing in Gnats 4.0

RE: Subject line processing in Gnats 4.0

[Dirk Bergstrom]

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

Re: Subject line processing in Gnats 4.0

[Paul Traina]

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

Re: Subject line processing in Gnats 4.0

[Michael Richardson]

>>>>> "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

Re: Subject line processing in Gnats 4.0 ,

[Michael Richardson]

>>>>> "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

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

[-- 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

Re: Subject line processing in Gnats 4.0

[Michael Richardson]

-----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

Re: Subject line processing in Gnats 4.0

[Yngve Svendsen]

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

Re: Subject line processing in Gnats 4.0

[Chad C. Walstrom]

[-- 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 --]

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

>>>>> "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

RE: Subject line processing in Gnats 4.0

[Dirk Bergstrom]

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

Re: Subject line processing in Gnats 4.0

[Paul Traina]

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

Re: Subject line processing in Gnats 4.0 ,

[Michael Richardson]

>>>>> "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

Re: Subject line processing in Gnats 4.0

[Michael Richardson]

>>>>> "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

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

[-- 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

Re: Subject line processing in Gnats 4.0

[Michael Richardson]

-----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

Re: Subject line processing in Gnats 4.0

[Yngve Svendsen]

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

Re: Subject line processing in Gnats 4.0

[Chad C. Walstrom]

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-----

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

>>>>> "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

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

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

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

>>>>> "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

RE: Subject line processing in Gnats 4.0

[Dirk Bergstrom]

>     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

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

>>>>> "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

Re: Subject line processing in Gnats 4.0

[Paul Traina]

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

RE: Subject line processing in Gnats 4.0

[Dirk Bergstrom]

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

RE: Subject line processing in Gnats 4.0

[Dirk Bergstrom]

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

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

>>>>> "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

Subject line processing in Gnats 4.0

[Michael Richardson]

  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

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

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

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

>>>>> "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

RE: Subject line processing in Gnats 4.0

[Dirk Bergstrom]

>     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

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

>>>>> "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

Re: Subject line processing in Gnats 4.0

[Paul Traina]

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

RE: Subject line processing in Gnats 4.0

[Dirk Bergstrom]

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

RE: Subject line processing in Gnats 4.0

[Dirk Bergstrom]

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

Re: Subject line processing in Gnats 4.0

[Milan Zamazal]

>>>>> "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

Subject line processing in Gnats 4.0

[Michael Richardson]

  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