Allen Wittenauer created HADOOP-12113:
-
Summary: update test-patch branch to latest code
Key: HADOOP-12113
URL: https://issues.apache.org/jira/browse/HADOOP-12113
Project: Hadoop Common
Alan Burlison created HADOOP-12112:
--
Summary: Make hadoop-common-project Native code -Wall-clean
Key: HADOOP-12112
URL: https://issues.apache.org/jira/browse/HADOOP-12112
Project: Hadoop Common
Alan Burlison created HADOOP-12114:
--
Summary: Make hadoop-tools/hadoop-pipes Native code -Wall-clean
Key: HADOOP-12114
URL: https://issues.apache.org/jira/browse/HADOOP-12114
Project: Hadoop Common
Thanks Tsuyoshi for the comment.
Targeting to 2.7 looks good to me, however, I'd like to maintenance
branch-2.6 also. It's only about a half year since 2.6.0 was released.
I don't want to abandon relatively new branches.
On 6/23/15 16:05, Tsuyoshi Ozawa wrote:
Thank you for clarification,
There's no reason we have to choose 2.6 xor 2.7. If we have willing RMs and
enough PMCs who will vote on releases, there's no reason we can't maintain
both.
However, based on the discussion at Hadoop Summit with Yahoo and Twitter,
their interest is primarily in 2.6, and Daryn mentioned the need
On Tue, Jun 23, 2015 at 10:30 AM, Andrew Wang andrew.w...@cloudera.com
wrote:
There's no reason we have to choose 2.6 xor 2.7. If we have willing RMs and
enough PMCs who will vote on releases, there's no reason we can't maintain
both.
However, based on the discussion at Hadoop Summit with
I'm trying to test stuff prior to submission, following the instructions
at http://wiki.apache.org/hadoop/HowToContribute and even when using an
unmodified git clone from the repo on a LLinux machine I've failed to
get a clean test run. Normally I end up with a timeout error somewhere
in
On Jun 23, 2015, at 1:32 PM, Alan Burlison alan.burli...@oracle.com wrote:
I'm trying to test stuff prior to submission, following the instructions at
http://wiki.apache.org/hadoop/HowToContribute and even when using an
unmodified git clone from the repo on a LLinux machine I've failed to
So, as far as I can see, Hadoop has the main developer area for core Hadoop
code, unit tests in the test directories, user scripts (like
hadoop/mapred/yarn), and build scripts.
I've got some utilities that are really for Hadoop contributors. These
serve two purposes:
1. These are just
Could they go under dev-support?
On Tue, Jun 23, 2015 at 4:29 PM, Ray Chiang rchi...@cloudera.com wrote:
So, as far as I can see, Hadoop has the main developer area for core Hadoop
code, unit tests in the test directories, user scripts (like
hadoop/mapred/yarn), and build scripts.
I've got
On Tue, Jun 23, 2015 at 12:30 PM, Andrew Wang andrew.w...@cloudera.com
wrote:
There's no reason we have to choose 2.6 xor 2.7. If we have willing RMs and
enough PMCs who will vote on releases, there's no reason we can't maintain
both.
However, based on the discussion at Hadoop Summit with
On 24/06/2015 04:22, Sean Busbey wrote:
Probably not (barring maven attempting to grab SNAPSHOT versions of other
modules while building).
What are the machine specs like? the complete unit test set requires a fair
bit of machine power (i.e. more than my laptop can handle).
The Linux machine
Thank you for clarification, Karthik.
I'd also like to work on stable release management with community.
I'm thinking of speedy release against next version - 1 branch for
making community feedback faster (e.g. current next version is 2.8, so
cherry-picking to 2.7 and releasing it are useful
Thanks Allen for reminding me of supporting JDK6. If 2.6 is the target,
any commmiter needs to check a bug fix patch when cherry-picking it.
For trunk, I'm thinking we need to decide what we should do for release
3.x, in another thread. I'm okay to discuss it again.
On 6/23/15 01:19, Allen
Thanks Karthik for the comment.
I'm +1 for your approach to ensure stability.
On 6/22/15 23:50, Karthik Kambatla wrote:
Thanks for starting this thread, Akira.
+1 to more maintenance releases. More stable upstream releases avoids
duplicating cherry-pick work across consumers/vendors, and shows
Yea, throw them under dev-support. It'd be good to link them up on the wiki
or website too so they're more findable.
Related, we could also use a README in dev-support as an overview of what
everything does.
On Tue, Jun 23, 2015 at 8:19 PM, Sean Busbey bus...@cloudera.com wrote:
Could they go
Also if they are general Hadoop big data examples were happy to carry them in
bigtop as well ... Especially if they touch multiple areas of the Hadoop
ecosystem
On Jun 23, 2015, at 11:56 PM, Andrew Wang andrew.w...@cloudera.com wrote:
Yea, throw them under dev-support. It'd be good to link
17 matches
Mail list logo
