public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mike Stump <mrs@apple.com>
To: Giovanni Bajo <rasky@develer.com>
Cc: Janis Johnson <janis187@us.ibm.com>,
	Mark Mitchell <mark@codesourcery.com>,
	gcc@gcc.gnu.org
Subject: Re: Mainline in regression-fix mode after Thanksgiving
Date: Tue, 23 Nov 2004 22:14:00 -0000	[thread overview]
Message-ID: <AB1F2514-DAC5-409B-906B-79D22C93A9D0@apple.com> (raw)
In-Reply-To: <095801c4d180$19e95e40$f503030a@mimas>

I find the current thread kinda surreal.

I would like to arguing in favor of setting a policy in which we 
automagically assign people the regressions they cause.  One advantage, 
by exposing them to the after effects of what they do, with experience 
in such a system, they learn what types of changes cause what types of 
problems.  I'll go so far as to say, most people actually change their 
behavior to match the automation.  My experience is that this happens 
in 8-12 months.  Having a machine do it, is easier to take, then having 
someone bring it up, if the machine brings up the issue, others, in 
time, generally won't have to.  Our development model relies heavily on 
trust.  I trust you will not make things worse, and you trust me, that 
I will not.  Our users trust us that we won't put in regressions.  
Users are not unimportant.

As to the question of important regressions v unimportant ones, things 
we plan on shipping broken, those can be xfailed/suspended/closed.

The issue was raised that we can revert patches for regressions that 
are not promptly fixed.  While this works some of the time, this breaks 
down when the regression is found via slow turn around testing 
(non-dejagnu testing), and sometimes these can take a year or more to 
show up, at that point, we generally can't just revert a change, as 
there may now be other work that relies in a more critical way, that 
the change is in.

I don't think people need to unassign so others can take up the slack, 
I think people should just grab bugs they want to fix, and once fixed, 
close them.  A bug that has been sitting for a year on someone's plate 
means that we need more maintainers in that area, or that the bug just 
isn't all that important.  When people step forward to fix things, they 
are voting that the bug is important.

I think that each person can decide if they work on a regression they 
caused or a bug they want to fix.  In general, we want to encourage 
people to fix they regressions they cause.  I think most people 
understand this.


So, let me ask if anyone who puts in patches would object to having 
regressions assigned to them?  If no one objects, I'd say, lets just 
make it policy.

  parent reply	other threads:[~2004-11-23 21:52 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-23  1:16 Mark Mitchell
2004-11-23  1:21 ` Kazu Hirata
2004-11-23  1:28   ` Diego Novillo
2004-11-23  1:31     ` Mark Mitchell
2004-11-23  1:37       ` Diego Novillo
2004-11-23 11:46       ` Nathan Sidwell
2004-11-23 16:09         ` Mark Mitchell
2004-11-23  2:15 ` Mike Stump
2004-11-23  2:31   ` Mark Mitchell
2004-11-23  3:00     ` Giovanni Bajo
2004-11-23  8:17       ` Daniel Berlin
2004-11-23  8:39     ` H. J. Lu
2004-11-23 17:19     ` Janis Johnson
2004-11-23 17:23       ` Giovanni Bajo
2004-11-23 18:02         ` Mark Mitchell
2004-11-23 18:20           ` Joe Buck
2004-11-23 18:34             ` Giovanni Bajo
2004-11-23 19:01               ` Joe Buck
2004-11-25 15:47                 ` Gerald Pfeifer
2004-11-23 18:03         ` Janis Johnson
2004-11-23 22:14         ` Mike Stump [this message]
2004-11-24 18:44           ` Giovanni Bajo
2004-11-25 12:41             ` Richard Sandiford
2004-11-25 18:03               ` Mike Stump
     [not found]           ` <41A3B68A.5020408@cs.york.ac.uk>
2004-11-23 23:52             ` Mike Stump
2004-11-24 18:49             ` Giovanni Bajo
2004-11-24 19:39               ` Joe Buck
2004-11-28 13:02       ` Toon Moene
2004-11-24 17:29 ` Joseph S. Myers
2004-11-24 17:32   ` Mark Mitchell
2004-11-24 17:38   ` Gabriel Dos Reis
2004-11-28 12:59 ` Toon Moene
2004-11-29  5:02   ` Mark Mitchell
2004-11-29 11:30     ` Richard Earnshaw
2004-11-29 13:53       ` Paul Brook
2004-11-29 14:06         ` Richard Earnshaw
2004-11-29 16:07           ` Andreas Schwab
2004-11-29 21:47             ` Phil Edwards
2004-11-29 21:59               ` Paul Brook
2004-11-29 23:27                 ` Phil Edwards
2004-11-30 22:49       ` Gerald Pfeifer
2004-11-23 20:05 Richard Kenner
2004-11-28 13:41 Richard Kenner

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=AB1F2514-DAC5-409B-906B-79D22C93A9D0@apple.com \
    --to=mrs@apple.com \
    --cc=gcc@gcc.gnu.org \
    --cc=janis187@us.ibm.com \
    --cc=mark@codesourcery.com \
    --cc=rasky@develer.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).