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 an
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.
>
> Regar
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 *exist
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 e
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
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
