Will do. Thanks.
Carl On Wed, Jan 15, 2014 at 3:33 PM, Thejas Nair <the...@hortonworks.com> 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 > <leftylever...@gmail.com> 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 <the...@hortonworks.com> > 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 <vik...@hortonworks.com> > >> 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 <the...@hortonworks.com> > >> 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. > >> >> If a committer feel that a patch shouldn't have gone in (because of > >> >> technical issues or it went it too soon), they should be able to -1 > it > >> >> and revert the patch, until further review is done. > >> >> > >> >> In other words, I think this can be a guidance instead of a law in > the > >> >> by-laws. What do others in hive community think about this ? > >> >> > >> >> This has been working well in case of other apache hadoop related > >> projects. > >> >> > >> >> > >> >> On Fri, Dec 27, 2013 at 2: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. > >> >> > >> >> -- > >> >> 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. > >> > > -- > 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. >
