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

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

Colin McCabe 2013-10-25, 23:01
Copy link to this message
Re: [VOTE] Merge HDFS-4949 to trunk
With 3 +1s, the vote passes.  Thanks, all.


On Fri, Oct 25, 2013 at 4:01 PM, Colin McCabe <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 25, 2013 at 10:07 AM, Suresh Srinivas
> <[EMAIL PROTECTED]> wrote:
>> 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.
> OK.
>> 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.
> best,
> Colin
>> 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