Date: Tue, 11 Feb 2003 19:07:36 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: bugbusters@freebsd.org Subject: Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-) Message-ID: <3E49BA78.9B24BB22@mindspring.com> References: <20030209185618.GA19962@papagena.rockefeller.edu> <20030209151407.N548@localhost> <2e1y2e7jtu.y2e@localhost.localdomain> <20030211190614.GA2153@gothmog.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
Giorgos Keramidas wrote: > Interesting stuff. I've been toying around with the idea of an > automated ``close and send a gentle reply to the originator'' script > for feedback PRs that are more than 3-4 months old and no activity has > appeared in the audit trail since the last transition to feedback. > If 3-4 months seems too short, we can change it to 1 year or more. > > The reasoning behind an automated close of the PR is that if the > originator of the PR has falled off the face of the earth, lost net > connectivity and nobody else picked up the problem report, then it's > probably something nobody cares about so we shouldn't waste time on it. I understand the reasoning, but it's not reasonable. 8-). Consider if the problem were something like succeptability to smurf attacks, but none of the committers cared about it enough to do anything about it, or close the PR. Eventually, under these rules, the problem "times out", but the root cause is never addressed. Even if the original reported is hit by a bus the day after the report is submitted the first time, that doesn't make the problem "go away", merely by wishing it away. What is the intent of timing out bug reports? What is the perceived need? If it's just to apply a filter so you can not see them, you can do that by constraining the search filter to ignore PR's older than some date, without having to remove them from the database. > Then all it would take for PRs to slowly rot and close would be that > committers set the already open PRs to the feedback state if they seem > to be too old to be relevant to current and supported releases. Does > this look any good as an idea? Why do you want reports to "slowly rot"? Should we do the same thing with source code that does not get touched in a while? This whole discussion sems aimed at being able to discard PR's that are inconvenient, through their persistance, or through the inability of people to resolve them, or the inability of the project to grant commit access to those people willing to resolve them, when members of the project who already have commit access are unwilling to do so. Old PR's are, to my mind, the most valuable of all PR's, in terms of attracting talent to the project: persistant breakage is often the most annoying. This seems to me an attempt to mitigate that annoyance by ignoring it, rather than attracting new volunteers to the project. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugbusters" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E49BA78.9B24BB22>