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 <edlinuxg...@gmail.com>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 <ser...@hortonworks.com > >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 <the...@hortonworks.com > >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 < > hashut...@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 <the...@hortonworks.com> > >> 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 <c...@apache.org> > >> 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. >
