I think hadoop9 has a similar problem as hadoop8, based on a recent build.
The javac output has a compile-proto error:
https://builds.apache.org/job/PreCommit-HDFS-Build/3755/
https://builds.apache.org/job/PreCommit-HDFS-Build/3755/artifact/trunk/patchprocess/trunkJavacWarnings.txt
On Sun, Jan 6
Verified the tarball checksums. Ran a couple example jobs on a 3 node
cluster successfully, with the same WARN caveat as Bobby.
+1 (non-binding).
On Thu, Feb 7, 2013 at 7:33 AM, Robert Evans wrote:
> I downloaded the binary package and ran a few example jobs on a 3 node
> cluster. Everything se
Hi Niranjan,
Try doing your initial clone from the github mirror instead, I found it to
be much faster:
https://github.com/apache/hadoop-common
I use the apache git for subsequent pulls.
Best,
Andrew
On Tue, Apr 9, 2013 at 6:15 PM, maisnam ns wrote:
> Hi,
>
> I am trying to execute - g
HBase has some nice metrics stuff that's not part of hadoop-common,
including a nifty reservoir sampling histogram / stats class. Would
definitely be nice to pull in.
There's also the MutableQuantiles class in hadoop-common if you want to
calculate a more accurate histogram.
If you're looking for
Thanks for the summary Steve, very useful.
I'm wondering a bit about the point on testing AbstractFileSystem rather
than FileSystem. While these are both wrappers for DFSClient, they're
pretty different in terms of the APIs they expose. Furthermore, AFS is not
actually a client-facing API; clients
27;m looking in the wrong place? Sanjay (or anyone else), could you
> clarify this for us?
>
> Regards
> Steve Watt
>
> - Original Message -
> From: "Andrew Wang"
> To: common-dev@hadoop.apache.org
> Cc: mbhandar...@gopivotal.com, "shv hadoop"
Are these RAT errors related to the previous discussion about running RAT
after tests? I thought we resolved to run RAT prior, since that's what a
release tarball will look like.
On Thu, Oct 29, 2015 at 8:40 AM, Chris Nauroth
wrote:
> +1 to treating it as a bug in Hadoop code if a test writes a
Has anything changed regarding the github integration since the last time
we discussed this? That blog post is from 2014, and we discussed
alternative review systems earlier in 2015.
Colin specifically was concerned about forking the discussion between JIRA
and other places:
http://search-hadoop.
On Thu, Oct 29, 2015 at 2:29 PM, Steve Loughran
wrote:
>
> > On 29 Oct 2015, at 20:34, Andrew Wang wrote:
> >
> > Has anything changed regarding the github integration since the last time
> > we discussed this? That blog post is from 2014, and we discussed
> > a
On Thu, Oct 29, 2015 at 3:12 PM, Owen O'Malley wrote:
> On Thu, Oct 29, 2015 at 1:34 PM, Andrew Wang
> wrote:
>
> > Has anything changed regarding the github integration since the last time
> > we discussed this?
>
>
> There is a lot more experience with i
On Thu, Oct 29, 2015 at 3:29 PM, Owen O'Malley wrote:
> On Thu, Oct 29, 2015 at 2:42 PM, Andrew Wang
> wrote:
>
> >
> > If I had my druthers, we'd focus on Gerrit rather than Github as a
> > successor review system. Better review, better fits our dev wo
On Thu, Oct 29, 2015 at 4:58 PM, Arpit Agarwal
wrote:
> On 10/29/15, 3:48 PM, "Andrew Wang" wrote:
>
>
> > If we pushed for it, I think it could happen.
>
> Gerrit support is a complete unknown. The community response to date
> supports Github integration. Gith
I'm trying to slow this discussion down so we can:
a) Determine the problem(s) we're trying to solve
b) See how the proposed solutions meet this problem
The flood of +1's were made before a full proposal of what "enabling github
integration" means, which has only been really specified in Owen's m
>
>
> >>
> >> > If that's the case, we should also look at review alternatives
> >> > like RB and Crucible.
> >>
> >> Okay by me if the community consensus supports one of them. The fact
> that
> >> they exist but no one uses them is not a ringing endorsement.
> >>
> >> HBase uses reviewboard, as d
>
>
> > 2) Better attribution of contributors with their GH id (Arpit)
> >
>
> This doesn't happen very naturally other than the pull requests are
> typically shown in their fork of the apache repo.
>
> It happens if we used PRs for integration, but yes I agree that it does
not if GH is just used a
On Fri, Oct 30, 2015 at 1:59 PM, Colin P. McCabe wrote:
> I am -1 on the current GH stuff, just because I feel like there wasn't
> enough discussion, testing, and documentation of it. The initial
> proposal had no details and was implemented before any of the people
> who had had misgivings on t
wen O'Malley wrote:
> On Fri, Oct 30, 2015 at 2:37 PM, Andrew Wang
> wrote:
>
> >
> > Strongly agree that we need documentation for all this.
>
>
> Agreed.
>
>
> > Some of my open questions are also still pending.
> >
>
> Which open quest
Has there been any progress on locking down the Github permissions like I
asked above? It's been about 3 weeks.
Steve also just asked on another thread to turn off the emails to
common-dev. Since we're sticking with JIRA as the source-of-truth, the
common-dev emails aren't useful.
On Fri, Nov 13,
t is always happening on Apache git rather than
> > Github. Therefore, there is no disabling required for pull request.
> > Primary activity is still on JIRA, and Github is only a supplement to
> make
> > line by line code review easy. Overall user experience is better than RB
Hey Vinod,
I'm fine with the idea of alpha/beta marking in the abstract, but had a
question: do we define these terms in our compatibility policy or
elsewhere? I think it's commonly understood among us developers (alpha
means not fully tested and API unstable, beta means it's not fully tested
but
vise all newly added configuration properties to make sure they
> follow our general naming patterns. New contributors sometimes create
> non-standard properties that we come to regret supporting.
> - Generate a list of newly added public entry-points and validate that
> they are all ind
Hi all,
Right now we get something like 7 comments from Hudson whenever a change is
committed. Would anyone object if I turned off 6 of them? We have
variations like:
Hadoop-trunk-Commit
Hadoop-Hdfs-trunk-Java8
Hadoop-Yarn-trunk
...etc
I propose leaving notifications on for just Hadoop-trunk-Com
I set up a parameterized branch-2 job during the 2.6.2 release process, so
you can do on-demand builds there for whatever branch:
https://builds.apache.org/view/H-L/view/Hadoop/job/Hadoop-branch2-parameterized/
We already have a nightly branch-2 jobs and the set of flaky tests normally
isn't that
>
>
> maybe discuss having a list @ release time. As an example, s3 and
> encryption at rest shipped in beta stage... what's in 2.8 that "we don't
> yet trust ourselves?". Me, I'd put erasure coding in there just because
> I've no familiarity with it
>
> Quick clarification, EC isn't scheduled for
9:22 AM, Allen Wittenauer wrote:
>
> > On Nov 25, 2015, at 5:41 PM, Andrew Wang
> wrote:
> >
> > Hi all,
> >
> > Right now we get something like 7 comments from Hudson whenever a change
> is
> > committed. Would anyone object if I turned off 6 of the
On Mon, Nov 30, 2015 at 3:04 PM, Allen Wittenauer wrote:
>
> > On Nov 30, 2015, at 11:33 AM, Andrew Wang
> wrote:
> >
> > Good point Allen. So I guess the broader question is, do we find the
> > per-commit tracking build and test useful? With our current flakines
to Hadoop-trunk-Commit, feel free to
append more stuff as desired.
On Mon, Nov 30, 2015 at 3:11 PM, Andrew Wang
wrote:
>
> On Mon, Nov 30, 2015 at 3:04 PM, Allen Wittenauer
> wrote:
>
>>
>> > On Nov 30, 2015, at 11:33 AM, Andrew Wang
>> wrote:
>> >
>&
> eclipse... -C
>
> On Wed, Oct 7, 2015 at 2:31 PM, Andrew Wang
> wrote:
> > Hi all,
> >
> > I happened to see this on the maven list, looks like the Maven eclipse
> > plugin (aka "eclipse:eclipse") is being retired.
> >
> > Our BUILDI
My 2c is that we should have monotonicity in releases. That way no
"upgrade" is a regression.
On Wed, Dec 23, 2015 at 10:00 PM, Tsuyoshi Ozawa wrote:
> Hi Vinod,
>
> thank you for the clarification.
>
> > - Pull these 16 tickets into 2.7.2 and roll a new RC
> > > What do people think? Do folks
I like monotonic releases since it's simple for users to understand. Is it
difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
don't follow why special casing some class of fixes is desirable.
Also for maintenance releases, aren't all included fixes supposed to be for
serious
I just turned off some checkstyle warnings at HADOOP-12713, namely the
"file is too long" warning whenever you modify an existing big file.
Steve, if you want to make indentation more flexible, feel free to file a
patch and I'll +1. The overall response on this thread seems positive.
Best,
Andrew
se of JDK8 language features (and, presumably, APIs)
> means you've abandoned #1, i.e., you haven't (really) bumped the JDK
> source version to JDK8.
>
> Also, note that releasing from trunk is a way of achieving #3, it's
> not a way of abandoning it.
>
>
&g
.
Best,
Andrew
On Thu, Feb 18, 2016 at 2:50 PM, Kihwal Lee
wrote:
> Moving Hadoop 3 forward sounds fine. If EC is one of the main motivations,
> are we getting rid of branch-2.8?
>
> Kihwal
>
> From: Andrew Wang
> To: "common-dev@hadoop.apache.org"
>
er to be done in the major release.
>
> Regards,
> Kai
>
> -Original Message-
> From: Andrew Wang [mailto:andrew.w...@cloudera.com]
> Sent: Friday, February 19, 2016 7:04 AM
> To: hdfs-...@hadoop.apache.org; Kihwal Lee
> Cc: mapreduce-...@hadoop.apache.org; common-dev@
Hi Junping, thanks for the mail, inline:
On Sat, Feb 20, 2016 at 7:34 AM, Junping Du wrote:
> Shall we consolidate effort for 2.8.0 and 3.0.0? It doesn't sounds
> reasonable to have two alpha releases to go in parallel. Is EC feature the
> main motivation of releasing hadoop 3 here? If so, I don
Hi Kai,
Could you file a JIRA and post patch to disable that checkstyle rule? You
can look at HADOOP-12713 for an example. Ping me and I'll review.
Best,
Andrew
On Sun, Feb 28, 2016 at 11:28 PM, Zheng, Kai wrote:
> Hi,
>
> I'm wondering if we could get rid of the style checking in getters like
Hi all,
I wanted to ask a release-related question. Right now, the RC tarball we
vote on is not the same as the released tarball. This is because one of the
publishing steps is to edit CHANGES.txt to include the release date and
rebuild:
https://wiki.apache.org/hadoop/HowToRelease
I don't like t
appy if someone else wants to take it up.
Best,
Andrew
On Wed, Mar 2, 2016 at 8:06 PM, Karthik Kambatla wrote:
> I'm fine with dropping this step.
> I can't help but bring it up again, shouldn't we drop the CHANGES.txt
> altogether?
>
> Get Outlook
>
>
the above welcome as always.
Best,
Andrew
On Wed, Mar 2, 2016 at 9:46 PM, Akira AJISAKA
wrote:
> I'm fine with deleting CHANGES.txt in branch-2/branch-2.8.
> https://issues.apache.org/jira/browse/HADOOP-11792
>
> Thanks,
> Akira
>
>
> On 3/3/16 13:55, Andrew Wan
Hi all,
With the inclusion of HADOOP-12651 going back to branch-2.8, CHANGES.txt
and release notes are now generated by Yetus. I've gone ahead and deleted
the manually updated CHANGES.txt from trunk, branch-2, and branch-2.8
(HADOOP-11792). Many thanks to Allen for the releasedocmaker.py rewrite,
A branch sounds fine, but how are we going to get 3 +1's to merge it? If
it's hard to find one reviewer, seems even harder to find two.
On Tue, Mar 22, 2016 at 10:56 AM, Allen Wittenauer <
allenwittena...@yahoo.com.invalid> wrote:
>
> > On Mar 22, 2016, at 10:49 AM, larry mccay wrote:
> >
> > Th
As I expressed on HDFS-8791, I do not want to include this JIRA in a
maintenance release. I've only seen it crop up on a handful of our
customer's clusters, and large users like Twitter and Yahoo that seem to be
more affected are also the most able to patch this change in themselves.
Layout upgrad
One other thing I wanted to bring up regarding HDFS-8791, we haven't
backported the parallel DN upgrade improvement (HDFS-8578) to branch-2.6.
HDFS-8578 is a very important related fix since otherwise upgrade will be
very slow.
On Thu, Mar 31, 2016 at 10:35 AM, Andrew Wang
wrote:
&
gt; > (2) Just let specific users backport this into specific 2.x branches
> they
> > need and leave it only on trunk.
> >
> > Unless this behavior stops breaking rolling upgrades/downgrades, I think
> > we should just revert it from branch-2 and definitely 2.7.3 as it
tch in so
> >> it's slightly less visible.
> >> >
> >> > That means 3.0 is going to be an alpha release, not final.
> >> >
> >> > one thing that could be shared is any build.xml automation of the
> >> release process, to at least take a
What does "fix" mean? We aren't supposed to force push to non-feature
branches, and actually thought this was disabled.
Also FYI for the future, we normally format our commit messages with
periods, e.g.:
HADOOP-13011. Clearly Document the Password Details for Keystore-based
Credential Providers.
to "fix" it?
>
> Again, sorry for the inconvenience.
>
> On Fri, Apr 22, 2016 at 12:10 AM, Andrew Wang
> wrote:
>
> > What does "fix" mean? We aren't supposed to force push to non-feature
> > branches, and actually thought this was disabled.
Great comments Vinod, thanks for replying.
Since trunk is a superset of branch-2.8, I think the two efforts are mostly
aligned. The 2.8 blockers are likely also 3.0 blockers. For example, the
create-release and L&N JIRAs I mentioned are in this camp. The difference
between the two is the expectati
Hi all,
I wanted to confirm my version numbering plan for Hadoop 3.x. We had a
related thread on this topic about a year ago, mostly focusing on the
branch-2 maintenance releases:
http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201504.mbox/%3CFAA30A53-C2BD-4380-9245-C8DBEC7BF386%40hort
On Mon, May 2, 2016 at 2:00 PM, Roman Shaposhnik
wrote:
> On Mon, May 2, 2016 at 1:50 PM, Andrew Wang
> wrote:
> > Hi all,
> >
> > I wanted to confirm my version numbering plan for Hadoop 3.x. We had a
> > related thread on this topic about a year ago, mostl
>
> >> but I'm going to spend time on our first RC this week.
> Sorry what does this mean? Did you mean the first RC version or
> 3.0.0-alpha1 will be cut out this week?
> Anyway will try to get some tasks done sooner.
>
> First RC for whatever we name the first 3.0 alpha release.
There's no need
Does anyone have any pull with INFRA? I ping'd INFRA-11236 but it's
unassigned and been dormant for a while.
On Tue, May 3, 2016 at 3:07 PM, Allen Wittenauer wrote:
>
>
> Just a heads up that I accidentally forced push over branch-2 and
> branch-2.8 (in the process of pushing a feature b
://infra.chat/
>
> --Chris Nauroth
>
>
>
>
> On 5/3/16, 3:45 PM, "Andrew Wang" wrote:
>
> >Does anyone have any pull with INFRA? I ping'd INFRA-11236 but it's
> >unassigned and been dormant for a while.
> >
> >On Tue, May 3, 2016 at 3:
+1
On Tue, May 10, 2016 at 12:36 PM, Ravi Prakash wrote:
> +1. Thanks for driving this Akira
>
> On Tue, May 10, 2016 at 10:25 AM, Tsuyoshi Ozawa wrote:
>
> > > Before cutting 3.0.0-alpha RC, I'd like to drop JDK7 support in trunk.
> >
> > Sounds good. To do so, we need to check the blockers of
Why don't we address these on a case-by-case basis, changing the
annotations on these key classes to Public? LimitedPrivate{"YARN
applications"} is the same thing as Public.
This way we don't need to add special exceptions to our compatibility
policy. Keeps it simple.
Best,
Andrew
On Tue, May 10
Hi all,
Sounds like we have general agreement on this release numbering scheme for
3.x.
I'm going to attempt some mvn and JIRA invocations to get the version
numbers lined up for alpha1, wish me luck.
Best,
Andrew
On Tue, May 3, 2016 at 9:52 AM, Roman Shaposhnik
wrote:
> On Tue, May 3, 2016 a
On Thu, May 12, 2016 at 11:01 AM, Gangumalla, Uma
wrote:
> Thanks Andrew for driving. Sounds good. Go ahead please.
>
> Good luck :-)
>
> Regards,
> Uma
>
> On 5/12/16, 10:52 AM, "Andrew Wang" wrote:
>
> >Hi all,
> >
> >Sounds like we have gen
Try asking on infra.chat (Apache INFRA's hipchat). I was in that room
earlier today, and they were working on the ongoing JIRA spam.
On Thu, May 12, 2016 at 3:03 PM, Xiao Chen wrote:
> Hello,
>
> I'm not sure if common-dev is the right contact list, please redirect me if
> not.
>
> It seems the
+1. I looked at the patches on the branch, wasn't too bad to review. As
Allen said, there's some code movement, assorted other nice doc and shell
fixups.
Found one extra typo, which I added to HADOOP-13129.
Best,
Andrew
On Wed, May 11, 2016 at 1:14 AM, Sean Busbey wrote:
> +1 (non-binding)
>
>
Hi common-dev,
We have a first cut of the L&N files on HADOOP-12893. Many thanks to Xiao
Chen and Akira Ajisaka for doing the brunt of this work. However, full ASF
compliance will require a lot more Maven work. In the meanwhile, our
releases are blocked.
We're thinking about a "fix-and-iterate" a
I just gave you committer permissions on JIRA, try now?
On Mon, May 16, 2016 at 12:03 AM, Zheng, Kai wrote:
> I just ran into the bad situation that I committed HDFS-8449 but can't
> resolve the issue due to lacking the required permission to me. Am not sure
> if it's caused by my setup or envir
Very happy to announce that we've committed HADOOP-11858. I'm looking
forward to writing my first lambda in Java. I also attached a video to the
JIRA so we can all relive this moment in Hadoop development history.
It sounds like there's some precommit work to align test-patch with this
change. I'm
t;> On Mon, May 16, 2016 at 5:22 PM, Junping Du
> > > > wrote:
> > > > >>
> > > > >> Someone fix the permission issue so that Administrator, committer
> > and
> > > > >>> reporter can edit the issue now.
> > > &g
o say "the src tarball is the only official release artifact, the
bin tarball and jars are only provided as a convenience", but I don't think
we're actually allowed to do that.
On Tue, May 17, 2016 at 1:56 AM, Steve Loughran
wrote:
>
> > On 16 May 2016, at 02:43, An
s we want to achieve for alpha1? From EC's
> perspective, maybe we should target on having all compatibility-related
> changes in alpha1, like new config keys and fsimage format?
>
> Thanks,
>
> On Thu, May 12, 2016 at 11:35 AM Andrew Wang
> wrote:
>
>> Hi folks,
&g
I'm in favor of something that helps unify the current mess of Jenkins
jobs. We do something similar for our internal Hadoop repo: each branch has
a "build.sh" and "test.sh" script that builds and then runs the tests. This
predates Yetus, else we'd probably have used that. So +1 from me.
One thing
To clarify what happened here, I moved the commits to a feature branch, not
just reverting the commits. The intent was to make it easy to merge back in
later, and also to unblock the 2.8 and 3.0 releases we've been trying very
hard to wrap up for weeks. This doesn't slow down development since you
I'm not super happy about the alternative of reverting the auto-generated
CHANGES/RL JIRAs, since it means we have to do CHANGES.txt maintenance
again in branch-2. That's an overhead that we pay for every commit, and
it's particularly bad when doing backports.
As I commented on HADOOP-12892, I thi
Hi all,
On a separate thread, a question was raised about 3.x branching and use of
feature branches going forward.
We discussed this previously on the "Looking to a Hadoop 3 release" thread
that has spanned the years, with Vinod making this proposal (building on
ideas from others who also comment
gt; is a
>> >> much more tricky question (related to trunk-incompat etc.). But per my
>> >> comment above, IMHO, *not committing uncompleted work to trunk* should
>> be a
>> >> much easier principle to agree upon.
>> >>
>> >>
>>
On Fri, Jun 10, 2016 at 9:39 PM, Karthik Kambatla
wrote:
> I would like to understand the trunk-incompat part of the proposal a
> little better.
>
> Is trunk-incompat always going to be a superset of trunk? If yes, is it
> just a change in naming convention with a hope that our approach to trunk
>
> I agree with the concerns you raise around feature rot. For a feature like
>> EC, it'd be untenable to leave it in trunk-incompat since the rebases would
>> be impossible. I imagine we'd also need a very motivated maintainer (or
>> maintainers) to handle the periodic integration of new trunk co
This vote from last year covers some of it, says to use "git merge --no-ff"
and tags. With merge, I believe the history is propagated correctly.
https://lists.apache.org/thread.html/43cd65c6b6c3c0e8ac2b3c76afd9eff1f78b177fabe9c4a96d9b3d0b@1440189889@%3Ccommon-dev.hadoop.apache.org%3E
I never got
You can also look for JIRAs with the "newbie" label, Eli's JIRA filter is
handy here:
https://issues.apache.org/jira/issues/?filter=12315566
I'd even refine it by looking for recent unresolved, unassigned JIRAs with
this query:
project in (HADOOP, MAPREDUCE, HDFS) AND labels = newbie AND status
Hi all,
I wanted to broadcast plans for putting the FileSystem symlinks work
(HADOOP-8040) into branch-2.1 for the pending Hadoop 2 GA release. I think
it's pretty important we get it in since it's not a compatible change; if
it misses the GA train, we're not going to have symlinks until the next
Hey all,
Sorry to hijack the vote thread, but it'd be good to get some input on my
email from yesterday re: symlink support in branch-2.1. I think it really
should be in GA one way or the other.
http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201309.mbox/%3CCAGB5D2ZDjqt69oFfv_HOsWEH18T
by adding possibly newer APIs and
> leaving
> > existing APIs as is. If this can be done, my vote is to enable this
> feature
> > in 2.3. Even if it cannot be done, I am concerned that this is coming
> quite
> > late and we should see if could allow some incompatible cha
We still need to resolve some symlink issues; are we planning to spin a new
RC? Leaving it as-is is not a good option.
On Sun, Sep 22, 2013 at 11:23 PM, Roman Shaposhnik wrote:
> On Mon, Sep 16, 2013 at 11:38 PM, Arun C Murthy
> wrote:
> > Folks,
> >
> > I've created a release candidate (rc0)
Hey Arun,
That plan sounds good to me, thanks for being on top of things. What's the
new fix version we should be using (2.1.2 or 2.2.0)? Would be good to get
the same clarification regarding which branches should be receiving
commits. I think a 2.1.2 would be nice to get the symlinks changes in a
HADOOP-9984 is going to break interface compatibility for out-of-tree
FileSystems. It'd also be good to let downstream components do some testing
before GA.
Thanks,
Andrew
On Tue, Oct 1, 2013 at 5:18 PM, Jagane Sundar wrote:
> +1
> Makes good sense.
>
> Jagane
>
> -Original Message-
>
If we're serious about not breaking compatibility after GA, then we need to
slow down and make sure we get these new APIs right, or can add them in a
compatible fashion.
HADOOP-9984 ended up being a bigger change than initially expected, and we
need to break compatibility with out-of-tree FileSyst
Colin posted a summary of our phone call yesterday (attendees: myself,
Colin, Daryn, Nathan, Jason, Chris, Suresh, Sanjay) on HADOOP-9984:
https://issues.apache.org/jira/browse/HADOOP-9984?focusedCommentId=13785701&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13785
Hello all,
I'd like to call a vote to merge the HDFS-4949 branch (in-memory caching)
to trunk. Colin McCabe and I have been hard at work the last 3.5 months
implementing this feature, and feel that it's reached a level of stability
and utility where it's ready for broader testing and integration.
Hey folks,
I've been seeing some reports about search results for Hadoop being broken
because stable now points to the v2 docs, where a lot of stuff has moved
around.
e.g.
http://hadoop.apache.org/docs/stable/fair_scheduler.html (404, first result
on google for "hadoop fair scheduler")
http://ha
shot test
> >> plan
> >> > that was posted to HDFS-2802. For my own part, I've run the new unit
> >> > tests, and I've tested end-to-end in a pseudo-distributed deployment.
> >> It's
> >> > unlikely that I'll get a chance to test fully di
I'm in agreement with Steve on this one. We're aware that Java 6 is EOL,
but we can't drop support for the lifetime of the 2.x line since it's a
(very) incompatible change. AFAIK a 3.x release fixing this isn't on any of
our horizons yet.
Best,
Andrew
On Thu, Oct 31, 2013 at 6:15 AM, Robert Rati
to trunk, we will continue to test and fix any bugs that may be
> found on trunk as well as add further tests as outlined in the test plan.
>
> The bulk of the design and implementation was done by Suresh Srinivas,
> Sanjay Radia, Nicholas Sze, Junping Du and me. Also, thanks to Eric
port which can
> > align with the 2.5 time frame, with the second merge potentially in
> > March/April.
> >
> > Arpit
> >
> >
> > On Fri, Dec 6, 2013 at 3:15 PM, Andrew Wang > >wrote:
> >
> > > Hi everyone,
> > >
> > >
Hi Karthiek,
I haven't checked 1.0.4, but in 2.2.0 and onwards, there's this setting you
can tweak up:
dfs.datanode.balance.bandwidthPerSec
By default, it's set to just 1MB/s, which is pretty slow. Again at least in
2.2.0, there's also `hdfs dfsadmin -setBalancerBandwidth` which can be used
to a
Hi Dhaivat,
I did a good chunk of the design and implementation of HDFS-4949, so if you
could post a longer writeup of your envisioned use cases and
implementation, I'd definitely be interested in taking a look.
It's also good to note that HDFS-4949 is only the foundation for a whole
slew of pote
Hi all,
Could someone give my wiki account edit permissions? Username is
"AndrewWang".
Thanks,
Andrew
n do the same for my account too?
> > >
> > > My Hadoop wiki username is ArpitAgarwal
> > >
> > > Thanks!
> > >
> > >
> > > On Fri, Jan 3, 2014 at 4:54 PM, Andrew Wang > >wrote:
> > >
> > >> Hi al
Hi all,
The 0.23 nightly Jenkins build has been broken since we bumped the protobuf
version. I briefly poked around but didn't see an obvious way of fixing it
from Jenkins, so I just disabled it so it'll stop sending us emails. If
someone is still interested in this build, feel free to fix it and
Hi all,
I'm pretty excited to see a 2.4 this month if possible. Since I think
people were favorable to the idea of time-based releases, how do we feel
about just cutting branch-2 and spinning up the release process for our
January goal?
Looking at the roadmap (https://wiki.apache.org/hadoop/Roadm
elease 2.4 end of the month
> > (after a bit more testing of RM HA in secure mode). Thanks for the offer,
> > I'll ping you if I need any help.
> >
> > OTOH, can someone from HDFS chime in on status of symlinks?
> >
> > Arun
> >
> > On Jan 20, 201
here are a bunch of major
> > things that are still missing there: YARN-1202, YARN-1410, YARN-1525 and
> > YARN-1611/YARN-1459.
> >
> > We need to start labeling individual features alpha/beta/stable now that
> > we have a stable 2.2 base.
> >
> > Thanks
> >
s a week? That seems
> like a terrible overhead.
> - What about downstream projects? BigTop is in with these monthly cycles?
>
> Thanks,
> +vinod
>
>
> On Jan 22, 2014, at 12:04 PM, Andrew Wang
> wrote:
>
> Thanks for the comments everyone.
>
> Vinod, i
Hi Arun, thanks for the reply. I hope that I've come across as an earnest
and motivated contributor who wants to help make high-quality releases.
Volunteering myself as RM and pushing for a 2.4 was not a reflection on
your stewardship of 2.x so far. I know it's a lot of work.
I didn't mean to sugg
I just finished tuning up branch-2.3 and fixing up the HDFS and Common
CHANGES.txt in trunk, branch-2, and branch-2.3. I had to merge back a few
JIRAs committed between the swizzle and now where the fix version was 2.3
but weren't in branch-2.3.
I think the only two HDFS and Common JIRAs that are
I added you as a contributor on Hadoop Common, let me know if you need
anything else.
I've hit that annoying dialog box before too, but what works for me is
using a private browsing window. Todd posited that the error is due to
stale cookies after a JIRA upgrade, and this fixes it.
On Thu, Jan 3
1 - 100 of 616 matches
Mail list logo
