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:05
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.
> >> >
> >> >
> >> > On Fri, Dec 27, 2013 at 1:03 PM, Thejas Nair <[EMAIL PROTECTED]
> >> >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.