re [1]. -C
[1]: https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/
On Tue, May 15, 2018 at 10:27 AM, Allen Wittenauer
wrote:
>
>> On May 15, 2018, at 10:16 AM, Chris Douglas wrote:
>>
>> They've been failing for a long time. It can't i
They've been failing for a long time. It can't install bats, and
that's fatal? -C
On Tue, May 15, 2018 at 9:43 AM, Allen Wittenauer
wrote:
>
>
> FYI:
>
> I’m going to disable the branch-2 nightly jobs.
> -
> To unsubscribe, e-mai
orkflow, which merged trunk at a regular
>> frequency into ozone, and then ozone was merged back.
>>
>> Here is the mail that we followed for the merge process.
>> https://lists.apache.org/thread.html/43cd65c6b6c3c0e8ac
>>
>> Thanks
>> Xiaoyu
>>
>>
>>
This really made a mess of trunk. Periodically merging trunk into the
HDFS-7240 branch, then merging the whole thing back, created a tangle
of references that's very difficult to work with (look at the output
of git log --graph).
I'm not sure it's even possible to fix this, but this is why feature
> Andrew
>
> On Mar 22, 2018 9:51 AM, "Chris Douglas" wrote:
>
> +1 (binding)
>
> This compromise seems to address most of the concerns raised during
> the discussion. Thanks for proposing and driving this, Owen.
>
> On Thu, Mar 22, 2018 at 9:30 AM, Andrew W
+1 (binding)
This compromise seems to address most of the concerns raised during
the discussion. Thanks for proposing and driving this, Owen.
On Thu, Mar 22, 2018 at 9:30 AM, Andrew Wang wrote:
> In Owen's proposal, it says to delete the module from the release branch.
> We need to do this since
Thanks, Allen.
On Thu, Mar 15, 2018 at 10:20 AM, Iñigo Goiri wrote:
>> * It ALWAYS applies HADOOP-14667.05.patch prior to running. As a result,
>> this is only set up for trunk with no parameterization to run other
>> branches.
I tried to get this running in my environment a few weeks ago, but
sue, but will double check. Let me know if there are
> more meetups planned in the near future and we can use this.
>
> Thanks
> +Vinod
>
> On Mar 6, 2018, at 7:48 PM, Chris Douglas wrote:
>
> Found a meetup alternative (thanks Subru):
> https://meetingstar.io/event/fk1
We're using a shared doc to track work in progress, PA/review ready,
and committed [1]. -C
[1]: https://s.apache.org/RLlx
On Mon, Mar 12, 2018 at 9:17 AM, Chris Douglas wrote:
> On Fri, Mar 9, 2018 at 7:52 PM, 俊平堵 wrote:
>> Thanks for organizing this, Chris! Please let me know if
. -C
[1]: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75965105
> 2018-03-05 16:03 GMT-08:00 Chris Douglas :
>
>> [Cross-posting, as this affects the rest of the project]
>>
>> Hey folks-
>>
>> As discussed last month [1], the HDFS build hasn't been heal
here.
>
> Thanks,
>
> Junping
>
> 2018-03-05 16:03 GMT-08:00 Chris Douglas :
>
>> [Cross-posting, as this affects the rest of the project]
>>
>> Hey folks-
>>
>> As discussed last month [1], the HDFS build hasn't been healthy
>> r
+1 (binding) -C
On Thu, Mar 8, 2018 at 9:31 AM, Jim Clampffer wrote:
> Hi Everyone,
>
> The feedback was generally positive on the discussion thread [1] so I'd
> like to start a formal vote for merging HDFS-8707 (libhdfs++) into trunk.
> The vote will be open for 7 days and end 6PM EST on 3/15/18
eId=75965105
On Tue, Mar 6, 2018 at 7:48 PM, Chris Douglas wrote:
> Found a meetup alternative (thanks Subru):
> https://meetingstar.io/event/fk13172f1d75KN
>
> So we can get a rough headcount, please add (local) if you plan to
> attend in-person. -C
>
>
> On Mon,
Found a meetup alternative (thanks Subru):
https://meetingstar.io/event/fk13172f1d75KN
So we can get a rough headcount, please add (local) if you plan to
attend in-person. -C
On Mon, Mar 5, 2018 at 4:03 PM, Chris Douglas wrote:
> [Cross-posting, as this affects the rest of the project]
>
[Cross-posting, as this affects the rest of the project]
Hey folks-
As discussed last month [1], the HDFS build hasn't been healthy
recently. We're dedicating a bug bash to stabilize the build and
address some longstanding issues with our unit tests. We rely on our
CI infrastructure to keep the p
[
https://issues.apache.org/jira/browse/HDFS-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas reopened HDFS-13216:
--
> HDFS
>
>
> Key: HDFS-13216
> URL: https://is
[
https://issues.apache.org/jira/browse/HDFS-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas resolved HDFS-13216.
--
Resolution: Invalid
> HDFS
>
>
> Key: HDFS-13216
>
hen read erasure
>> coded file?
>> 3. Is there any building/testing mechanism to enforce the consistency
>> between the c++ part and Java part?
>> 4. I thought the public header and lib should be exported when building
>> the distribution package, otherwise hard to use the
+1
Let's get this done. We've had many false starts on a native HDFS
client. This is a good base to build on. -C
On Wed, Feb 28, 2018 at 9:55 AM, Jim Clampffer
wrote:
> Hi everyone,
>
> I'd like to start a thread to discuss merging the HDFS-8707 aka libhdfs++
> into trunk. I sent originally sen
Correction: 3/12 or 3/13, as in March 12 or 13th. -C
On Tue, Feb 20, 2018 at 3:59 PM, Chris Douglas wrote:
> Looking at the poll [1], it looks like 12/12 or 12/13 would be the
> best day to do this. If you haven't posted your availability and would
> like to participate, please
can't attend in-person. -C
[1]: https://doodle.com/poll/r22znitzae9apfbf
On Fri, Feb 9, 2018 at 1:45 PM, Chris Douglas wrote:
> On Thu, Feb 8, 2018 at 5:47 PM, 郑锴(铁杰) wrote:
>>>>I'm looking at you, TestDFSStripedOutputStreamWithFailure ...
>> AFAIK and IMO, it&
s should definitely help and be appreciated.
>
> Regards,
> Kai
>
> ------
> 发件人:Chris Douglas
> 发送时间:2018年2月8日(星期四) 08:39
> 收件人:Hdfs-dev
> 主 题:Re: [DISCUSS] Meetup for HDFS tests and build infra
>
> Created a poll [1] to inform sch
Created a poll [1] to inform scheduling. -C
[1]: https://doodle.com/poll/r22znitzae9apfbf
On Tue, Feb 6, 2018 at 3:09 PM, Chris Douglas wrote:
> The HDFS build is not healthy. Many of the unit tests aren't actually
> run in Jenkins due to resource exhaustion, haven't been updat
The HDFS build is not healthy. Many of the unit tests aren't actually
run in Jenkins due to resource exhaustion, haven't been updated since
build/test/data was the test temp dir, or are chronically unstable
(I'm looking at you, TestDFSStripedOutputStreamWithFailure). The
situation has deteriorated
On Fri, Feb 2, 2018 at 10:22 AM, Arpit Agarwal wrote:
> Do you plan to roll an RC with an uncommitted fix? That isn't the right
> approach.
The fix will be committed to the release branch. We'll vote on the
release, and if it receives a majority of +1 votes then it becomes
3.0.1. That's how the
+1 Looking forward to this. -C
On Fri, Jan 26, 2018 at 7:28 AM, Arun Suresh wrote:
> Hello yarn-dev@
>
> Based on the positive feedback from the DISCUSS thread [1], I'd like to
> start a formal vote to merge YARN-6592 [2] to trunk. The vote will run for 5
> days, and will end Jan 31 7:30AM PDT.
>
[
https://issues.apache.org/jira/browse/HDFS-12970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas resolved HDFS-12970.
--
Resolution: Invalid
> HdfsFileStatus#getPath returning n
Chris Douglas created HDFS-12944:
Summary: Update NOTICE for AssertJ dependency
Key: HDFS-12944
URL: https://issues.apache.org/jira/browse/HDFS-12944
Project: Hadoop HDFS
Issue Type: Task
+1 to close it out.
With 6 +1 votes (5 binding) this passes.
Thanks everyone, particularly Sean and Inigo for trying it out. We'll
merge this soon. -C
On Fri, Dec 8, 2017 at 3:44 PM, Chris Douglas wrote:
> Discussion thread: https://s.apache.org/kxT1
>
> We're down to the
[
https://issues.apache.org/jira/browse/HDFS-12903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas resolved HDFS-12903.
--
Resolution: Fixed
> [READ] Fix closing streams in ImageWri
[
https://issues.apache.org/jira/browse/HDFS-12903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas reopened HDFS-12903:
--
> [READ] Fix closing streams in ImageWri
Chris Douglas created HDFS-12926:
Summary: open(PathHandle) contract test should be exhaustive for
default options
Key: HDFS-12926
URL: https://issues.apache.org/jira/browse/HDFS-12926
Project
Discussion thread: https://s.apache.org/kxT1
We're down to the last few issues and are preparing the branch to
merge to trunk. We'll post merge patches to HDFS-9806 [1]. Minor,
"cleanup" tasks (checkstyle, findbugs, naming, etc.) will be tracked
in HDFS-12712 [2].
We've tried to ensure that when
[
https://issues.apache.org/jira/browse/HDFS-10262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas resolved HDFS-10262.
--
Resolution: Duplicate
Fixed in HDFS-7878
> Change HdfsFileStatus::fileId to an opa
Chris Douglas created HDFS-12885:
Summary: Add visibility/stability annotations
Key: HDFS-12885
URL: https://issues.apache.org/jira/browse/HDFS-12885
Project: Hadoop HDFS
Issue Type: Sub
Hey hdfs-dev@-
The HDFS-9806 dev branch is getting ready to merge to trunk. This branch
adds a new storage type (PROVIDED) to support reading remote data as HDFS
blocks. Design documentation and discussion are available on JIRA [1].
Over the next week or so, we'll work through the remaining issue
Chris Douglas created HDFS-12882:
Summary: Support full open(PathHandle) contract in HDFS
Key: HDFS-12882
URL: https://issues.apache.org/jira/browse/HDFS-12882
Project: Hadoop HDFS
Issue
[
https://issues.apache.org/jira/browse/HDFS-11576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas reopened HDFS-11576:
--
Reopening for branch-2
> Block recovery will fail indefinitely if recovery time > hea
[
https://issues.apache.org/jira/browse/HDFS-11576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas reopened HDFS-11576:
--
Reopening because {{TestPipelinesFailover}} isn't spurious, this time.
> Block recovery w
Chris Douglas created HDFS-12877:
Summary: Add open(PathHandle) with default buffersize
Key: HDFS-12877
URL: https://issues.apache.org/jira/browse/HDFS-12877
Project: Hadoop HDFS
Issue Type
Chris Douglas created HDFS-12874:
Summary: [READ] Documentation for provided storage
Key: HDFS-12874
URL: https://issues.apache.org/jira/browse/HDFS-12874
Project: Hadoop HDFS
Issue Type
Chris Douglas created HDFS-12844:
Summary:
TestClientDistributedCacheManager::testDetermineCacheVisibilities assumes all
parent dirs set other exec
Key: HDFS-12844
URL: https://issues.apache.org/jira/browse/HDFS
[
https://issues.apache.org/jira/browse/HDFS-12681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas reopened HDFS-12681:
--
Reopening to revert this, and try another approach
> Fold HdfsLocatedFileStatus i
+1 (binding)
Verified source tarball. Checksum and signature match, built from
source, ran some unit tests. Skimmed NOTICE/LICENSE. -C
On Mon, Nov 13, 2017 at 4:10 PM, Arun Suresh wrote:
> Hi Folks,
>
> Apache Hadoop 2.9.0 is the first release of Hadoop 2.9 line and will be the
> starting releas
The labor required for these release formalisms is exceeding their
value. Our minor releases have more bugs than our patch releases (we
hope), but every consumer should understand how software versioning
works. Every device I own has bugs on major OS updates. That doesn't
imply that every minor rel
Chris Douglas created HDFS-12729:
Summary: Document special paths in HDFS
Key: HDFS-12729
URL: https://issues.apache.org/jira/browse/HDFS-12729
Project: Hadoop HDFS
Issue Type: Task
Sean/Junping-
Ignoring the epistemology, it's a problem. Let's figure out what's
causing memory to balloon and then we can work out the appropriate
remedy.
Is this reproducible outside the CI environment? To Junping's point,
would YETUS-561 provide more detailed information to aid debugging? -C
+1 (binding)
Looked through the src distribution. Checksum, signatures match, ran
some of the unit tests. Also checked the site docs; thanks for
updating the Docker container security docs.
Thanks, Junping. -C
On Thu, Oct 19, 2017 at 5:42 PM, Junping Du wrote:
> Hi folks,
> I've created ou
Chris Douglas created HDFS-12681:
Summary: Fold HdfsLocatedFileStatus into HdfsFileStatus
Key: HDFS-12681
URL: https://issues.apache.org/jira/browse/HDFS-12681
Project: Hadoop HDFS
Issue
r (a new
>> component) so everything is isolated.
>>
>> In addition, no new APIs have been added and we rely fully in
>> ClientProtocol.
>>
>>
>>
>> I’d like to thank the people at Microsoft (specially, Jason, Ricardo,
>> Chris, Subru, Jakob, Carlo an
shouldn't be enabled in secure environments. How are users
supposed to make this determination without it?
> Vote still continue until a real blocker comes.
Soright. I remain -1. -C
> ____
> From: Chris Douglas
> Sent: Monday, September 11,
-1 (binding)
I don't think we should release this without YARN-6622.
Since this doesn't happen often: a -1 in this case is NOT a veto.
Releases are approved by majority vote of the PMC. -C
On Mon, Sep 11, 2017 at 11:45 AM, Junping Du wrote:
> Thanks Mikols for notifying on this. I think docker
Chris Douglas created HDFS-12417:
Summary: Disable flaky TestDFSStripedOutputStreamWithFailure
Key: HDFS-12417
URL: https://issues.apache.org/jira/browse/HDFS-12417
Project: Hadoop HDFS
[
https://issues.apache.org/jira/browse/HDFS-12349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas reopened HDFS-12349:
--
> Improve log message when it could not alloc enough blocks for
Chris Douglas created HDFS-12410:
Summary: Ignore unknown StorageTypes
Key: HDFS-12410
URL: https://issues.apache.org/jira/browse/HDFS-12410
Project: Hadoop HDFS
Issue Type: Task
ill advocate for this particular merge on those merits. -C
[1] https://issues.apache.org/jira/browse/HADOOP-14741
[2] git diff --diff-filter=M $(git merge-base apache/HDFS-10467
apache/trunk)..apache/HDFS-10467
> On Thu, Aug 24, 2017 at 1:39 PM, Chris Douglas wrote:
>>
>> I'd
- There is some argument about naming the feature as “Router-based
> federation” but I’m open for better names.
>
>
>
> *Credits*:
>
> I’d like to thank the people at Microsoft (specially, Jason, Ricardo,
> Chris, Subru, Jakob, Carlo and Giovanni), Twitter (Ming and G
+1 (binding)
Looked through the src tarball. Checksum and signature match, skimmed
NOTICE/LICENSE, ran some unit tests. -C
On Sat, Jul 29, 2017 at 4:29 PM, Konstantin Shvachko
wrote:
> Hi everybody,
>
> Here is the next release of Apache Hadoop 2.7 line. The previous stable
> release 2.7.3 was a
Chris Douglas created HDFS-12250:
Summary: Reduce usage of FsPermissionExtension in HDFS unit tests
Key: HDFS-12250
URL: https://issues.apache.org/jira/browse/HDFS-12250
Project: Hadoop HDFS
On Mon, Jul 31, 2017 at 3:56 PM Chris Douglas wrote:
>
>> On Mon, Jul 31, 2017 at 3:02 PM, Konstantin Shvachko
>> wrote:
>> > For the packaging, here is the exact phrasing from the sited
>> release-policy
>> > document relevant to binaries:
>>
On Mon, Jul 31, 2017 at 3:02 PM, Konstantin Shvachko
wrote:
> For the packaging, here is the exact phrasing from the sited release-policy
> document relevant to binaries:
> "As a convenience to users that might not have the appropriate tools to
> build a compiled version of the source, binary/byte
On Wed, Mar 29, 2017 at 4:59 PM, Stack wrote:
>> The former; an intermediate handler decoding, [modifying,] and
>> encoding the record without losing unknown fields.
>>
>
> I did not try this. Did you? Otherwise I can.
Yeah, I did. Same format. -C
>> This looks fine. -C
>>
>> > Thanks,
>> > St.A
On Wed, Mar 29, 2017 at 1:13 PM, Stack wrote:
> Is the below evidence enough that pb3 in proto2 syntax mode does not drop
> 'unknown' fields? (Maybe you want evidence that java tooling behaves the
> same?)
I reproduced your example with the Java tooling, including changing
some of the fields in t
[
https://issues.apache.org/jira/browse/HDFS-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas resolved HDFS-9809.
-
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 3.0.0-alpha2
> Abstr
[
https://issues.apache.org/jira/browse/HDFS-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas resolved HDFS-10640.
--
Resolution: Later
Closing this, given attention to solving this across the project in HADOOP
On Tue, Mar 28, 2017 at 4:18 PM, Andrew Wang wrote:
> Unfortunately, it sounds like these are intrinsic differences with PB3.
That's too bad... but possibly not fatal: most of the data we proxy
through client code is, if not opaque, it's at least immutable
(particularly tokens). If PB3 does suppo
On Tue, Mar 28, 2017 at 3:04 PM, Andrew Wang wrote:
> There's no mention of the convenient "Embedded messages are compatible with
>> bytes if the bytes contain an encoded version of the message" semantics in
>> proto3.
>
>
> I checked the proto3 guide, and I think this is supported:
> https://deve
On Wed, Jan 25, 2017 at 11:42 AM, Andrew Wang wrote:
> Chris and Karthik, could you clarify the contingency of your votes? Is
> fixing just the release notes sufficient?
My +1 was not contingent on any changes.
The release is fine as-is. Fixing any subset of the release notes,
minicluster jar, a
On Mon, Jan 23, 2017 at 9:32 PM, Allen Wittenauer
wrote:
> The problem here is that there is a 'license' directory and a file called
> 'LICENSE'. If this gets extracted by jar via jar xf, it will fail. unzip
> can be made to extract it via an option like -o. To make matters worse, none
> of
Thanks for all your work on this, Andrew. It's great to see the 3.x
series moving forward.
If you were willing to modify the release notes and add the LICENSE to
the jar, we don't need to reset the clock on the VOTE, IMO.
What's the issue with the minicluster jar [1]? I tried to reproduce,
but ha
On Fri, Jan 20, 2017 at 2:50 PM, Sangjin Lee wrote:
> The security patch for the 2.6.x line is a case in point. Without any
> guideline, we would start with "What should we do for 2.6.x? Should we
> continue to patch it?" With this guideline, the baseline is already "it's
> been 2 years since 2.6.
Sorry, I'd missed the end of the EOL discussion thread.
As several people have pointed out, this is unenforceable. The release
dates on the front page are a decent signal for liveness... do we need
something more formal? All these hypothetical situations would be
decided with more context. The "go
+1 Verified checksum and signature. Unpacked the jar, started
single-node HDFS cluster, did some cursory checks.
Read through the commit log from 2.6.4; particularly happy to see
HADOOP-12893. -C
On Tue, Sep 27, 2016 at 1:28 PM, Sangjin Lee wrote:
> Hi folks,
>
> I have created a release candida
+1 (also on JIRA) -C
On Wed, Sep 7, 2016 at 6:44 AM, Allen Wittenauer
wrote:
>
> I’d like to call for a vote to run for 5 days (ending Mon 12, 2016
> at 7AM PT) to merge the HADOOP-13341 feature branch into trunk. This branch
> was developed exclusively by me. As usual with large shel
> I'm certainly open to alternate proposals for versioning and fix versions,
> but to reiterate, I like this versioning since it imitates other enterprise
> software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like
> 3.0.0-alpha1 will be immediately familiar to end users. Conversel
I agree with Konst. The virtues of branching (instead of releasing
from trunk) and using the version suffix for the 3.x releases are lost
on me. Both introduce opportunities for error, in commits, in
consistent JIRA tagging, in packaging...
We can mark stability on the website. If someone builds a
Chris Douglas created HDFS-10706:
Summary: Add tool generating FSImage from external store
Key: HDFS-10706
URL: https://issues.apache.org/jira/browse/HDFS-10706
Project: Hadoop HDFS
Issue
Reading through HDFS-9924, a request for a design doc- and a -1 on
committing to trunk- was raised in mid-May, but commits to trunk
continued. Why is that? Shouldn't this have paused while the details
were discussed? Branching is neutral to the pace of feature
development, but consensus on the resu
If we're not starting branch-3/trunk, what would distinguish it from
trunk/trunk-incompat? Is it the same mechanism with different labels?
That may be a reasonable strategy when we create branch-3, as a
release branch for beta. Releasing 3.x from trunk will help us figure
out which incompatibiliti
Chris Douglas created HDFS-10262:
Summary: Change HdfsFileStatus::fileId to an opaque identifier
Key: HDFS-10262
URL: https://issues.apache.org/jira/browse/HDFS-10262
Project: Hadoop HDFS
[
https://issues.apache.org/jira/browse/HDFS-9938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas resolved HDFS-9938.
-
Resolution: Won't Fix
Yes, thanks for opening this [~vishwajeet.dusane]. Resolving as WO
Chris Douglas created HDFS-9808:
---
Summary: Combine READ_ONLY_SHARED DatanodeStorages with the same ID
Key: HDFS-9808
URL: https://issues.apache.org/jira/browse/HDFS-9808
Project: Hadoop HDFS
Chris Douglas created HDFS-9807:
---
Summary: Add an optional StorageID to writes
Key: HDFS-9807
URL: https://issues.apache.org/jira/browse/HDFS-9807
Project: Hadoop HDFS
Issue Type: Improvement
Chris Douglas created HDFS-9806:
---
Summary: Allow HDFS block replicas to be provided by an external
storage system
Key: HDFS-9806
URL: https://issues.apache.org/jira/browse/HDFS-9806
Project: Hadoop
nges
>>and uncertainties in where and how it should go, thus more risk in
>>stalling.
>>
>>>> If the encryption libraries are the only ones you're interested in
>>>>pulling out, then Apache Commons does seem like a better target than a
>>>>separa
ing out, then Apache Commons does
seem like a better target than a separate project. -C
On Wed, Feb 3, 2016 at 1:49 AM, Chris Douglas wrote:
> On Wed, Feb 3, 2016 at 12:48 AM, Gangumalla, Uma
> wrote:
>>>Standing in the point of shared fundamental piece of code like this, I do
g prebuilt jars from the internet.
>>
>>Kai Zheng's question about whether we would bundle openSSL's libraries is
>>a good one. Given the high rate of new vulnerabilities discovered in
>>that library, it seems like bundling would require Hadoop users and
>>
As a subproject of Hadoop, Chimera could maintain its own cadence.
There's also no reason why it should maintain dependencies on other
parts of Hadoop, if those are separable. How is this solution
inadequate?
If Chimera is not successful as an independent project or stalls,
Hadoop and/or Spark and
With two active sustaining branches (2.6, 2.7), what would you think
of releasing trunk as 3.x instead of pushing 2.8? There are many new
features (EC, Y1197, etc.), and trunk could be the source of several
alpha/beta releases before we fork the 3.x line. -C
On Sat, Sep 26, 2015 at 12:49 PM, Vinod
Chris Douglas created HDFS-9020:
---
Summary: Support hflush/hsync in WebHDFS
Key: HDFS-9020
URL: https://issues.apache.org/jira/browse/HDFS-9020
Project: Hadoop HDFS
Issue Type: Improvement
On Fri, Mar 6, 2015 at 4:32 PM, Vinod Kumar Vavilapalli
wrote:
> I'd encourage everyone to post their wish list on the Roadmap wiki that
> *warrants* making incompatible changes forcing us to go 3.x.
This is a useful exercise, but not a prerequisite to releasing 3.0.0
as an alpha off of trunk, r
On Mon, Mar 2, 2015 at 11:04 PM, Konstantin Shvachko
wrote:
> 2. If Hadoop 3 and 2.x are meant to exist together, we run a risk to
> manifest split-brain behavior again, as we had with hadoop-1, hadoop-2 and
> other versions. If that somehow beneficial for commercial vendors, which I
> don't see h
+1 -C
On Fri, Aug 8, 2014 at 7:57 PM, Karthik Kambatla wrote:
> I have put together this proposal based on recent discussion on this topic.
>
> Please vote on the proposal. The vote runs for 7 days.
>
>1. Migrate from subversion to git for version control.
>2. Force-push to be disabled on
+1 -C
On Tue, Jun 24, 2014 at 1:53 AM, Arun C Murthy wrote:
> Folks,
>
> As discussed, I'd like to call a vote on changing our by-laws to change
> release votes from 7 days to 5.
>
> I've attached the change to by-laws I'm proposing.
>
> Please vote, the vote will the usual period of 7 days.
+1 (binding)
Verified checksum, signature. Built from src, poked at single-node
cluster, ran some unit tests. -C
On Tue, Feb 11, 2014 at 6:49 AM, Arun C Murthy wrote:
> Folks,
>
> I've created a release candidate (rc0) for hadoop-2.3.0 that I would like to
> get released.
>
> The RC is availabl
Stack-
It's impossible to distinguish uncertainty from concern-trolling on
public lists. "I'm concerned that the right honorable gentleman's rash
may be syphilis. What says the senate?" is not innocent, even if it's
sincere. Speak discreetly to your colleagues, who happen to share your
aversion to
+1
Verified checksum and signature, built tarball, ran some unit tests. -C
On Mon, Oct 7, 2013 at 12:00 AM, Arun C Murthy wrote:
> Folks,
>
> I've created a release candidate (rc0) for hadoop-2.2.0 that I would like to
> get released - this release fixes a small number of bugs and some
> proto
+1
Checksum and signature match, ran some tests. -C
On Mon, Jun 3, 2013 at 1:19 PM, Sandy Ryza wrote:
> +1 (non-binding). Did a full build from source and ran a few sample jobs
> on a pseudo-distributed cluster.
>
> -Sandy
>
>
> On Mon, Jun 3, 2013 at 11:29 AM, Kihwal Lee wrote:
>
>> +1 I've d
+1
Checksum and signature match, ran some unit tests, checked diff
against 2.0.4-alpha.
Thanks for seeing this through, Cos. -C
On Mon, Jun 3, 2013 at 1:13 PM, Alejandro Abdelnur wrote:
> +1 RC2. Verified MD5 & signature, checked CHANGES.txt files, built,
> configured pseudo cluster, run a coup
; Can we limit the vote thread to the merits of the release then?
Happily.
> That sound like adding an insult to injury, if my forth-language skills do not
> mislead me.
They do mislead you, or I've expressed the point imprecisely. We can
take this offline. -C
>> >> > On
1 - 100 of 126 matches
Mail list logo