To close the loop on this one, I created a label for the candidate list of
patches:
https://issues.apache.org/jira/issues/?jql=labels%20%3D%202.6.1-candidatehttps://issues.apache.org/jira/issues/?jql=labels%20=%202.6.1-candidate,
in order to make progress while the issue is still hot.
The
Masatake Iwasaki created HADOOP-12240:
-
Summary: Fix tests requiring native library to be skipped in
non-native profile
Key: HADOOP-12240
URL: https://issues.apache.org/jira/browse/HADOOP-12240
Inline
On Wed, Jul 15, 2015 at 5:22 PM, Vinod Kumar Vavilapalli
vino...@hortonworks.com wrote:
I can understand these (sort of newish) questions from hbase-dev. We
already have a well laid-out release-management process. If people want to
learn more about how it works, please head over to
Steve Loughran created HADOOP-12235:
---
Summary: hadoop-openstack junit mockito dependencies should be
provided
Key: HADOOP-12235
URL: https://issues.apache.org/jira/browse/HADOOP-12235
Project:
Duo Xu created HADOOP-12239:
---
Summary: StorageException complaining no lease ID when updating
FolderLastModifiedTime in WASB
Key: HADOOP-12239
URL: https://issues.apache.org/jira/browse/HADOOP-12239
See https://builds.apache.org/job/Hadoop-Common-trunk/1555/changes
Hi all,
Thanks everyone for the push on 2.7.1! Branch-2.7 is now open for commits
to a 2.7.2 release. JIRA also now has a 2.7.2 version for all the
sub-projects.
Continuing the previous 2.7.1 thread on steady maintenance releases [1], we
should follow up 2.7.1 with a 2.7.2 within 4 weeks.
Why not just have the discussion here? It seems integral to the matter of
having more maintenance releases on those versions.
On Wed, Jul 15, 2015 at 11:39 AM, Karthik Kambatla ka...@cloudera.com
wrote:
I believe there was general consensus to do more maintenance releases, as
witnessed in the
Got pinged on a recent thread on this one.
As I mentioned there, I had many offline discussions re 2.6.1.
The biggest problem I found offline was about what bug-fixes are acceptable and
what aren’t for everyone wishing to consume 2.6.1. Given the number of
bug-fixes that went into 2.7.x and
Yeah, I started a thread while back on this one
(http://markmail.org/message/sbykjn5xgnksh6wg) and had many offline discussions
re 2.6.1.
The biggest problem I found offline was about what bug-fixes are acceptable and
what aren’t for everyone wishing to consume 2.6.1. Given the number of
Over on HBase, committers volunteer to be release runners for a whole
release line. I wouldn't use the word 'appoint' necessarily because the
arrangement is an informal communal practice, not written down anywhere as
policy or codified into bylaws.
If it is helpful to have a data point from
Is there anyone interested in volunteering to run a 2.6.1 release (Akira?)?
You'd get some help (especially if the bar is set high and only critical
bug fixes are allowed in: i.e. no features, no 'perf' fixes, no jar
updates, and so on).
St.Ack
On Wed, Jul 15, 2015 at 3:07 PM, Chris Douglas
As I proposed in the other thread, how about we adopting the following
model:
x.y.1 releases have all Blocker, Critical, Major bug fixes applied to the
next minor release.
x.y.2 releases have all Blocker, Critical bug fixes applied to the next
minor release.
x.y.3 releases have all Blocker bug
If people are concerned about regression then just don't install new
versions, or install a vendor tested stable version. Giving users choices
is a good thing for stability.
On Wed, Jul 15, 2015 at 2:17 PM, Sangjin Lee sjl...@gmail.com wrote:
I think the bar for making the maintenance releases
Every new patch potentially brings in new bugs. So, if we want to limit the
kinds of potential bugs introduced in point releases, we might want to
limit what gets in.
Would be nice to make sure a point release is more stable than a previous
point release in that line.
On Wed, Jul 15, 2015 at
I think the bar for making the maintenance releases should be set
reasonably high, and the main reason is the concern for
stability/regression. Unfortunately there have been cases where a seemingly
innocuous bug fix introduced regressions, small or large. And that defeats
the purpose of a
Why not just include all backwards compatible bug fixes?
Alternatively, why not appoint a Release Manager for the minor release line
and then allow them to arbitrate when there's disagreement about inclusion?
This has worked well in the HBase community.
On Wed, Jul 15, 2015 at 3:49 PM, Karthik
I can understand these (sort of newish) questions from hbase-dev. We already
have a well laid-out release-management process. If people want to learn more
about how it works, please head over to http://hadoop.apache.org/bylaws.html.
In terms of 2.6.1 release management, it wasn’t stuck for lack
On Wed, Jul 15, 2015 at 2:07 PM, Sean Busbey bus...@cloudera.com wrote:
Alternatively, why not appoint a Release Manager for the minor release line
and then allow them to arbitrate when there's disagreement about inclusion?
This has worked well in the HBase community.
Release managers aren't
+1 Chris is right.
++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email:
Tsuyoshi Ozawa created HADOOP-12237:
---
Summary: releasedocmaker.py doesn't work behind a proxy
Key: HADOOP-12237
URL: https://issues.apache.org/jira/browse/HADOOP-12237
Project: Hadoop Common
Strong +1 for having a 2.6.1 release. I understand Vinod has been trying to
get that effort going but it's been stalled a little bit. It would be good
to rekindle that effort.
Companies with big hadoop 2.x deployments (including mine) have always
tried to stabilize a 2.x release by
Tsuyoshi Ozawa created HADOOP-12238:
---
Summary: Passing project option to releasedocmaker.py for running
mvn site -Preleasedocs
Key: HADOOP-12238
URL: https://issues.apache.org/jira/browse/HADOOP-12238
[
https://issues.apache.org/jira/browse/HADOOP-12238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allen Wittenauer resolved HADOOP-12238.
---
Resolution: Duplicate
There's already a JIRA covering moving trunk's releasedoc
I believe there was general consensus to do more maintenance releases, as
witnessed in the other thread.
There have been discussions on what should go into 2.x.1, 2.x.2, etc., but
I don't think we have a clear proposal. It would be nice to put that
together, so committers know where all to commit
25 matches
Mail list logo
