On Thu, Feb 14, 2013 at 6:41 PM, Andrea Pescetti <pesce...@apache.org> wrote:
> Rob Weir wrote:
>>
>> When a committ is vetoed, it should be reverted quickly.
>
>
> Yes, when we have a proper veto, with valid technical grounds. A good side
> of the 0 ^ 0 discussion is that contributors are now better educated on
> this.
>
>
>> If the original coder is willing and able to revert quickly, then
>> great.  But anyone, including the veto'er can do this.
>
>
> Of course anyone can. But it's appropriate to try and have the committer,
> and nobody else, undo his work, unless there are exceptional reasons
> (trademark concerns, build breakers that forbid others from getting this
> done...).
>
>
>> It is very likely that the person whose changes were vetoed will not
>> like the veto or the revert.  That is quite natural.
>
>
> A committer is expected to be mature enough to understand rules: if a veto
> is issued, a committer will comply with policy and revert his patch, with no
> need that you step in and do it for him.
>
> It has already been discussed on this list: it may only be a matter of
> politeness, but someone sees it as unrespectful to have a commit reverted by
> someone else. Give him the opportunity to fix things himself, if not else as
> a way to acknowledge that the veto had the required technical grounds.
> Enforce the revert only if needed.
>
> The results on the code are identical, but the results on the community are
> different. And we all care about (and benefit from) having a healthy
> community, where everybody feels respected.
>
>
>> Then, if needed, continue the discussion, including alternative
>> approaches and solutions to satisfying the concerns of outstanding
>> vetos.
>
>
> I agree that there should be no delay from the moment a veto is acknowledged
> to the moment the commit is reverted, and that discussions can be held after
> the revert. But, whenever possible, give the committer the opportunity to
> revert the commit himself.
>

I agree with you that this is a good description of how a mainstream
veto should work.

I'm not sure we need to document how to handle the odd cases were
there is explicit or implied refusal to revert from the original
coder.  But obviously every committer has it within their power to
deal with such exceptional cases.  That in itself should make it clear
that it is ineffective to refuse or delay reverting a patch after a
veto.

-Rob

> Regards,
>   Andrea.

Reply via email to