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