Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hive, mail # user - [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws


Copy link to this message
-
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Edward Capriolo 2013-12-29, 18:13
"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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]
>> >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 <[EMAIL PROTECTED]
>> >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 <
>> [EMAIL PROTECTED]
>> >> >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.