This is a long standing issue with branch-0.22 - are either of you planning
on fixing this?
I personally do not have plans to fix security in .22. I don't think
we should target it. I hope 0.23 will be a replacement for it by
summer. Is it still in your roadmap, Arun?
I also don't think that
Sanjay,
Yes I plan to continue fixing bugs as long as I use the branch, and
release it if the need arise. I hope there won't be many required with
0.23 progressing as planned.
Thanks,
--Konstantin
On Mon, Mar 19, 2012 at 4:24 PM, sanjay Radia san...@hortonworks.com wrote:
On Mar 19, 2012, at
Lots of good stuff on this thread. Todd, Chris and Todd have made great
points. (+1)
Doug, I think you have misdiagnosed the problem (in your comment below). IMO
the problem at the time of the creation of the 0.20.2xx was that the Hadoop
community had not produced a stable release for
On Mon, Mar 19, 2012 at 11:02 PM, Konstantin Shvachko
shv.had...@gmail.com wrote:
Feature freeze has been broken so many times for the .20 branch, so
that it became a norm for the entire project rather than an exception,
which we had in the past.
I agree we should be stricter about what
On 3/19/12 3:38 PM, Todd Lipcon t...@cloudera.com wrote:
So a related policy we might add
to prevent such situations in the future might be that if you backport
something from branch n to n-2 then you ought to also be required to
backport it to branch n-1 and in general to all intervening
On 3/19/12 11:02 PM, Konstantin Shvachko shv.had...@gmail.com wrote:
Doug
to prevent such situations in the future might be that if you backport
something from branch n to n-2 then you ought to also be required to
backport it to branch n-1 and in general to all intervening branches.
This is
We vote would be to leave 0.22 as it is, and rename 0.23 as Hadoop 2.0.
-dhruba
On Sun, Mar 18, 2012 at 5:07 PM, Owen O'Malley omal...@apache.org wrote:
Without working security, I don't think 0.22 should be moved out of the
0.22.x release numbering. I see that branch-0.22 has 12 fixes since
Hadoop naming is definitely confusing. And having Hadoop-1 did not
make it less confusing for users.
Current 0.22 - Gets renamed to 1.5 (if it ever gets tested and released)
It was released on November 29, 2011.
eBay is actively using it as of today.
If the goal of renaming branches is to make
I agree with Konstantin. In previous discussion, I had suggested
simultaneous renumbering, but for some reason it was not considered.
(For history buffs: I upgraded from Windows 1.0 to Windows 3.1 straight.
Windows 2.0 did not have many features that made it compelling to upgrade.
It did not seem
Konstantin and Milind,
As I've noted on the other thread (my bad):
However, the problem is that hadoop-0.22 has removed public and
non-deprecated apis/features (i.e. security) which are present in branch-1
(previously branch-0.20.2xx).
This is against the Apache Hadoop release policy
On 03/19/2012 02:47 PM, Arun C Murthy wrote:
This is against the Apache Hadoop release policy on major releases i.e. only
features deprecated for at least one release can be removed.
In many case the reason this happened was that features were backported
from trunk to 0.20 but not to 0.22. In
Arun,
As Konstantin has noted in the email below:
If the community decides to rename .22 to 2 I will be glad to work on it.
My inclination (as I have communicated to several people at apachecon) is
to upgrade our clusters from 1.0 to 0.23 (whatever it is called when it
becomes stable). The
On Mon, Mar 19, 2012 at 2:56 PM, Doug Cutting cutt...@apache.org wrote:
On 03/19/2012 02:47 PM, Arun C Murthy wrote:
This is against the Apache Hadoop release policy on major releases i.e. only
features deprecated for at least one release can be removed.
In many case the reason this happened
On 03/19/2012 03:38 PM, Todd Lipcon wrote:
Unfortunately, I don't have a better solution in mind that resolves
the above problems - I just don't think it's tenable to combine a
policy like anyone may make a release branch off trunk and claim a
major version number with another policy like you
-1. I agree with Todd; we tried this policy before and the project
didn't produce a usable release for two years. Its benefits are
fiction and its harm is documented.
However 0.22 is (or isn't) released, no general policy is required and
nobody should waste their time trying to define one.
On Mon, Mar 19, 2012 at 3:38 PM, Todd Lipcon t...@cloudera.com wrote:
On the other hand, it does suck for users if they update from 1.x to
2.x and they end up losing some bug fixes or features they
previously were running.
Keep in mind that nobody's proposing to rename .22 branch into 2 right
On Mar 19, 2012, at 4:18 PM, Doug Cutting wrote:
We also should decide whether we want to permit ourselves to get in this
pinch again. I think it's avoidable if in the future we only make
releases that are consistent with our other policies. Backports should
be easier for intervening
Roman Milind: asking again - would you guys be willing to step up and fix
0.22 to be more reasonable as a hadoop-2 candidate i.e. fix/validate security?
On Mar 19, 2012, at 4:29 PM, Roman Shaposhnik wrote:
On Mon, Mar 19, 2012 at 3:38 PM, Todd Lipcon t...@cloudera.com wrote:
On the other
On Mar 20, 2012, at 12:28 AM, Chris Douglas wrote:
-1. I agree with Todd; we tried this policy before and the project
didn't produce a usable release for two years. Its benefits are
fiction and its harm is documented.
However 0.22 is (or isn't) released, no general policy is required and
Arun, let me answer both of your questions in the same reply:
On Mon, Mar 19, 2012 at 4:38 PM, Arun C Murthy a...@hortonworks.com wrote:
So, let me ask again - is there anyone willing to step up and fix security in
branch-0.22?
If not, and I haven't seen evidence to the contrary for a very
On Mon, Mar 19, 2012 at 12:04PM, Konstantin Shvachko wrote:
Hadoop naming is definitely confusing. And having Hadoop-1 did not
make it less confusing for users.
Current 0.22 - Gets renamed to 1.5 (if it ever gets tested and released)
It was released on November 29, 2011.
eBay is actively
Hi,
Just one concern I wanted to expresss:
On Sun, Mar 18, 2012 at 11:11 AM, Todd Papaioannou
drluckys...@gmail.com wrote:
[Snip]
Current 1.X - Remains 1.x (as new bug fix releases are released)
Current 0.22 - Gets renamed to 1.5 (if it ever gets tested and released)
Current 0.23 - Gets
9.22 can't be considered as 1.5 because it is the major release from 1.0 (old
0.20.x). Besides, by declaring it as 1.5 we'll be planting future confusion of
the same sort that happened around 0.20* line.
And last but not least, the same discussion has happened in the past around
1.0 release time
On Mar 18, 2012, at 10:01 AM, Konstantin Boudnik wrote:
9.22 can't be considered as 1.5 because it is the major release from 1.0 (old
0.20.x). Besides, by declaring it as 1.5 we'll be planting future confusion of
the same sort that happened around 0.20* line.
And last but not least, the
Without working security, I don't think 0.22 should be moved out of the
0.22.x release numbering. I see that branch-0.22 has 12 fixes since 0.22.0,
which was 3 months ago. My read on those numbers is that there is some
adoption and therefore bug fixes, but no one is making major changes in the
All,
With the upcoming release of 0.23, isn't it about time that we started calling
0.23 Hadoop 2.0 instead?
While the numbering system may make sense to everyone here, to the rest of the
world it's going to be hella confusing for 0.23 to come out after Hadoop 1.0
was released. Since 0.23 has
26 matches
Mail list logo
