From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27880 invoked from network); 12 Dec 2001 05:45:51 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 12 Dec 2001 05:45:51 -0000 Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.22 #1 (Debian)) id 16E2Ca-0005ng-00; Wed, 12 Dec 2001 00:45:08 -0500 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by fencepost.gnu.org with esmtp (Exim 3.22 #1 (Debian)) id 16E2AX-0005h7-00 for ; Wed, 12 Dec 2001 00:43:01 -0500 Received: from trianon (trianon.shockwave.org [192.111.107.43]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id fBC5gq664204; Tue, 11 Dec 2001 21:42:52 -0800 (PST) (envelope-from pst@juniper.net) Message-ID: <004101c182cf$d703b4b0$2b6b6fc0@shockwave.org> From: "Paul Traina" To: "Dirk Bergstrom" , "Milan Zamazal" , "Michael Richardson" Cc: References: Subject: Re: Subject line processing in Gnats 4.0 Organization: Juniper Networks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: help-gnats-admin@gnu.org Errors-To: help-gnats-admin@gnu.org X-BeenThere: help-gnats@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General discussion about GNU GNATS List-Archive: Date: Thu, 01 Nov 2001 07:18:00 -0000 X-SW-Source: 2001-q4/txt/msg00084.txt.bz2 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" To: "Milan Zamazal" ; "Michael Richardson" Cc: 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:)? //. > 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 (/) 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", 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 , 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul Traina" To: "Dirk Bergstrom" , "Milan Zamazal" , "Michael Richardson" Cc: Subject: Re: Subject line processing in Gnats 4.0 Date: Tue, 11 Dec 2001 21:45:00 -0000 Message-ID: <004101c182cf$d703b4b0$2b6b6fc0@shockwave.org> References: X-SW-Source: 2001-q4/msg00205.html Message-ID: <20011211214500._EROfZY9nhAlCNbZRl4RrBk18fQlNAS9UOp6gZL5YHY@z> 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" To: "Milan Zamazal" ; "Michael Richardson" Cc: 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:)? //. > 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 (/) 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", 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 , 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 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