|
From: | Mel Hatzis |
Subject: | Re: Subject header matching--once again |
Date: | Mon, 04 Nov 2002 15:16:45 -0800 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 |
On 11/04/2002 11:11 AM, Lars Henriksen wrote:
On Sun, Nov 03, 2002 at 09:17:08PM -0800, Mel Hatzis wrote:(snip) Building on your proposal, I suggest that it'd be even better if an array of capture groups could be specified, each associated with a field name. This would allow for fields other than 'category' on the subject line. This could take the following form: subject-matching { "\\<PR[ \t#/]?([0-9]+)[ \t]?:(.*)" captured-fields { "Number" "Synopsis" } }I like that, a nice, concise way of identifying the groups and their purpose, The built-in default would then become subject-matching { "\\<(PR[ \t#]?\\|([-\\w+.]+)/)([0-9]+)" captured-fields { "" "Category" "Number" } }The example above would match subject lines of the form: "PR 333 : missing subject-matching clause causes gnatsd to dump core" (verifying that the synopsis matched the PR number before accepting it as a reference to PR 333)Would you allow any field name to appear in the list or just an exquisite selection? I am not well versed in the intricacies of gnatsd. Does the existing code allow a check of Synopsis as you suggest? There will, of course, have to be validity checks for each of the field types in the list.
The existing code would need to be modified to do the checking. Currently, the code does a category search for the captured stuff preceding the pr number - so it's fairly hardwired. This could be addressed using 'find_field_index' and 'field_value' for the fields in question. One would also need to be careful to account for changes - for example, if PR 333 is associated with category 'A' and someone updates it to category 'B', a subject line of 'Re: A/333' should probably still match PR 333 - this is currently what happens because the check for category is independent of PR number. This poses a problem for setups like my example which used 'Synopsis' since, if the synopsis for PR 333 is modified, there is no way to verify subject lines that reference the old synopsis. However, this problem also applies to category, if one considers the possibility that a category is deleted from the categories file. Perhaps this is OK - if the category is deleted, it shouldn't surprise anyone if subject lines with the old category no longer match. This is a tougher argument to apply to a modified synopsis - since you're not deleting the synopsis value, you're merely modifying it. With a category modification, you can still do the verification, but with a synopsis modification, you can't. It all comes down to gnats-admin policy - the patch gives you the flexibility to define your own policy. It won't protect against ill-defined policy. -Mel
[Prev in Thread] | Current Thread | [Next in Thread] |