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. >
