You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by Carl Steinbach <cw...@apache.org> on 2013/12/27 04:08:40 UTC
[DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
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
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Alan Gates <ga...@hortonworks.com>.
One other benefit in rotating chairs is that it exposes more of Hive’s PMC members to the board and other Apache old timers. This is helpful in getting better integrated into Apache and becoming a candidate for Apache membership. It is also an excellent education in the Apache Way for those who serve.
Alan.
On Dec 31, 2013, at 3:30 PM, Lefty Leverenz <le...@gmail.com> wrote:
> Okay, I'm convinced that one-year terms for the chair are reasonable.
> Thanks for the reassurance, Edward and Thejas.
>
> 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.
>>
>
> Sergey makes a good point, but the 24h rule seems helpful in prioritizing
> tasks. We're all deadline-driven, right?
>
> I'm the chief culprit of seeing "patch available" and ignoring it until it
> has been committed. Then if I find some minor typo or doc issue, I'm
> embarrassed at posting a comment after the commit because nobody wants to
> revert a patch just for documentation.
>
> -- Lefty
>
>
> On Sun, Dec 29, 2013 at 12:06 PM, Thejas Nair <th...@hortonworks.com>wrote:
>
>> On Sun, Dec 29, 2013 at 12:06 AM, Lefty Leverenz
>> <le...@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?
>>
>> The ramp up time is not significant, as you can see from the list of
>> responsibilities mentioned here -
>> http://www.apache.org/dev/pmc.html#chair .
>> We have enough people in PMC who have been involved with Apache
>> project for long time and are familiar with apache bylaws and way of
>> doing things. Also, the former PMC chairs are likely to be around to
>> help as needed.
>>
>>> Could a current chair be chosen for another consecutive term? Could two
>>> chairs alternate years indefinitely?
>> I would take the meaning of rotation to mean that we have a new chair
>> for the next term. I think it should be OK to have same chair in
>> alternative year. 2 years is a long time and it sounds reasonable
>> given the size of the community ! :)
>>
>>> Do many other projects have annual rotations?
>> Yes, at least hadoop and pig project have that. I could not find
>> by-laws pages easily for other projects.
>>
>>>
>>> Would it be inconvenient to change chairs in the middle of a release?
>> No. The PMC Chair position does not have any special role in 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)*.
>>
>> I think you should feel free to fix such a typos in this wiki without
>> a vote on it ! :)
>>
>> --
>> 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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Alan Gates <ga...@hortonworks.com>.
One other benefit in rotating chairs is that it exposes more of Hive’s PMC members to the board and other Apache old timers. This is helpful in getting better integrated into Apache and becoming a candidate for Apache membership. It is also an excellent education in the Apache Way for those who serve.
Alan.
On Dec 31, 2013, at 3:30 PM, Lefty Leverenz <le...@gmail.com> wrote:
> Okay, I'm convinced that one-year terms for the chair are reasonable.
> Thanks for the reassurance, Edward and Thejas.
>
> 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.
>>
>
> Sergey makes a good point, but the 24h rule seems helpful in prioritizing
> tasks. We're all deadline-driven, right?
>
> I'm the chief culprit of seeing "patch available" and ignoring it until it
> has been committed. Then if I find some minor typo or doc issue, I'm
> embarrassed at posting a comment after the commit because nobody wants to
> revert a patch just for documentation.
>
> -- Lefty
>
>
> On Sun, Dec 29, 2013 at 12:06 PM, Thejas Nair <th...@hortonworks.com>wrote:
>
>> On Sun, Dec 29, 2013 at 12:06 AM, Lefty Leverenz
>> <le...@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?
>>
>> The ramp up time is not significant, as you can see from the list of
>> responsibilities mentioned here -
>> http://www.apache.org/dev/pmc.html#chair .
>> We have enough people in PMC who have been involved with Apache
>> project for long time and are familiar with apache bylaws and way of
>> doing things. Also, the former PMC chairs are likely to be around to
>> help as needed.
>>
>>> Could a current chair be chosen for another consecutive term? Could two
>>> chairs alternate years indefinitely?
>> I would take the meaning of rotation to mean that we have a new chair
>> for the next term. I think it should be OK to have same chair in
>> alternative year. 2 years is a long time and it sounds reasonable
>> given the size of the community ! :)
>>
>>> Do many other projects have annual rotations?
>> Yes, at least hadoop and pig project have that. I could not find
>> by-laws pages easily for other projects.
>>
>>>
>>> Would it be inconvenient to change chairs in the middle of a release?
>> No. The PMC Chair position does not have any special role in 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)*.
>>
>> I think you should feel free to fix such a typos in this wiki without
>> a vote on it ! :)
>>
>> --
>> 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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Lefty Leverenz <le...@gmail.com>.
Okay, I'm convinced that one-year terms for the chair are reasonable.
Thanks for the reassurance, Edward and Thejas.
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.
>
Sergey makes a good point, but the 24h rule seems helpful in prioritizing
tasks. We're all deadline-driven, right?
I'm the chief culprit of seeing "patch available" and ignoring it until it
has been committed. Then if I find some minor typo or doc issue, I'm
embarrassed at posting a comment after the commit because nobody wants to
revert a patch just for documentation.
-- Lefty
On Sun, Dec 29, 2013 at 12:06 PM, Thejas Nair <th...@hortonworks.com>wrote:
> On Sun, Dec 29, 2013 at 12:06 AM, Lefty Leverenz
> <le...@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?
>
> The ramp up time is not significant, as you can see from the list of
> responsibilities mentioned here -
> http://www.apache.org/dev/pmc.html#chair .
> We have enough people in PMC who have been involved with Apache
> project for long time and are familiar with apache bylaws and way of
> doing things. Also, the former PMC chairs are likely to be around to
> help as needed.
>
> > Could a current chair be chosen for another consecutive term? Could two
> > chairs alternate years indefinitely?
> I would take the meaning of rotation to mean that we have a new chair
> for the next term. I think it should be OK to have same chair in
> alternative year. 2 years is a long time and it sounds reasonable
> given the size of the community ! :)
>
> > Do many other projects have annual rotations?
> Yes, at least hadoop and pig project have that. I could not find
> by-laws pages easily for other projects.
>
> >
> > Would it be inconvenient to change chairs in the middle of a release?
> No. The PMC Chair position does not have any special role in 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)*.
>
> I think you should feel free to fix such a typos in this wiki without
> a vote on it ! :)
>
> --
> 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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Lefty Leverenz <le...@gmail.com>.
Okay, I'm convinced that one-year terms for the chair are reasonable.
Thanks for the reassurance, Edward and Thejas.
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.
>
Sergey makes a good point, but the 24h rule seems helpful in prioritizing
tasks. We're all deadline-driven, right?
I'm the chief culprit of seeing "patch available" and ignoring it until it
has been committed. Then if I find some minor typo or doc issue, I'm
embarrassed at posting a comment after the commit because nobody wants to
revert a patch just for documentation.
-- Lefty
On Sun, Dec 29, 2013 at 12:06 PM, Thejas Nair <th...@hortonworks.com>wrote:
> On Sun, Dec 29, 2013 at 12:06 AM, Lefty Leverenz
> <le...@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?
>
> The ramp up time is not significant, as you can see from the list of
> responsibilities mentioned here -
> http://www.apache.org/dev/pmc.html#chair .
> We have enough people in PMC who have been involved with Apache
> project for long time and are familiar with apache bylaws and way of
> doing things. Also, the former PMC chairs are likely to be around to
> help as needed.
>
> > Could a current chair be chosen for another consecutive term? Could two
> > chairs alternate years indefinitely?
> I would take the meaning of rotation to mean that we have a new chair
> for the next term. I think it should be OK to have same chair in
> alternative year. 2 years is a long time and it sounds reasonable
> given the size of the community ! :)
>
> > Do many other projects have annual rotations?
> Yes, at least hadoop and pig project have that. I could not find
> by-laws pages easily for other projects.
>
> >
> > Would it be inconvenient to change chairs in the middle of a release?
> No. The PMC Chair position does not have any special role in 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)*.
>
> I think you should feel free to fix such a typos in this wiki without
> a vote on it ! :)
>
> --
> 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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
On Sun, Dec 29, 2013 at 12:06 AM, Lefty Leverenz
<le...@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?
The ramp up time is not significant, as you can see from the list of
responsibilities mentioned here -
http://www.apache.org/dev/pmc.html#chair .
We have enough people in PMC who have been involved with Apache
project for long time and are familiar with apache bylaws and way of
doing things. Also, the former PMC chairs are likely to be around to
help as needed.
> Could a current chair be chosen for another consecutive term? Could two
> chairs alternate years indefinitely?
I would take the meaning of rotation to mean that we have a new chair
for the next term. I think it should be OK to have same chair in
alternative year. 2 years is a long time and it sounds reasonable
given the size of the community ! :)
> Do many other projects have annual rotations?
Yes, at least hadoop and pig project have that. I could not find
by-laws pages easily for other projects.
>
> Would it be inconvenient to change chairs in the middle of a release?
No. The PMC Chair position does not have any special role in 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)*.
I think you should feel free to fix such a typos in this wiki without
a vote on it ! :)
--
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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
On Sun, Dec 29, 2013 at 12:06 AM, Lefty Leverenz
<le...@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?
The ramp up time is not significant, as you can see from the list of
responsibilities mentioned here -
http://www.apache.org/dev/pmc.html#chair .
We have enough people in PMC who have been involved with Apache
project for long time and are familiar with apache bylaws and way of
doing things. Also, the former PMC chairs are likely to be around to
help as needed.
> Could a current chair be chosen for another consecutive term? Could two
> chairs alternate years indefinitely?
I would take the meaning of rotation to mean that we have a new chair
for the next term. I think it should be OK to have same chair in
alternative year. 2 years is a long time and it sounds reasonable
given the size of the community ! :)
> Do many other projects have annual rotations?
Yes, at least hadoop and pig project have that. I could not find
by-laws pages easily for other projects.
>
> Would it be inconvenient to change chairs in the middle of a release?
No. The PMC Chair position does not have any special role in 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)*.
I think you should feel free to fix such a typos in this wiki without
a vote on it ! :)
--
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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Edward Capriolo <ed...@gmail.com>.
"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 <ed...@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 <le...@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 <hashutosh@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 <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 <cw...@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.
>> >>
>> >
>> >
>>
>
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Edward Capriolo <ed...@gmail.com>.
"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 <ed...@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 <le...@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 <hashutosh@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 <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 <cw...@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.
>> >>
>> >
>> >
>>
>
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Edward Capriolo <ed...@gmail.com>.
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 <le...@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 <hashutosh@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 <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 <cw...@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.
> >>
> >
> >
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Edward Capriolo <ed...@gmail.com>.
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 <le...@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 <hashutosh@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 <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 <cw...@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.
> >>
> >
> >
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Lefty Leverenz <le...@gmail.com>.
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 <ha...@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 <ed...@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 <cw...@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.
>>
>
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Lefty Leverenz <le...@gmail.com>.
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 <ha...@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 <ed...@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 <cw...@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.
>>
>
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Ashutosh Chauhan <ha...@apache.org>.
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 <ed...@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 <th...@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 <cw...@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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Ashutosh Chauhan <ha...@apache.org>.
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 <ed...@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 <th...@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 <cw...@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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Edward Capriolo <ed...@gmail.com>.
" 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 <se...@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 <th...@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 <ha...@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 <th...@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 <cw...@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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Edward Capriolo <ed...@gmail.com>.
" 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 <se...@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 <th...@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 <ha...@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 <th...@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 <cw...@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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Lefty Leverenz <le...@gmail.com>.
> ... to nudge committers to review patches sooner ...
I'm of two minds about this, so I'd like to hear more opinions.
In theory, picking up the pace seems like a good idea. But in practice,
everybody has other tasks to juggle so reviewing patches doesn't always
find a place in the daily schedule.
(Maybe I'm trying to follow too many tickets at once, searching for doc
issues. Could we use a no-work-on-weekends fiction, counting Friday to
Monday as 24 hours?)
-- Lefty
On Wed, Jan 8, 2014 at 12:07 PM, Thejas Nair <th...@hortonworks.com> wrote:
> More thoughts on the 24 hour wait : Changing the by-law to a 24 hr
> wait from first time patch is marked as available (or making this a
> guidance instead of by-law), is likely to nudge committers to review
> patches sooner. Right now, the clock starts ticking for a commit when
> another committer has +1'd. With the change the clock starts ticking
> when patch is available (ie, controlled by contributor). I think this
> 'small' change will improver things for better in a bigger way.
>
>
>
> On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com>
> wrote:
> > After thinking some more about it, I am not sure if we need to have a
> > hard and fast rule of 24 hours before commit. I think we should let
> > committers make a call on if this is a trivial, safe and non
> > controversial change and commit it in less than 24 hours in such
> > cases. In case of larger changes, waiting for couple of days for
> > feedback makes sense.
> > If a committer feel that a patch shouldn't have gone in (because of
> > technical issues or it went it too soon), they should be able to -1 it
> > and revert the patch, until further review is done.
> >
> > In other words, I think this can be a guidance instead of a law in the
> > by-laws. What do others in hive community think about this ?
> >
> > This has been working well in case of other apache hadoop related
> projects.
> >
> >
> > On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
> > <se...@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 <th...@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 <cw...@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.
>
> --
> 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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Lefty Leverenz <le...@gmail.com>.
> ... to nudge committers to review patches sooner ...
I'm of two minds about this, so I'd like to hear more opinions.
In theory, picking up the pace seems like a good idea. But in practice,
everybody has other tasks to juggle so reviewing patches doesn't always
find a place in the daily schedule.
(Maybe I'm trying to follow too many tickets at once, searching for doc
issues. Could we use a no-work-on-weekends fiction, counting Friday to
Monday as 24 hours?)
-- Lefty
On Wed, Jan 8, 2014 at 12:07 PM, Thejas Nair <th...@hortonworks.com> wrote:
> More thoughts on the 24 hour wait : Changing the by-law to a 24 hr
> wait from first time patch is marked as available (or making this a
> guidance instead of by-law), is likely to nudge committers to review
> patches sooner. Right now, the clock starts ticking for a commit when
> another committer has +1'd. With the change the clock starts ticking
> when patch is available (ie, controlled by contributor). I think this
> 'small' change will improver things for better in a bigger way.
>
>
>
> On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com>
> wrote:
> > After thinking some more about it, I am not sure if we need to have a
> > hard and fast rule of 24 hours before commit. I think we should let
> > committers make a call on if this is a trivial, safe and non
> > controversial change and commit it in less than 24 hours in such
> > cases. In case of larger changes, waiting for couple of days for
> > feedback makes sense.
> > If a committer feel that a patch shouldn't have gone in (because of
> > technical issues or it went it too soon), they should be able to -1 it
> > and revert the patch, until further review is done.
> >
> > In other words, I think this can be a guidance instead of a law in the
> > by-laws. What do others in hive community think about this ?
> >
> > This has been working well in case of other apache hadoop related
> projects.
> >
> >
> > On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
> > <se...@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 <th...@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 <cw...@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.
>
> --
> 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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
More thoughts on the 24 hour wait : Changing the by-law to a 24 hr
wait from first time patch is marked as available (or making this a
guidance instead of by-law), is likely to nudge committers to review
patches sooner. Right now, the clock starts ticking for a commit when
another committer has +1'd. With the change the clock starts ticking
when patch is available (ie, controlled by contributor). I think this
'small' change will improver things for better in a bigger way.
On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com> wrote:
> After thinking some more about it, I am not sure if we need to have a
> hard and fast rule of 24 hours before commit. I think we should let
> committers make a call on if this is a trivial, safe and non
> controversial change and commit it in less than 24 hours in such
> cases. In case of larger changes, waiting for couple of days for
> feedback makes sense.
> If a committer feel that a patch shouldn't have gone in (because of
> technical issues or it went it too soon), they should be able to -1 it
> and revert the patch, until further review is done.
>
> In other words, I think this can be a guidance instead of a law in the
> by-laws. What do others in hive community think about this ?
>
> This has been working well in case of other apache hadoop related projects.
>
>
> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
> <se...@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 <th...@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 <ha...@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 <th...@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 <cw...@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.
--
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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
More thoughts on the 24 hour wait : Changing the by-law to a 24 hr
wait from first time patch is marked as available (or making this a
guidance instead of by-law), is likely to nudge committers to review
patches sooner. Right now, the clock starts ticking for a commit when
another committer has +1'd. With the change the clock starts ticking
when patch is available (ie, controlled by contributor). I think this
'small' change will improver things for better in a bigger way.
On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com> wrote:
> After thinking some more about it, I am not sure if we need to have a
> hard and fast rule of 24 hours before commit. I think we should let
> committers make a call on if this is a trivial, safe and non
> controversial change and commit it in less than 24 hours in such
> cases. In case of larger changes, waiting for couple of days for
> feedback makes sense.
> If a committer feel that a patch shouldn't have gone in (because of
> technical issues or it went it too soon), they should be able to -1 it
> and revert the patch, until further review is done.
>
> In other words, I think this can be a guidance instead of a law in the
> by-laws. What do others in hive community think about this ?
>
> This has been working well in case of other apache hadoop related projects.
>
>
> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
> <se...@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 <th...@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 <ha...@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 <th...@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 <cw...@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.
--
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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Carl Steinbach <cw...@gmail.com>.
Will do.
Thanks.
Carl
On Wed, Jan 15, 2014 at 3:33 PM, Thejas Nair <th...@hortonworks.com> wrote:
> Adding another sentence to clarify that with a -1, the patch can be
> reverted "If the code has been committed before the -1, the code can
> be reverted until the vote is over."
>
> Approval : Code Change : The code can be committed after the first
> +1. Committers should wait for reasonable time after patch is
> available so that other committers have had a chance to look at it. If
> a -1 is received and an agreement is not reached among the committers
> on how to resolve the issue, lazy majority with a voting period of 7
> days will be used. If the code has been committed before the -1, the
> code can be reverted until the vote is over.
>
>
> Carl,
> People seem to agree (and other people seem to be OK, considering the
> silence). Can you please include this in the by-law changes being
> proposed and put it to vote ?
>
> Thanks,
> Thejas
>
>
>
>
> On Tue, Jan 14, 2014 at 11:05 PM, Lefty Leverenz
> <le...@gmail.com> wrote:
> > This wording seems fine. You could add "a" here: "Committers should
> wait
> > for [a] reasonable time...."
> >
> > The guidance is good.
> >
> > +1
> >
> > -- Lefty
> >
> >
> > On Tue, Jan 14, 2014 at 7:53 PM, Thejas Nair <th...@hortonworks.com>
> wrote:
> >
> >> I guess the silence from others on the changing the '24 hours from +1'
> >> to a guidance of '24 hours from patch available', implies they are OK
> >> with this change.
> >>
> >> Proposed general guidance for commits for committers: Wait for 24
> >> hours from the time a patch is made 'patch available' before doing a
> >> "+1" and committing, so that other committers have had sufficient time
> >> to look at the patch. If the patch is trivial and safe changes such as
> >> a small bug fix, improvement in error message or an incremental
> >> documentation change, it is OK to not wait for 24 hours. For
> >> significant changes the wait should be for a couple of days. If patch
> >> is updated the new patch is significantly different from old one, the
> >> wait should start from the time the new patch is uploaded. Use your
> >> discretion to decide if it would be useful to wait longer than 24
> >> hours on a weekend or holiday for that patch.
> >>
> >> Proposed change in by-law : (if someone can word it better, that would
> >> be great!)
> >>
> >> Action : Code Change : A change made to a codebase of the project and
> >> committed by a committer. This includes source code, documentation,
> >> website content, etc.
> >>
> >> Approval : Code Change : The code can be committed after the first
> >> +1. Committers should wait for reasonable time after patch is
> >> available so that other committers have had a chance to look at it. If
> >> a -1 is received and an agreement is not reached among the committers
> >> on how to resolve the issue, lazy majority with a voting period of 7
> >> days will be used.
> >>
> >> Minimum Length : Code Change : 7 days on a -1.
> >>
> >>
> >> On Tue, Jan 14, 2014 at 6:25 PM, Vikram Dixit <vi...@hortonworks.com>
> >> wrote:
> >> > I think there is value in having some changes committed in less than
> 24
> >> > hours. Particularly for minor changes. Also reverting of patches makes
> >> > sense. Although it could be cumbersome, it is not much worse than what
> >> > would happen now incase of a bad commit. Anyway we wait for the unit
> >> tests
> >> > to complete at the very least.
> >> >
> >> > I am +1 on Thejas' proposal.
> >> >
> >> >
> >> > On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com>
> >> wrote:
> >> >
> >> >> After thinking some more about it, I am not sure if we need to have a
> >> >> hard and fast rule of 24 hours before commit. I think we should let
> >> >> committers make a call on if this is a trivial, safe and non
> >> >> controversial change and commit it in less than 24 hours in such
> >> >> cases. In case of larger changes, waiting for couple of days for
> >> >> feedback makes sense.
> >> >> If a committer feel that a patch shouldn't have gone in (because of
> >> >> technical issues or it went it too soon), they should be able to -1
> it
> >> >> and revert the patch, until further review is done.
> >> >>
> >> >> In other words, I think this can be a guidance instead of a law in
> the
> >> >> by-laws. What do others in hive community think about this ?
> >> >>
> >> >> This has been working well in case of other apache hadoop related
> >> projects.
> >> >>
> >> >>
> >> >> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
> >> >> <se...@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.
> >> >>
> >> >> --
> >> >> 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.
> >>
>
> --
> 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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Carl Steinbach <cw...@gmail.com>.
Will do.
Thanks.
Carl
On Wed, Jan 15, 2014 at 3:33 PM, Thejas Nair <th...@hortonworks.com> wrote:
> Adding another sentence to clarify that with a -1, the patch can be
> reverted "If the code has been committed before the -1, the code can
> be reverted until the vote is over."
>
> Approval : Code Change : The code can be committed after the first
> +1. Committers should wait for reasonable time after patch is
> available so that other committers have had a chance to look at it. If
> a -1 is received and an agreement is not reached among the committers
> on how to resolve the issue, lazy majority with a voting period of 7
> days will be used. If the code has been committed before the -1, the
> code can be reverted until the vote is over.
>
>
> Carl,
> People seem to agree (and other people seem to be OK, considering the
> silence). Can you please include this in the by-law changes being
> proposed and put it to vote ?
>
> Thanks,
> Thejas
>
>
>
>
> On Tue, Jan 14, 2014 at 11:05 PM, Lefty Leverenz
> <le...@gmail.com> wrote:
> > This wording seems fine. You could add "a" here: "Committers should
> wait
> > for [a] reasonable time...."
> >
> > The guidance is good.
> >
> > +1
> >
> > -- Lefty
> >
> >
> > On Tue, Jan 14, 2014 at 7:53 PM, Thejas Nair <th...@hortonworks.com>
> wrote:
> >
> >> I guess the silence from others on the changing the '24 hours from +1'
> >> to a guidance of '24 hours from patch available', implies they are OK
> >> with this change.
> >>
> >> Proposed general guidance for commits for committers: Wait for 24
> >> hours from the time a patch is made 'patch available' before doing a
> >> "+1" and committing, so that other committers have had sufficient time
> >> to look at the patch. If the patch is trivial and safe changes such as
> >> a small bug fix, improvement in error message or an incremental
> >> documentation change, it is OK to not wait for 24 hours. For
> >> significant changes the wait should be for a couple of days. If patch
> >> is updated the new patch is significantly different from old one, the
> >> wait should start from the time the new patch is uploaded. Use your
> >> discretion to decide if it would be useful to wait longer than 24
> >> hours on a weekend or holiday for that patch.
> >>
> >> Proposed change in by-law : (if someone can word it better, that would
> >> be great!)
> >>
> >> Action : Code Change : A change made to a codebase of the project and
> >> committed by a committer. This includes source code, documentation,
> >> website content, etc.
> >>
> >> Approval : Code Change : The code can be committed after the first
> >> +1. Committers should wait for reasonable time after patch is
> >> available so that other committers have had a chance to look at it. If
> >> a -1 is received and an agreement is not reached among the committers
> >> on how to resolve the issue, lazy majority with a voting period of 7
> >> days will be used.
> >>
> >> Minimum Length : Code Change : 7 days on a -1.
> >>
> >>
> >> On Tue, Jan 14, 2014 at 6:25 PM, Vikram Dixit <vi...@hortonworks.com>
> >> wrote:
> >> > I think there is value in having some changes committed in less than
> 24
> >> > hours. Particularly for minor changes. Also reverting of patches makes
> >> > sense. Although it could be cumbersome, it is not much worse than what
> >> > would happen now incase of a bad commit. Anyway we wait for the unit
> >> tests
> >> > to complete at the very least.
> >> >
> >> > I am +1 on Thejas' proposal.
> >> >
> >> >
> >> > On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com>
> >> wrote:
> >> >
> >> >> After thinking some more about it, I am not sure if we need to have a
> >> >> hard and fast rule of 24 hours before commit. I think we should let
> >> >> committers make a call on if this is a trivial, safe and non
> >> >> controversial change and commit it in less than 24 hours in such
> >> >> cases. In case of larger changes, waiting for couple of days for
> >> >> feedback makes sense.
> >> >> If a committer feel that a patch shouldn't have gone in (because of
> >> >> technical issues or it went it too soon), they should be able to -1
> it
> >> >> and revert the patch, until further review is done.
> >> >>
> >> >> In other words, I think this can be a guidance instead of a law in
> the
> >> >> by-laws. What do others in hive community think about this ?
> >> >>
> >> >> This has been working well in case of other apache hadoop related
> >> projects.
> >> >>
> >> >>
> >> >> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
> >> >> <se...@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.
> >> >>
> >> >> --
> >> >> 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.
> >>
>
> --
> 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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
Adding another sentence to clarify that with a -1, the patch can be
reverted "If the code has been committed before the -1, the code can
be reverted until the vote is over."
Approval : Code Change : The code can be committed after the first
+1. Committers should wait for reasonable time after patch is
available so that other committers have had a chance to look at it. If
a -1 is received and an agreement is not reached among the committers
on how to resolve the issue, lazy majority with a voting period of 7
days will be used. If the code has been committed before the -1, the
code can be reverted until the vote is over.
Carl,
People seem to agree (and other people seem to be OK, considering the
silence). Can you please include this in the by-law changes being
proposed and put it to vote ?
Thanks,
Thejas
On Tue, Jan 14, 2014 at 11:05 PM, Lefty Leverenz
<le...@gmail.com> wrote:
> This wording seems fine. You could add "a" here: "Committers should wait
> for [a] reasonable time...."
>
> The guidance is good.
>
> +1
>
> -- Lefty
>
>
> On Tue, Jan 14, 2014 at 7:53 PM, Thejas Nair <th...@hortonworks.com> wrote:
>
>> I guess the silence from others on the changing the '24 hours from +1'
>> to a guidance of '24 hours from patch available', implies they are OK
>> with this change.
>>
>> Proposed general guidance for commits for committers: Wait for 24
>> hours from the time a patch is made 'patch available' before doing a
>> "+1" and committing, so that other committers have had sufficient time
>> to look at the patch. If the patch is trivial and safe changes such as
>> a small bug fix, improvement in error message or an incremental
>> documentation change, it is OK to not wait for 24 hours. For
>> significant changes the wait should be for a couple of days. If patch
>> is updated the new patch is significantly different from old one, the
>> wait should start from the time the new patch is uploaded. Use your
>> discretion to decide if it would be useful to wait longer than 24
>> hours on a weekend or holiday for that patch.
>>
>> Proposed change in by-law : (if someone can word it better, that would
>> be great!)
>>
>> Action : Code Change : A change made to a codebase of the project and
>> committed by a committer. This includes source code, documentation,
>> website content, etc.
>>
>> Approval : Code Change : The code can be committed after the first
>> +1. Committers should wait for reasonable time after patch is
>> available so that other committers have had a chance to look at it. If
>> a -1 is received and an agreement is not reached among the committers
>> on how to resolve the issue, lazy majority with a voting period of 7
>> days will be used.
>>
>> Minimum Length : Code Change : 7 days on a -1.
>>
>>
>> On Tue, Jan 14, 2014 at 6:25 PM, Vikram Dixit <vi...@hortonworks.com>
>> wrote:
>> > I think there is value in having some changes committed in less than 24
>> > hours. Particularly for minor changes. Also reverting of patches makes
>> > sense. Although it could be cumbersome, it is not much worse than what
>> > would happen now incase of a bad commit. Anyway we wait for the unit
>> tests
>> > to complete at the very least.
>> >
>> > I am +1 on Thejas' proposal.
>> >
>> >
>> > On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com>
>> wrote:
>> >
>> >> After thinking some more about it, I am not sure if we need to have a
>> >> hard and fast rule of 24 hours before commit. I think we should let
>> >> committers make a call on if this is a trivial, safe and non
>> >> controversial change and commit it in less than 24 hours in such
>> >> cases. In case of larger changes, waiting for couple of days for
>> >> feedback makes sense.
>> >> If a committer feel that a patch shouldn't have gone in (because of
>> >> technical issues or it went it too soon), they should be able to -1 it
>> >> and revert the patch, until further review is done.
>> >>
>> >> In other words, I think this can be a guidance instead of a law in the
>> >> by-laws. What do others in hive community think about this ?
>> >>
>> >> This has been working well in case of other apache hadoop related
>> projects.
>> >>
>> >>
>> >> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
>> >> <se...@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 <th...@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 <cw...@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.
>> >>
>> >> --
>> >> 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.
>>
--
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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
Adding another sentence to clarify that with a -1, the patch can be
reverted "If the code has been committed before the -1, the code can
be reverted until the vote is over."
Approval : Code Change : The code can be committed after the first
+1. Committers should wait for reasonable time after patch is
available so that other committers have had a chance to look at it. If
a -1 is received and an agreement is not reached among the committers
on how to resolve the issue, lazy majority with a voting period of 7
days will be used. If the code has been committed before the -1, the
code can be reverted until the vote is over.
Carl,
People seem to agree (and other people seem to be OK, considering the
silence). Can you please include this in the by-law changes being
proposed and put it to vote ?
Thanks,
Thejas
On Tue, Jan 14, 2014 at 11:05 PM, Lefty Leverenz
<le...@gmail.com> wrote:
> This wording seems fine. You could add "a" here: "Committers should wait
> for [a] reasonable time...."
>
> The guidance is good.
>
> +1
>
> -- Lefty
>
>
> On Tue, Jan 14, 2014 at 7:53 PM, Thejas Nair <th...@hortonworks.com> wrote:
>
>> I guess the silence from others on the changing the '24 hours from +1'
>> to a guidance of '24 hours from patch available', implies they are OK
>> with this change.
>>
>> Proposed general guidance for commits for committers: Wait for 24
>> hours from the time a patch is made 'patch available' before doing a
>> "+1" and committing, so that other committers have had sufficient time
>> to look at the patch. If the patch is trivial and safe changes such as
>> a small bug fix, improvement in error message or an incremental
>> documentation change, it is OK to not wait for 24 hours. For
>> significant changes the wait should be for a couple of days. If patch
>> is updated the new patch is significantly different from old one, the
>> wait should start from the time the new patch is uploaded. Use your
>> discretion to decide if it would be useful to wait longer than 24
>> hours on a weekend or holiday for that patch.
>>
>> Proposed change in by-law : (if someone can word it better, that would
>> be great!)
>>
>> Action : Code Change : A change made to a codebase of the project and
>> committed by a committer. This includes source code, documentation,
>> website content, etc.
>>
>> Approval : Code Change : The code can be committed after the first
>> +1. Committers should wait for reasonable time after patch is
>> available so that other committers have had a chance to look at it. If
>> a -1 is received and an agreement is not reached among the committers
>> on how to resolve the issue, lazy majority with a voting period of 7
>> days will be used.
>>
>> Minimum Length : Code Change : 7 days on a -1.
>>
>>
>> On Tue, Jan 14, 2014 at 6:25 PM, Vikram Dixit <vi...@hortonworks.com>
>> wrote:
>> > I think there is value in having some changes committed in less than 24
>> > hours. Particularly for minor changes. Also reverting of patches makes
>> > sense. Although it could be cumbersome, it is not much worse than what
>> > would happen now incase of a bad commit. Anyway we wait for the unit
>> tests
>> > to complete at the very least.
>> >
>> > I am +1 on Thejas' proposal.
>> >
>> >
>> > On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com>
>> wrote:
>> >
>> >> After thinking some more about it, I am not sure if we need to have a
>> >> hard and fast rule of 24 hours before commit. I think we should let
>> >> committers make a call on if this is a trivial, safe and non
>> >> controversial change and commit it in less than 24 hours in such
>> >> cases. In case of larger changes, waiting for couple of days for
>> >> feedback makes sense.
>> >> If a committer feel that a patch shouldn't have gone in (because of
>> >> technical issues or it went it too soon), they should be able to -1 it
>> >> and revert the patch, until further review is done.
>> >>
>> >> In other words, I think this can be a guidance instead of a law in the
>> >> by-laws. What do others in hive community think about this ?
>> >>
>> >> This has been working well in case of other apache hadoop related
>> projects.
>> >>
>> >>
>> >> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
>> >> <se...@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 <th...@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 <cw...@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.
>> >>
>> >> --
>> >> 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.
>>
--
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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Lefty Leverenz <le...@gmail.com>.
This wording seems fine. You could add "a" here: "Committers should wait
for [a] reasonable time...."
The guidance is good.
+1
-- Lefty
On Tue, Jan 14, 2014 at 7:53 PM, Thejas Nair <th...@hortonworks.com> wrote:
> I guess the silence from others on the changing the '24 hours from +1'
> to a guidance of '24 hours from patch available', implies they are OK
> with this change.
>
> Proposed general guidance for commits for committers: Wait for 24
> hours from the time a patch is made 'patch available' before doing a
> "+1" and committing, so that other committers have had sufficient time
> to look at the patch. If the patch is trivial and safe changes such as
> a small bug fix, improvement in error message or an incremental
> documentation change, it is OK to not wait for 24 hours. For
> significant changes the wait should be for a couple of days. If patch
> is updated the new patch is significantly different from old one, the
> wait should start from the time the new patch is uploaded. Use your
> discretion to decide if it would be useful to wait longer than 24
> hours on a weekend or holiday for that patch.
>
> Proposed change in by-law : (if someone can word it better, that would
> be great!)
>
> Action : Code Change : A change made to a codebase of the project and
> committed by a committer. This includes source code, documentation,
> website content, etc.
>
> Approval : Code Change : The code can be committed after the first
> +1. Committers should wait for reasonable time after patch is
> available so that other committers have had a chance to look at it. If
> a -1 is received and an agreement is not reached among the committers
> on how to resolve the issue, lazy majority with a voting period of 7
> days will be used.
>
> Minimum Length : Code Change : 7 days on a -1.
>
>
> On Tue, Jan 14, 2014 at 6:25 PM, Vikram Dixit <vi...@hortonworks.com>
> wrote:
> > I think there is value in having some changes committed in less than 24
> > hours. Particularly for minor changes. Also reverting of patches makes
> > sense. Although it could be cumbersome, it is not much worse than what
> > would happen now incase of a bad commit. Anyway we wait for the unit
> tests
> > to complete at the very least.
> >
> > I am +1 on Thejas' proposal.
> >
> >
> > On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com>
> wrote:
> >
> >> After thinking some more about it, I am not sure if we need to have a
> >> hard and fast rule of 24 hours before commit. I think we should let
> >> committers make a call on if this is a trivial, safe and non
> >> controversial change and commit it in less than 24 hours in such
> >> cases. In case of larger changes, waiting for couple of days for
> >> feedback makes sense.
> >> If a committer feel that a patch shouldn't have gone in (because of
> >> technical issues or it went it too soon), they should be able to -1 it
> >> and revert the patch, until further review is done.
> >>
> >> In other words, I think this can be a guidance instead of a law in the
> >> by-laws. What do others in hive community think about this ?
> >>
> >> This has been working well in case of other apache hadoop related
> projects.
> >>
> >>
> >> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
> >> <se...@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 <th...@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 <cw...@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.
> >>
> >> --
> >> 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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Lefty Leverenz <le...@gmail.com>.
This wording seems fine. You could add "a" here: "Committers should wait
for [a] reasonable time...."
The guidance is good.
+1
-- Lefty
On Tue, Jan 14, 2014 at 7:53 PM, Thejas Nair <th...@hortonworks.com> wrote:
> I guess the silence from others on the changing the '24 hours from +1'
> to a guidance of '24 hours from patch available', implies they are OK
> with this change.
>
> Proposed general guidance for commits for committers: Wait for 24
> hours from the time a patch is made 'patch available' before doing a
> "+1" and committing, so that other committers have had sufficient time
> to look at the patch. If the patch is trivial and safe changes such as
> a small bug fix, improvement in error message or an incremental
> documentation change, it is OK to not wait for 24 hours. For
> significant changes the wait should be for a couple of days. If patch
> is updated the new patch is significantly different from old one, the
> wait should start from the time the new patch is uploaded. Use your
> discretion to decide if it would be useful to wait longer than 24
> hours on a weekend or holiday for that patch.
>
> Proposed change in by-law : (if someone can word it better, that would
> be great!)
>
> Action : Code Change : A change made to a codebase of the project and
> committed by a committer. This includes source code, documentation,
> website content, etc.
>
> Approval : Code Change : The code can be committed after the first
> +1. Committers should wait for reasonable time after patch is
> available so that other committers have had a chance to look at it. If
> a -1 is received and an agreement is not reached among the committers
> on how to resolve the issue, lazy majority with a voting period of 7
> days will be used.
>
> Minimum Length : Code Change : 7 days on a -1.
>
>
> On Tue, Jan 14, 2014 at 6:25 PM, Vikram Dixit <vi...@hortonworks.com>
> wrote:
> > I think there is value in having some changes committed in less than 24
> > hours. Particularly for minor changes. Also reverting of patches makes
> > sense. Although it could be cumbersome, it is not much worse than what
> > would happen now incase of a bad commit. Anyway we wait for the unit
> tests
> > to complete at the very least.
> >
> > I am +1 on Thejas' proposal.
> >
> >
> > On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com>
> wrote:
> >
> >> After thinking some more about it, I am not sure if we need to have a
> >> hard and fast rule of 24 hours before commit. I think we should let
> >> committers make a call on if this is a trivial, safe and non
> >> controversial change and commit it in less than 24 hours in such
> >> cases. In case of larger changes, waiting for couple of days for
> >> feedback makes sense.
> >> If a committer feel that a patch shouldn't have gone in (because of
> >> technical issues or it went it too soon), they should be able to -1 it
> >> and revert the patch, until further review is done.
> >>
> >> In other words, I think this can be a guidance instead of a law in the
> >> by-laws. What do others in hive community think about this ?
> >>
> >> This has been working well in case of other apache hadoop related
> projects.
> >>
> >>
> >> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
> >> <se...@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 <th...@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 <cw...@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.
> >>
> >> --
> >> 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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
I guess the silence from others on the changing the '24 hours from +1'
to a guidance of '24 hours from patch available', implies they are OK
with this change.
Proposed general guidance for commits for committers: Wait for 24
hours from the time a patch is made 'patch available' before doing a
"+1" and committing, so that other committers have had sufficient time
to look at the patch. If the patch is trivial and safe changes such as
a small bug fix, improvement in error message or an incremental
documentation change, it is OK to not wait for 24 hours. For
significant changes the wait should be for a couple of days. If patch
is updated the new patch is significantly different from old one, the
wait should start from the time the new patch is uploaded. Use your
discretion to decide if it would be useful to wait longer than 24
hours on a weekend or holiday for that patch.
Proposed change in by-law : (if someone can word it better, that would
be great!)
Action : Code Change : A change made to a codebase of the project and
committed by a committer. This includes source code, documentation,
website content, etc.
Approval : Code Change : The code can be committed after the first
+1. Committers should wait for reasonable time after patch is
available so that other committers have had a chance to look at it. If
a -1 is received and an agreement is not reached among the committers
on how to resolve the issue, lazy majority with a voting period of 7
days will be used.
Minimum Length : Code Change : 7 days on a -1.
On Tue, Jan 14, 2014 at 6:25 PM, Vikram Dixit <vi...@hortonworks.com> wrote:
> I think there is value in having some changes committed in less than 24
> hours. Particularly for minor changes. Also reverting of patches makes
> sense. Although it could be cumbersome, it is not much worse than what
> would happen now incase of a bad commit. Anyway we wait for the unit tests
> to complete at the very least.
>
> I am +1 on Thejas' proposal.
>
>
> On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com> wrote:
>
>> After thinking some more about it, I am not sure if we need to have a
>> hard and fast rule of 24 hours before commit. I think we should let
>> committers make a call on if this is a trivial, safe and non
>> controversial change and commit it in less than 24 hours in such
>> cases. In case of larger changes, waiting for couple of days for
>> feedback makes sense.
>> If a committer feel that a patch shouldn't have gone in (because of
>> technical issues or it went it too soon), they should be able to -1 it
>> and revert the patch, until further review is done.
>>
>> In other words, I think this can be a guidance instead of a law in the
>> by-laws. What do others in hive community think about this ?
>>
>> This has been working well in case of other apache hadoop related projects.
>>
>>
>> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
>> <se...@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 <th...@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 <th...@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 <cw...@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.
>>
>> --
>> 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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
I guess the silence from others on the changing the '24 hours from +1'
to a guidance of '24 hours from patch available', implies they are OK
with this change.
Proposed general guidance for commits for committers: Wait for 24
hours from the time a patch is made 'patch available' before doing a
"+1" and committing, so that other committers have had sufficient time
to look at the patch. If the patch is trivial and safe changes such as
a small bug fix, improvement in error message or an incremental
documentation change, it is OK to not wait for 24 hours. For
significant changes the wait should be for a couple of days. If patch
is updated the new patch is significantly different from old one, the
wait should start from the time the new patch is uploaded. Use your
discretion to decide if it would be useful to wait longer than 24
hours on a weekend or holiday for that patch.
Proposed change in by-law : (if someone can word it better, that would
be great!)
Action : Code Change : A change made to a codebase of the project and
committed by a committer. This includes source code, documentation,
website content, etc.
Approval : Code Change : The code can be committed after the first
+1. Committers should wait for reasonable time after patch is
available so that other committers have had a chance to look at it. If
a -1 is received and an agreement is not reached among the committers
on how to resolve the issue, lazy majority with a voting period of 7
days will be used.
Minimum Length : Code Change : 7 days on a -1.
On Tue, Jan 14, 2014 at 6:25 PM, Vikram Dixit <vi...@hortonworks.com> wrote:
> I think there is value in having some changes committed in less than 24
> hours. Particularly for minor changes. Also reverting of patches makes
> sense. Although it could be cumbersome, it is not much worse than what
> would happen now incase of a bad commit. Anyway we wait for the unit tests
> to complete at the very least.
>
> I am +1 on Thejas' proposal.
>
>
> On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com> wrote:
>
>> After thinking some more about it, I am not sure if we need to have a
>> hard and fast rule of 24 hours before commit. I think we should let
>> committers make a call on if this is a trivial, safe and non
>> controversial change and commit it in less than 24 hours in such
>> cases. In case of larger changes, waiting for couple of days for
>> feedback makes sense.
>> If a committer feel that a patch shouldn't have gone in (because of
>> technical issues or it went it too soon), they should be able to -1 it
>> and revert the patch, until further review is done.
>>
>> In other words, I think this can be a guidance instead of a law in the
>> by-laws. What do others in hive community think about this ?
>>
>> This has been working well in case of other apache hadoop related projects.
>>
>>
>> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
>> <se...@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 <th...@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 <th...@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 <cw...@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.
>>
>> --
>> 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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Vikram Dixit <vi...@hortonworks.com>.
I think there is value in having some changes committed in less than 24
hours. Particularly for minor changes. Also reverting of patches makes
sense. Although it could be cumbersome, it is not much worse than what
would happen now incase of a bad commit. Anyway we wait for the unit tests
to complete at the very least.
I am +1 on Thejas' proposal.
On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com> wrote:
> After thinking some more about it, I am not sure if we need to have a
> hard and fast rule of 24 hours before commit. I think we should let
> committers make a call on if this is a trivial, safe and non
> controversial change and commit it in less than 24 hours in such
> cases. In case of larger changes, waiting for couple of days for
> feedback makes sense.
> If a committer feel that a patch shouldn't have gone in (because of
> technical issues or it went it too soon), they should be able to -1 it
> and revert the patch, until further review is done.
>
> In other words, I think this can be a guidance instead of a law in the
> by-laws. What do others in hive community think about this ?
>
> This has been working well in case of other apache hadoop related projects.
>
>
> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
> <se...@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 <th...@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 <th...@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 <cw...@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.
>
> --
> 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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Vikram Dixit <vi...@hortonworks.com>.
I think there is value in having some changes committed in less than 24
hours. Particularly for minor changes. Also reverting of patches makes
sense. Although it could be cumbersome, it is not much worse than what
would happen now incase of a bad commit. Anyway we wait for the unit tests
to complete at the very least.
I am +1 on Thejas' proposal.
On Tue, Jan 7, 2014 at 7:01 PM, Thejas Nair <th...@hortonworks.com> wrote:
> After thinking some more about it, I am not sure if we need to have a
> hard and fast rule of 24 hours before commit. I think we should let
> committers make a call on if this is a trivial, safe and non
> controversial change and commit it in less than 24 hours in such
> cases. In case of larger changes, waiting for couple of days for
> feedback makes sense.
> If a committer feel that a patch shouldn't have gone in (because of
> technical issues or it went it too soon), they should be able to -1 it
> and revert the patch, until further review is done.
>
> In other words, I think this can be a guidance instead of a law in the
> by-laws. What do others in hive community think about this ?
>
> This has been working well in case of other apache hadoop related projects.
>
>
> On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
> <se...@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 <th...@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 <th...@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 <cw...@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.
>
> --
> 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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
After thinking some more about it, I am not sure if we need to have a
hard and fast rule of 24 hours before commit. I think we should let
committers make a call on if this is a trivial, safe and non
controversial change and commit it in less than 24 hours in such
cases. In case of larger changes, waiting for couple of days for
feedback makes sense.
If a committer feel that a patch shouldn't have gone in (because of
technical issues or it went it too soon), they should be able to -1 it
and revert the patch, until further review is done.
In other words, I think this can be a guidance instead of a law in the
by-laws. What do others in hive community think about this ?
This has been working well in case of other apache hadoop related projects.
On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
<se...@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 <th...@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 <ha...@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 <th...@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 <cw...@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.
--
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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
After thinking some more about it, I am not sure if we need to have a
hard and fast rule of 24 hours before commit. I think we should let
committers make a call on if this is a trivial, safe and non
controversial change and commit it in less than 24 hours in such
cases. In case of larger changes, waiting for couple of days for
feedback makes sense.
If a committer feel that a patch shouldn't have gone in (because of
technical issues or it went it too soon), they should be able to -1 it
and revert the patch, until further review is done.
In other words, I think this can be a guidance instead of a law in the
by-laws. What do others in hive community think about this ?
This has been working well in case of other apache hadoop related projects.
On Fri, Dec 27, 2013 at 2:28 PM, Sergey Shelukhin
<se...@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 <th...@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 <ha...@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 <th...@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 <cw...@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.
--
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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Sergey Shelukhin <se...@hortonworks.com>.
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 <th...@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 <ha...@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 <th...@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 <cw...@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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Sergey Shelukhin <se...@hortonworks.com>.
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 <th...@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 <ha...@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 <th...@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 <cw...@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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
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 <ha...@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 <th...@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 <cw...@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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
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 <ha...@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 <th...@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 <cw...@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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Ashutosh Chauhan <ha...@apache.org>.
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 <th...@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 <cw...@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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Ashutosh Chauhan <ha...@apache.org>.
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 <th...@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 <cw...@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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Ashutosh Chauhan <ha...@apache.org>.
I will echo Thejas's concern w.r.t RC voting. Usually it takes 2-3 rounds
of RC and folks generally tend to vote towards end of cycle. So, if we
increase it to 7 days, we are looking at 21 days (in worst case) to get a
release out, which may not be what we want. So, for RC vote my suggestion
will be to stick with current 3-days voting period.
For other votes (like committers, branch merges etc.) I don't have much
preference, but there also 7-days looks excessive.
Thanks,
Ashutosh
On Fri, Dec 27, 2013 at 9:33 AM, Thejas Nair <th...@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 <cw...@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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Ashutosh Chauhan <ha...@apache.org>.
I will echo Thejas's concern w.r.t RC voting. Usually it takes 2-3 rounds
of RC and folks generally tend to vote towards end of cycle. So, if we
increase it to 7 days, we are looking at 21 days (in worst case) to get a
release out, which may not be what we want. So, for RC vote my suggestion
will be to stick with current 3-days voting period.
For other votes (like committers, branch merges etc.) I don't have much
preference, but there also 7-days looks excessive.
Thanks,
Ashutosh
On Fri, Dec 27, 2013 at 9:33 AM, Thejas Nair <th...@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 <cw...@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.
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
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 <cw...@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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Edward Capriolo <ed...@gmail.com>.
I like the changes. I believe rotating the PMC chair will keep the project
fresh. Work and life events come in spurts, and it's hard to step down when
your at the top (
http://disinfo.com/2013/02/ratzinger-resigns-first-pope-to-quit-since-1415/
:) .
On Thu, Dec 26, 2013 at 10:08 PM, Carl Steinbach <cw...@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
>
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Thejas Nair <th...@hortonworks.com>.
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 <cw...@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.
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Posted by Edward Capriolo <ed...@gmail.com>.
I like the changes. I believe rotating the PMC chair will keep the project
fresh. Work and life events come in spurts, and it's hard to step down when
your at the top (
http://disinfo.com/2013/02/ratzinger-resigns-first-pope-to-quit-since-1415/
:) .
On Thu, Dec 26, 2013 at 10:08 PM, Carl Steinbach <cw...@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
>