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
The throughput on this thread is too high.
Nicholas/Suresh: do either of you disagree with the general approach
in HDFS-347? Holding an inevitable branch open causes a lot of pain
(Suresh, you endured much of that personally with security, which had
a lot of follow-on work). While it makes sense t
On Wed, Feb 20, 2013 at 5:12 PM, Aaron T. Myers wrote:
> Given that the only substantive concerns with HDFS-347 seem to be about
> Windows support for local reads, for now we only merge this branch to
> trunk. Support for doing HDFS-2246 style local reads will be removed from
> trunk, but retained
On Mon, Feb 25, 2013 at 1:16 PM, Eli Collins wrote:
> I think we need a transition period when any kinks are worked out of
> 347 but I don't think we need one alpha/beta release where both
> mechanisms are supported (because 2246 was just a short term solution
> rather than a long term commitment)
Eli, you've sent the same email a half dozen times in the last ~24
hours. You might try a different tactic.
Suresh, if you're willing to "support and maintain" HDFS-2246, do you
have cycles to propose a patch to the HDFS-347 branch reintegrating
HDFS-2246 with the simplifications you outlined? In
the 2.x branch. FWIW, I
think that's the compromise solution. -C
> On Feb 20, 2013, at 4:29 PM, Chris Douglas wrote:
>
>> There's
>> ample precedent for retaining obscure, clumsy features as a temporary
>> stop-gap (e.g., service plugins, opaque blobs of bytes in
Konstantin-
There's no debate on the necessity of CI and related infrastructure to
support the platform well. Suresh outlined the support to effect this
here: http://s.apache.org/s1
Is the commitment to establish this infrastructure after the merge
sufficient? -C
On Fri, Mar 1, 2013 at 12:18 PM,
On Fri, Mar 1, 2013 at 1:57 PM, Konstantin Shvachko
wrote:
> Commitment is a good thing.
> I think the two builds that I proposed are a prerequisite for Win support.
> If we commit windows patch people will start breaking it the next day.
> Which we wont know without the nightly build and wont be
+1
Verified checksums and signatures, ran some tests, built the tarball. -C
On Thu, Apr 11, 2013 at 12:55 PM, Thomas Graves wrote:
> I've created a release candidate (RC0) for hadoop-0.23.7 that I would like
> to release.
>
> This release is a sustaining release with several important bug fixes
+1
Verified checksum, signatures. Ran some tests, built the package. -C
On Fri, Apr 12, 2013 at 2:56 PM, Arun C Murthy wrote:
> Folks,
>
> I've created a release candidate (RC2) for hadoop-2.0.4-alpha that I would
> like to release.
>
> The RC is available at:
> http://people.apache.org/~acmur
You're not missing anything, but the probability of a 16 (thought it
was 20?) byte collision with random bytes is vanishingly small. -C
On Sat, Apr 27, 2013 at 4:30 AM, Hs wrote:
> Hi,
>
> I am learning hadoop. I read the SequenceFile.java in hadoop-1.0.4 source
> codes. And I find the sync(long
On Wed, May 1, 2013 at 6:24 PM, Arun C Murthy wrote:
> Having a strict policy leads to all sorts of further dialogues and issues we
> could do well without.
+1
Can anyone remember why we vote on release plans? -C
On Thu, May 2, 2013 at 2:11 AM, Konstantin Shvachko
wrote:
> On Thu, May 2, 2013 at 12:07 AM, Chris Douglas wrote:
>> Can anyone remember why we vote on release plans? -C
>
> To vote on features to include in the release.
Since most features are developed in branches (requiri
+1
Checksum and signature match, ran some unit tests, verified w/ a diff
of release-2.0.4-alpha that the release contains MAPREDUCE-5240 and
HADOOP-9407, plus some fixups to the release notes. -C
On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik wrote:
> All,
>
> I have created a release candi
On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy wrote:
> Why not include MAPREDUCE-4211 as well rather than create one release per
> patch?
>From Cos's description, it sounded like these were backports of fixes
to help Sqoop2 and fix some build issues. If it's not just to fixup
leftover bugs in
n. I changed my vote instead of trusting you. -C
> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy wrote:
>> > Why not include MAPREDUCE-4211 as well rather than create one release per
>> > patch?
>>
>>
based on recent experience
I don't expect you to forgo it. I'd be happy to learn my caution is
unnecessary. -C
>> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy
>> >> wrote:
>> >
; 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
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
+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
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
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 (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
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,
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
+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
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
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
+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
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
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
+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
+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.
>
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
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
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
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
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&
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
+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
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
[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
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]
>
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,
+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
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
. -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
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
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
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
+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
> 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
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
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
>>
>>
>>
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
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
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
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
>>
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
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
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
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
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
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
> 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
+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
+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
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
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.
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 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
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 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 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 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
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 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 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:
>>
+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
- 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
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
+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
+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 -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
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
On Thu, Jun 25, 2009 at 11:42 PM, Nigel Daley wrote:
> Here are some logos for the new subprojects
> http://www.flickr.com/photos/88199...@n00/3661433605/
>
> Please vote +1 if you like 'em and -1 if you don't.
>
> Cheers,
> Nige
>
+1 This fix has been in limbo for a long time; thanks for finishing
it, Nicholas. -C
On Mon, Oct 19, 2009 at 2:34 PM, Tsz Wo (Nicholas), Sze
wrote:
> DFSClient has a retry mechanism on block acquiring for read. If the number
> of retries attends to a certain limit (defined by
> dfs.client.max.
This month, the MapReduce + HDFS contributor meeting was held at
Cloudera Headquarters.
Announcements for contributor meetings are here:
http://www.meetup.com/Hadoop-Contributors/
Minutes follow. No decisions were made at this meeting, but the
following issues were discussed and may presage futur
It was part of a suite of DAG tools driven by ant, e.g. HADOOP-2778. I
doubt it's still used and it can probably be removed. -C
On Fri, Jul 22, 2011 at 2:21 PM, Eli Collins wrote:
> +hdfs-dev -general (bcc)
>
> None of src/ant actually looks hdfs specific (part of FsShell), should
> we move it t
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
[
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-12417:
Summary: Disable flaky TestDFSStripedOutputStreamWithFailure
Key: HDFS-12417
URL: https://issues.apache.org/jira/browse/HDFS-12417
Project: Hadoop HDFS
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
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
[
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
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
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-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
[
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
[
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
1 - 100 of 126 matches
Mail list logo
