Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <AD354F56741A1B47882A625909A59C692BE3A254@SZXEML505-MBX.china.huawei.com>
References: 
 <CAMyYaR++-i8etK8Dh3g8y4bTc9ogdCdvuAP6ASo53348z0FeRg@mail.gmail.com>
	<55A754CA.6060301@oss.nttdata.co.jp>
	<CAAD07OKHn5Hc59SKyzJeviCPhpa3D6fGXFdi-Kd3RzTvHXmDSw@mail.gmail.com>
	<D1CD18F3.272A8%cnauroth@hortonworks.com>
	<A310858B-6F6D-4DAF-9F87-33CF5FDF246C@hortonworks.com>
	<CAAD07OLQGADW1xYCAfYyuDmDdqMX_Cw7sv=U6c1+1KBikYij6w@mail.gmail.com>
	<621877812.236842.1445958775552.JavaMail.yahoo@mail.yahoo.com>
	<AD354F56741A1B47882A625909A59C692BE39FD9@SZXEML505-MBX.china.huawei.com>
	<CAAD07OK6D0_Ad1Vpa3JmsG99h0fdQfYdD2hbcO3GTZXoPtp84g@mail.gmail.com>
	<AD354F56741A1B47882A625909A59C692BE3A0C9@SZXEML505-MBX.china.huawei.com>
	<9FC1F956-7C15-4FF9-841F-1E0E5C6AC05C@hortonworks.com>
	<CAAD07OKKRwkM6BmAS0tTdUK7YjAeRjq9HPp1287XhcNzuLJPgg@mail.gmail.com>
	<AD354F56741A1B47882A625909A59C692BE3A254@SZXEML505-MBX.china.huawei.com>
Date: Wed, 28 Oct 2015 15:34:29 -0700
Message-ID: 
 <CALwhT96hkHVaC1TsOhNQEd9CKofyXFbMchZ7n-zGnF23hrQU0Q@mail.gmail.com>
Subject: Re: 2.7.2 release plan
From: Karthik Kambatla <kasha@cloudera.com>
To: "yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>
Cc: Tsuyoshi Ozawa <ozawa@apache.org>,
 Vinod Vavilapalli <vinodkv@hortonworks.com>,
	"hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>,
	"common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
 Vinod Kumar Vavilapalli <vinodkv@apache.org>,
	Wangda Tan <wheeleast@gmail.com>
Content-Type: multipart/alternative; boundary=001a114e4ab43b53c0052331cc1c

--001a114e4ab43b53c0052331cc1c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I would like for us to make sure later maintenance releases are more stable
than previous ones. IMO, increasing stability is more important than the
timing of a release.

Will adding all the patches in 2.7.3 reduce the stability going from 2.7.2
to 2.7.3? If yes, can we just leave them for 2.8.0?

On Wed, Oct 28, 2015 at 12:07 PM, Naganarasimha G R (Naga) <
garlanaganarasimha@huawei.com> wrote:

> Yes Vinod & Tsuyoshi,
>
> Within a week merging them would be difficult. I can start backporting
> them after 2.7.2 so that it can be ported to 2.7.3 faster, also shall i
> apply  2.7.3-candidate labels to them ?
>
> + Naga
> ______________________________
> From: Tsuyoshi Ozawa [ozawa@apache.org]
> Sent: Wednesday, October 28, 2015 23:13
> To: Vinod Vavilapalli
> Cc: yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> common-dev@hadoop.apache.org; Vinod Kumar Vavilapalli; Wangda Tan;
> Tsuyoshi Ozawa; Naganarasimha G R (Naga)
> Subject: Re: 2.7.2 release plan
>
> Vinod,
>
> Thank you for taking care of this. I've checked the list of changes.
> As a result, I agree that we don't have enough time to backport these
> changes into 2.7.2 by this weekend. For a fast move, it's better
> suggestion to me to backport these tickets into 2.7.3.
>
> Best,
> - Tsuyoshi
>
> On Thu, Oct 29, 2015 at 2:19 AM, Vinod Vavilapalli
> <vinodkv@hortonworks.com> wrote:
> > Tsuyoshi / Wangda / Naga,
> >
> > This looks too big of a list to me if we have to cut an RC by this
> weekend per my plan.
> >
> > I=E2=80=99d suggest a fast move on things you think are low risk enough=
 and punt
> everything else for next release.
> >
> > Thanks
> > +Vinod
> >
> >> On Oct 28, 2015, at 3:08 AM, Naganarasimha G R (Naga) <
> garlanaganarasimha@huawei.com> wrote:
> >>
> >> Thanks Tsuyoshi,
> >> If required even i can pitch in  :)
> >> Additional to this we added the support in Mapreduce for labels in
> MAPREDUCE-6304,
> >>
> >> Regards,
> >> + Naga
> >> ________________________________________
> >> From: Tsuyoshi Ozawa [ozawa@apache.org]
> >> Sent: Wednesday, October 28, 2015 14:28
> >> To: yarn-dev@hadoop.apache.org
> >> Cc: hdfs-dev@hadoop.apache.org; common-dev@hadoop.apache.org; Vinod
> Kumar Vavilapalli; Wangda tan
> >> Subject: Re: 2.7.2 release plan
> >>
> >> Thank you for reporting, Naganarasimha.
> >> Vinod and Wangda, I will help you to backport these changes.
> >>
> >> Best,
> >> - Tsuyoshi
> >>
> >> On Wed, Oct 28, 2015 at 2:57 PM, Naganarasimha G R (Naga)
> >> <garlanaganarasimha@huawei.com> wrote:
> >>> Hi Vinod, & Wangda
> >>>
> >>> I think it would be good to backport, following jira's related to
> NodeLabels as it will improve debug ability and usability of NodeLabels
> >>> --------------------------------
> >>> Key                     Summary
> >>> --------------------------------
> >>> YARN-4215       YARN-2492 RMNodeLabels Manager Need to verify and
> replace node labels for the only modified Node Label Mappings in the requ=
est
> >>> YARN-4162       YARN-2492 CapacityScheduler: Add resource usage by
> partition and queue capacity by partition to REST API
> >>> YARN-4140       YARN-2492 RM container allocation delayed incase of
> app submitted to Nodelabel partition
> >>> YARN-3717       YARN-2492 Expose app/am/queue's node-label-expression
> to RM web UI / CLI / REST-API
> >>> YARN-3647       YARN-2492 RMWebServices api's should use updated api
> from CommonNodeLabelsManager to get NodeLabel object
> >>> YARN-3593       YARN-2492 Add label-type and Improve
> "DEFAULT_PARTITION" in Node Labels Page
> >>> YARN-3583       YARN-2492 Support of NodeLabel object instead of plai=
n
> String in YarnClient side.
> >>> YARN-3581       YARN-2492 Deprecate -directlyAccessNodeLabelStore in
> RMAdminCLI
> >>> YARN-3579       YARN-2492 CommonNodeLabelsManager should support
> NodeLabel instead of string label name when getting
> node-to-label/label-to-label mappings
> >>> YARN-3565       YARN-2492
> NodeHeartbeatRequest/RegisterNodeManagerRequest should use NodeLabel obje=
ct
> instead of String
> >>> YARN-3521       YARN-2492 Support return structured NodeLabel objects
> in REST API
> >>> YARN-3362       YARN-2492 Add node label usage in RM CapacitySchedule=
r
> web UI
> >>> YARN-3326       YARN-2492 Support RESTful API for getLabelsToNodes
> >>> YARN-3216       YARN-2492 Max-AM-Resource-Percentage should respect
> node labels
> >>> YARN-3136       YARN-3091 getTransferredContainers can be a bottlenec=
k
> during AM registration
> >>>
> >>> Please inform if any support is required to backport them to 2.7.2
> >>>
> >>> Regards,
> >>> + Naga
> >>> ________________________________________
> >>> From: Kihwal Lee [kihwal@yahoo-inc.com.INVALID]
> >>> Sent: Tuesday, October 27, 2015 20:42
> >>> To: hdfs-dev@hadoop.apache.org; common-dev@hadoop.apache.org
> >>> Cc: Chris Nauroth; yarn-dev@hadoop.apache.org;
> mapreduce-dev@hadoop.apache.org; Vinod Kumar Vavilapalli; Ming Ma
> >>> Subject: Re: 2.7.2 release plan
> >>>
> >>> I think we need HDFS-8950 and HDFS-7725 in 2.7.2.It should be easy to
> backport/cherry-pick HDFS-7725. For HDFS-8950, it will be nice if Ming ca=
n
> chime in.
> >>> Kihwal
> >>>
> >>>      From: Tsuyoshi Ozawa <ozawa@apache.org>
> >>> To: "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>
> >>> Cc: Chris Nauroth <cnauroth@hortonworks.com>; "
> yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>; "
> hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>; "
> mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>; Vinod
> Kumar Vavilapalli <vinodkv@apache.org>
> >>> Sent: Tuesday, October 27, 2015 2:39 AM
> >>> Subject: Re: 2.7.2 release plan
> >>>
> >>> Vinod and Chris,
> >>>
> >>> Thanks for your reply. I'll do also backport not only bug fixes but
> >>> also documentations(I think 2.7.2 includes them). It helps users a lo=
t.
> >>>
> >>> Best,
> >>> - Tsuyoshi
> >>>
> >>> On Tuesday, 27 October 2015, Vinod Vavilapalli <
> vinodkv@hortonworks.com>
> >>> wrote:
> >>>
> >>>> +1.
> >>>>
> >>>> Thanks
> >>>> +Vinod
> >>>>
> >>>>> On Jul 16, 2015, at 8:18 AM, Chris Nauroth <cnauroth@hortonworks.co=
m
> >>>> <javascript:;>> wrote:
> >>>>>
> >>>>> I'd be comfortable with inclusion of any doc-only patch in minor
> >>>> releases.
> >>>>> There is a lot of value to end users in pushing documentation fixes
> as
> >>>>> quickly as possible, and they don't bear the same risk of
> regressions or
> >>>>> incompatibilities as code changes.
> >>>>>
> >>>>> --Chris Nauroth
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 7/16/15, 12:38 AM, "Tsuyoshi Ozawa" <ozawa@apache.org
> <javascript:;>>
> >>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> thank you for starting the discussion about 2.7.2 release.
> >>>>>>
> >>>>>>> The focus obviously is to have blocker issues [2], bug-fixes and
> *no*
> >>>>>> features / improvements.
> >>>>>>
> >>>>>> I've committed YARN-3170, which is an improvement of documentation=
.
> I
> >>>>>> thought documentation pages which can be fit into branch-2.7 can b=
e
> >>>>>> included easily. Should I revert it?
> >>>>>>
> >>>>>>>> I need help from all committers in automatically
> >>>>>> merging in any patch that fits the above criterion into 2.7.2
> instead of
> >>>>>> only on trunk or 2.8.
> >>>>>>
> >>>>>> Sure, I'll try my best.
> >>>>>>
> >>>>>>> That way we can include not only blocker but also critical bug
> fixes to
> >>>>>>> 2.7.2 release.
> >>>>>>
> >>>>>> As Vinod mentioned, we should also apply major bug fixes into
> >>>> branch-2.7.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> - Tsuyoshi
> >>>>>>
> >>>>>> On Thu, Jul 16, 2015 at 3:52 PM, Akira AJISAKA
> >>>>>> <ajisakaa@oss.nttdata.co.jp <javascript:;>> wrote:
> >>>
> >>>
> >>>>>>> Thanks Vinod for starting 2.7.2 release plan.
> >>>>>>>
> >>>>>>>> The focus obviously is to have blocker issues [2], bug-fixes and
> *no*
> >>>>>>>> features / improvements.
> >>>>>>>
> >>>>>>> Can we adopt the plan as Karthik mentioned in "Additional
> maintenance
> >>>>>>> releases for Hadoop 2.y versions" thread? That way we can include
> not
> >>>>>>> only
> >>>>>>> blocker but also critical bug fixes to 2.7.2 release.
> >>>>>>>
> >>>>>>> In addition, branch-2.7 is a special case. (2.7.1 is the first
> stable
> >>>>>>> release) Therefore I'm thinking we can include major bug fixes as
> well.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Akira
> >>>>>>>
> >>>>>>>
> >>>>>>> On 7/16/15 04:13, Vinod Kumar Vavilapalli wrote:
> >>>>>>>>
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks everyone for the push on 2.7.1! Branch-2.7 is now open fo=
r
> >>>>>>>> commits
> >>>>>>>> to a 2.7.2 release. JIRA also now has a 2.7.2 version for all th=
e
> >>>>>>>> sub-projects.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Continuing the previous 2.7.1 thread on steady maintenance
> releases
> >>>>>>>> [1],
> >>>>>>>> we
> >>>>>>>> should follow up 2.7.1 with a 2.7.2 within 4 weeks. Earlier I
> tried a
> >>>>>>>> 2-3
> >>>>>>>> week cycle for 2.7.1, but it seems to be impractical given the
> >>>>>>>> community
> >>>>>>>> size. So, I propose we target a release by the end for 4 weeks
> from
> >>>>>>>> now,
> >>>>>>>> starting the release close-down within 2-3 weeks.
> >>>>>>>>
> >>>>>>>> The focus obviously is to have blocker issues [2], bug-fixes and
> *no*
> >>>>>>>> features / improvements. I need help from all committers in
> >>>>>>>> automatically
> >>>>>>>> merging in any patch that fits the above criterion into 2.7.2
> instead
> >>>>>>>> of
> >>>>>>>> only on trunk or 2.8.
> >>>>>>>>
> >>>>>>>> Thoughts?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> +Vinod
> >>>>>>>>
> >>>>>>>> [1] A 2.7.1 release to follow up 2.7.0
> >>>>>>>> http://markmail.org/message/zwzze6cqqgwq4rmw
> >>>>>>>>
> >>>>>>>> [2] 2.7.2 release blockers:
> >>>>>>>> https://issues.apache.org/jira/issues/?filter=3D12332867
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
>

--001a114e4ab43b53c0052331cc1c--