Re: [ANNOUNCE] New Apache Hadoop Committer - He Xiaoqiao

2020-06-11 Thread Sree Vaddi
Congratulations, He Xiaoqiao.

Thank you./Sree

 

On Thursday, June 11, 2020, 9:54:32 AM PDT, Chao Sun  
wrote:  
 
 Congrats Xiaoqiao!

On Thu, Jun 11, 2020 at 9:36 AM Ayush Saxena  wrote:

> Congratulations He Xiaoqiao!!!
>
> -Ayush
>
> > On 11-Jun-2020, at 9:30 PM, Wei-Chiu Chuang  wrote:
> >
> > In bcc: general@
> >
> > It's my pleasure to announce that He Xiaoqiao has been elected as a
> > committer on the Apache Hadoop project recognizing his continued
> > contributions to the
> > project.
> >
> > Please join me in congratulating him.
> >
> > Hearty Congratulations & Welcome aboard Xiaoqiao!
> >
> > Wei-Chiu Chuang
> > (On behalf of the Hadoop PMC)
>
> -
> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>
>  

Re: [DISCUSS] fate of branch-2.9

2020-03-02 Thread Sree Vaddi
+1

Sent from Yahoo Mail on Android 
 
  On Mon, Mar 2, 2020 at 5:12 PM, Wei-Chiu Chuang wrote:   
Hi,

Following the discussion to end branch-2.8, I want to start a discussion
around what's next with branch-2.9. I am hesitant to use the word "end of
life" but consider these facts:

* 2.9.0 was released Dec 17, 2017.
* 2.9.2, the last 2.9.x release, went out Nov 19 2018, which is more than
15 months ago.
* no one seems to be interested in being the release manager for 2.9.3.
* Most if not all of the active Hadoop contributors are using Hadoop 2.10
or Hadoop 3.x.
* We as a community do not have the cycle to manage multiple release line,
especially since Hadoop 3.3.0 is coming out soon.

It is perhaps the time to gradually reduce our footprint in Hadoop 2.x, and
encourage people to upgrade to Hadoop 3.x

Thoughts?
  


Re: [DISCUSS] About creation of Hadoop Thirdparty repository for shaded artifacts

2020-01-04 Thread Sree Vaddi
apache/hadoop-thirdparty, How would it fit into ASF ? As an Incubating Project 
? Or as a TLP ?
Or as a new project definition ?

The effort to streamline and put in an accepted standard for the dependencies 
that require shading,seems beyond the siloed efforts of hadoop, hbase, etc

I propose, we bring all the decision makers from all these artifacts in one 
room and decide best course of action.I am looking at, no projects should ever 
had to shade any artifacts except as an absolute necessary alternative.


Thank you./Sree

 

On Saturday, January 4, 2020, 7:49:18 AM PST, Vinayakumar B 
 wrote:  
 
 Hi,
Sorry for the late reply,.
>>> To be exact, how can we better use the thirdparty repo? Looking at
HBase as an example, it looks like everything that are known to break a lot
after an update get shaded into the hbase-thirdparty artifact: guava,
netty, ... etc.
Is it the purpose to isolate these naughty dependencies?
Yes, shading is to isolate these naughty dependencies from downstream
classpath and have independent control on these upgrades without breaking
downstreams.

First PR https://github.com/apache/hadoop-thirdparty/pull/1 to create the
protobuf shaded jar is ready to merge.

Please take a look if anyone interested, will be merged may be after two
days if no objections.

-Vinay


On Thu, Oct 10, 2019 at 3:30 AM Wei-Chiu Chuang  wrote:

> Hi I am late to this but I am keen to understand more.
>
> To be exact, how can we better use the thirdparty repo? Looking at HBase
> as an example, it looks like everything that are known to break a lot after
> an update get shaded into the hbase-thirdparty artifact: guava, netty, ...
> etc.
> Is it the purpose to isolate these naughty dependencies?
>
> On Wed, Oct 9, 2019 at 12:38 PM Vinayakumar B 
> wrote:
>
>> Hi All,
>>
>> I have updated the PR as per @Owen O'Malley 
>> 's suggestions.
>>
>>    i. Renamed the module to 'hadoop-shaded-protobuf37'
>>    ii. Kept the shaded package to 'o.a.h.thirdparty.protobuf37'
>>
>> Please review!!
>>
>> Thanks,
>> -Vinay
>>
>>
>> On Sat, Sep 28, 2019 at 10:29 AM 张铎(Duo Zhang) 
>> wrote:
>>
>> > For HBase we have a separated repo for hbase-thirdparty
>> >
>> > https://github.com/apache/hbase-thirdparty
>> >
>> > We will publish the artifacts to nexus so we do not need to include
>> > binaries in our git repo, just add a dependency in the pom.
>> >
>> >
>> >
>> https://mvnrepository.com/artifact/org.apache.hbase.thirdparty/hbase-shaded-protobuf
>> >
>> >
>> > And it has its own release cycles, only when there are special
>> requirements
>> > or we want to upgrade some of the dependencies. This is the vote thread
>> for
>> > the newest release, where we want to provide a shaded gson for jdk7.
>> >
>> >
>> >
>> https://lists.apache.org/thread.html/f12c589baabbc79c7fb2843422d4590bea982cd102e2bd9d21e9884b@%3Cdev.hbase.apache.org%3E
>> >
>> >
>> > Thanks.
>> >
>> > Vinayakumar B  于2019年9月28日周六 上午1:28写道:
>> >
>> > > Please find replies inline.
>> > >
>> > > -Vinay
>> > >
>> > > On Fri, Sep 27, 2019 at 10:21 PM Owen O'Malley <
>> owen.omal...@gmail.com>
>> > > wrote:
>> > >
>> > > > I'm very unhappy with this direction. In particular, I don't think
>> git
>> > is
>> > > > a good place for distribution of binary artifacts. Furthermore, the
>> PMC
>> > > > shouldn't be releasing anything without a release vote.
>> > > >
>> > > >
>> > > Proposed solution doesnt release any binaries in git. Its actually a
>> > > complete sub-project which follows entire release process, including
>> VOTE
>> > > in public. I have mentioned already that release process is similar to
>> > > hadoop.
>> > > To be specific, using the (almost) same script used in hadoop to
>> generate
>> > > artifacts, sign and deploy to staging repository. Please let me know
>> If I
>> > > am conveying anything wrong.
>> > >
>> > >
>> > > > I'd propose that we make a third party module that contains the
>> > *source*
>> > > > of the pom files to build the relocated jars. This should
>> absolutely be
>> > > > treated as a last resort for the mostly Google projects that
>> regularly
>> > > > break binary compatibility (eg. Protobuf & Guava).
>> > > >
>> > > >
>> > > Same has been implemented in the PR
>> > > https://github.com/apache/hadoop-thirdparty/pull/1. Please check and
>> let
>> > > me
>> > > know If I misunderstood. Yes, this is the last option we have AFAIK.
>> > >
>> > >
>> > > > In terms of naming, I'd propose something like:
>> > > >
>> > > > org.apache.hadoop.thirdparty.protobuf2_5
>> > > > org.apache.hadoop.thirdparty.guava28
>> > > >
>> > > > In particular, I think we absolutely need to include the version of
>> the
>> > > > underlying project. On the other hand, since we should not be
>> shading
>> > > > *everything* we can drop the leading com.google.
>> > > >
>> > > >
>> > > IMO, This naming convention is easy for identifying the underlying
>> > project,
>> > > but  it will be difficult to maintain going forward if underlying
>> project
>> > > versions 

Re: [VOTE] Moving Submarine to a separate Apache project proposal

2019-09-08 Thread Sree Vaddi
Congratulations, Wangda. Thank you.
Let's work towards it's better adoption.


Thank you./Sree

 

On Sunday, September 8, 2019, 10:30:49 PM PDT, Wangda Tan 
 wrote:  
 
 Thanks everybody for voting! Let me conclude the voting thread:

We got 16 binding +1s from PMCs. And 29 +1s from Committers/Contributors.
With no veto.

The vote now passed, we will work with the Apache community to get new
project created and continue the spin-off process.

Best,
Wangda Tan


On Sun, Sep 8, 2019 at 11:24 AM Chen Liang  wrote:

> Late +1.  I am interested in the project too. Please include me.
>
> Regards,
> Chen
>
> Varun Saxena  于2019年9月7日周六 上午10:35写道:
>
>> Belated +1.
>> I too am interested in the project. Please include me.
>>
>> Regards,
>> Varun Saxena
>>
>> On Sat, Sep 7, 2019 at 9:35 PM Sunil Govindan  wrote:
>>
>> > +1 to the proposal.
>> > Thanks to the community for the great response.
>> >
>> > - Sunil
>> >
>> > On Sun, Sep 1, 2019 at 10:49 AM Wangda Tan  wrote:
>> >
>> > > Hi all,
>> > >
>> > > As we discussed in the previous thread [1],
>> > >
>> > > I just moved the spin-off proposal to CWIKI and completed all TODO
>> parts.
>> > >
>> > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/HADOOP/Submarine+Project+Spin-Off+to+TLP+Proposal
>> > >
>> > > If you have interests to learn more about this. Please review the
>> > proposal
>> > > let me know if you have any questions/suggestions for the proposal.
>> This
>> > > will be sent to board post voting passed. (And please note that the
>> > > previous voting thread [2] to move Submarine to a separate Github repo
>> > is a
>> > > necessary effort to move Submarine to a separate Apache project but
>> not
>> > > sufficient so I sent two separate voting thread.)
>> > >
>> > > Please let me know if I missed anyone in the proposal, and reply if
>> you'd
>> > > like to be included in the project.
>> > >
>> > > This voting runs for 7 days and will be concluded at Sep 7th, 11 PM
>> PDT.
>> > >
>> > > Thanks,
>> > > Wangda Tan
>> > >
>> > > [1]
>> > >
>> > >
>> >
>> https://lists.apache.org/thread.html/4a2210d567cbc05af92c12aa6283fd09b857ce209d537986ed800029@%3Cyarn-dev.hadoop.apache.org%3E
>> > > [2]
>> > >
>> > >
>> >
>> https://lists.apache.org/thread.html/6e94469ca105d5a15dc63903a541bd21c7ef70b8bcff475a16b5ed73@%3Cyarn-dev.hadoop.apache.org%3E
>> > >
>> >
>>
>  

Re: [VOTE] Moving Submarine to a separate Apache project proposal

2019-09-01 Thread Sree Vaddi
+1 to move submarine to separate apache project.
It is not clear in the proposal, if submarine majority voted to move to a 
seperate apache project,will it go through the incubation and TLP (top level 
project) later ?1. Incubationpros and cons
efforts towards making it a TLP
2. direct TLP

Thank you./Sree

 

On Saturday, August 31, 2019, 10:19:06 PM PDT, Wangda Tan 
 wrote:  
 
 Hi all,

As we discussed in the previous thread [1],

I just moved the spin-off proposal to CWIKI and completed all TODO parts.

https://cwiki.apache.org/confluence/display/HADOOP/Submarine+Project+Spin-Off+to+TLP+Proposal

If you have interests to learn more about this. Please review the proposal
let me know if you have any questions/suggestions for the proposal. This
will be sent to board post voting passed. (And please note that the
previous voting thread [2] to move Submarine to a separate Github repo is a
necessary effort to move Submarine to a separate Apache project but not
sufficient so I sent two separate voting thread.)

Please let me know if I missed anyone in the proposal, and reply if you'd
like to be included in the project.

This voting runs for 7 days and will be concluded at Sep 7th, 11 PM PDT.

Thanks,
Wangda Tan

[1]
https://lists.apache.org/thread.html/4a2210d567cbc05af92c12aa6283fd09b857ce209d537986ed800029@%3Cyarn-dev.hadoop.apache.org%3E
[2]
https://lists.apache.org/thread.html/6e94469ca105d5a15dc63903a541bd21c7ef70b8bcff475a16b5ed73@%3Cyarn-dev.hadoop.apache.org%3E