Let's discuss annual rotation of the PMC chair a bit more. Although I agree with the points made in favor, I wonder about frequent loss of expertise and needing to establish new relationships. What's the ramp-up time?
Could a current chair be chosen for another consecutive term? Could two chairs alternate years indefinitely? >From an ASF board perspective, I imagine longer terms would be preferable. Do many other projects have annual rotations? Would it be inconvenient to change chairs in the middle of a release? And now to trivialize my comments: while making other changes, let's fix this typo: "Membership of the PMC can be revoked by an unanimous vote ..." *(should be "a unanimous ..." just like "a university" because the rule is based on sound, not spelling)*. -- Lefty On Fri, Dec 27, 2013 at 6:12 PM, Ashutosh Chauhan <hashut...@apache.org>wrote: > 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. >> > >
