By "merge-based workflow", this is referring to branch development and
merging? I don't see much issue with allowing a rebase-based workflow if
we're okay with allowing force-push on feature branches. If anything, the
next step would be disallowing merge-based workflows and mandating rebases
for a
zhaoyunjiong created MAPREDUCE-6024:
---
Summary: java.net.SocketTimeoutException in Fetcher caused jobs
stuck for more than 1 hour
Key: MAPREDUCE-6024
URL: https://issues.apache.org/jira/browse/MAPREDUCE-6024
[
https://issues.apache.org/jira/browse/MAPREDUCE-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Binglin Chang resolved MAPREDUCE-5984.
--
Resolution: Fixed
> native-task: reuse lz4 sources in hadoop-common
> -
If by very same workflow you mean a merge-based workflow that would be fine
to call out in the vote proposal.
Separately, do we want to disable force push for version branches
(branch-x) and point release branches (branch-x.y) in addition to trunk?
On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdel
I would say we can first move to git and keep the very same workflow we
have today, then we can evolve it.
On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal
wrote:
> +1 to voting on specific workflow(s).
>
>
> On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla
> wrote:
>
> > If we are to start a vot
+1 to voting on specific workflow(s).
On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla wrote:
> If we are to start a vote thread, will people prefer a vote thread that
> includes potential workflows as well?
>
>
> On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla
> wrote:
>
> > Thanks for your
If we are to start a vote thread, will people prefer a vote thread that
includes potential workflows as well?
On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla wrote:
> Thanks for your opinions, everyone. Looks like most people are for the
> change and no one is against it. Let me start a vote f
+1 (non-binding)
Brought up a pseudo distributed cluster. Ran a few HDFS operations and a
couple of example MR jobs. Checked metrics being written out through
FileSink.
On Tue, Aug 5, 2014 at 5:37 PM, Karthik Kambatla wrote:
> Hi folks,
>
> I have put together a release candidate (rc1) for Had
Thanks for your opinions, everyone. Looks like most people are for the
change and no one is against it. Let me start a vote for this.
On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA
wrote:
> Thank you for supplementation, Andrew. Yes, we should go step by step
> and let's discuss review workflow
This vote is cancelled due to the incompatible issue.
On Fri, Aug 1, 2014 at 5:28 PM, Karthik Kambatla wrote:
> Missed Andrew's email in the other thread. Looks like we might need
> HDFS-6793.
>
> I ll wait to see if others find any other issues, so I can address them
> all together.
>
>
> On F
Hi folks,
I have put together a release candidate (rc1) for Hadoop 2.5.0.
The RC is available at: http://people.apache.org/~kasha/hadoop-2.5.0-RC1/
The RC tag in svn is here:
https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.5.0-rc1/
The maven artifacts are staged at:
https://reposito
See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1853/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 34855 lines...]
TestJobClientGetJob.testGetRunning
Hello,
does somebody know how to get the name of currently processed file from the
map-function in C++? HadoopPipes::MapContext::getInputSplit() returns an
std::string, which contains filename, but surrounded with some (non-printable)
characters. How to correctly extract a filename from this va
13 matches
Mail list logo