Thanks for the verification Nick!
Regarding that one issue, we saw this before itself in 2.7 and deemed it to be
a compatible change given the expected usage of the API. The error in your
report is “a client class C is not abstract and does not override abstract
method in ApplicationBaseProtoco
Hi folks,
I ran a modified version [0] of the compatibility checking tool we use in
HBase over this release. There's one source-related issue [1] in YARN API
that may need to be addressed in the next candidate. Otherwise, it's
looking pretty clean for a patch release. Nice job!
[0]: http://people
One more popped in from Jeff Zhang from Apache Tez: YARN-4154.
Looking at that too for RC1.
Thanks
+Vinod
> On Sep 11, 2015, at 11:37 AM, Vinod Kumar Vavilapalli
> wrote:
>
> Thanks Sangjin and Akira for finding the bug and the fix!
>
> This fix is needed because YARN-1809 was pulled in. I
Thanks Sangjin and Akira for finding the bug and the fix!
This fix is needed because YARN-1809 was pulled in. I further found 3 more
related fixes that need to be pulled in because of YARN-1809: YARN-1884 and
YARN-3544 (UI fixes), YARN-3740 (to avoid incompat).
This VOTE thread is closed now, I
I could reproduce the issue, and I found YARN-3171 will fix it.
Hi Vinod, would you include YARN-3171?
I applied the patch to branch-2.6.1 locally and confirmed the issue was
fixed.
Regards,
Akira
On 9/11/15 09:16, Sangjin Lee wrote:
I verified the signatures for both source and the binary t
I pointed master branch of hbase to 2.6.1 RC0.
Ran unit test suite and results are good.
Cheers
On Thu, Sep 10, 2015 at 5:16 PM, Sangjin Lee wrote:
> I verified the signatures for both source and the binary tarballs. I
> started up a pseudo-distributed cluster, and tested simple apps such as
>
I verified the signatures for both source and the binary tarballs. I
started up a pseudo-distributed cluster, and tested simple apps such as
sleep and terasort.
I do see one issue with the RM UI where the sorting by id is broken. The
table is not rendered in the expected id-descending order, and w
I’ve finished this one too. Trunk, branch-2, branch-2.7 and branch-2.6 reflect
the backports. I haven’t touched the point branches like 2.7.1.
Thanks
+Vinod
On Sep 10, 2015, at 10:48 AM, Vinod Kumar Vavilapalli
mailto:vino...@hortonworks.com>> wrote:
Updating CHANGES.txt entries to reflect th
I have just finished this.
Thanks
+Vinod
On Sep 10, 2015, at 10:48 AM, Vinod Kumar Vavilapalli
mailto:vino...@hortonworks.com>> wrote:
- Patches that got into 2.6.1 all the way from 2.8 are NOT in 2.7.2 yet,
this will be done as a followup.
When I meant rebase, I meant “start with 2.6.1 + add patches that are already
in branch-2.6”.
The other way around “apply all 2.6.1 patches on today’s 2.6” is very hard for
me. I just came out of a very long process of 153 cherry-pick+merges+test,
cannot do that again.
Thanks
+Vinod
> On Sep
On Sep 9, 2015, at 6:00 PM, Vinod Kumar Vavilapalli wrote:
> - Note that branch-2.6 which will be the base for 2.6.2 doesn't have these
> fixes yet. Once 2.6.1 goes through, I plan to rebase branch-2.6 based off
> 2.6.1.
Isn’t there a risk that there are things in branch-2.6 that aren’t
Forking thread for these follow up activities.
One more thing to do - Updating CHANGES.txt entries to reflect the patch-move
up to 2.6.1
Thanks
+Vinod
On Sep 9, 2015, at 6:00 PM, Vinod Kumar Vavilapalli
mailto:vino...@apache.org>> wrote:
- Note that branch-2.6 which will be the base for 2.6.
Hi all,
After a nearly month long [1] toil, with loads of help from Sangjin Lee and
Akira Ajisaka, and 153 commits later, I've created a release candidate RC0
for hadoop-2.6.1.
The RC is available at: http://people.apache.org/~vinodkv/hadoop-2.6.1-RC0/
The RC tag in git is: release-2.6.1-RC0
T
13 matches
Mail list logo
