You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-dev@hadoop.apache.org by Brahma Reddy Battula <br...@huawei.com> on 2017/04/18 06:40:15 UTC
RE: About 2.7.4 Release
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 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: 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: 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>.
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: 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>.
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