[VOTE] Release cadence and EOL
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
Re: [VOTE] Release cadence and EOL
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: hdfs-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
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 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-unsubscr...@hadoop.apache.org > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > >
Re: [VOTE] Release cadence and EOL
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 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 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 > > 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-unsubscr...@hadoop.apache.org > > > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > > > > > > > > >
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: hdfs-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
+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-dev@hadoop.apache.org; yarn-...@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
Re: [VOTE] Release cadence and EOL
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-dev@hadoop.apache.org; yarn-...@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
Re: [VOTE] Release cadence and EOL
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-dev@hadoop.apache.org; > yarn-...@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'
Re: [VOTE] Release cadence and EOL
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-dev@hadoop.apache.org; >> yarn-...@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 >> >> >> >> >> - To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
rs. > > > > My 2c, > > Andrew > > > > > > > > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal < > aagar...@hortonworks.com> > > 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-dev@hadoop.apache.org; > >> yarn-...@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. > >
Re: [VOTE] Release cadence and EOL
;> > >> >> 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-dev@hadoop.apache.org; >> >> yarn-...@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
Re: [VOTE] Release cadence and EOL
> On Jan 21, 2017, at 7:08 PM, Karthik Kambatla wrote: > > 3. RM: some method to madness. Junping, for instance, is trying to roll > a release with 2300 patches. It is a huge time investment. (Thanks again, > Junping.) Smaller releases are easier to manage. A target release cadence, > coupled with a process that encourages volunteering, IMO would lead to more > committers doing releases. In the case of 2.8.0, that's on the original RM and "back port fever" that inflicts way too many committers. 2.8.0 has been sitting in a separate branch for over a year. Of *course* it is going to be a disaster. If the original RM had said "I don't have time, someone take over" after 3 months of it being left idle or another committer feeling as though they could take it or not everyone dumping everything they can in every release possible, it wouldn't be nearly as bad. Not only do we need to encourage volunteering, but we also need to encourage people to relinquish control. If the PMC wants to enact a cadence, then they also must be willing to step in when an RM is unresponsive and request someone else take over. A message every three months saying "Yes, I'm still working on it." doesn't really help anyone, including the RM. > To conclude, the biggest value I see is us (the community) agreeing on good > practices for our releases and work towards that. Writing it down somewhere > makes it a little more formal like the compatibility stuff, even if it is > not enforceable. So it's exactly like the compatibility stuff. ;) - To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
I'm going to stop the vote and go back to the discussion. It shouldn't be a big surprise given the reservation we have so far. I do hope there will be some actionable outcome as a result of that discussion. Regards, Sangjin On Mon, Jan 23, 2017 at 8:17 AM, Allen Wittenauer wrote: > > > On Jan 21, 2017, at 7:08 PM, Karthik Kambatla > wrote: > > > > 3. RM: some method to madness. Junping, for instance, is trying to roll > > a release with 2300 patches. It is a huge time investment. (Thanks > again, > > Junping.) Smaller releases are easier to manage. A target release > cadence, > > coupled with a process that encourages volunteering, IMO would lead to > more > > committers doing releases. > > > In the case of 2.8.0, that's on the original RM and "back port > fever" that inflicts way too many committers. 2.8.0 has been sitting in a > separate branch for over a year. Of *course* it is going to be a > disaster. If the original RM had said "I don't have time, someone take > over" after 3 months of it being left idle or another committer feeling as > though they could take it or not everyone dumping everything they can in > every release possible, it wouldn't be nearly as bad. > > Not only do we need to encourage volunteering, but we also need to > encourage people to relinquish control. If the PMC wants to enact a > cadence, then they also must be willing to step in when an RM is > unresponsive and request someone else take over. A message every three > months saying "Yes, I'm still working on it." doesn't really help anyone, > including the RM. > > > > To conclude, the biggest value I see is us (the community) agreeing on > good > > practices for our releases and work towards that. Writing it down > somewhere > > makes it a little more formal like the compatibility stuff, even if it is > > not enforceable. > > So it's exactly like the compatibility stuff. ;) > > > - > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > >
