hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lefty Leverenz <leftylever...@gmail.com>
Subject Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
Date Wed, 15 Jan 2014 07:05:30 GMT
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.
>

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