Re: [racket-dev] Responding to old bug reports
Yesterday, Sam Tobin-Hochstadt wrote: In my role as bug czar, I've been trying to work through the backlog of old unexamined bugs. Unfortunately, many of them (a) have very little information and (b) are from a long time ago. A good example is this one: http://bugs.racket-lang.org/query/?cmd=viewpr=9481 There are a few options here: 1. Close old (how old?) bugs that don't have enough information to triage/reproduce. 2. Put them in the feedback state, with a general request for more information. 3. Attempt to guess at what component this belongs to, and assign it that way. 4. Leave it in the current state. I think 3 and 4 are both unacceptable. I'm leaning toward 2. The major drawback of 2 vs 1 is that we accumulate lots of bugs that nothing will ever happen with. The major drawback of 1 is that we're saying to someone who took the time to report a bug we didn't care about this bug at the time, so now we're closing it. I think that a sensible choice would be to combine #1 and #2: decide that PRs that have been in feedback state for a while are retired. It's easy to do this -- here's a query that shows all of these PRs sorted by date of last modification: http://bugs.racket-lang.org/query/?State=feedback;columns=Category;columns=Synopsis;columns=Last-Modified;sortby=Last-Modified;cmd=submit%20query Looks like there are very few of them and most could be closed. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Responding to old bug reports
On Fri, Dec 2, 2011 at 4:39 AM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Sam Tobin-Hochstadt wrote: In my role as bug czar, I've been trying to work through the backlog of old unexamined bugs. Unfortunately, many of them (a) have very little information and (b) are from a long time ago. A good example is this one: http://bugs.racket-lang.org/query/?cmd=viewpr=9481 There are a few options here: 1. Close old (how old?) bugs that don't have enough information to triage/reproduce. 2. Put them in the feedback state, with a general request for more information. 3. Attempt to guess at what component this belongs to, and assign it that way. 4. Leave it in the current state. I think 3 and 4 are both unacceptable. I'm leaning toward 2. The major drawback of 2 vs 1 is that we accumulate lots of bugs that nothing will ever happen with. The major drawback of 1 is that we're saying to someone who took the time to report a bug we didn't care about this bug at the time, so now we're closing it. I think that a sensible choice would be to combine #1 and #2: decide that PRs that have been in feedback state for a while are retired. It's easy to do this -- here's a query that shows all of these PRs sorted by date of last modification: That's basically what Robby suggested as well, and it seems right to me as well. I also did just close the example bug I gave. http://bugs.racket-lang.org/query/?State=feedback;columns=Category;columns=Synopsis;columns=Last-Modified;sortby=Last-Modified;cmd=submit%20query Looks like there are very few of them and most could be closed. Unfortunately, some of these need to be re-triaged. For example, 6285 is a real bug, and I think is only accidentally in the feedback state. But there aren't that many, so it's ok. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Responding to old bug reports
How about closing the PR, but with a message that says we would be happy to reopen if we've closed the PR by mistake (i.e., there's still a problem) or if more information is available? At Thu, 1 Dec 2011 11:13:23 -0500, Sam Tobin-Hochstadt wrote: In my role as bug czar, I've been trying to work through the backlog of old unexamined bugs. Unfortunately, many of them (a) have very little information and (b) are from a long time ago. A good example is this one: http://bugs.racket-lang.org/query/?cmd=viewpr=9481 There are a few options here: 1. Close old (how old?) bugs that don't have enough information to triage/reproduce. 2. Put them in the feedback state, with a general request for more information. 3. Attempt to guess at what component this belongs to, and assign it that way. 4. Leave it in the current state. I think 3 and 4 are both unacceptable. I'm leaning toward 2. The major drawback of 2 vs 1 is that we accumulate lots of bugs that nothing will ever happen with. The major drawback of 1 is that we're saying to someone who took the time to report a bug we didn't care about this bug at the time, so now we're closing it. Thoughts? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
