public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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/


  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).