Re: About 2.7.4 Release
Okay. If you file a jira and attach a patch, I'll review it. -Akira On 2017/04/25 22:15, Brahma Reddy Battula wrote: Looks Following Jira's are not updated in CHANGES.txt HADOOP-14066,HDFS-11608,HADOOP-14293,HDFS-11628,YARN-6274,YARN-6152,HADOOP-13119,HDFS-10733,HADOOP-13958,HDFS-11280,YARN-6024. May be we can raise one Jira to track this..? --Brahma Reddy Battula -Original Message- From: Akira Ajisaka [mailto:aajis...@apache.org] Sent: 25 April 2017 15:36 To: Haohui Mai Cc: Brahma Reddy Battula; Andrew Wang; Sangjin Lee; Vinod Kumar Vavilapalli; Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-...@hadoop.apache.org Subject: Re: About 2.7.4 Release > It would be great to backport HDFS-9710 to 2.7.4 as this is one of the > critical fixes on scalability. Sounds good. > Maybe we should create a jira to track this? I think now either way (reopen or create) is fine. Release doc maker creates change logs by fetching information from JIRA, so reopening the tickets should be avoided when a release process is in progress. The issue HDFS-9710 (and HDFS-9726) have been fixed in 2.8.0 and 3.0.0-alpha1 and both versions have been released, so reopening this issue does not affect the release doc maker. -Akira On 2017/04/25 16:21, Haohui Mai wrote: It would be great to backport HDFS-9710 to 2.7.4 as this is one of the critical fixes on scalability. Maybe we should create a jira to track this? ~Haohui On Tue, Apr 25, 2017 at 12:06 AM, Akira Ajisaka wrote: Ping I too can help with the release process. Now there are 0 blocker and 6 critical issues targeted for 2.7.4. https://s.apache.org/HsIu If there are critical/blocker issues that need to be fixed in branch-2.7, please set Target Version/s to 2.7.4. That way the issues can be found by the above query. I'll check if there are conflicts among JIRA, git commit log, and the change logs. Regards, Akira On 2017/04/18 15:40, Brahma Reddy Battula wrote: Hi All Any update on 2.7.4 ..? Gentle Remainder!! Let me know anything I can help on this.. Regards Brahma Reddy Battula -Original Message- From: Andrew Wang [mailto:andrew.w...@cloudera.com] Sent: 08 March 2017 04:22 To: Sangjin Lee Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-...@hadoop.apache.org Subject: Re: About 2.7.4 Release Our release steps are documented on the wiki: 2.6/2.7: https://wiki.apache.org/hadoop/HowToReleasePreDSBCR 2.8+: https://wiki.apache.org/hadoop/HowToRelease I think given the push toward 2.8 and 3.0, there's less interest in streamlining the 2.6 and 2.7 release processes. CHANGES.txt is the biggest pain, and that's fixed in 2.8+. Current pain points for 2.8+ include: # fixing up JIRA versions and the release notes, though I somewhat addressed this with the versions script for 3.x # making and staging an RC and sending the vote email still requires a lot of manual steps # publishing the release is also quite manual I think the RC issues can be attacked with enough scripting. Steve had an ant file that automated a lot of this for slider. I think it'd be nice to have a nightly Jenkins job that builds an RC, since I've spent a day or two for each 3.x alpha fixing build issues. Publishing can be attacked via a mix of scripting and revamping the darned website. Forrest is pretty bad compared to the newer static site generators out there (e.g. need to write XML instead of markdown, it's hard to review a staging site because of all the absolute links, hard to customize, did I mention XML?), and the look and feel of the site is from the 00s. We don't actually have that much site content, so it should be possible to migrate to a new system. On Tue, Mar 7, 2017 at 9:13 AM, Sangjin Lee wrote: I don't think there should be any linkage between releasing 2.8.0 and 2.7.4. If we have a volunteer for releasing 2.7.4, we should go full speed ahead. We still need a volunteer from a PMC member or a committer as some tasks may require certain privileges, but I don't think it precludes working with others to close down the release. I for one would like to see more frequent releases, and being able to automate release steps more would go a long way. On Tue, Mar 7, 2017 at 2:16 AM, Marton Elek wrote: Is there any reason to wait for 2.8 with 2.7.4? Unfortunately the previous thread about release cadence has been ended without final decision. But if I understood well, there was more or less an agreement about that it would be great to achieve more frequent releases, if possible (with or without written rules and EOL policy). I personally prefer to be more closer to the scheduling part of the proposal: "A minor release on the latest major line should be every 6 months, and a maintenance release on a minor release (as there may be concurrently maintained minor releases) every 2 months". I don't know what is the hardest part of creating new minor/maintenance releases. But if the prob
[jira] [Resolved] (YARN-6529) Add JMX metrics for Priority Reservation Agent
[ https://issues.apache.org/jira/browse/YARN-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Po resolved YARN-6529. --- Resolution: Duplicate Duplicate of YARN-6530. > Add JMX metrics for Priority Reservation Agent > -- > > Key: YARN-6529 > URL: https://issues.apache.org/jira/browse/YARN-6529 > Project: Hadoop YARN > Issue Type: Task >Reporter: Sean Po >Assignee: Sean Po > > YARN-5211 proposes adding support for generalized priorities for reservations > in the YARN ReservationSystem. This JIRA is a sub-task to track the changes > needed to gauge the performance of the priority reservation agent. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-6530) Add JMX metrics for Priority Reservation Agent
Sean Po created YARN-6530: - Summary: Add JMX metrics for Priority Reservation Agent Key: YARN-6530 URL: https://issues.apache.org/jira/browse/YARN-6530 Project: Hadoop YARN Issue Type: Sub-task Reporter: Sean Po YARN-5211 proposes adding support for generalized priorities for reservations in the YARN ReservationSystem. This JIRA is a sub-task to track the changes needed to gauge the performance of the priority reservation agent. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-6529) Add JMX metrics for Priority Reservation Agent
Sean Po created YARN-6529: - Summary: Add JMX metrics for Priority Reservation Agent Key: YARN-6529 URL: https://issues.apache.org/jira/browse/YARN-6529 Project: Hadoop YARN Issue Type: Task Reporter: Sean Po Assignee: Sean Po -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-6528) Add JMX metrics for Plan Follower and Agent Placement and Plan Operations
Sean Po created YARN-6528: - Summary: Add JMX metrics for Plan Follower and Agent Placement and Plan Operations Key: YARN-6528 URL: https://issues.apache.org/jira/browse/YARN-6528 Project: Hadoop YARN Issue Type: Task Reporter: Sean Po Assignee: Sean Po -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-6527) Provide a better out-of-the-box experience for SLS
Robert Kanter created YARN-6527: --- Summary: Provide a better out-of-the-box experience for SLS Key: YARN-6527 URL: https://issues.apache.org/jira/browse/YARN-6527 Project: Hadoop YARN Issue Type: Sub-task Components: scheduler-load-simulator Affects Versions: 3.0.0-alpha3 Reporter: Robert Kanter The example provided with SLS appears to be broken - I didn't see any jobs running. On top of that, it seems like getting SLS to run properly requires a lot of hadoop site configs, scheduler configs, etc. I was only able to get something running after [~yufeigu] provided a lot of config files. We should provide a better out-of-the-box experience for SLS. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-6526) Refactoring SQLFederationStateStore by avoiding to recreate the connections at every call
Giovanni Matteo Fumarola created YARN-6526: -- Summary: Refactoring SQLFederationStateStore by avoiding to recreate the connections at every call Key: YARN-6526 URL: https://issues.apache.org/jira/browse/YARN-6526 Project: Hadoop YARN Issue Type: Sub-task Components: federation Reporter: Giovanni Matteo Fumarola -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-6525) Linux container executor should not propagate application errors
Miklos Szegedi created YARN-6525: Summary: Linux container executor should not propagate application errors Key: YARN-6525 URL: https://issues.apache.org/jira/browse/YARN-6525 Project: Hadoop YARN Issue Type: Bug Affects Versions: 3.0.0-alpha2 Reporter: Miklos Szegedi wait_and_get_exit_code currently returns the application error code as LCE error code. This may overlap with LCE errors. Instead LCE should return a fixed application failed error code. I should print the application error into the logs. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Resolved] (YARN-6524) Avoid storing unnecessary information in the Memory for the finished apps
[ https://issues.apache.org/jira/browse/YARN-6524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Lowe resolved YARN-6524. -- Resolution: Duplicate > Avoid storing unnecessary information in the Memory for the finished apps > - > > Key: YARN-6524 > URL: https://issues.apache.org/jira/browse/YARN-6524 > Project: Hadoop YARN > Issue Type: Bug > Components: RM >Affects Versions: 2.7.3 >Reporter: Naganarasimha G R > > Avoid storing unnecessary information in the Memory for the finished apps > In case of cluster with large number of finished apps, more memory is > required to store the unused information i.e. related AM's Container launch > like Localization resources, tokens etc. > In one such scenario we had around 9k finished apps each with 257 > LocalResource amounting to 108 kbytes per app and just for 9k apps it was > nearly taking ~ 0.8 GB of memory. In Low end machines this would create > resource crunch in RM -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
RE: About 2.7.4 Release
Looks Following Jira's are not updated in CHANGES.txt HADOOP-14066,HDFS-11608,HADOOP-14293,HDFS-11628,YARN-6274,YARN-6152,HADOOP-13119,HDFS-10733,HADOOP-13958,HDFS-11280,YARN-6024. May be we can raise one Jira to track this..? --Brahma Reddy Battula -Original Message- From: Akira Ajisaka [mailto:aajis...@apache.org] Sent: 25 April 2017 15:36 To: Haohui Mai Cc: Brahma Reddy Battula; Andrew Wang; Sangjin Lee; Vinod Kumar Vavilapalli; Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-...@hadoop.apache.org Subject: Re: About 2.7.4 Release > It would be great to backport HDFS-9710 to 2.7.4 as this is one of the > > critical fixes on scalability. Sounds good. > Maybe we should create a jira to track this? I think now either way (reopen or create) is fine. Release doc maker creates change logs by fetching information from JIRA, so reopening the tickets should be avoided when a release process is in progress. The issue HDFS-9710 (and HDFS-9726) have been fixed in 2.8.0 and 3.0.0-alpha1 and both versions have been released, so reopening this issue does not affect the release doc maker. -Akira On 2017/04/25 16:21, Haohui Mai wrote: > It would be great to backport HDFS-9710 to 2.7.4 as this is one of the > critical fixes on scalability. Maybe we should create a jira to track > this? > > ~Haohui > > On Tue, Apr 25, 2017 at 12:06 AM, Akira Ajisaka wrote: >> Ping >> >> I too can help with the release process. >> >> Now there are 0 blocker and 6 critical issues targeted for 2.7.4. >> https://s.apache.org/HsIu >> >> If there are critical/blocker issues that need to be fixed in >> branch-2.7, please set Target Version/s to 2.7.4. That way the issues >> can be found by the above query. >> >> I'll check if there are conflicts among JIRA, git commit log, and the >> change logs. >> >> Regards, >> Akira >> >> >> On 2017/04/18 15:40, Brahma Reddy Battula wrote: >>> >>> Hi All >>> >>> Any update on 2.7.4 ..? Gentle Remainder!! Let me know anything I >>> can help on this.. >>> >>> >>> >>> Regards >>> Brahma Reddy Battula >>> >>> -Original Message- >>> From: Andrew Wang [mailto:andrew.w...@cloudera.com] >>> Sent: 08 March 2017 04:22 >>> To: Sangjin Lee >>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; >>> Hdfs-dev; mapreduce-...@hadoop.apache.org >>> Subject: Re: About 2.7.4 Release >>> >>> Our release steps are documented on the wiki: >>> >>> 2.6/2.7: >>> >>> https://wiki.apache.org/hadoop/HowToReleasePreDSBCR >>> >>> 2.8+: >>> https://wiki.apache.org/hadoop/HowToRelease >>> >>> I think given the push toward 2.8 and 3.0, there's less interest in >>> streamlining the 2.6 and 2.7 release processes. CHANGES.txt is the >>> biggest pain, and that's fixed in 2.8+. >>> >>> Current pain points for 2.8+ include: >>> >>> # fixing up JIRA versions and the release notes, though I somewhat >>> addressed this with the versions script for 3.x # making and staging >>> an RC and sending the vote email still requires a lot of manual >>> steps # publishing the release is also quite manual >>> >>> I think the RC issues can be attacked with enough scripting. Steve >>> had an ant file that automated a lot of this for slider. I think >>> it'd be nice to have a nightly Jenkins job that builds an RC, since >>> I've spent a day or two for each 3.x alpha fixing build issues. >>> >>> Publishing can be attacked via a mix of scripting and revamping the >>> darned website. Forrest is pretty bad compared to the newer static >>> site generators out there (e.g. need to write XML instead of >>> markdown, it's hard to review a staging site because of all the >>> absolute links, hard to customize, did I mention XML?), and the look >>> and feel of the site is from the 00s. We don't actually have that >>> much site content, so it should be possible to migrate to a new system. >>> >>> On Tue, Mar 7, 2017 at 9:13 AM, Sangjin Lee wrote: >>> I don't think there should be any linkage between releasing 2.8.0 and 2.7.4. If we have a volunteer for releasing 2.7.4, we should go full speed ahead. We still need a volunteer from a PMC member or a committer as some tasks may require certain privileges, but I don't think it precludes working with others to close down the release. I for one would like to see more frequent releases, and being able to automate release steps more would go a long way. On Tue, Mar 7, 2017 at 2:16 AM, Marton Elek wrote: > Is there any reason to wait for 2.8 with 2.7.4? > > Unfortunately the previous thread about release cadence has been > ended without final decision. But if I understood well, there was > more or less an > > agreement about that it would be great to achieve more frequent > releases, if possible (with or without written rules and EOL policy). > > I personally prefer to be more closer to the scheduling part of > the
RE: Pre-commit Build is failing
Ok.thanks Ted Yu. -Original Message- From: Ted Yu [mailto:yuzhih...@gmail.com] Sent: 25 April 2017 20:33 To: Brahma Reddy Battula Cc: Hadoop Common; Hdfs-dev; yarn-dev@hadoop.apache.org Subject: Re: Pre-commit Build is failing Please see: INFRA-13985 > On Apr 25, 2017, at 5:18 AM, Brahma Reddy Battula > wrote: > > Hi All > > > Pre-commit build for all the project is failing with following error, any > idea on this..? > > > > > HEAD is now at 2ba21d6 YARN-6392. Add submit time to Application Summary log. > (Zhihai Xu via wangda) > > Already on 'trunk' > > Your branch is up-to-date with 'origin/trunk'. > > fatal: unable to access > 'https://git-wip-us.apache.org/repos/asf/hadoop.git/': server certificate > verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none > > ERROR: git pull is failing > > > > > > References: > > https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HADOOP-Build/12178/console > > https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/19194/console > > https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-YARN-Build/15733/console > > > > > Regards > Brahma Reddy Battula > - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
Re: Pre-commit Build is failing
Please see: INFRA-13985 > On Apr 25, 2017, at 5:18 AM, Brahma Reddy Battula > wrote: > > Hi All > > > Pre-commit build for all the project is failing with following error, any > idea on this..? > > > > > HEAD is now at 2ba21d6 YARN-6392. Add submit time to Application Summary log. > (Zhihai Xu via wangda) > > Already on 'trunk' > > Your branch is up-to-date with 'origin/trunk'. > > fatal: unable to access > 'https://git-wip-us.apache.org/repos/asf/hadoop.git/': server certificate > verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none > > ERROR: git pull is failing > > > > > > References: > > https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HADOOP-Build/12178/console > > https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/19194/console > > https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-YARN-Build/15733/console > > > > > Regards > Brahma Reddy Battula > - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
Pre-commit Build is failing
Hi All Pre-commit build for all the project is failing with following error, any idea on this..? HEAD is now at 2ba21d6 YARN-6392. Add submit time to Application Summary log. (Zhihai Xu via wangda) Already on 'trunk' Your branch is up-to-date with 'origin/trunk'. fatal: unable to access 'https://git-wip-us.apache.org/repos/asf/hadoop.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none ERROR: git pull is failing References: https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HADOOP-Build/12178/console https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/19194/console https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-YARN-Build/15733/console Regards Brahma Reddy Battula
Re: About 2.7.4 Release
> It would be great to backport HDFS-9710 to 2.7.4 as this is one of the > critical fixes on scalability. Sounds good. > Maybe we should create a jira to track this? I think now either way (reopen or create) is fine. Release doc maker creates change logs by fetching information from JIRA, so reopening the tickets should be avoided when a release process is in progress. The issue HDFS-9710 (and HDFS-9726) have been fixed in 2.8.0 and 3.0.0-alpha1 and both versions have been released, so reopening this issue does not affect the release doc maker. -Akira On 2017/04/25 16:21, Haohui Mai wrote: It would be great to backport HDFS-9710 to 2.7.4 as this is one of the critical fixes on scalability. Maybe we should create a jira to track this? ~Haohui On Tue, Apr 25, 2017 at 12:06 AM, Akira Ajisaka wrote: Ping I too can help with the release process. Now there are 0 blocker and 6 critical issues targeted for 2.7.4. https://s.apache.org/HsIu If there are critical/blocker issues that need to be fixed in branch-2.7, please set Target Version/s to 2.7.4. That way the issues can be found by the above query. I'll check if there are conflicts among JIRA, git commit log, and the change logs. Regards, Akira On 2017/04/18 15:40, Brahma Reddy Battula wrote: Hi All Any update on 2.7.4 ..? Gentle Remainder!! Let me know anything I can help on this.. Regards Brahma Reddy Battula -Original Message- From: Andrew Wang [mailto:andrew.w...@cloudera.com] Sent: 08 March 2017 04:22 To: Sangjin Lee Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-...@hadoop.apache.org Subject: Re: About 2.7.4 Release Our release steps are documented on the wiki: 2.6/2.7: https://wiki.apache.org/hadoop/HowToReleasePreDSBCR 2.8+: https://wiki.apache.org/hadoop/HowToRelease I think given the push toward 2.8 and 3.0, there's less interest in streamlining the 2.6 and 2.7 release processes. CHANGES.txt is the biggest pain, and that's fixed in 2.8+. Current pain points for 2.8+ include: # fixing up JIRA versions and the release notes, though I somewhat addressed this with the versions script for 3.x # making and staging an RC and sending the vote email still requires a lot of manual steps # publishing the release is also quite manual I think the RC issues can be attacked with enough scripting. Steve had an ant file that automated a lot of this for slider. I think it'd be nice to have a nightly Jenkins job that builds an RC, since I've spent a day or two for each 3.x alpha fixing build issues. Publishing can be attacked via a mix of scripting and revamping the darned website. Forrest is pretty bad compared to the newer static site generators out there (e.g. need to write XML instead of markdown, it's hard to review a staging site because of all the absolute links, hard to customize, did I mention XML?), and the look and feel of the site is from the 00s. We don't actually have that much site content, so it should be possible to migrate to a new system. On Tue, Mar 7, 2017 at 9:13 AM, Sangjin Lee wrote: I don't think there should be any linkage between releasing 2.8.0 and 2.7.4. If we have a volunteer for releasing 2.7.4, we should go full speed ahead. We still need a volunteer from a PMC member or a committer as some tasks may require certain privileges, but I don't think it precludes working with others to close down the release. I for one would like to see more frequent releases, and being able to automate release steps more would go a long way. On Tue, Mar 7, 2017 at 2:16 AM, Marton Elek wrote: Is there any reason to wait for 2.8 with 2.7.4? Unfortunately the previous thread about release cadence has been ended without final decision. But if I understood well, there was more or less an agreement about that it would be great to achieve more frequent releases, if possible (with or without written rules and EOL policy). I personally prefer to be more closer to the scheduling part of the proposal: "A minor release on the latest major line should be every 6 months, and a maintenance release on a minor release (as there may be concurrently maintained minor releases) every 2 months". I don't know what is the hardest part of creating new minor/maintenance releases. But if the problems are technical (smoketesting, unit tests, old release script, anything else) I would be happy to do any task for new maintenance releases (or more frequent releases). Regards, Marton From: Akira Ajisaka Sent: Tuesday, March 07, 2017 7:34 AM To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-...@hadoop.apache.org Subject: Re: About 2.7.4 Release Probably 2.8.0 will be released soon. https://issues.apache.org/jira/browse/HADOOP-13866? focusedCommentId=15898379&page=com.atlassian.jira. plugin.system.issuetabpanels:comment-tabpanel#comment-15898379 I'm thinking 2.7.4 release process starts after 2.8.0 releas
Re: About 2.7.4 Release
It would be great to backport HDFS-9710 to 2.7.4 as this is one of the critical fixes on scalability. Maybe we should create a jira to track this? ~Haohui On Tue, Apr 25, 2017 at 12:06 AM, Akira Ajisaka wrote: > Ping > > I too can help with the release process. > > Now there are 0 blocker and 6 critical issues targeted for 2.7.4. > https://s.apache.org/HsIu > > If there are critical/blocker issues that need to be fixed in branch-2.7, > please set Target Version/s to 2.7.4. That way the issues can be found by > the above query. > > I'll check if there are conflicts among JIRA, git commit log, and the change > logs. > > Regards, > Akira > > > On 2017/04/18 15:40, Brahma Reddy Battula wrote: >> >> Hi All >> >> Any update on 2.7.4 ..? Gentle Remainder!! Let me know anything I can >> help on this.. >> >> >> >> Regards >> Brahma Reddy Battula >> >> -Original Message- >> From: Andrew Wang [mailto:andrew.w...@cloudera.com] >> Sent: 08 March 2017 04:22 >> To: Sangjin Lee >> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; >> mapreduce-...@hadoop.apache.org >> Subject: Re: About 2.7.4 Release >> >> Our release steps are documented on the wiki: >> >> 2.6/2.7: >> >> https://wiki.apache.org/hadoop/HowToReleasePreDSBCR >> >> 2.8+: >> https://wiki.apache.org/hadoop/HowToRelease >> >> I think given the push toward 2.8 and 3.0, there's less interest in >> streamlining the 2.6 and 2.7 release processes. CHANGES.txt is the biggest >> pain, and that's fixed in 2.8+. >> >> Current pain points for 2.8+ include: >> >> # fixing up JIRA versions and the release notes, though I somewhat >> addressed this with the versions script for 3.x # making and staging an RC >> and sending the vote email still requires a lot of manual steps # publishing >> the release is also quite manual >> >> I think the RC issues can be attacked with enough scripting. Steve had an >> ant file that automated a lot of this for slider. I think it'd be nice to >> have a nightly Jenkins job that builds an RC, since I've spent a day or two >> for each 3.x alpha fixing build issues. >> >> Publishing can be attacked via a mix of scripting and revamping the darned >> website. Forrest is pretty bad compared to the newer static site generators >> out there (e.g. need to write XML instead of markdown, it's hard to review a >> staging site because of all the absolute links, hard to customize, did I >> mention XML?), and the look and feel of the site is from the 00s. We don't >> actually have that much site content, so it should be possible to migrate to >> a new system. >> >> On Tue, Mar 7, 2017 at 9:13 AM, Sangjin Lee wrote: >> >>> I don't think there should be any linkage between releasing 2.8.0 and >>> 2.7.4. If we have a volunteer for releasing 2.7.4, we should go full >>> speed ahead. We still need a volunteer from a PMC member or a >>> committer as some tasks may require certain privileges, but I don't >>> think it precludes working with others to close down the release. >>> >>> I for one would like to see more frequent releases, and being able to >>> automate release steps more would go a long way. >>> >>> On Tue, Mar 7, 2017 at 2:16 AM, Marton Elek >>> wrote: >>> Is there any reason to wait for 2.8 with 2.7.4? Unfortunately the previous thread about release cadence has been ended without final decision. But if I understood well, there was more or less >>> >>> an agreement about that it would be great to achieve more frequent releases, if possible (with or without written rules and EOL policy). I personally prefer to be more closer to the scheduling part of the proposal: "A minor release on the latest major line should be every 6 months, and a maintenance release on a minor release (as there may be concurrently maintained minor releases) every 2 months". I don't know what is the hardest part of creating new minor/maintenance releases. But if the problems are technical (smoketesting, unit tests, >>> >>> old release script, anything else) I would be happy to do any task for new maintenance releases (or more frequent releases). Regards, Marton From: Akira Ajisaka Sent: Tuesday, March 07, 2017 7:34 AM To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-...@hadoop.apache.org Subject: Re: About 2.7.4 Release Probably 2.8.0 will be released soon. https://issues.apache.org/jira/browse/HADOOP-13866? focusedCommentId=15898379&page=com.atlassian.jira. plugin.system.issuetabpanels:comment-tabpanel#comment-15898379 I'm thinking 2.7.4 release process starts after 2.8.0 release, so 2.7.4 will be released in April or May. (hopefully) Thoughts? Regards, Akira On 2017/03/01 21:01, Brahma Reddy Battula wrote: > > Hi All >
Re: About 2.7.4 Release
Ping I too can help with the release process. Now there are 0 blocker and 6 critical issues targeted for 2.7.4. https://s.apache.org/HsIu If there are critical/blocker issues that need to be fixed in branch-2.7, please set Target Version/s to 2.7.4. That way the issues can be found by the above query. I'll check if there are conflicts among JIRA, git commit log, and the change logs. Regards, Akira On 2017/04/18 15:40, Brahma Reddy Battula wrote: Hi All Any update on 2.7.4 ..? Gentle Remainder!! Let me know anything I can help on this.. Regards Brahma Reddy Battula -Original Message- From: Andrew Wang [mailto:andrew.w...@cloudera.com] Sent: 08 March 2017 04:22 To: Sangjin Lee Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-...@hadoop.apache.org Subject: Re: About 2.7.4 Release Our release steps are documented on the wiki: 2.6/2.7: https://wiki.apache.org/hadoop/HowToReleasePreDSBCR 2.8+: https://wiki.apache.org/hadoop/HowToRelease I think given the push toward 2.8 and 3.0, there's less interest in streamlining the 2.6 and 2.7 release processes. CHANGES.txt is the biggest pain, and that's fixed in 2.8+. Current pain points for 2.8+ include: # fixing up JIRA versions and the release notes, though I somewhat addressed this with the versions script for 3.x # making and staging an RC and sending the vote email still requires a lot of manual steps # publishing the release is also quite manual I think the RC issues can be attacked with enough scripting. Steve had an ant file that automated a lot of this for slider. I think it'd be nice to have a nightly Jenkins job that builds an RC, since I've spent a day or two for each 3.x alpha fixing build issues. Publishing can be attacked via a mix of scripting and revamping the darned website. Forrest is pretty bad compared to the newer static site generators out there (e.g. need to write XML instead of markdown, it's hard to review a staging site because of all the absolute links, hard to customize, did I mention XML?), and the look and feel of the site is from the 00s. We don't actually have that much site content, so it should be possible to migrate to a new system. On Tue, Mar 7, 2017 at 9:13 AM, Sangjin Lee wrote: I don't think there should be any linkage between releasing 2.8.0 and 2.7.4. If we have a volunteer for releasing 2.7.4, we should go full speed ahead. We still need a volunteer from a PMC member or a committer as some tasks may require certain privileges, but I don't think it precludes working with others to close down the release. I for one would like to see more frequent releases, and being able to automate release steps more would go a long way. On Tue, Mar 7, 2017 at 2:16 AM, Marton Elek wrote: Is there any reason to wait for 2.8 with 2.7.4? Unfortunately the previous thread about release cadence has been ended without final decision. But if I understood well, there was more or less an agreement about that it would be great to achieve more frequent releases, if possible (with or without written rules and EOL policy). I personally prefer to be more closer to the scheduling part of the proposal: "A minor release on the latest major line should be every 6 months, and a maintenance release on a minor release (as there may be concurrently maintained minor releases) every 2 months". I don't know what is the hardest part of creating new minor/maintenance releases. But if the problems are technical (smoketesting, unit tests, old release script, anything else) I would be happy to do any task for new maintenance releases (or more frequent releases). Regards, Marton From: Akira Ajisaka Sent: Tuesday, March 07, 2017 7:34 AM To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-...@hadoop.apache.org Subject: Re: About 2.7.4 Release Probably 2.8.0 will be released soon. https://issues.apache.org/jira/browse/HADOOP-13866? focusedCommentId=15898379&page=com.atlassian.jira. plugin.system.issuetabpanels:comment-tabpanel#comment-15898379 I'm thinking 2.7.4 release process starts after 2.8.0 release, so 2.7.4 will be released in April or May. (hopefully) Thoughts? Regards, Akira On 2017/03/01 21:01, Brahma Reddy Battula wrote: Hi All It has been six months for branch-2.7 release.. is there any near plan for 2.7.4..? Thanks&Regards Brahma Reddy Battula - To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apa
