hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sangjin Lee <sj...@apache.org>
Subject Re: [Release thread] 2.6.5 release activities
Date Fri, 12 Aug 2016 20:31:55 GMT
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 <jdu@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 <ctrezzo@gmail.com>
> Sent: Friday, August 12, 2016 12:42 AM
> To: Karthik Kambatla
> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> mapreduce-dev@hadoop.apache.org; yarn-dev@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 <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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message