Re: [VOTE] Release Apache Hadoop 2.8.0 (RC3)

+1 (binding) * Built from source * Started a pseudo-distributed cluster with fairscheduler. * Ran sample jobs * Verified WebUI On Wed, Mar 22, 2017 at 11:56 AM, varunsax...@apache.org < varun.saxena.apa...@gmail.com> wrote: > Thanks Junping for creating the release. > > +1 (non-binding) > > *

[jira] [Resolved] (MAPREDUCE-6506) Make the reducer-preemption configs consistent in how they handle defaults

[ https://issues.apache.org/jira/browse/MAPREDUCE-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik Kambatla resolved MAPREDUCE-6506. - Resolution: Not A Problem Target Version/s: (was: ) Closing

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha2 RC0

iles within jars > should not reset the clock on the VOTE. -C > > > On Wed, Jan 25, 2017 at 11:14 AM, Karthik Kambatla <ka...@cloudera.com> > > wrote: > > > >> Thanks for driving the alphas, Andrew. I don't see the need to restart > the > >> vote an

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha2 RC0

Thanks for driving the alphas, Andrew. I don't see the need to restart the vote and I feel it is okay to fix the minor issues before releasing. +1 (binding). Downloaded source, stood up a pseudo-distributed cluster with FairScheduler, ran example jobs, and played around with the UI. Thanks

Re: [VOTE] Release cadence and EOL

Given the discussions, I feel we are not ready for VOTE on this yet. Sangjin, should we go back to the DISCUSS thread? IMO, these are guidelines and not policies we want to enforce. Maybe, the text should say something along the lines of: "The Hadoop community is inclined to". And, maybe, a

Re: [VOTE] Release cadence and EOL

+1 I would also like to see some process guidelines. I should have brought this up on the discussion thread, but I thought of them only now :( - Is an RM responsible for all maintenance releases against a minor release, or finding another RM to drive a maintenance release? In the past,

Re: [DISCUSS] Release cadence and EOL

topic has aged quite a bit in the discussion thread. Should > we take it to a vote? Do we need additional discussions? > > Regards, > Sangjin > > On Wed, Nov 9, 2016 at 11:11 PM, Karthik Kambatla <ka...@cloudera.com> > wrote: > >> Fair points, Sangjin and Andrew.

Re: Updated 2.8.0-SNAPSHOT artifact

rs to the list before we release then I'd rather stay where >> > we're at and ship it ASAP. >> > >> > Jason >> > (1) https://issues.apache.org/jira/issues/?jql=project%20in% >> > 20%28hadoop%2C%20yarn%2C%20mapreduce%2C%20hdfs%29% >> > 20and%20re

Re: [DISCUSS] Release cadence and EOL

r. >>> > >>> > The proposal is a minor release on the latest major line every 6 >>> months, >>> > and a maintenance release on a minor release (as there may be >>> concurrently >>> > maintained minor releases) every 2 months. >>&g

Re: Updated 2.8.0-SNAPSHOT artifact

Is there value in releasing current branch-2.8? Aren't we better off re-cutting the branch off of branch-2? On Tue, Oct 25, 2016 at 12:20 AM, Akira Ajisaka wrote: > It's almost a year since branch-2.8 has cut. > I'm thinking we need to release 2.8.0 ASAP. > >

Re: Chrome extension to collapse JIRA comments

Never included the link :) https://github.com/gezapeti/jira-comment-collapser On Mon, Oct 17, 2016 at 6:46 PM, Karthik Kambatla <ka...@cloudera.com> wrote: > Hi folks > > Sorry for the widespread email, but thought you would find this useful. > > My colleague, Pe

Chrome extension to collapse JIRA comments

Hi folks Sorry for the widespread email, but thought you would find this useful. My colleague, Peter, had put together this chrome extension to collapse comments from certain users (HadoopQA, Githubbot) that makes tracking conversations in JIRAs much easier. Cheers! Karthik

Re: [VOTE] Release Apache Hadoop 2.6.5 (RC1)

Thanks for putting the RC together, Sangjin. +1 (binding) Built from source, deployed pseudo distributed cluster and ran some example MR jobs. On Fri, Oct 7, 2016 at 6:01 PM, Yongjun Zhang wrote: > Hi Sangjin, > > Thanks a lot for your work here. > > My +1 (binding). > >

Re: [DISCUSS] Release cadence and EOL

> > > Here is just an idea to get started. How about "a minor release line is > EOLed 2 years after it is released or there are 2 newer minor releases, > whichever is sooner. The community reserves the right to extend or shorten > the life of a release line if there is a good reason to do so." > >

[DISCUSS] Release cadence and EOL

Forking off this discussion from 2.6.5 release thread. Junping and Chris T have brought up important concerns regarding too many concurrent releases and the lack of EOL for our releases. First up, it would be nice to hear from others on our releases having the notion of EOL and other

Re: [Release thread] 2.6.5 release activities

Since there is sufficient interest in 2.6.5, we should probably do it. All the reasons Allen outlines make sense. That said, Junping brings up a very important point that we should think of for future releases. For a new user or a user that does not directly contribute to the project, more stable

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

we should bump up trunk version to 4.x for landing new incompatible > changes. > > Thanks, > > Junping > ________ > From: Karthik Kambatla <ka...@cloudera.com> > Sent: Monday, August 08, 2016 6:54 PM > Cc: common-...@hadoop.apache.org;

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I like the 3.0.0-alphaX approach primarily for simpler understanding of compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing because, it is not immediately clear that 3.0.0 and 3.1.0 could be incompatible in APIs. I am open to something like 2.98.x for alphas and 2.99.x for

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Inline. > >> BTW, I never see we have a clear definition for alpha release. It is >> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.) >> but sometimes means unstable in production quality (2.7.0). I think we >> should clearly define it with major consensus so user won't

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Inline. > 1) Set the fix version for all a.b.c versions, where c > 0. > 2) For each major release line, set the lowest a.b.0 version. > Sounds reasonable. > > The -alphaX versions we're using leading up to 3.0.0 GA can be treated as > a.b.c versions, with alpha1 being the a.b.0 release. >

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

IIRR, the vote is on source artifacts and binaries are for convenience. If that is right, I am open to either options - do another RC or continue this vote and fix the binary artifacts. On Tue, Jul 26, 2016 at 12:11 PM, Vinod Kumar Vavilapalli < vino...@apache.org> wrote: > Thanks Daniel and

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

+1 (binding) * Downloaded and build from source * Checked LICENSE and NOTICE * Pseudo-distributed cluster with FairScheduler * Ran MR and HDFS tests * Verified basic UI On Sun, Jul 24, 2016 at 1:07 PM, larry mccay wrote: > +1 binding > > * downloaded and built from source >

Re: [DISCUSS] Increased use of feature branches

Thanks for clarifying Andrew. Inline. On Mon, Jun 13, 2016 at 3:59 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > > On Fri, Jun 10, 2016 at 9:39 PM, Karthik Kambatla <ka...@cloudera.com> > wrote: > >> I would like to understand the trunk-incompat part of t

Re: [DISCUSS] Increased use of feature branches

ous and significant: >>> >> > - A lot of commits (incompatible, risky, uncompleted feature, etc.) >>> have >>> >> > to wait to commit to trunk or put into a separated branch that could >>> >> delay >>> >> > feature development

Re: [DISCUSS] Increased use of feature branches

ing the approach for 3.x. The new proposal forces following these requirements and hence I like it more. > > Thanks, > > Junping > > From: Karthik Kambatla <ka...@cloudera.com> > Sent: Friday, June 10, 2016 7:49 AM > To: Andrew Wang > Cc: common-...@hado

Re: [DISCUSS] Increased use of feature branches

Thanks for restarting this thread Andrew. I really hope we can get this across to a VOTE so it is clear. I see a few advantages shipping from trunk: - The lack of need for one additional backport each time. - Feature rot in trunk Instead of creating branch-3, I recommend creating

Re: Looking to a Hadoop 3 release

I am with Vinod on avoiding merging mostly_complete_branches to trunk since we are not shipping any release off it. If 3.x releases going off of trunk is going to help with this, I am fine with that approach. We should still make sure to keep trunk-incompat small and not include large features.

[jira] [Created] (MAPREDUCE-6673) Add a test example job that grows in memory usage over time

Karthik Kambatla created MAPREDUCE-6673: --- Summary: Add a test example job that grows in memory usage over time Key: MAPREDUCE-6673 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6673

[jira] [Created] (MAPREDUCE-6669) Jobs with encrypted spills don't tolerate AM failures

Karthik Kambatla created MAPREDUCE-6669: --- Summary: Jobs with encrypted spills don't tolerate AM failures Key: MAPREDUCE-6669 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6669 Project

[jira] [Created] (MAPREDUCE-6638) Jobs with encrypted spills don't recover if the AM goes down

Karthik Kambatla created MAPREDUCE-6638: --- Summary: Jobs with encrypted spills don't recover if the AM goes down Key: MAPREDUCE-6638 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6638

Re: MAPREDUCE-6520 and MAPREDUCE-6543 review request

Dustin, one of us could definitely review the patches, but I highly encourage involving folks in the community (and networking with them) for non-urgent patches. Tsuyoshi is a cool guy and is generally keen on test cleanups, as you can see from his chiming in on this JIRA. Want to try hitting him

Re: [Release thread] 2.8.0 release activities

Thanks Vinod. Not labeling 2.8.0 stable sounds perfectly reasonable to me. Let us not call it alpha or beta though, it is quite confusing. :) On Wed, Feb 3, 2016 at 8:17 PM, Gangumalla, Uma wrote: > Thanks Vinod. +1 for 2.8 release start. > > Regards, > Uma > > On

Re: [UPDATE] New ASF git policy on force-pushes / Tags / Stale branches

Filed https://issues.apache.org/jira/browse/INFRA-11136 On Mon, Jan 25, 2016 at 3:41 PM, Vinod Kumar Vavilapalli wrote: > I believe this is still in place, though I am not sure how we can verify > this (without doing a force-push of course) > > +Vinod > > > One thing that

Re: [UPDATE] New ASF git policy on force-pushes / Tags / Stale branches

+1 on all counts. One thing that wasn't clear from the INFRA announcement: are trunk, branch-* branches protected against force-pushes in the new world? If not, should we ask them to be locked up? Thanks Karthik On Thu, Jan 14, 2016 at 10:26 PM, Vinod Kumar Vavilapalli < vino...@apache.org>

Highlighting communication on releases

Hi folks In the last few months, we have been shipping multiple releases - maintenance and minor - elevating the quality and purpose of our releases. With the increase in releases and related communication, I wonder if we need to highlight release-related communication in some way. Otherwise, it

Re: [DISCUSS] Looking to a 2.8.0 release

Did we consider cutting a branch-3 that borrows relatively compatible patches from trunk to run the 3.x line? That said, I would like for us to really tighten our compatibility policies and actually stick to them starting the next major release. On Wed, Nov 11, 2015 at 1:11 PM, Vinod Vavilapalli

Re: [DISCUSS] Looking to a 2.8.0 release

I am really against the notion of calling x.y.0 releases alpha/beta; it is very confusing. If we think a release is alpha/beta quality, why not release it as x.y.0-alpha or x.y.0-beta, and follow it up eventually with x.y.0 GA. I am in favor of labeling any of the newer features to be of

[jira] [Resolved] (MAPREDUCE-6531) CLONE - Mumak: Map-Reduce Simulator

[ https://issues.apache.org/jira/browse/MAPREDUCE-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik Kambatla resolved MAPREDUCE-6531. - Resolution: Won't Fix Resolving as "Won't Fix". > CLONE - Muma

Re: [DISCUSS] About the details of JDK-8 support

On Wed, Oct 14, 2015 at 4:28 PM, Allen Wittenauer wrote: > > If people want, I could setup a cut off of yetus master to run the jenkins > test-patch. (multiple maven repos, docker support, multijdk support, … ) > Yetus would get some real world testing out of it and hadoop

[jira] [Created] (MAPREDUCE-6506) Make the reducer-preemption configs consistent in how they handle defaults

Karthik Kambatla created MAPREDUCE-6506: --- Summary: Make the reducer-preemption configs consistent in how they handle defaults Key: MAPREDUCE-6506 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6506

[jira] [Created] (MAPREDUCE-6501) Improve reducer preemption

Karthik Kambatla created MAPREDUCE-6501: --- Summary: Improve reducer preemption Key: MAPREDUCE-6501 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6501 Project: Hadoop Map/Reduce

Re: [VOTE] Release Apache Hadoop 2.6.1 RC1

+1 (binding) Ran a few MR jobs on a pseudo-distributed cluster on Java 8. On Tue, Sep 22, 2015 at 8:09 AM, Masatake Iwasaki < iwasak...@oss.nttdata.co.jp> wrote: > +1(non-binding) > > - verified mds and signature of source and binary tarball > - built from source tarball with -Pnative on CentOS

[jira] [Resolved] (MAPREDUCE-6485) MR job hanged forever because all resources are taken up by reducers and the last map attempt never get resource to run

[ https://issues.apache.org/jira/browse/MAPREDUCE-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik Kambatla resolved MAPREDUCE-6485. - Resolution: Duplicate I believe this is a duplicate of MAPREDUCE-6302

Scaling JHS

Hi folks Just wanted to bring this up and see what people think. IIUC, JHS memory consumption depends on the number of jobs, tasks per job, and concurrent accesses. There might be a few orthogonal approaches to improving its scalability: - Appears we process jhist files on every access. May

Re: [VOTE] Release Apache Hadoop 2.7.1 RC0

of the planned [1] 2 weeks in getting this release out: post-mortem in a separate thread. [1]: A 2.7.1 release to follow up 2.7.0 http://markmail.org/thread/zwzze6cqqgwq4rmw -- Karthik Kambatla Software Engineer, Cloudera Inc. http://five.sentenc.es

[jira] [Created] (MAPREDUCE-6369) MR compile shouldn't depend on nodemanager

Karthik Kambatla created MAPREDUCE-6369: --- Summary: MR compile shouldn't depend on nodemanager Key: MAPREDUCE-6369 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6369 Project: Hadoop Map

[jira] [Resolved] (MAPREDUCE-1439) Learning Scheduler

[ https://issues.apache.org/jira/browse/MAPREDUCE-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik Kambatla resolved MAPREDUCE-1439. - Resolution: Won't Fix Given the lack of activity for 5 years

Re: [DISCUSS] branch-1

2013 …. I guess we need a PMC member to declare a vote or whatever…. -- Karthik Kambatla Software Engineer, Cloudera Inc. http://five.sentenc.es

Re: [DISCUSS] branch-1

intention of working on the 1.3 release, especially given that 1.2.1 was Aug 2013 …. I guess we need a PMC member to declare a vote or whatever…. -- Karthik Kambatla Software Engineer, Cloudera Inc. http://five.sentenc.es

[jira] [Resolved] (MAPREDUCE-6343) JobConf.parseMaximumHeapSizeMB() fails to parse value greater than 2GB expressed in bytes

[ https://issues.apache.org/jira/browse/MAPREDUCE-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik Kambatla resolved MAPREDUCE-6343. - Resolution: Fixed Fix Version/s: 3.0.0 Hadoop Flags: Reviewed

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

or beta or whatever. -- Karthik Kambatla Software Engineer, Cloudera Inc. http://five.sentenc.es

Re: [DISCUSS] Looking to a 2.8.0 release

? Thanks +Vinod -- Karthik Kambatla Software Engineer, Cloudera Inc. http://five.sentenc.es

Re: [VOTE] Release Apache Hadoop 2.7.0 RC0

. Thanks, Vinod [1]: A 2.7.1 release to follow up 2.7.0 http://markmail.org/thread/zwzze6cqqgwq4rmw -- Karthik Kambatla Software Engineer, Cloudera Inc. http://five.sentenc.es

Re: Removal of unused properties

at least for one major release before being removed. http://hadoop.apache.org/docs/r2.6.0/hadoop-project-dist/ hadoop-common/Compatibility.html#Hadoop_Configuration_Files Is it applicable for unused properties? Can we remove unused properties right now? Regards, Akira -- Karthik Kambatla

Re: A 2.7.1 release to follow up 2.7.0

incompatibilities with 2.7.0, we can fix those in 2.7.1 and promote that to be the stable release. Sounds reasonable. Thoughts? Thanks,+Vinod -- Karthik Kambatla Software Engineer, Cloudera Inc. http://five.sentenc.es

Uncertainty of pre-commit builds

were run against one of the MR modules. I suspect there is a race condition when there are multiple builds executing on the same node, or remnants from a previous run are getting picked up. Filed HADOOP-11779 for this. -- Karthik Kambatla Software Engineer, Cloudera Inc

Re: Uncertainty of pre-commit builds

race if Jenkins doesn’t setup the environment correctly or leaks variables between runs. shellcheck prints out so many messages on the current code I’m surprised it doesn’t crash. On Mar 31, 2015, at 9:21 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi devs, I am sure people must have

Re: Hadoop 3.x: what about shipping trunk as a 2.x release in 2015?

release and fixed shell scripts items, pushing out those benefits to people sooner rather than later, and puts off the Hello, we've just broken your code event for another 12+ months. Comments? -Steve -- Karthik Kambatla Software Engineer, Cloudera Inc

Re: Reviving HADOOP-7435: Making Jenkins pre-commit build work with branches

before. This may need us to collectively agree on some convention - the last comment says that the branch patch name should be in some format for this to work. Thanks, +Vinod -- Karthik Kambatla Software Engineer, Cloudera Inc. http

Re: Looking to a Hadoop 3 release

makes backports easier, since we're likely maintaining 2.x for a while yet. Please let me know any comments / concerns related to the above. If people are friendly to the idea, I'd like to cut a branch-3 and start working on the first alpha. Best, Andrew -- Karthik Kambatla

Re: Looking to a Hadoop 3 release

not revolutionary, are still incompatible, and require a major version bump. -- Karthik Kambatla Software Engineer, Cloudera Inc. http://five.sentenc.es

Re: Looking to a Hadoop 3 release

backports easier, since we're likely maintaining 2.x for a while yet. Please let me know any comments / concerns related to the above. If people are friendly to the idea, I'd like to cut a branch-3 and start working on the first alpha. Best, Andrew -- Karthik Kambatla Software Engineer

Re: DISCUSSION: Patch commit criteria.

for this community so far. I think most of the discrepancies arise from the fact that reviewers are hard to find. May be this should be the focus of improvements rather than the RTC rules. Thanks, --Konst -- Karthik Kambatla Software Engineer, Cloudera Inc

Re: 2.7 status

status of the 2.7 release? I know initially it started out as a java-7 only release, but looking at the JIRAs that is very much not the case. Do we have a certain timeframe for 2.7 or is it time to discuss it? Thanks, Sangjin -- Karthik Kambatla Software Engineer, Cloudera Inc

[jira] [Resolved] (MAPREDUCE-5842) uber job with LinuxContainerExecutor cause exception

[ https://issues.apache.org/jira/browse/MAPREDUCE-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik Kambatla resolved MAPREDUCE-5842. - Resolution: Duplicate This appears to be a duplicate of MAPREDUCE-5799

Re: Upgrading findbugs

this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- Karthik Kambatla Software Engineer, Cloudera Inc. http://five.sentenc.es

Re: Thinking ahead to hadoop-2.7

positioned as the JDK7-only release, then it would be good to know how 2.8 lines up in terms of timing. Our interest is landing the shared cache feature (YARN-1492)... Thanks. Sangjin On Mon, Dec 1, 2014 at 2:55 PM, Karthik Kambatla ka...@cloudera.com wrote: Thanks

Re: Thinking ahead to hadoop-2.7

Thanks for starting this thread, Arun. Your proposal seems reasonable to me. I suppose we would like new features and improvements to go into 2.8 then? If yes, what time frame are we looking at for 2.8? Looking at YARN, it would be nice to get a release with shared-cache and a stable version of

Re: [VOTE] Merge branch MAPREDUCE-2841 to trunk

+1 I skimmed over the initial import, but looked at the follow-up patches more closely. There is very little change to the existing code, most (all?) of which is already committed to trunk. Ran wordcount with the default collector and the native collector on a single node setup - the latter takes

Re: [VOTE] Release Apache Hadoop 2.5.1 RC0

HADOOP-11078 to track this. Regards, Akira (2014/09/09 0:51), Karthik Kambatla wrote: +1 (non-binding) Built the source tarball, brought up a pseudo-distributed cluster and ran a few MR jobs. Verified documentation and size of the binary tarball. On Fri, Sep 5, 2014 at 5:18 PM

Re: [VOTE] Release Apache Hadoop 2.5.1 RC0

+1 (non-binding) Built the source tarball, brought up a pseudo-distributed cluster and ran a few MR jobs. Verified documentation and size of the binary tarball. On Fri, Sep 5, 2014 at 5:18 PM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, I have put together a release candidate (RC0

[VOTE] Release Apache Hadoop 2.5.1 RC0

Hi folks, I have put together a release candidate (RC0) for Hadoop 2.5.1. The RC is available at: http://people.apache.org/~kasha/hadoop-2.5.1-RC0/ The RC git tag is release-2.5.1-RC0 The maven artifacts are staged at: https://repository.apache.org/content/repositories/orgapachehadoop-1010/ You

[jira] [Resolved] (MAPREDUCE-5956) MapReduce AM should not use maxAttempts to determine if this is the last retry

[ https://issues.apache.org/jira/browse/MAPREDUCE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik Kambatla resolved MAPREDUCE-5956. - Resolution: Fixed Target Version/s: 2.6.0 (was: 2.5.1) Spoke

[DISCUSS] Hadoop 2.5.1

Hi folks Now that all issues with target 2.5.1 are committed, I am planning to cut an RC for 2.5.1 this Friday. The fixes going into 2.5.1 are - http://s.apache.org/2Mz Are there any other Blocker issues that we would like to get into 2.5.1? If there are any, please mark them as Blocker and

Git repo ready to use

Hi folks, I am very excited to let you know that the git repo is now writable. I committed a few changes (CHANGES.txt fixes and branching for 2.5.1) and everything looks good. Current status: 1. All branches have the same names, including trunk. 2. Force push is disabled on trunk,

Re: Git repo ready to use

Oh.. a couple more things. The git commit hashes have changed and are different from what we had on our github. This might interfere with any build automations that folks have. Another follow-up item: email and JIRA integration On Wed, Aug 27, 2014 at 1:33 AM, Karthik Kambatla ka

Re: Git repo ready to use

at 1:40 AM, Karthik Kambatla ka...@cloudera.com wrote: Oh.. a couple more things. The git commit hashes have changed and are different from what we had on our github. This might interfere with any build automations that folks have. Another follow-up item: email and JIRA integration On Wed

Re: Git repo ready to use

It appears the comments from Hudson on our JIRAs (post commits) are not setup by the INFRA team. Do we use any other scripts for this? If yes, do we want to fix those scripts or use svngit2jira? On Wed, Aug 27, 2014 at 10:18 AM, Karthik Kambatla ka...@cloudera.com wrote: The emails for commits

Re: Git repo ready to use

=cloudstack.git;h=7260e8d This is more concise and easier to look at than the Hudson list. On Wed, Aug 27, 2014 at 10:48 AM, Karthik Kambatla ka...@cloudera.com wrote: It appears the comments from Hudson on our JIRAs (post commits) are not setup by the INFRA team. Do we use any other scripts

Re: Updates on migration to git

Last I heard, the import is still going on and appears closer to getting done. Thanks for your patience with the migration. I ll update you as and when there is something. Eventually, the git repo should be at the location in the wiki. On Mon, Aug 25, 2014 at 3:45 PM, Karthik Kambatla ka

Re: Updates on migration to git

basis. Was there any voting on this in PMC and should we have a vote to ensure everyone is one the same page on doing this and how to go about it? Regards, Suresh On Tue, Aug 26, 2014 at 9:17 AM, Karthik Kambatla ka...@cloudera.com wrote: Last I heard, the import is still going

Re: Updates on migration to git

The git repository is now ready for inspection. I ll take a look shortly, but it would be great if a few others could too. Once we are okay with it, we can ask it to be writable. On Tuesday, August 26, 2014, Karthik Kambatla ka...@cloudera.com wrote: Hi Suresh There was one vote thread

Re: Updates on migration to git

comfortable with making the git repo writable under these conditions? I ll let other people poke around and report. Thanks for your cooperation, Karthik On Tue, Aug 26, 2014 at 1:19 PM, Karthik Kambatla ka...@cloudera.com wrote: The git repository is now ready for inspection. I ll take a look shortly

Re: Updates on migration to git

and branch-2, verified all the branches are present. Also checked a few branches and the recent commit history matches our existing repo. Everything looks good so far. On Tue, Aug 26, 2014 at 1:19 PM, Karthik Kambatla ka...@cloudera.com wrote: The git repository is now ready for inspection. I ll

Re: Updates on migration to git

experience, especially when a project has committers new to git, force-push support causes more trouble than it's worth. -Todd On Tue, Aug 26, 2014 at 4:39 PM, Karthik Kambatla ka...@cloudera.com wrote: Looks like our git repo is good to go. On INFRA-8195, I am asking Daniel to enable

Re: Updates on migration to git

, but it doesn't have to be. For git-flow workflows (which we use in slider) master/ is for releases, develop/ for dev. On 24 August 2014 02:31, Karthik Kambatla ka...@cloudera.com wrote: Couple of things: 1. Since no one expressed any reservations against doing this on Sunday

Re: Updates on migration to git

, Karthik Kambatla ka...@cloudera.com wrote: Thanks for your input, Steve. Sorry for sending the email out that late, I sent it as soon as I could. On Mon, Aug 25, 2014 at 2:20 AM, Steve Loughran ste...@hortonworks.com wrote: just caught up with this after some offlininess...15:48 PST

Re: Updates on migration to git

Thanks Giri. By the way, writes to svn are now disabled. On Saturday, August 23, 2014, Giridharan Kesavan gkesa...@hortonworks.com wrote: ​I can take a look at this on Monday. ​ -giri On Sat, Aug 23, 2014 at 6:31 PM, Karthik Kambatla ka...@cloudera.com javascript:; wrote: Couple

Re: Updates on migration to git

understand Giri maintains those builds, do we have anyone else who has access in case Giri is not reachable? Giri - please shout out if you can help us with this either on Sunday or Monday. Thanks Karthik On Fri, Aug 22, 2014 at 3:50 PM, Karthik Kambatla ka...@cloudera.com wrote: Also, does

Updates on migration to git

Hi folks, For the SCM migration, feel free to follow https://issues.apache.org/jira/browse/INFRA-8195 Most of this is planned to be handled this Sunday. As a result, the subversion repository would be read-only. If this is a major issue for you, please shout out. Daniel Gruno, the one helping

Re: Updates on migration to git

Also, does anyone know what we use for integration between JIRA and svn? I am assuming svn2jira. On Fri, Aug 22, 2014 at 3:48 PM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, For the SCM migration, feel free to follow https://issues.apache.org/jira/browse/INFRA-8195 Most

[jira] [Reopened] (MAPREDUCE-5956) MapReduce AM should not use maxAttempts to determine if this is the last retry

[ https://issues.apache.org/jira/browse/MAPREDUCE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik Kambatla reopened MAPREDUCE-5956: - Reopening this to include in 2.5.1. MapReduce AM should not use maxAttempts

Apache Hadoop 2.5.0 published tarballs are missing some txt files

Hi devs Tsuyoshi just brought it to my notice that the published tarballs don't have LICENSE, NOTICE and README at the top-level. Instead, they are only under common, hdfs, etc. Now that we have already announced the release and the jars/functionality doesn't change, I propose we just update the

Re: [VOTE] Migration from subversion to git for version control

hit...@apache.org wrote: +1 — Hitesh On Aug 8, 2014, at 7:57 PM, Karthik Kambatla ka...@cloudera.com 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

Re: [VOTE] Release Apache Hadoop 2.5.0 RC2

files are not compiled. Would you please generate documents with 'mvn site site:stage /path/to/deploy'? I'm +1 (non-binding) if the documents are included. Thanks, Akira (2014/08/12 13:49), Karthik Kambatla wrote: I have updated the binary tar ball to include the docs, by building the docs

Re: [VOTE] Release Apache Hadoop 2.5.0 RC2

on this Karthik. Arun On Aug 6, 2014, at 1:59 PM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, I have put together a release candidate (rc2) for Hadoop 2.5.0. The RC is available at: http://people.apache.org/~kasha/hadoop-2.5.0-RC2/ The RC tag in svn is here: https

Re: [VOTE] Release Apache Hadoop 2.5.0 RC2

, could you create new tar ball with the documentations? Thanks, - Tsuyoshi On Thu, Aug 7, 2014 at 5:59 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, I have put together a release candidate (rc2) for Hadoop 2.5.0. The RC is available at: http://people.apache.org/~kasha

Re: [VOTE] Release Apache Hadoop 2.5.0 RC2

to update binary tarball without modifying source code. +1(non-binding) to continue the voting. Thanks, - Tsuyoshi On Tue, Aug 12, 2014 at 3:47 AM, Karthik Kambatla ka...@cloudera.com wrote: Thanks Akira for catching the missing docs. Let me work on *updating* the binary tarball to include

Re: [VOTE] Release Apache Hadoop 2.5.0 RC2

Can someone please verify the signatures on the new binary and the old source tarballs to make sure it is all good? If it is, I believe we can go ahead and close the vote. On Mon, Aug 11, 2014 at 9:49 PM, Karthik Kambatla ka...@cloudera.com wrote: I have updated the binary tar ball to include

Re: [DISCUSS] Migrate from svn to git for source control?

Thanks Steve. Including that in the proposal. By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html), I can't tell what kind of a vote this would be. On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran ste...@hortonworks.com wrote: On 6 August 2014 22:16, Karthik Kambatla ka

  1   2   3   >