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).
>> adding details about what functionality is missing (I posted a comment on
>> 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
>> 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,
>> 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
>>> 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.
>>> On Fri, Oct 25, 2013 at 5:45 AM, Chris Nauroth <[EMAIL PROTECTED]
>>> > 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
>>> > 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