Konstantin Shvachko 2013-04-25, 03:17
Roman Shaposhnik 2013-04-25, 15:44
Konstantin Shvachko 2013-04-25, 22:41
Robert Evans 2013-04-25, 15:28
Roman Shaposhnik 2013-04-25, 15:48
Robert Evans 2013-04-25, 22:05
Konstantin Shvachko 2013-04-25, 22:06
Sorry I have not responded sooner. I feel like I have had nothing but
meetings for the past two weeks or so :) My responses are inline below.
On 4/25/13 5:06 PM, "Konstantin Shvachko" <[EMAIL PROTECTED]> wrote:
>Thanks for sharing your opinion.
>On Thu, Apr 25, 2013 at 8:28 AM, Robert Evans <[EMAIL PROTECTED]> wrote:
>> I like the idea. +1
>> I would just make a few tweaks to it, but I am not married to the tweaks
>> and would be happy to adopt the proposal as is. I would prefer a trunk
>> release every quarter. I am fine if a release manager wants to release
>> more often, but I think a regular release cadence makes it simpler for
>> downstream projects and customers to plan for testing and integrating
>> these new releases.
>> I would also like to have a formal process for adopting long term
>> stabilization branches and for retiring them.
>What do you mean by that?
>Branches are adopted if a group of people decides to use and support
>one. Just the way it happened with branch 0.23, but did not with
>0.21 or 0.22. The latter naturally retired, not to say it was a lost
>I don't think there is a way to tell people to use or not one branch or
>So the purpose of the community as I see it is to create the ground
>for stabilizing the releases we produce.
I agree that we cannot say "you are not allowed to use branch-X", even for
very old releases. It is just nice if the community can agree to some
degree about what branches we are going to receive bug fixes/support long
term, and which branches are not. It would be very nice if we could
reduce the number of branches being used, but some sort of minor
commitment from the community that serious bugs on branches X and Y Š are
going to be fixed. Maybe we don't have to worry about it because the
distribution vendors will provide their own long term support.
>> The problem with branch-0.23
>> is that it really is just being stabilized by one group. This in and of
>> itself isn't bad but if the majority of the community is on the same
>> it will stabilize more quickly, and downstream projects/customers can
>> that for the next N-months this branch will be available and receive
>> bug/security fixes. At the end of N-months the community can decide to
>> continue supporting the branch for another period of time or to stop.
>> That way customers can have confidence that when they adopt a branch
>> know how long it will be around for.
>True. Good or bad this is how the community works.
>Anybody can build and propose a release or a change.
>So as anybody can drop a feature in the middle of implementation and
>never come back. Don't even need a vote on that.
>That is why we should develop them in branches and release upon
>So that our customers could be at least sure that the branch they picked
>is not going to change and they can contribute to its stabilization as
>It is really great that Yahoo team (with you as RM) yet again helped
>Hadoop move forward. Not talking about 0.23 only here.
OK to clarify here I am -0 on marking 0.23.7 stable. And this is my
personal opinion here (no Yahoo! hat involved)
>> Also I would not really want 0.23.7 to be marked as the latest stable
>> release, unless
>Not sure I understood. Are you saying 0.23.7 could be marked stable
>under the three conditions. What are they?
>> 1) the community decides that we will maintain it going forward for at
>> least 6 to 12 more months
>Are you asking for help or are you concerned that 0.23 branch will
>somehow disappear? Don't think the latter is possible.
>Look at branch 1, previously known as 0.20. It's been there for
This depends on how quickly Yahoo will be off of branch-0.23 and if Yahoo
is the only one maintaining it then it will not receive any bug fixes.
Does that make branch-0.23 any less stable, no. Does it make it less
desirable for people to move to? Yes.
We stabilized 0.23 with the primarily goal of stabilizing Map Reduce
running on YARN. I don't have a lot of visibility into other applications
that are using YARN. I don't really want YARN applications to need to put
in hacks like pig and hive have to do in order to run on different
versions. But if others feel strongly about this I am fine with relenting.
Roman Shaposhnik 2013-04-30, 04:34
Robert Evans 2013-04-30, 17:39
Konstantin Boudnik 2013-05-01, 05:40
Shv.hadoop 2013-05-01, 06:51