hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arun C Murthy <...@hortonworks.com>
Subject Sustaining Releases (Was: [VOTE] Release
Date Wed, 03 Aug 2011 21:02:40 GMT
On Aug 2, 2011, at 4:28 AM, Steve Loughran wrote:
> I'm getting confused about release roadmaps right now
> Is there somewhere that lists the (proposed) timetable for the 0.20.204, 0.20.205, 0.22,
0.23 releases?

Since I was among the people who started the 'security on 0.20' thread, I apologize for the
lack of clarity on the roadmap and timelines. 

Eric did send out a note on the motivation for sustaining releases (http://s.apache.org/hadoop-sustenance-releases)
- which I believe is important to keep Hadoop installations going. However, I accept that
there has been very poor clarity on the process for inclusion of content to the sustaining
releases and the timelines.

Here is my proposal for the community process for sustaining releases moving forward:
# The Release Manager should clearly communicate, upfront, the expected timeline for each
upcoming release. 
# Anyone interested in contributing to the release submits a patch to trunk, if applicable*,
and to the branch-0.20-security branch. Then talk to the Release Manager for inclusion via
the normal process.

The RM is responsible for release content, timelines and for enforcing that each change should
have an equivalent for trunk, as applicable, before inclusion.

If this makes sense, I'll add this to the wiki to record it.


So, how are we doing with 0.20.204 content and trunk given the above proposal? Very well,
in fact. Matt, Suresh and I have done a detailed analysis (separate email), please take a


*Please note the exception that we have agreed that MRv2 is the way forward (http://s.apache.org/mr1)
, and thus, MR1 patches might not be ported as-is to trunk in some cases such as fixes to
JobTracker/TaskTracker. However, this doesn't mean changes to the runtime (i.e. map task,
reduce task, sort, shuffle etc.) are exempt from the rules proposed above. 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message