hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashutosh Chauhan <hashut...@apache.org>
Subject Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Date Sat, 28 Dec 2013 02:12:56 GMT
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 <edlinuxguru@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 <sergey@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 <thejas@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 <
> hashutosh@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 <thejas@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 <cws@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message