I see you already put in both HDFS-8950 and HDFS-7725, so we are good there.
Can you please do a pass on HDFS-8871 and may be help nudge Daryn on HDFS-8893, HDFS-8674 and HDFS-8498? Thanks +Vinod > On Oct 27, 2015, at 8:12 AM, Kihwal Lee <kih...@yahoo-inc.com.INVALID> wrote: > > 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 can > chime in. > Kihwal > > From: Tsuyoshi Ozawa <oz...@apache.org> > To: "common-...@hadoop.apache.org" <common-...@hadoop.apache.org> > Cc: Chris Nauroth <cnaur...@hortonworks.com>; "yarn-...@hadoop.apache.org" > <yarn-...@hadoop.apache.org>; "hdfs-dev@hadoop.apache.org" > <hdfs-dev@hadoop.apache.org>; "mapreduce-...@hadoop.apache.org" > <mapreduce-...@hadoop.apache.org>; Vinod Kumar Vavilapalli > <vino...@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 lot. > > Best, > - Tsuyoshi > > On Tuesday, 27 October 2015, Vinod Vavilapalli <vino...@hortonworks.com> > wrote: > >> +1. >> >> Thanks >> +Vinod >> >>> On Jul 16, 2015, at 8:18 AM, Chris Nauroth <cnaur...@hortonworks.com >> <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" <oz...@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 be >>>> 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 >>>> <ajisa...@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 for >>>>>> commits >>>>>> to a 2.7.2 release. JIRA also now has a 2.7.2 version for all the >>>>>> 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=12332867 >>>>>> >>>>> >>>> >>> >>> >> >> > >
