> 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 <aajis...@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.w...@cloudera.com]
Sent: 08 March 2017 04:22
To: Sangjin Lee
Cc: Marton Elek; Hadoop Common; yarn-...@hadoop.apache.org; Hdfs-dev;
mapreduce-...@hadoop.apache.org
Subject: Re: About 2.7.4 Release
Our release steps are documented on the wiki:
2.6/2.7:
https://wiki.apache.org/hadoop/HowToReleasePreDSBCR
2.8+:
https://wiki.apache.org/hadoop/HowToRelease
I think given the push toward 2.8 and 3.0, there's less interest in
streamlining the 2.6 and 2.7 release processes. CHANGES.txt is the biggest
pain, and that's fixed in 2.8+.
Current pain points for 2.8+ include:
# fixing up JIRA versions and the release notes, though I somewhat
addressed this with the versions script for 3.x # making and staging an RC
and sending the vote email still requires a lot of manual steps # publishing
the release is also quite manual
I think the RC issues can be attacked with enough scripting. Steve had an
ant file that automated a lot of this for slider. I think it'd be nice to
have a nightly Jenkins job that builds an RC, since I've spent a day or two
for each 3.x alpha fixing build issues.
Publishing can be attacked via a mix of scripting and revamping the darned
website. Forrest is pretty bad compared to the newer static site generators
out there (e.g. need to write XML instead of markdown, it's hard to review a
staging site because of all the absolute links, hard to customize, did I
mention XML?), and the look and feel of the site is from the 00s. We don't
actually have that much site content, so it should be possible to migrate to
a new system.
On Tue, Mar 7, 2017 at 9:13 AM, Sangjin Lee <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 <aajis...@apache.org>
Sent: Tuesday, March 07, 2017 7:34 AM
To: Brahma Reddy Battula; Hadoop Common; yarn-...@hadoop.apache.org;
Hdfs-dev; mapreduce-...@hadoop.apache.org
Subject: Re: About 2.7.4 Release
Probably 2.8.0 will be released soon.
https://issues.apache.org/jira/browse/HADOOP-13866?
focusedCommentId=15898379&page=com.atlassian.jira.
plugin.system.issuetabpanels:comment-tabpanel#comment-15898379
I'm thinking 2.7.4 release process starts after 2.8.0 release, so
2.7.4 will be released in April or May. (hopefully)
Thoughts?
Regards,
Akira
On 2017/03/01 21:01, Brahma Reddy Battula wrote:
Hi All
It has been six months for branch-2.7 release.. is there any near
plan
for 2.7.4..?
Thanks&Regards
Brahma Reddy Battula
--------------------------------------------------------------------
- To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
--------------------------------------------------------------------
- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org
