Hi,
I'm glad we're heading towards a release. We'd like to better understand some
aspects regarding the release plan.
What would be the tentative release schedule, and what affects particular
releases? We could either continue with our current version or plan based on
what's going to be relea
On 3/30/10 8:22 PM, "Owen O'Malley" wrote:
>
> On Mar 30, 2010, at 3:40 PM, Doug Cutting wrote:
>
>> Another release we might consider is 1.0 based on 0.20.
>
> It is tempting and I think that 0.20 is *really* our 1.0, but I think
> re-labeling a release a year after it came out would be co
Owen O'Malley wrote:
It is tempting and I think that 0.20 is *really* our 1.0, but I think
re-labeling a release a year after it came out would be confusing.
I wasn't proposing just a re-labeling. I was proposing a new release,
branched from 0.20 rather than trunk. We'd introduce some change
Allen Wittenauer wrote:
The fact that there are a *ton*
of admin tool changes/fixes/additions in the Yahoo! Distribution of 0.20
(and quite a few in CDH) should be the big hint that Apache 0.20 is *not*
1.0.
Right. I'm proposing we make a 1.0 release that tries to match what
folks are actual
HDFS 0.20 does not have a reliable append.
Also it is (was last time I looked) incompatible with the 0.21 append HDFS-256.
That wouldn't be a problem if that was the only incompatibility. But it's not.
If 1.0 is re-labeled or re-branched from 0.20 we will have to many
incompatibilities
going int
[Owen] > I think that we should change the rules so that the remaining
0.X releases are minor releases.
+1
[Owen] > I'll volunteer to be release manager for a release branched
in November, which should be roughly 6 months after Tom's new 0.21
release.
That would be great. Thanks, Owen!
[Doug] >
RPC.waitForProxy should retry through NoRouteToHostException
Key: HADOOP-6667
URL: https://issues.apache.org/jira/browse/HADOOP-6667
Project: Hadoop Common
Issue Type: Improvement
If I may pitch in briefly here, believe it or not, there is a lot of
enterprises out there whom think that anything that isn't version 1.0
isn't worth considering, let alone deploying (doesn't make sense, but
some people are like that). Hence, from a market adoption point of view,
Apache Hadoop
Apply audience and stability annotations to classes in common
-
Key: HADOOP-6668
URL: https://issues.apache.org/jira/browse/HADOOP-6668
Project: Hadoop Common
Issue Type: Improvemen
Konstantin Shvachko wrote:
I would like to propose a straightforward release of 0.21 from current
0.21 branch.
That could be done too. Tom's volunteered to drive a release from trunk
in a few weeks. Owen's volunteered to drive another release from trunk
in about six months. Would you like
zlib.compress.level ignored for DefaultCodec initialization
-
Key: HADOOP-6669
URL: https://issues.apache.org/jira/browse/HADOOP-6669
Project: Hadoop Common
Issue Type: Bug
Moving to mapreduce-dev@ (bcc common-dev@).
Responses inline:
On Mar 29, 2010, at 7:02 PM, Mike Cardosa wrote:
1) When the jobtracker assigns a task to a tasktracker, it determines
if the task is data-local or rack-local from the splits (which were
generated during the job init process). Where
UserGroupInformation doesn't support use in hash tables
---
Key: HADOOP-6670
URL: https://issues.apache.org/jira/browse/HADOOP-6670
Project: Hadoop Common
Issue Type: Bug
Componen
On 3/31/2010 2:19 PM, Doug Cutting wrote:
> Konstantin Shvachko wrote:
>> I would like to propose a straightforward release of 0.21 from current
>> 0.21 branch.
>
> That could be done too. Would you like to volunteer to drive a release from
> the current 0.21 branch?
I would If I could.
I intende
14 matches
Mail list logo
