hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kumar Vavilapalli <vino...@apache.org>
Subject Re: Branch merges and 3.0.0-beta1 scope
Date Fri, 25 Aug 2017 21:42:49 GMT
> From a release management perspective, it's *extremely* reasonable to block the inclusion
of new features a month from the planned release date. A typical software development lifecycle
includes weeks of feature freeze and weeks of code freeze. It is no knock on any developer
or any feature to say that we should not include something in 3.0.0.

We have never followed the ‘typical' lifecycle that I am guessing you are referring to.
If we are, you'll need to publish some of the following: a feature freeze date, blockers-criticals-only-from-now
date, testing-finish date, documentation-finish date, final release date and so on.

What we do with Apache releases typically is instead we say ‘this' is roughly when we want
to release, and roughly what features must land and let the rest figure out itself.

Neither is right or wrong. If we want to change the process, we should communicate as such.

Proposing a feature freeze date on the fly is only going to confuse people.

> I've been very open and clear about the goals, schedule, and scope of 3.0.0 over the
last year plus. The point of the extended alpha process was to get all our features in during
alpha, and the alpha merge window has been open for a year. I'm unmoved by arguments about
how long a feature has been worked on. None of these were not part of the original 3.0.0 scope,
and our users have been waiting even longer for big-ticket 3.0 items like JDK8 and HDFS EC
that were part of the discussed scope.

Except our schedule is so fluid (not due to the release management process to be fair) that
it is hard for folks to plan their features. IIRC, our schedule was a GA release beginning
of this year. Again, this is not a critique of 3.0 release process - I have myself done enough
releases to know that sticking to a date and herding the crowd has been an extremely hard

The only way out of this is get 3.0 out and stick to 1-2 month minor releases. May be we start
that by planning a 3.1 right now and push one in January assuming 3.0 GA happens in November.
Cadence is a habit.

> I see that two VOTEs have gone out since I was out. I still plan to follow the proposal
in my original email. This means I'll cut branch-3 and branch-3.0, and move trunk to 4.0.0
before these VOTEs end. This will open up development for Hadoop 3.1.0 and 4.0.0.
> I'm reaching out to the lead contributor of each of these features individually to discuss.
We need to close on this quickly, and email is too low bandwidth at this stage.

My only concern in all of this is if some of these branch contributors decide that they don’t
want and then proceed to having a parallel release and cause pains for everyone. This is what
I tried avoiding parallel 2.9 and 2.10 offline and that’s what I am trying to do here. For
now, I don’t have a horse in this race - that’s between you and the branch-contributors
in question for now. If you can reach an agreement, we are all good for it.


To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

View raw message