hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <mfo...@hortonworks.com>
Subject Re: Sustaining Releases (Was: [VOTE] Release 0.20.204.0-rc0)
Date Wed, 24 Aug 2011 23:29:28 GMT
Per Arun's message below, I edited the "Sustaining Release" section of
http://wiki.apache.org/hadoop/Roadmap
to incorporate these items.  Feedback welcome.
--Matt

On Wed, Aug 3, 2011 at 3:39 PM, Eli Collins <eli@cloudera.com> wrote:

> On Wed, Aug 3, 2011 at 2:02 PM, Arun C Murthy <acm@hortonworks.com> wrote:
> > 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.
> >
>
> +1   sounds great.
>
> Thanks,
> Eli
>

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