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
" I propose to modify
> that one such that there must be 24 hour duration between creation of jira
> and patch commit, that will ensure that there is sufficient time for folks
> to see changes which are happening on trunk."

One thing. Many of the jira's have little detail. So someone could file a
ticket like:

12:01am
Subject: Change optimizer to deal with redundant data
Body: at times the optimizer can skip redundant data. Like we talked about
for 6 hours at the meetup.

11:59 Patch submitted
12:01am (next day) +1 commit.

How about we word it like this:

The accepted patch must have been uploaded to jira 24 hours before it is
committed.

In this way it gives everyone 24 hours to look at the code to be committed.

On Fri, Dec 27, 2013 at 5:28 PM, Sergey Shelukhin <[EMAIL PROTECTED]>wrote:

> I actually have a patch out on a jira that says it will be committed in 24
> hours from long ago ;)
>
> Is 24h rule is needed at all? In other projects, I've seen patches simply
> reverted by author (or someone else). It's a rare occurrence, and it should
> be possible to revert a patch if someone -1s it after commit, esp. within
> the same 24 hours when not many other changes are in.
>
>
> On Fri, Dec 27, 2013 at 1:03 PM, Thejas Nair <[EMAIL PROTECTED]>wrote:
>
>> I agree with Ashutosh that the 24 hour waiting period after +1 is
>> cumbersome, I have also forgotten to commit patches after +1,
>> resulting in patches going stale.
>>
>> But I think 24 hours wait between creation of jira and patch commit is
>> not very useful, as the thing to be examined is the patch and not the
>> jira summary/description.
>> I think having a waiting period of 24 hours between a jira being made
>> 'patch available' and committing is better and sufficient.
>>
>>
>> On Fri, Dec 27, 2013 at 11:44 AM, Ashutosh Chauhan <[EMAIL PROTECTED]>
>> wrote:
>> > Proposed changes look good to me, both suggested by Carl and Thejas.
>> > Another one I would like to add for consideration is: 24 hour rule
>> between
>> > +1 and commit. Since this exists only in Hive (no other apache project
>> > which I am aware of) this surprises new contributors. More importantly,
>> I
>> > have seen multiple cases where patch didn't get committed because
>> committer
>> > after +1 forgot to commit after 24 hours have passed. I propose to
>> modify
>> > that one such that there must be 24 hour duration between creation of
>> jira
>> > and patch commit, that will ensure that there is sufficient time for
>> folks
>> > to see changes which are happening on trunk.
>> >
>> > Thanks,
>> > Ashutosh
>> >
>> >
>> > On Fri, Dec 27, 2013 at 9:33 AM, Thejas Nair <[EMAIL PROTECTED]>
>> wrote:
>> >
>> >> The changes look good to me.
>> >> Only concern I have is with the 7 days for release candidate voting.
>> >> Based on my experience with releases, it often takes few cycles to get
>> >> the candidate out, and people tend to vote closer to the end of the
>> >> voting period. This can mean that it takes several weeks to get a
>> >> release out. But this will not be so much of a problem as long as
>> >> people don't wait for end of the voting period to vote, or if they
>> >> look at the candidate branch even before the release candidate is out.
>> >>
>> >> Should we also include a provision for branch merges ? I think we
>> >> should have a longer voting period for branch merges (3 days instead
>> >> of 1?) and require 3 +1s (this part is also in the hadoop by-law ) .
>> >>
>> >>
>> >> On Thu, Dec 26, 2013 at 7:08 PM, Carl Steinbach <[EMAIL PROTECTED]>
>> wrote:
>> >> > I think we should make several changes to the Apache Hive Project
>> Bylaws.
>> >> > The proposed changes are available for review here:
>> >> >
>> >> >
>> >>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=38568856
>> >> >
>> >> > Most of the changes were directly inspired by provisions found in the
>> >> Apache
>> >> > Hadoop Project Bylaws.
>> >> >
>> >> > Summary of proposed changes:
>> >> >
>> >>
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