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> 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> 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 >>> >> >
