On Thu, Jan 08, 2004 at 10:51:53PM +0000, Paul Robinson wrote:
> Just a thought:
> 
> How about everything that hasn't been touched in 3 years gets put into a 
> special state of "closed-believed-dead", everything over 12 months (or 
> 6?) gets the same AFTER an e-mail has been sent out to the originator to 
> see if the problem still exists?
> 
> It's just that way, I think a lot of PRs for obsolete hardware and 
> versions will get closed up, thereby making it easier for those of us 
> trying to pick our way through and see what is still new and relevant 
> and in need of some love and care and attention. If somebody still has 
> the problem and it's an issue, it just gets a new PR that comes back on 
> the top of the queue, it's live and we can deal with PRs as they come in.
> 
> Thoughts? Just a thought that might help clean up the DB on an idle 
> Thursday evening. I'm sure it's been thought of before.

Well, here's a extract from a mail I sent to another non-committer
interested in doing the same thing, about two days ago.  Note that we
do already timeout PRs in feedback after a period of time without a
reply (currently 3 months).

Also note that there's a bugbusters@ list where this kind of discussion
should live, but I think I may be the only person subscribed (although
rousing the list is really my responsibility, I've yet to think up a
good enough scheme).

Forwarded mail:

        Thanks for the offer of help.
        
        Sending stuff to current could be considered useful, but committers
        interested in fixing bugs (which is hopefully all of them!) will all be
        subscribed to freebsd-bugs@, which means that by simply submitting a
        followup to the PR they'll get automatically notified.
        
        There a few ways for non-committers to help out though:  if you think
        that a PR can be closed, then submit a followup to the PR with the
        reason why, and include the string "This PR can be closed".  The reason
        can be anything from "this isn't a problem on later releases", "this was
        fixed in revision x of src/foo/bar/quux.c" to "the user is at fault".
        
        Just because a PR can't be closed though, if you have information to
        add to a PR (an updated patch, "cannot replicate here", etc.) then send
        it in as a followup.  Of course, if you know of (or can code) a fix, send
        it!

Ceri
-- 

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to