hive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Steinbach <cwsteinb...@gmail.com>
Subject Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Date Fri, 17 Jan 2014 08:11:11 GMT
Will do.

Thanks.

Carl


On Wed, Jan 15, 2014 at 3:33 PM, Thejas Nair <thejas@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
> <leftyleverenz@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 <thejas@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 <vikram@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 <thejas@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
> >> >> <sergey@hortonworks.com> wrote:
> >> >> > I actually have a patch out on a jira that says it will be
> committed
> >> in
> >> >> 24
> >> >> > hours from long ago ;)
> >> >> >
> >> >> > Is 24h rule is needed at all? In other projects, I've seen patches
> >> simply
> >> >> > reverted by author (or someone else). It's a rare occurrence,
and
> it
> >> >> should
> >> >> > be possible to revert a patch if someone -1s it after commit,
esp.
> >> within
> >> >> > the same 24 hours when not many other changes are in.
> >> >> >
> >> >> >
> >> >> > On Fri, Dec 27, 2013 at 1:03 PM, Thejas Nair <
> thejas@hortonworks.com>
> >> >> wrote:
> >> >> >>
> >> >> >> I agree with Ashutosh that the 24 hour waiting period after
+1 is
> >> >> >> cumbersome, I have also forgotten to commit patches after
+1,
> >> >> >> resulting in patches going stale.
> >> >> >>
> >> >> >> But I think 24 hours wait between creation of jira and patch
> commit
> >> is
> >> >> >> not very useful, as the thing to be examined is the patch
and not
> the
> >> >> >> jira summary/description.
> >> >> >> I think having a waiting period of 24 hours between a jira
being
> made
> >> >> >> 'patch available' and committing is better and sufficient.
> >> >> >>
> >> >> >>
> >> >> >> On Fri, Dec 27, 2013 at 11:44 AM, Ashutosh Chauhan <
> >> >> hashutosh@apache.org>
> >> >> >> wrote:
> >> >> >> > Proposed changes look good to me, both suggested by Carl
and
> >> Thejas.
> >> >> >> > Another one I would like to add for consideration is:
24 hour
> rule
> >> >> >> > between
> >> >> >> > +1 and commit. Since this exists only in Hive (no other
apache
> >> project
> >> >> >> > which I am aware of) this surprises new contributors.
More
> >> >> importantly,
> >> >> >> > I
> >> >> >> > have seen multiple cases where patch didn't get committed
> because
> >> >> >> > committer
> >> >> >> > after +1 forgot to commit after 24 hours have passed.
I propose
> to
> >> >> >> > modify
> >> >> >> > that one such that there must be 24 hour duration between
> creation
> >> of
> >> >> >> > jira
> >> >> >> > and patch commit, that will ensure that there is sufficient
time
> >> for
> >> >> >> > folks
> >> >> >> > to see changes which are happening on trunk.
> >> >> >> >
> >> >> >> > Thanks,
> >> >> >> > Ashutosh
> >> >> >> >
> >> >> >> >
> >> >> >> > On Fri, Dec 27, 2013 at 9:33 AM, Thejas Nair <
> >> thejas@hortonworks.com>
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> >> The changes look good to me.
> >> >> >> >> Only concern I have is with the 7 days for release
candidate
> >> voting.
> >> >> >> >> Based on my experience with releases, it often takes
few
> cycles to
> >> >> get
> >> >> >> >> the candidate out, and people tend to vote closer
to the end of
> >> the
> >> >> >> >> voting period. This can mean that it takes several
weeks to
> get a
> >> >> >> >> release out. But this will not be so much of a problem
as long
> as
> >> >> >> >> people don't wait for end of the voting period to
vote, or if
> they
> >> >> >> >> look at the candidate branch even before the release
candidate
> is
> >> >> out.
> >> >> >> >>
> >> >> >> >> Should we also include a provision for branch merges
? I think
> we
> >> >> >> >> should have a longer voting period for branch merges
(3 days
> >> instead
> >> >> >> >> of 1?) and require 3 +1s (this part is also in the
hadoop
> by-law
> >> ) .
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Thu, Dec 26, 2013 at 7:08 PM, Carl Steinbach <
> cws@apache.org>
> >> >> wrote:
> >> >> >> >> > I think we should make several changes to the
Apache Hive
> >> Project
> >> >> >> >> > Bylaws.
> >> >> >> >> > The proposed changes are available for review
here:
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=38568856
> >> >> >> >> >
> >> >> >> >> > Most of the changes were directly inspired by
provisions
> found
> >> in
> >> >> the
> >> >> >> >> Apache
> >> >> >> >> > Hadoop Project Bylaws.
> >> >> >> >> >
> >> >> >> >> > Summary of proposed changes:
> >> >> >> >> >
> >> >> >> >> > * Add provisions for branch committers and speculative
> branches.
> >> >> >> >> >
> >> >> >> >> > * Define the responsibilities of a release manager.
> >> >> >> >> >
> >> >> >> >> > * PMC Chairs serve for one year and are elected
by the PMC
> using
> >> >> >> >> > Single
> >> >> >> >> > Transferable Vote (STV) voting.
> >> >> >> >> >
> >> >> >> >> > * With the exception of code change votes, the
minimum
> length of
> >> >> all
> >> >> >> >> voting
> >> >> >> >> > periods is extended to seven days.
> >> >> >> >> >
> >> >> >> >> > Thanks.
> >> >> >> >> >
> >> >> >> >> > Carl
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> CONFIDENTIALITY NOTICE
> >> >> >> >> NOTICE: This message is intended for the use of the
individual
> or
> >> >> >> >> entity to
> >> >> >> >> which it is addressed and may contain information
that is
> >> >> confidential,
> >> >> >> >> privileged and exempt from disclosure under applicable
law. If
> the
> >> >> >> >> reader
> >> >> >> >> of this message is not the intended recipient, you
are hereby
> >> >> notified
> >> >> >> >> that
> >> >> >> >> any printing, copying, dissemination, distribution,
disclosure
> or
> >> >> >> >> forwarding of this communication is strictly prohibited.
If you
> >> have
> >> >> >> >> received this communication in error, please contact
the sender
> >> >> >> >> immediately
> >> >> >> >> and delete it from your system. Thank You.
> >> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> CONFIDENTIALITY NOTICE
> >> >> >> NOTICE: This message is intended for the use of the individual
or
> >> entity
> >> >> >> to
> >> >> >> which it is addressed and may contain information that is
> >> confidential,
> >> >> >> privileged and exempt from disclosure under applicable law.
If the
> >> >> reader
> >> >> >> of this message is not the intended recipient, you are hereby
> >> notified
> >> >> >> that
> >> >> >> any printing, copying, dissemination, distribution, disclosure
or
> >> >> >> forwarding of this communication is strictly prohibited. If
you
> have
> >> >> >> received this communication in error, please contact the sender
> >> >> >> immediately
> >> >> >> and delete it from your system. Thank You.
> >> >> >
> >> >> >
> >> >> >
> >> >> > CONFIDENTIALITY NOTICE
> >> >> > NOTICE: This message is intended for the use of the individual
or
> >> entity
> >> >> to
> >> >> > which it is addressed and may contain information that is
> >> confidential,
> >> >> > privileged and exempt from disclosure under applicable law. If
the
> >> >> reader of
> >> >> > this message is not the intended recipient, you are hereby notified
> >> that
> >> >> any
> >> >> > printing, copying, dissemination, distribution, disclosure or
> >> forwarding
> >> >> of
> >> >> > this communication is strictly prohibited. If you have received
> this
> >> >> > communication in error, please contact the sender immediately
and
> >> delete
> >> >> it
> >> >> > from your system. Thank You.
> >> >>
> >> >> --
> >> >> 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.
>

Mime
View raw message