Re: Planning for 3.0.0-alpha2

2017-01-19 Thread Akira Ajisaka 

Thanks Sangjin for finding this.

> It looks like hadoop-cloud-storage-project was missed in the version set?

Yes. Probably this is because

  hadoop-cloud-storage-project

is missing in pom.xml so `mvn versions:set` did not work for the 
project. Filed HADOOP-14004 for fixing this.


Regards,
Akira

On 2017/01/20 14:09, Sangjin Lee wrote:

It looks like hadoop-cloud-storage-project was missed in the version set?

On Thu, Jan 19, 2017 at 4:19 PM, Andrew Wang 
wrote:


I've branched branch-3.0.0-alpha2 and moved out the target versions except
for our last blocker to a new 3.0.0-alpha3 version.

Business can continue as usual, please just set target/fix versions of
3.0.0-alpha3 now instead of 3.0.0-alpha2.

Thanks,
Andrew

On Thu, Jan 19, 2017 at 3:52 PM, Andrew Wang 
wrote:


Heads up that I'm branching for 3.0.0-alpha2 and moving out targets
versions. We're waiting on one last blocker which is in final stages of
review.

Best,
Andrew

On Wed, Jan 4, 2017 at 11:15 AM, Andrew Wang 
wrote:


Hi folks,

Thanks to the hard work of many contributors, we've been steadily

burning

down alpha2 blockers. There are only 4 remaining, three of which are PA

and

likely to be committed shortly.

Once those three go in (hopefully this week), I'm going to cut the

alpha2

branch and wait for that last blocker. Normal development activity can
continue on trunk and branch-2, and doesn't need to be committed to the
alpha2 branch.

Since we still have some significant code to wrap up (Tomcat->Jetty
conversion, EC work, rolling upgrade compatibility), it's likely there

will

also be an alpha3 before we freeze for beta1. I've updated the Hadoop 3
wiki page [1] to reflect this.

Thanks,
Andrew

[1]: https://cwiki.apache.org/confluence/display/HADOOP/Hado
op+3.0.0+release

On Mon, Oct 17, 2016 at 1:57 PM, Andrew Wang 
wrote:


Hi folks,

It's been a month since 3.0.0-alpha1, and we've been incorporating

fixes

based on downstream feedback. Thus, it's getting to be time for
3.0.0-alpha2. I'm using this JIRA query to track open issues:

https://issues.apache.org/jira/issues/?jql=project%20in%20(H
ADOOP%2C%20HDFS%2C%20MAPREDUCE%2C%20YARN)%20AND%20%22Target%
20Version%2Fs%22%20in%20(3.0.0-alpha2%2C%203.0.0-beta1%2C%
202.8.0)%20AND%20statusCategory%20not%20in%20(Complete)%
20ORDER%20BY%20priority

If alpha2 goes well, we can declare feature freeze, cut branch-3, and
move onto beta1. My plan for the 3.0.0 release timeline looks like

this:


* alpha2 in early November
* beta1 in early Jan
* GA in early March

I'd appreciate everyone's help in resolving blocker and critical issues
on the above JIRA search.

Thanks,
Andrew












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

Re: Planning for 3.0.0-alpha2

2017-01-19 Thread Sangjin Lee 
It looks like hadoop-cloud-storage-project was missed in the version set?

On Thu, Jan 19, 2017 at 4:19 PM, Andrew Wang 
wrote:

> I've branched branch-3.0.0-alpha2 and moved out the target versions except
> for our last blocker to a new 3.0.0-alpha3 version.
>
> Business can continue as usual, please just set target/fix versions of
> 3.0.0-alpha3 now instead of 3.0.0-alpha2.
>
> Thanks,
> Andrew
>
> On Thu, Jan 19, 2017 at 3:52 PM, Andrew Wang 
> wrote:
>
> > Heads up that I'm branching for 3.0.0-alpha2 and moving out targets
> > versions. We're waiting on one last blocker which is in final stages of
> > review.
> >
> > Best,
> > Andrew
> >
> > On Wed, Jan 4, 2017 at 11:15 AM, Andrew Wang 
> > wrote:
> >
> >> Hi folks,
> >>
> >> Thanks to the hard work of many contributors, we've been steadily
> burning
> >> down alpha2 blockers. There are only 4 remaining, three of which are PA
> and
> >> likely to be committed shortly.
> >>
> >> Once those three go in (hopefully this week), I'm going to cut the
> alpha2
> >> branch and wait for that last blocker. Normal development activity can
> >> continue on trunk and branch-2, and doesn't need to be committed to the
> >> alpha2 branch.
> >>
> >> Since we still have some significant code to wrap up (Tomcat->Jetty
> >> conversion, EC work, rolling upgrade compatibility), it's likely there
> will
> >> also be an alpha3 before we freeze for beta1. I've updated the Hadoop 3
> >> wiki page [1] to reflect this.
> >>
> >> Thanks,
> >> Andrew
> >>
> >> [1]: https://cwiki.apache.org/confluence/display/HADOOP/Hado
> >> op+3.0.0+release
> >>
> >> On Mon, Oct 17, 2016 at 1:57 PM, Andrew Wang 
> >> wrote:
> >>
> >>> Hi folks,
> >>>
> >>> It's been a month since 3.0.0-alpha1, and we've been incorporating
> fixes
> >>> based on downstream feedback. Thus, it's getting to be time for
> >>> 3.0.0-alpha2. I'm using this JIRA query to track open issues:
> >>>
> >>> https://issues.apache.org/jira/issues/?jql=project%20in%20(H
> >>> ADOOP%2C%20HDFS%2C%20MAPREDUCE%2C%20YARN)%20AND%20%22Target%
> >>> 20Version%2Fs%22%20in%20(3.0.0-alpha2%2C%203.0.0-beta1%2C%
> >>> 202.8.0)%20AND%20statusCategory%20not%20in%20(Complete)%
> >>> 20ORDER%20BY%20priority
> >>>
> >>> If alpha2 goes well, we can declare feature freeze, cut branch-3, and
> >>> move onto beta1. My plan for the 3.0.0 release timeline looks like
> this:
> >>>
> >>> * alpha2 in early November
> >>> * beta1 in early Jan
> >>> * GA in early March
> >>>
> >>> I'd appreciate everyone's help in resolving blocker and critical issues
> >>> on the above JIRA search.
> >>>
> >>> Thanks,
> >>> Andrew
> >>>
> >>
> >>
> >
>

Re: [VOTE] Release cadence and EOL

2017-01-19 Thread Chris Douglas 
Sorry, I'd missed the end of the EOL discussion thread.

As several people have pointed out, this is unenforceable. The release
dates on the front page are a decent signal for liveness... do we need
something more formal? All these hypothetical situations would be
decided with more context. The "good reason" clause allows revive a
release line if two "live" branches straddle a dud, so this proposal
only commits us to maintain our mistakes. For two years? As Andrew
points out, while this heuristic usually holds, we're not set up to
enforce it.

We may want to have an informal policy for security issues, since
there are known holes in 2.6.x and earlier that aren't going to be
patched. We need to issue CVEs for those. A policy would simplify
tracking (e.g., announce vulnerabilities no more than a month after a
fix is available in a later release), so we don't wait indefinitely to
announce. Additionally, creating a JIRA and flagging the release on
the download page would be ample warning.

We can still embargo security flaws if someone asks (to give them time
time to implement a fix and call a vote). If there's nothing else in
the release, then we're effectively announcing it. In those cases, we
call a vote on private@ (cc: security@). -C


On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang  wrote:
> I don't think the motivation here is vendor play or taking away power from
> committers. Having a regular release cadence helps our users understand
> when a feature will ship so they can plan their upgrades. Having an EOL
> policy and a minimum support period helps users choose a release line, and
> understand when they will need to upgrade.
>
> In the earlier thread, we discussed how these are not rules, but
> guidelines. There's a lot of flexibility if someone wants to keep
> maintaining a release line (particularly if they are willing to do the
> backporting work). More power to them; more releases are a good thing for
> the project.
>
> My main concern (which I raised on the earlier thread) is that without
> significant improvements to the release process and upstream integration
> testing, it's unlikely we'll actually ship more releases. Too often,
> branches are simply not in a releaseable state, or they have latent blocker
> bugs due to a lack of testing. This is what we've been struggling with on
> both the 2.8.x and 3.0.0-x release lines.
>
> So, in the abstract, I'm +1 on having a published policy on release cadence
> and EOL. This information helps users.
>
> However, I don't think we're ready to actually execute on this policy for
> the above reasons. This leaves me ambivalent overall, perhaps -0 since
> publishing a policy we don't follow is more confusing to users.
>
> My 2c,
> Andrew
>
>
>
> On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal 
> wrote:
>
>> The ASF release policy says releases may not be vetoed [1] so the EOL
>> policy sounds unenforceable. Not sure a release cadence is enforceable
>> either since Release Managers are volunteers.
>>
>> 1. https://www.apache.org/dev/release.html#approving-a-release
>>
>>
>>
>> On 1/18/17, 7:06 PM, "Junping Du"  wrote:
>>
>> +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

Re: [Continued] [Release thread] 2.8.0 release activities

2017-01-19 Thread Junping Du 
According to Varun's offline email, the security fixes has landed on branch-2, 
2.8 and 2.8.0 branch. 
I was kicking off a new RC build (RC1), and will publish it for vote soon. In 
the mean time, please mark fix version as 2.8.1 for any new commits landed on 
branch-2.8, and don't commit anything to branch-2.8.0 at this moment. Thanks!

Cheers,

Junping


From: Junping Du 
Sent: Wednesday, January 18, 2017 3:26 PM
To: common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org; 
mapreduce-...@hadoop.apache.org; yarn-dev@hadoop.apache.org
Cc: Varun Vasudev
Subject: Re: [Continued] [Release thread] 2.8.0 release activities

Hi folks,
 In the passed one or two weeks, we found some new blockers get coming on 
branch-2.8, like: YARN-6068 (log aggregation get stuck when NM restart with 
work preserving enabled) and YARN-6072 (RM unable to start in secure mode). 
Both of them are fixed now (YARN-6072 is fixed by Ajith and I fixed YARN-6068), 
and I was starting the RC build process since early this week. As we have 
significant build tools/process change (docker based) since 2.8 comparing with 
2.6/2.7, it takes me a while to get familiar with it and finally get a 
successful build on 2.8.0-RC0 last night.
 I already push RC0 tag into public which is prerequisite step before RC 
voting. However,  in the mean while, I was pinged by Varun Vasudev that there 
are a known vulnerability issues on container_executor get identified and 
discussed in hadoop security email threads - looks like YARN-5704 fixed part of 
it, but left part - the privilege escalation via /proc/self/environ is not 
fixed yet. So most likely, I have to withdraw our 2.8.0 RC0 although I haven't 
announced it public for vote yet. I will wait this issue get fixed to prepare a 
new release candidate. As RC0 tag cannot be reverted after push into apache, 
our next release candidate will start from RC1.
As I mentioned in early email, 2.8.0 is a very big release (2300+ commits 
since 2.7.3) and I am glad that we are almost there. Thanks everyone for being 
patient and contributing our release work. Please let me know if you have more 
comments or suggestions.

Thanks,

Junping

From: Junping Du 
Sent: Wednesday, January 04, 2017 1:41 AM
To: common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org; 
mapreduce-...@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: Re: [Continued] [Release thread] 2.8.0 release activities

Hi all Hadoopers,
 I just commit YARN-3866 which is the last blocker for branch-2.8, so since 
tomorrow I will kick off process to prepare the first RC for our 2.8.0 release. 
This release will include at least 2374 commits that never landed before in 
previous 2.x releases. Please check https://s.apache.org/RW5k for details. 
There are also 352 fixes marked in 2.7.1, 2.7.2 and 2.7.3 but not marked with 
2.8 (https://s.apache.org/RKti) that I need to double check all are landed in 
branch-2.8 and fix the versions before kicking off the first RC.
 Our progress is slightly behind my estimation weeks ago. However, 
considering we just go through holidays and Jenkins cleanup issues linger on 
for several projects (YARN, etc.), our achievement here is still great! Thanks 
everyone for keep calm and carry on the help for the release. Kudos to Wangda, 
Jian, Akira, Jason, Sangjin, Karthik and all for pushing hard on blockers 
during this time. Also, special thanks to Vinod and Andrew for sharing 
knowledge and practice (include scripts for auto version check) for releasing 
effort.
 Will try to prepare RC0 of 2.8 release for vote within this week. Stay 
tuned!

Thanks,

Junping


From: Junping Du 
Sent: Wednesday, December 07, 2016 11:31 AM
To: Akira Ajisaka; common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org; 
mapreduce-...@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: Re: [Continued] [Release thread] 2.8.0 release activities

Thanks Akira for reporting this. Actually, HADOOP-2.8-JACC worked well for 
several runs before last weekend, but it get failed for latest several runs, 
probably affected by recently Jenkins down.
However, from my recent manual kick off, it seems to be good again: 
https://builds.apache.org/view/H-L/view/Hadoop/job/Hadoop-2.8-JACC/9/. I will 
keep an eye for today's nightly run to see if it back to normal.


Thanks,

Junping


From: Akira Ajisaka 
Sent: Wednesday, December 07, 2016 12:12 AM
To: common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org; 
mapreduce-...@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: Re: [Continued] [Release thread] 2.8.0 release activities

Thanks Junping and Andrew!

HADOOP-2.8-JACC is not working well, so I manually kicked a job to
compare 2.8 with 2.7.3.

Re: Planning for 3.0.0-alpha2

2017-01-19 Thread Andrew Wang 
I've branched branch-3.0.0-alpha2 and moved out the target versions except
for our last blocker to a new 3.0.0-alpha3 version.

Business can continue as usual, please just set target/fix versions of
3.0.0-alpha3 now instead of 3.0.0-alpha2.

Thanks,
Andrew

On Thu, Jan 19, 2017 at 3:52 PM, Andrew Wang 
wrote:

> Heads up that I'm branching for 3.0.0-alpha2 and moving out targets
> versions. We're waiting on one last blocker which is in final stages of
> review.
>
> Best,
> Andrew
>
> On Wed, Jan 4, 2017 at 11:15 AM, Andrew Wang 
> wrote:
>
>> Hi folks,
>>
>> Thanks to the hard work of many contributors, we've been steadily burning
>> down alpha2 blockers. There are only 4 remaining, three of which are PA and
>> likely to be committed shortly.
>>
>> Once those three go in (hopefully this week), I'm going to cut the alpha2
>> branch and wait for that last blocker. Normal development activity can
>> continue on trunk and branch-2, and doesn't need to be committed to the
>> alpha2 branch.
>>
>> Since we still have some significant code to wrap up (Tomcat->Jetty
>> conversion, EC work, rolling upgrade compatibility), it's likely there will
>> also be an alpha3 before we freeze for beta1. I've updated the Hadoop 3
>> wiki page [1] to reflect this.
>>
>> Thanks,
>> Andrew
>>
>> [1]: https://cwiki.apache.org/confluence/display/HADOOP/Hado
>> op+3.0.0+release
>>
>> On Mon, Oct 17, 2016 at 1:57 PM, Andrew Wang 
>> wrote:
>>
>>> Hi folks,
>>>
>>> It's been a month since 3.0.0-alpha1, and we've been incorporating fixes
>>> based on downstream feedback. Thus, it's getting to be time for
>>> 3.0.0-alpha2. I'm using this JIRA query to track open issues:
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(H
>>> ADOOP%2C%20HDFS%2C%20MAPREDUCE%2C%20YARN)%20AND%20%22Target%
>>> 20Version%2Fs%22%20in%20(3.0.0-alpha2%2C%203.0.0-beta1%2C%
>>> 202.8.0)%20AND%20statusCategory%20not%20in%20(Complete)%
>>> 20ORDER%20BY%20priority
>>>
>>> If alpha2 goes well, we can declare feature freeze, cut branch-3, and
>>> move onto beta1. My plan for the 3.0.0 release timeline looks like this:
>>>
>>> * alpha2 in early November
>>> * beta1 in early Jan
>>> * GA in early March
>>>
>>> I'd appreciate everyone's help in resolving blocker and critical issues
>>> on the above JIRA search.
>>>
>>> Thanks,
>>> Andrew
>>>
>>
>>
>

[jira] [Resolved] (YARN-5831) Propagate allowPreemptionFrom flag all the way down to the app

2017-01-19 Thread Andrew Wang (JIRA) 

 [ 
https://issues.apache.org/jira/browse/YARN-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Wang resolved YARN-5831.
---
Resolution: Fixed

> Propagate allowPreemptionFrom flag all the way down to the app
> --
>
> Key: YARN-5831
> URL: https://issues.apache.org/jira/browse/YARN-5831
> Project: Hadoop YARN
>  Issue Type: Sub-task
>  Components: fairscheduler
>Reporter: Karthik Kambatla
>Assignee: Yufei Gu
> Fix For: 3.0.0-alpha2
>
> Attachments: YARN-5831.001.patch, YARN-5831.002.patch, 
> YARN-5831.003.patch, YARN-5831.004.patch, YARN-5831.005.patch
>
>
> FairScheduler allows disallowing preemption from a queue. When checking if 
> preemption for an application is allowed, the new preemption code recurses 
> all the way to the root queue to check this flag. 
> Propagating this information all the way to the app will be more efficient. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Planning for 3.0.0-alpha2

2017-01-19 Thread Andrew Wang 
Heads up that I'm branching for 3.0.0-alpha2 and moving out targets
versions. We're waiting on one last blocker which is in final stages of
review.

Best,
Andrew

On Wed, Jan 4, 2017 at 11:15 AM, Andrew Wang 
wrote:

> Hi folks,
>
> Thanks to the hard work of many contributors, we've been steadily burning
> down alpha2 blockers. There are only 4 remaining, three of which are PA and
> likely to be committed shortly.
>
> Once those three go in (hopefully this week), I'm going to cut the alpha2
> branch and wait for that last blocker. Normal development activity can
> continue on trunk and branch-2, and doesn't need to be committed to the
> alpha2 branch.
>
> Since we still have some significant code to wrap up (Tomcat->Jetty
> conversion, EC work, rolling upgrade compatibility), it's likely there will
> also be an alpha3 before we freeze for beta1. I've updated the Hadoop 3
> wiki page [1] to reflect this.
>
> Thanks,
> Andrew
>
> [1]: https://cwiki.apache.org/confluence/display/HADOOP/
> Hadoop+3.0.0+release
>
> On Mon, Oct 17, 2016 at 1:57 PM, Andrew Wang 
> wrote:
>
>> Hi folks,
>>
>> It's been a month since 3.0.0-alpha1, and we've been incorporating fixes
>> based on downstream feedback. Thus, it's getting to be time for
>> 3.0.0-alpha2. I'm using this JIRA query to track open issues:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20in%20(
>> HADOOP%2C%20HDFS%2C%20MAPREDUCE%2C%20YARN)%20AND%20%
>> 22Target%20Version%2Fs%22%20in%20(3.0.0-alpha2%2C%203.0.0-
>> beta1%2C%202.8.0)%20AND%20statusCategory%20not%20in%20(
>> Complete)%20ORDER%20BY%20priority
>>
>> If alpha2 goes well, we can declare feature freeze, cut branch-3, and
>> move onto beta1. My plan for the 3.0.0 release timeline looks like this:
>>
>> * alpha2 in early November
>> * beta1 in early Jan
>> * GA in early March
>>
>> I'd appreciate everyone's help in resolving blocker and critical issues
>> on the above JIRA search.
>>
>> Thanks,
>> Andrew
>>
>
>

Re: [VOTE] Release cadence and EOL

2017-01-19 Thread Andrew Wang 
I don't think the motivation here is vendor play or taking away power from
committers. Having a regular release cadence helps our users understand
when a feature will ship so they can plan their upgrades. Having an EOL
policy and a minimum support period helps users choose a release line, and
understand when they will need to upgrade.

In the earlier thread, we discussed how these are not rules, but
guidelines. There's a lot of flexibility if someone wants to keep
maintaining a release line (particularly if they are willing to do the
backporting work). More power to them; more releases are a good thing for
the project.

My main concern (which I raised on the earlier thread) is that without
significant improvements to the release process and upstream integration
testing, it's unlikely we'll actually ship more releases. Too often,
branches are simply not in a releaseable state, or they have latent blocker
bugs due to a lack of testing. This is what we've been struggling with on
both the 2.8.x and 3.0.0-x release lines.

So, in the abstract, I'm +1 on having a published policy on release cadence
and EOL. This information helps users.

However, I don't think we're ready to actually execute on this policy for
the above reasons. This leaves me ambivalent overall, perhaps -0 since
publishing a policy we don't follow is more confusing to users.

My 2c,
Andrew



On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal 
wrote:

> The ASF release policy says releases may not be vetoed [1] so the EOL
> policy sounds unenforceable. Not sure a release cadence is enforceable
> either since Release Managers are volunteers.
>
> 1. https://www.apache.org/dev/release.html#approving-a-release
>
>
>
> On 1/18/17, 7:06 PM, "Junping Du"  wrote:
>
> +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 
> Sent: Wednesday, January 18, 2017 3:30 PM
> To: Chris Trezzo
> Cc: common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org;
> yarn-dev@hadoop.apache.org; mapreduce-...@hadoop.apache.org
> Subject: Re: [VOTE] Release cadence and EOL
>
> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo 
> 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.
>

Re: [VOTE] Release cadence and EOL

2017-01-19 Thread Arpit Agarwal 
The ASF release policy says releases may not be vetoed [1] so the EOL policy 
sounds unenforceable. Not sure a release cadence is enforceable either since 
Release Managers are volunteers.

1. https://www.apache.org/dev/release.html#approving-a-release



On 1/18/17, 7:06 PM, "Junping Du"  wrote:

+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 
Sent: Wednesday, January 18, 2017 3:30 PM
To: Chris Trezzo
Cc: common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org; 
yarn-dev@hadoop.apache.org; mapreduce-...@hadoop.apache.org
Subject: Re: [VOTE] Release cadence and EOL

> On Jan 18, 2017, at 11:21 AM, Chris Trezzo  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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org


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