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 Thu, 09 Jan 2014 11:39:45 GMT
>  ... 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 <thejas@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 <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.
>

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