On Apr 1, 2010, at 10:50 AM, Doug Cutting wrote:
If it takes months, it is a failure. It should take weeks, if that.
On Apr 1, 2010, at 9:31 PM, Dhruba Borthakur wrote:
We have been testing the HDFS append code for 0.20 (using HDFS-200,
HDFS-142), but I believe it is not ready for production
+1 for exploring. HBase TRUNK is now mavenized. Has kinks still but
its getting there. Will see if can get some of the "experts" hanging
in hbase space to help out with this effort.
St.Ack
On Thu, Apr 1, 2010 at 7:34 PM, Chris Douglas wrote:
> +1 -C
>
> On Thursday, April 1, 2010, Giridharan K
We have been testing the HDFS append code for 0.20 (using HDFS-200,
HDFS-142), but I believe it is not ready for production yet. I am guessing
that there would be another two months of testing before I would classify
0.20.3 + HDFS-200 as production quality. HDFS-200 touches code paths that
would ge
> Companies wanting a 1.0 product could always pay Cloudera and get a
v2 product.
lol :) good point Allen, lets please *not* adopt a 1.0 labeling for
Apache Hadoop :)
Seriously though, to avoid my previous comment about 1.0 labeling being
misinterpreted, though I think the 1.0 labeling is i
+1 -C
On Thursday, April 1, 2010, Giridharan Kesavan wrote:
>
> I would like call for a vote to created a development branch of common
> trunk to work on mavenizing hadoop common.
>
> -Giri
>
>>> - de-deprecate "classic" mapred APIs (no Jira issue yet)
>>
>> Why?
>
> So that folks can be told that if their code compiles without deprecation
> warnings against 1.0 then it should work for all 1.x releases.
Deprecation warnings aren't only fair notice that the API may go away.
The classic
+1 for the the exploration. *If* it works as advertised, it'll be a
great time saver.
Giridharan Kesavan wrote:
I would like call for a vote to created a development branch of common
trunk to work on mavenizing hadoop common.
-Giri
+1 for creating a branch for exploring moving to Maven.
Performance Improvement in Secure RPC
-
Key: HADOOP-6674
URL: https://issues.apache.org/jira/browse/HADOOP-6674
Project: Hadoop Common
Issue Type: Improvement
Reporter: Jitendra Nath Pandey
Hi Guys,
To throw in my 2 cents: it would be really nice to get out a 1.0 branch
based off of 0.20 < it¹s not perfect, but releases never are. That¹s why you
can make more of them. :)
In terms of the significance of the 1.0 labeling, I think it's important for
adoption. I was telling someone at J
I would like call for a vote to created a development branch of common
trunk to work on mavenizing hadoop common.
-Giri
Chris Douglas wrote:
- de-deprecate "classic" mapred APIs (no Jira issue yet)
Why?
So that folks can be told that if their code compiles without
deprecation warnings against 1.0 then it should work for all 1.x releases.
I don't mind releasing 1.0 with the classic APIs. Given the installe
LOL, I want a v100! :)
On 4/1/10 2:31 PM, "Allen Wittenauer" wrote:
On 4/1/10 2:15 PM, "Mattmann, Chris A (388J)"
wrote:
> In terms of the significance of the 1.0 labeling, I think it's important for
> adoption.
Companies wanting a 1.0 product could always pay Cloudera and get a v2
product
On 4/1/10 2:15 PM, "Mattmann, Chris A (388J)"
wrote:
> In terms of the significance of the 1.0 labeling, I think it's important for
> adoption.
Companies wanting a 1.0 product could always pay Cloudera and get a v2
product. ;)
Hi Guys,
To throw in my 2 cents: it would be really nice to get out a 1.0 branch
based off of 0.20 < it¹s not perfect, but releases never are. That¹s why you
can make more of them. :)
In terms of the significance of the 1.0 labeling, I think it's important for
adoption. I was telling someone at J
> Thus far the changes suggested for a 1.0 branch are:
> - de-deprecate "classic" mapred APIs (no Jira issue yet)
Why? Tom and Owen's proposal preserves compatibility with the
deprecated FileSystem and mapred APIs up to 1.0. After Tom cuts a
release- from either the 0.21 branch or trunk- then iss
nightly builds have incorrect VersionInfo
-
Key: HADOOP-6673
URL: https://issues.apache.org/jira/browse/HADOOP-6673
Project: Hadoop Common
Issue Type: Bug
Components: build
Report
Todd Lipcon wrote:
With HDFS-200 we'd also need HDFS-142
Good to know. I' have to admit to being puzzled by HDFS-200, since
Nicholas resolved it as a duplicate on 7 January, yet Dhruba's continued
to post patches to it.
Dhruba, Stack: do you have any thoughts on the appropriateness of maki
On Thu, Apr 1, 2010 at 10:50 AM, Doug Cutting wrote:
> Chris Douglas wrote:
>
>> Spending the next few months voting and arguing on which
>> patches make it into "new" 0.20 (branched in 2008) instead of
>> addressing these issues is *not* progress. I strongly oppose this.
>>
>
> If it takes month
Chris Douglas wrote:
Spending the next few months voting and arguing on which
patches make it into "new" 0.20 (branched in 2008) instead of
addressing these issues is *not* progress. I strongly oppose this.
If it takes months, it is a failure. It should take weeks, if that.
Thus far the chang
> My latest proposal, a 1.0 branch based on 0.20, contains two questions:
>
> 1. Should we make an Apache release that more closely corresponds to what
> folks are using in production today (and will be using for a while yet)?
>
> 2. If we're considering the 0.20 mapreduce and filesystem APIs to be
Thanks Tom and Owen for stepping up --
We're using 0.20.2 as effectively 1.0 here, too, so I think a 1.0 branch is
a good idea that recognizes that status quo and deal with it, particularly
for having a 1.0 that's pre-split and pre-security (big changes).
Couple random thoughts:
1) I agree with
Chris K Wensel wrote:
are we saying we will de-deprecate the stable APIs in .20, or make the new APIs
introduced in .20 stable?
+1 on removing the deprecations on the stable APIs.
Yes. I too am +1 on removing deprecations in stable, public APIs in a
1.0 release. Code that uses only public
are we saying we will de-deprecate the stable APIs in .20, or make the new APIs
introduced in .20 stable?
+1 on removing the deprecations on the stable APIs.
On Mar 31, 2010, at 2:19 PM, Doug Cutting wrote:
> Konstantin Shvachko wrote:
>> I would like to propose a straightforward release of 0.2
Our org (Trend Micro) will be using an internal build based on 0.20 for at
least the rest of this year. It is, really, already "1.0" from our point of
view, the first ASF Hadoop release officially adopted into our production
environment. I hope other users of Hadoop will speak up on this thread
BytesWritable.write(buf) use much more CPU in writeInt() then write(buf)
Key: HADOOP-6672
URL: https://issues.apache.org/jira/browse/HADOOP-6672
Project: Hadoop Common
To use maven for hadoop common builds
-
Key: HADOOP-6671
URL: https://issues.apache.org/jira/browse/HADOOP-6671
Project: Hadoop Common
Issue Type: Improvement
Components: build
Affects Versio
27 matches
Mail list logo
