Henry, thank you *very much* for this input! I agree, let us not put more structure/rules than needed at this point.
On Fri, Sep 5, 2014 at 6:58 PM, Henry Saputra <henry.sapu...@gmail.com> wrote: > +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 <se...@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 >
