Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hive >> mail # user >> [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws


Copy link to this message
-
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Will do.

Thanks.

Carl
On Wed, Jan 15, 2014 at 3:33 PM, Thejas Nair <[EMAIL PROTECTED]> wrote:

> Adding another sentence to clarify that with a -1, the patch can be
> reverted "If the code has been committed before the -1, the code can
> be reverted until the vote is over."
>
> Approval :  Code Change : The code can be committed after the first
> +1. Committers should wait for reasonable time after patch is
> available so that other committers have had a chance to look at it. If
> a -1 is received and an agreement is not reached among the committers
> on how to resolve the issue, lazy majority with a voting period of 7
> days will be used. If the code has been committed before the -1, the
> code can be reverted until the vote is over.
>
>
> Carl,
> People seem to agree (and other people seem to be OK, considering the
> silence). Can you please include this in the by-law changes being
> proposed and put it to vote ?
>
> Thanks,
> Thejas
>
>
>
>
> On Tue, Jan 14, 2014 at 11:05 PM, Lefty Leverenz
> <[EMAIL PROTECTED]> wrote:
> > This wording seems fine.  You could add "a" here:  "Committers should
> wait
> > for [a] reasonable time...."
> >
> > The guidance is good.
> >
> > +1
> >
> > -- Lefty
> >
> >
> > On Tue, Jan 14, 2014 at 7:53 PM, Thejas Nair <[EMAIL PROTECTED]>
> wrote:
> >
> >> I guess the silence from others on the changing the '24 hours from +1'
> >> to a guidance of '24 hours from patch available', implies they are OK
> >> with this change.
> >>
> >> Proposed general guidance for commits for committers: Wait for 24
> >> hours from the time a patch is made 'patch available'  before doing a
> >> "+1" and committing, so that other committers have had sufficient time
> >> to look at the patch. If the patch is trivial and safe changes such as
> >> a small bug fix, improvement in error message or an incremental
> >> documentation change, it is OK to not wait for 24 hours. For
> >> significant changes the wait should be for a couple of days. If patch
> >> is updated the new patch is significantly different from old one, the
> >> wait should start from the time the new patch is uploaded. Use your
> >> discretion to decide if it would be useful to wait longer than 24
> >> hours on a weekend or holiday for that patch.
> >>
> >> Proposed change in by-law : (if someone can word it better, that would
> >> be great!)
> >>
> >> Action : Code Change : A change made to a codebase of the project and
> >> committed by a committer. This includes source code, documentation,
> >> website content, etc.
> >>
> >> Approval :  Code Change : The code can be committed after the first
> >> +1. Committers should wait for reasonable time after patch is
> >> available so that other committers have had a chance to look at it. If
> >> a -1 is received and an agreement is not reached among the committers
> >> on how to resolve the issue, lazy majority with a voting period of 7
> >> days will be used.
> >>
> >> Minimum Length : Code Change : 7 days on a -1.
> >>
> >>
> >> On Tue, Jan 14, 2014 at 6:25 PM, Vikram Dixit <[EMAIL PROTECTED]>
> >> wrote:
> >> > I think there is value in having some changes committed in less than
> 24
> >> > hours. Particularly for minor changes. Also reverting of patches makes
> >> > sense. Although it could be cumbersome, it is not much worse than what
> >> > would happen now incase of a bad commit. Anyway we wait for the unit
> >> tests
> >> > to complete at the very least.
> >> >
> >> > I am +1 on Thejas' proposal.
> >> >
> >> >
> >> > On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <[EMAIL PROTECTED]>
> >> wrote:
> >> >
> >> >> After thinking some more about it, I am not sure if we need to have a
> >> >> hard and fast rule of 24 hours before commit. I think we should let
> >> >> committers make a call on if this is a trivial, safe and non
> >> >> controversial change and commit it in less than 24 hours in such
> >> >> cases. In case of larger changes, waiting for couple of days for
> >> >> feedback makes sense.