"Also something similar to this was said in the thread, "my +1 issue was never committed for N days". Will new bylaws solve this problem? What is the root of the problem?"
For the record, I will suggest the root of this problems is that there are too many people working in "silos", and as the project adds more "silos" the number of people who review issues outside of their silos is not growing. On Sun, Dec 29, 2013 at 1:05 PM, Edward Capriolo <edlinuxg...@gmail.com>wrote: > I think the terms is good. We do not want to have a lame duck scenario. > > Strictly the chair is only responsible for this: > http://www.apache.org/dev/pmc.html#chair > > In many of the other ASF projects the chair is a more active organizer of > the committers. I have seen chairs suggest road maps, hang out in the IRC > and say "Hey committer Y, can you review jira X". We have never had anyone > in place that managed the project in this way, and we may not want that. > However, I do think if we could try bring in fresh body from time to time, > potentially with feature based agendas, who engaged the PMC in discussions > and moved the project in a direction. > > Also something similar to this was said in the thread, "my +1 issue was > never committed for N days". Will new bylaws solve this problem? What is > the root of the problem? > > > On Sun, Dec 29, 2013 at 3:06 AM, Lefty Leverenz > <leftylever...@gmail.com>wrote: > >> 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. >> >> >> > >> > >> > >
