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.
