hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Payne <erichadoo...@yahoo.com.INVALID>
Subject Re: Updated 2.8.0-SNAPSHOT artifact
Date Thu, 10 Nov 2016 14:16:31 GMT
How do we come to a resolution regarding whether or not re-cut branch-2.8 or release it as
it is (after fixing blockers)?
There are some things in branch-2 that I would like to pull back into branch-2.8, so a resolution
to this question will affect how I proceed.
Thanks,-Eric
      From: Karthik Kambatla <kasha@cloudera.com>
 To: Ming Ma <mingma@twitter.com> 
Cc: Sangjin Lee <sjlee0@gmail.com>; Jason Lowe <jlowe@yahoo-inc.com>; Akira Ajisaka
<ajisakaa@oss.nttdata.co.jp>; Brahma Reddy Battula <brahmareddy.battula@huawei.com>;
Vinod Kumar Vavilapalli <vinodkv@apache.org>; "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>;
"hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>; "mapreduce-dev@hadoop.apache.org"
<mapreduce-dev@hadoop.apache.org>; "yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>
 Sent: Thursday, November 10, 2016 1:56 AM
 Subject: Re: Updated 2.8.0-SNAPSHOT artifact
   
If there is interest in releasing off of branch-2.8, we should definitely
do that. As Sangjin mentioned, there might be value in doing 2.9 off
branch-2 too.

How do we go about maintenance releases along those minor lines, and when
would we discontinue 2.6.x/2.7.x releases?

On Wed, Nov 9, 2016 at 12:06 PM, Ming Ma <mingma@twitter.com> wrote:

> I would also prefer releasing current 2.8 branch sooner. There are several
> incomplete features in branch-2 such as YARN-914 and HDFS-7877 that are
> better served if we can complete them in the next major release. Letting
> them span across multiple releases might not be desirable as there could be
> some potential compatibility issues involved. Therefore if we recut 2.8 it
> means we have to work on those items before the new 2.8 is released which
> could cause major delay on the schedule.
>
> On Mon, Nov 7, 2016 at 10:37 AM, Sangjin Lee <sjlee0@gmail.com> wrote:
>
>> +1. Resetting the 2.8 effort and the branch at this point may be
>> counter-productive. IMO we should focus on resolving the remaining
>> blockers
>> and getting it out the door. I also think that we should seriously
>> consider
>> 2.9 as well, as a fairly large number of changes have accumulated in
>> branch-2 (over branch-2.8).
>>
>>
>> Sangjin
>>
>> On Fri, Nov 4, 2016 at 3:38 PM, Jason Lowe <jlowe@yahoo-inc.com.invalid>
>> wrote:
>>
>> > At this point my preference would be to do the most expeditious thing to
>> > release 2.8, whether that's sticking with the branch-2.8 we have today
>> or
>> > re-cutting it on branch-2.  Doing a quick JIRA query, there's been
>> almost
>> > 2,400 JIRAs resolved in 2.8.0 (1).  For many of them, it's well-past
>> time
>> > they saw a release vehicle.  If re-cutting the branch means we have to
>> wrap
>> > up a few extra things that are still in-progress on branch-2 or add a
>> few
>> > more blockers to the list before we release then I'd rather stay where
>> > we're at and ship it ASAP.
>> >
>> > Jason
>> > (1) https://issues.apache.org/jira/issues/?jql=project%20in%
>> > 20%28hadoop%2C%20yarn%2C%20mapreduce%2C%20hdfs%29%
>> > 20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%202.8.0
>> >
>> >
>> >
>> >
>> >
>> >    On Tuesday, October 25, 2016 5:31 PM, Karthik Kambatla <
>> > kasha@cloudera.com> wrote:
>> >
>> >
>> >  Is there value in releasing current branch-2.8? Aren't we better off
>> > re-cutting the branch off of branch-2?
>> >
>> > On Tue, Oct 25, 2016 at 12:20 AM, Akira Ajisaka <
>> > ajisakaa@oss.nttdata.co.jp>
>> > wrote:
>> >
>> > > It's almost a year since branch-2.8 has cut.
>> > > I'm thinking we need to release 2.8.0 ASAP.
>> > >
>> > > According to the following list, there are 5 blocker and 6 critical
>> > issues.
>> > > https://issues.apache.org/jira/issues/?filter=12334985
>> > >
>> > > Regards,
>> > > Akira
>> > >
>> > >
>> > > On 10/18/16 10:47, Brahma Reddy Battula wrote:
>> > >
>> > >> Hi Vinod,
>> > >>
>> > >> Any plan on first RC for branch-2.8 ? I think, it has been long time.
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> --Brahma Reddy Battula
>> > >>
>> > >> -----Original Message-----
>> > >> From: Vinod Kumar Vavilapalli [mailto:vinodkv@apache.org]
>> > >> Sent: 20 August 2016 00:56
>> > >> To: Jonathan Eagles
>> > >> Cc: common-dev@hadoop.apache.org
>> > >> Subject: Re: Updated 2.8.0-SNAPSHOT artifact
>> > >>
>> > >> Jon,
>> > >>
>> > >> That is around the time when I branched 2.8, so I guess you were
>> getting
>> > >> SNAPSHOT artifacts till then from the branch-2 nightly builds.
>> > >>
>> > >> If you need it, we can set up SNAPSHOT builds. Or just wait for the
>> > first
>> > >> RC, which is around the corner.
>> > >>
>> > >> +Vinod
>> > >>
>> > >> On Jul 28, 2016, at 4:27 PM, Jonathan Eagles <jeagles@gmail.com>
>> wrote:
>> > >>>
>> > >>> Latest snapshot is uploaded in Nov 2015, but checkins are still
>> coming
>> > >>> in quite frequently.
>> > >>> https://repository.apache.org/content/repositories/snapshots
>> /org/apach
>> > >>> e/hadoop/hadoop-yarn-api/
>> > >>>
>> > >>> Are there any plans to start producing updated SNAPSHOT artifacts
>> for
>> > >>> current hadoop development lines?
>> > >>>
>> > >>
>> > >>
>> > >> ------------------------------------------------------------
>> ---------
>> > >> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>> > >> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>> > >>
>> > >>
>> > >> ------------------------------------------------------------
>> ---------
>> > >> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>> > >> For additional commands, e-mail: common-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