Mailing-List: contact dev-help@flink.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of henry.saputra@gmail.com
 designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANC1h_trv+eogMDHrF5TSFaHAn3hS7j3N9ODNcx7mj998dZUJA@mail.gmail.com>
References: 
 <CANC1h_trv+eogMDHrF5TSFaHAn3hS7j3N9ODNcx7mj998dZUJA@mail.gmail.com>
Date: Fri, 5 Sep 2014 09:58:27 -0700
Message-ID: 
 <CALuGr6buv6bjCSsfcaHU2XHCTSrjjr6oBKSXv4ZBUAtV6VPL=Q@mail.gmail.com>
Subject: Re: Community & Committing rules
From: Henry Saputra <henry.saputra@gmail.com>
To: "dev@flink.incubator.apache.org" <dev@flink.incubator.apache.org>
Content-Type: text/plain; charset=UTF-8

+1 for commits small changes directly, which is the perk of being
committers of open source project.

However, as many people had mentioned, when the changes are none
trivial or requires modification of existing behavior then a pull
request and reviews should be requested to get extra pairs of eyes.

And when it is a new feature or major changes, such as rewrite RPC
flows, then hopefully consensus of plan could achieve via discussions
in dev@ list and with opening JIRA ticket to track the effort.
VOTE should be done when consensus is hard to get and changes are
needed for greater good.

Having official commit rules are like having project bylaws.
I don't think we need bylaws of committing changes at this point,
because it would cause confusion and many existing Apache projects did
not get it right with formal bylaws.

- Henry

On Fri, Sep 5, 2014 at 3:50 AM, Stephan Ewen <sewen@apache.org> wrote:
> Hi!
>
> I think part of the discussion that arose around the proposed Java/Scala
> and RPC/Akka changes comes from the fact that we have not clearly written
> down the community/committing rules anywhere yet. In particular, how do we
> treat proposed major changes.
>
> Most of us (including me) worked under the assumption that committers can
> commit small fixes immediately, and those can be vetoed (reverted) in
> hind-sight by others (has not yet happened, though).
>
> Anything that has impact on other people goes through pull requests, and is
> then discussed upon, revised, or rejected. This seems to be the model that
> many other Apache projects use (like Mahout for example, Sebastian, correct
> my if I am wrong there).
>
> That has seemed to work so far, and in that sense, the use of Akka for
> example is still a proposal only.
>
> For major refactorings like the RPC/Actor one, it makes sense to try and
> reach consensus before the implementation effort, because it is too much
> work to do it without knowing that it will be accepted. This may be a vote,
> but I would prefer it to be rather lightweight, like dropping a mail on the
> dev list, giving people an early chance to voice concerns.
>
> Does it make sense to write these simple rules down somewhere (wiki?), so
> that it is transparent?
>
> Stephan