Thanks folks for opening up the discussion on our EOL policy. That's also exactly what I wanted to discuss when I opened up the 2.6.5 discussion:
I also want to gauge the community's interest in maintaining the 2.6.x > line. How long do we maintain this line? What would be a sensible EOL > policy? Note that as the main code lines start diverging (java version, > features, etc.), the cost of maintaining multiple release lines does go up. > I'd love to hear your thoughts. I look forward to that discussion thread. As for 2.6.5, since there is enough interest in it, I'll work with Chris on that. Regards, Sangjin On Fri, Aug 12, 2016 at 8:19 AM, Junping Du <j...@hortonworks.com> wrote: > I am OK with going forward for 2.6.5 release given some people may not be > ready for migration to 2.7 and we have done some preparation work already. > Thanks Chris for pushing the release work forward! > About future releases of 2.6 (after 2.6.5) or any other legacy releases, I > think it worth more discussions. I disagree with what Allen said below - > Java 6 support should be a solid reason for branch-2.6 release keep going. > In this community, we are so aggressive to drop Java 7 support in 3.0.x > release. Here, why we are so conservative to keep releasing new bits to > support Java 6? Our release effort, although driven by different person, > should be consistent logically. > I don't think we have clear rules/polices about EOL of legacy releases > before. This is a bit off topic here. Will start a new thread later for > more discussion. > > Thanks, > > Junping > > ________________________________________ > From: Chris Trezzo <ctre...@gmail.com> > Sent: Friday, August 12, 2016 12:42 AM > To: Karthik Kambatla > Cc: common-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org; > mapreduce-...@hadoop.apache.org; yarn-...@hadoop.apache.org > Subject: Re: [Release thread] 2.6.5 release activities > > Thanks everyone for the discussion! Based on what has been said in this > thread, I will move forward on the preparation efforts (working with > Sangjin and the community) for a 2.6.5 release. If there is a strong > objection to this, please let us know. > > I see three initial tasks going forward: > > 1. Fix the pre-commit build for branch-2.6. I am not entirely sure what is > involved here, but will start looking into it using HADOOP-12800 as a > starting point. > > 2. Look through the unresolved issues still targeted to 2.6.5 and > resolve/re-target as necessary. There are currently 17 of them: > https://issues.apache.org/jira/issues/?jql=(project%20% > 3D%20%22Hadoop%20Common%22%20OR%20project%20%3D%20% > 22Hadoop%20YARN%22%20OR% > 20project%20%3D%20%22Hadoop%20Map%2FReduce%22%20OR% > 20project%20%3D%20%22Hadoop%20HDFS%22)%20AND%20( > fixVersion%20%3D%202.6.5%20OR%20%22Target%20Version%2Fs%22% > 20%3D%202.6.5)%20AND%20(status%20!%3D%20Resolved%20AND%20status%20!%3D% > 20Closed)%20ORDER%20BY%20status%20ASC > > 3. Look through the backport candidates in the spreadsheet in more detail > and backport/drop as necessary. There are currently 15 of them: > https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3olWpOCo6EBAey1WYC > 8hTRUemHvYPPzY/edit?usp=sharing > > Finally, I think it would be awesome to continue the release end-of-life > discussion. As we get better and better at release cadence it is going to > be really helpful to have an established EOL policy. It will be less > confusing for contributors and help set clear expectations for end users as > to when they need to start making reasonable migration plans, especially if > they want to stay on a well supported release line. I would be happy to > help with this effort as well. It would be great if we could leverage that > discussion and have EOL information for the 2.6 line when we release 2.6.5. > > As always, please let me know if I have missed something. > > Thanks! > Chris Trezzo > > On Thu, Aug 11, 2016 at 1:03 PM, Karthik Kambatla <ka...@cloudera.com> > wrote: > > > Since there is sufficient interest in 2.6.5, we should probably do it. > All > > the reasons Allen outlines make sense. > > > > That said, Junping brings up a very important point that we should think > of > > for future releases. For a new user or a user that does not directly > > contribute to the project, more stable releases make it hard to pick > from. > > > > As Chris T mentioned, the notion of EOL for our releases seems like a > good > > idea. However, to come up with any EOLs, we need to have some sort of > > cadence for the releases. While this is hard for major releases (big > bang, > > potentially incompatible features), it should be doable for minor > releases. > > > > How do people feel about doing a minor release every 6 months, with > > follow-up maintenance releases every 2 months until the next minor and as > > needed after that? That way, we could EOL a minor release a year after > its > > initial release? In the future, we could consider shrinking this window. > In > > addition to the EOL, this also makes our releases a little more > predictable > > for both users and vendors. Note that 2.6.0 went out almost 2 years ago > and > > we haven't had a new minor release in 14 months. I am happy to start > > another DISCUSS thread around this if people think it is useful. > > > > Thanks > > Karthik > > > > On Thu, Aug 11, 2016 at 12:50 PM, Allen Wittenauer < > > a...@effectivemachines.com > > > wrote: > > > > > > > > > On Aug 11, 2016, at 8:10 AM, Junping Du <j...@hortonworks.com> wrote: > > > > > > > > Allen, to be clear, I am not against any branch release effort here. > > > However, > > > > > > "I'm not an X but.... " > > > > > > > as RM for previous releases 2.6.3 and 2.6.4, I feel to have > > > responsibility to take care branch-2.6 together with other RMs (Vinod > and > > > Sangjin) on this branch and understand current gap - especially, to get > > > consensus from community on the future plan for 2.6.x. > > > > Our bylaw give us freedom for anyone to do release effort, but our > > bylaw > > > doesn't stop our rights for reasonable question/concern on any release > > > plan. As you mentioned below, people can potentially fire up branch-1 > > > release effort. But if you call a release plan tomorrow for branch-1, I > > > cannot imagine nobody will question on that effort. Isn't it? > > > > > > From previous discussions I've seen around releases, I > > > think it would depend upon which employee from which vendor raised the > > > question. > > > > > > > Let's keep discussions on releasing 2.6.5 more technical. IMO, to > make > > > 2.6.5 release more reasonable, shouldn't we check following questions > > first? > > > > 1. Do we have any significant issues that should land on 2.6.5 > > comparing > > > with 2.6.4? > > > > 2. If so, any technical reasons (like: upgrade is not smoothly, > > > performance downgrade, incompatibility with downstream projects, etc.) > to > > > stop our users to move from 2.6.4 to 2.7.2/2.7.3? > > > > I believe having good answer on these questions can make our release > > > plan more reasonable to the whole community. More thoughts? > > > > > > I think these questions are moot though: > > > > > > * Hadoop 2.6 is the last release to support JDK6. That sort of ends > any > > > questions around moving to 2.7. > > > > > > * There are always bugs in software that can benefit from getting > fixes. > > > Given the JDK6 issue, yes, of course there are reasons why someone may > > want > > > a 2.6.5. > > > > > > * If a company/vendor is willing to fund people to work on a release, > I'd > > > much rather they do that work in the ASF than off on their own > somewhere. > > > This way the community as a whole benefits. > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: mapreduce-dev-unsubscr...@hadoop.apache.org > > > For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: mapreduce-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org > >
