For more details, see
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/113/
No changes
-1 overall
The following subsystems voted -1:
asflicense unit
The following subsystems voted -1 but
were configured to be filtered/ignored:
cc checkstyle javac javadoc pylint shell
If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
tomorrow in case there's more discussion. If any one is willing to help
review my script and JIRA queries, that'd also be great.
I can also do the 2.
+1 (binding)
* Downloaded and build from source
* Checked LICENSE and NOTICE
* Pseudo-distributed cluster with FairScheduler
* Ran MR and HDFS tests
* Verified basic UI
On Sun, Jul 24, 2016 at 1:07 PM, larry mccay wrote:
> +1 binding
>
> * downloaded and built from source
> * checked LICENSE an
I got asked this off-list, so as a reminder, only PMC votes are binding on
releases. Everyone is encouraged to vote on releases though!
+1 (binding)
* Downloaded source, built
* Started up HDFS and YARN
* Ran Pi job which as usual returned 4, and a little teragen
On Mon, Jul 25, 2016 at 11:08 AM
I'll also add that, as a YARN newbie, I did hit two usability issues. These
are very unlikely to be regressions, and I can file JIRAs if they seem
fixable.
* I didn't have SSH to localhost set up (new laptop), and when I tried to
run the Pi job, it'd exit my window manager session. I feel there mu
+1 (non-binding)
- Downloaded the binary tarball
- Verified checksum
- Verified all jars have LICENSE and NOTICE (using the script
in HADOOP-13374)
- Started Pseudo-distributed cluster and verified basic HDFS operations
work, example Pi job succeed.
- Started kms with a sample
Oops - make that:
+1 (non-binding)
On Sun, Jul 24, 2016 at 4:07 PM, larry mccay wrote:
> +1 binding
>
> * downloaded and built from source
> * checked LICENSE and NOTICE files
> * verified signatures
> * ran standalone tests
> * installed pseudo-distributed instance on my mac
> * ran through H
On Fri, Jul 22, 2016 at 5:15 PM, Allen Wittenauer
wrote:
>
> But if I don't use ApplicationClassLoader, my java app is basically
> screwed then, right?
>
If we start upgrading the libraries aggressively, then it would also mean
that the ApplicationClassLoader should be more of the default than t
> On Jul 25, 2016, at 1:16 PM, Sangjin Lee wrote:
>
> Also: right now, the non-Linux and/or non-x86 platforms have to supply their
> own leveldbjni jar (or at least the C level library?) in order to make YARN
> even functional. How is that going to work with the class path manipulation?
>
>
Actually, I wouldn’t trust this report as it stands today at all.
I quickly glanced the report, looking for what it highlights as incompatible.
But the ones that I saw have private / visible for testing annotations. Other
than acting as useless evidence for those lashing out on branch-2, this wo
Thanks Vinod.
+1 (Binding)
- Built from source and deploy a pseudo cluster locally
- Run DS on YARN
- With/Without node labels enabled.
- Wangda
On Mon, Jul 25, 2016 at 1:55 PM, Mingliang Liu wrote:
> Thanks Vinod.
>
> +1 (non-binding)
>
> * Downloaded and built from source (with Java 8)
> *
>> There's a plan for more 3.0.0 alphas, so there's still time to help out
> before things settle down for beta. If 2.8.0 is ready to go, it should
> happen before even alpha2.
I wasn’t talk about my irresistible urge to help (which of course is there : ))
, it was about making sure enough eye-ba
Please don’t do this for 2.8.0 against 2.7.0 till we change our existing
release ordering conventions.
Till now, I made sure 2.8.0 only has issues that are not in 2.7.3 - per the
2.8.0-follows-2.7.3 convention. As part of the release process, I will fix the
remaining tickets to follow this same
Thanks for all that great help moving this release forward, Jian, Sangjin,
Wangda et al! Appreciate it.
The License / Notice fix is finally in. And I pushed out a 2.7.3 RC0 last week.
I only see 9 blocker / critical fixes pending for 2.8.0 -
https://issues.apache.org/jira/issues/?filter=1233498
+1 (binding)
- Verified signatures and digests- Built from source with native support-
Deployed a pseudo-distributed cluster- Ran some sample jobs
Jason
From: Vinod Kumar Vavilapalli
To: "common-...@hadoop.apache.org" ;
hdfs-...@hadoop.apache.org; yarn-...@hadoop.apache.org;
"mapreduce-
I agree with what Vinod mentioned: we need to revisit all incompatible
changes and revert unnecessary ones. Even if we don't have any
compatibility guarantees between 2.x and 3.x. But make user to be less
frustrated while trying 3.x is always a better option to me.
To achieve this we need to run j
I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to
track running JDIFF on trunk and analyze results for Hadoop-common. I will
work on that and keep the JIRA and this thread updated. We need to do the
same work for YARN/MR/HDFS.
On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan wr
Hi Andrew,
Please wait updating fix version for branch-2 committed tickets before we
get a consensus on this. Updating fix versions for them could bring lots of
troubles for on going two releases (2.7.3 / 2.8.0).
Thanks,
Wangda
On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang
wrote:
> If I don't h
Thanks Vinod+Wangda for the comments,
Above, Allen and I discussed a proposal which I think is reasonable and
also lines up well with our current approach. If you feel something is
underspecified or needs improvement, please raise those points.
We have been doing concurrent releases with the 2.6.
Thanks Vinod.
+1 (non-binding)
* Downloaded and built from source
* Checked LICENSE and NOTICE
* Deployed a pseudo cluster
* Ran through MR and HDFS tests
* verified basic HDFS operations and Pi job.
Zhihai
On Fri, Jul 22, 2016 at 7:15 PM, Vinod Kumar Vavilapalli wrote:
> Hi all,
>
> I've cre
20 matches
Mail list logo
