incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Code ownership (was Re: whoweare.html)
Date Wed, 06 Nov 2002 07:28:47 GMT

Justin Erenkrantz wrote:
> --On Wednesday, November 6, 2002 2:58 PM +1100 Peter Donald 
> <> 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 

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message