flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Márton Balassi <balassi.mar...@gmail.com>
Subject Re: Community & Committing rules
Date Fri, 05 Sep 2014 12:47:10 GMT
The argument of Robert & Kostas on not requiring a vote thread unless
someone asks for it makes sense, mine was too much.


On Fri, Sep 5, 2014 at 2:33 PM, Kostas Tzoumas <ktzoumas@apache.org> wrote:

> +1 for not requiring a vote thread unless someone asks for it
>
>
> On Fri, Sep 5, 2014 at 1:51 PM, Robert Metzger <rmetzger@apache.org>
> wrote:
>
> > I agree with Stephan: If somebody wants to do a major change and is
> > uncertain if the community is willing to accept the change, they can ask
> on
> > the mailing list about it.
> >
> > I would rather go with Stephan's suggestion to just drop a mail on the
> dev@
> > list, without a formal vote. If there is a disagreement or somebody asks
> > for a vote, we can still start a vote. This is how I perceived this
> project
> > since it entered the incubator.
> >
> > I'm against the explicit requirement for a vote (this is how I understood
> > Marton) because it would make things too complicated (working on Flink
> > should be fun, not a highly regulated process).
> >
> >
> > I'm against adding the community rules into the "How to Contrib". Its
> such
> > an important topic that we should dedicate a separate page on that (the
> > internet is already so huge, this one page won't hurt). Having such a
> page
> > also shows the IPMC that our community is healthy.
> >
> >
> >
> > On Fri, Sep 5, 2014 at 1:39 PM, Ufuk Celebi <uce@apache.org> wrote:
> >
> > > +1 but I would say not the Wiki, but the How To Contribute guide.
> > >
> > > @Marton: do you have a link for the mail vote befor major changes. In
> any
> > > case, for me it doesn't matter whether it is a vote or a light weight
> > mail
> > > to the dev list.
> > >
> > >
> > > On Fri, Sep 5, 2014 at 1:10 PM, Márton Balassi <
> balassi.marton@gmail.com
> > >
> > > wrote:
> > >
> > > > I'd prefer the mail vote before major changes (this is also the
> > preferred
> > > > Apache guideline if I'm not mistaken).
> > > >
> > > > Writing down the basics on a wiki makes it clearer and also easier
> for
> > > new
> > > > contributors to get involved. This page is somewhat related though
> (at
> > > > least for voting):
> > > > http://www.apache.org/foundation/voting.html
> > > >
> > > >
> > > > On Fri, Sep 5, 2014 at 12:50 PM, 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
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message