Return-Path: X-Original-To: apmail-hive-dev-archive@www.apache.org Delivered-To: apmail-hive-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7F4F810C17 for ; Sat, 28 Dec 2013 02:13:23 +0000 (UTC) Received: (qmail 42139 invoked by uid 500); 28 Dec 2013 02:13:20 -0000 Delivered-To: apmail-hive-dev-archive@hive.apache.org Received: (qmail 41945 invoked by uid 500); 28 Dec 2013 02:13:19 -0000 Mailing-List: contact dev-help@hive.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hive.apache.org Delivered-To: mailing list dev@hive.apache.org Received: (qmail 41922 invoked by uid 99); 28 Dec 2013 02:13:19 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Dec 2013 02:13:19 +0000 Received: from localhost (HELO mail-we0-f181.google.com) (127.0.0.1) (smtp-auth username hashutosh, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Dec 2013 02:13:18 +0000 Received: by mail-we0-f181.google.com with SMTP id x55so8446412wes.26 for ; Fri, 27 Dec 2013 18:13:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6+7/T/ewT5GFbWoLtunr9wN7PTd96iKB9Vmu29eVqlg=; b=Y1/ZWGLC2cqDIhGkgEAs8fv8pxK2IA3HgXiL8Bs0l0YGRFgUxpCHfP3VcRTp/X0Zgh n0bBYJpNv7HuGyzgdfEici9UxJdVJQ2IcVaUcxm5JxpTCYXfn1XZP8Nh4MFrThUBhG5M uuf0i4yc0a3Y60qRMoZJQz+OdE0YCS4uZswYyNc3zZd5GNBy2NuT5XRAavTTh/4M9leN DX9BsHSs+gF3TsO+cdw5gAorPzi7a1j2SZAE59bPiylj6hgWbk9Vj53YILTO5Ps22DyF mKPE1gKgk6/FrTRRCstj+iOUWH1yUCxxxpGy4roajQkz0wFEWj5pzwsehhEN7rJVtIN0 roiA== X-Received: by 10.180.79.106 with SMTP id i10mr25167181wix.23.1388196796669; Fri, 27 Dec 2013 18:13:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.134.40 with HTTP; Fri, 27 Dec 2013 18:12:56 -0800 (PST) In-Reply-To: References:

From: Ashutosh Chauhan Date: Fri, 27 Dec 2013 18:12:56 -0800 Message-ID: Subject: Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws To: "dev@hive.apache.org" Cc: "user@hive.apache.org" , "private@hive.apache.org" Content-Type: multipart/alternative; boundary=f46d0421a639f1a64904ee8ec002 --f46d0421a639f1a64904ee8ec002 Content-Type: text/plain; charset=ISO-8859-1 This is what Thejas has also suggested earlier in thread. Sounds good to me. On Fri, Dec 27, 2013 at 5:43 PM, Edward Capriolo wrote: > " 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 >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 >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 < > hashutosh@apache.org> > >> 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 > >> 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 > >> 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: > >> >> > > >> >> > * Add provisions for branch committers and speculative branches. > >> >> > > >> >> > * Define the responsibilities of a release manager. > >> >> > > >> >> > * PMC Chairs serve for one year and are elected by the PMC using > >> Single > >> >> > Transferable Vote (STV) voting. > >> >> > > >> >> > * With the exception of code change votes, the minimum length of > all > >> >> voting > >> >> > periods is extended to seven days. > >> >> > > >> >> > Thanks. > >> >> > > >> >> > Carl > >> >> > >> >> -- > >> >> CONFIDENTIALITY NOTICE > >> >> NOTICE: This message is intended for the use of the individual or > >> entity to > >> >> which it is addressed and may contain information that is > confidential, > >> >> privileged and exempt from disclosure under applicable law. If the > >> reader > >> >> of this message is not the intended recipient, you are hereby > notified > >> that > >> >> any printing, copying, dissemination, distribution, disclosure or > >> >> forwarding of this communication is strictly prohibited. If you have > >> >> received this communication in error, please contact the sender > >> immediately > >> >> and delete it from your system. Thank You. > >> >> > >> > >> -- > >> CONFIDENTIALITY NOTICE > >> NOTICE: This message is intended for the use of the individual or entity > >> to > >> which it is addressed and may contain information that is confidential, > >> privileged and exempt from disclosure under applicable law. If the > reader > >> of this message is not the intended recipient, you are hereby notified > >> that > >> any printing, copying, dissemination, distribution, disclosure or > >> forwarding of this communication is strictly prohibited. If you have > >> received this communication in error, please contact the sender > >> immediately > >> and delete it from your system. Thank You. > >> > > > > > > CONFIDENTIALITY NOTICE > > NOTICE: This message is intended for the use of the individual or entity > > to which it is addressed and may contain information that is > confidential, > > privileged and exempt from disclosure under applicable law. If the reader > > of this message is not the intended recipient, you are hereby notified > that > > any printing, copying, dissemination, distribution, disclosure or > > forwarding of this communication is strictly prohibited. If you have > > received this communication in error, please contact the sender > immediately > > and delete it from your system. Thank You. > --f46d0421a639f1a64904ee8ec002--