> ... to nudge committers to review patches sooner ... I'm of two minds about this, so I'd like to hear more opinions.
In theory, picking up the pace seems like a good idea. But in practice, everybody has other tasks to juggle so reviewing patches doesn't always find a place in the daily schedule. (Maybe I'm trying to follow too many tickets at once, searching for doc issues. Could we use a no-work-on-weekends fiction, counting Friday to Monday as 24 hours?) -- Lefty On Wed, Jan 8, 2014 at 12:07 PM, Thejas Nair <the...@hortonworks.com> wrote: > More thoughts on the 24 hour wait : Changing the by-law to a 24 hr > wait from first time patch is marked as available (or making this a > guidance instead of by-law), is likely to nudge committers to review > patches sooner. Right now, the clock starts ticking for a commit when > another committer has +1'd. With the change the clock starts ticking > when patch is available (ie, controlled by contributor). I think this > 'small' change will improver things for better in a bigger way. > > > > 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. >
