On Mon, Mar 2, 2015 at 11:29 AM, Vinod Kumar Vavilapalli
vino...@hortonworks.com wrote:
We always needed another committer's +1 even if it isn't that clear in the
bylaws. In the minimum, we should codify this in the bylaws to avoid stuff
like people committing their own patches.
Regarding
Vinod,
I agree that triviality is hard to define and we should not add things that
can be interpreted multiple ways to the bylaws.
If something is not quite clear in the bylaws, it would make sense to have
a proposal of new phrasing, so that we could discuss it here and call a
vote upon reaching
I agree with Andrew and Konst here. I don't think the language is
unclear in the rule, either... consensus with a minimum of one +1
clearly indicates that _other people_ are involved, not just one
person.
I would also mention that we created the branch committer role
specifically to make it
We always needed another committer's +1 even if it isn't that clear in the
bylaws. In the minimum, we should codify this in the bylaws to avoid stuff like
people committing their own patches.
Regarding trivial changes, I always distinguish between trivial *patches* and
trivial changes to
There were discussions on several jiras and threads recently about how RTC
actually works in Hadoop.
My opinion has always been that for a patch to be committed it needs an
approval (+1) of at least one committer other than the author and no -1s.
The Bylaws seem to be stating just that:
Consensus
I have the same interpretation as Konst on this. +1 from at least one
committer other than the author, no -1s.
I don't think there should be an exclusion for trivial patches, since the
definition of trivial is subjective. The exception here is CHANGES.txt,
which is something we really should get
