public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jim Wilson <wilson@cygnus.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Loop unroll fixes
Date: Fri, 14 Sep 2001 16:45:00 -0000	[thread overview]
Message-ID: <200109142345.QAA08763@cygnus.com> (raw)
In-Reply-To: <87elp9j2rg.fsf@cgsoftware.com>

>No, I'd rather believe he's trying to just bully people into reviewing
>a patch.
>Which is good, in reality.

I can understand that you are probably responding in frustration, perhaps from
personal experience with problems with patch reviews, but I still don't think
that justifies a lack of civility in this case.

If there was evidence in the public record that a maintainer was unresponsive,
then yes, bullying would be appropriate.  But bullying should not be the
first approach, it should be the last resort.  There is no public evidence
to indicate that an maintainer was unresponsive.  And there is public evidence
indicating that bullying was the first approach used.

>It shouldn't take months to review patches.

Ideally, yes, but we get so many patches that no matter how good the process
is, there will always be some patches that are delayed.  I believe the
majority of patches get a response in a reasonable amount of time.  When
someone points out unreviewed patches, they usually get a response in a
reasonable amount of time.  Most patches that are delayed after that are
controversial and/or potentially disruptive.  That is not unreasonable.
I agree that the current process is a pain to work with, but overall I think
it is working reasonably well.

In this particular case, I presented evidence showing that there was one
month delay because of miscommunication, and one more month of delay because
of a conflict with the gcc 3.0.1 release process.  Thus the two month delay
in this particular case, though unfortunate, is perfectly understandable,
and does not indicate any serious flaws with the current system.

>This is the wrong approach.
>Your job, as a maintainer, is to review patches.
>It's not some "honor", or exalted position.
>You are supposed to review every patch, that comes into your area, in
>a reasonable amount of time.  Months is not reasonable.

I presented ample evidence in my last message to demonstrate that there is
no basis for this accusation in this particular case.  Making this claim
is offensive, and couterproductive.  I did volunteer to review this patch,
and now my thanks for my trouble is getting a flame from you.  If volunteers
get flamed for trying to help, then they will be less willing to help in the
future, and we will only have more trouble with patch reviews.

>Deferring action for a week just looks like you are trying to have a
>fiefdom of your own.

Another offensive comment.  My approach is easy to understand, it is a simple
application of negative reinforcement.  If someone uses threats against me,
then I will delay cooperating with them.  The more I am threated, the more
I will delay.  Eventually, I expect people will learn that threats are
counterproductive, and stop using them.  I am willing to accept the risk
that this approach will occasionally backfire.  I will not accept the claim
that this approach is wrong.  After all, I am a volunteer, and I reserve the
right to decide what I do with the time that I have volunteered to spend on
gcc.

Jim

  parent reply	other threads:[~2001-09-14 16:45 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-13 16:35 Zoltan Hidvegi
2001-09-13 18:58 ` David Edelsohn
2001-09-13 23:50   ` Jim Wilson
2001-09-14  6:55     ` Daniel Berlin
2001-09-14 12:15       ` Joseph S. Myers
2001-09-14 16:45       ` Jim Wilson [this message]
2001-09-14 20:11         ` David Edelsohn
2001-09-14 22:23           ` Jim Wilson
2001-09-15  2:42           ` Bernd Schmidt
2001-09-14 21:16         ` Daniel Berlin
2001-09-14  9:41     ` David Edelsohn
2001-09-14 10:46       ` Bernd Schmidt
2001-09-14 11:47         ` David Edelsohn
2001-09-14 17:54       ` Jim Wilson
2001-09-14 18:35         ` David Edelsohn
2001-09-14 19:56           ` Jim Wilson
2001-09-15  2:56         ` Joseph S. Myers
2001-10-04  6:46 ` Franz Sirl
2001-10-04  7:40   ` Mark Mitchell
2001-10-04 20:46   ` Jim Wilson
2001-10-04 20:51     ` Mark Mitchell
2001-10-04 23:10       ` Zoltan Hidvegi
2001-10-10  0:05         ` Mark Mitchell
     [not found] <Pine.LNX.4.33.0109141957550.29416-100000@host140.cambridge.redhat.com>
2001-09-14 14:36 ` David Edelsohn
     [not found] <200109142021.QAA26236@makai.watson.ibm.com>
2001-09-15  8:57 ` Bernd Schmidt
2001-09-17 13:16   ` Richard Henderson
2001-09-17 14:24     ` Joe Buck
2001-09-17 15:11       ` Richard Henderson
2001-09-17 17:22         ` Mark Mitchell
2001-09-18  2:19         ` Joseph S. Myers
2001-09-18  4:16 Richard Kenner
2001-09-18 10:47 Benjamin Kosnik
2001-09-18 11:54 mike stump
2001-09-18 12:34 ` Joseph S. Myers
2001-09-19 11:28   ` Joe Buck
2001-09-24  9:31     ` law
2001-09-18 17:36 Richard Kenner
2001-10-10  1:12 Wolfgang Bangerth
2001-10-10  1:16 ` Mark Mitchell
2001-10-10  5:14   ` Franz Sirl
2001-10-10 11:08     ` Mark Mitchell

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=200109142345.QAA08763@cygnus.com \
    --to=wilson@cygnus.com \
    --cc=dan@cgsoftware.com \
    --cc=gcc@gcc.gnu.org \
    /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).