Chris Nauroth created HADOOP-11547:
--
Summary: hadoop-common native compilation fails on Windows due to
missing support for __attribute__ declaration.
Key: HADOOP-11547
URL:
Done
On 3 February 2015 at 23:38:58, Jesse Crouch
(je...@atxcursions.commailto:je...@atxcursions.com) wrote:
JesseCrouch
See https://builds.apache.org/job/Hadoop-Common-trunk/1396/changes
Changes:
[jlowe] YARN-3085. Application summary should include the application type.
Contributed by Rohith
[ozawa] HADOOP-11045. Introducing a tool to detect flaky tests of hadoop
jenkins testing job. Contributed by Yongjun
See https://builds.apache.org/job/Hadoop-common-trunk-Java8/96/changes
Changes:
[jlowe] YARN-3085. Application summary should include the application type.
Contributed by Rohith
[ozawa] HADOOP-11045. Introducing a tool to detect flaky tests of hadoop
jenkins testing job. Contributed by
I'm worrying more about the ongoing situation. As a release approaches someone
effectively goes full time as the gatekeeper, -for a good release they should
be saying too late! for most features and only if it's low risk to
non-critical bug fixes
Which means that non-critical stuff don't get
I wonder if this work logically falls under the release manager role.
During a release, we generally spend a little bit of time thinking
about what new features we added, systems we stabilized, interfaces we
changed, etc. etc. This gives us some perspective to look backwards
at old JIRAs and
The main JIRA dashboard for each project has an Issues tab with useful
summary statistics and links to filtered queries, most notably links to
unresolved issues grouped by each project sub-component.
https://issues.apache.org/jira/browse/HADOOP/?selectedTab=com.atlassian.jir
Release managers are just committers trying to roll releases; it's not
an enduring role. A patch manager is just someone helping to track
work and direct reviewers to issues. The job doesn't come with a hat.
We could look into a badge and gun if that would help.
This doesn't require a lot of
There are many ways to find reviewers. Look at the set of watchers,
email people who work on that component (check git if you're unsure
who's been there recently), or even email random committers and ask
for leads. Privately ask people why they stopped responding to an
issue. Even if an issue has
Is process really the problem? Or, more directly, how does any of this
actually increase the pool beyond the (I’m feeling generous today) 10 or so
committers (never mind PMC) that actually review patches that come from outside
their employers on a regular basis?
To put this
+1 to patch managers per component.
On Wed, Feb 4, 2015 at 12:29 PM, Allen Wittenauer a...@altiscale.com wrote:
Is process really the problem? Or, more directly, how does any of
this actually increase the pool beyond the (I’m feeling generous today) 10
or so committers (never mind
[
https://issues.apache.org/jira/browse/HADOOP-8594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akira AJISAKA resolved HADOOP-8594.
---
Resolution: Fixed
Closing this issue as all sub-tasks has been closed.
Now hadoop use
Brahma Reddy Battula created HADOOP-11545:
-
Summary: [ hadoop credential ] ArrayIndexOutOfBoundsException
thrown when we list -provider
Key: HADOOP-11545
URL:
13 matches
Mail list logo
