hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Junping Du <...@hortonworks.com>
Subject Re: [VOTE] Release cadence and EOL
Date Thu, 19 Jan 2017 03:06:59 GMT
+1 on Sangjin's proposal - 
"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."

I also noticed Karthik bring up some new proposals - some of them looks interesting to me
and I have some ideas as well. Karthik, can you bring it out in a separated discussion threads
so that we can discuss from there?

About Chris Trezzo's question about definition of EOL of hadoop release, I think potentially
changes could be: 
1. For users of Apache hadoop, they would expect to upgrade to a new minor/major releases
after EOL of their current release because there is no guarantee of new maintenance release.

2. For release effort, apache law claim that committer can volunteer RM for any release. With
this release EOL proposal passes and written into hadoop bylaw, anyone want to call for a
release which is EOL then she/he have to provide a good reason to community and get voted
before to start release effort. We don't want to waste community time/resource to verify/vote
a narrow interested release.

3. About committer's responsibility, I think the bottom line is committer should commit patch
contributor's target release and her/his own interest release which I conservatively agree
with Allen's point that this vote doesn't change anything. But if a committer want to take
care more interest from the whole community like most committers are doing today, he/she should
understand which branches can benefit more people and could skip some EOL release branches
for backport effort.

About major release EOL, this could be more complicated and I think we should discuss separately.

Thanks,

Junping
________________________________________
From: Allen Wittenauer <aw@effectivemachines.com>
Sent: Wednesday, January 18, 2017 3:30 PM
To: Chris Trezzo
Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
mapreduce-dev@hadoop.apache.org
Subject: Re: [VOTE] Release cadence and EOL

> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ctrezzo@gmail.com> wrote:
>
> Thanks Sangjin for pushing this forward! I have a few questions:

        These are great questions, because I know I'm not seeing a whole lot of substance
in this vote.  The way to EOL software in the open source universe is with new releases and
aging it out.  If someone wants to be a RE for a new branch-1 release, more power to them.
 As volunteers to the ASF, we're not on the hook to provide much actual support.  This feels
more like a vendor play than a community one.  But if the PMC want to vote on it, whatever.
 It won't be first bylaw that doesn't really mean much.

> 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.

        Just a point of clarification.  There is no policy that says that committers must
back port.  It's up to the individual committers to push a change onto any particular branch.
Therefore, this vote doesn't really change anything in terms of committer responsibilities
here.

> 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?

        I'm looking forward to seeing this answer too, given that 2.7.0 is probably past the
2 year mark, 2.8.0 has seemingly been in a holding pattern for over a year, and the next 3.0.0
alpha should be RSN....

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


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


Mime
View raw message