hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: [Release thread] 2.6.5 release activities
Date Sat, 13 Aug 2016 16:49:42 GMT

> On 12 Aug 2016, at 01:42, Chris Trezzo <ctrezzo@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

-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 <kasha@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 <
>> aw@effectivemachines.com
>>> wrote:
>>>> On Aug 11, 2016, at 8:10 AM, Junping Du <jdu@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-unsubscribe@hadoop.apache.org
>>> For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

View raw message