Thanks for great feedback thus far. I agree with some that this is more of a guideline than a policy. I also agree to some extent that this is not very enforceable given the current practice.
I do differ, though, on whether there is value in something like this if it is not completely enforceable. I don't think it's such a binary situation, and do think there is a plenty of middle ground where a good guideline can save us time and help us a great deal. If we view this more as a guideline (or a baseline if you will), this can act as a reference point for discussion for setting up releases as well as making decisions on stopping maintenance releases. Today, all of these discussions invariably have to start from scratch with only past experiences as a guide. We end up spending a decent amount of time just to get to a common understanding. If we have a baseline to operate from, at least we can considerably shorten that discussion and be a little more productive and consistent as a community. I see value in that. The security patch for the 2.6.x line is a case in point. Without any guideline, we would start with "What should we do for 2.6.x? Should we continue to patch it?" With this guideline, the baseline is already "it's been 2 years since 2.6.0 is released and we should consider stopping releasing from 2.6.x and encourage users to upgrade to 2.7.x." What do you think? On Thu, Jan 19, 2017 at 7:02 PM, Chris Douglas <cdoug...@apache.org> wrote: > 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. > Actually the decision on security issues is a pretty strong indicator of our desire for EOL. If we say we do not want to patch that line for security vulnerability, then there would be even *less* rationale for fixing any other issue on that line. So the decision to stop backporting security patches is a sufficient indication of EOL in my mind. > > 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 <andrew.w...@cloudera.com> > 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 < > 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" <j...@hortonworks.com> 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 <a...@effectivemachines.com> > >> 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 <ctre...@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-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: yarn-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org > >
