Clean up old PRs

[Eric]

> From: Jerry <jerry at seibercom.net>
> Date: Mon, 16 May 2011 08:02:07 -0400
> 
> There are several PRs that are years (literally) old. For example:
> <http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/87397>
> 
> o 2005/10/13 ports/87397 edwin [patch] incorrect use of PAPERSIZE make
> variable in some ports
> 
> Maybe it is time that some of these extremely old PRs be put to rest.
> Perhaps a new classification should be added. Presently there are
> several possible classifications:
> 
> o - open
>     A problem report has been submitted, no sanity checking performed.
> a - analyzed
>     The problem is understood and a solution is being sought.
> f - feedback
>     Further work requires additional information from the originator or
>     the community - possibly confirmation of the effectiveness of a
>     proposed solution.
> p - patched
>     A patch has been committed, but some issues (MFC and / or
>     confirmation from originator) are still open.
> r - repocopy
>     The resolution of the problem report is dependent on a repocopy
>     operation within the CVS repository which is awaiting completion.
> s - suspended
>     The problem is not being worked on, due to lack of information or
>     resources. This is a prime candidate for somebody who is looking
>     for a project to do. If the problem cannot be solved at all, it
>     will be closed, rather than suspended.
> c - closed
>     A problem report is closed when any changes have been integrated,
>     documented, and tested -- or when fixing the problem is abandoned.
> 
> I am proposing a new one:
> 
> x - expired
>     This report is over 2 years old. If no one has bothered to fix it
>     by now, then in all probability no one will.

Personally I quite like this idea, but to play devils advocate one could
just set the ancient PRs to closed, since this can be used for an abandoned
PR (as indicated in the classification descriptions).
However I like the idea of actually acknowledging that they have expired
since it may provide an interesting metric that could be measured.  It may
however be possible to still obtain that metric using a 'c' closed state -
since this is likely to be an automated PR expiry procedure perhaps whatever
batch process is doing the closing might set a suitable (consistent) 'Why'
message with the PR, something like "[EXPIRED] This report is over 2 years
old." which perhaps (he says not being too familiar with the underlying
GNATS db) could be filtered for and used in generating reports/stats?

Cheers

Eric