Ray Chiang created MAPREDUCE-6340:
-
Summary: Remove .xml and documentation references to
dfs.webhdfs.enabled
Key: MAPREDUCE-6340
URL: https://issues.apache.org/jira/browse/MAPREDUCE-6340
Project:
Hao Xia created MAPREDUCE-6343:
--
Summary: JobConf.parseMaximumHeapSizeMB() fails to parse value
greater than 2GB expressed in bytes
Key: MAPREDUCE-6343
URL: https://issues.apache.org/jira/browse/MAPREDUCE-6343
See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/2126/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 31993 lines...]
Results :
Tests in error:
See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/177/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 26974 lines...]
Tests run: 3, Failures: 0,
I think Karthik correctly identified the two reasons we might want to
denote a release as unstable:
a) Compatibility. Whether we have freedom to break compatibility before the
final release, i.e. what alpha typically means.
b) Quality. As Konst says, a release can be allowed to break
Rohith created MAPREDUCE-6342:
-
Summary: Make POM project names consistent
Key: MAPREDUCE-6342
URL: https://issues.apache.org/jira/browse/MAPREDUCE-6342
Project: Hadoop Map/Reduce
Issue Type:
My understanding was that the main reason that we labeled 2.0 alpha and 2.1
beta is that we wanted flexibility to make breaking API changes.
Is that the case now with 2.7? I.e. do we have APIs labeled as Public /
Stable that we want freedom to change in 2.8? If not, I definitely don't
think the
There were several requests on the user lists [1] for a 2.6.1 release. I
got many offline comments too.
Planning to do a 2.6.1 release in a few weeks time. We already have a bunch
of tickets committed to 2.7.1. I created a filter [2] to tracking pending
tickets.
We need to collectively come up
