your RESOLVED->CLOSED changes
Wolfgang Bangerth
bangerth@ices.utexas.edu
Fri May 23 20:14:00 GMT 2003
As a general note up front: I've certainly seen a good number of PRs, but
at most a dozen or so (out of 11k) which have been reopened because they
were not fixed. Out of these, most read something like "problem reappeared
in original testcase" (as opposed to some small testcase that was fixed).
I believe that for all practical purposes, the set of PRs closed with
someone claiming it is fixed but it wasn't is really empty.
> In the cases you're talking about, the cron job would automatically
> close the PR shortly after it's fixed. This doesn't require extra
> people at all.
What's it good for, then?
> In the cases I'm talking about, the originator would have a window of
> opportunity to test the fix and reject it if it doesn't happen to fix
> it for them. I've been burned too many times with my bug reports (er,
> not gcc, but for other projects) being closed without being fixed, and
> without me getting any say in it.
You can always re-open a report.
See, I'm just arguing that in 90% of cases we'd not get any feedback (or
not in time), so the cron job would kick in. In 9% of cases, people would
use a recent snapshot and report the problem fixed. This needs human
interaction then to close the PR for good. In 1% of cases, people would
realize that the bug is not fixed at all and complain. We need to do
something in that case anyway.
If we just didn't have the third state, we would only have to do something
in this 1% of cases, not in the 10%. I don't see any difference from a QA
viewpoint between having the third state and closing fixed PRs with the
note
"The bug is fixed now. We would appreciate if you could check this and
let us know if you still have problems."
Except for the fact that the last point creates significant less work for
us all.
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/
More information about the Gcc
mailing list