On May 10, 2011, at 10:49 PM, Aaron T. Myers wrote:
On Tue, May 10, 2011 at 10:24 PM, Devaraj Das d...@yahoo-inc.com
wrote:
.
By far the most significant incompatibility that I've seen from a user
perspective is that setting hadoop.job.ugi no longer has any effect.
Granted, this
On 5/8/11 11:10 AM, Eric Baldeschwieler eri...@yahoo-inc.com wrote:
I'd agree with this too. [same disclaimer as milind, not on PMC]
In general one would not expect to see an incompatible change added in a
dot release (0.24.1 0.24.2). I'd expect anything like that to require
community
On Tue, May 10, 2011 at 12:41 PM, Scott Carey sc...@richrelevance.comwrote:
As an observer, this is a very important observation. Sure, the default
is that dot releases are bugfix-onl. But exceptions to these rules are
sometimes required and often beneficial to the health of the project.
I'd agree with this too. [same disclaimer as milind, not on PMC]
In general one would not expect to see an incompatible change added in a dot
release (0.24.1 0.24.2). I'd expect anything like that to require community
discussion and support.
As milind summarized, we seem to have support for
On Sat, May 7, 2011 at 6:36 PM, Ian Holsman had...@holsman.net wrote:
On May 8, 2011, at 9:50 AM, Eric Sammer wrote:
do we permit
backward incompatible changes between 0.22.0 and 0.22.1 or is this
something we've allowed just for the 203 release?
good question.
do we allow incompatible
[I am not on PMC, but seeing that PMC may be busy with other issues, I
will try to answer your questions.]
Eric,
I think the thread
http://mail-archives.apache.org/mod_mbox/hadoop-general/201101.mbox/%3C18C
5c999-4680-4684-bc55-a430c40fd...@yahoo-inc.com%3E will answer your
questions. Here is
On May 6, 2011, at 11:18 PM, Milind Bhandarkar wrote:
Allen, there are per job limits, and per user limits in this branch. (So,
max capacity of -1 is for the queue, but within the queue, the per user
limits come into picture.) If I remember right, the defaults were based on
a certain
On May 8, 2011, at 9:50 AM, Eric Sammer wrote:
do we permit
backward incompatible changes between 0.22.0 and 0.22.1 or is this
something we've allowed just for the 203 release?
good question.
do we allow incompatible (smallish) features to be added to a 20.x release.
hoping that they will
[Mentioning again: I am not on the PMC, and this email contains
non-binding opinions based on my reading the general@hadoop.apache.org
emails.]
It is my understanding that, from the beginning, the 0.20+security was
always treated as an exception to the normal (I.e. Pre-0.20) release
process.
of forward
progress, and such. Perhaps this is additional, and I pray sufficient,
motivation to cease the proxy battles, bury the hatchet, etc.
- Andy
--- On Fri, 5/6/11, Steve Loughran ste...@apache.org wrote:
From: Steve Loughran ste...@apache.org
Subject: Re: [VOTE] Release candidate
On May 5, 2011, at 1:56 PM, Jakob Homan wrote:
+1
Downloaded, verified, tested on single node cluster to my
satisfaction. We've also brought this release up on a sizable cluster
and checked its basic sanity.
All of you people doing single node tests are missing stuff. For
On May 6, 2011, at 6:43 PM, Todd Papaioannou wrote:
Allen,
Can you provide some more details into what issues you are seeing with the
capacity scheduler? Is it just the docs don't match the code, or are you
seeing real issues with job scheduling?
Jobs are definitely not getting
I'm not going to cast a vote, but I'm concerned about this for the same reasons
Eli brought up -- in particular, compatibility with 0.22. I'm an author of
several patches that have gone into 0.21 and trunk, only to stay on hiatus for
2 years because the project hasn't made a stable release
Roy,
On Wed, May 4, 2011 at 7:22 PM, Roy T. Fielding field...@gbiv.com wrote:
The ASF is a vehicle for whomever wishes to collaborate on a
given project. Collaboration means helping do the work. Those
who do the work may do so for whatever reasons that they think
are good, whether it is
Non binding.
- Andy
--- On Wed, 5/4/11, Ian Holsman had...@holsman.net wrote:
just as a Tally we have
6+1's (andy.. is yours binding?? if so 7)
and 3 -1's.
so according to the votes so far we are releasing.. but
according to our bylaws.. we need to wait 7 days for
everyone to chime in.
I abstain: +/- 0.
I can't vote against the good work done by the crew at Y!
But I can't vote for a 0.20.clusterbomb release that railroads over
precedent compounding further the existing confusion that already
exists around the state of Hadoop.
Thanks,
St.Ack
On Wed, May 4, 2011 at 10:31 AM,
+1
Downloaded the release, validated checksums, deployed a single-node
cluster, and ran some HDFS sanity tests, Web UI tests and mapreduce
examples.
Regards,
Suresh
+1
Downloaded, verified, tested on single node cluster to my
satisfaction. We've also brought this release up on a sizable cluster
and checked its basic sanity.
Regardless of the difficult path we've had over the past year, this is
a good chunk of code to get out to the community. I'd much
Here's an updated release candidate for 0.20.203.0. I've incorporated the
feedback and included all of the patches from 0.20.2, which is the last stable
release. I also fixed the eclipse-plugin problem.
The candidate is at: http://people.apache.org/~omalley/hadoop-0.20.203.0-rc1/
Please
On Wed, May 4, 2011 at 10:31 AM, Owen O'Malley omal...@apache.org wrote:
Here's an updated release candidate for 0.20.203.0. I've incorporated the
feedback and included all of the patches from 0.20.2, which is the last
stable release. I also fixed the eclipse-plugin problem.
The candidate
On May 4, 2011, at 10:31 AM, Owen O'Malley wrote:
Here's an updated release candidate for 0.20.203.0. I've incorporated the
feedback and included all of the patches from 0.20.2, which is the last
stable release. I also fixed the eclipse-plugin problem.
The candidate is at:
On Wed, May 4, 2011 at 10:31 AM, Owen O'Malley omal...@apache.org wrote:
Here's an updated release candidate for 0.20.203.0. I've incorporated the
feedback and included all of the patches from 0.20.2, which is the last
stable release. I also fixed the eclipse-plugin problem.
The candidate
-1
This candidate has lots of patches that are not in trunk, potentially
adding regressions to 0.22 and 0.23. This should be addressed before we
release from 0.20-security. We should also not move to four-component
version numbering. A release from the 0.20-security branch should
perhaps be
-1 for the same reasons I outlined in my email yesterday. This is not a
community artifact following the community's processes, and thus should not
be an official release until those issues are addressed.
On Wed, May 4, 2011 at 3:17 PM, Doug Cutting cutt...@apache.org wrote:
-1
This candidate
With my Cloudera hat on..
When we went through the 10x and 20x patches we only pulled a subset
of them, primarily for security and the general improvements that we
thought were good. We found both incompatible changes and some
sketchy changes that we did not pull in from a quality perspective.
@Eli This rc contains many patches not yet committed to trunk.
If you've compiled this list, can you post it?
On Wed, May 4, 2011 at 3:24 PM, Eli Collins e...@cloudera.com wrote:
With my Cloudera hat on..
When we went through the 10x and 20x patches we only pulled a subset
of them, primarily
With Cloudera hat on, I agree with Eli's assessment.
With Apache hat on, I don't see how this is at all relevant to the task at
hand. I would make the same arguments against taking CDH3 and releasing it
as an ASF artifact -- we'd also have a certain amount of work to do to make
sure that all of
On Wed, May 4, 2011 at 3:29 PM, Jakob Homan jgho...@gmail.com wrote:
@Eli This rc contains many patches not yet committed to trunk.
If you've compiled this list, can you post it?
Here's the list Todd posted yesterday:
Your -1 vote essentially blocks the changes that are already available in
CDH to be available from Apache open source!
As Eric mentioned, this thread is about an Apache release, not CDH.
My -1 vote does not block these changes from being released via
Apache. You can not veto a release.
To: general@hadoop.apache.org
Sent: Wed, May 4, 2011 3:36:16 PM
Subject: Re: [VOTE] Release candidate 0.20.203.0-rc1
On Wed, May 4, 2011 at 3:29 PM, Jakob Homan jgho...@gmail.com wrote:
@Eli This rc contains many patches not yet committed to trunk.
If you've compiled this list, can you post
On May 4, 2011, at 1:17 PM, Allen Wittenauer wrote:
Am I misreading this, or are the MR protocols out of sync between
0.20.203 and 0.21? It would also appear that this is marked stable in 0.21.
What is the user impact?
The names of the protocols were changed, but the names of the
+1 for the release.
I downloaded the release, verified checksums, built and deployed. Ran
randomwriter jobs on it.
Everything passes.
--
thanks
mahadev
@mahadevkonar
On Wed, May 4, 2011 at 3:05 PM, Arun C Murthy a...@yahoo-inc.com wrote:
On May 4, 2011, at 10:31 AM, Owen O'Malley wrote:
On Wed, May 4, 2011 at 15:06, Suresh Srinivas sures...@yahoo-inc.com wrote:
Eli,
How many of these patches that you find troublesome are in CDH already?
How is that relevant to the release vote and discrepancies listed in
Eli's email?
Regards,
Suresh
On 5/4/11 3:03 PM, Eli Collins
On Wed, May 4, 2011 at 4:11 PM, Arun C Murthy a...@yahoo-inc.com wrote:
On May 4, 2011, at 4:09 PM, Tsz Wo (Nicholas), Sze wrote:
The list seems highly inaccurate. Checked the first few N/A items. All
are
false positives.
Also, can you please provide a list on features which are not
On May 4, 2011, at 4:44 PM, Todd Lipcon wrote:
On Wed, May 4, 2011 at 4:11 PM, Arun C Murthy a...@yahoo-inc.com
wrote:
On May 4, 2011, at 4:09 PM, Tsz Wo (Nicholas), Sze wrote:
The list seems highly inaccurate. Checked the first few N/A
items. All
are
false positives.
Also, can you
Good suggestion, it would be helpful to hash out the issues around
compatibility, feature branches, version numbers, how to contribute at
Apache before putting up new votes that would be helpful, ie the vote
would go much smoother if all the issues with the previous vote were
addressed before
Eli,
I think the intent from the email was to just vote on this thread,
which I agree with.
Discussions should be done in a separate threads. Hopefully we can
all stick to just voting!
thanks
mahadev
On Wed, May 4, 2011 at 5:22 PM, Eli Collins e...@cloudera.com wrote:
Good suggestion, it
I tend to agree. Changing release model of Apache Hadoop train isn't
something that should be done in a hassle or as a part of release
voting.
If these questions aren't addressed - let's postpone the vote and
discuss all the complications or implications until they sorted out or
the
I'm +1 on releasing rc1. The signature and hashes match on the
artifact, ran some of the more aggressive MR tests. Reviewed changes
from rc0.
It looks like we need a FAQ for this release, if only to prevent the
same questions from being asked and answered across different threads
and lists.
Ok. I'll bite.
The point of a vote is to learn what everyone thinks. So far we have learned:
1 - the team that is trying to contribute code and do a release thinks it is
ready.
2 - Cloudera does not think the release is a good idea.
No more talk between the Team contributing code and
On Wed, May 4, 2011 at 6:18 PM, Eric Baldeschwieler
eri...@yahoo-inc.com wrote:
Ok. I'll bite.
The point of a vote is to learn what everyone thinks. So far we have learned:
1 - the team that is trying to contribute code and do a release thinks it is
ready.
2 - Cloudera does not think the
Non-biding -1.
I did download it and checked it out, but when I look at the
documentation I see it says Hadoop 0.20 documentation in the tab on
top. From what I can tell this isn't the branch 0.20 so I think it's
an error and from a user point of view this looks more like something
I would call
My (non-binding) vote for 0.20.203.0-rc1 is +1.
I downloaded, compiled, ran tests, ran my bigrams example, all ran
perfectly.
(I did a single node test without security on.)
The voting criteria I used are:
1. Is this a working release? : Yes
2. Does it take the codebase forward? : Yes
3. Does
Speculation either on the motives of those objecting to a release or of those
making contributions or proposing a release does not advance progress. The
accusations and counter-accusations seen on this thread are regrettable and I
feel less and less confident in the future of Apache Hadoop as
+1.
I downloaded the bits, compiled and ran unit tests. Also, looked at the
source code to some extent. Looks good.
-dhruba
On Wed, May 4, 2011 at 6:56 PM, Roy T. Fielding field...@gbiv.com wrote:
On May 4, 2011, at 5:39 PM, Eli Collins wrote:
The point is that these discussion should be
On May 4, 2011, at 6:24 PM, Jean-Daniel Cryans wrote:
Non-biding -1.
I did download it and checked it out, but when I look at the
documentation I see it says Hadoop 0.20 documentation in the tab on
top. From what I can tell this isn't the branch 0.20 so I think it's
an error and from a
just as a Tally
we have
6+1's (andy.. is yours binding?? if so 7)
and 3 -1's.
so according to the votes so far we are releasing.. but according to our
bylaws.. we need to wait 7 days for everyone to chime in.
--I
On May 5, 2011, at 12:22 PM, Roy T. Fielding wrote:
On May 4, 2011, at 6:24 PM,
-1.
As Roy says, whatever gets released will define the new norm by which
policies are assumed, and I certainly don't want this project to change its
norms to accommodate bad practices. In particular, Eli presented three very
reasonable technical objections to this release. To summarize:
1)
(non-binding) -1 for similar reasons to what Jeff and others have laid out,
and certainly if we're going to change the development process as a side
effect of a release vote.
On Wed, May 4, 2011 at 9:54 PM, Jeff Hammerbacher ham...@cloudera.comwrote:
-1.
As Roy says, whatever gets released
49 matches
Mail list logo
