Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> [VOTE] Merge HDFS-4949 to trunk


Copy link to this message
-
Re: [VOTE] Merge HDFS-4949 to trunk
I don't necessarily disagree with the general questions about the
procedural issues of merge votes. Thanks for bringing that up in the other
thread you mentioned. To some extent it seems like much of this has been
based on custom, and if folks feel that more precisely defining the merge
vote process is warranted, then I think we should take that up over on that
thread.

With regard to this particular merge vote, I've spoken with Chris offline
about his feelings on this. He said that he is not dead-set on restarting
the vote, though he suspects that others may be. It seems to me the
remaining unfinished asks (e.g. updating the design doc) can reasonably be
done either after this vote but before the merge to trunk proper, or could
even reasonably be done after merging to trunk.

Given that, I'll lend my +1 to this merge. I've been reviewing the branch
pretty consistently since work started on it, and have personally
run/tested several builds of it along the way. I've also reviewed the
design thoroughly. The implementation, overall design, and API seem to me
plenty stable enough to be merged into trunk. I know that there remains a
handful of javac warnings in the branch that aren't in trunk, but I trust
those will be taken care of before the merge.

If anyone out there does feel strongly that this merge vote should be
restarted, then please speak up soon. Again, we can restart the vote if
need be, but I honestly think we'll gain very little by doing so.

Best,
Aaron
On Fri, Oct 25, 2013 at 5:45 AM, Chris Nauroth <[EMAIL PROTECTED]>wrote:

> Hi Andrew,
>
> I've come to the conclusion that I'm very confused about merge votes.  :-)
>  It's not just about HDFS-4949.  I'm confused about all merge votes.
>  Rather than muddy the waters here, I've started a separate discussion on
> common-dev.
>
> I do agree with the general plan outlined here, and I will comment directly
> on the HDFS-4949 jira with a binding +1 when I see that we've completed
> that plan.
>
> Chris Nauroth
> Hortonworks
> http://hortonworks.com/
>
>
>
> On Wed, Oct 23, 2013 at 2:18 PM, Andrew Wang <[EMAIL PROTECTED]
> >wrote:
>
> > Hey Chris,
> >
> > Right now we're on track to have all of those things done by tomorrow.
> > Since the remaining issues are either not technical or do not involve
> major
> > changes, I was hoping we could +1 this merge vote in the spirit of "+1
> > pending jenkins". We've gotten clean unit test runs on upstream Jenkins
> as
> > well, so the only fixups we should need for test-patch.sh are findbugs
> and
> > javac (which are normally pretty trivial to clean up). Of course, all of
> > your listed prereqs and test-patch would be taken care of before actually
> > merging to trunk.
> >
> > So, we can reset the vote if you feel strongly about this, but it seems
> > like the only real result will be delaying the merge by a week.
> >
> > Thanks,
> > Andrew
> >
> >
> > On Wed, Oct 23, 2013 at 1:03 PM, Chris Nauroth <[EMAIL PROTECTED]
> > >wrote:
> >
> > > I've received some feedback that we haven't handled this merge vote the
> > > same as other comparable merge votes, and that the vote should be reset
> > > because of this.
> > >
> > > The recent custom is that we only call for the merge vote after all
> > > pre-requisites have been satisfied.  This would include committing to
> the
> > > feature branch all patches that the devs deem necessary before the code
> > > lands in trunk, posting a test plan, posting an updated design doc in
> > case
> > > implementation choices diverged from the original design doc, and
> > getting a
> > > good test-patch run from Jenkins on the merge patch.  This was the
> > process
> > > followed for other recent major features like HDFS-2802 (snapshots),
> > > HDFS-347 (short-circuit reads via sharing file descriptors), and
> > > HADOOP-8562 (Windows compatibility).  In this thread, we've diverged
> from
> > > that process by calling for a vote on a branch that hasn't yet
> completed
> > > the pre-requisites and stating a plan for work to be done before the