Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hive >> mail # user >> [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws


Copy link to this message
-
Re: [DISCUSS] Proposed Changes to the Apache Hive Project Bylaws
>  ... 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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
> > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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 <
> [EMAIL PROTECTED]>
> >>> 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
> >>> >
> >>> >
> >>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB