Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CALwhT94FBdtBz=hEKsBBp0k=wW1GKTTLE3aHgqzYJ++SFx-9hA@mail.gmail.com>
References: <CADbBEnvHDdrGCYtGj2PR0i5Wsj=EaPcZ3awg3VPnT6Q_CPG7pQ@mail.gmail.com>
 <bc537456-b976-6e7c-3ace-c7e0c2239f82@cloudera.com> <CADbBEntuOhrzj-BBDuq0kC+81cGYSwDrYp9O8SL4PMS5mfkDSA@mail.gmail.com>
 <CALwhT94FBdtBz=hEKsBBp0k=wW1GKTTLE3aHgqzYJ++SFx-9hA@mail.gmail.com>
From: Chris Trezzo <ctrezzo@gmail.com>
Date: Wed, 18 Jan 2017 11:21:19 -0800
Message-ID: <CAPz5eN7AC3J=kLR45nOpHAO8DF8xK75qdg2Abg-T-zCyignHnA@mail.gmail.com>
Subject: Re: [VOTE] Release cadence and EOL
To: Karthik Kambatla <kasha@cloudera.com>
Cc: Sangjin Lee <sjlee@apache.org>, Daniel Templeton <daniel@cloudera.com>,
	"common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
	"hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>,
	"yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>,
	"mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=001a114c71364706b0054663523b
archived-at: Wed, 18 Jan 2017 19:21:33 -0000

--001a114c71364706b0054663523b
Content-Type: text/plain; charset=UTF-8

Thanks Sangjin for pushing this forward! I have a few questions:

1. What is the definition of end-of-life for a release in the hadoop
project? My current understanding is as follows: When a release line
reaches end-of-life, there are no more planned releases for that line.
Committers are no longer responsible for back-porting bug fixes to the line
(including fixed security vulnerabilities) and it is essentially
unmaintained.

2. How do major releases affect the end-of-life proposal? For example, how
does a new minor release in the next major release affect the end-of-life
of minor releases in a previous major release? Is it possible to have a
maintained 2.x release if there is a 3.3 release?

Thanks!

On Tue, Jan 17, 2017 at 10:32 AM, Karthik Kambatla <kasha@cloudera.com>
wrote:

> +1
>
> I would also like to see some process guidelines. I should have brought
> this up on the discussion thread, but I thought of them only now :(
>
>    - Is an RM responsible for all maintenance releases against a minor
>    release, or finding another RM to drive a maintenance release? In the
> past,
>    this hasn't been a major issue.
>    - When do we pick/volunteer to RM a minor release? IMO, this should be
>    right after the previous release goes out. For example, Junping is
> driving
>    2.8.0 now. As soon as that is done, we need to find a volunteer to RM
> 2.9.0
>    6 months after.
>    - The release process has multiple steps, based on
>    major/minor/maintenance. It would be nice to capture/track how long each
>    step takes so the RM can be prepared. e.g. herding the cats for an RC
> takes
>    x weeks, compatibility checks take y days of work.
>
>
> On Tue, Jan 17, 2017 at 10:05 AM, Sangjin Lee <sjlee@apache.org> wrote:
>
> > Thanks for correcting me! I left out a sentence by mistake. :)
> >
> > To correct the proposal we're voting for:
> >
> > A minor release on the latest major line should be every 6 months, and a
> > maintenance release on a minor release (as there may be concurrently
> > maintained minor releases) every 2 months.
> >
> > A minor release line is end-of-lifed 2 years after it is released or
> there
> > are 2 newer minor releases, whichever is sooner. The community reserves
> the
> > right to extend or shorten the life of a release line if there is a good
> > reason to do so.
> >
> > Sorry for the snafu.
> >
> > Regards,
> > Sangjin
> >
> > On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <daniel@cloudera.com>
> > wrote:
> >
> > > Thanks for driving this, Sangjin. Quick question, though: the subject
> > line
> > > is "Release cadence and EOL," but I don't see anything about cadence in
> > the
> > > proposal.  Did I miss something?
> > >
> > > Daniel
> > >
> > >
> > > On 1/17/17 8:35 AM, Sangjin Lee wrote:
> > >
> > >> Following up on the discussion thread on this topic (
> > >> https://s.apache.org/eFOf), I'd like to put the proposal for a vote
> for
> > >> the
> > >> release cadence and EOL. The proposal is as follows:
> > >>
> > >> "A minor release line is end-of-lifed 2 years after it is released or
> > >> there
> > >> are 2 newer minor releases, whichever is sooner. The community
> reserves
> > >> the
> > >> right to extend or shorten the life of a release line if there is a
> good
> > >> reason to do so."
> > >>
> > >> This also entails that we the Hadoop community commit to following
> this
> > >> practice and solving challenges to make it possible. Andrew Wang laid
> > out
> > >> some of those challenges and what can be done in the discussion thread
> > >> mentioned above.
> > >>
> > >> I'll set the voting period to 7 days. I understand a majority rule
> would
> > >> apply in this case. Your vote is greatly appreciated, and so are
> > >> suggestions!
> > >>
> > >> Thanks,
> > >> Sangjin
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> > > For additional commands, e-mail: common-dev-help@hadoop.apache.org
> > >
> > >
> >
>

--001a114c71364706b0054663523b--