For more details, see
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/59/
[Jun 10, 2016 10:15:36 AM] (aajisaka) MAPREDUCE-6741. Refactor
UncompressedSplitLineReader.fillBuffer().
[Jun 10, 2016 4:02:28 PM] (aw) HDFS-7987. Allow files / directories to be moved
(Ravi Prakash via aw)
I would like to understand the trunk-incompat part of the proposal a little
better.
Is trunk-incompat always going to be a superset of trunk? If yes, is it
just a change in naming convention with a hope that our approach to trunk
stability changes as Sangjin mentioned?
Or, is it okay for trunk-in
Xiao Chen created HADOOP-13258:
--
Summary: Fix trailing whitespace in LICENSE.txt for pre-commit.
Key: HADOOP-13258
URL: https://issues.apache.org/jira/browse/HADOOP-13258
Project: Hadoop Common
Let me try to clarify a few points, since not everyone might have been
present for the previous emails.
On the "Looking to a Hadoop 3 release" thread, we already reached consensus
on doing releases from trunk. People didn't want to have to commit to
another branch, and wanted to try releasing from
Thanks for your thoughts Anu.
Regarding your question
> And then comes the question, once 3.0 becomes official, where do we
> check-in a change, if that would break something? so this will lead us
> back to trunk being the unstable – 3.0 being the new “branch-2”.
Andrew mentioned in the origin
I actively work on two branches (Diskbalancer and ozone) and I agree with most
of what Sangjin said.
There is an overhead in working with branches, there are both technical costs
and administrative issues
which discourages developers from using branches.
I think the biggest issue with branch b
Chris Nauroth created HADOOP-13257:
--
Summary: Improve Azure Data Lake contract tests.
Key: HADOOP-13257
URL: https://issues.apache.org/jira/browse/HADOOP-13257
Project: Hadoop Common
Issue T
Interestingly, that FindBugs warning in hadoop-azure-datalake was not
flagged during pre-commit before I committed HADOOP-12666. I'm going to
propose that we address it in scope of HADOOP-12875.
--Chris Nauroth
On 6/10/16, 10:30 AM, "Apache Jenkins Server"
wrote:
>For more details, see
>htt
Hi Folks
Could anyone review HADOOP-12687 ? Basically patch is going to break RFC
1535.
Does Hadoop meet mandatory RFC standards? It would be greatly appreciated
if folks express your opinion and helping in for getting consensus.
Thanks & Regards
Rohith Sharma K S
Having worked on a major feature in a feature branch, I have some thoughts
and observations on feature branch development.
IMO feature branch development v. direct commits to trunk in piecemeal is
really a choice of *granularity*. Do we want a series of fine-grained state
changes on trunk or fewer
[
https://issues.apache.org/jira/browse/HADOOP-13249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jing Zhao resolved HADOOP-13249.
Resolution: Fixed
Fix Version/s: 2.9.0
Thanks for the contribution, Zhihai! I've committed
For more details, see
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/58/
No changes
-1 overall
The following subsystems voted -1:
findbugs unit
The following subsystems voted -1 but
were configured to be filtered/ignored:
cc checkstyle javac javadoc pylint shellche
Thanks for the notes Andrew, Junping, Karthik.
Here are some of my understandings:
- Trunk is the "latest and greatest" of Hadoop. If a user starts using
Hadoop today, without legacy workloads, trunk is what he/she should use.
- Therefore, each commit to trunk should be transactional -- atomic,
c
Steve Loughran created HADOOP-13256:
---
Summary: define FileSystem.listStatusIterator, implement contract
tsets
Key: HADOOP-13256
URL: https://issues.apache.org/jira/browse/HADOOP-13256
Project: Hadoo
Inline.
On Fri, Jun 10, 2016 at 6:56 AM, Junping Du wrote:
> Comparing with advantages, I believe the disadvantages of shipping any
> releases directly from trunk are more obvious and significant:
> - A lot of commits (incompatible, risky, uncompleted feature, etc.) have
> to wait to commit to t
Comparing with advantages, I believe the disadvantages of shipping any releases
directly from trunk are more obvious and significant:
- A lot of commits (incompatible, risky, uncompleted feature, etc.) have to
wait to commit to trunk or put into a separated branch that could delay feature
develo
For more details, see
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/57/
[Jun 9, 2016 4:28:49 PM] (stevel) HADOOP-13237: s3a initialization against
public bucket fails if caller
[Jun 9, 2016 7:30:58 PM] (vinodkv) YARN-5191. Renamed the newly added
âdownload=trueâ option for
17 matches
Mail list logo
