You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-dev@hadoop.apache.org by Brahma Reddy Battula <br...@huawei.com> on 2017/03/01 12:01:48 UTC
About 2.7.4 Release
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
Re: About 2.7.4 Release
Posted by Marton Elek <me...@hortonworks.com>.
Thank you very much for your feedback. I am opening the following JIRAs:
1. Create dev-support scripts to do the bulk jira updates required by the releases (check remaining jiras, update fix versions, etc.)
2. Create a 'wizzard' like script which guide through the release process (all the steps from the wiki pages, not just a build. But it may be an extension of the existing script):
Goals:
* It would work even without the apache infrastructure: with custom configuration (forked repositories/alternative nexus), it would be possible to test the scripts even by a non-commiter.
* every step which could be automated should be scripted (create git branches, build,...). if something could be not automated there an explanation could be printed out, and wait for confirmation
* Before dangerous steps (eg. bulk jira update) we can ask for confirmation and explain what will be happened (eg. the following jira items will be changed: ....)
* The run should be idempontent (and there should be an option to continue the release from any steps).
3. Migrate the forrest based home page to a use a modern static site generator.
Goals: * existing links should work (or at least redirected)
* It should be easy to add more content required by a release automatically
4. It's not about the release, but I think the current maven site theme also could be updated to use a (more modern) theme, which could be similar to the main site from step 3.
Let me know if you have any other suggestion for actionable items. Or comment the Jiras if you have more specific requirements.
Marton
ps: Vinod, I will contact with you, soon.
________________________________________
From: Vinod Kumar Vavilapalli <vi...@apache.org>
Sent: Tuesday, March 07, 2017 11:58 PM
To: Sangjin Lee
Cc: Marton Elek; common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@hadoop.apache.org
Subject: Re: About 2.7.4 Release
I was planning to take this up, celebrating my return from my paternity leave of absence for quite a while.
Marton, let me know if you do want to take this up instead and we can work together.
Thanks
+Vinod
> On Mar 7, 2017, at 9:13 AM, Sangjin Lee <sj...@apache.org> wrote:
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Marton Elek <me...@hortonworks.com>.
Thank you very much for your feedback. I am opening the following JIRAs:
1. Create dev-support scripts to do the bulk jira updates required by the releases (check remaining jiras, update fix versions, etc.)
2. Create a 'wizzard' like script which guide through the release process (all the steps from the wiki pages, not just a build. But it may be an extension of the existing script):
Goals:
* It would work even without the apache infrastructure: with custom configuration (forked repositories/alternative nexus), it would be possible to test the scripts even by a non-commiter.
* every step which could be automated should be scripted (create git branches, build,...). if something could be not automated there an explanation could be printed out, and wait for confirmation
* Before dangerous steps (eg. bulk jira update) we can ask for confirmation and explain what will be happened (eg. the following jira items will be changed: ....)
* The run should be idempontent (and there should be an option to continue the release from any steps).
3. Migrate the forrest based home page to a use a modern static site generator.
Goals: * existing links should work (or at least redirected)
* It should be easy to add more content required by a release automatically
4. It's not about the release, but I think the current maven site theme also could be updated to use a (more modern) theme, which could be similar to the main site from step 3.
Let me know if you have any other suggestion for actionable items. Or comment the Jiras if you have more specific requirements.
Marton
ps: Vinod, I will contact with you, soon.
________________________________________
From: Vinod Kumar Vavilapalli <vi...@apache.org>
Sent: Tuesday, March 07, 2017 11:58 PM
To: Sangjin Lee
Cc: Marton Elek; common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@hadoop.apache.org
Subject: Re: About 2.7.4 Release
I was planning to take this up, celebrating my return from my paternity leave of absence for quite a while.
Marton, let me know if you do want to take this up instead and we can work together.
Thanks
+Vinod
> On Mar 7, 2017, at 9:13 AM, Sangjin Lee <sj...@apache.org> wrote:
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Marton Elek <me...@hortonworks.com>.
Thank you very much for your feedback. I am opening the following JIRAs:
1. Create dev-support scripts to do the bulk jira updates required by the releases (check remaining jiras, update fix versions, etc.)
2. Create a 'wizzard' like script which guide through the release process (all the steps from the wiki pages, not just a build. But it may be an extension of the existing script):
Goals:
* It would work even without the apache infrastructure: with custom configuration (forked repositories/alternative nexus), it would be possible to test the scripts even by a non-commiter.
* every step which could be automated should be scripted (create git branches, build,...). if something could be not automated there an explanation could be printed out, and wait for confirmation
* Before dangerous steps (eg. bulk jira update) we can ask for confirmation and explain what will be happened (eg. the following jira items will be changed: ....)
* The run should be idempontent (and there should be an option to continue the release from any steps).
3. Migrate the forrest based home page to a use a modern static site generator.
Goals: * existing links should work (or at least redirected)
* It should be easy to add more content required by a release automatically
4. It's not about the release, but I think the current maven site theme also could be updated to use a (more modern) theme, which could be similar to the main site from step 3.
Let me know if you have any other suggestion for actionable items. Or comment the Jiras if you have more specific requirements.
Marton
ps: Vinod, I will contact with you, soon.
________________________________________
From: Vinod Kumar Vavilapalli <vi...@apache.org>
Sent: Tuesday, March 07, 2017 11:58 PM
To: Sangjin Lee
Cc: Marton Elek; common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@hadoop.apache.org
Subject: Re: About 2.7.4 Release
I was planning to take this up, celebrating my return from my paternity leave of absence for quite a while.
Marton, let me know if you do want to take this up instead and we can work together.
Thanks
+Vinod
> On Mar 7, 2017, at 9:13 AM, Sangjin Lee <sj...@apache.org> wrote:
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
I was planning to take this up, celebrating my return from my paternity leave of absence for quite a while.
Marton, let me know if you do want to take this up instead and we can work together.
Thanks
+Vinod
> On Mar 7, 2017, at 9:13 AM, Sangjin Lee <sj...@apache.org> wrote:
>
> 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.
Re: About 2.7.4 Release
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
I was planning to take this up, celebrating my return from my paternity leave of absence for quite a while.
Marton, let me know if you do want to take this up instead and we can work together.
Thanks
+Vinod
> On Mar 7, 2017, at 9:13 AM, Sangjin Lee <sj...@apache.org> wrote:
>
> 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.
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 8, 2017, at 1:54 PM, Allen Wittenauer <aw...@effectivemachines.com> wrote:
>
> This is already possible:
> * don’t use —asfrelease
> * use —sign, —native, and, if appropriate for your platform, —docker and —dockercache
Oh yeah, I forgot about this:
https://effectivemachines.com/2016/08/16/building-your-own-apache-hadoop-distribution/
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 8, 2017, at 1:54 PM, Allen Wittenauer <aw...@effectivemachines.com> wrote:
>
> This is already possible:
> * don’t use —asfrelease
> * use —sign, —native, and, if appropriate for your platform, —docker and —dockercache
Oh yeah, I forgot about this:
https://effectivemachines.com/2016/08/16/building-your-own-apache-hadoop-distribution/
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 8, 2017, at 1:54 PM, Allen Wittenauer <aw...@effectivemachines.com> wrote:
>
> This is already possible:
> * don’t use —asfrelease
> * use —sign, —native, and, if appropriate for your platform, —docker and —dockercache
Oh yeah, I forgot about this:
https://effectivemachines.com/2016/08/16/building-your-own-apache-hadoop-distribution/
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 8, 2017, at 1:54 PM, Allen Wittenauer <aw...@effectivemachines.com> wrote:
>
> This is already possible:
> * don’t use —asfrelease
> * use —sign, —native, and, if appropriate for your platform, —docker and —dockercache
Oh yeah, I forgot about this:
https://effectivemachines.com/2016/08/16/building-your-own-apache-hadoop-distribution/
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 8, 2017, at 10:55 AM, Marton Elek <me...@hortonworks.com> wrote:
>
> I think the main point here is the testing of the release script, not the creation of the official release.
… except the Hadoop PMC was doing exactly this from 2.3.0 up until recently. Which means we have a few years worth of releases that are effectively untrustworthy despite being signed. One of the (many) reasons I rewrote the release process was to get Hadoop back in line with ASF policy. Given the massive turn over in committers, I don’t want us to repeat the same mistakes (like we usually do).
> I think there should be an option to configure the release tool to use a forked github repo and/or a private playground nexus instead of official apache repos. In this case it would be easy to test regularly the tool, even by a non-committer (or even from Jenkins). But it would be just a smoketest of the release script…
This is already possible:
* don’t use —asfrelease
* use —sign, —native, and, if appropriate for your platform, —docker and —dockercache
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 8, 2017, at 10:55 AM, Marton Elek <me...@hortonworks.com> wrote:
>
> I think the main point here is the testing of the release script, not the creation of the official release.
… except the Hadoop PMC was doing exactly this from 2.3.0 up until recently. Which means we have a few years worth of releases that are effectively untrustworthy despite being signed. One of the (many) reasons I rewrote the release process was to get Hadoop back in line with ASF policy. Given the massive turn over in committers, I don’t want us to repeat the same mistakes (like we usually do).
> I think there should be an option to configure the release tool to use a forked github repo and/or a private playground nexus instead of official apache repos. In this case it would be easy to test regularly the tool, even by a non-committer (or even from Jenkins). But it would be just a smoketest of the release script…
This is already possible:
* don’t use —asfrelease
* use —sign, —native, and, if appropriate for your platform, —docker and —dockercache
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 8, 2017, at 10:55 AM, Marton Elek <me...@hortonworks.com> wrote:
>
> I think the main point here is the testing of the release script, not the creation of the official release.
… except the Hadoop PMC was doing exactly this from 2.3.0 up until recently. Which means we have a few years worth of releases that are effectively untrustworthy despite being signed. One of the (many) reasons I rewrote the release process was to get Hadoop back in line with ASF policy. Given the massive turn over in committers, I don’t want us to repeat the same mistakes (like we usually do).
> I think there should be an option to configure the release tool to use a forked github repo and/or a private playground nexus instead of official apache repos. In this case it would be easy to test regularly the tool, even by a non-committer (or even from Jenkins). But it would be just a smoketest of the release script…
This is already possible:
* don’t use —asfrelease
* use —sign, —native, and, if appropriate for your platform, —docker and —dockercache
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 8, 2017, at 10:55 AM, Marton Elek <me...@hortonworks.com> wrote:
>
> I think the main point here is the testing of the release script, not the creation of the official release.
… except the Hadoop PMC was doing exactly this from 2.3.0 up until recently. Which means we have a few years worth of releases that are effectively untrustworthy despite being signed. One of the (many) reasons I rewrote the release process was to get Hadoop back in line with ASF policy. Given the massive turn over in committers, I don’t want us to repeat the same mistakes (like we usually do).
> I think there should be an option to configure the release tool to use a forked github repo and/or a private playground nexus instead of official apache repos. In this case it would be easy to test regularly the tool, even by a non-committer (or even from Jenkins). But it would be just a smoketest of the release script…
This is already possible:
* don’t use —asfrelease
* use —sign, —native, and, if appropriate for your platform, —docker and —dockercache
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Marton Elek <me...@hortonworks.com>.
I think the main point here is the testing of the release script, not the creation of the official release.
I think there should be an option to configure the release tool to use a forked github repo and/or a private playground nexus instead of official apache repos. In this case it would be easy to test regularly the tool, even by a non-committer (or even from Jenkins). But it would be just a smoketest of the release script...
Marton
________________________________________
From: Allen Wittenauer <aw...@effectivemachines.com>
Sent: Wednesday, March 08, 2017 2:24 AM
To: Andrew Wang
Cc: Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@hadoop.apache.org
Subject: Re: About 2.7.4 Release
> On Mar 7, 2017, at 2:51 PM, Andrew Wang <an...@cloudera.com> wrote:
> I think it'd be nice to
> have a nightly Jenkins job that builds an RC,
Just a reminder that any such build cannot be used for an actual release:
http://www.apache.org/legal/release-policy.html#owned-controlled-hardware
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-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
Re: About 2.7.4 Release
Posted by Marton Elek <me...@hortonworks.com>.
I think the main point here is the testing of the release script, not the creation of the official release.
I think there should be an option to configure the release tool to use a forked github repo and/or a private playground nexus instead of official apache repos. In this case it would be easy to test regularly the tool, even by a non-committer (or even from Jenkins). But it would be just a smoketest of the release script...
Marton
________________________________________
From: Allen Wittenauer <aw...@effectivemachines.com>
Sent: Wednesday, March 08, 2017 2:24 AM
To: Andrew Wang
Cc: Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@hadoop.apache.org
Subject: Re: About 2.7.4 Release
> On Mar 7, 2017, at 2:51 PM, Andrew Wang <an...@cloudera.com> wrote:
> I think it'd be nice to
> have a nightly Jenkins job that builds an RC,
Just a reminder that any such build cannot be used for an actual release:
http://www.apache.org/legal/release-policy.html#owned-controlled-hardware
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Marton Elek <me...@hortonworks.com>.
I think the main point here is the testing of the release script, not the creation of the official release.
I think there should be an option to configure the release tool to use a forked github repo and/or a private playground nexus instead of official apache repos. In this case it would be easy to test regularly the tool, even by a non-committer (or even from Jenkins). But it would be just a smoketest of the release script...
Marton
________________________________________
From: Allen Wittenauer <aw...@effectivemachines.com>
Sent: Wednesday, March 08, 2017 2:24 AM
To: Andrew Wang
Cc: Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@hadoop.apache.org
Subject: Re: About 2.7.4 Release
> On Mar 7, 2017, at 2:51 PM, Andrew Wang <an...@cloudera.com> wrote:
> I think it'd be nice to
> have a nightly Jenkins job that builds an RC,
Just a reminder that any such build cannot be used for an actual release:
http://www.apache.org/legal/release-policy.html#owned-controlled-hardware
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 7, 2017, at 2:51 PM, Andrew Wang <an...@cloudera.com> wrote:
> I think it'd be nice to
> have a nightly Jenkins job that builds an RC,
Just a reminder that any such build cannot be used for an actual release:
http://www.apache.org/legal/release-policy.html#owned-controlled-hardware
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 7, 2017, at 2:51 PM, Andrew Wang <an...@cloudera.com> wrote:
> I think it'd be nice to
> have a nightly Jenkins job that builds an RC,
Just a reminder that any such build cannot be used for an actual release:
http://www.apache.org/legal/release-policy.html#owned-controlled-hardware
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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:aajisaka@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-dev@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 <aa...@apache.org> 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.wang@cloudera.com]
>>>> Sent: 08 March 2017 04:22
>>>> To: Sangjin Lee
>>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>> Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>>> 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 <aa...@apache.org>
>>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>>> To: Brahma Reddy Battula; Hadoop Common;
>>>>>> yarn-dev@hadoop.apache.org; Hdfs-dev;
>>>>>> mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-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
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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:aajisaka@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-dev@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 <aa...@apache.org> 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.wang@cloudera.com]
>>>> Sent: 08 March 2017 04:22
>>>> To: Sangjin Lee
>>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>> Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>>> 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 <aa...@apache.org>
>>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>>> To: Brahma Reddy Battula; Hadoop Common;
>>>>>> yarn-dev@hadoop.apache.org; Hdfs-dev;
>>>>>> mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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:aajisaka@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-dev@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 <aa...@apache.org> 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.wang@cloudera.com]
>>>> Sent: 08 March 2017 04:22
>>>> To: Sangjin Lee
>>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>> Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>>> 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 <aa...@apache.org>
>>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>>> To: Brahma Reddy Battula; Hadoop Common;
>>>>>> yarn-dev@hadoop.apache.org; Hdfs-dev;
>>>>>> mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-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: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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:aajisaka@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-dev@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 <aa...@apache.org> 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.wang@cloudera.com]
>>>> Sent: 08 March 2017 04:22
>>>> To: Sangjin Lee
>>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>> Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>>> 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 <aa...@apache.org>
>>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>>> To: Brahma Reddy Battula; Hadoop Common;
>>>>>> yarn-dev@hadoop.apache.org; Hdfs-dev;
>>>>>> mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
RE: About 2.7.4 Release
Posted by Brahma Reddy Battula <br...@huawei.com>.
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:aajisaka@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-dev@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 <aa...@apache.org> 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.wang@cloudera.com]
>>> Sent: 08 March 2017 04:22
>>> To: Sangjin Lee
>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org;
>>> Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>> 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 <aa...@apache.org>
>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>> To: Brahma Reddy Battula; Hadoop Common;
>>>>> yarn-dev@hadoop.apache.org; Hdfs-dev;
>>>>> mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
Can we wait for 2.7.4 first? There are still backports happening to
branch-2.7. After that, there shouldn't be many backports since both 2.8.x
and 2.7.x will be up-to-date with what's in 3.0.0-alpha1 and 3.0.0-alpha2.
On Tue, May 2, 2017 at 4:07 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> Is there any reason to not Close -alpha1+resolved state JIRAs? It's been
> quite a while and those definitely should not getting re-opened anymore.
> What about -alpha2's that are also resolved?
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
Can we wait for 2.7.4 first? There are still backports happening to
branch-2.7. After that, there shouldn't be many backports since both 2.8.x
and 2.7.x will be up-to-date with what's in 3.0.0-alpha1 and 3.0.0-alpha2.
On Tue, May 2, 2017 at 4:07 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> Is there any reason to not Close -alpha1+resolved state JIRAs? It's been
> quite a while and those definitely should not getting re-opened anymore.
> What about -alpha2's that are also resolved?
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
Can we wait for 2.7.4 first? There are still backports happening to
branch-2.7. After that, there shouldn't be many backports since both 2.8.x
and 2.7.x will be up-to-date with what's in 3.0.0-alpha1 and 3.0.0-alpha2.
On Tue, May 2, 2017 at 4:07 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> Is there any reason to not Close -alpha1+resolved state JIRAs? It's been
> quite a while and those definitely should not getting re-opened anymore.
> What about -alpha2's that are also resolved?
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
Can we wait for 2.7.4 first? There are still backports happening to
branch-2.7. After that, there shouldn't be many backports since both 2.8.x
and 2.7.x will be up-to-date with what's in 3.0.0-alpha1 and 3.0.0-alpha2.
On Tue, May 2, 2017 at 4:07 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> Is there any reason to not Close -alpha1+resolved state JIRAs? It's been
> quite a while and those definitely should not getting re-opened anymore.
> What about -alpha2's that are also resolved?
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
Is there any reason to not Close -alpha1+resolved state JIRAs? It's been quite a while and those definitely should not getting re-opened anymore. What about -alpha2's that are also resolved?
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
Is there any reason to not Close -alpha1+resolved state JIRAs? It's been quite a while and those definitely should not getting re-opened anymore. What about -alpha2's that are also resolved?
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
Is there any reason to not Close -alpha1+resolved state JIRAs? It's been quite a while and those definitely should not getting re-opened anymore. What about -alpha2's that are also resolved?
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
Is there any reason to not Close -alpha1+resolved state JIRAs? It's been quite a while and those definitely should not getting re-opened anymore. What about -alpha2's that are also resolved?
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
On Mon, May 1, 2017 at 3:44 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I believe I asked about this on dev-yetus a while back. I'd prefer that
> the presence of the fix version be sufficient to indicate whether a JIRA is
> included in a release branch. Yetus requires that the JIRA be resolved as
> "Fixed" to show up, which is why we are in our current situation.
>
> We can't do this because Hadoop is the only one that I've seen
> that sets Fix version at close time. Everyone else is setting fix version
> in place of target (which is a custom field, iirc).
>
> Let's see if I can revive the discussion over on a yetus list/jira. I
think it's easier to add a new flag to Yetus than changing the Hadoop JIRA
workflow, and it seems like this issue is becoming more acute.
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
On Mon, May 1, 2017 at 3:44 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I believe I asked about this on dev-yetus a while back. I'd prefer that
> the presence of the fix version be sufficient to indicate whether a JIRA is
> included in a release branch. Yetus requires that the JIRA be resolved as
> "Fixed" to show up, which is why we are in our current situation.
>
> We can't do this because Hadoop is the only one that I've seen
> that sets Fix version at close time. Everyone else is setting fix version
> in place of target (which is a custom field, iirc).
>
> Let's see if I can revive the discussion over on a yetus list/jira. I
think it's easier to add a new flag to Yetus than changing the Hadoop JIRA
workflow, and it seems like this issue is becoming more acute.
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
On Mon, May 1, 2017 at 3:44 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I believe I asked about this on dev-yetus a while back. I'd prefer that
> the presence of the fix version be sufficient to indicate whether a JIRA is
> included in a release branch. Yetus requires that the JIRA be resolved as
> "Fixed" to show up, which is why we are in our current situation.
>
> We can't do this because Hadoop is the only one that I've seen
> that sets Fix version at close time. Everyone else is setting fix version
> in place of target (which is a custom field, iirc).
>
> Let's see if I can revive the discussion over on a yetus list/jira. I
think it's easier to add a new flag to Yetus than changing the Hadoop JIRA
workflow, and it seems like this issue is becoming more acute.
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
On Mon, May 1, 2017 at 3:44 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I believe I asked about this on dev-yetus a while back. I'd prefer that
> the presence of the fix version be sufficient to indicate whether a JIRA is
> included in a release branch. Yetus requires that the JIRA be resolved as
> "Fixed" to show up, which is why we are in our current situation.
>
> We can't do this because Hadoop is the only one that I've seen
> that sets Fix version at close time. Everyone else is setting fix version
> in place of target (which is a custom field, iirc).
>
> Let's see if I can revive the discussion over on a yetus list/jira. I
think it's easier to add a new flag to Yetus than changing the Hadoop JIRA
workflow, and it seems like this issue is becoming more acute.
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com> wrote:
> I believe I asked about this on dev-yetus a while back. I'd prefer that the presence of the fix version be sufficient to indicate whether a JIRA is included in a release branch. Yetus requires that the JIRA be resolved as "Fixed" to show up, which is why we are in our current situation.
We can't do this because Hadoop is the only one that I've seen that sets Fix version at close time. Everyone else is setting fix version in place of target (which is a custom field, iirc).
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com> wrote:
> I believe I asked about this on dev-yetus a while back. I'd prefer that the presence of the fix version be sufficient to indicate whether a JIRA is included in a release branch. Yetus requires that the JIRA be resolved as "Fixed" to show up, which is why we are in our current situation.
We can't do this because Hadoop is the only one that I've seen that sets Fix version at close time. Everyone else is setting fix version in place of target (which is a custom field, iirc).
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com> wrote:
> I believe I asked about this on dev-yetus a while back. I'd prefer that the presence of the fix version be sufficient to indicate whether a JIRA is included in a release branch. Yetus requires that the JIRA be resolved as "Fixed" to show up, which is why we are in our current situation.
We can't do this because Hadoop is the only one that I've seen that sets Fix version at close time. Everyone else is setting fix version in place of target (which is a custom field, iirc).
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com> wrote:
> I believe I asked about this on dev-yetus a while back. I'd prefer that the presence of the fix version be sufficient to indicate whether a JIRA is included in a release branch. Yetus requires that the JIRA be resolved as "Fixed" to show up, which is why we are in our current situation.
We can't do this because Hadoop is the only one that I've seen that sets Fix version at close time. Everyone else is setting fix version in place of target (which is a custom field, iirc).
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
I didn't close JIRAs after the 3.0.0-alpha1 or alpha2 releases since
closing makes the JIRAs read-only. This makes it more annoying to backport
to older releases and for concurrent releases in general.
I believe I asked about this on dev-yetus a while back. I'd prefer that the
presence of the fix version be sufficient to indicate whether a JIRA is
included in a release branch. Yetus requires that the JIRA be resolved as
"Fixed" to show up, which is why we are in our current situation.
On Thu, Apr 27, 2017 at 12:47 AM, Akira Ajisaka <aa...@apache.org> wrote:
> Thanks Allen for the additional information.
>
> > At one point, JIRA was configured to refuse re-opening after a release
> is cut.
>
> In the past, release manager closed the tickets and the process is written
> in the wiki: https://wiki.apache.org/hadoop/HowToRelease
>
> > 10. In JIRA, close issues resolved in the release. Disable mail
> notifications for this bulk change.
>
> Therefore, let's close them.
>
> On 2017/04/27 3:01, Allen Wittenauer wrote:
>
>>
>> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
>>>
>>>> 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.
>>>
>>>
>> Keep in mind that the release documentation is part of the build
>> process. Users who are doing their own builds will have incomplete
>> documentation if we keep re-opening JIRAs after a release. At one point,
>> JIRA was configured to refuse re-opening after a release is cut. I'm not
>> sure why it stopped doing that, but it might be time to see if we can
>> re-enable that functionality.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
I didn't close JIRAs after the 3.0.0-alpha1 or alpha2 releases since
closing makes the JIRAs read-only. This makes it more annoying to backport
to older releases and for concurrent releases in general.
I believe I asked about this on dev-yetus a while back. I'd prefer that the
presence of the fix version be sufficient to indicate whether a JIRA is
included in a release branch. Yetus requires that the JIRA be resolved as
"Fixed" to show up, which is why we are in our current situation.
On Thu, Apr 27, 2017 at 12:47 AM, Akira Ajisaka <aa...@apache.org> wrote:
> Thanks Allen for the additional information.
>
> > At one point, JIRA was configured to refuse re-opening after a release
> is cut.
>
> In the past, release manager closed the tickets and the process is written
> in the wiki: https://wiki.apache.org/hadoop/HowToRelease
>
> > 10. In JIRA, close issues resolved in the release. Disable mail
> notifications for this bulk change.
>
> Therefore, let's close them.
>
> On 2017/04/27 3:01, Allen Wittenauer wrote:
>
>>
>> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
>>>
>>>> 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.
>>>
>>>
>> Keep in mind that the release documentation is part of the build
>> process. Users who are doing their own builds will have incomplete
>> documentation if we keep re-opening JIRAs after a release. At one point,
>> JIRA was configured to refuse re-opening after a release is cut. I'm not
>> sure why it stopped doing that, but it might be time to see if we can
>> re-enable that functionality.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
I didn't close JIRAs after the 3.0.0-alpha1 or alpha2 releases since
closing makes the JIRAs read-only. This makes it more annoying to backport
to older releases and for concurrent releases in general.
I believe I asked about this on dev-yetus a while back. I'd prefer that the
presence of the fix version be sufficient to indicate whether a JIRA is
included in a release branch. Yetus requires that the JIRA be resolved as
"Fixed" to show up, which is why we are in our current situation.
On Thu, Apr 27, 2017 at 12:47 AM, Akira Ajisaka <aa...@apache.org> wrote:
> Thanks Allen for the additional information.
>
> > At one point, JIRA was configured to refuse re-opening after a release
> is cut.
>
> In the past, release manager closed the tickets and the process is written
> in the wiki: https://wiki.apache.org/hadoop/HowToRelease
>
> > 10. In JIRA, close issues resolved in the release. Disable mail
> notifications for this bulk change.
>
> Therefore, let's close them.
>
> On 2017/04/27 3:01, Allen Wittenauer wrote:
>
>>
>> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
>>>
>>>> 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.
>>>
>>>
>> Keep in mind that the release documentation is part of the build
>> process. Users who are doing their own builds will have incomplete
>> documentation if we keep re-opening JIRAs after a release. At one point,
>> JIRA was configured to refuse re-opening after a release is cut. I'm not
>> sure why it stopped doing that, but it might be time to see if we can
>> re-enable that functionality.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
I didn't close JIRAs after the 3.0.0-alpha1 or alpha2 releases since
closing makes the JIRAs read-only. This makes it more annoying to backport
to older releases and for concurrent releases in general.
I believe I asked about this on dev-yetus a while back. I'd prefer that the
presence of the fix version be sufficient to indicate whether a JIRA is
included in a release branch. Yetus requires that the JIRA be resolved as
"Fixed" to show up, which is why we are in our current situation.
On Thu, Apr 27, 2017 at 12:47 AM, Akira Ajisaka <aa...@apache.org> wrote:
> Thanks Allen for the additional information.
>
> > At one point, JIRA was configured to refuse re-opening after a release
> is cut.
>
> In the past, release manager closed the tickets and the process is written
> in the wiki: https://wiki.apache.org/hadoop/HowToRelease
>
> > 10. In JIRA, close issues resolved in the release. Disable mail
> notifications for this bulk change.
>
> Therefore, let's close them.
>
> On 2017/04/27 3:01, Allen Wittenauer wrote:
>
>>
>> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
>>>
>>>> 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.
>>>
>>>
>> Keep in mind that the release documentation is part of the build
>> process. Users who are doing their own builds will have incomplete
>> documentation if we keep re-opening JIRAs after a release. At one point,
>> JIRA was configured to refuse re-opening after a release is cut. I'm not
>> sure why it stopped doing that, but it might be time to see if we can
>> re-enable that functionality.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
Thanks Allen for the additional information.
> At one point, JIRA was configured to refuse re-opening after a
release is cut.
In the past, release manager closed the tickets and the process is
written in the wiki: https://wiki.apache.org/hadoop/HowToRelease
> 10. In JIRA, close issues resolved in the release. Disable mail
notifications for this bulk change.
Therefore, let's close them.
On 2017/04/27 3:01, Allen Wittenauer wrote:
>
>> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
>>> 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.
>>
>
> Keep in mind that the release documentation is part of the build process. Users who are doing their own builds will have incomplete documentation if we keep re-opening JIRAs after a release. At one point, JIRA was configured to refuse re-opening after a release is cut. I'm not sure why it stopped doing that, but it might be time to see if we can re-enable that functionality.
>
>
> ---------------------------------------------------------------------
> 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
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
Thanks Allen for the additional information.
> At one point, JIRA was configured to refuse re-opening after a
release is cut.
In the past, release manager closed the tickets and the process is
written in the wiki: https://wiki.apache.org/hadoop/HowToRelease
> 10. In JIRA, close issues resolved in the release. Disable mail
notifications for this bulk change.
Therefore, let's close them.
On 2017/04/27 3:01, Allen Wittenauer wrote:
>
>> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
>>> 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.
>>
>
> Keep in mind that the release documentation is part of the build process. Users who are doing their own builds will have incomplete documentation if we keep re-opening JIRAs after a release. At one point, JIRA was configured to refuse re-opening after a release is cut. I'm not sure why it stopped doing that, but it might be time to see if we can re-enable that functionality.
>
>
> ---------------------------------------------------------------------
> 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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
Thanks Allen for the additional information.
> At one point, JIRA was configured to refuse re-opening after a
release is cut.
In the past, release manager closed the tickets and the process is
written in the wiki: https://wiki.apache.org/hadoop/HowToRelease
> 10. In JIRA, close issues resolved in the release. Disable mail
notifications for this bulk change.
Therefore, let's close them.
On 2017/04/27 3:01, Allen Wittenauer wrote:
>
>> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
>>> 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.
>>
>
> Keep in mind that the release documentation is part of the build process. Users who are doing their own builds will have incomplete documentation if we keep re-opening JIRAs after a release. At one point, JIRA was configured to refuse re-opening after a release is cut. I'm not sure why it stopped doing that, but it might be time to see if we can re-enable that functionality.
>
>
> ---------------------------------------------------------------------
> 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: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
Thanks Allen for the additional information.
> At one point, JIRA was configured to refuse re-opening after a
release is cut.
In the past, release manager closed the tickets and the process is
written in the wiki: https://wiki.apache.org/hadoop/HowToRelease
> 10. In JIRA, close issues resolved in the release. Disable mail
notifications for this bulk change.
Therefore, let's close them.
On 2017/04/27 3:01, Allen Wittenauer wrote:
>
>> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
>>> 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.
>>
>
> Keep in mind that the release documentation is part of the build process. Users who are doing their own builds will have incomplete documentation if we keep re-opening JIRAs after a release. At one point, JIRA was configured to refuse re-opening after a release is cut. I'm not sure why it stopped doing that, but it might be time to see if we can re-enable that functionality.
>
>
> ---------------------------------------------------------------------
> 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
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
> > 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.
>
Keep in mind that the release documentation is part of the build process. Users who are doing their own builds will have incomplete documentation if we keep re-opening JIRAs after a release. At one point, JIRA was configured to refuse re-opening after a release is cut. I'm not sure why it stopped doing that, but it might be time to see if we can re-enable that functionality.
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
> > 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.
>
Keep in mind that the release documentation is part of the build process. Users who are doing their own builds will have incomplete documentation if we keep re-opening JIRAs after a release. At one point, JIRA was configured to refuse re-opening after a release is cut. I'm not sure why it stopped doing that, but it might be time to see if we can re-enable that functionality.
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
RE: About 2.7.4 Release
Posted by Brahma Reddy Battula <br...@huawei.com>.
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:aajisaka@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-dev@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 <aa...@apache.org> 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.wang@cloudera.com]
>>> Sent: 08 March 2017 04:22
>>> To: Sangjin Lee
>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org;
>>> Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>> 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 <aa...@apache.org>
>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>> To: Brahma Reddy Battula; Hadoop Common;
>>>>> yarn-dev@hadoop.apache.org; Hdfs-dev;
>>>>> mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
RE: About 2.7.4 Release
Posted by Brahma Reddy Battula <br...@huawei.com>.
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:aajisaka@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-dev@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 <aa...@apache.org> 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.wang@cloudera.com]
>>> Sent: 08 March 2017 04:22
>>> To: Sangjin Lee
>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org;
>>> Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>> 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 <aa...@apache.org>
>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>> To: Brahma Reddy Battula; Hadoop Common;
>>>>> yarn-dev@hadoop.apache.org; Hdfs-dev;
>>>>> mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
> > 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.
>
Keep in mind that the release documentation is part of the build process. Users who are doing their own builds will have incomplete documentation if we keep re-opening JIRAs after a release. At one point, JIRA was configured to refuse re-opening after a release is cut. I'm not sure why it stopped doing that, but it might be time to see if we can re-enable that functionality.
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
RE: About 2.7.4 Release
Posted by Brahma Reddy Battula <br...@huawei.com>.
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:aajisaka@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-dev@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 <aa...@apache.org> 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.wang@cloudera.com]
>>> Sent: 08 March 2017 04:22
>>> To: Sangjin Lee
>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org;
>>> Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>> 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 <aa...@apache.org>
>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>> To: Brahma Reddy Battula; Hadoop Common;
>>>>> yarn-dev@hadoop.apache.org; Hdfs-dev;
>>>>> mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
> > 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.
>
Keep in mind that the release documentation is part of the build process. Users who are doing their own builds will have incomplete documentation if we keep re-opening JIRAs after a release. At one point, JIRA was configured to refuse re-opening after a release is cut. I'm not sure why it stopped doing that, but it might be time to see if we can re-enable that functionality.
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
> 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 <aa...@apache.org> 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.wang@cloudera.com]
>>> Sent: 08 March 2017 04:22
>>> To: Sangjin Lee
>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev;
>>> mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>> 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 <aa...@apache.org>
>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
> 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 <aa...@apache.org> 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.wang@cloudera.com]
>>> Sent: 08 March 2017 04:22
>>> To: Sangjin Lee
>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev;
>>> mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>> 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 <aa...@apache.org>
>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-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
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
> 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 <aa...@apache.org> 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.wang@cloudera.com]
>>> Sent: 08 March 2017 04:22
>>> To: Sangjin Lee
>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev;
>>> mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>> 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 <aa...@apache.org>
>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
> 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 <aa...@apache.org> 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.wang@cloudera.com]
>>> Sent: 08 March 2017 04:22
>>> To: Sangjin Lee
>>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev;
>>> mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>>> 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 <aa...@apache.org>
>>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-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
Re: About 2.7.4 Release
Posted by Haohui Mai <ri...@gmail.com>.
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 <aa...@apache.org> 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.wang@cloudera.com]
>> Sent: 08 March 2017 04:22
>> To: Sangjin Lee
>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev;
>> mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>> 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 <aa...@apache.org>
>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>> For additional commands, e-mail: hdfs-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: 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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Haohui Mai <ri...@gmail.com>.
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 <aa...@apache.org> 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.wang@cloudera.com]
>> Sent: 08 March 2017 04:22
>> To: Sangjin Lee
>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev;
>> mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>> 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 <aa...@apache.org>
>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>> For additional commands, e-mail: hdfs-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: 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: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Haohui Mai <ri...@gmail.com>.
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 <aa...@apache.org> 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.wang@cloudera.com]
>> Sent: 08 March 2017 04:22
>> To: Sangjin Lee
>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev;
>> mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>> 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 <aa...@apache.org>
>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>> For additional commands, e-mail: hdfs-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: 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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Haohui Mai <ri...@gmail.com>.
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 <aa...@apache.org> 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.wang@cloudera.com]
>> Sent: 08 March 2017 04:22
>> To: Sangjin Lee
>> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev;
>> mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com>
>>> 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 <aa...@apache.org>
>>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>>> For additional commands, e-mail: hdfs-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: 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
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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.wang@cloudera.com]
> Sent: 08 March 2017 04:22
> To: Sangjin Lee
> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>> For additional commands, e-mail: hdfs-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: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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.wang@cloudera.com]
> Sent: 08 March 2017 04:22
> To: Sangjin Lee
> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>> For additional commands, e-mail: hdfs-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: 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
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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.wang@cloudera.com]
> Sent: 08 March 2017 04:22
> To: Sangjin Lee
> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>> For additional commands, e-mail: hdfs-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: 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
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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.wang@cloudera.com]
> Sent: 08 March 2017 04:22
> To: Sangjin Lee
> Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
>>> Sent: Tuesday, March 07, 2017 7:34 AM
>>> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
>>> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
>>> For additional commands, e-mail: hdfs-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: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
RE: About 2.7.4 Release
Posted by Brahma Reddy Battula <br...@huawei.com>.
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.wang@cloudera.com]
Sent: 08 March 2017 04:22
To: Sangjin Lee
Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
> > Sent: Tuesday, March 07, 2017 7:34 AM
> > To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> > Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-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
> >
> >
>
RE: About 2.7.4 Release
Posted by Brahma Reddy Battula <br...@huawei.com>.
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.wang@cloudera.com]
Sent: 08 March 2017 04:22
To: Sangjin Lee
Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
> > Sent: Tuesday, March 07, 2017 7:34 AM
> > To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> > Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-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
> >
> >
>
RE: About 2.7.4 Release
Posted by Brahma Reddy Battula <br...@huawei.com>.
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.wang@cloudera.com]
Sent: 08 March 2017 04:22
To: Sangjin Lee
Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
> > Sent: Tuesday, March 07, 2017 7:34 AM
> > To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> > Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-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
> >
> >
>
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 7, 2017, at 2:51 PM, Andrew Wang <an...@cloudera.com> wrote:
> I think it'd be nice to
> have a nightly Jenkins job that builds an RC,
Just a reminder that any such build cannot be used for an actual release:
http://www.apache.org/legal/release-policy.html#owned-controlled-hardware
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
RE: About 2.7.4 Release
Posted by Brahma Reddy Battula <br...@huawei.com>.
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.wang@cloudera.com]
Sent: 08 March 2017 04:22
To: Sangjin Lee
Cc: Marton Elek; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
> > Sent: Tuesday, March 07, 2017 7:34 AM
> > To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> > Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-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
> >
> >
>
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Mar 7, 2017, at 2:51 PM, Andrew Wang <an...@cloudera.com> wrote:
> I think it'd be nice to
> have a nightly Jenkins job that builds an RC,
Just a reminder that any such build cannot be used for an actual release:
http://www.apache.org/legal/release-policy.html#owned-controlled-hardware
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
> > Sent: Tuesday, March 07, 2017 7:34 AM
> > To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> > Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-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
> >
> >
>
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
> > Sent: Tuesday, March 07, 2017 7:34 AM
> > To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> > Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-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
> >
> >
>
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
> > Sent: Tuesday, March 07, 2017 7:34 AM
> > To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> > Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-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
> >
> >
>
Re: About 2.7.4 Release
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
I was planning to take this up, celebrating my return from my paternity leave of absence for quite a while.
Marton, let me know if you do want to take this up instead and we can work together.
Thanks
+Vinod
> On Mar 7, 2017, at 9:13 AM, Sangjin Lee <sj...@apache.org> wrote:
>
> 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.
Re: About 2.7.4 Release
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
I was planning to take this up, celebrating my return from my paternity leave of absence for quite a while.
Marton, let me know if you do want to take this up instead and we can work together.
Thanks
+Vinod
> On Mar 7, 2017, at 9:13 AM, Sangjin Lee <sj...@apache.org> wrote:
>
> 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.
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
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 <sj...@apache.org> 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 <me...@hortonworks.com> 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 <aa...@apache.org>
> > Sent: Tuesday, March 07, 2017 7:34 AM
> > To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> > Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-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
> >
> >
>
Re: About 2.7.4 Release
Posted by Sangjin Lee <sj...@apache.org>.
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 <me...@hortonworks.com> 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 <aa...@apache.org>
> Sent: Tuesday, March 07, 2017 7:34 AM
> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-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
>
>
Re: About 2.7.4 Release
Posted by Sangjin Lee <sj...@apache.org>.
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 <me...@hortonworks.com> 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 <aa...@apache.org>
> Sent: Tuesday, March 07, 2017 7:34 AM
> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-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
>
>
Re: About 2.7.4 Release
Posted by Sangjin Lee <sj...@apache.org>.
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 <me...@hortonworks.com> 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 <aa...@apache.org>
> Sent: Tuesday, March 07, 2017 7:34 AM
> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-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
>
>
Re: About 2.7.4 Release
Posted by Sangjin Lee <sj...@apache.org>.
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 <me...@hortonworks.com> 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 <aa...@apache.org>
> Sent: Tuesday, March 07, 2017 7:34 AM
> To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org;
> Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-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
>
>
Re: About 2.7.4 Release
Posted by Marton Elek <me...@hortonworks.com>.
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 <aa...@apache.org>
Sent: Tuesday, March 07, 2017 7:34 AM
To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Marton Elek <me...@hortonworks.com>.
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 <aa...@apache.org>
Sent: Tuesday, March 07, 2017 7:34 AM
To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-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
Re: About 2.7.4 Release
Posted by Marton Elek <me...@hortonworks.com>.
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 <aa...@apache.org>
Sent: Tuesday, March 07, 2017 7:34 AM
To: Brahma Reddy Battula; Hadoop Common; yarn-dev@hadoop.apache.org; Hdfs-dev; mapreduce-dev@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Akira Ajisaka <aa...@apache.org>.
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: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org