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