Re: Loop unroll fixes

[Daniel Berlin <dan@cgsoftware.com>]

Jim Wilson <wilson@cygnus.com> writes:

>>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.
Errr, i'm confused which lack of civility you are referring to, yours,
mine, or his?

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

And at what point do you consider it a last resort?
Days?
Weeks?
Months?
Years?

>   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.
Having an insignificant number of patches (Way less than 1%) that are
delayed is an achievable goal.

> majority of patches get a response in a reasonable amount of time.

I'm not so sure about this, but i'll reserve judgement for another
year or so.
>   When
> someone points out unreviewed patches, they usually get a response in a
> reasonable amount of time.
Same here.
>   Most patches that are delayed after that are
> controversial and/or potentially disruptive. 
I disagree, currently, but once again, i'll reserve judgement for
another year or so.
> That is not unreasonable.
If it were true, i would agree it's not unreasonable.
> I agree that the current process is a pain to work with, but overall I think
> it is working reasonably well.
Same reservation.
>
> 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.
Accusation?
I said delaying is the wrong approach.
I have not made an accusation or claim, besides that maintainers are
supposed to review patches, regardless of their protest or non-protest.
> 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. 
That's a flame?
I think you've misinterpreted it.

>  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.
How so?
I'm simply giving you an idea of what it appears like, whether you
like how it appears to me or not. I find it strange you can find a way
to take offense at that.
>   My approach is easy to understand, it is a simple
> application of negative reinforcement.
Which is, again, a bad idea in this case, IMHO.
>   If someone uses threats against me,
> then I will delay cooperating with them. 
>  The more I am threated, the more
> I will delay.
And the worse *you* look.
Not the person doing it.
This is because as a maintainer, it doesn't make squat difference if
the person is an asshole or not, it's still your job to review their
patches in a timely manner.
Once again, IMHO. I'm simply presenting my viewpoint. Don't interpret
it as an accusation.
>  Eventually, I expect people will learn that threats are
> counterproductive, and stop using them.
Doubtful, since the majority are likely occasional contributors, and
when you ignore them, they'll just go away.
>   I am willing to accept the risk
> that this approach will occasionally backfire. 
I argue that this will constantly backfire, and will just decrease the
quality of gcc.
> I will not accept the claim
> that this approach is wrong.
Accept it or not, doesn't change whether it actually *is* the right
approach or not (Same applies to me, of course).
>  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.
Sure.  But if a maintainer isn't reviewing patches, or otherwise not
doing their job as a maintainer (once again, neither is an accusation,
i'm simply giving a general statement, not one directed at you), then
they shouldn't expect to be the only once given the ability to review
those patches.
In other words, if a maintainer can't seem to get patches reviewed in
a reasonable amount of time, be it intentional (they were
"threatened", and used your approach), or not, the solution is to add
more maintainers, some who can deal with the "threats".
GCC should not be slowed down, simply because someone decides they are
being threatened. It's bigger than any one person, and not everyone
who contributes will have a likable personality. It would be a mistake
to simply ignore those who don't have one, assuming their patches are
no better or worse than any other contributor.

Once again, most of this is all philosophical argumentation, not one
directly pertaining to the situation at hand.

--Dan
>
> Jim

-- 
"There was a power outage at a department store yesterday.
Twenty people were trapped on the escalators.
"-Steven Wright