-1 for rc1
I downloaded and ran the test target 3 times.
First run failed because my umask is defaulted to 0002, which is a known
problem HADOOP-5050 committed to 0.21 but not 0.20.
Set umask to 0022 and re-ran test twice. Both resulted in failure. Here is
the list of failed tests:
[junit] Te
atches we have applied to our internal branch
and follow the recommended process for these to suggest them for the 203
release.
Thanks,
Joep
-Original Message-
From: Nigel Daley [mailto:nda...@mac.com]
Sent: Tuesday, May 03, 2011 2:17 PM
To: common-dev@hadoop.apache.org
Subject: Re:
On May 3, 2011, at 1:48 PM, Owen O'Malley wrote:
>
> On May 3, 2011, at 1:33 PM, Nigel Daley wrote:
>
>> Owen, any reason you're not building the eclipse plugin for this release?
>> Instructions are here: http://wiki.apache.org/hadoop/HowToRelease
>
> Of course, I know (and have updated) the
On May 3, 2011, at 1:33 PM, Nigel Daley wrote:
> Owen, any reason you're not building the eclipse plugin for this release?
> Instructions are here: http://wiki.apache.org/hadoop/HowToRelease
Of course, I know (and have updated) the HowToRelease page. It looks like the
eclipse-plugin was drop
Owen, any reason you're not building the eclipse plugin for this release?
Instructions are here: http://wiki.apache.org/hadoop/HowToRelease
n.
On Apr 29, 2011, at 4:09 PM, Owen O'Malley wrote:
> I think everything is ready to go on the 0.20.203.0 release. It includes
> security and a lot of
I also have built instrumented cluster and at least no bindings
required for system testing are broken.
--
Take care,
Konstantin (Cos) Boudnik
On Tue, May 3, 2011 at 12:51, Jakob Homan wrote:
> Tested the RC on a single node cluster, kicked the tires. Looks good.
> +1 on its release.
>
> Rega
Tested the RC on a single node cluster, kicked the tires. Looks good.
+1 on its release.
Regardless of how the RC got here, we only get benefit from releasing
it. It represents a huge chunk of work from our contributors,
provides needed features for our users and moves us one step closer to
mak
Yup, exactly right - it has been reverted in the trunk as well. Thanks
for digging this up, Koji!
On Tue, May 3, 2011 at 11:22, Koji Noguchi wrote:
>>> except
>>> HADOOP-6386 and HADOOP-6428.
>> causes a rolling port side effect in TT
>>
> I remember bugging Cos and Rob to revert HADOOP-6386.
> h
>> except
>> HADOOP-6386 and HADOOP-6428.
> causes a rolling port side effect in TT
>
I remember bugging Cos and Rob to revert HADOOP-6386.
https://issues.apache.org/jira/browse/HADOOP-6760?focusedCommentId=12867342&;
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
t-12
I think its a good idea to release hadoop-0.20.203. It moves Apache Hadoop a
step forward.
Looks like the technical difficulties are resolved now with latest Arun's
commits.
Being a superset of hadoop-0.20.2 it can be considered based on one of the
official Apache releases.
I don't think there was
On Mon, May 2, 2011 at 22:18, Arun C Murthy wrote:
>
> On May 2, 2011, at 9:43 PM, Konstantin Boudnik wrote:
>>
>> I have looked somewhat more into these two JIRAs and if I remember
>> correctly
>> this fix causes a rolling port side effect in TT and it has been reverted
>> in
>> 0.20.200 (Y! Fred
On May 2, 2011, at 9:43 PM, Konstantin Boudnik wrote:
I have looked somewhat more into these two JIRAs and if I remember
correctly
this fix causes a rolling port side effect in TT and it has been
reverted in
0.20.200 (Y! Fred? release) because Ops weren't happy about this (I
am sure
you ca
On Mon, May 2, 2011 at 16:56, Arun C Murthy wrote:
>
> On May 2, 2011, at 3:01 PM, Arun C Murthy wrote:
>
>
>> On May 2, 2011, at 12:31 PM, Tom White wrote:
>>
>>> I just did a quick search, and these are the JIRAs that are in 0.20.2
>>> but appear not to be in 0.20.203.0.
>>>
>>
>> Thanks Tom.
>
On May 2, 2011, at 9:07 AM, Owen O'Malley wrote:
>
> On May 1, 2011, at 8:52 PM, Nigel Daley wrote:
>
>> I would like to see CI setup on this branch before we release anything from
>> it. I've copied the 0.20 build config and tried running it on this branch,
>> but getting a native compile f
On May 3, 2011, at 9:58 AM, Arun C Murthy wrote:
>>
>> Owen, Suresh and I have committed everything on this list except
>> HADOOP-6386 and HADOOP-6428. Not sure which of the two are relevant/
>> necessary, I'll check with Cos. Other than that hadoop-0.20.203 now a
>> superset of hadoop-0.20.2.
On May 2, 2011, at 4:56 PM, Arun C Murthy wrote:
On May 2, 2011, at 3:01 PM, Arun C Murthy wrote:
On May 2, 2011, at 12:31 PM, Tom White wrote:
I just did a quick search, and these are the JIRAs that are in
0.20.2
but appear not to be in 0.20.203.0.
Thanks Tom.
I did a quick analysis:
On May 2, 2011, at 3:01 PM, Arun C Murthy wrote:
On May 2, 2011, at 12:31 PM, Tom White wrote:
I just did a quick search, and these are the JIRAs that are in 0.20.2
but appear not to be in 0.20.203.0.
Thanks Tom.
I did a quick analysis:
# Remaining for 0.20.203
* HADOOP-5611
* HADOOP-56
On May 2, 2011, at 12:31 PM, Tom White wrote:
I just did a quick search, and these are the JIRAs that are in 0.20.2
but appear not to be in 0.20.203.0.
Thanks Tom.
I did a quick analysis:
# Remaining for 0.20.203
* HADOOP-5611
* HADOOP-5612
* HADOOP-5623
* HDFS-596
* HDFS-723
* HDFS-73
Hey Eric,
I don't have any objections to a release from
branch-0.20-security-203. However when I examined the specific patch
set I noticed the are important implications with respect to
compatibility (of for 0.20.2 and 0.22), a question about project model
(eg not reviewing patches on jira before
How hard would it be to get the patches Tom lists below into
branch-0.20-security-203? I'd think it'd be an easier sell if it were
a superset of all in 0.20, especially since it bears its name.
Otherwise, glad to see the release candidate.
St.Ack
Doug,
On May 2, 2011, at 10:58 AM, Doug Cutting wrote:
The patch selection process for this branch did not appear to be a
community process. A massive patch set was committed en-masse with no
public discussion before or after about its specific composition.
Lets review:
# You proposed to rel
Hi folks,
This strikes me as a bit odd. I think we have already discussed this at length
and agreed that a release could proceed.
Since then, Arun and Owen have worked actively to incorporated community
feedback into this release.
All parties making Hadoop releases other then Apache have al
On Mon, May 2, 2011 at 12:16 PM, Eli Collins wrote:
> On Fri, Apr 29, 2011 at 4:09 PM, Owen O'Malley wrote:
>> I think everything is ready to go on the 0.20.203.0 release. It includes
>> security and a lot of improvements in the capacity scheduler and JobTracker.
>>
>> Should we release http://p
On Fri, Apr 29, 2011 at 4:09 PM, Owen O'Malley wrote:
> I think everything is ready to go on the 0.20.203.0 release. It includes
> security and a lot of improvements in the capacity scheduler and JobTracker.
>
> Should we release http://people.apache.org/~omalley/hadoop-0.20.203.0-rc0/?
>
Based
On 05/02/2011 11:37 AM, Alan Gates wrote:
> From the viewpoint of a downstream user, I'd like to see this released.
> Right now Hive 0.7 and soon HCatalog 0.1 have to depend on a Cloudera
> distribution because they need security. Having Apache products depend
> on 3rd party distributions of Apac
From the viewpoint of a downstream user, I'd like to see this
released. Right now Hive 0.7 and soon HCatalog 0.1 have to depend on
a Cloudera distribution because they need security. Having Apache
products depend on 3rd party distributions of Apache products is
bogus. The sooner this is
On 04/29/2011 04:09 PM, Owen O'Malley wrote:
> I think everything is ready to go on the 0.20.203.0 release. It
> includes security and a lot of improvements in the capacity scheduler
> and JobTracker.
This does not appear to include the 0.20-append work? So it's not
advisable to use HBase with th
On May 1, 2011, at 8:52 PM, Nigel Daley wrote:
> I would like to see CI setup on this branch before we release anything from
> it. I've copied the 0.20 build config and tried running it on this branch,
> but getting a native compile failure:
> https://builds.apache.org/hudson/view/G-L/view/Ha
On Sun, May 1, 2011 at 7:20 PM, Arun C Murthy wrote:
> Eli,
>
> On Apr 30, 2011, at 7:19 PM, "Eli Collins" wrote:
>> Seems like we need to do this before releasing 0.20.203 to prevent
>> blocking the upcoming 0.22 release, due to it being a regression
>> against the stable release (the sooner a r
I would like to see CI setup on this branch before we release anything from it.
I've copied the 0.20 build config and tried running it on this branch, but
getting a native compile failure:
https://builds.apache.org/hudson/view/G-L/view/Hadoop/job/Hadoop-0.20.203-Build/1/console
Nige
On Apr 30
Eli,
On Apr 30, 2011, at 7:19 PM, "Eli Collins" wrote:
> Seems like we need to do this before releasing 0.20.203 to prevent
> blocking the upcoming 0.22 release, due to it being a regression
> against the stable release (the sooner a release from trunk can
> replace a 0.20 based release the bette
+1
Signature matches, md5/sha1 match. Also tried a basic HDFS upgrade
from 0.20.2 to 0.20.203 with fresh configs on a single node: all OK,
including rollback to 0.20.2. -C
On Fri, Apr 29, 2011 at 4:09 PM, Owen O'Malley wrote:
> I think everything is ready to go on the 0.20.203.0 release. It incl
+1 based on some single node tests I did (with security ON).
On 4/29/11 4:09 PM, "Owen O'Malley" wrote:
I think everything is ready to go on the 0.20.203.0 release. It includes
security and a lot of improvements in the capacity scheduler and JobTracker.
Should we release http://people.apache.
On Sat, Apr 30, 2011 at 7:17 AM, Owen O'Malley wrote:
> On Fri, Apr 29, 2011 at 7:21 PM, Eli Collins wrote:
>
>> I took a quick look at the changes in the branch
>
>
> Thanks for taking a look. Please continue to inspect and test out the
> release and vote. I'm really excited that we'll have a re
On Fri, Apr 29, 2011 at 7:21 PM, Eli Collins wrote:
> I took a quick look at the changes in the branch
Thanks for taking a look. Please continue to inspect and test out the
release and vote. I'm really excited that we'll have a release that has
security and the "fred" user limits. Users despera
Hey Owen,
I took a quick look at the changes in the branch (specifically the
range of 200 or so changes where the first line of the commit doesn't
reference a jira). Most of these look like backports of patches on
jira, however there also seem to be changes that don't correspond to
changes in tru
I think everything is ready to go on the 0.20.203.0 release. It includes
security and a lot of improvements in the capacity scheduler and JobTracker.
Should we release http://people.apache.org/~omalley/hadoop-0.20.203.0-rc0/?
-- Owen
37 matches
Mail list logo
