> On 12 Aug 2016, at 01:42, Chris Trezzo <ctre...@gmail.com> wrote: > > 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
I'd recommend looking at the S3a phase I patches and pick up those which essentially mean it's not suitable for production in 2.6 https://issues.apache.org/jira/browse/HADOOP-11571 -blocksize == 0, HTTP1.1 request abort vs close in particular. There's another thing to look at: security. What security patches will need to go into 2.6.x which can actually be done? > > 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: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
