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
Are there any other things we should do today prior to merging?
Can we get the user documentation done soon (HDFS-5386)? I've given a
round of feedback. If it helps, I can volunteer to upload a new patch that
incorporates my feedback.
Chris Nauroth
Hortonworks
http://hortonworks.com/
On
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
On Thu, Oct 24, 2013 at 6:18 AM, Andrew Wang andrew.w...@cloudera.comwrote:
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
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
On Thu, Oct 24, 2013 at 1:45 PM, Chris Nauroth cnaur...@hortonworks.com 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
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
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
I agree that the code has reached a stable point. Colin and Andrew, thank
you for your contributions and collaboration.
Throughout development, I've watched the feature grow by running daily
builds in a pseudo-distributed deployment. As of this week, the full
feature set is working end-to-end.
Hi Chris,
I think it's feasible to complete those tasks in the next 7 days.
Andrew is on HDFS-5386.
The test plan document is a great idea. We'll try to get that up
early next week. We have a lot of unit tests now, clearly, but some
manual testing is important too.
If we discover any issues
+1
Sounds great!
Regarding testing caching+federation, this is another thing that I had
intended to pick up as part of HDFS-5149. I'm not sure if I can get this
done in the next 7 days, so I'll keep you posted.
Chris Nauroth
Hortonworks
http://hortonworks.com/
On Fri, Oct 18, 2013 at 11:15
Hello all,
I'd like to call a vote to merge the HDFS-4949 branch (in-memory caching)
to trunk. Colin McCabe and I have been hard at work the last 3.5 months
implementing this feature, and feel that it's reached a level of stability
and utility where it's ready for broader testing and integration.
+1. Thanks, guys.
best,
Colin
On Thu, Oct 17, 2013 at 3:01 PM, Andrew Wang andrew.w...@cloudera.com wrote:
Hello all,
I'd like to call a vote to merge the HDFS-4949 branch (in-memory caching)
to trunk. Colin McCabe and I have been hard at work the last 3.5 months
implementing this feature,
13 matches
Mail list logo
