drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomer Shiran <tshi...@gmail.com>
Subject Re: [VOTE] Drill bylaws
Date Thu, 09 Oct 2014 00:44:56 GMT
Makes sense to simplify and not have a special carveout for branch merges.

WRT my rationale, I think that an approach that encourages
agreement/consensus will lead to more consistency around the UX (eg, APIs).
Didn't mean to imply that one 'side' would be proposing an objectively
better UX than the other 'side', just that encouraging some additional
thinking and collaboration on these fine points could be beneficial. My
$0.02... :-)

On Wed, Oct 8, 2014 at 3:09 PM, Julian Hyde <jhyde@apache.org> wrote:

> On Oct 8, 2014, at 2:29 PM, Tomer Shiran <tshiran@gmail.com> wrote:
>
> Given Drill's
> focus on providing a great user experience, I think that having stronger
> controls in place makes sense.
>
>
> I don’t agree with your rationale. You are assuming that in a crisis the
> majority wants a “great user experience” and the minority wants… what… a
> worse user experience? It could just as easily be the reverse.
>
> That said, I do agree with your conclusion.
>
> I suggest to strike the text
>
> >  , unless the code change represents a merge from a branch, in which case
> three +1s are required.
>
> It may be appropriate for Hadoop, which uses svn, but is not appropriate
> for Drill, which uses git, and therefore every commit is arguably a merge
> from a branch. For non-trivial code changes, we don’t need language in the
> bylaws: the committer would be wise to build consensus in advance, or face
> having his/her change backed out.
>
> Julian
>

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