From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: DJ Delorie <dj@redhat.com>
Cc: neroden@twcny.rr.com, <gcc@gcc.gnu.org>
Subject: Re: your RESOLVED->CLOSED changes
Date: Fri, 23 May 2003 20:14:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.44.0305231503170.13914-100000@gandalf.ices.utexas.edu> (raw)
In-Reply-To: <200305232001.h4NK1b815531@greed.delorie.com>
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/
next prev parent reply other threads:[~2003-05-23 20:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-23 7:39 Nathanael Nerode
2003-05-23 8:55 ` Giovanni Bajo
2003-05-23 9:36 ` Gerald Pfeifer
2003-05-23 10:19 ` Giovanni Bajo
2003-05-23 14:18 ` Wolfgang Bangerth
2003-05-23 15:47 ` Nathanael Nerode
2003-05-23 19:23 ` Wolfgang Bangerth
2003-05-23 19:46 ` DJ Delorie
2003-05-23 19:56 ` Wolfgang Bangerth
2003-05-23 20:03 ` DJ Delorie
2003-05-23 20:14 ` Wolfgang Bangerth [this message]
[not found] ` <Pine.LNX.4.44.0305230908020.22023-100000@gandalf.ices.utex as.edu>
2003-05-23 14:19 ` John Anthony Kazos Jr.
2003-05-23 15:41 ` Nathanael Nerode
2003-05-23 15:33 ` Nathanael Nerode
2003-05-23 9:43 ` Joseph S. Myers
[not found] ` <Pine.LNX.4.53.0305231035220.4682@kern.srcf.societies.cam.a c.uk>
2003-05-23 9:53 ` John Anthony Kazos Jr.
2003-05-23 15:05 ` Daniel Berlin
2003-05-23 15:54 ` Nathanael Nerode
-- strict thread matches above, loose matches on Subject: below --
2003-05-23 15:29 Volker Reichelt
2003-05-23 16:18 ` Daniel Berlin
2003-05-23 19:23 ` Wolfgang Bangerth
2003-05-23 19:37 ` DJ Delorie
2003-05-23 14:55 Wolfgang Bangerth
[not found] <20030523062858.322.qmail@sources.redhat.com>
2003-05-23 6:59 ` Giovanni Bajo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.44.0305231503170.13914-100000@gandalf.ices.utexas.edu \
--to=bangerth@ices.utexas.edu \
--cc=dj@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=neroden@twcny.rr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).