Re: Hadoop 3.1.0 release discussion

uot; <mapreduce-...@hadoop.apache.org>, Vinod Kumar Vavilapalli <vino...@hortonworks.com> Subject: Re: Hadoop 3.1.0 release discussion Thanks for the update. On Tue, Jan 30, 2018 at 4:51 PM, Gangumalla, Uma <uma.ganguma...@intel.com<mailto:uma.ganguma...@intel.com>> wrote: Hi Wangda,

Re: Hadoop 3.1.0 release discussion

; wrote: Hi Uma, Thanks, I saw HDFS-13050 has been resolved 4 hours ago, I don't see any other blockers under HDFS-10285. I think you guys should be able to start voting thread in time for merging to trunk. - Wangda On Mon, Jan 29, 2018 at 3:12 AM, Gangumalla,

Re: Hadoop 3.1.0 release discussion

* (Varun V) YARN-5673: container-executor write. Given security refactoring of c-e (YARN-6623) is already landed, IMHO other stuff may be moved to 3.2. Thanks, Wangda On Mon, Jan 22, 2018 at 1:49 PM, Gangumalla, Uma <uma.ganguma...@intel.com<mailto:uma.ganguma...@intel.com>> wrote: Sure,

Re: Hadoop 3.1.0 release discussion

Sure, Wangda. Regards, Uma On 1/18/18, 10:19 AM, "Wangda Tan" <wheele...@gmail.com> wrote: Thanks Uma, Could you update this thread once the merge vote started? Best, Wangda On Wed, Jan 17, 2018 at 4:30 PM, Gangumalla, Uma <uma.ganguma...@i

Re: Hadoop 3.1.0 release discussion

HI Wangda, Thank you for the head-up mail. We are in the branch (HDFS-10285) and trying to push the tasks sooner before the deadline. Regards, Uma On 1/17/18, 11:35 AM, "Wangda Tan" wrote: Hi All, Since we're fast approaching previously proposed feature

Re: [VOTE] Release Apache Hadoop 3.0.0 RC1

Here is my +1(binding) too. Sorry for late vote. Verified signatures of the source tarball. built from source. set up a 2-node test cluster. Tested via HDFS commands and java API – Written bunch of files and read back. Ran basic MR job Thanks Andrew and others for the hard work for getting

Re: [DISCUSS] Branches and versions for Hadoop 3

Plan looks good to me. +1 Regards, Uma On 8/25/17, 10:36 AM, "Andrew Wang" wrote: >Hi folks, > >With 3.0.0-beta1 fast approaching, I wanted to go over the proposed >branching strategy. > >In the early 2.x days, moving trunk immediately to 3.0.0 was a mistake.

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

+1 (binding). Overall it¹s a great effort, Andrew. Thank you for putting all the energy. Downloaded and built. Ran some sample jobs. I would love to see all this efforts will lead to get the GA from Hadoop 3.X soon. Regards, Uma On 8/30/16, 8:51 AM, "Andrew Wang"

Re: Release numbering for 3.x leading up to GA

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 general agreement on this release numbering scheme for >3.x. > >I'm going to attempt some mvn and JIRA

Re: [DISCUSS] Set minimum version of Hadoop 3 to JDK8 (HADOOP-11858)

+1 Regards, Uma On 5/10/16, 2:24 PM, "Andrew Wang" wrote: >+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: >>

Re: [VOTE] Accept Chimera as new Apache Commons Component

+1 (non-binding) +common-dev@hadoop On 3/21/16, 6:59 PM, "Gangumalla, Uma" <uma.ganguma...@intel.com> wrote: >+1 (non-binding) > > >Regards, >Uma > >On 3/21/16, 1:45 AM, "Benedikt Ritter" <brit...@apache.org> wrote: > >>Hi al

Re: Branch policy question

Thanks Chris N for digging back on this details. The main concern on this question was started like ³Since it¹s nearly impossible for me to get timely reviews for some build and script changes Š.². So, Even for CTR process, review is needed thing at some point. I have one question here is CTR

Re: Branch policy question

> is it possible for me to setup a branch, self review+commit to that >branch, then request a branch merge? Basically this is something like Commit-Then-Review(here review later) process right. I have not seen we followed this approach here( not sure if I missed some branches followed that). Even

Re: Style checking related to getters

+1 for disabling them. Regards, Uma On 2/29/16, 11:16 AM, "Andrew Wang" wrote: >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,

Re: [crypto][chimera] Next steps

Thanks all for the valuable feedbacks and discussions. Here are my replies for some of the questions.. [Mark wrote] It depends. I care less about the quality of the code than I do about the community that comes with it / forms around it. A strong community can fix code issues. Great code can't

Re: [crypto][chimera] Next steps

ry" <garydgreg...@gmail.com> wrote: >All files should follow the Commons Maven naming scheme to make it easy to >reach from Maven, Ivy and so on. > >This will be commons-crypto-1.0.jar for example. > >Gary > >On Mon, Feb 22, 2016 at 1:06 PM, Gangumalla, Uma ><

Re: [crypto][chimera] Next steps

>I would highly recommend shading this library when it is used in Hadoop and/or Spark, to prevent version skew problems between Hadoop and Spark like we have had in the past. [uma]Ha. This avoids multiple jars versions issues. Agreed IMO. >I think at a minimum, we should include the version

Re: Looking to a Hadoop 3 release

Yes. I think starting 3.0 release with alpha is good idea. So it would get some time to reach the beta or GA. +1 for the plan. For the compatibility purposes and as current stable versions, we should continue 2.x releases anyway. Thanks Andrew for starting the thread. Regards, Uma On 2/18/16,

Re: Chimera as new component in Apache Commons

, "Benedikt Ritter" <brit...@apache.org> wrote: >Hello Uma, > >welcome to the Apache Commons dev list. It's great to see that two >projects >get together to share code via Apache Commons. > >2016-02-16 22:36 GMT+01:00 Gangumalla, Uma <uma.ganguma...@intel.com>: &

Chimera as new component in Apache Commons

Hi Devs, Recently we worked with Spark community to implement the shuffle encryption. While implementing that, we realized some/most of the code in Apache Hadoop encryption code and this implementation code have to be duplicated. This leads to an idea to create separate reusable library,

Re: Hadoop encryption module as Apache Chimera incubator project

, February 5, 2016 6:28 AM >To: common-dev@hadoop.apache.org >Cc: hdfs-...@hadoop.apache.org >Subject: Re: Hadoop encryption module as Apache Chimera incubator project > >On Thu, Feb 4, 2016 at 12:06 PM, Gangumalla, Uma ><uma.ganguma...@intel.com> wrote: > >> [UMA] O

Re: Hadoop encryption module as Apache Chimera incubator project

rary with few/no dependencies would be generally >useful. As a subproject, it could have a broader scope that could evolve >into a viable TLP. 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 sep

Re: [Release thread] 2.8.0 release activities

Thanks Vinod. +1 for 2.8 release start. Regards, Uma On 2/3/16, 3:53 PM, "Vinod Kumar Vavilapalli" wrote: >Seems like all the features listed in the Roadmap wiki are in. I¹m going >to try cutting an RC this weekend for a first/non-stable release off of >branch-2.8. > >Let

Re: [VOTE] Merge HDFS-7285 (erasure coding) branch to trunk

+1 Great addition to HDFS. Thanks all contributors for the nice work. Regards, Uma On 9/22/15, 3:40 PM, "Zhe Zhang" wrote: >Hi, > >I'd like to propose a vote to merge the HDFS-7285 feature branch back to >trunk. Since November 2014 we have been designing and developing

Re: [YETUS] Yetus TLP approved

Congratulations, Great efforts Sean and team! Regards, Uma On 9/17/15, 8:59 AM, "Sean Busbey" wrote: >Hi Folks! > >At yesterday's ASF board meeting the Apache Yetus TLP was approved. >There's >still some ASF Infra work to get done[1] before we can start transitioning >our

RE: [VOTE] Change by-laws on release votes: 5 days instead of 7

+1 Regards, Uma -Original Message- From: Arun C Murthy [mailto:a...@hortonworks.com] Sent: Tuesday, June 24, 2014 2:24 PM To: common-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org; yarn-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org Subject: [VOTE] Change by-laws on release

RE: [DISCUSS] Change by-laws on release votes: 5 days instead of 7

: [DISCUSS] Change by-laws on release votes: 5 days instead of 7 Uma, Voting periods are defined in *minimum* terms, so it already covers what you'd like to see i.e. the vote can continue longer. thanks, Arun On Jun 21, 2014, at 2:19 AM, Gangumalla, Uma uma.ganguma...@intel.com wrote: How about

RE: [DISCUSS] Change by-laws on release votes: 5 days instead of 7

How about proposing vote for 5days and give chance to RM for extending vote for 2more days( total to 7days) if the rc did not receive enough vote within 5days? If a rc received enough votes in 5days, RM can close vote. I can see an advantage of 7days voting is, that will cover all the week and

RE: hadoop-2.5 - June end?

Yes. Suresh. I have merged HDFS-2006 (Extended Attributes) to branch-2. So, that it will be included in 2.5 release. Regards, Uma -Original Message- From: Suresh Srinivas [mailto:sur...@hortonworks.com] Sent: Tuesday, June 10, 2014 10:15 PM To: mapreduce-...@hadoop.apache.org Cc: