Justin Erenkrantz wrote:
> --On Wednesday, November 6, 2002 2:58 PM +1100 Peter Donald
> <peter@apache.org> wrote:
>
>> In cases where the cost of fixing is higher than detailed
>> explanation then the patches get rejected.
>
>
> I would prefer to push back on contributors in most cases. There's a
> threshold though. If it's relatively minor, I will just fix it up.
>
>> Agree with that. We aren't talking about committers here though. We
>> are talking about developers in wide world who submit code via
>> patches to mailing list or bugzilla.
>
>
> <quote="Nicola">
>
>> A trick that seasoned committers do on new committers is to change
>> their first commits and work on them, to show that the code is of
>> everyone. If they complain, it's time for a nice and bold
>> explanation.
>
> </quote>
>
> Nicola seems to be talking specifically about committers not
> contributors (people without commit). Your earlier statement led me to
> believe that you agree with Nicola and think that's a good practice. It
> seems you don't necessarily agree. =)
Yes, in this case I was, but Peter correctly extended the example to
contributors anyway, following my line of thinking.
> For contributors, you can tweak their patches slightly, but I would
> strongly discourage doing that for committers. To me, that is extremely
> suspect behavior. IMHO, committers should be aware of policies *before*
> they become committers. And, they should be trusted to respond to
> feedback.
You're right, I wasn't clear.
I intended to talk about committing new files-code that is good, but
can, as always, be made better.
>> yanking doesn't happen.
>
>
> FWIW, PHP has a low commit barrier and does yank. HTTP Server/APR do
> have a higher barrier, so we're fairly certain that there won't be a
> need to yank. Something in the middle may need to consider yanking of
> commit privs especially if there is a pattern of bogus commits.
You are getting to extremes here, I'm talking about milder changes, and
not about bugus commits, but about good commits that others help out to
make even better. Basically it applies to new code-classes, not fixes or
enhancements.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|