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

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

Copy link to this message
Re: [VOTE] Merge HDFS-4949 to trunk
On Fri, Oct 25, 2013 at 10:07 AM, Suresh Srinivas
> I posted a comment in the other thread about feature branch merges.
> My preference is to make sure the requirements we have for regular patches
> be applied to feature branch patch as well (3 +1s is the only exception).
> Also
> adding details about what functionality is missing (I posted a comment on
> HDFS-4949)
> and the changes that deferred that will be done post merge to trunk would
> be good.
> It would be better to start the merge vote  when the work is ready instead
> of
> trying to optimize 1 week by doing the required work for merging in
> parallel with
> the vote.


> If all the requirements for merging have been met, I am +1 on the merge,
> without
> the need for restarting the vote.

I think the requirements are all in place right now.  I'll create a
JIRA detailing the post-merge subtasks just to make it clearer what
the plan is from here.

If there are no more comments, I'll commit later tonight.

I wouldn't mind waiting a week if there was a feature someone
absolutely felt we needed pre-merge, but I also feel like it would be
two weeks, due to Hadoop Summit next week.

> On Thu, Oct 24, 2013 at 11:29 PM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:
>> 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