From owner-freebsd-bugs@FreeBSD.ORG Tue Apr 5 22:48:31 2005 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DBB616A4CE for ; Tue, 5 Apr 2005 22:48:31 +0000 (GMT) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E3EA43D2F for ; Tue, 5 Apr 2005 22:48:31 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 93497149CF; Tue, 5 Apr 2005 17:48:30 -0500 (CDT) Date: Tue, 5 Apr 2005 17:48:30 -0500 (CDT) From: Mark Linimon X-X-Sender: linimon@pancho To: Matteo Riondato In-Reply-To: <20050405205601.GE674@kaiser.sig11.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-bugs@freebsd.org Subject: Re: About Feedback timeout X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2005 22:48:31 -0000 On Tue, 5 Apr 2005, Matteo Riondato wrote: > While digging in the PR database to find some PRs I can help to solve, > I found many PRs still open even if they are really old, refer to old > and no longer supported -RELEASE or the submitter didn't reply to > feedback request. What we have written down is in the following article: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pr-guidelines/ It provides an overview but IMHO isn't thorough enough. I wrote a proposal to rewrite/extend it at one point (both with some general principles and some specific, version-related suggestions for "oldness") but there wasn't much support for the changes as such. I haven't gotten back around to rewriting them. The gist of what I wanted to add was that we should try to respect the intent of the original submitter (at some point they were _trying_ to help us out) even though many of the PRs are stale and/or incomplete. So I personally don't just close ancient ones with "sorry, too old". In general, when I work on them, I ask for feedback; about 1/3 of the email addresses bounce, 1/3 of the time there is no reply, and most of the rest are divided between 'no longer a problem' and 'still a problem'. Only a few people get offended that no one has looked at the problem until now. The reality of the situation is that we have more requests for feature additions and (more often) for requests for help with installations than we can realistically do. Thus the PR count increases. Certainly the ones with feedback timeout just need to be closed. The ones for unsupported releases, well, my theory is that the people should be asked nicely if the problem still exists. Many of these will bounce or not get replies. Other committers just prefer to close them, though. But remember too, just because a PR is really old doesn't necessarily imply that the problem got fixed somehow :-( But any help you can provide to do the followup work is appreciated. (Of course, if I didn't believe that, I wouldn't be one of the bugmeisters, now would I? :-) ) In an ideal world we'd have a much smaller set of PRs and each of those would have a fix for a very specific problem. We're certainly pretty far from that goal, but IMHO not as far as we used to be. Final advice: every little bit counts, but don't expect to fix the entire content of the PR database; just do a little bit at a time. mcl