Date: Thu, 31 May 2018 15:07:39 -0600 From: Warner Losh <imp@bsdimp.com> To: Dieter BSD <dieterbsd@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: PRs are being closed for bogus reasons :-( Message-ID: <CANCZdfovyg61=b0-60ZD426Z=774Wxm9hJxZ=bSqReW_fD4DoA@mail.gmail.com> In-Reply-To: <CAA3ZYrDE1qN36jkg6bfTuUQL-Ko01UhVa=i%2BJ7t7AfN4hdBDMQ@mail.gmail.com> References: <CAA3ZYrDE1qN36jkg6bfTuUQL-Ko01UhVa=i%2BJ7t7AfN4hdBDMQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 31, 2018 at 2:31 PM, Dieter BSD <dieterbsd@gmail.com> wrote: > Standard operating procedure at FreeBSD is: > > Ignore PR for years. > Close PR because it is "old". > > Question: In what universe is this acceptable? > > Example, from one of today's spam: > > > Unfortunately this PR was never addressed before these versions > > of FreeBSD went out of support. Sorry. > > > > If this is still a problem, please open a new PR. Thanks. > > Question: Support? What support? There is no support. > > Question: What would be the reason for someone to resubmit a PR > that was closed merely because it was "old"? > There's a problem with the PR database: there's too many bugs. Some of these bugs are real, some are not. Some have been fixed but never closed (either due to laziness on the part of the developer, or due to ignorance that the PR existed that matched the bug fixed). After a while, the report loses its value and just becomes noise that decreases the value of other bugs in the PR database. What Eitan is doing is to try to catch up with the backlog by asking people if the problem is still a bug, and if so to refile so we know that the information is fresh. In addition, he's been applying fixes that are easy that have languished. So, is this idea? Nope. However, it's clear that the project doesn't have the resources to re-validate bugs as still being a bug, at least given the volume of bugs in our bug database. This is not a terrible "second best" idea that should help the signal / noise ratio of the PR database, which makes it more valuable to developers and others that might fancy fixing a bug. The execution, however, could have explained these things better to avoid friction and hard feeling for people that had bugs so affected. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfovyg61=b0-60ZD426Z=774Wxm9hJxZ=bSqReW_fD4DoA>