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