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
On Thu, Oct 24, 2013 at 3:46 PM, Doug Cutting cutt...@apache.org wrote:
Here's my take, FWIW. The entire project needs to determine whether
it is willing to take on the maintenance of code developed in a
branch. This vote needs the widest audience. On the other hand,
discussion on the
See https://builds.apache.org/job/Hadoop-Common-trunk/932/changes
Changes:
[brandonli] HDFS-5171. NFS should create input stream for a file and try to
share it with multiple read requests. Contributed by Haohui Mai
[sandy] YARN-1335. Move duplicate code from FSSchedulerApp and FiCaSchedulerApp
Vinay created HADOOP-10071:
--
Summary: under construction files deletion after
snapshot+checkpoint+nn restart leads nn safemode
Key: HADOOP-10071
URL: https://issues.apache.org/jira/browse/HADOOP-10071
I agree with what Nicholas is saying.
Feature branch merge votes are similar to traditional review-commit process.
That means the code should be ready, and pass the Jenkins build tests.
Also similar to regular patches where one describes what changes the
patch brings, having an updated design
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 Fri, Oct 25, 2013 at 9:35 AM, Suresh Srinivas sur...@hortonworks.com wrote:
Granted some of the feature readiness activity can be done during voting.
But I fail to understand why expediting a feature that takes months to build
should try to optimize a week. Why not finish the requirements we
It seems that overall the branch-merge voting threads are overloaded with
multiple goals.
Like other things that we vote on, a DISCUSS/PROPOSAL thread upfront for the
branch-merge should alleviate any concerns that any committer might have. Once
that is done, [VOTE] thread can simply be a
On Fri, Oct 25, 2013 at 10:56 AM, Vinod Kumar Vavilapalli
vino...@apache.org wrote:
Discussing on a voting thread is not productive.
When all votes are +1 then no discussion is needed. One shouldn't
call a vote unless one expects all votes to be +1. But, if
unexpectedly they're not all +1,
Chris Nauroth created HADOOP-10072:
--
Summary: TestNfsExports#testMultiMatchers fails due to
non-deterministic timing around cache expiry check.
Key: HADOOP-10072
URL:
11 matches
Mail list logo
