Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB