Re: Looking for Champion and Mentors

[Eya Badal Abdisho]

On 2020/01/31 13:52:17, "John D. Ament"  wrote: 
> On Fri, Jan 31, 2020 at 12:48 AM Eya Badal Abdisho 
> wrote:
> 
> >
> >
> > On 2020/01/29 23:45:40, Justin Mclean  wrote:
> > > Hi,
> > >
> > > > Meanwhile please let me know if there is any other information that I
> > can provide you with.
> > >
> > > The Incubator prefers projects that already have a community around
> > them.  A little more information about that community around your project
> > would help, so far it seems (but I could be mistaken) it’s more of an
> > internal company project that wants to become an open source one and grow a
> > community around it.
> > >
> > > Thanks,
> > > Justin
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >Thank you, Justin, for your feedback.
> >
> > >AgensGraph Extension project started as an internal project due to our
> > community requests and needs in regard to having an extension instead of
> > the fork edition of PostgreSQL. From the beginning, the plan was to make
> > the extension an open-source project after a beta version was released. We
> > hope that the old existing users will join this community as committers as
> > well since the initial goal of this project was based on the user's desire
> > to eliminate the need to perform data migrations or replication. (The ease
> > of adoption for the extension is incomparable to that of for edition that
> > will create an even bigger community than the current edition.)
> >
> > For your reference please find the requests and comments in links below
> > from our community where they asked for an extension version of AgensGraph:
> >
> > https://github.com/bitnine-oss/agensgraph/issues/268
> >
> >
> I think another way to look at what Justin's saying is that we don't want
> to bring on a project that only has one developer on it.  It's very hard
> for that project to grow.  It's pretty common for corporate sponsored
> projects to move to Apache; the project can grow outside of any one
> corporate structure.
> 
> 
> >
> > >We are actively engaged in the PostgreSQL community by co-sponsoring
> > PostgreSQL events. Through this project, we expect that lots of people from
> > that community will join and participate as developers and users.
> >
> >
> > Please let me know if you need any additional information and we will be
> > more than happy to provide that.
> >
> > Best regards,
> > Eya
> >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
> Dear everyone, 

I just want to mention that the AgensGraph Extension project repository is 
public now for your consideration: https://github.com/bitnine-oss/agensgraph-ext
 
It is also updated on our proposal: 
https://cwiki.apache.org/confluence/display/INCUBATOR/AgensGraphExtension

Please let me know if you have any questions. 

Best, 
Eya 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for Champion and Mentors

[John D. Ament]

On Fri, Jan 31, 2020 at 12:48 AM Eya Badal Abdisho 
wrote:

>
>
> On 2020/01/29 23:45:40, Justin Mclean  wrote:
> > Hi,
> >
> > > Meanwhile please let me know if there is any other information that I
> can provide you with.
> >
> > The Incubator prefers projects that already have a community around
> them.  A little more information about that community around your project
> would help, so far it seems (but I could be mistaken) it’s more of an
> internal company project that wants to become an open source one and grow a
> community around it.
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >Thank you, Justin, for your feedback.
>
> >AgensGraph Extension project started as an internal project due to our
> community requests and needs in regard to having an extension instead of
> the fork edition of PostgreSQL. From the beginning, the plan was to make
> the extension an open-source project after a beta version was released. We
> hope that the old existing users will join this community as committers as
> well since the initial goal of this project was based on the user's desire
> to eliminate the need to perform data migrations or replication. (The ease
> of adoption for the extension is incomparable to that of for edition that
> will create an even bigger community than the current edition.)
>
> For your reference please find the requests and comments in links below
> from our community where they asked for an extension version of AgensGraph:
>
> https://github.com/bitnine-oss/agensgraph/issues/268
>
>
I think another way to look at what Justin's saying is that we don't want
to bring on a project that only has one developer on it.  It's very hard
for that project to grow.  It's pretty common for corporate sponsored
projects to move to Apache; the project can grow outside of any one
corporate structure.


>
> >We are actively engaged in the PostgreSQL community by co-sponsoring
> PostgreSQL events. Through this project, we expect that lots of people from
> that community will join and participate as developers and users.
>
>
> Please let me know if you need any additional information and we will be
> more than happy to provide that.
>
> Best regards,
> Eya
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Looking for Champion and Mentors

[Eya Badal Abdisho]

On 2020/01/29 23:45:40, Justin Mclean  wrote: 
> Hi,
> 
> > Meanwhile please let me know if there is any other information that I can 
> > provide you with. 
> 
> The Incubator prefers projects that already have a community around them.  A 
> little more information about that community around your project would help, 
> so far it seems (but I could be mistaken) it’s more of an internal company 
> project that wants to become an open source one and grow a community around 
> it.
> 
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>Thank you, Justin, for your feedback.  

>AgensGraph Extension project started as an internal project due to our 
>community requests and needs in regard to having an extension instead of the 
>fork edition of PostgreSQL. From the beginning, the plan was to make the 
>extension an open-source project after a beta version was released. We hope 
>that the old existing users will join this community as committers as well 
>since the initial goal of this project was based on the user's desire to 
>eliminate the need to perform data migrations or replication. (The ease of 
>adoption for the extension is incomparable to that of for edition that will 
>create an even bigger community than the current edition.)

For your reference please find the requests and comments in links below from 
our community where they asked for an extension version of AgensGraph: 

https://github.com/bitnine-oss/agensgraph/issues/268


>We are actively engaged in the PostgreSQL community by co-sponsoring 
>PostgreSQL events. Through this project, we expect that lots of people from 
>that community will join and participate as developers and users.


Please let me know if you need any additional information and we will be more 
than happy to provide that. 

Best regards, 
Eya  



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for Champion and Mentors

[Justin Mclean]

Hi,

> Meanwhile please let me know if there is any other information that I can 
> provide you with. 

The Incubator prefers projects that already have a community around them.  A 
little more information about that community around your project would help, so 
far it seems (but I could be mistaken) it’s more of an internal company project 
that wants to become an open source one and grow a community around it.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for Champion and Mentors

[Eya Badal Abdisho]

On 2020/01/29 03:31:45, Justin Mclean  wrote: 
> Hi,
> 
> Thanks for the proposal, and it sounds like an interesting project.
> 
> > Orphaned Products
> > The core developers of the AgensGraph Extension team plan to work full time 
> > on this project. There is no risk of orphaned or abandoned code.
> 
> Given they are all from some company there could be a high risk of the 
> project being orphaned, can you provide some more information.
> 
> > Homogenous Developers:
> > The current list of committers includes developers from several different 
> > countries. The core committers are geographically distributed across the 
> > U.S., Europe, and Asia. They are experienced with working in a distributed 
> > environment.
> 
> But they all work for one company?
> 
> > Mailing lists
> > agex-...@incubator.apache.org
> > agex-comm...@incubator.apache.org
> > agex-priv...@incubator.apache.org
> > agex-u...@incubator.apache.org
> 
> One minor thing, it's best not to have a user list at the start and only add 
> one once you need it.
> 
> > Git Repositories:
> > The Git repository is not public yet, but we can provide the private 
> > repository upon request for your review.
> 
> This is slightly confusing how is an open source project able to function 
> with a private repo?
> 
> > Initial Committers
> > Junseok Yang (jsy...@bitnine.net ), Josh Innis (josh.in...@bitnine.net ) , 
> > John Gemignani (john.gemign...@bitnine.net ) , Hyunwoo Ha (h...@bitnine.net)
> 
> You mentioned other contributors above, is there any reason they are not on 
> the initial committer list. Four people is a small number for a functioning 
> project management committee, while 3 is the minimum, we would like to see 
> more initial committers. It would also be good if they were not all from the 
> same company.
> 
> Please make sure you use the most recent template when making the proposal, 
> There's a couple of missing items. [1]
> 
> Thanks,
> Justin
> 
> 1. https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> Hello Justin, 

Thank you so much for the feedback, I really appreciate it. 

>One minor thing, it's best not to have a user list at the start and only add 
>one once you need it.
>>For sure, I will add that later and for now won't include it. 

> This is slightly confusing how is an open-source project able to function 
> with a private repo?
>>I understand your confusion regarding the private repo and we will make the 
>>repo public as soon as possible to avoid any confusion.
 
> Please make sure you use the most recent template when making the proposal, 
> There's a couple of missing items. [1]
>>I will also make sure to include the missing parts as well. 

>>We will provide you with more information regarding your other concerns after 
>>an internal quick discussion with our developers 

Meanwhile please let me know if there is any other information that I can 
provide you with. 

Best regards, 
Eya 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for Champion and Mentors

[Justin Mclean]

Hi,

Thanks for the proposal, and it sounds like an interesting project.

> Orphaned Products
> The core developers of the AgensGraph Extension team plan to work full time 
> on this project. There is no risk of orphaned or abandoned code.

Given they are all from some company there could be a high risk of the project 
being orphaned, can you provide some more information.

> Homogenous Developers:
> The current list of committers includes developers from several different 
> countries. The core committers are geographically distributed across the 
> U.S., Europe, and Asia. They are experienced with working in a distributed 
> environment.

But they all work for one company?

> Mailing lists
> agex-...@incubator.apache.org
> agex-comm...@incubator.apache.org
> agex-priv...@incubator.apache.org
> agex-u...@incubator.apache.org

One minor thing, it's best not to have a user list at the start and only add 
one once you need it.

> Git Repositories:
> The Git repository is not public yet, but we can provide the private 
> repository upon request for your review.

This is slightly confusing how is an open source project able to function with 
a private repo?

> Initial Committers
> Junseok Yang (jsy...@bitnine.net ), Josh Innis (josh.in...@bitnine.net ) , 
> John Gemignani (john.gemign...@bitnine.net ) , Hyunwoo Ha (h...@bitnine.net)

You mentioned other contributors above , is there any reason they are not on 
the initial committer list. Four people is a small number for a functioning 
project management committee, while 3 is the minimum, we would like to see more 
initial committers. It would also be good if they were not all from the same 
company.

Please make sure you use the most recent template when making the proposal, 
There's a couple of missing items. [1]

Thanks,
Justin

1. https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Looking for Champion and Mentors

[Eya Badal Abdisho]

Hello all,

I am Eya, a software engineer working with the AgensGraph Extension team 
(Multimodel Database)

We propose to contribute AgensGraph Extension as an Apache Incubator project, 
and
we are still looking for possible Champion and Mentors. If anyone would like to 
volunteer, we would greatly appreciate it. 

Best Regards,
Eya 

===
The draft of the proposal can be found on wiki: 
https://cwiki.apache.org/confluence/display/INCUBATOR/AgensGraphExtension
===

You may also find following the draft(work in progress) version of the proposal 
as well

*This proposal is the first draft and is a work in progress*

Abstract
AgensGraph Extension will be a multi-model database that enables graph and 
relational models built on PostgreSQL.

Proposal
We propose the AgensGraph Extension to the Apache foundation. AgensGraph 
Extension is to provide an extension for PostgreSQL to give the users the 
ability to leverage graph database on top of the existing relational database 
with minimal effort. The basic principle of the project is to create single 
storage that can handle both relational and graph model data so that the users 
can use the standard ANSI SQL along with openCypher 
(http://www.opencypher.org), the Graph query language. 

Background
To provide some background, the AgensGraph extension project is being actively 
developed. This project is a new generation of a multi-model graph database for 
the modern complex data environment. A graph database can solve problems from 
very different angles, thanks to its different approach to data and its 
organization. By preparing data in graph models the users can apply graph 
algorithms that provide forte in handling complexity. Moreover, Graph data is a 
suitable form to apply machine learning. 

Prior to AgensGraph extension, there is an existing forked project which is 
publicly available on the following link: 
https://github.com/bitnine-oss/agensgraph

While working on the fork version of this project, we found out that there are 
increasing voices asking for an extension of AgensGraph. It was then when we 
decided to develop and work on the extension version to provide more benefits 
to PostgreSQL users such as easy installation and compatibility. 

AgensGraph Extension is a multi-model database designed to be simple and 
user-friendly, which supports the relational and graph data model at the same 
time that enables users to integrate the legacy relational data model and the 
flexible graph data model in one database. AgensGraph Extension supports 
ANSI-SQL and openCypher (http://www.opencypher.org). SQL queries and Cypher 
queries can be integrated into a single query in AgensGraph Extension. 

Currently, we have active users and contributors that forked and used this 
project to build other projects. Some examples could be found in the following 
links: https://www.nuget.org/packages/FSharp.Data.AgensGraph/

Rationale
AgensGraph mainly offers a multimodel database, eliminating the migration 
efforts while having relational and graph models.  

There is a strong need for a cohesive, easy to migrate multimodel for a 
relational and graph database. AgensGraph Extension is an extension of 
PostgreSQL which supports all the functionalities and features of the 
PostgreSQL and offers a graph model in addition. Users with a relational 
background and data model who are in need of having a graph model on top of 
their existing relational model can use this extension with minimal effort 
because they can use existing data without migration to enable graph database.

Since AgensGraph Extension is based on the powerful PostgreSQL RDBMS, it is 
very robust, fully-featured and ready to use. AgensGraph Extension is optimized 
for handling complex connected graph data and provides plenty of powerful 
database features essential to the database environment including ACID 
transactions, multi-version concurrency control, stored procedure, triggers, 
constraints, sophisticated monitoring and a flexible data model (JSON). 
Moreover, AgensGraph Extension leverages the rich eco-systems of PostgreSQL and 
can be extended with many outstanding external modules, like PostGIS.

Initial Goals
A complete implementation of openCypher language specification in a PostgreSQL 
extension: 

Implementation of openCypher parser 
Implementation of internal AgensGraph Data Types 
Implementation of expression logic 
Implementation of Cypher language Clauses (Return, Create, Delete, Update, 
Match)
Implementation of variable length expressions (VLE)
Implementation of graph-related functions (such as aggregation)

Current Status

Meritocracy:
Our current practices align with the meritocracy principles of Apache. 
AgensGraph Extension was originally created by Junseok Yang in June 2019. 
Committers have the freedom to work on a task independently and consult any 
other member of the team when necessary. Once committers have finished, a git 
patch

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Tan,Zhongyi]

Yes , the project name is confirmed as brpc.



在 2018/9/21 上午11:13， "Liang Chen"  写入:

>Hi
>
>An interesting project.
>One question : the project name is confirmed with "brpc"?  it means "baidu
>rpc" ?
>
>Just kind reminder :  it would be better if you could confirm the name
>before starting incubating, it would be the lowest cost for your project.
>
>Regards
>Liang
>
>
>
>--
>Sent from: http://apache-incubator-general.996316.n3.nabble.com/
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Liang Chen]

Hi

An interesting project.
One question : the project name is confirmed with "brpc"?  it means "baidu
rpc" ?

Just kind reminder :  it would be better if you could confirm the name
before starting incubating, it would be the lowest cost for your project.

Regards
Liang



--
Sent from: http://apache-incubator-general.996316.n3.nabble.com/

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Dave Fisher]

Hi Justin,

Given the recent activity around dropping inactive mentors there will be a 
large need for fresh IPMC members. I think that a general message to members@ 
with a list of podlings and proposals needing mentors would be a reasonable 
message.

See you in Montreal.

Regards,
Dave

> On Sep 20, 2018, at 2:30 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> The IPMC might be too shallow a pool.   Justin, can you email members@ for 
>> them with a draft of their proposal, perhaps?
> 
> Given they need to understand the incubation process they should probably be 
> an IPMC member and subscribed to this list. Given the large size of memebers@ 
> there would probably be some complaints if I emailed it there.
> 
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Justin Mclean]

Hi,

> The IPMC might be too shallow a pool.   Justin, can you email members@ for 
> them with a draft of their proposal, perhaps?

Given they need to understand the incubation process they should probably be an 
IPMC member and subscribed to this list. Given the large size of memebers@ 
there would probably be some complaints if I emailed it there.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Kevin A. McGrail]

The IPMC might be too shallow a pool.   Justin, can you email members@
for them with a draft of their proposal, perhaps?

On 9/19/2018 9:16 PM, Tan,Zhongyi wrote:
> Hi, JB,
>
> The proposal on wiki has been Updated.
>
> Add JB and Kevin as mentors.
>
> But we still look for champion, can someone help?
>
> Thanks
>
>
>
> 在 2018/9/19 下午1:53， "Jean-Baptiste Onofré"  写入:
>
>> Hi,
>>
>> sure. I think we can update the wiki with the proposal.
>>
>> Thoughts ?
>>
>> Regards
>> JB
>>
>> On 19/09/2018 04:34, Tan,Zhongyi wrote:
>>> Hi，JB，
>>>
>>> can we invite you as the mentor of brpc？
>>>
>>> thanks
>>>
>>>
>>> 在 2018/9/17 下午12:18， "Jean-Baptiste Onofré"  写入:
>>>
>>>> Hi,
>>>>
>>>> With great pleasure. I'm not sure I will contribute so much on the
>>>> code,
>>>> but I would be more than happy to help and guide the incubation.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 17/09/2018 05:21, Tan,Zhongyi wrote:
>>>>> Hi， JB
>>>>>
>>>>> Would you like to be champion for this project？
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> 在 2018/9/14 下午5:20， "Jean-Baptiste Onofré"  写入:
>>>>>
>>>>>> Thanks for the details. It helps.
>>>>>>
>>>>>> Let me do a new pass on the proposal.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 14/09/2018 10:19, Tan,Zhongyi wrote:
>>>>>>> Hi， JB，
>>>>>>> Below are our answers to your questions，
>>>>>>> Please check，
>>>>>>> Thanks.
>>>>>>>
>>>>>>> 1. brpc doesn't depend on any other Apache projects. brpc currently
>>>>>>> depends on the following external project:
>>>>>>>- leveldb
>>>>>>>- openssl
>>>>>>>- protobuf
>>>>>>>- gperftools (optional)
>>>>>>>- glog (optional)
>>>>>>>- gtest
>>>>>>>
>>>>>>> 2. brpc is alternative for C++ rpc fcramework，implementations for
>>>>>>> other
>>>>>>> languages are not competitive enough (comparing to gRPC) to be
>>>>>>> opensourced.  Besides the basic RPC function, brpc(C++) provides
>>>>>>> additional features than gRPC:
>>>>>>>- Clients and servers can talk in multiple protocols: baidu
>>>>>>> internal
>>>>>>> protocol, http, thrift, http2(communicable with gRPC, the PR is
>>>>>>> under
>>>>>>> reviewing) and tens of other protocols.
>>>>>>>- Proved better performance in different scenarios, by
>>>>>>> eliminating
>>>>>>> locks on hotpaths and using goroutine-like concurrency(bthread) with
>>>>>>> cache
>>>>>>> friendly data structures
>>>>>>>- More useful debugging utilities to help C++ programers build
>>>>>>> solid
>>>>>>> online services.
>>>>>>>- Various access patterns such as one-to-one, one-to-many(fan
>>>>>>> out),
>>>>>>> streaming, which simplify implementation of complex distributed
>>>>>>> services.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> It's an interesting project. I have two questions:
>>>>>>>>
>>>>>>>> 1. do you have some interactions/dependencies with other Apache
>>>>>>>> projects, especially CXF for instance ?
>>>>>>>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>>>>>>>> Different features ?
>>>>>>>>
>>>>>>>> I might be interested by mentoring the project, I would like to
>>>>>>>> understand exactly the target/purposes.
>>>>>>>>
>>&g

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Tan,Zhongyi]

Hi, JB,

The proposal on wiki has been Updated.

Add JB and Kevin as mentors.

But we still look for champion, can someone help?

Thanks



在 2018/9/19 下午1:53， "Jean-Baptiste Onofré"  写入:

>Hi,
>
>sure. I think we can update the wiki with the proposal.
>
>Thoughts ?
>
>Regards
>JB
>
>On 19/09/2018 04:34, Tan,Zhongyi wrote:
>> Hi，JB，
>> 
>> can we invite you as the mentor of brpc？
>> 
>> thanks
>> 
>> 
>> 在 2018/9/17 下午12:18， "Jean-Baptiste Onofré"  写入:
>> 
>>> Hi,
>>>
>>> With great pleasure. I'm not sure I will contribute so much on the
>>>code,
>>> but I would be more than happy to help and guide the incubation.
>>>
>>> Regards
>>> JB
>>>
>>> On 17/09/2018 05:21, Tan,Zhongyi wrote:
>>>> Hi， JB
>>>>
>>>> Would you like to be champion for this project？
>>>>
>>>> Thanks
>>>>
>>>>
>>>> 在 2018/9/14 下午5:20， "Jean-Baptiste Onofré"  写入:
>>>>
>>>>> Thanks for the details. It helps.
>>>>>
>>>>> Let me do a new pass on the proposal.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 14/09/2018 10:19, Tan,Zhongyi wrote:
>>>>>> Hi， JB，
>>>>>> Below are our answers to your questions，
>>>>>> Please check，
>>>>>> Thanks.
>>>>>>
>>>>>> 1. brpc doesn't depend on any other Apache projects. brpc currently
>>>>>> depends on the following external project:
>>>>>>- leveldb
>>>>>>- openssl
>>>>>>- protobuf
>>>>>>- gperftools (optional)
>>>>>>- glog (optional)
>>>>>>- gtest
>>>>>>
>>>>>> 2. brpc is alternative for C++ rpc fcramework，implementations for
>>>>>> other
>>>>>> languages are not competitive enough (comparing to gRPC) to be
>>>>>> opensourced.  Besides the basic RPC function, brpc(C++) provides
>>>>>> additional features than gRPC:
>>>>>>- Clients and servers can talk in multiple protocols: baidu
>>>>>> internal
>>>>>> protocol, http, thrift, http2(communicable with gRPC, the PR is
>>>>>>under
>>>>>> reviewing) and tens of other protocols.
>>>>>>- Proved better performance in different scenarios, by
>>>>>>eliminating
>>>>>> locks on hotpaths and using goroutine-like concurrency(bthread) with
>>>>>> cache
>>>>>> friendly data structures
>>>>>>- More useful debugging utilities to help C++ programers build
>>>>>> solid
>>>>>> online services.
>>>>>>- Various access patterns such as one-to-one, one-to-many(fan
>>>>>>out),
>>>>>> streaming, which simplify implementation of complex distributed
>>>>>> services.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It's an interesting project. I have two questions:
>>>>>>>
>>>>>>> 1. do you have some interactions/dependencies with other Apache
>>>>>>> projects, especially CXF for instance ?
>>>>>>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>>>>>>> Different features ?
>>>>>>>
>>>>>>> I might be interested by mentoring the project, I would like to
>>>>>>> understand exactly the target/purposes.
>>>>>>>
>>>>>>> Thanks !
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 13/09/2018 08:20, Tan,Zhongyi wrote:
>>>>>>>> Hi, guys,
>>>>>>>>
>>>>>>>> brpc is one open source RPC framework that is very popular in
>>>>>>>>baidu
>>>>>>>> and
>>>>>>>> china.
>>>>>>>> We want to contribute it to ASF to make it more successful.
>>>>>>>> And we are looking for champion 

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Tan,Zhongyi]

Ok，I will update the wiki

But we are still looking for volunteer to be champion，

Anyone can help？


在 2018/9/19 下午1:53， "Jean-Baptiste Onofré"  写入:

>Hi,
>
>sure. I think we can update the wiki with the proposal.
>
>Thoughts ?
>
>Regards
>JB
>
>On 19/09/2018 04:34, Tan,Zhongyi wrote:
>> Hi，JB，
>> 
>> can we invite you as the mentor of brpc？
>> 
>> thanks
>> 
>> 
>> 在 2018/9/17 下午12:18， "Jean-Baptiste Onofré"  写入:
>> 
>>> Hi,
>>>
>>> With great pleasure. I'm not sure I will contribute so much on the
>>>code,
>>> but I would be more than happy to help and guide the incubation.
>>>
>>> Regards
>>> JB
>>>
>>> On 17/09/2018 05:21, Tan,Zhongyi wrote:
>>>> Hi， JB
>>>>
>>>> Would you like to be champion for this project？
>>>>
>>>> Thanks
>>>>
>>>>
>>>> 在 2018/9/14 下午5:20， "Jean-Baptiste Onofré"  写入:
>>>>
>>>>> Thanks for the details. It helps.
>>>>>
>>>>> Let me do a new pass on the proposal.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 14/09/2018 10:19, Tan,Zhongyi wrote:
>>>>>> Hi， JB，
>>>>>> Below are our answers to your questions，
>>>>>> Please check，
>>>>>> Thanks.
>>>>>>
>>>>>> 1. brpc doesn't depend on any other Apache projects. brpc currently
>>>>>> depends on the following external project:
>>>>>>- leveldb
>>>>>>- openssl
>>>>>>- protobuf
>>>>>>- gperftools (optional)
>>>>>>- glog (optional)
>>>>>>- gtest
>>>>>>
>>>>>> 2. brpc is alternative for C++ rpc fcramework，implementations for
>>>>>> other
>>>>>> languages are not competitive enough (comparing to gRPC) to be
>>>>>> opensourced.  Besides the basic RPC function, brpc(C++) provides
>>>>>> additional features than gRPC:
>>>>>>- Clients and servers can talk in multiple protocols: baidu
>>>>>> internal
>>>>>> protocol, http, thrift, http2(communicable with gRPC, the PR is
>>>>>>under
>>>>>> reviewing) and tens of other protocols.
>>>>>>- Proved better performance in different scenarios, by
>>>>>>eliminating
>>>>>> locks on hotpaths and using goroutine-like concurrency(bthread) with
>>>>>> cache
>>>>>> friendly data structures
>>>>>>- More useful debugging utilities to help C++ programers build
>>>>>> solid
>>>>>> online services.
>>>>>>- Various access patterns such as one-to-one, one-to-many(fan
>>>>>>out),
>>>>>> streaming, which simplify implementation of complex distributed
>>>>>> services.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It's an interesting project. I have two questions:
>>>>>>>
>>>>>>> 1. do you have some interactions/dependencies with other Apache
>>>>>>> projects, especially CXF for instance ?
>>>>>>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>>>>>>> Different features ?
>>>>>>>
>>>>>>> I might be interested by mentoring the project, I would like to
>>>>>>> understand exactly the target/purposes.
>>>>>>>
>>>>>>> Thanks !
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 13/09/2018 08:20, Tan,Zhongyi wrote:
>>>>>>>> Hi, guys,
>>>>>>>>
>>>>>>>> brpc is one open source RPC framework that is very popular in
>>>>>>>>baidu
>>>>>>>> and
>>>>>>>> china.
>>>>>>>> We want to contribute it to ASF to make it more successful.
>>>>>>>> And we are looking for champion and mentor for this project,
>>>>>>&

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Zhangyi Chen]

Hi, Von Gosling

In a short time, the core develop team of brpc are still focusing on
adopting brpc to satisfy scenarios where performance of communication and
thread scheduling do really matter, such as HPC, search backend and
distributed storage.  There is some work that we can do:
1. Merge rdma related stuff to the code base
2. Implement user space tcp-stack based on dpdk
3. Numa-aware thread scheduling algorithm
4. Zero copy I/O stack (from storage to network)

Bindings for other languages are always welcomed. If someone from the
community is willing to do these stuffs, we are glad to help to complement
the design and implementation.

Best Regards,
Zhangyi Chen

On Mon, Sep 17, 2018 at 11:42 AM Von Gosling  wrote:

> Hi,
>
> I am excited to see a new rpc framework grow and flourish in apache
> comprehensive culture, rpc is so important infrastructure as messaging.
> Also, I am glad to help brpc community to learn and incubate smoothly under
> the Apache Way. After a look through about brpc , I  have one question that
> what’s the plan for our brpc future? I noticed that your mention brpc is an
> c++ rpc framework. AFAIK, sole language-lock rpc framework will not go far
> away in nowadays, especially facing the challenge of the new cloud
> computing paradigm, such as serverless and so on.
>
>
> Best Regards,
> Von Gosling
>
> > 2. brpc is alternative for C++ rpc fcramework，implementations for other
> > languages are not competitive enough (comparing to gRPC) to be
> > opensourced.  Besides the basic RPC function, brpc(C++) provides
> > additional features than gRPC:
> >   - Clients and servers can talk in multiple protocols: baidu internal
> > protocol, http, thrift, http2(communicable with gRPC, the PR is under
> > reviewing) and tens of other protocols.
> >   - Proved better performance in different scenarios, by eliminating
> > locks on hotpaths and using goroutine-like concurrency(bthread) with
> cache
> > friendly data structures
> >   - More useful debugging utilities to help C++ programers build solid
> > online services.
> >   - Various access patterns such as one-to-one, one-to-many(fan out),
> > streaming, which simplify implementation of complex distributed services.
>
>
>
>
> > 在 2018年9月14日，16:19，Tan,Zhongyi  写道：
> >
> > Hi， JB，
> > Below are our answers to your questions，
> > Please check，
> > Thanks.
> >
> > 1. brpc doesn't depend on any other Apache projects. brpc currently
> > depends on the following external project:
> >   - leveldb
> >   - openssl
> >   - protobuf
> >   - gperftools (optional)
> >   - glog (optional)
> >   - gtest
> >
> > 2. brpc is alternative for C++ rpc fcramework，implementations for other
> > languages are not competitive enough (comparing to gRPC) to be
> > opensourced.  Besides the basic RPC function, brpc(C++) provides
> > additional features than gRPC:
> >   - Clients and servers can talk in multiple protocols: baidu internal
> > protocol, http, thrift, http2(communicable with gRPC, the PR is under
> > reviewing) and tens of other protocols.
> >   - Proved better performance in different scenarios, by eliminating
> > locks on hotpaths and using goroutine-like concurrency(bthread) with
> cache
> > friendly data structures
> >   - More useful debugging utilities to help C++ programers build solid
> > online services.
> >   - Various access patterns such as one-to-one, one-to-many(fan out),
> > streaming, which simplify implementation of complex distributed services.
> >
> >
> >
> > 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
> >
> >> Hi,
> >>
> >> It's an interesting project. I have two questions:
> >>
> >> 1. do you have some interactions/dependencies with other Apache
> >> projects, especially CXF for instance ?
> >> 2. what's the comparison between brpc and gRPC ? An alternative ?
> >> Different features ?
> >>
> >> I might be interested by mentoring the project, I would like to
> >> understand exactly the target/purposes.
> >>
> >> Thanks !
> >> Regards
> >> JB
> >>
> >> On 13/09/2018 08:20, Tan,Zhongyi wrote:
> >>> Hi, guys,
> >>>
> >>> brpc is one open source RPC framework that is very popular in baidu and
> >>> china.
> >>> We want to contribute it to ASF to make it more successful.
> >>> And we are looking for champion and mentor for this project,
> >>> if anyone would like to volunteer, we will be very appreciated.
> >>>
> >>

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Jean-Baptiste Onofré]

Hi,

sure. I think we can update the wiki with the proposal.

Thoughts ?

Regards
JB

On 19/09/2018 04:34, Tan,Zhongyi wrote:
> Hi，JB，
> 
> can we invite you as the mentor of brpc？
> 
> thanks
> 
> 
> 在 2018/9/17 下午12:18， "Jean-Baptiste Onofré"  写入:
> 
>> Hi,
>>
>> With great pleasure. I'm not sure I will contribute so much on the code,
>> but I would be more than happy to help and guide the incubation.
>>
>> Regards
>> JB
>>
>> On 17/09/2018 05:21, Tan,Zhongyi wrote:
>>> Hi， JB
>>>
>>> Would you like to be champion for this project？
>>>
>>> Thanks
>>>
>>>
>>> 在 2018/9/14 下午5:20， "Jean-Baptiste Onofré"  写入:
>>>
>>>> Thanks for the details. It helps.
>>>>
>>>> Let me do a new pass on the proposal.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 14/09/2018 10:19, Tan,Zhongyi wrote:
>>>>> Hi， JB，
>>>>> Below are our answers to your questions，
>>>>> Please check，
>>>>> Thanks.
>>>>>
>>>>> 1. brpc doesn't depend on any other Apache projects. brpc currently
>>>>> depends on the following external project:
>>>>>- leveldb
>>>>>- openssl
>>>>>- protobuf
>>>>>- gperftools (optional)
>>>>>- glog (optional)
>>>>>- gtest
>>>>>
>>>>> 2. brpc is alternative for C++ rpc fcramework，implementations for
>>>>> other
>>>>> languages are not competitive enough (comparing to gRPC) to be
>>>>> opensourced.  Besides the basic RPC function, brpc(C++) provides
>>>>> additional features than gRPC:
>>>>>- Clients and servers can talk in multiple protocols: baidu
>>>>> internal
>>>>> protocol, http, thrift, http2(communicable with gRPC, the PR is under
>>>>> reviewing) and tens of other protocols.
>>>>>- Proved better performance in different scenarios, by eliminating
>>>>> locks on hotpaths and using goroutine-like concurrency(bthread) with
>>>>> cache
>>>>> friendly data structures
>>>>>- More useful debugging utilities to help C++ programers build
>>>>> solid
>>>>> online services.
>>>>>- Various access patterns such as one-to-one, one-to-many(fan out),
>>>>> streaming, which simplify implementation of complex distributed
>>>>> services.
>>>>>
>>>>>
>>>>>
>>>>> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It's an interesting project. I have two questions:
>>>>>>
>>>>>> 1. do you have some interactions/dependencies with other Apache
>>>>>> projects, especially CXF for instance ?
>>>>>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>>>>>> Different features ?
>>>>>>
>>>>>> I might be interested by mentoring the project, I would like to
>>>>>> understand exactly the target/purposes.
>>>>>>
>>>>>> Thanks !
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 13/09/2018 08:20, Tan,Zhongyi wrote:
>>>>>>> Hi, guys,
>>>>>>>
>>>>>>> brpc is one open source RPC framework that is very popular in baidu
>>>>>>> and
>>>>>>> china.
>>>>>>> We want to contribute it to ASF to make it more successful.
>>>>>>> And we are looking for champion and mentor for this project,
>>>>>>> if anyone would like to volunteer, we will be very appreciated.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>> Here is the draft for brpc proposal.
>>>>>>>
>>>>>>>
>>>>>>> # brpc Proposal
>>>>>>>
>>>>>>> ## Abstract
>>>>>>>
>>>>>>> brpc is an industrial-grade RPC framework for building reliable and
>>>>>>> high-performance services.
>>>>>>>
>>>>>>> ## Proposal
>>>>>&g

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Tan,Zhongyi]

Hi，JB，

can we invite you as the mentor of brpc？

thanks


在 2018/9/17 下午12:18， "Jean-Baptiste Onofré"  写入:

>Hi,
>
>With great pleasure. I'm not sure I will contribute so much on the code,
>but I would be more than happy to help and guide the incubation.
>
>Regards
>JB
>
>On 17/09/2018 05:21, Tan,Zhongyi wrote:
>> Hi， JB
>> 
>> Would you like to be champion for this project？
>> 
>> Thanks
>> 
>> 
>> 在 2018/9/14 下午5:20， "Jean-Baptiste Onofré"  写入:
>> 
>>> Thanks for the details. It helps.
>>>
>>> Let me do a new pass on the proposal.
>>>
>>> Regards
>>> JB
>>>
>>> On 14/09/2018 10:19, Tan,Zhongyi wrote:
>>>> Hi， JB，
>>>> Below are our answers to your questions，
>>>> Please check，
>>>> Thanks.
>>>>
>>>> 1. brpc doesn't depend on any other Apache projects. brpc currently
>>>> depends on the following external project:
>>>>- leveldb
>>>>- openssl
>>>>- protobuf
>>>>- gperftools (optional)
>>>>- glog (optional)
>>>>- gtest
>>>>
>>>> 2. brpc is alternative for C++ rpc fcramework，implementations for
>>>>other
>>>> languages are not competitive enough (comparing to gRPC) to be
>>>> opensourced.  Besides the basic RPC function, brpc(C++) provides
>>>> additional features than gRPC:
>>>>- Clients and servers can talk in multiple protocols: baidu
>>>>internal
>>>> protocol, http, thrift, http2(communicable with gRPC, the PR is under
>>>> reviewing) and tens of other protocols.
>>>>- Proved better performance in different scenarios, by eliminating
>>>> locks on hotpaths and using goroutine-like concurrency(bthread) with
>>>> cache
>>>> friendly data structures
>>>>- More useful debugging utilities to help C++ programers build
>>>>solid
>>>> online services.
>>>>- Various access patterns such as one-to-one, one-to-many(fan out),
>>>> streaming, which simplify implementation of complex distributed
>>>> services.
>>>>
>>>>
>>>>
>>>> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
>>>>
>>>>> Hi,
>>>>>
>>>>> It's an interesting project. I have two questions:
>>>>>
>>>>> 1. do you have some interactions/dependencies with other Apache
>>>>> projects, especially CXF for instance ?
>>>>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>>>>> Different features ?
>>>>>
>>>>> I might be interested by mentoring the project, I would like to
>>>>> understand exactly the target/purposes.
>>>>>
>>>>> Thanks !
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 13/09/2018 08:20, Tan,Zhongyi wrote:
>>>>>> Hi, guys,
>>>>>>
>>>>>> brpc is one open source RPC framework that is very popular in baidu
>>>>>> and
>>>>>> china.
>>>>>> We want to contribute it to ASF to make it more successful.
>>>>>> And we are looking for champion and mentor for this project,
>>>>>> if anyone would like to volunteer, we will be very appreciated.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>> Here is the draft for brpc proposal.
>>>>>>
>>>>>>
>>>>>> # brpc Proposal
>>>>>>
>>>>>> ## Abstract
>>>>>>
>>>>>> brpc is an industrial-grade RPC framework for building reliable and
>>>>>> high-performance services.
>>>>>>
>>>>>> ## Proposal
>>>>>>
>>>>>> We propose to contribute the brpc codebase and associated
>>>>>> artifacts(e.g. documentation etc.) to the Apache Software
>>>>>>Foundation,
>>>>>> and aim to  build a wider open community around it in the 'Apache
>>>>>> Way'.
>>>>>>
>>>>>>
>>>>>> ## Background
>>>>>>
>>>>>> The RPC framework used in Baidu before 2014 was developed at 2008
>>>>>>and
>>>>>> limited in 

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Kevin A. McGrail]

On 9/18/2018 12:11 AM, Tan,Zhongyi wrote:
> Thanks，Kevin.
>
Thanks, Tan.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Tan,Zhongyi]

Hi，Dave，
It is a pity that you have little time to be mentor of brpc.
Never mind, you have help us greatly.

Hi, guys, 
is there anyone who volunteer to be champion or mentor of brpc?

Thanks
 

在 2018/9/18 下午12:29， "Dave Fisher"  写入:

>Hi Zhongyi Tan,
>
>With Daffofil, Doris and eCharts I am mentoring three projects. I will
>watch this one as there are some similar challenges, but I don’t think I
>have time to Mentor this one. (I may pick up one other who have lost an
>inactive mentor.)
>
>All the best,
>Dave
>
>Sent from my iPhone
>
>> On Sep 17, 2018, at 9:11 PM, Tan,Zhongyi  wrote:
>> 
>> Thanks，Kevin.
>> 
>> Your help is very appreciated.
>> We will add you to mentor list.
>> 
>> 
>> 在 2018/9/17 下午6:52， "Kevin A. McGrail"  写入:
>> 
>>> Tan, I would be happy to help mentor this project as well.
>>> 
>>>> On 9/17/2018 12:18 AM, Jean-Baptiste Onofré wrote:
>>>> Hi,
>>>> 
>>>> With great pleasure. I'm not sure I will contribute so much on the
>>>>code,
>>>> but I would be more than happy to help and guide the incubation.
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>>> On 17/09/2018 05:21, Tan,Zhongyi wrote:
>>>>> Hi， JB
>>>>> 
>>>>> Would you like to be champion for this project？
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> 
>>>>> 在 2018/9/14 下午5:20， "Jean-Baptiste Onofré"  写入:
>>>>> 
>>>>>> Thanks for the details. It helps.
>>>>>> 
>>>>>> Let me do a new pass on the proposal.
>>>>>> 
>>>>>> Regards
>>>>>> JB
>>>>>> 
>>>>>>> On 14/09/2018 10:19, Tan,Zhongyi wrote:
>>>>>>> Hi， JB，
>>>>>>> Below are our answers to your questions，
>>>>>>> Please check，
>>>>>>> Thanks.
>>>>>>> 
>>>>>>> 1. brpc doesn't depend on any other Apache projects. brpc currently
>>>>>>> depends on the following external project:
>>>>>>>   - leveldb
>>>>>>>   - openssl
>>>>>>>   - protobuf
>>>>>>>   - gperftools (optional)
>>>>>>>   - glog (optional)
>>>>>>>   - gtest
>>>>>>> 
>>>>>>> 2. brpc is alternative for C++ rpc fcramework，implementations for
>>>>>>> other
>>>>>>> languages are not competitive enough (comparing to gRPC) to be
>>>>>>> opensourced.  Besides the basic RPC function, brpc(C++) provides
>>>>>>> additional features than gRPC:
>>>>>>>   - Clients and servers can talk in multiple protocols: baidu
>>>>>>> internal
>>>>>>> protocol, http, thrift, http2(communicable with gRPC, the PR is
>>>>>>>under
>>>>>>> reviewing) and tens of other protocols.
>>>>>>>   - Proved better performance in different scenarios, by
>>>>>>>eliminating
>>>>>>> locks on hotpaths and using goroutine-like concurrency(bthread)
>>>>>>>with
>>>>>>> cache
>>>>>>> friendly data structures
>>>>>>>   - More useful debugging utilities to help C++ programers build
>>>>>>> solid
>>>>>>> online services.
>>>>>>>   - Various access patterns such as one-to-one, one-to-many(fan
>>>>>>> out),
>>>>>>> streaming, which simplify implementation of complex distributed
>>>>>>> services.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> It's an interesting project. I have two questions:
>>>>>>>> 
>>>>>>>> 1. do you have some interactions/dependencies with other Apache
>>>>>>>> projects, especially CXF for instance ?
>>>>>>>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>>>>>>>> Different features ?
>>>>>>>> 
>>>>>>>> I might be inter

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Dave Fisher]

Hi Zhongyi Tan,

With Daffofil, Doris and eCharts I am mentoring three projects. I will watch 
this one as there are some similar challenges, but I don’t think I have time to 
Mentor this one. (I may pick up one other who have lost an inactive mentor.)

All the best,
Dave

Sent from my iPhone

> On Sep 17, 2018, at 9:11 PM, Tan,Zhongyi  wrote:
> 
> Thanks，Kevin.
> 
> Your help is very appreciated.
> We will add you to mentor list.
> 
> 
> 在 2018/9/17 下午6:52， "Kevin A. McGrail"  写入:
> 
>> Tan, I would be happy to help mentor this project as well.
>> 
>>> On 9/17/2018 12:18 AM, Jean-Baptiste Onofré wrote:
>>> Hi,
>>> 
>>> With great pleasure. I'm not sure I will contribute so much on the code,
>>> but I would be more than happy to help and guide the incubation.
>>> 
>>> Regards
>>> JB
>>> 
>>>> On 17/09/2018 05:21, Tan,Zhongyi wrote:
>>>> Hi， JB
>>>> 
>>>> Would you like to be champion for this project？
>>>> 
>>>> Thanks
>>>> 
>>>> 
>>>> 在 2018/9/14 下午5:20， "Jean-Baptiste Onofré"  写入:
>>>> 
>>>>> Thanks for the details. It helps.
>>>>> 
>>>>> Let me do a new pass on the proposal.
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>>> On 14/09/2018 10:19, Tan,Zhongyi wrote:
>>>>>> Hi， JB，
>>>>>> Below are our answers to your questions，
>>>>>> Please check，
>>>>>> Thanks.
>>>>>> 
>>>>>> 1. brpc doesn't depend on any other Apache projects. brpc currently
>>>>>> depends on the following external project:
>>>>>>   - leveldb
>>>>>>   - openssl
>>>>>>   - protobuf
>>>>>>   - gperftools (optional)
>>>>>>   - glog (optional)
>>>>>>   - gtest
>>>>>> 
>>>>>> 2. brpc is alternative for C++ rpc fcramework，implementations for
>>>>>> other
>>>>>> languages are not competitive enough (comparing to gRPC) to be
>>>>>> opensourced.  Besides the basic RPC function, brpc(C++) provides
>>>>>> additional features than gRPC:
>>>>>>   - Clients and servers can talk in multiple protocols: baidu
>>>>>> internal
>>>>>> protocol, http, thrift, http2(communicable with gRPC, the PR is under
>>>>>> reviewing) and tens of other protocols.
>>>>>>   - Proved better performance in different scenarios, by eliminating
>>>>>> locks on hotpaths and using goroutine-like concurrency(bthread) with
>>>>>> cache
>>>>>> friendly data structures
>>>>>>   - More useful debugging utilities to help C++ programers build
>>>>>> solid
>>>>>> online services.
>>>>>>   - Various access patterns such as one-to-one, one-to-many(fan
>>>>>> out),
>>>>>> streaming, which simplify implementation of complex distributed
>>>>>> services.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> It's an interesting project. I have two questions:
>>>>>>> 
>>>>>>> 1. do you have some interactions/dependencies with other Apache
>>>>>>> projects, especially CXF for instance ?
>>>>>>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>>>>>>> Different features ?
>>>>>>> 
>>>>>>> I might be interested by mentoring the project, I would like to
>>>>>>> understand exactly the target/purposes.
>>>>>>> 
>>>>>>> Thanks !
>>>>>>> Regards
>>>>>>> JB
>>>>>>> 
>>>>>>>> On 13/09/2018 08:20, Tan,Zhongyi wrote:
>>>>>>>> Hi, guys,
>>>>>>>> 
>>>>>>>> brpc is one open source RPC framework that is very popular in baidu
>>>>>>>> and
>>>>>>>> china.
>>>>>>>> We want to contribute it to ASF to make it more successful.
>>>>>>>> And we

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Tan,Zhongyi]

Thanks，Kevin.

Your help is very appreciated.
We will add you to mentor list.


在 2018/9/17 下午6:52， "Kevin A. McGrail"  写入:

>Tan, I would be happy to help mentor this project as well.
>
>On 9/17/2018 12:18 AM, Jean-Baptiste Onofré wrote:
>> Hi,
>>
>> With great pleasure. I'm not sure I will contribute so much on the code,
>> but I would be more than happy to help and guide the incubation.
>>
>> Regards
>> JB
>>
>> On 17/09/2018 05:21, Tan,Zhongyi wrote:
>>> Hi， JB
>>>
>>> Would you like to be champion for this project？
>>>
>>> Thanks
>>>
>>>
>>> 在 2018/9/14 下午5:20， "Jean-Baptiste Onofré"  写入:
>>>
>>>> Thanks for the details. It helps.
>>>>
>>>> Let me do a new pass on the proposal.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 14/09/2018 10:19, Tan,Zhongyi wrote:
>>>>> Hi， JB，
>>>>> Below are our answers to your questions，
>>>>> Please check，
>>>>> Thanks.
>>>>>
>>>>> 1. brpc doesn't depend on any other Apache projects. brpc currently
>>>>> depends on the following external project:
>>>>>- leveldb
>>>>>- openssl
>>>>>- protobuf
>>>>>- gperftools (optional)
>>>>>- glog (optional)
>>>>>- gtest
>>>>>
>>>>> 2. brpc is alternative for C++ rpc fcramework，implementations for
>>>>>other
>>>>> languages are not competitive enough (comparing to gRPC) to be
>>>>> opensourced.  Besides the basic RPC function, brpc(C++) provides
>>>>> additional features than gRPC:
>>>>>- Clients and servers can talk in multiple protocols: baidu
>>>>>internal
>>>>> protocol, http, thrift, http2(communicable with gRPC, the PR is under
>>>>> reviewing) and tens of other protocols.
>>>>>- Proved better performance in different scenarios, by eliminating
>>>>> locks on hotpaths and using goroutine-like concurrency(bthread) with
>>>>> cache
>>>>> friendly data structures
>>>>>- More useful debugging utilities to help C++ programers build
>>>>>solid
>>>>> online services.
>>>>>- Various access patterns such as one-to-one, one-to-many(fan
>>>>>out),
>>>>> streaming, which simplify implementation of complex distributed
>>>>> services.
>>>>>
>>>>>
>>>>>
>>>>> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It's an interesting project. I have two questions:
>>>>>>
>>>>>> 1. do you have some interactions/dependencies with other Apache
>>>>>> projects, especially CXF for instance ?
>>>>>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>>>>>> Different features ?
>>>>>>
>>>>>> I might be interested by mentoring the project, I would like to
>>>>>> understand exactly the target/purposes.
>>>>>>
>>>>>> Thanks !
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 13/09/2018 08:20, Tan,Zhongyi wrote:
>>>>>>> Hi, guys,
>>>>>>>
>>>>>>> brpc is one open source RPC framework that is very popular in baidu
>>>>>>> and
>>>>>>> china.
>>>>>>> We want to contribute it to ASF to make it more successful.
>>>>>>> And we are looking for champion and mentor for this project,
>>>>>>> if anyone would like to volunteer, we will be very appreciated.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>> Here is the draft for brpc proposal.
>>>>>>>
>>>>>>>
>>>>>>> # brpc Proposal
>>>>>>>
>>>>>>> ## Abstract
>>>>>>>
>>>>>>> brpc is an industrial-grade RPC framework for building reliable and
>>>>>>> high-performance services.
>>>>>>>
>>>>>>> ## Proposal
>>>>>>>
>>>

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Kevin A. McGrail]

Tan, I would be happy to help mentor this project as well.

On 9/17/2018 12:18 AM, Jean-Baptiste Onofré wrote:
> Hi,
>
> With great pleasure. I'm not sure I will contribute so much on the code,
> but I would be more than happy to help and guide the incubation.
>
> Regards
> JB
>
> On 17/09/2018 05:21, Tan,Zhongyi wrote:
>> Hi， JB
>>
>> Would you like to be champion for this project？
>>
>> Thanks
>>
>>
>> 在 2018/9/14 下午5:20， "Jean-Baptiste Onofré"  写入:
>>
>>> Thanks for the details. It helps.
>>>
>>> Let me do a new pass on the proposal.
>>>
>>> Regards
>>> JB
>>>
>>> On 14/09/2018 10:19, Tan,Zhongyi wrote:
>>>> Hi， JB，
>>>> Below are our answers to your questions，
>>>> Please check，
>>>> Thanks.
>>>>
>>>> 1. brpc doesn't depend on any other Apache projects. brpc currently
>>>> depends on the following external project:
>>>>- leveldb
>>>>- openssl
>>>>- protobuf
>>>>- gperftools (optional)
>>>>- glog (optional)
>>>>- gtest
>>>>
>>>> 2. brpc is alternative for C++ rpc fcramework，implementations for other
>>>> languages are not competitive enough (comparing to gRPC) to be
>>>> opensourced.  Besides the basic RPC function, brpc(C++) provides
>>>> additional features than gRPC:
>>>>- Clients and servers can talk in multiple protocols: baidu internal
>>>> protocol, http, thrift, http2(communicable with gRPC, the PR is under
>>>> reviewing) and tens of other protocols.
>>>>- Proved better performance in different scenarios, by eliminating
>>>> locks on hotpaths and using goroutine-like concurrency(bthread) with
>>>> cache
>>>> friendly data structures
>>>>- More useful debugging utilities to help C++ programers build solid
>>>> online services.
>>>>- Various access patterns such as one-to-one, one-to-many(fan out),
>>>> streaming, which simplify implementation of complex distributed
>>>> services.
>>>>
>>>>
>>>>
>>>> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
>>>>
>>>>> Hi,
>>>>>
>>>>> It's an interesting project. I have two questions:
>>>>>
>>>>> 1. do you have some interactions/dependencies with other Apache
>>>>> projects, especially CXF for instance ?
>>>>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>>>>> Different features ?
>>>>>
>>>>> I might be interested by mentoring the project, I would like to
>>>>> understand exactly the target/purposes.
>>>>>
>>>>> Thanks !
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 13/09/2018 08:20, Tan,Zhongyi wrote:
>>>>>> Hi, guys,
>>>>>>
>>>>>> brpc is one open source RPC framework that is very popular in baidu
>>>>>> and
>>>>>> china.
>>>>>> We want to contribute it to ASF to make it more successful.
>>>>>> And we are looking for champion and mentor for this project,
>>>>>> if anyone would like to volunteer, we will be very appreciated.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>> Here is the draft for brpc proposal.
>>>>>>
>>>>>>
>>>>>> # brpc Proposal
>>>>>>
>>>>>> ## Abstract
>>>>>>
>>>>>> brpc is an industrial-grade RPC framework for building reliable and
>>>>>> high-performance services.
>>>>>>
>>>>>> ## Proposal
>>>>>>
>>>>>> We propose to contribute the brpc codebase and associated
>>>>>> artifacts(e.g. documentation etc.) to the Apache Software Foundation,
>>>>>> and aim to  build a wider open community around it in the 'Apache
>>>>>> Way'.
>>>>>>
>>>>>>
>>>>>> ## Background
>>>>>>
>>>>>> The RPC framework used in Baidu before 2014 was developed at 2008 and
>>>>>> limited in protocols and performance, and there were also serveral
>>>>>> implementations fo

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Jean-Baptiste Onofré]

Hi,

With great pleasure. I'm not sure I will contribute so much on the code,
but I would be more than happy to help and guide the incubation.

Regards
JB

On 17/09/2018 05:21, Tan,Zhongyi wrote:
> Hi， JB
> 
> Would you like to be champion for this project？
> 
> Thanks
> 
> 
> 在 2018/9/14 下午5:20， "Jean-Baptiste Onofré"  写入:
> 
>> Thanks for the details. It helps.
>>
>> Let me do a new pass on the proposal.
>>
>> Regards
>> JB
>>
>> On 14/09/2018 10:19, Tan,Zhongyi wrote:
>>> Hi， JB，
>>> Below are our answers to your questions，
>>> Please check，
>>> Thanks.
>>>
>>> 1. brpc doesn't depend on any other Apache projects. brpc currently
>>> depends on the following external project:
>>>- leveldb
>>>- openssl
>>>- protobuf
>>>- gperftools (optional)
>>>- glog (optional)
>>>- gtest
>>>
>>> 2. brpc is alternative for C++ rpc fcramework，implementations for other
>>> languages are not competitive enough (comparing to gRPC) to be
>>> opensourced.  Besides the basic RPC function, brpc(C++) provides
>>> additional features than gRPC:
>>>- Clients and servers can talk in multiple protocols: baidu internal
>>> protocol, http, thrift, http2(communicable with gRPC, the PR is under
>>> reviewing) and tens of other protocols.
>>>- Proved better performance in different scenarios, by eliminating
>>> locks on hotpaths and using goroutine-like concurrency(bthread) with
>>> cache
>>> friendly data structures
>>>- More useful debugging utilities to help C++ programers build solid
>>> online services.
>>>- Various access patterns such as one-to-one, one-to-many(fan out),
>>> streaming, which simplify implementation of complex distributed
>>> services.
>>>
>>>
>>>
>>> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
>>>
>>>> Hi,
>>>>
>>>> It's an interesting project. I have two questions:
>>>>
>>>> 1. do you have some interactions/dependencies with other Apache
>>>> projects, especially CXF for instance ?
>>>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>>>> Different features ?
>>>>
>>>> I might be interested by mentoring the project, I would like to
>>>> understand exactly the target/purposes.
>>>>
>>>> Thanks !
>>>> Regards
>>>> JB
>>>>
>>>> On 13/09/2018 08:20, Tan,Zhongyi wrote:
>>>>> Hi, guys,
>>>>>
>>>>> brpc is one open source RPC framework that is very popular in baidu
>>>>> and
>>>>> china.
>>>>> We want to contribute it to ASF to make it more successful.
>>>>> And we are looking for champion and mentor for this project,
>>>>> if anyone would like to volunteer, we will be very appreciated.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> Here is the draft for brpc proposal.
>>>>>
>>>>>
>>>>> # brpc Proposal
>>>>>
>>>>> ## Abstract
>>>>>
>>>>> brpc is an industrial-grade RPC framework for building reliable and
>>>>> high-performance services.
>>>>>
>>>>> ## Proposal
>>>>>
>>>>> We propose to contribute the brpc codebase and associated
>>>>> artifacts(e.g. documentation etc.) to the Apache Software Foundation,
>>>>> and aim to  build a wider open community around it in the 'Apache
>>>>> Way'.
>>>>>
>>>>>
>>>>> ## Background
>>>>>
>>>>> The RPC framework used in Baidu before 2014 was developed at 2008 and
>>>>> limited in protocols and performance, and there were also serveral
>>>>> implementations focused on their own scenarios from Baidu's different
>>>>> BU. As an infrastructural team in Baidu, we tried to build a new
>>>>> framework to unify all RPC scenarios inside. The framework was named
>>>>> "baidu-rpc" internally the early versions were adopted and online at
>>>>> late 2014. The framework was rapidly iterated at 2015-2017, and
>>>>> thousands kinds of services and almost all core services adopted it.
>>>>> And
>>>>> in 2017

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Von Gosling]

Hi,

I am excited to see a new rpc framework grow and flourish in apache 
comprehensive culture, rpc is so important infrastructure as messaging. Also, I 
am glad to help brpc community to learn and incubate smoothly under the Apache 
Way. After a look through about brpc , I  have one question that what’s the 
plan for our brpc future? I noticed that your mention brpc is an c++ rpc 
framework. AFAIK, sole language-lock rpc framework will not go far away in 
nowadays, especially facing the challenge of the new cloud computing paradigm, 
such as serverless and so on.


Best Regards,
Von Gosling

> 2. brpc is alternative for C++ rpc fcramework，implementations for other
> languages are not competitive enough (comparing to gRPC) to be
> opensourced.  Besides the basic RPC function, brpc(C++) provides
> additional features than gRPC:
>   - Clients and servers can talk in multiple protocols: baidu internal
> protocol, http, thrift, http2(communicable with gRPC, the PR is under
> reviewing) and tens of other protocols.
>   - Proved better performance in different scenarios, by eliminating
> locks on hotpaths and using goroutine-like concurrency(bthread) with cache
> friendly data structures
>   - More useful debugging utilities to help C++ programers build solid
> online services.
>   - Various access patterns such as one-to-one, one-to-many(fan out),
> streaming, which simplify implementation of complex distributed services.




> 在 2018年9月14日，16:19，Tan,Zhongyi  写道：
> 
> Hi， JB，
> Below are our answers to your questions，
> Please check，
> Thanks.
> 
> 1. brpc doesn't depend on any other Apache projects. brpc currently
> depends on the following external project:
>   - leveldb
>   - openssl
>   - protobuf
>   - gperftools (optional)
>   - glog (optional)
>   - gtest
> 
> 2. brpc is alternative for C++ rpc fcramework，implementations for other
> languages are not competitive enough (comparing to gRPC) to be
> opensourced.  Besides the basic RPC function, brpc(C++) provides
> additional features than gRPC:
>   - Clients and servers can talk in multiple protocols: baidu internal
> protocol, http, thrift, http2(communicable with gRPC, the PR is under
> reviewing) and tens of other protocols.
>   - Proved better performance in different scenarios, by eliminating
> locks on hotpaths and using goroutine-like concurrency(bthread) with cache
> friendly data structures
>   - More useful debugging utilities to help C++ programers build solid
> online services.
>   - Various access patterns such as one-to-one, one-to-many(fan out),
> streaming, which simplify implementation of complex distributed services.
> 
> 
> 
> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
> 
>> Hi,
>> 
>> It's an interesting project. I have two questions:
>> 
>> 1. do you have some interactions/dependencies with other Apache
>> projects, especially CXF for instance ?
>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>> Different features ?
>> 
>> I might be interested by mentoring the project, I would like to
>> understand exactly the target/purposes.
>> 
>> Thanks !
>> Regards
>> JB
>> 
>> On 13/09/2018 08:20, Tan,Zhongyi wrote:
>>> Hi, guys,
>>> 
>>> brpc is one open source RPC framework that is very popular in baidu and
>>> china.
>>> We want to contribute it to ASF to make it more successful.
>>> And we are looking for champion and mentor for this project,
>>> if anyone would like to volunteer, we will be very appreciated.
>>> 
>>> Thanks.
>>> 
>>> 
>>> Here is the draft for brpc proposal.
>>> 
>>> 
>>> # brpc Proposal
>>> 
>>> ## Abstract
>>> 
>>> brpc is an industrial-grade RPC framework for building reliable and
>>> high-performance services.
>>> 
>>> ## Proposal
>>> 
>>> We propose to contribute the brpc codebase and associated
>>> artifacts(e.g. documentation etc.) to the Apache Software Foundation,
>>> and aim to  build a wider open community around it in the 'Apache Way'.
>>> 
>>> 
>>> ## Background
>>> 
>>> The RPC framework used in Baidu before 2014 was developed at 2008 and
>>> limited in protocols and performance, and there were also serveral
>>> implementations focused on their own scenarios from Baidu's different
>>> BU. As an infrastructural team in Baidu, we tried to build a new
>>> framework to unify all RPC scenarios inside. The framework was named
>>> "baidu-rpc" internally the early versions were adopted and online at
>

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Tan,Zhongyi]

Hi， JB

Would you like to be champion for this project？

Thanks


在 2018/9/14 下午5:20， "Jean-Baptiste Onofré"  写入:

>Thanks for the details. It helps.
>
>Let me do a new pass on the proposal.
>
>Regards
>JB
>
>On 14/09/2018 10:19, Tan,Zhongyi wrote:
>> Hi， JB，
>> Below are our answers to your questions，
>> Please check，
>> Thanks.
>> 
>> 1. brpc doesn't depend on any other Apache projects. brpc currently
>> depends on the following external project:
>>- leveldb
>>- openssl
>>- protobuf
>>- gperftools (optional)
>>- glog (optional)
>>- gtest
>> 
>> 2. brpc is alternative for C++ rpc fcramework，implementations for other
>> languages are not competitive enough (comparing to gRPC) to be
>> opensourced.  Besides the basic RPC function, brpc(C++) provides
>> additional features than gRPC:
>>- Clients and servers can talk in multiple protocols: baidu internal
>> protocol, http, thrift, http2(communicable with gRPC, the PR is under
>> reviewing) and tens of other protocols.
>>- Proved better performance in different scenarios, by eliminating
>> locks on hotpaths and using goroutine-like concurrency(bthread) with
>>cache
>> friendly data structures
>>- More useful debugging utilities to help C++ programers build solid
>> online services.
>>- Various access patterns such as one-to-one, one-to-many(fan out),
>> streaming, which simplify implementation of complex distributed
>>services.
>> 
>> 
>> 
>> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
>> 
>>> Hi,
>>>
>>> It's an interesting project. I have two questions:
>>>
>>> 1. do you have some interactions/dependencies with other Apache
>>> projects, especially CXF for instance ?
>>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>>> Different features ?
>>>
>>> I might be interested by mentoring the project, I would like to
>>> understand exactly the target/purposes.
>>>
>>> Thanks !
>>> Regards
>>> JB
>>>
>>> On 13/09/2018 08:20, Tan,Zhongyi wrote:
>>>> Hi, guys,
>>>>
>>>> brpc is one open source RPC framework that is very popular in baidu
>>>>and
>>>> china.
>>>> We want to contribute it to ASF to make it more successful.
>>>> And we are looking for champion and mentor for this project,
>>>> if anyone would like to volunteer, we will be very appreciated.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> Here is the draft for brpc proposal.
>>>>
>>>>
>>>> # brpc Proposal
>>>>
>>>> ## Abstract
>>>>
>>>> brpc is an industrial-grade RPC framework for building reliable and
>>>> high-performance services.
>>>>
>>>> ## Proposal
>>>>
>>>> We propose to contribute the brpc codebase and associated
>>>> artifacts(e.g. documentation etc.) to the Apache Software Foundation,
>>>> and aim to  build a wider open community around it in the 'Apache
>>>>Way'.
>>>>
>>>>
>>>> ## Background
>>>>
>>>> The RPC framework used in Baidu before 2014 was developed at 2008 and
>>>> limited in protocols and performance, and there were also serveral
>>>> implementations focused on their own scenarios from Baidu's different
>>>> BU. As an infrastructural team in Baidu, we tried to build a new
>>>> framework to unify all RPC scenarios inside. The framework was named
>>>> "baidu-rpc" internally the early versions were adopted and online at
>>>> late 2014. The framework was rapidly iterated at 2015-2017, and
>>>> thousands kinds of services and almost all core services adopted it.
>>>>And
>>>> in 2017, we opensourced it as "brpc" and hope to get more adoptions
>>>>and
>>>> contributions from outside. At the time of opensourcing, there're more
>>>> than 1 million instances inside Baidu using baidu-rpc (not counting
>>>> clients).
>>>>
>>>>
>>>> ## Rationale
>>>>
>>>> brpc has been approved inside baidu, since many high performance core
>>>> services are using it.
>>>> And since its open source, it has been adopted by several other
>>>> companies, including Iqiyi, Didi, Sougou, BiliBili etc.
&

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Jean-Baptiste Onofré]

Thanks for the details. It helps.

Let me do a new pass on the proposal.

Regards
JB

On 14/09/2018 10:19, Tan,Zhongyi wrote:
> Hi， JB，
> Below are our answers to your questions，
> Please check，
> Thanks.
> 
> 1. brpc doesn't depend on any other Apache projects. brpc currently
> depends on the following external project:
>- leveldb
>- openssl
>- protobuf
>- gperftools (optional)
>- glog (optional)
>- gtest
> 
> 2. brpc is alternative for C++ rpc fcramework，implementations for other
> languages are not competitive enough (comparing to gRPC) to be
> opensourced.  Besides the basic RPC function, brpc(C++) provides
> additional features than gRPC:
>- Clients and servers can talk in multiple protocols: baidu internal
> protocol, http, thrift, http2(communicable with gRPC, the PR is under
> reviewing) and tens of other protocols.
>- Proved better performance in different scenarios, by eliminating
> locks on hotpaths and using goroutine-like concurrency(bthread) with cache
> friendly data structures
>- More useful debugging utilities to help C++ programers build solid
> online services.
>- Various access patterns such as one-to-one, one-to-many(fan out),
> streaming, which simplify implementation of complex distributed services.
> 
> 
> 
> 在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:
> 
>> Hi,
>>
>> It's an interesting project. I have two questions:
>>
>> 1. do you have some interactions/dependencies with other Apache
>> projects, especially CXF for instance ?
>> 2. what's the comparison between brpc and gRPC ? An alternative ?
>> Different features ?
>>
>> I might be interested by mentoring the project, I would like to
>> understand exactly the target/purposes.
>>
>> Thanks !
>> Regards
>> JB
>>
>> On 13/09/2018 08:20, Tan,Zhongyi wrote:
>>> Hi, guys,
>>>
>>> brpc is one open source RPC framework that is very popular in baidu and
>>> china.
>>> We want to contribute it to ASF to make it more successful.
>>> And we are looking for champion and mentor for this project,
>>> if anyone would like to volunteer, we will be very appreciated.
>>>
>>> Thanks.
>>>
>>>
>>> Here is the draft for brpc proposal.
>>>
>>>
>>> # brpc Proposal
>>>
>>> ## Abstract
>>>
>>> brpc is an industrial-grade RPC framework for building reliable and
>>> high-performance services.
>>>
>>> ## Proposal
>>>
>>> We propose to contribute the brpc codebase and associated
>>> artifacts(e.g. documentation etc.) to the Apache Software Foundation,
>>> and aim to  build a wider open community around it in the 'Apache Way'.
>>>
>>>
>>> ## Background
>>>
>>> The RPC framework used in Baidu before 2014 was developed at 2008 and
>>> limited in protocols and performance, and there were also serveral
>>> implementations focused on their own scenarios from Baidu's different
>>> BU. As an infrastructural team in Baidu, we tried to build a new
>>> framework to unify all RPC scenarios inside. The framework was named
>>> "baidu-rpc" internally the early versions were adopted and online at
>>> late 2014. The framework was rapidly iterated at 2015-2017, and
>>> thousands kinds of services and almost all core services adopted it. And
>>> in 2017, we opensourced it as "brpc" and hope to get more adoptions and
>>> contributions from outside. At the time of opensourcing, there're more
>>> than 1 million instances inside Baidu using baidu-rpc (not counting
>>> clients).
>>>
>>>
>>> ## Rationale
>>>
>>> brpc has been approved inside baidu, since many high performance core
>>> services are using it.
>>> And since its open source, it has been adopted by several other
>>> companies, including Iqiyi, Didi, Sougou, BiliBili etc.
>>>
>>> ## Current Status
>>>
>>> brpc has been an open source project on GitHub
>>> (https://github.com/brpc/brpc) since 2017.
>>>
>>> Currently it has more than 7.3k stars, 1.6k forks, and is one of the
>>> most popular repositories in topic of rpc category in GitHub rpc
>>> catelogy.
>>> It has been widely used in Baidu, with 1,000,000+ instances and
>>> thousands kinds of services.
>>> Besides, many other companies have already used it also, such as Iqiyi,
>>> Didi, Sougou, BiliBili etc.
>>>
>>> ##

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Tan,Zhongyi]

Hi， JB，
Below are our answers to your questions，
Please check，
Thanks.

1. brpc doesn't depend on any other Apache projects. brpc currently
depends on the following external project:
   - leveldb
   - openssl
   - protobuf
   - gperftools (optional)
   - glog (optional)
   - gtest

2. brpc is alternative for C++ rpc fcramework，implementations for other
languages are not competitive enough (comparing to gRPC) to be
opensourced.  Besides the basic RPC function, brpc(C++) provides
additional features than gRPC:
   - Clients and servers can talk in multiple protocols: baidu internal
protocol, http, thrift, http2(communicable with gRPC, the PR is under
reviewing) and tens of other protocols.
   - Proved better performance in different scenarios, by eliminating
locks on hotpaths and using goroutine-like concurrency(bthread) with cache
friendly data structures
   - More useful debugging utilities to help C++ programers build solid
online services.
   - Various access patterns such as one-to-one, one-to-many(fan out),
streaming, which simplify implementation of complex distributed services.



在 2018/9/13 下午3:00， "Jean-Baptiste Onofré"  写入:

>Hi,
>
>It's an interesting project. I have two questions:
>
>1. do you have some interactions/dependencies with other Apache
>projects, especially CXF for instance ?
>2. what's the comparison between brpc and gRPC ? An alternative ?
>Different features ?
>
>I might be interested by mentoring the project, I would like to
>understand exactly the target/purposes.
>
>Thanks !
>Regards
>JB
>
>On 13/09/2018 08:20, Tan,Zhongyi wrote:
>> Hi, guys,
>> 
>> brpc is one open source RPC framework that is very popular in baidu and
>>china.
>> We want to contribute it to ASF to make it more successful.
>> And we are looking for champion and mentor for this project,
>> if anyone would like to volunteer, we will be very appreciated.
>> 
>> Thanks.
>> 
>> 
>> Here is the draft for brpc proposal.
>> 
>> 
>> # brpc Proposal
>> 
>> ## Abstract
>> 
>> brpc is an industrial-grade RPC framework for building reliable and
>>high-performance services.
>> 
>> ## Proposal
>> 
>> We propose to contribute the brpc codebase and associated
>>artifacts(e.g. documentation etc.) to the Apache Software Foundation,
>>and aim to  build a wider open community around it in the 'Apache Way'.
>> 
>> 
>> ## Background
>> 
>> The RPC framework used in Baidu before 2014 was developed at 2008 and
>>limited in protocols and performance, and there were also serveral
>>implementations focused on their own scenarios from Baidu's different
>>BU. As an infrastructural team in Baidu, we tried to build a new
>>framework to unify all RPC scenarios inside. The framework was named
>>"baidu-rpc" internally the early versions were adopted and online at
>>late 2014. The framework was rapidly iterated at 2015-2017, and
>>thousands kinds of services and almost all core services adopted it. And
>>in 2017, we opensourced it as "brpc" and hope to get more adoptions and
>>contributions from outside. At the time of opensourcing, there're more
>>than 1 million instances inside Baidu using baidu-rpc (not counting
>>clients).
>> 
>> 
>> ## Rationale
>> 
>> brpc has been approved inside baidu, since many high performance core
>>services are using it.
>> And since its open source, it has been adopted by several other
>>companies, including Iqiyi, Didi, Sougou, BiliBili etc.
>> 
>> ## Current Status
>> 
>> brpc has been an open source project on GitHub
>>(https://github.com/brpc/brpc) since 2017.
>> 
>> Currently it has more than 7.3k stars, 1.6k forks, and is one of the
>>most popular repositories in topic of rpc category in GitHub rpc
>>catelogy.
>> It has been widely used in Baidu, with 1,000,000+ instances and
>>thousands kinds of services.
>> Besides, many other companies have already used it also, such as Iqiyi,
>>Didi, Sougou, BiliBili etc.
>> 
>> ### Meritocracy
>> 
>> brpc was originally created by Ge Jun and Chen zhangyi inside baidu
>>from 2014.
>> Since its opensource in 2017, it has already followed meritocracy
>>principles.
>> It accepts multiple contributions from other companies.
>> And now, the core developers are from several different companies.
>> 
>> We will follow Apache way to encourage more developers to contribute in
>>this project.
>> We know that only active and committed developers from a diverse set of
>>backgrounds
>> can make brpc a successful project.
>> 
>

Re: We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Jean-Baptiste Onofré]

Hi,

It's an interesting project. I have two questions:

1. do you have some interactions/dependencies with other Apache
projects, especially CXF for instance ?
2. what's the comparison between brpc and gRPC ? An alternative ?
Different features ?

I might be interested by mentoring the project, I would like to
understand exactly the target/purposes.

Thanks !
Regards
JB

On 13/09/2018 08:20, Tan,Zhongyi wrote:
> Hi, guys,
> 
> brpc is one open source RPC framework that is very popular in baidu and china.
> We want to contribute it to ASF to make it more successful.
> And we are looking for champion and mentor for this project,
> if anyone would like to volunteer, we will be very appreciated.
> 
> Thanks.
> 
> 
> Here is the draft for brpc proposal.
> 
> 
> # brpc Proposal
> 
> ## Abstract
> 
> brpc is an industrial-grade RPC framework for building reliable and 
> high-performance services.
> 
> ## Proposal
> 
> We propose to contribute the brpc codebase and associated artifacts(e.g. 
> documentation etc.) to the Apache Software Foundation, and aim to  build a 
> wider open community around it in the 'Apache Way'.
> 
> 
> ## Background
> 
> The RPC framework used in Baidu before 2014 was developed at 2008 and limited 
> in protocols and performance, and there were also serveral implementations 
> focused on their own scenarios from Baidu's different BU. As an 
> infrastructural team in Baidu, we tried to build a new framework to unify all 
> RPC scenarios inside. The framework was named "baidu-rpc" internally the 
> early versions were adopted and online at late 2014. The framework was 
> rapidly iterated at 2015-2017, and thousands kinds of services and almost all 
> core services adopted it. And in 2017, we opensourced it as "brpc" and hope 
> to get more adoptions and contributions from outside. At the time of 
> opensourcing, there're more than 1 million instances inside Baidu using 
> baidu-rpc (not counting clients).
> 
> 
> ## Rationale
> 
> brpc has been approved inside baidu, since many high performance core 
> services are using it.
> And since its open source, it has been adopted by several other companies, 
> including Iqiyi, Didi, Sougou, BiliBili etc.
> 
> ## Current Status
> 
> brpc has been an open source project on GitHub (https://github.com/brpc/brpc) 
> since 2017.
> 
> Currently it has more than 7.3k stars, 1.6k forks, and is one of the most 
> popular repositories in topic of rpc category in GitHub rpc catelogy.
> It has been widely used in Baidu, with 1,000,000+ instances and thousands 
> kinds of services.
> Besides, many other companies have already used it also, such as Iqiyi, Didi, 
> Sougou, BiliBili etc.
> 
> ### Meritocracy
> 
> brpc was originally created by Ge Jun and Chen zhangyi inside baidu from 2014.
> Since its opensource in 2017, it has already followed meritocracy principles.
> It accepts multiple contributions from other companies.
> And now, the core developers are from several different companies.
> 
> We will follow Apache way to encourage more developers to contribute in this 
> project.
> We know that only active and committed developers from a diverse set of 
> backgrounds
> can make brpc a successful project.
> 
> 
> ### Community
> 
> brpc has been building an active community since its open source. Currently,
> the community includes over 31 contributors.
> The core developers of brpc are listed below.
> 
> ### Core Developers
> 
> * Ge Jun(https://github.com/jamesge jge...@gmail.com)
> * Chen Zhangyi(https://github.com/chenzhangyi frozen@gmail.com)
> * Jiang Rujie(https://github.com/old-bear jrjb...@gmail.com)
> * Zhu Jiashun(http://github.com/zyearn zhujiashun2...@gmail.com)
> * Wang Yao(https://github.com/ipconfigme ipconfi...@gmail.com)
> 
> ### Alignment
> 
> brpc is useful for building reliable and high-performance applications.
> Since ASF has many famous performance-related and rpc-related projects,
> we believe that ASF is a perfect choice to help brpc project to attract
> more developers and users as well as having more cooperation with existing 
> projects.
> 
> ## Known Risks
> 
> ### Orphaned Products
> 
> Since our core developers are from different companies and many companies are 
> using it,
> the risk of the project being abandoned is minimal.
> For example, Baidu is extensively using it in their production environment
> and many large corporations including Iqiyi, Didi, Sougou, BiliBili use it in 
> their production applications.
> 
> 
> ### Inexperience with Open Source
> 
> brpc has been an active open source project for more than one year.
> During that time, the project has

We want to contribute brpc to ASF, looking for champion and mentor ,please help

[Tan,Zhongyi]

Hi, guys,

brpc is one open source RPC framework that is very popular in baidu and china.
We want to contribute it to ASF to make it more successful.
And we are looking for champion and mentor for this project,
if anyone would like to volunteer, we will be very appreciated.

Thanks.


Here is the draft for brpc proposal.


# brpc Proposal

## Abstract

brpc is an industrial-grade RPC framework for building reliable and 
high-performance services.

## Proposal

We propose to contribute the brpc codebase and associated artifacts(e.g. 
documentation etc.) to the Apache Software Foundation, and aim to  build a 
wider open community around it in the 'Apache Way'.


## Background

The RPC framework used in Baidu before 2014 was developed at 2008 and limited 
in protocols and performance, and there were also serveral implementations 
focused on their own scenarios from Baidu's different BU. As an infrastructural 
team in Baidu, we tried to build a new framework to unify all RPC scenarios 
inside. The framework was named "baidu-rpc" internally the early versions were 
adopted and online at late 2014. The framework was rapidly iterated at 
2015-2017, and thousands kinds of services and almost all core services adopted 
it. And in 2017, we opensourced it as "brpc" and hope to get more adoptions and 
contributions from outside. At the time of opensourcing, there're more than 1 
million instances inside Baidu using baidu-rpc (not counting clients).


## Rationale

brpc has been approved inside baidu, since many high performance core services 
are using it.
And since its open source, it has been adopted by several other companies, 
including Iqiyi, Didi, Sougou, BiliBili etc.

## Current Status

brpc has been an open source project on GitHub (https://github.com/brpc/brpc) 
since 2017.

Currently it has more than 7.3k stars, 1.6k forks, and is one of the most 
popular repositories in topic of rpc category in GitHub rpc catelogy.
It has been widely used in Baidu, with 1,000,000+ instances and thousands kinds 
of services.
Besides, many other companies have already used it also, such as Iqiyi, Didi, 
Sougou, BiliBili etc.

### Meritocracy

brpc was originally created by Ge Jun and Chen zhangyi inside baidu from 2014.
Since its opensource in 2017, it has already followed meritocracy principles.
It accepts multiple contributions from other companies.
And now, the core developers are from several different companies.

We will follow Apache way to encourage more developers to contribute in this 
project.
We know that only active and committed developers from a diverse set of 
backgrounds
can make brpc a successful project.


### Community

brpc has been building an active community since its open source. Currently,
the community includes over 31 contributors.
The core developers of brpc are listed below.

### Core Developers

* Ge Jun(https://github.com/jamesge jge...@gmail.com)
* Chen Zhangyi(https://github.com/chenzhangyi frozen@gmail.com)
* Jiang Rujie(https://github.com/old-bear jrjb...@gmail.com)
* Zhu Jiashun(http://github.com/zyearn zhujiashun2...@gmail.com)
* Wang Yao(https://github.com/ipconfigme ipconfi...@gmail.com)

### Alignment

brpc is useful for building reliable and high-performance applications.
Since ASF has many famous performance-related and rpc-related projects,
we believe that ASF is a perfect choice to help brpc project to attract
more developers and users as well as having more cooperation with existing 
projects.

## Known Risks

### Orphaned Products

Since our core developers are from different companies and many companies are 
using it,
the risk of the project being abandoned is minimal.
For example, Baidu is extensively using it in their production environment
and many large corporations including Iqiyi, Didi, Sougou, BiliBili use it in 
their production applications.


### Inexperience with Open Source

brpc has been an active open source project for more than one year.
During that time, the project has attracted 30+ contributors and gained a lot 
of attention.
The core developers are all active users and followers of open source.

### Homogenous Developers

brpc was created inside Baidu, but after brpc was open sourced, it received a 
lot of bug fixes and enhancements from other developers not working at Baidu.
And the core developers now are from different companies now.

### Reliance on Salaried Developers

Baidu invested in brpc as a general rpc framework used in company widely.
The core developers have been dedicated to this project for about four years.
And after its open source, developers around the world have involved in.
Besides, we want more developers and researchers to contribute to the project.

### An Excessive Fascination with the Apache Brand

The mission of brpc is to help developers build reliable and high-performance 
services quickly and easily.
It has been widely used in production environment throughout Baidu and after 
opensource, it has g

Re: Looking for Champion

[Li,De(BDG)]

Hi Jim,

Do you have any questions or suggestions about this Roadmap, please feel
free to let us know.

Best Regards,
Reed 

On 2018/6/21 下午8:06， "Li,De(BDG)"  wrote:

>We have a general Plan or Roadmap:
>
>1. Find out the code, modules, components which duplicates of Impala;
>2. Determine the features which could be merged to Impala under Impala
>community support.
>3, Define clearly the interface between the query engine and other
>components, such as the storage engine, metadata management, mysql server,
>load and export modules, web server and so on.
>4. Separate the Impala query engine from Palo.
>
>
>Best Regards,
>Reed
>
>On 2018/6/19 下午9:48， "Jim Apple"  wrote:
>
>>>
>>> I'm not sure if Palo is just a storage system but definitely we will
>>> separate query engine from Palo.
>>>
>>
>>That's great news, and I think it will benefit users of Impala and Palo.
>>
>>
>>> Of cource, as you mentioned, "this could be a lot of work", so it will
>>> take a long time and we also hope that Impala community could support
>>>us.
>>>
>>
>>Yes, I expect so.
>
>?B婯
>KKKCB??[溳
>X溫軞X橩??K[XZ[??賉橽榌?][溳X溫軞X橮?[樰X榏?軏榎?X?K涇櫭B憶軋?Y??]?[蹣[??
圹[X[???K[XZ[??賉橽榌
>?Z?[???[樰X榏?軏榎?X?K涇櫭B

Re: Looking for Champion

[Jim Apple]

Looks great!

On Thu, Jun 21, 2018 at 5:06 AM Li,De(BDG)  wrote:

> We have a general Plan or Roadmap:
>
> 1. Find out the code, modules, components which duplicates of Impala;
> 2. Determine the features which could be merged to Impala under Impala
> community support.
> 3, Define clearly the interface between the query engine and other
> components, such as the storage engine, metadata management, mysql server,
> load and export modules, web server and so on.
> 4. Separate the Impala query engine from Palo.
>
>
> Best Regards,
> Reed
>
> On 2018/6/19 下午9:48， "Jim Apple"  wrote:
>
> >>
> >> I'm not sure if Palo is just a storage system but definitely we will
> >> separate query engine from Palo.
> >>
> >
> >That's great news, and I think it will benefit users of Impala and Palo.
> >
> >
> >> Of cource, as you mentioned, "this could be a lot of work", so it will
> >> take a long time and we also hope that Impala community could support
> >>us.
> >>
> >
> >Yes, I expect so.
>
>

Re: Looking for Champion

[Li,De(BDG)]

We have a general Plan or Roadmap:

1. Find out the code, modules, components which duplicates of Impala;
2. Determine the features which could be merged to Impala under Impala
community support.
3, Define clearly the interface between the query engine and other
components, such as the storage engine, metadata management, mysql server,
load and export modules, web server and so on.
4. Separate the Impala query engine from Palo.


Best Regards,
Reed

On 2018/6/19 下午9:48， "Jim Apple"  wrote:

>>
>> I'm not sure if Palo is just a storage system but definitely we will
>> separate query engine from Palo.
>>
>
>That's great news, and I think it will benefit users of Impala and Palo.
>
>
>> Of cource, as you mentioned, "this could be a lot of work", so it will
>> take a long time and we also hope that Impala community could support
>>us.
>>
>
>Yes, I expect so.

Re: Looking for Champion

[Li,De(BDG)]

 load should not be very large.

##Initial Committers

* Ruyue Ma (https://github.com/maruyue, maru...@baidu.com)
* Chun Zhao (https://github.com/imay, buaa.zh...@gmail.com)
* Mingyu Chen (https://github.com/morningman,chenmin...@baidu.com)
* De Li（https://github.com/lide-reed, mailtol...@sina.com）
* Hao Chen (https://github.com/chenhao7253886, chenha...@baidu.com)
* Chaoyong Li (https://github.com/cyongli, lichaoy...@baidu.com)
* Bin Lin (https://github.com/lingbin, lingbi...@gmail.com)
* Sijie Guo (guosi...@gmail.com)
* Zheng Shao (zs...@apache.org)

##Affiliations

The initial committers are employees of Baidu Inc..

##Sponsors

###Champion

Dave Fisher, dave2w...@comcast.net

###Nominated Mentors

* Luke Han, luke...@apache.org
* Dave Fisher, dave2w...@comcast.net
* Willem Jiang, willem.ji...@gmail.com

###Sponsoring Entity

We are requesting the Incubator to sponsor this project.

On 2018/6/19 下午6:54， "Li,De(BDG)" mailto:l...@baidu.com>> wrote:

Hi Dave,

Thank you for your summary.

For #1, I got it, we will find a new name ASAP within several days.

For #2, I see, about license, we are rechecking all licenses of components in 
Palo, and we have fixed most of those we found as I wrote in last email. Next, 
we will continue to do this work carefully.

For #3, We have reflected upon Jim's suggestion, and we will try to find out or 
define a cleanly interface between Palo and Impala and to determine which parts 
should keep in Palo and which parts should as patches for Impala. More detail 
and roadmap are still to be work out.

For #4, I accepted your suggestion and I will update proposal.

Once I have a new name, I will send you with updated proposal.

Best Regards,
Reed

发件人: Dave Fisher mailto:dave2w...@comcast.net>>
答复: mailto:general@incubator.apache.org>>
日期: 2018年6月19日 星期二 上午2:08
至: mailto:general@incubator.apache.org>>
主题: Re: Looking for Champion

Hi Li,De -

Since I agreed to champion this project I think that we need a summary about 
what the Incubator PMC cares about in order to accept a podling. What the 
prospective project needs to address. We also need to be clear what should 
happen during Incubation and at what time. I think that many of the questions 
that came up in this thread had to do with assessing how much effort it will 
take to Incubate Palo (or whatever the name will be)

(1) The name Palo. Since there seems to be an issue with that name we should 
have a new name. It is not unknown for a podling to change its name, but that 
does generate extra work for Infrastructure to change the name after podling 
start up. It would be our preference for Palo to find a new name prior to 
VOTING on the proposal. Please do this elsewhere and come back to me with the 
new name so that I can help with the updated proposal.

(2) Licensing of the software. Several bits came up as questionable. Regardless 
of cleanup that has already occurred we have identified that we will need to be 
very careful. It will be important to discuss and carefully handle the Software 
Grant Agreement to make sure that the source listed is correct. I think that 
the SGA must come early during incubation.

(3) Relationship with Impala. Palo has apparently forked portions of Impala. 
This means that some are concerned that there is a missed synergy with the 
Apache Impala project. Is there a clean interface that can be built between the 
projects? It would help if the Palo developers would explore this with Impala 
at d...@impala.apache.org<mailto:d...@impala.apache.org>.

That said, part of the Incubation process is to learn the Apache Way. IMHO it 
is ok for the relationship between Impala PMC and a pooling PPMC to be a work 
in process.

(4) Currently, Willem, Luke Han and Dave Fisher are qualified to officially 
mentor. I suggest that Sijie Guo and Zheng Shao be included as Initial 
Committers in order to help from within the PPMC.

On Jun 14, 2018, at 11:03 AM, Jim Apple 
mailto:jbap...@cloudera.com.INVALID>> wrote:

I don't want to be a stickler, but I don't think "For issues mentioned by
Jim, Todd and Tim, I have replied on last Saturday."

To my email about Palo being an ASF project as a storage system without a
query engine, you replied only, "We will seriously consider this proposal."

I see no response to Tim's concern that "The code isn't owned by any
individual, I contributed it to Apache and it's
free for anyone to do what they want to do with it, but pulling in
improvements from other projects without any attempt to attribute it or
contribute improvements back seems contrary to the Apache way.”

Jim - do you need answers to these concerns prior to agreeing to accept this 
project into the Incubator?

Regards,
Dave


On Thu, Jun 14, 2018 at 12:48 AM, Li,De(BDG) 
mailto:l...@baidu.com>> wrote:

Hi all,

About Palo, we have fixed following issues.

1. Related Impala
For issues mentioned by Jim, Todd and Tim, I have replied on la

Re: Looking for Champion

[Luke Han]

I think this should leave to the team who contribute to this project, those
projects could share different purpose but also can work together...if the
architecture is flexible enough.

Jim Apple 于2018年6月19日周二 上午5:39写道：

> Let me respond specifically to a few of these as a way to, I hope,
> inspire the Palo community to reconsider contributing to Impala. It
> could be a great opportunity for us to produce value by keeping the
> query engine working smoothly while the Palo community can focus more
> of their efforts on the storage system. There is some analogue here
> with how Impala works on other storage systems.
>
> > Firstly, as a query engine for Hadoop, Impala deeply depend on HDFS and
> > HBase
> > (At least several years ago it was like this)
>
> Impala can run on other storage. See, for instance
> http://impala.apache.org/docs/build/html/topics/impala_kudu.html and
> http://impala.apache.org/docs/build/html/topics/impala_isilon.html
>
> > Secondly, due to introduced Mesa data model. The Catalog is different
> from
> > Impala.
> > We developped a In-Memory Catalog and also support Rollup, aggregation
> > data
> > model. As a consequnce, we have to change sql grammar based on Impala.
>
> Impala supports catalog data cached in memory, and adding new features
> to Impala's SQL grammar is not forbidden. I think one of my first
> largish contributions changed the grammar.
>
> > Thirdly, it is a big difference in Cluster manager and node deployment.
> > Contrast Impala, Query compiling, query execution coordination and
> catalog
> > management of storage engine are integrated to be frontend daemon.
> > Query execution and data storage are integrated to be backend daemon.
>
> I'm not sure I understand - how is Palo different here?
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Looking for Champion

[Luke Han]

Incubating progress is something how to fix such issue, there's no need
such plan at this moment

Ryan Blue 于2018年6月19日周二 上午4:13写道：

> Okay, then let me rephrase: I would like to see a plan in the Palo proposal
> for a licensing scrub to be done before graduation.
>
> I'm still a little skeptical about this practice because the Incubator PMC
> validates the release on behalf of the foundation, but I think that's a
> separate issue to consider that doesn't need to distract on this Palo
> thread. Thanks for the explanation, Greg!
>
> On Mon, Jun 18, 2018 at 1:00 PM, Greg Stein  wrote:
>
> > Heya Ryan,
> >
> > On Mon, Jun 18, 2018 at 2:39 PM Ryan Blue  wrote:
> >
> >> > we have allowed (and IMO should continue) podlings to have licensing
> >> issues during their incubator releases
> >>
> >> Thanks for pointing this out, Greg. I wasn't aware of this and have
> >> always had releases fail when we discover licensing issues. I think
> there's
> >> a significant risk of license problems, so I had assumed we would
> require a
> >> thorough scrub before the first release.
> >>
> >> What's the argument for finishing this work before graduation rather
> than
> >> first release? Isn't the release a product for which the ASF is legally
> >> responsible? Given that we fail releases for known license issues,
> >> shouldn't we also be more careful when we know there are likely to be
> >> issues?
> >>
> >
> > This is why incubator releases have a disclaimer. It gives them time to
> > work through dependency and licensing issues, even while they're testing
> > their release process with our KEYS and distribution framework. So the
> > "argument" is simply to allow the podling to multitask, rather than gate
> > one of their activities.
> >
> > When you really want to lift the cover, there isn't a problem if a
> podling
> > releases (say) a hard LGPL dependency. That's just a policy choice of the
> > Foundation, to avoid such dependencies. We don't like it, and maybe some
> > messed up licensing downstream, possibly, for somebody to tease apart.
> But
> > historically, the Incubator has let these issues slide for a while, yet
> > gate on graduation.
> >
> > I also feel that podling releases are in a grey area, that don't truly
> > have the full backing of the ASF (thus the disclaimer, and them not
> being a
> > TLP; although technically the Apache Incubator is the stand-in PMC behind
> > the release).
> >
> > Cheers,
> > -g
> >
> >
>
>
> --
> Ryan Blue
> Software Engineer
> Netflix
>

Re: Looking for Champion

[Jim Apple]

>
> I'm not sure if Palo is just a storage system but definitely we will
> separate query engine from Palo.
>

That's great news, and I think it will benefit users of Impala and Palo.


> Of cource, as you mentioned, "this could be a lot of work", so it will
> take a long time and we also hope that Impala community could support us.
>

Yes, I expect so.

Re: Looking for Champion

[Li,De(BDG)]

ot;We will seriously consider this
>> proposal."
>> >
>> > I see no response to Tim's concern that "The code isn't owned by any
>> > individual, I contributed it to Apache and it's
>> > free for anyone to do what they want to do with it, but pulling in
>> > improvements from other projects without any attempt to attribute it
>>or
>> > contribute improvements back seems contrary to the Apache way.”
>> >
>> >
>> > Jim - do you need answers to these concerns prior to agreeing to
>>accept
>> this
>> > project into the Incubator?
>> >
>> > Regards,
>> > Dave
>> >
>> >
>> > On Thu, Jun 14, 2018 at 12:48 AM, Li,De(BDG)  wrote:
>> >
>> > Hi all,
>> >
>> > About Palo, we have fixed following issues.
>> >
>> > 1. Related Impala
>> > For issues mentioned by Jim, Todd and Tim, I have replied on last
>> Saturday.
>> >
>> > 2、Lisence issue
>> > For issues mentioned by Todd and Ted.
>> > 1) be/aes/* come from mysql-5.6, GPL v2.1 license
>> > Fixed: removed aes related codes.
>> > https://github.com/baidu/palo/commit/ac770c33d445a4c18a0b74f56b28a4
>> > 180b30bf
>> > b7
>> > https://github.com/baidu/palo/commit/3c9f2ae6695ffebe41e39b6bf65440
>> > 77698f1c
>> > ed
>> >
>> > 2) be/util/mysql_dtoa.cpp copy from MySQL, GPL license
>> > Fixed: removed mysql_dtoa related codes.
>> > https://github.com/baidu/palo/commit/bfe1bc7cf39e165a7c52b2c9415509
>> > 75b1f841
>> > a1
>> >
>> > 3) be/http/mongoose.h, Copyright (c) 2004-2012 Sergey Lyubka
>> > Fixed: restored to original lisence, we are searching another http
>>server
>> > to replace it.
>> > https://github.com/baidu/palo/commit/81baef34f48a2dbe7401712c5e0a50
>> > f59f04a8
>> > 31
>> >
>> > 4) be/rpc/*
>> > Fixed: We have replaced it with brpc, and we will remove Hypertable
>>after
>> > few weeks for waiting users' upgrade to brpc.
>> > https://github.com/baidu/palo/tree/master/be/src/rpc
>> >
>> > 3、Dependency licenses
>> > For issue mentioned by Dave, It looks like that Palo have not depend
>>on
>> > OpenLdap and cyrus-sasl directly,
>> > but some thirdpary libraries need them to compile, libcurl and
>>gperftools
>> > for instance.
>> > For rapidjson, we are looking for alternative one.
>> >
>> > 4、About the name of Palo
>> > For issue mentioned by Julian.
>> > We are figuring out a better one.
>> >
>> > Best Regards,
>> > Reed
>> >
>> >
>> >
>> > 在 2018/6/13 上午8:54， "Li,De(BDG)"  写入:
>> >
>> > Hi Julian,
>> >
>> > Thank you.
>> >
>> > It looks like that we have to find another one.
>> > If anyone has a good name, please feel free to let me know.
>> >
>> > Best Regards,
>> > Reed
>> >
>> > 在 2018/6/13 上午4:20， "Julian Hyde"  写入:
>> >
>> > Note that there is an existing database product called Palo - an open
>> > source OLAP engine by German company Jedox[1]. There there is a high
>> > likelihood that Palo would have to change its name during incubation,
>>if
>> > accepted.
>> >
>> > Julian
>> >
>> > [1] https://en.wikipedia.org/wiki/Palo_(OLAP_database)
>> > <https://en.wikipedia.org/wiki/Palo_(OLAP_database)>
>> >
>> >
>> >
>> > On Jun 10, 2018, at 3:49 AM, Han Luke  wrote:
>> >
>> > Cool Dave, it’s great to have you to be the campaign.
>> >
>> >
>> > 
>> > From: Tan,Zhongyi mailto:tanzhon...@baidu.com>>
>> > Sent: Saturday, June 9, 2018 8:16:28 AM
>> > To: general@incubator.apache.org <mailto:general@incubator.apache.org>
>> > Subject: Re: Looking for Champion
>> >
>> > thanks，willem
>> >
>> > we are very appreciate.
>> >
>> > 在 2018年6月8日，23:03，Willem Jiang  写道：
>> >
>> > Hi,
>> >
>> > I'm willing to be the Mentor.
>> > Please count me in.
>> >
>> >
>> >
>> > Willem Jiang
>> >
>> > Twitter: willemjiang
>> > Weibo: 姜宁willem
>> >
>> > On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher 
>> > wrote:
>> >
>> > Hi -

Re: Looking for Champion

[Li,De(BDG)]

Hi Dave,

Thank you for your summary.

For #1, I got it, we will find a new name ASAP within several days.

For #2, I see, about license, we are rechecking all licenses of components in 
Palo, and we have fixed most of those we found as I wrote in last email. Next, 
we will continue to do this work carefully.

For #3, We have reflected upon Jim's suggestion, and we will try to find out or 
define a cleanly interface between Palo and Impala and to determine which parts 
should keep in Palo and which parts should as patches for Impala. More detail 
and roadmap are still to be work out.

For #4, I accepted your suggestion and I will update proposal.

Once I have a new name, I will send you with updated proposal.

Best Regards,
Reed

发件人: Dave Fisher mailto:dave2w...@comcast.net>>
答复: mailto:general@incubator.apache.org>>
日期: 2018年6月19日 星期二 上午2:08
至: mailto:general@incubator.apache.org>>
主题: Re: Looking for Champion

Hi Li,De -

Since I agreed to champion this project I think that we need a summary about 
what the Incubator PMC cares about in order to accept a podling. What the 
prospective project needs to address. We also need to be clear what should 
happen during Incubation and at what time. I think that many of the questions 
that came up in this thread had to do with assessing how much effort it will 
take to Incubate Palo (or whatever the name will be)

(1) The name Palo. Since there seems to be an issue with that name we should 
have a new name. It is not unknown for a podling to change its name, but that 
does generate extra work for Infrastructure to change the name after podling 
start up. It would be our preference for Palo to find a new name prior to 
VOTING on the proposal. Please do this elsewhere and come back to me with the 
new name so that I can help with the updated proposal.

(2) Licensing of the software. Several bits came up as questionable. Regardless 
of cleanup that has already occurred we have identified that we will need to be 
very careful. It will be important to discuss and carefully handle the Software 
Grant Agreement to make sure that the source listed is correct. I think that 
the SGA must come early during incubation.

(3) Relationship with Impala. Palo has apparently forked portions of Impala. 
This means that some are concerned that there is a missed synergy with the 
Apache Impala project. Is there a clean interface that can be built between the 
projects? It would help if the Palo developers would explore this with Impala 
at d...@impala.apache.org<mailto:d...@impala.apache.org>.

That said, part of the Incubation process is to learn the Apache Way. IMHO it 
is ok for the relationship between Impala PMC and a pooling PPMC to be a work 
in process.

(4) Currently, Willem, Luke Han and Dave Fisher are qualified to officially 
mentor. I suggest that Sijie Guo and Zheng Shao be included as Initial 
Committers in order to help from within the PPMC.

On Jun 14, 2018, at 11:03 AM, Jim Apple 
mailto:jbap...@cloudera.com.INVALID>> wrote:

I don't want to be a stickler, but I don't think "For issues mentioned by
Jim, Todd and Tim, I have replied on last Saturday."

To my email about Palo being an ASF project as a storage system without a
query engine, you replied only, "We will seriously consider this proposal."

I see no response to Tim's concern that "The code isn't owned by any
individual, I contributed it to Apache and it's
free for anyone to do what they want to do with it, but pulling in
improvements from other projects without any attempt to attribute it or
contribute improvements back seems contrary to the Apache way.”

Jim - do you need answers to these concerns prior to agreeing to accept this 
project into the Incubator?

Regards,
Dave


On Thu, Jun 14, 2018 at 12:48 AM, Li,De(BDG) 
mailto:l...@baidu.com>> wrote:

Hi all,

About Palo, we have fixed following issues.

1. Related Impala
For issues mentioned by Jim, Todd and Tim, I have replied on last Saturday.

2、Lisence issue
For issues mentioned by Todd and Ted.
1) be/aes/* come from mysql-5.6, GPL v2.1 license
Fixed: removed aes related codes.
https://github.com/baidu/palo/commit/ac770c33d445a4c18a0b74f56b28a4
180b30bf
b7
https://github.com/baidu/palo/commit/3c9f2ae6695ffebe41e39b6bf65440
77698f1c
ed

2) be/util/mysql_dtoa.cpp copy from MySQL, GPL license
Fixed: removed mysql_dtoa related codes.
https://github.com/baidu/palo/commit/bfe1bc7cf39e165a7c52b2c9415509
75b1f841
a1

3) be/http/mongoose.h, Copyright (c) 2004-2012 Sergey Lyubka
Fixed: restored to original lisence, we are searching another http server
to replace it.
https://github.com/baidu/palo/commit/81baef34f48a2dbe7401712c5e0a50
f59f04a8
31

4) be/rpc/*
Fixed: We have replaced it with brpc, and we will remove Hypertable after
few weeks for waiting users' upgrade to brpc.
https://github.com/baidu/palo/tree/master/be/src/rpc

3、Dependency licenses
For issue mentioned by Dave, It looks like 

Re: Looking for Champion

[Li,De(BDG)]

Hi Jim,

Thank you for your response.

We have reflected upon your suggestion and we agree with you for the most
part.
We will try to find out or define a cleanly interface between Palo and
Impala and to determine which parts should keep in Palo and which parts
should as patches for Impala.
I'm not sure if Palo is just a storage system but definitely we will
separate query engine from Palo.
Of cource, as you mentioned, "this could be a lot of work", so it will
take a long time and we also hope that Impala community could support us.

For Tim's concern, as I said in another email, what we have done ever
maybe not in Apache way but I think it is a good opportuniy to us to
participate in open source community and learn to do things in Apache way,
including how to corporate with Impala community (indeed we lack of
interaction).

Best Regards,
Reed



在 2018/6/15 上午2:03， "Jim Apple"  写入:

>I don't want to be a stickler, but I don't think "For issues mentioned by
>Jim, Todd and Tim, I have replied on last Saturday."
>
>To my email about Palo being an ASF project as a storage system without a
>query engine, you replied only, "We will seriously consider this
>proposal."
>
>I see no response to Tim's concern that "The code isn't owned by any
>individual, I contributed it to Apache and it's
>free for anyone to do what they want to do with it, but pulling in
>improvements from other projects without any attempt to attribute it or
>contribute improvements back seems contrary to the Apache way."
>
>On Thu, Jun 14, 2018 at 12:48 AM, Li,De(BDG)  wrote:
>
>> Hi all,
>>
>> About Palo, we have fixed following issues.
>>
>> 1. Related Impala
>> For issues mentioned by Jim, Todd and Tim, I have replied on last
>>Saturday.
>>
>> 2、Lisence issue
>> For issues mentioned by Todd and Ted.
>> 1) be/aes/* come from mysql-5.6, GPL v2.1 license
>> Fixed: removed aes related codes.
>> https://github.com/baidu/palo/commit/ac770c33d445a4c18a0b74f56b28a4
>> 180b30bf
>> b7
>> https://github.com/baidu/palo/commit/3c9f2ae6695ffebe41e39b6bf65440
>> 77698f1c
>> ed
>>
>> 2) be/util/mysql_dtoa.cpp copy from MySQL, GPL license
>> Fixed: removed mysql_dtoa related codes.
>> https://github.com/baidu/palo/commit/bfe1bc7cf39e165a7c52b2c9415509
>> 75b1f841
>> a1
>>
>> 3) be/http/mongoose.h, Copyright (c) 2004-2012 Sergey Lyubka
>> Fixed: restored to original lisence, we are searching another http
>>server
>> to replace it.
>> https://github.com/baidu/palo/commit/81baef34f48a2dbe7401712c5e0a50
>> f59f04a8
>> 31
>>
>> 4) be/rpc/*
>> Fixed: We have replaced it with brpc, and we will remove Hypertable
>>after
>> few weeks for waiting users' upgrade to brpc.
>> https://github.com/baidu/palo/tree/master/be/src/rpc
>>
>> 3、Dependency licenses
>> For issue mentioned by Dave, It looks like that Palo have not depend on
>> OpenLdap and cyrus-sasl directly,
>> but some thirdpary libraries need them to compile, libcurl and
>>gperftools
>> for instance.
>> For rapidjson, we are looking for alternative one.
>>
>> 4、About the name of Palo
>> For issue mentioned by Julian.
>> We are figuring out a better one.
>>
>> Best Regards,
>> Reed
>>
>>
>>
>> 在 2018/6/13 上午8:54， "Li,De(BDG)"  写入:
>>
>> >Hi Julian,
>> >
>> >Thank you.
>> >
>> >It looks like that we have to find another one.
>> >If anyone has a good name, please feel free to let me know.
>> >
>> >Best Regards,
>> >Reed
>> >
>> >在 2018/6/13 上午4:20， "Julian Hyde"  写入:
>> >
>> >>Note that there is an existing database product called Palo - an open
>> >>source OLAP engine by German company Jedox[1]. There there is a high
>> >>likelihood that Palo would have to change its name during incubation,
>>if
>> >>accepted.
>> >>
>> >>Julian
>> >>
>> >>[1] https://en.wikipedia.org/wiki/Palo_(OLAP_database)
>> >><https://en.wikipedia.org/wiki/Palo_(OLAP_database)>
>> >>
>> >>
>> >>
>> >>> On Jun 10, 2018, at 3:49 AM, Han Luke  wrote:
>> >>>
>> >>> Cool Dave, it’s great to have you to be the campaign.
>> >>>
>> >>>
>> >>> 
>> >>> From: Tan,Zhongyi ><mailto:tanzhon...@baidu.com>>
>> >>> Sent: Saturday, June 9, 2018 8:16:28 AM
>> >>> 

Re: Looking for Champion

[Jim Apple]

Let me respond specifically to a few of these as a way to, I hope,
inspire the Palo community to reconsider contributing to Impala. It
could be a great opportunity for us to produce value by keeping the
query engine working smoothly while the Palo community can focus more
of their efforts on the storage system. There is some analogue here
with how Impala works on other storage systems.

> Firstly, as a query engine for Hadoop, Impala deeply depend on HDFS and
> HBase
> (At least several years ago it was like this)

Impala can run on other storage. See, for instance
http://impala.apache.org/docs/build/html/topics/impala_kudu.html and
http://impala.apache.org/docs/build/html/topics/impala_isilon.html

> Secondly, due to introduced Mesa data model. The Catalog is different from
> Impala.
> We developped a In-Memory Catalog and also support Rollup, aggregation
> data
> model. As a consequnce, we have to change sql grammar based on Impala.

Impala supports catalog data cached in memory, and adding new features
to Impala's SQL grammar is not forbidden. I think one of my first
largish contributions changed the grammar.

> Thirdly, it is a big difference in Cluster manager and node deployment.
> Contrast Impala, Query compiling, query execution coordination and catalog
> management of storage engine are integrated to be frontend daemon.
> Query execution and data storage are integrated to be backend daemon.

I'm not sure I understand - how is Palo different here?

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for Champion

[Ted Dunning]

The licensing scrub does need to be done. But not necessarily before
incubation starts.



On Mon, Jun 18, 2018 at 10:13 PM Ryan Blue 
wrote:

> Okay, then let me rephrase: I would like to see a plan in the Palo proposal
> for a licensing scrub to be done before graduation.
>
> I'm still a little skeptical about this practice because the Incubator PMC
> validates the release on behalf of the foundation, but I think that's a
> separate issue to consider that doesn't need to distract on this Palo
> thread. Thanks for the explanation, Greg!
>
> On Mon, Jun 18, 2018 at 1:00 PM, Greg Stein  wrote:
>
> > Heya Ryan,
> >
> > On Mon, Jun 18, 2018 at 2:39 PM Ryan Blue  wrote:
> >
> >> > we have allowed (and IMO should continue) podlings to have licensing
> >> issues during their incubator releases
> >>
> >> Thanks for pointing this out, Greg. I wasn't aware of this and have
> >> always had releases fail when we discover licensing issues. I think
> there's
> >> a significant risk of license problems, so I had assumed we would
> require a
> >> thorough scrub before the first release.
> >>
> >> What's the argument for finishing this work before graduation rather
> than
> >> first release? Isn't the release a product for which the ASF is legally
> >> responsible? Given that we fail releases for known license issues,
> >> shouldn't we also be more careful when we know there are likely to be
> >> issues?
> >>
> >
> > This is why incubator releases have a disclaimer. It gives them time to
> > work through dependency and licensing issues, even while they're testing
> > their release process with our KEYS and distribution framework. So the
> > "argument" is simply to allow the podling to multitask, rather than gate
> > one of their activities.
> >
> > When you really want to lift the cover, there isn't a problem if a
> podling
> > releases (say) a hard LGPL dependency. That's just a policy choice of the
> > Foundation, to avoid such dependencies. We don't like it, and maybe some
> > messed up licensing downstream, possibly, for somebody to tease apart.
> But
> > historically, the Incubator has let these issues slide for a while, yet
> > gate on graduation.
> >
> > I also feel that podling releases are in a grey area, that don't truly
> > have the full backing of the ASF (thus the disclaimer, and them not
> being a
> > TLP; although technically the Apache Incubator is the stand-in PMC behind
> > the release).
> >
> > Cheers,
> > -g
> >
> >
>
>
> --
> Ryan Blue
> Software Engineer
> Netflix
>

Re: Looking for Champion

[Ryan Blue]

Okay, then let me rephrase: I would like to see a plan in the Palo proposal
for a licensing scrub to be done before graduation.

I'm still a little skeptical about this practice because the Incubator PMC
validates the release on behalf of the foundation, but I think that's a
separate issue to consider that doesn't need to distract on this Palo
thread. Thanks for the explanation, Greg!

On Mon, Jun 18, 2018 at 1:00 PM, Greg Stein  wrote:

> Heya Ryan,
>
> On Mon, Jun 18, 2018 at 2:39 PM Ryan Blue  wrote:
>
>> > we have allowed (and IMO should continue) podlings to have licensing
>> issues during their incubator releases
>>
>> Thanks for pointing this out, Greg. I wasn't aware of this and have
>> always had releases fail when we discover licensing issues. I think there's
>> a significant risk of license problems, so I had assumed we would require a
>> thorough scrub before the first release.
>>
>> What's the argument for finishing this work before graduation rather than
>> first release? Isn't the release a product for which the ASF is legally
>> responsible? Given that we fail releases for known license issues,
>> shouldn't we also be more careful when we know there are likely to be
>> issues?
>>
>
> This is why incubator releases have a disclaimer. It gives them time to
> work through dependency and licensing issues, even while they're testing
> their release process with our KEYS and distribution framework. So the
> "argument" is simply to allow the podling to multitask, rather than gate
> one of their activities.
>
> When you really want to lift the cover, there isn't a problem if a podling
> releases (say) a hard LGPL dependency. That's just a policy choice of the
> Foundation, to avoid such dependencies. We don't like it, and maybe some
> messed up licensing downstream, possibly, for somebody to tease apart. But
> historically, the Incubator has let these issues slide for a while, yet
> gate on graduation.
>
> I also feel that podling releases are in a grey area, that don't truly
> have the full backing of the ASF (thus the disclaimer, and them not being a
> TLP; although technically the Apache Incubator is the stand-in PMC behind
> the release).
>
> Cheers,
> -g
>
>


-- 
Ryan Blue
Software Engineer
Netflix

Re: Looking for Champion

[Greg Stein]

Heya Ryan,

On Mon, Jun 18, 2018 at 2:39 PM Ryan Blue  wrote:

> > we have allowed (and IMO should continue) podlings to have licensing
> issues during their incubator releases
>
> Thanks for pointing this out, Greg. I wasn't aware of this and have always
> had releases fail when we discover licensing issues. I think there's a
> significant risk of license problems, so I had assumed we would require a
> thorough scrub before the first release.
>
> What's the argument for finishing this work before graduation rather than
> first release? Isn't the release a product for which the ASF is legally
> responsible? Given that we fail releases for known license issues,
> shouldn't we also be more careful when we know there are likely to be
> issues?
>

This is why incubator releases have a disclaimer. It gives them time to
work through dependency and licensing issues, even while they're testing
their release process with our KEYS and distribution framework. So the
"argument" is simply to allow the podling to multitask, rather than gate
one of their activities.

When you really want to lift the cover, there isn't a problem if a podling
releases (say) a hard LGPL dependency. That's just a policy choice of the
Foundation, to avoid such dependencies. We don't like it, and maybe some
messed up licensing downstream, possibly, for somebody to tease apart. But
historically, the Incubator has let these issues slide for a while, yet
gate on graduation.

I also feel that podling releases are in a grey area, that don't truly have
the full backing of the ASF (thus the disclaimer, and them not being a TLP;
although technically the Apache Incubator is the stand-in PMC behind the
release).

Cheers,
-g

Re: Looking for Champion

[Ryan Blue]

> we have allowed (and IMO should continue) podlings to have licensing
issues during their incubator releases

Thanks for pointing this out, Greg. I wasn't aware of this and have always
had releases fail when we discover licensing issues. I think there's a
significant risk of license problems, so I had assumed we would require a
thorough scrub before the first release.

What's the argument for finishing this work before graduation rather than
first release? Isn't the release a product for which the ASF is legally
responsible? Given that we fail releases for known license issues,
shouldn't we also be more careful when we know there are likely to be
issues?

rb

On Mon, Jun 18, 2018 at 12:24 PM, Greg Stein  wrote:

> On Mon, Jun 18, 2018 at 2:08 PM Ryan Blue 
> wrote:
> >...
>
>> 2. The license problems so far show that the project has not paid adequate
>> attention to licensing up to now, which is a big risk. I'd like to see
>> what
>> kind of licensing scrub is proposed before the potential podling's first
>> release. I don't think that catching all the obvious ones is sufficient.
>
>
> To be clear: we have allowed (and IMO should continue) podlings to have
> licensing issues during their incubator releases. For example, while
> they're still dealing with Hibernate dependencies. It is understandable and
> (IMO) acceptable that such releases will have problems. That is just part
> of the process. As long as it gets cleaned up before graduation.
>
> Not diminishing the need for a good scrub, but I would not want to see
> releases gated on that. (it's unclear from your text; maybe just a *plan*
> rather than completion of the scrub?)
>
> Cheers,
> -g
>
>


-- 
Ryan Blue
Software Engineer
Netflix

Re: Looking for Champion

[Greg Stein]

On Mon, Jun 18, 2018 at 2:08 PM Ryan Blue  wrote:
>...

> 2. The license problems so far show that the project has not paid adequate
> attention to licensing up to now, which is a big risk. I'd like to see what
> kind of licensing scrub is proposed before the potential podling's first
> release. I don't think that catching all the obvious ones is sufficient.


To be clear: we have allowed (and IMO should continue) podlings to have
licensing issues during their incubator releases. For example, while
they're still dealing with Hibernate dependencies. It is understandable and
(IMO) acceptable that such releases will have problems. That is just part
of the process. As long as it gets cleaned up before graduation.

Not diminishing the need for a good scrub, but I would not want to see
releases gated on that. (it's unclear from your text; maybe just a *plan*
rather than completion of the scrub?)

Cheers,
-g

Re: Looking for Champion

[Ryan Blue]

sue
> > For issues mentioned by Todd and Ted.
> > 1) be/aes/* come from mysql-5.6, GPL v2.1 license
> > Fixed: removed aes related codes.
> > https://github.com/baidu/palo/commit/ac770c33d445a4c18a0b74f56b28a4
> > 180b30bf
> > b7
> > https://github.com/baidu/palo/commit/3c9f2ae6695ffebe41e39b6bf65440
> > 77698f1c
> > ed
> >
> > 2) be/util/mysql_dtoa.cpp copy from MySQL, GPL license
> > Fixed: removed mysql_dtoa related codes.
> > https://github.com/baidu/palo/commit/bfe1bc7cf39e165a7c52b2c9415509
> > 75b1f841
> > a1
> >
> > 3) be/http/mongoose.h, Copyright (c) 2004-2012 Sergey Lyubka
> > Fixed: restored to original lisence, we are searching another http server
> > to replace it.
> > https://github.com/baidu/palo/commit/81baef34f48a2dbe7401712c5e0a50
> > f59f04a8
> > 31
> >
> > 4) be/rpc/*
> > Fixed: We have replaced it with brpc, and we will remove Hypertable after
> > few weeks for waiting users' upgrade to brpc.
> > https://github.com/baidu/palo/tree/master/be/src/rpc
> >
> > 3、Dependency licenses
> > For issue mentioned by Dave, It looks like that Palo have not depend on
> > OpenLdap and cyrus-sasl directly,
> > but some thirdpary libraries need them to compile, libcurl and gperftools
> > for instance.
> > For rapidjson, we are looking for alternative one.
> >
> > 4、About the name of Palo
> > For issue mentioned by Julian.
> > We are figuring out a better one.
> >
> > Best Regards,
> > Reed
> >
> >
> >
> > 在 2018/6/13 上午8:54， "Li,De(BDG)"  写入:
> >
> > Hi Julian,
> >
> > Thank you.
> >
> > It looks like that we have to find another one.
> > If anyone has a good name, please feel free to let me know.
> >
> > Best Regards,
> > Reed
> >
> > 在 2018/6/13 上午4:20， "Julian Hyde"  写入:
> >
> > Note that there is an existing database product called Palo - an open
> > source OLAP engine by German company Jedox[1]. There there is a high
> > likelihood that Palo would have to change its name during incubation, if
> > accepted.
> >
> > Julian
> >
> > [1] https://en.wikipedia.org/wiki/Palo_(OLAP_database)
> > <https://en.wikipedia.org/wiki/Palo_(OLAP_database)>
> >
> >
> >
> > On Jun 10, 2018, at 3:49 AM, Han Luke  wrote:
> >
> > Cool Dave, it’s great to have you to be the campaign.
> >
> >
> > 
> > From: Tan,Zhongyi mailto:tanzhon...@baidu.com>>
> > Sent: Saturday, June 9, 2018 8:16:28 AM
> > To: general@incubator.apache.org <mailto:general@incubator.apache.org>
> > Subject: Re: Looking for Champion
> >
> > thanks，willem
> >
> > we are very appreciate.
> >
> > 在 2018年6月8日，23:03，Willem Jiang  写道：
> >
> > Hi,
> >
> > I'm willing to be the Mentor.
> > Please count me in.
> >
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher 
> > wrote:
> >
> > Hi -
> >
> > I’m willing to Champion and Mentor. I have a couple of comments
> > inline.
> > I’ll look at dependency licenses later today. It’s early for me.
> >
> >
> > On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
> >
> > Hi all,
> >
> > I am Reed, as a developer worked with the team for Palo (a MPP-based
> >
> > interactive SQL data warehousing).
> >
> > https://github.com/baidu/palo/wiki/Palo-Overview
> >
> > We propose to contribute Palo as an Apache Incubator project, and
> > we are still looking for possible Champion if anyone would like to
> >
> > volunteer. Thanks a lot.
> >
> >
> > Best Regards,
> > Reed
> >
> > ===
> > The draft of the proposal as below:
> >
> > #Apache Palo
> >
> > ##Abstract
> >
> > Palo is a MPP-based interactive SQL data warehousing for reporting
> > and
> >
> > analysis.
> >
> >
> > ##Proposal
> >
> > We propose to contribute the Palo codebase and associated artifacts
> >
> > (e.g. documentation, web-site content etc.) to the Apache Software
> > Foundation with the intent of forming a productive, meritocratic and
> > open
> > community around Palo’s continued development, according to the
> > ‘Apache
> > Way’.
> >
> >
> > Baidu owns several trademarks regarding Palo, and proposes to
> 

Re: Looking for Champion

[Jim Apple]

 a better one.
>
> Best Regards,
> Reed
>
>
>
> 在 2018/6/13 上午8:54， "Li,De(BDG)"  写入:
>
> Hi Julian,
>
> Thank you.
>
> It looks like that we have to find another one.
> If anyone has a good name, please feel free to let me know.
>
> Best Regards,
> Reed
>
> 在 2018/6/13 上午4:20， "Julian Hyde"  写入:
>
> Note that there is an existing database product called Palo - an open
> source OLAP engine by German company Jedox[1]. There there is a high
> likelihood that Palo would have to change its name during incubation, if
> accepted.
>
> Julian
>
> [1] https://en.wikipedia.org/wiki/Palo_(OLAP_database)
> <https://en.wikipedia.org/wiki/Palo_(OLAP_database)>
>
>
>
> On Jun 10, 2018, at 3:49 AM, Han Luke  wrote:
>
> Cool Dave, it’s great to have you to be the campaign.
>
>
> 
> From: Tan,Zhongyi mailto:tanzhon...@baidu.com>>
> Sent: Saturday, June 9, 2018 8:16:28 AM
> To: general@incubator.apache.org <mailto:general@incubator.apache.org>
> Subject: Re: Looking for Champion
>
> thanks，willem
>
> we are very appreciate.
>
> 在 2018年6月8日，23:03，Willem Jiang  写道：
>
> Hi,
>
> I'm willing to be the Mentor.
> Please count me in.
>
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher 
> wrote:
>
> Hi -
>
> I’m willing to Champion and Mentor. I have a couple of comments
> inline.
> I’ll look at dependency licenses later today. It’s early for me.
>
>
> On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
>
> Hi all,
>
> I am Reed, as a developer worked with the team for Palo (a MPP-based
>
> interactive SQL data warehousing).
>
> https://github.com/baidu/palo/wiki/Palo-Overview
>
> We propose to contribute Palo as an Apache Incubator project, and
> we are still looking for possible Champion if anyone would like to
>
> volunteer. Thanks a lot.
>
>
> Best Regards,
> Reed
>
> ===
> The draft of the proposal as below:
>
> #Apache Palo
>
> ##Abstract
>
> Palo is a MPP-based interactive SQL data warehousing for reporting
> and
>
> analysis.
>
>
> ##Proposal
>
> We propose to contribute the Palo codebase and associated artifacts
>
> (e.g. documentation, web-site content etc.) to the Apache Software
> Foundation with the intent of forming a productive, meritocratic and
> open
> community around Palo’s continued development, according to the
> ‘Apache
> Way’.
>
>
> Baidu owns several trademarks regarding Palo, and proposes to
> transfer
>
> ownership of those trademarks in full to the ASF.
>
>
> ###Overview of Palo
>
> Palo’s implementation consists of two daemons: Frontend (FE) and
> Backend
>
> (BE).
>
>
> **Frontend daemon** consists of query coordinator and catalog
> manager.
>
> Query coordinator is responsible for receiving users’ sql queries,
> compiling queries and managing queries execution. Catalog manager is
> responsible for managing metadata such as databases, tables,
> partitions,
> replicas and etc. Several frontend daemons could be deployed to
> guarantee
> fault-tolerance, and load balancing.
>
>
> **Backend daemon** stores the data and executes the query fragments.
>
> Many backend daemons could also be deployed to provide scalability
> and
> fault-tolerance.
>
>
> A typical Palo cluster generally composes of several frontend
> daemons
>
> and dozens to hundreds of backend daemons.
>
>
> Users can use MySQL client tools to connect any frontend daemon to
>
> submit SQL query. Frontend receives the query and compiles it into
> query
> plans executable by the Backend. Then Frontend sends the query plan
> fragments to Backend. Backend will build a query execution DAG. Data
> is
> fetched and pipelined into the DAG. The final result response is sent
> to
> client via Frontend. The distribution of query fragment execution
> takes
> minimizing data movement and maximizing scan locality as the main
> goal.
>
>
> ##Background
>
> At Baidu, Prior to Palo, different tools were deployed to solve
> diverse
>
> requirements in many ways. And when a use case requires the
> simultaneous
> availability of capabilities that cannot all be provided by a single
> tool,
> users were forced to build hybrid architectures that stitch multiple
> tools
> together, but we believe that they shouldn’t need to accept such
> inherent
> complexity. A storage system built to provide great performance
> across a
> broad range of workloads provides a more elegant solut

Re: Looking for Champion

[Dave Fisher]

; It looks like that we have to find another one.
>>> If anyone has a good name, please feel free to let me know.
>>> 
>>> Best Regards,
>>> Reed
>>> 
>>> 在 2018/6/13 上午4:20， "Julian Hyde"  写入:
>>> 
>>>> Note that there is an existing database product called Palo - an open
>>>> source OLAP engine by German company Jedox[1]. There there is a high
>>>> likelihood that Palo would have to change its name during incubation, if
>>>> accepted.
>>>> 
>>>> Julian
>>>> 
>>>> [1] https://en.wikipedia.org/wiki/Palo_(OLAP_database)
>>>> <https://en.wikipedia.org/wiki/Palo_(OLAP_database)>
>>>> 
>>>> 
>>>> 
>>>>> On Jun 10, 2018, at 3:49 AM, Han Luke  wrote:
>>>>> 
>>>>> Cool Dave, it’s great to have you to be the campaign.
>>>>> 
>>>>> 
>>>>> 
>>>>> From: Tan,Zhongyi mailto:tanzhon...@baidu.com>>
>>>>> Sent: Saturday, June 9, 2018 8:16:28 AM
>>>>> To: general@incubator.apache.org <mailto:general@incubator.apache.org>
>>>>> Subject: Re: Looking for Champion
>>>>> 
>>>>> thanks，willem
>>>>> 
>>>>> we are very appreciate.
>>>>> 
>>>>>> 在 2018年6月8日，23:03，Willem Jiang  写道：
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I'm willing to be the Mentor.
>>>>>> Please count me in.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Willem Jiang
>>>>>> 
>>>>>> Twitter: willemjiang
>>>>>> Weibo: 姜宁willem
>>>>>> 
>>>>>>> On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi -
>>>>>>> 
>>>>>>> I’m willing to Champion and Mentor. I have a couple of comments
>>>>>>> inline.
>>>>>>> I’ll look at dependency licenses later today. It’s early for me.
>>>>>>> 
>>>>>>> 
>>>>>>>> On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
>>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> I am Reed, as a developer worked with the team for Palo (a MPP-based
>>>>>>> interactive SQL data warehousing).
>>>>>>>> https://github.com/baidu/palo/wiki/Palo-Overview
>>>>>>>> 
>>>>>>>> We propose to contribute Palo as an Apache Incubator project, and
>>>>>>>> we are still looking for possible Champion if anyone would like to
>>>>>>> volunteer. Thanks a lot.
>>>>>>>> 
>>>>>>>> Best Regards,
>>>>>>>> Reed
>>>>>>>> 
>>>>>>>> ===
>>>>>>>> The draft of the proposal as below:
>>>>>>>> 
>>>>>>>> #Apache Palo
>>>>>>>> 
>>>>>>>> ##Abstract
>>>>>>>> 
>>>>>>>> Palo is a MPP-based interactive SQL data warehousing for reporting
>>>>>>>> and
>>>>>>> analysis.
>>>>>>>> 
>>>>>>>> ##Proposal
>>>>>>>> 
>>>>>>>> We propose to contribute the Palo codebase and associated artifacts
>>>>>>> (e.g. documentation, web-site content etc.) to the Apache Software
>>>>>>> Foundation with the intent of forming a productive, meritocratic and
>>>>>>> open
>>>>>>> community around Palo’s continued development, according to the
>>>>>>> ‘Apache
>>>>>>> Way’.
>>>>>>>> 
>>>>>>>> Baidu owns several trademarks regarding Palo, and proposes to
>>>>>>>> transfer
>>>>>>> ownership of those trademarks in full to the ASF.
>>>>>>>> 
>>>>>>>> ###Overview of Palo
>>>>>>>> 
>>>>>>>> Palo’s implementation consists of two daemons: Frontend (FE) and
>>>>>>>> Backend
>>>>&g

Re: Looking for Champion

[Jim Apple]

I don't want to be a stickler, but I don't think "For issues mentioned by
Jim, Todd and Tim, I have replied on last Saturday."

To my email about Palo being an ASF project as a storage system without a
query engine, you replied only, "We will seriously consider this proposal."

I see no response to Tim's concern that "The code isn't owned by any
individual, I contributed it to Apache and it's
free for anyone to do what they want to do with it, but pulling in
improvements from other projects without any attempt to attribute it or
contribute improvements back seems contrary to the Apache way."

On Thu, Jun 14, 2018 at 12:48 AM, Li,De(BDG)  wrote:

> Hi all,
>
> About Palo, we have fixed following issues.
>
> 1. Related Impala
> For issues mentioned by Jim, Todd and Tim, I have replied on last Saturday.
>
> 2、Lisence issue
> For issues mentioned by Todd and Ted.
> 1) be/aes/* come from mysql-5.6, GPL v2.1 license
> Fixed: removed aes related codes.
> https://github.com/baidu/palo/commit/ac770c33d445a4c18a0b74f56b28a4
> 180b30bf
> b7
> https://github.com/baidu/palo/commit/3c9f2ae6695ffebe41e39b6bf65440
> 77698f1c
> ed
>
> 2) be/util/mysql_dtoa.cpp copy from MySQL, GPL license
> Fixed: removed mysql_dtoa related codes.
> https://github.com/baidu/palo/commit/bfe1bc7cf39e165a7c52b2c9415509
> 75b1f841
> a1
>
> 3) be/http/mongoose.h, Copyright (c) 2004-2012 Sergey Lyubka
> Fixed: restored to original lisence, we are searching another http server
> to replace it.
> https://github.com/baidu/palo/commit/81baef34f48a2dbe7401712c5e0a50
> f59f04a8
> 31
>
> 4) be/rpc/*
> Fixed: We have replaced it with brpc, and we will remove Hypertable after
> few weeks for waiting users' upgrade to brpc.
> https://github.com/baidu/palo/tree/master/be/src/rpc
>
> 3、Dependency licenses
> For issue mentioned by Dave, It looks like that Palo have not depend on
> OpenLdap and cyrus-sasl directly,
> but some thirdpary libraries need them to compile, libcurl and gperftools
> for instance.
> For rapidjson, we are looking for alternative one.
>
> 4、About the name of Palo
> For issue mentioned by Julian.
> We are figuring out a better one.
>
> Best Regards,
> Reed
>
>
>
> 在 2018/6/13 上午8:54， "Li,De(BDG)"  写入:
>
> >Hi Julian,
> >
> >Thank you.
> >
> >It looks like that we have to find another one.
> >If anyone has a good name, please feel free to let me know.
> >
> >Best Regards,
> >Reed
> >
> >在 2018/6/13 上午4:20， "Julian Hyde"  写入:
> >
> >>Note that there is an existing database product called Palo - an open
> >>source OLAP engine by German company Jedox[1]. There there is a high
> >>likelihood that Palo would have to change its name during incubation, if
> >>accepted.
> >>
> >>Julian
> >>
> >>[1] https://en.wikipedia.org/wiki/Palo_(OLAP_database)
> >><https://en.wikipedia.org/wiki/Palo_(OLAP_database)>
> >>
> >>
> >>
> >>> On Jun 10, 2018, at 3:49 AM, Han Luke  wrote:
> >>>
> >>> Cool Dave, it’s great to have you to be the campaign.
> >>>
> >>>
> >>> 
> >>> From: Tan,Zhongyi mailto:tanzhon...@baidu.com>>
> >>> Sent: Saturday, June 9, 2018 8:16:28 AM
> >>> To: general@incubator.apache.org <mailto:general@incubator.apache.org>
> >>> Subject: Re: Looking for Champion
> >>>
> >>> thanks，willem
> >>>
> >>> we are very appreciate.
> >>>
> >>>> 在 2018年6月8日，23:03，Willem Jiang  写道：
> >>>>
> >>>> Hi,
> >>>>
> >>>> I'm willing to be the Mentor.
> >>>> Please count me in.
> >>>>
> >>>>
> >>>>
> >>>> Willem Jiang
> >>>>
> >>>> Twitter: willemjiang
> >>>> Weibo: 姜宁willem
> >>>>
> >>>>> On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher 
> >>>>>wrote:
> >>>>>
> >>>>> Hi -
> >>>>>
> >>>>> I’m willing to Champion and Mentor. I have a couple of comments
> >>>>>inline.
> >>>>> I’ll look at dependency licenses later today. It’s early for me.
> >>>>>
> >>>>>
> >>>>>> On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I am Reed, as a dev

Re: Looking for Champion

[Li,De(BDG)]

Hi all,

About Palo, we have fixed following issues.

1. Related Impala
For issues mentioned by Jim, Todd and Tim, I have replied on last Saturday.

2、Lisence issue
For issues mentioned by Todd and Ted.
1) be/aes/* come from mysql-5.6, GPL v2.1 license
Fixed: removed aes related codes.
https://github.com/baidu/palo/commit/ac770c33d445a4c18a0b74f56b28a4180b30bf
b7
https://github.com/baidu/palo/commit/3c9f2ae6695ffebe41e39b6bf6544077698f1c
ed

2) be/util/mysql_dtoa.cpp copy from MySQL, GPL license
Fixed: removed mysql_dtoa related codes.
https://github.com/baidu/palo/commit/bfe1bc7cf39e165a7c52b2c941550975b1f841
a1

3) be/http/mongoose.h, Copyright (c) 2004-2012 Sergey Lyubka
Fixed: restored to original lisence, we are searching another http server
to replace it.
https://github.com/baidu/palo/commit/81baef34f48a2dbe7401712c5e0a50f59f04a8
31

4) be/rpc/*
Fixed: We have replaced it with brpc, and we will remove Hypertable after
few weeks for waiting users' upgrade to brpc.
https://github.com/baidu/palo/tree/master/be/src/rpc

3、Dependency licenses
For issue mentioned by Dave, It looks like that Palo have not depend on
OpenLdap and cyrus-sasl directly,
but some thirdpary libraries need them to compile, libcurl and gperftools
for instance.
For rapidjson, we are looking for alternative one.

4、About the name of Palo
For issue mentioned by Julian.
We are figuring out a better one.

Best Regards,
Reed



在 2018/6/13 上午8:54， "Li,De(BDG)"  写入:

>Hi Julian,
>
>Thank you.
>
>It looks like that we have to find another one.
>If anyone has a good name, please feel free to let me know.
>
>Best Regards,
>Reed
>
>在 2018/6/13 上午4:20， "Julian Hyde"  写入:
>
>>Note that there is an existing database product called Palo - an open
>>source OLAP engine by German company Jedox[1]. There there is a high
>>likelihood that Palo would have to change its name during incubation, if
>>accepted.
>>
>>Julian
>>
>>[1] https://en.wikipedia.org/wiki/Palo_(OLAP_database)
>><https://en.wikipedia.org/wiki/Palo_(OLAP_database)>
>>
>>
>>
>>> On Jun 10, 2018, at 3:49 AM, Han Luke  wrote:
>>> 
>>> Cool Dave, it’s great to have you to be the campaign.
>>> 
>>> 
>>> 
>>> From: Tan,Zhongyi mailto:tanzhon...@baidu.com>>
>>> Sent: Saturday, June 9, 2018 8:16:28 AM
>>> To: general@incubator.apache.org <mailto:general@incubator.apache.org>
>>> Subject: Re: Looking for Champion
>>> 
>>> thanks，willem
>>> 
>>> we are very appreciate.
>>> 
>>>> 在 2018年6月8日，23:03，Willem Jiang  写道：
>>>> 
>>>> Hi,
>>>> 
>>>> I'm willing to be the Mentor.
>>>> Please count me in.
>>>> 
>>>> 
>>>> 
>>>> Willem Jiang
>>>> 
>>>> Twitter: willemjiang
>>>> Weibo: 姜宁willem
>>>> 
>>>>> On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher 
>>>>>wrote:
>>>>> 
>>>>> Hi -
>>>>> 
>>>>> I’m willing to Champion and Mentor. I have a couple of comments
>>>>>inline.
>>>>> I’ll look at dependency licenses later today. It’s early for me.
>>>>> 
>>>>> 
>>>>>> On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> I am Reed, as a developer worked with the team for Palo (a MPP-based
>>>>> interactive SQL data warehousing).
>>>>>> https://github.com/baidu/palo/wiki/Palo-Overview
>>>>>> 
>>>>>> We propose to contribute Palo as an Apache Incubator project, and
>>>>>> we are still looking for possible Champion if anyone would like to
>>>>> volunteer. Thanks a lot.
>>>>>> 
>>>>>> Best Regards,
>>>>>> Reed
>>>>>> 
>>>>>> ===
>>>>>> The draft of the proposal as below:
>>>>>> 
>>>>>> #Apache Palo
>>>>>> 
>>>>>> ##Abstract
>>>>>> 
>>>>>> Palo is a MPP-based interactive SQL data warehousing for reporting
>>>>>>and
>>>>> analysis.
>>>>>> 
>>>>>> ##Proposal
>>>>>> 
>>>>>> We propose to contribute the Palo codebase and associated artifacts
>>>>> (e.g. documentation, web-site content etc.) to the Apache Software
>>>>> Foundatio

Re: Looking for Champion

[Li,De(BDG)]

Hi Julian,

Thank you.

It looks like that we have to find another one.
If anyone has a good name, please feel free to let me know.

Best Regards,
Reed

在 2018/6/13 上午4:20， "Julian Hyde"  写入:

>Note that there is an existing database product called Palo - an open
>source OLAP engine by German company Jedox[1]. There there is a high
>likelihood that Palo would have to change its name during incubation, if
>accepted.
>
>Julian
>
>[1] https://en.wikipedia.org/wiki/Palo_(OLAP_database)
><https://en.wikipedia.org/wiki/Palo_(OLAP_database)>
>
>
>
>> On Jun 10, 2018, at 3:49 AM, Han Luke  wrote:
>> 
>> Cool Dave, it’s great to have you to be the campaign.
>> 
>> 
>> 
>> From: Tan,Zhongyi mailto:tanzhon...@baidu.com>>
>> Sent: Saturday, June 9, 2018 8:16:28 AM
>> To: general@incubator.apache.org <mailto:general@incubator.apache.org>
>> Subject: Re: Looking for Champion
>> 
>> thanks，willem
>> 
>> we are very appreciate.
>> 
>>> 在 2018年6月8日，23:03，Willem Jiang  写道：
>>> 
>>> Hi,
>>> 
>>> I'm willing to be the Mentor.
>>> Please count me in.
>>> 
>>> 
>>> 
>>> Willem Jiang
>>> 
>>> Twitter: willemjiang
>>> Weibo: 姜宁willem
>>> 
>>>> On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher 
>>>>wrote:
>>>> 
>>>> Hi -
>>>> 
>>>> I’m willing to Champion and Mentor. I have a couple of comments
>>>>inline.
>>>> I’ll look at dependency licenses later today. It’s early for me.
>>>> 
>>>> 
>>>>> On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I am Reed, as a developer worked with the team for Palo (a MPP-based
>>>> interactive SQL data warehousing).
>>>>> https://github.com/baidu/palo/wiki/Palo-Overview
>>>>> 
>>>>> We propose to contribute Palo as an Apache Incubator project, and
>>>>> we are still looking for possible Champion if anyone would like to
>>>> volunteer. Thanks a lot.
>>>>> 
>>>>> Best Regards,
>>>>> Reed
>>>>> 
>>>>> ===
>>>>> The draft of the proposal as below:
>>>>> 
>>>>> #Apache Palo
>>>>> 
>>>>> ##Abstract
>>>>> 
>>>>> Palo is a MPP-based interactive SQL data warehousing for reporting
>>>>>and
>>>> analysis.
>>>>> 
>>>>> ##Proposal
>>>>> 
>>>>> We propose to contribute the Palo codebase and associated artifacts
>>>> (e.g. documentation, web-site content etc.) to the Apache Software
>>>> Foundation with the intent of forming a productive, meritocratic and
>>>>open
>>>> community around Palo’s continued development, according to the
>>>>‘Apache
>>>> Way’.
>>>>> 
>>>>> Baidu owns several trademarks regarding Palo, and proposes to
>>>>>transfer
>>>> ownership of those trademarks in full to the ASF.
>>>>> 
>>>>> ###Overview of Palo
>>>>> 
>>>>> Palo’s implementation consists of two daemons: Frontend (FE) and
>>>>>Backend
>>>> (BE).
>>>>> 
>>>>> **Frontend daemon** consists of query coordinator and catalog
>>>>>manager.
>>>> Query coordinator is responsible for receiving users’ sql queries,
>>>> compiling queries and managing queries execution. Catalog manager is
>>>> responsible for managing metadata such as databases, tables,
>>>>partitions,
>>>> replicas and etc. Several frontend daemons could be deployed to
>>>>guarantee
>>>> fault-tolerance, and load balancing.
>>>>> 
>>>>> **Backend daemon** stores the data and executes the query fragments.
>>>> Many backend daemons could also be deployed to provide scalability and
>>>> fault-tolerance.
>>>>> 
>>>>> A typical Palo cluster generally composes of several frontend daemons
>>>> and dozens to hundreds of backend daemons.
>>>>> 
>>>>> Users can use MySQL client tools to connect any frontend daemon to
>>>> submit SQL query. Frontend receives the query and compiles it into
>>>>query
>>

Re: Looking for Champion

[Julian Hyde]

Note that there is an existing database product called Palo - an open source 
OLAP engine by German company Jedox[1]. There there is a high likelihood that 
Palo would have to change its name during incubation, if accepted.

Julian

[1] https://en.wikipedia.org/wiki/Palo_(OLAP_database) 
<https://en.wikipedia.org/wiki/Palo_(OLAP_database)>



> On Jun 10, 2018, at 3:49 AM, Han Luke  wrote:
> 
> Cool Dave, it’s great to have you to be the campaign.
> 
> 
> 
> From: Tan,Zhongyi mailto:tanzhon...@baidu.com>>
> Sent: Saturday, June 9, 2018 8:16:28 AM
> To: general@incubator.apache.org <mailto:general@incubator.apache.org>
> Subject: Re: Looking for Champion
> 
> thanks，willem
> 
> we are very appreciate.
> 
>> 在 2018年6月8日，23:03，Willem Jiang  写道：
>> 
>> Hi,
>> 
>> I'm willing to be the Mentor.
>> Please count me in.
>> 
>> 
>> 
>> Willem Jiang
>> 
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>> 
>>> On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher  wrote:
>>> 
>>> Hi -
>>> 
>>> I’m willing to Champion and Mentor. I have a couple of comments inline.
>>> I’ll look at dependency licenses later today. It’s early for me.
>>> 
>>> 
>>>> On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I am Reed, as a developer worked with the team for Palo (a MPP-based
>>> interactive SQL data warehousing).
>>>> https://github.com/baidu/palo/wiki/Palo-Overview
>>>> 
>>>> We propose to contribute Palo as an Apache Incubator project, and
>>>> we are still looking for possible Champion if anyone would like to
>>> volunteer. Thanks a lot.
>>>> 
>>>> Best Regards,
>>>> Reed
>>>> 
>>>> ===
>>>> The draft of the proposal as below:
>>>> 
>>>> #Apache Palo
>>>> 
>>>> ##Abstract
>>>> 
>>>> Palo is a MPP-based interactive SQL data warehousing for reporting and
>>> analysis.
>>>> 
>>>> ##Proposal
>>>> 
>>>> We propose to contribute the Palo codebase and associated artifacts
>>> (e.g. documentation, web-site content etc.) to the Apache Software
>>> Foundation with the intent of forming a productive, meritocratic and open
>>> community around Palo’s continued development, according to the ‘Apache
>>> Way’.
>>>> 
>>>> Baidu owns several trademarks regarding Palo, and proposes to transfer
>>> ownership of those trademarks in full to the ASF.
>>>> 
>>>> ###Overview of Palo
>>>> 
>>>> Palo’s implementation consists of two daemons: Frontend (FE) and Backend
>>> (BE).
>>>> 
>>>> **Frontend daemon** consists of query coordinator and catalog manager.
>>> Query coordinator is responsible for receiving users’ sql queries,
>>> compiling queries and managing queries execution. Catalog manager is
>>> responsible for managing metadata such as databases, tables, partitions,
>>> replicas and etc. Several frontend daemons could be deployed to guarantee
>>> fault-tolerance, and load balancing.
>>>> 
>>>> **Backend daemon** stores the data and executes the query fragments.
>>> Many backend daemons could also be deployed to provide scalability and
>>> fault-tolerance.
>>>> 
>>>> A typical Palo cluster generally composes of several frontend daemons
>>> and dozens to hundreds of backend daemons.
>>>> 
>>>> Users can use MySQL client tools to connect any frontend daemon to
>>> submit SQL query. Frontend receives the query and compiles it into query
>>> plans executable by the Backend. Then Frontend sends the query plan
>>> fragments to Backend. Backend will build a query execution DAG. Data is
>>> fetched and pipelined into the DAG. The final result response is sent to
>>> client via Frontend. The distribution of query fragment execution takes
>>> minimizing data movement and maximizing scan locality as the main goal.
>>>> 
>>>> ##Background
>>>> 
>>>> At Baidu, Prior to Palo, different tools were deployed to solve diverse
>>> requirements in many ways. And when a use case requires the simultaneous
>>> availability of capabilities that cannot all be provided by a single tool,
>>> users were forced to build hybrid architectures that stitch multipl

Re: Looking for Champion

[Han Luke]

Cool Dave, it’s great to have you to be the campaign.



From: Tan,Zhongyi 
Sent: Saturday, June 9, 2018 8:16:28 AM
To: general@incubator.apache.org
Subject: Re: Looking for Champion

thanks，willem

we are very appreciate.

> 在 2018年6月8日，23:03，Willem Jiang  写道：
>
> Hi,
>
> I'm willing to be the Mentor.
> Please count me in.
>
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>> On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher  wrote:
>>
>> Hi -
>>
>> I’m willing to Champion and Mentor. I have a couple of comments inline.
>> I’ll look at dependency licenses later today. It’s early for me.
>>
>>
>>> On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
>>>
>>> Hi all,
>>>
>>> I am Reed, as a developer worked with the team for Palo (a MPP-based
>> interactive SQL data warehousing).
>>> https://github.com/baidu/palo/wiki/Palo-Overview
>>>
>>> We propose to contribute Palo as an Apache Incubator project, and
>>> we are still looking for possible Champion if anyone would like to
>> volunteer. Thanks a lot.
>>>
>>> Best Regards,
>>> Reed
>>>
>>> ===
>>> The draft of the proposal as below:
>>>
>>> #Apache Palo
>>>
>>> ##Abstract
>>>
>>> Palo is a MPP-based interactive SQL data warehousing for reporting and
>> analysis.
>>>
>>> ##Proposal
>>>
>>> We propose to contribute the Palo codebase and associated artifacts
>> (e.g. documentation, web-site content etc.) to the Apache Software
>> Foundation with the intent of forming a productive, meritocratic and open
>> community around Palo’s continued development, according to the ‘Apache
>> Way’.
>>>
>>> Baidu owns several trademarks regarding Palo, and proposes to transfer
>> ownership of those trademarks in full to the ASF.
>>>
>>> ###Overview of Palo
>>>
>>> Palo’s implementation consists of two daemons: Frontend (FE) and Backend
>> (BE).
>>>
>>> **Frontend daemon** consists of query coordinator and catalog manager.
>> Query coordinator is responsible for receiving users’ sql queries,
>> compiling queries and managing queries execution. Catalog manager is
>> responsible for managing metadata such as databases, tables, partitions,
>> replicas and etc. Several frontend daemons could be deployed to guarantee
>> fault-tolerance, and load balancing.
>>>
>>> **Backend daemon** stores the data and executes the query fragments.
>> Many backend daemons could also be deployed to provide scalability and
>> fault-tolerance.
>>>
>>> A typical Palo cluster generally composes of several frontend daemons
>> and dozens to hundreds of backend daemons.
>>>
>>> Users can use MySQL client tools to connect any frontend daemon to
>> submit SQL query. Frontend receives the query and compiles it into query
>> plans executable by the Backend. Then Frontend sends the query plan
>> fragments to Backend. Backend will build a query execution DAG. Data is
>> fetched and pipelined into the DAG. The final result response is sent to
>> client via Frontend. The distribution of query fragment execution takes
>> minimizing data movement and maximizing scan locality as the main goal.
>>>
>>> ##Background
>>>
>>> At Baidu, Prior to Palo, different tools were deployed to solve diverse
>> requirements in many ways. And when a use case requires the simultaneous
>> availability of capabilities that cannot all be provided by a single tool,
>> users were forced to build hybrid architectures that stitch multiple tools
>> together, but we believe that they shouldn’t need to accept such inherent
>> complexity. A storage system built to provide great performance across a
>> broad range of workloads provides a more elegant solution to the problems
>> that hybrid architectures aim to solve. Palo is the solution.
>>>
>>> Palo is designed to be a simple and single tightly coupled system, not
>> depending on other systems. Palo provides high concurrent low latency point
>> query performance, but also provides high throughput queries of ad-hoc
>> analysis. Palo provides bulk-batch data loading, but also provides near
>> real-time mini-batch data loading. Palo also provides high availability,
>> reliability, fault tolerance, and scalability.
>>>
>>> ##Rationale
>>>
>>> Palo mainly integrates the technology of Google Mesa and Apache Impala.
>

Re: Looking for Champion

[Li,De(BDG)]

>> > >Hello! As a contributor to Impala, I’d be interested in hearing
>>thoughts
>> > >from the Palo community about integration between Impala and Palo.
>> > >
>> > >For instance, are there any apparent design goals of Impala that the
>> Palo
>> > >community thinks are fundamentally incompatible with Palo?
>> > >
>> > >Thanks,
>> > >Jim
>> > >
>> > >On 2018/06/08 04:45:32, "Li,De(BDG)"  wrote:
>> > >> Hi all,
>> > >>
>> > >> I am Reed, as a developer worked with the team for Palo (a
>>MPP-based
>> > >>interactive SQL data warehousing).
>> > >> https://github.com/baidu/palo/wiki/Palo-Overview
>> > >>
>> > >> We propose to contribute Palo as an Apache Incubator project, and
>> > >> we are still looking for possible Champion if anyone would like to
>> > >>volunteer. Thanks a lot.
>> > >>
>> > >> Best Regards,
>> > >> Reed
>> > >>
>> > >> ===
>> > >> The draft of the proposal as below:
>> > >>
>> > >> #Apache Palo
>> > >>
>> > >> ##Abstract
>> > >>
>> > >> Palo is a MPP-based interactive SQL data warehousing for reporting
>>and
>> > >>analysis.
>> > >>
>> > >> ##Proposal
>> > >>
>> > >> We propose to contribute the Palo codebase and associated artifacts
>> > >>(e.g. documentation, web-site content etc.) to the Apache Software
>> > >>Foundation with the intent of forming a productive, meritocratic and
>> > >>open community around Palo’s continued development, according to the
>> > >>‘Apache Way’.
>> > >>
>> > >> Baidu owns several trademarks regarding Palo, and proposes to
>>transfer
>> > >>ownership of those trademarks in full to the ASF.
>> > >>
>> > >> ###Overview of Palo
>> > >>
>> > >> Palo’s implementation consists of two daemons: Frontend (FE) and
>> > >>Backend (BE).
>> > >>
>> > >> **Frontend daemon** consists of query coordinator and catalog
>>manager.
>> > >>Query coordinator is responsible for receiving users’ sql queries,
>> > >>compiling queries and managing queries execution. Catalog manager is
>> > >>responsible for managing metadata such as databases, tables,
>> partitions,
>> > >>replicas and etc. Several frontend daemons could be deployed to
>> > >>guarantee fault-tolerance, and load balancing.
>> > >>
>> > >> **Backend daemon** stores the data and executes the query
>>fragments.
>> > >>Many backend daemons could also be deployed to provide scalability
>>and
>> > >>fault-tolerance.
>> > >>
>> > >> A typical Palo cluster generally composes of several frontend
>>daemons
>> > >>and dozens to hundreds of backend daemons.
>> > >>
>> > >> Users can use MySQL client tools to connect any frontend daemon to
>> > >>submit SQL query. Frontend receives the query and compiles it into
>> query
>> > >>plans executable by the Backend. Then Frontend sends the query plan
>> > >>fragments to Backend. Backend will build a query execution DAG.
>>Data is
>> > >>fetched and pipelined into the DAG. The final result response is
>>sent
>> to
>> > >>client via Frontend. The distribution of query fragment execution
>>takes
>> > >>minimizing data movement and maximizing scan locality as the main
>>goal.
>> > >>
>> > >> ##Background
>> > >>
>> > >> At Baidu, Prior to Palo, different tools were deployed to solve
>> diverse
>> > >>requirements in many ways. And when a use case requires the
>> simultaneous
>> > >>availability of capabilities that cannot all be provided by a single
>> > >>tool, users were forced to build hybrid architectures that stitch
>> > >>multiple tools together, but we believe that they shouldn’t need to
>> > >>accept such inherent complexity. A storage system built to provide
>> great
>> > >>performance across a broad range of workloads provides a more
>>elegant
>> > >>solution to the p

Re: Looking for Champion

[Li,De(BDG)]

Hi Dave,

Thank you for your response.

As you mentioned that mongoose.h, it is serious mistake to replace license when 
updating Apache
license with a automatic script.

I have fixed it as following:
https://github.com/baidu/palo/commit/611afcd125dc136c58d7feb5552c26e9b215878a

By the way, I wonder Palo just use OpenLdap with binary way, is it still have 
license issue?

Best Regards,
Reed

发件人: Dave Fisher mailto:dave2w...@comcast.net>>
答复: mailto:general@incubator.apache.org>>
日期: 2018年6月9日 星期六 上午2:10
至: mailto:general@incubator.apache.org>>
主题: Re: Looking for Champion

Yuck. That’s a mess. That is one very large diff.

I see a few files related to AES the were GPL converted to Apache which not 
allowed.
Copyrights were changed too which is also incorrect.

Changes to this file 
be/src/http/mongoose.h<https://github.com/baidu/palo/commit/6486be64c319fe0beb8c6b4430c1662de54f182e#diff-586168bd25cfbf3bc8bc1b52abc4206c>
 violate license and copyright of Sergey Lyubka

GitHub makes you expand each diff after awhile.

There are dependency licenses that might be issues too.

These licenses have not been evaluated by LEGAL.
* OpenLdap (OpenLDAP Software License)
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=LICENSE;hb=e5f8117f0ce088d0bd7a8e18ddf37eaa40eb09b1
* rapidjson (Tencent)
Unknown
* cyrus-sasl (CMU License)
https://spdx.org/licenses/MIT-CMU.html
AKA MIT-CMU

Lots of work in evaluating licenses.

On Jun 8, 2018, at 9:46 AM, Ted Dunning 
mailto:ted.dunn...@gmail.com>> wrote:

Ouch.

The copyright in question was attached to code from the source code for
mySQL. There is no way that code can be in an Apache project.

Given the cut and paste history, it seems like it will require a very
detailed audit of code history or web searches to find where the original
code came from. The my_aes.c and .h files, for instance, have no hint in
their history that they came from GPL'ed code.

Yeah. Lot’s of oversight.

If we accept this proposal we need a Mentor who has time to help with this mess.

I don’t know that I have the time to lead that effort. Anyone?

Regards,
Dave


On Fri, Jun 8, 2018 at 5:37 PM Todd Lipcon 
mailto:t...@cloudera.com>> wrote:

...

+1. Also briefly browsing the code I found suspicious commits like this
one:

https://github.com/baidu/palo/commit/6486be64c319fe0beb8c6b4430c1662de54f182e

... in which a GPL license copyright by Oracle was "fixed" to be an Apache
license copyright Baidu.

So if this project does enter incubation I think we should be extra careful
to audit the origins of all of the source code.

Re: Looking for Champion

[Li,De(BDG)]

   Copyrights were changed too which is also incorrect.

Yes, we know that, I have fixed this mistake as following.
https://github.com/baidu/palo/commit/ac770c33d445a4c18a0b74f56b28a4180b30bf
b7

As you mentioned, we will recheck and make sure if Open LDAP is necessary
for Palo. 

Best Regards,
Reed


在 2018/6/9 上午4:13， "Ted Dunning"  写入:

>Open LDAP is a form of copy-left. It requires source code distribution of
>binary packaged versions.
>
>
>
>On Fri, Jun 8, 2018 at 7:10 PM Dave Fisher  wrote:
>
>> Yuck. That’s a mess. That is one very large diff.
>>
>> I see a few files related to AES the were GPL converted to Apache which
>> not allowed.
>> Copyrights were changed too which is also incorrect.
>>
>> Changes to this file be/src/http/mongoose.h
>> 
>>>f182e#diff-586168bd25cfbf3bc8bc1b52abc4206c> violate
>> license and copyright of Sergey Lyubka
>>
>> GitHub makes you expand each diff after awhile.
>>
>> There are dependency licenses that might be issues too.
>>
>> These licenses have not been evaluated by LEGAL.
>> * OpenLdap (OpenLDAP Software License)
>>
>> 
>>http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=LICENSE;
>>hb=e5f8117f0ce088d0bd7a8e18ddf37eaa40eb09b1
>> * rapidjson (Tencent)
>> Unknown
>> * cyrus-sasl (CMU License)
>> https://spdx.org/licenses/MIT-CMU.html
>> AKA MIT-CMU
>>
>> Lots of work in evaluating licenses.
>>
>> On Jun 8, 2018, at 9:46 AM, Ted Dunning  wrote:
>>
>> Ouch.
>>
>> The copyright in question was attached to code from the source code for
>> mySQL. There is no way that code can be in an Apache project.
>>
>> Given the cut and paste history, it seems like it will require a very
>> detailed audit of code history or web searches to find where the
>>original
>> code came from. The my_aes.c and .h files, for instance, have no hint in
>> their history that they came from GPL'ed code.
>>
>>
>> Yeah. Lot’s of oversight.
>>
>> If we accept this proposal we need a Mentor who has time to help with
>>this
>> mess.
>>
>> I don’t know that I have the time to lead that effort. Anyone?
>>
>> Regards,
>> Dave
>>
>>
>> On Fri, Jun 8, 2018 at 5:37 PM Todd Lipcon  wrote:
>>
>> ...
>>
>> +1. Also briefly browsing the code I found suspicious commits like this
>> one:
>>
>>
>> 
>>https://github.com/baidu/palo/commit/6486be64c319fe0beb8c6b4430c1662de54f
>>182e
>>
>> ... in which a GPL license copyright by Oracle was "fixed" to be an
>>Apache
>> license copyright Baidu.
>>
>> So if this project does enter incubation I think we should be extra
>>careful
>> to audit the origins of all of the source code.
>>
>>
>>
>>

Re: Looking for Champion

[Li,De(BDG)]

Hi Todd,

Thank you for your response.

It is serious mistake to replace Oracle license to Apache when updating
license with a script.

We have not check carefully, actually, those file no longer been used.
So I removed them and made a new commit.

https://github.com/baidu/palo/commit/ac770c33d445a4c18a0b74f56b28a4180b30bf
b7

Best Regards,
Reed


在 2018/6/9 上午12:37， "Todd Lipcon"  写入:

>On Fri, Jun 8, 2018 at 9:18 AM, Tim Armstrong 
>wrote:
>
>> > Meanwhile we found Impala is a very good MPP SQL query engine, so we
>> integrated
>> them together.
>>
>> Palo didn't integrate with Impala, it forked Impala's codebase and
>>embedded
>> it in its own repository. I don't remember any attempts from the Palo
>>team
>> to engage with the Impala community or attempt to work with us to
>> contribute any improvements.
>>
>> It looks like Palo is still pulling in new code from Impala.  E.g. this
>> commit includes a bunch of code I wrote as part of IMPALA-3200:
>> https://github.com/baidu/palo/commit/2419384e8a211f10e7636afc6d3423
>> 700ba22b5a#diff-1c501d9a8b5c3d1d1cce48d5e1fb0edf
>>
>> The code isn't owned by any individual, I contributed it to Apache and
>>it's
>> free for anyone to do what they want to do with it, but pulling in
>> improvements from other projects without any attempt to attribute it or
>> contribute improvements back seems contrary to the Apache way.
>>
>
>+1. Also briefly browsing the code I found suspicious commits like this
>one:
>https://github.com/baidu/palo/commit/6486be64c319fe0beb8c6b4430c1662de54f1
>82e
>
>... in which a GPL license copyright by Oracle was "fixed" to be an Apache
>license copyright Baidu.
>
>So if this project does enter incubation I think we should be extra
>careful
>to audit the origins of all of the source code.
>
>-Todd
>
>
>> On Fri, Jun 8, 2018 at 9:12 AM, Todd Lipcon  wrote:
>>
>> > On Thu, Jun 7, 2018 at 11:55 PM, Li,De(BDG)  wrote:
>> >
>> > > Hi, Jim
>> > >
>> > > Thank you for your response.
>> > > Actually, we start Palo in several years ago, and that time we
>> developed
>> > > the storage engine based on Mesa technology.
>> > > Meanwhile we found Impala is a very good MPP SQL query engine, so we
>> > > integrated them together.
>> > >
>> >
>> > From what I can tell of the Palo source, it's not so much an
>>integration
>> as
>> > a copied-and-modified codebase, right? i.e Palo does not use Impala
>>as a
>> > dependency, but rather shares a lot of code from the Impala project
>>that
>> > has since diverged.
>> >
>> >
>> > >
>> > > With this integration, the goal of Palo is to implement a single,
>> > > full-featured, mysql protocol compatible data warehousing.
>> > >
>> >
>> > That sounds pretty similar to the goals of the Impala project. Impala
>> isn't
>> > MySQL-compatible at the moment but that seems more like a particular
>> > feature that could be added rather than a distinct identity of the
>> project.
>> > Otherwise, Impala's goal is to be a full featured data warehouse
>>engine
>> as
>> > well.
>> >
>> > Generally Apache has no rules against multiple projects fulfilling
>> similar
>> > goals or use cases, even when those projects might compete. However I
>> think
>> > it would be relatively unusual to incubate a project that appears to
>>be
>> > derived from a fork of an existing project, at least without first
>> > considering whether the additional feature set could be contributed
>>back
>> to
>> > the existing community.
>> >
>> > -Todd
>> >
>> >
>> > > 在 2018/6/8 下午1:55， "Jim Apple"  写入:
>> > >
>> > > >Hello! As a contributor to Impala, I’d be interested in hearing
>> thoughts
>> > > >from the Palo community about integration between Impala and Palo.
>> > > >
>> > > >For instance, are there any apparent design goals of Impala that
>>the
>> > Palo
>> > > >community thinks are fundamentally incompatible with Palo?
>> > > >
>> > > >Thanks,
>> > > >Jim
>> > > >
>> > > >On 2018/06/08 04:45:32, "Li,De(BDG)"  wrote:
>> > > >> Hi all,
>> > > >>
>> > > >> I am Reed, as a developer worked with the team for Palo 

Re: Looking for Champion

[Li,De(BDG)]

Regarding Licence's question, we will complete the repair as soon as possible 
before voting.

发件人: Dave Fisher mailto:dave2w...@comcast.net>>
答复: mailto:general@incubator.apache.org>>
日期: 2018年6月9日 星期六 上午2:10
至: mailto:general@incubator.apache.org>>
主题: Re: Looking for Champion

Yuck. That’s a mess. That is one very large diff.

I see a few files related to AES the were GPL converted to Apache which not 
allowed.
Copyrights were changed too which is also incorrect.

Changes to this file 
be/src/http/mongoose.h<https://github.com/baidu/palo/commit/6486be64c319fe0beb8c6b4430c1662de54f182e#diff-586168bd25cfbf3bc8bc1b52abc4206c>
 violate license and copyright of Sergey Lyubka

GitHub makes you expand each diff after awhile.

There are dependency licenses that might be issues too.

These licenses have not been evaluated by LEGAL.
* OpenLdap (OpenLDAP Software License)
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=LICENSE;hb=e5f8117f0ce088d0bd7a8e18ddf37eaa40eb09b1
* rapidjson (Tencent)
Unknown
* cyrus-sasl (CMU License)
https://spdx.org/licenses/MIT-CMU.html
AKA MIT-CMU

Lots of work in evaluating licenses.

On Jun 8, 2018, at 9:46 AM, Ted Dunning 
mailto:ted.dunn...@gmail.com>> wrote:

Ouch.

The copyright in question was attached to code from the source code for
mySQL. There is no way that code can be in an Apache project.

Given the cut and paste history, it seems like it will require a very
detailed audit of code history or web searches to find where the original
code came from. The my_aes.c and .h files, for instance, have no hint in
their history that they came from GPL'ed code.

Yeah. Lot’s of oversight.

If we accept this proposal we need a Mentor who has time to help with this mess.

I don’t know that I have the time to lead that effort. Anyone?

Regards,
Dave


On Fri, Jun 8, 2018 at 5:37 PM Todd Lipcon 
mailto:t...@cloudera.com>> wrote:

...

+1. Also briefly browsing the code I found suspicious commits like this
one:

https://github.com/baidu/palo/commit/6486be64c319fe0beb8c6b4430c1662de54f182e

... in which a GPL license copyright by Oracle was "fixed" to be an Apache
license copyright Baidu.

So if this project does enter incubation I think we should be extra careful
to audit the origins of all of the source code.

Re: Looking for Champion

[Li,De(BDG)]

Thanks to Jim's suggestion. We will seriously consider this proposal.
Also, for some of the opinions given by everyone,
the Palo development team will seriously discuss and then give
everyone a unified reply next week.



在 2018/6/9 上午7:41， "Jim Apple"  写入:

>>
>> Generally Apache has no rules against multiple projects fulfilling
>>similar
>> goals or use cases, even when those projects might compete. However I
>>think
>> it would be relatively unusual to incubate a project that appears to be
>> derived from a fork of an existing project, at least without first
>> considering whether the additional feature set could be contributed
>>back to
>> the existing community.
>>
>
>And this is something I'm really excited about. If only the storage system
>part of Palo were contributed to the ASF, and simultaneously the Palo
>community and the Impala community worked together to integrate the query
>engine work of Palo into Impala, then this could provide a lot of benefit
>to users, I think. My hope is that it would eliminate the toil the Palo
>community is engaged in by rebasing Impala changes (as Tim noticed).
>Impala, meanwhile, might benefit from some changes Palo has made, like
>SIMD
>filtering.
>
>This could be a lot of work, but the current system seems to already
>include quite a lot of inefficiency from the duplication.

Re: Looking for Champion

[Li,De(BDG)]

Thank you Willem, warmly welcome.

在 2018/6/8 下午11:03， "Willem Jiang"  写入:

>Hi,
>
>I'm willing to be the Mentor.
>Please count me in.
>
>
>
>Willem Jiang
>
>Twitter: willemjiang
>Weibo: 姜宁willem
>
>On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher  wrote:
>
>> Hi -
>>
>> I’m willing to Champion and Mentor. I have a couple of comments inline.
>> I’ll look at dependency licenses later today. It’s early for me.
>>
>>
>> > On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
>> >
>> > Hi all,
>> >
>> > I am Reed, as a developer worked with the team for Palo (a MPP-based
>> interactive SQL data warehousing).
>> > https://github.com/baidu/palo/wiki/Palo-Overview
>> >
>> > We propose to contribute Palo as an Apache Incubator project, and
>> > we are still looking for possible Champion if anyone would like to
>> volunteer. Thanks a lot.
>> >
>> > Best Regards,
>> > Reed
>> >
>> > ===
>> > The draft of the proposal as below:
>> >
>> > #Apache Palo
>> >
>> > ##Abstract
>> >
>> > Palo is a MPP-based interactive SQL data warehousing for reporting and
>> analysis.
>> >
>> > ##Proposal
>> >
>> > We propose to contribute the Palo codebase and associated artifacts
>> (e.g. documentation, web-site content etc.) to the Apache Software
>> Foundation with the intent of forming a productive, meritocratic and
>>open
>> community around Palo’s continued development, according to the ‘Apache
>> Way’.
>> >
>> > Baidu owns several trademarks regarding Palo, and proposes to transfer
>> ownership of those trademarks in full to the ASF.
>> >
>> > ###Overview of Palo
>> >
>> > Palo’s implementation consists of two daemons: Frontend (FE) and
>>Backend
>> (BE).
>> >
>> > **Frontend daemon** consists of query coordinator and catalog manager.
>> Query coordinator is responsible for receiving users’ sql queries,
>> compiling queries and managing queries execution. Catalog manager is
>> responsible for managing metadata such as databases, tables, partitions,
>> replicas and etc. Several frontend daemons could be deployed to
>>guarantee
>> fault-tolerance, and load balancing.
>> >
>> > **Backend daemon** stores the data and executes the query fragments.
>> Many backend daemons could also be deployed to provide scalability and
>> fault-tolerance.
>> >
>> > A typical Palo cluster generally composes of several frontend daemons
>> and dozens to hundreds of backend daemons.
>> >
>> > Users can use MySQL client tools to connect any frontend daemon to
>> submit SQL query. Frontend receives the query and compiles it into query
>> plans executable by the Backend. Then Frontend sends the query plan
>> fragments to Backend. Backend will build a query execution DAG. Data is
>> fetched and pipelined into the DAG. The final result response is sent to
>> client via Frontend. The distribution of query fragment execution takes
>> minimizing data movement and maximizing scan locality as the main goal.
>> >
>> > ##Background
>> >
>> > At Baidu, Prior to Palo, different tools were deployed to solve
>>diverse
>> requirements in many ways. And when a use case requires the simultaneous
>> availability of capabilities that cannot all be provided by a single
>>tool,
>> users were forced to build hybrid architectures that stitch multiple
>>tools
>> together, but we believe that they shouldn’t need to accept such
>>inherent
>> complexity. A storage system built to provide great performance across a
>> broad range of workloads provides a more elegant solution to the
>>problems
>> that hybrid architectures aim to solve. Palo is the solution.
>> >
>> > Palo is designed to be a simple and single tightly coupled system, not
>> depending on other systems. Palo provides high concurrent low latency
>>point
>> query performance, but also provides high throughput queries of ad-hoc
>> analysis. Palo provides bulk-batch data loading, but also provides near
>> real-time mini-batch data loading. Palo also provides high availability,
>> reliability, fault tolerance, and scalability.
>> >
>> > ##Rationale
>> >
>> > Palo mainly integrates the technology of Google Mesa and Apache
>>Impala.
>> >
>> > Mesa is a highly scalable analytic data storage system that stores
>

Re: Looking for Champion

[Li,De(BDG)]

Hi Dave,

Thank you very much your help and warmly welcome you as Palo’s Champion
and Mentor.
About licenses, we known as far as following:

--
1. aes/* mysql-5.6  GPL v2.1
2. util/mysql_dtoa.cpp Percona Server for MySQL GPL
3. http/mongoose.h mongoose MIT License
--


We will resolve the ASAP.



在 2018/6/8 下午8:59， "Dave Fisher"  写入:

>Hi -
>
>I’m willing to Champion and Mentor. I have a couple of comments inline.
>I’ll look at dependency licenses later today. It’s early for me.
>
>
>> On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
>> 
>> Hi all,
>> 
>> I am Reed, as a developer worked with the team for Palo (a MPP-based
>>interactive SQL data warehousing).
>> https://github.com/baidu/palo/wiki/Palo-Overview
>> 
>> We propose to contribute Palo as an Apache Incubator project, and
>> we are still looking for possible Champion if anyone would like to
>>volunteer. Thanks a lot.
>> 
>> Best Regards,
>> Reed
>> 
>> ===
>> The draft of the proposal as below:
>> 
>> #Apache Palo
>> 
>> ##Abstract
>> 
>> Palo is a MPP-based interactive SQL data warehousing for reporting and
>>analysis.
>> 
>> ##Proposal
>> 
>> We propose to contribute the Palo codebase and associated artifacts
>>(e.g. documentation, web-site content etc.) to the Apache Software
>>Foundation with the intent of forming a productive, meritocratic and
>>open community around Palo’s continued development, according to the
>>‘Apache Way’.
>> 
>> Baidu owns several trademarks regarding Palo, and proposes to transfer
>>ownership of those trademarks in full to the ASF.
>> 
>> ###Overview of Palo
>> 
>> Palo’s implementation consists of two daemons: Frontend (FE) and
>>Backend (BE).
>> 
>> **Frontend daemon** consists of query coordinator and catalog manager.
>>Query coordinator is responsible for receiving users’ sql queries,
>>compiling queries and managing queries execution. Catalog manager is
>>responsible for managing metadata such as databases, tables, partitions,
>>replicas and etc. Several frontend daemons could be deployed to
>>guarantee fault-tolerance, and load balancing.
>> 
>> **Backend daemon** stores the data and executes the query fragments.
>>Many backend daemons could also be deployed to provide scalability and
>>fault-tolerance.
>> 
>> A typical Palo cluster generally composes of several frontend daemons
>>and dozens to hundreds of backend daemons.
>> 
>> Users can use MySQL client tools to connect any frontend daemon to
>>submit SQL query. Frontend receives the query and compiles it into query
>>plans executable by the Backend. Then Frontend sends the query plan
>>fragments to Backend. Backend will build a query execution DAG. Data is
>>fetched and pipelined into the DAG. The final result response is sent to
>>client via Frontend. The distribution of query fragment execution takes
>>minimizing data movement and maximizing scan locality as the main goal.
>> 
>> ##Background
>> 
>> At Baidu, Prior to Palo, different tools were deployed to solve diverse
>>requirements in many ways. And when a use case requires the simultaneous
>>availability of capabilities that cannot all be provided by a single
>>tool, users were forced to build hybrid architectures that stitch
>>multiple tools together, but we believe that they shouldn’t need to
>>accept such inherent complexity. A storage system built to provide great
>>performance across a broad range of workloads provides a more elegant
>>solution to the problems that hybrid architectures aim to solve. Palo is
>>the solution.
>> 
>> Palo is designed to be a simple and single tightly coupled system, not
>>depending on other systems. Palo provides high concurrent low latency
>>point query performance, but also provides high throughput queries of
>>ad-hoc analysis. Palo provides bulk-batch data loading, but also
>>provides near real-time mini-batch data loading. Palo also provides high
>>availability, reliability, fault tolerance, and scalability.
>> 
>> ##Rationale
>> 
>> Palo mainly integrates the technology of Google Mesa and Apache Impala.
>> 
>> Mesa is a highly scalable analytic data storage system that stores
>>critical measurement data related to Google's Internet advertising
>>business. Mesa is designed to satisfy complex and challenging set of
>>users’ and systems’ requirements, including near real-time data
>>ingestion and query ability, as well as high availability, reliability,
>>fault tolera

Re: Looking for Champion

[Tan,Zhongyi]

thanks，willem

we are very appreciate.

> 在 2018年6月8日，23:03，Willem Jiang  写道：
> 
> Hi,
> 
> I'm willing to be the Mentor.
> Please count me in.
> 
> 
> 
> Willem Jiang
> 
> Twitter: willemjiang
> Weibo: 姜宁willem
> 
>> On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher  wrote:
>> 
>> Hi -
>> 
>> I’m willing to Champion and Mentor. I have a couple of comments inline.
>> I’ll look at dependency licenses later today. It’s early for me.
>> 
>> 
>>> On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
>>> 
>>> Hi all,
>>> 
>>> I am Reed, as a developer worked with the team for Palo (a MPP-based
>> interactive SQL data warehousing).
>>> https://github.com/baidu/palo/wiki/Palo-Overview
>>> 
>>> We propose to contribute Palo as an Apache Incubator project, and
>>> we are still looking for possible Champion if anyone would like to
>> volunteer. Thanks a lot.
>>> 
>>> Best Regards,
>>> Reed
>>> 
>>> ===
>>> The draft of the proposal as below:
>>> 
>>> #Apache Palo
>>> 
>>> ##Abstract
>>> 
>>> Palo is a MPP-based interactive SQL data warehousing for reporting and
>> analysis.
>>> 
>>> ##Proposal
>>> 
>>> We propose to contribute the Palo codebase and associated artifacts
>> (e.g. documentation, web-site content etc.) to the Apache Software
>> Foundation with the intent of forming a productive, meritocratic and open
>> community around Palo’s continued development, according to the ‘Apache
>> Way’.
>>> 
>>> Baidu owns several trademarks regarding Palo, and proposes to transfer
>> ownership of those trademarks in full to the ASF.
>>> 
>>> ###Overview of Palo
>>> 
>>> Palo’s implementation consists of two daemons: Frontend (FE) and Backend
>> (BE).
>>> 
>>> **Frontend daemon** consists of query coordinator and catalog manager.
>> Query coordinator is responsible for receiving users’ sql queries,
>> compiling queries and managing queries execution. Catalog manager is
>> responsible for managing metadata such as databases, tables, partitions,
>> replicas and etc. Several frontend daemons could be deployed to guarantee
>> fault-tolerance, and load balancing.
>>> 
>>> **Backend daemon** stores the data and executes the query fragments.
>> Many backend daemons could also be deployed to provide scalability and
>> fault-tolerance.
>>> 
>>> A typical Palo cluster generally composes of several frontend daemons
>> and dozens to hundreds of backend daemons.
>>> 
>>> Users can use MySQL client tools to connect any frontend daemon to
>> submit SQL query. Frontend receives the query and compiles it into query
>> plans executable by the Backend. Then Frontend sends the query plan
>> fragments to Backend. Backend will build a query execution DAG. Data is
>> fetched and pipelined into the DAG. The final result response is sent to
>> client via Frontend. The distribution of query fragment execution takes
>> minimizing data movement and maximizing scan locality as the main goal.
>>> 
>>> ##Background
>>> 
>>> At Baidu, Prior to Palo, different tools were deployed to solve diverse
>> requirements in many ways. And when a use case requires the simultaneous
>> availability of capabilities that cannot all be provided by a single tool,
>> users were forced to build hybrid architectures that stitch multiple tools
>> together, but we believe that they shouldn’t need to accept such inherent
>> complexity. A storage system built to provide great performance across a
>> broad range of workloads provides a more elegant solution to the problems
>> that hybrid architectures aim to solve. Palo is the solution.
>>> 
>>> Palo is designed to be a simple and single tightly coupled system, not
>> depending on other systems. Palo provides high concurrent low latency point
>> query performance, but also provides high throughput queries of ad-hoc
>> analysis. Palo provides bulk-batch data loading, but also provides near
>> real-time mini-batch data loading. Palo also provides high availability,
>> reliability, fault tolerance, and scalability.
>>> 
>>> ##Rationale
>>> 
>>> Palo mainly integrates the technology of Google Mesa and Apache Impala.
>>> 
>>> Mesa is a highly scalable analytic data storage system that stores
>> critical measurement data related to Google's Internet advertising
>> business

Re: Looking for Champion

[Tan,Zhongyi]

great，dave，we will add you as champion.

thanks

> 在 2018年6月8日，20:59，Dave Fisher  写道：
> 
> Hi -
> 
> I’m willing to Champion and Mentor. I have a couple of comments inline. I’ll 
> look at dependency licenses later today. It’s early for me.
> 
> 
>> On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
>> 
>> Hi all,
>> 
>> I am Reed, as a developer worked with the team for Palo (a MPP-based 
>> interactive SQL data warehousing).
>> https://github.com/baidu/palo/wiki/Palo-Overview
>> 
>> We propose to contribute Palo as an Apache Incubator project, and
>> we are still looking for possible Champion if anyone would like to 
>> volunteer. Thanks a lot.
>> 
>> Best Regards,
>> Reed
>> 
>> ===
>> The draft of the proposal as below:
>> 
>> #Apache Palo
>> 
>> ##Abstract
>> 
>> Palo is a MPP-based interactive SQL data warehousing for reporting and 
>> analysis.
>> 
>> ##Proposal
>> 
>> We propose to contribute the Palo codebase and associated artifacts (e.g. 
>> documentation, web-site content etc.) to the Apache Software Foundation with 
>> the intent of forming a productive, meritocratic and open community around 
>> Palo’s continued development, according to the ‘Apache Way’.
>> 
>> Baidu owns several trademarks regarding Palo, and proposes to transfer 
>> ownership of those trademarks in full to the ASF.
>> 
>> ###Overview of Palo
>> 
>> Palo’s implementation consists of two daemons: Frontend (FE) and Backend 
>> (BE).
>> 
>> **Frontend daemon** consists of query coordinator and catalog manager. Query 
>> coordinator is responsible for receiving users’ sql queries, compiling 
>> queries and managing queries execution. Catalog manager is responsible for 
>> managing metadata such as databases, tables, partitions, replicas and etc. 
>> Several frontend daemons could be deployed to guarantee fault-tolerance, and 
>> load balancing.
>> 
>> **Backend daemon** stores the data and executes the query fragments. Many 
>> backend daemons could also be deployed to provide scalability and 
>> fault-tolerance.
>> 
>> A typical Palo cluster generally composes of several frontend daemons and 
>> dozens to hundreds of backend daemons.
>> 
>> Users can use MySQL client tools to connect any frontend daemon to submit 
>> SQL query. Frontend receives the query and compiles it into query plans 
>> executable by the Backend. Then Frontend sends the query plan fragments to 
>> Backend. Backend will build a query execution DAG. Data is fetched and 
>> pipelined into the DAG. The final result response is sent to client via 
>> Frontend. The distribution of query fragment execution takes minimizing data 
>> movement and maximizing scan locality as the main goal.
>> 
>> ##Background
>> 
>> At Baidu, Prior to Palo, different tools were deployed to solve diverse 
>> requirements in many ways. And when a use case requires the simultaneous 
>> availability of capabilities that cannot all be provided by a single tool, 
>> users were forced to build hybrid architectures that stitch multiple tools 
>> together, but we believe that they shouldn’t need to accept such inherent 
>> complexity. A storage system built to provide great performance across a 
>> broad range of workloads provides a more elegant solution to the problems 
>> that hybrid architectures aim to solve. Palo is the solution.
>> 
>> Palo is designed to be a simple and single tightly coupled system, not 
>> depending on other systems. Palo provides high concurrent low latency point 
>> query performance, but also provides high throughput queries of ad-hoc 
>> analysis. Palo provides bulk-batch data loading, but also provides near 
>> real-time mini-batch data loading. Palo also provides high availability, 
>> reliability, fault tolerance, and scalability.
>> 
>> ##Rationale
>> 
>> Palo mainly integrates the technology of Google Mesa and Apache Impala.
>> 
>> Mesa is a highly scalable analytic data storage system that stores critical 
>> measurement data related to Google's Internet advertising business. Mesa is 
>> designed to satisfy complex and challenging set of users’ and systems’ 
>> requirements, including near real-time data ingestion and query ability, as 
>> well as high availability, reliability, fault tolerance, and scalability for 
>> large data and query volumes.
>> 
>> Impala is a modern, open-source MPP SQL engine architected from the ground 
>> up for the Hadoop data processing

Re: Looking for Champion

[Jim Apple]

>
> Generally Apache has no rules against multiple projects fulfilling similar
> goals or use cases, even when those projects might compete. However I think
> it would be relatively unusual to incubate a project that appears to be
> derived from a fork of an existing project, at least without first
> considering whether the additional feature set could be contributed back to
> the existing community.
>

And this is something I'm really excited about. If only the storage system
part of Palo were contributed to the ASF, and simultaneously the Palo
community and the Impala community worked together to integrate the query
engine work of Palo into Impala, then this could provide a lot of benefit
to users, I think. My hope is that it would eliminate the toil the Palo
community is engaged in by rebasing Impala changes (as Tim noticed).
Impala, meanwhile, might benefit from some changes Palo has made, like SIMD
filtering.

This could be a lot of work, but the current system seems to already
include quite a lot of inefficiency from the duplication.

Re: Looking for Champion

[Ted Dunning]

Open LDAP is a form of copy-left. It requires source code distribution of
binary packaged versions.



On Fri, Jun 8, 2018 at 7:10 PM Dave Fisher  wrote:

> Yuck. That’s a mess. That is one very large diff.
>
> I see a few files related to AES the were GPL converted to Apache which
> not allowed.
> Copyrights were changed too which is also incorrect.
>
> Changes to this file be/src/http/mongoose.h
> 
>  violate
> license and copyright of Sergey Lyubka
>
> GitHub makes you expand each diff after awhile.
>
> There are dependency licenses that might be issues too.
>
> These licenses have not been evaluated by LEGAL.
> * OpenLdap (OpenLDAP Software License)
>
> http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=LICENSE;hb=e5f8117f0ce088d0bd7a8e18ddf37eaa40eb09b1
> * rapidjson (Tencent)
> Unknown
> * cyrus-sasl (CMU License)
> https://spdx.org/licenses/MIT-CMU.html
> AKA MIT-CMU
>
> Lots of work in evaluating licenses.
>
> On Jun 8, 2018, at 9:46 AM, Ted Dunning  wrote:
>
> Ouch.
>
> The copyright in question was attached to code from the source code for
> mySQL. There is no way that code can be in an Apache project.
>
> Given the cut and paste history, it seems like it will require a very
> detailed audit of code history or web searches to find where the original
> code came from. The my_aes.c and .h files, for instance, have no hint in
> their history that they came from GPL'ed code.
>
>
> Yeah. Lot’s of oversight.
>
> If we accept this proposal we need a Mentor who has time to help with this
> mess.
>
> I don’t know that I have the time to lead that effort. Anyone?
>
> Regards,
> Dave
>
>
> On Fri, Jun 8, 2018 at 5:37 PM Todd Lipcon  wrote:
>
> ...
>
> +1. Also briefly browsing the code I found suspicious commits like this
> one:
>
>
> https://github.com/baidu/palo/commit/6486be64c319fe0beb8c6b4430c1662de54f182e
>
> ... in which a GPL license copyright by Oracle was "fixed" to be an Apache
> license copyright Baidu.
>
> So if this project does enter incubation I think we should be extra careful
> to audit the origins of all of the source code.
>
>
>
>

Re: Looking for Champion

[Dave Fisher]

Yuck. That’s a mess. That is one very large diff.

I see a few files related to AES the were GPL converted to Apache which not 
allowed.
Copyrights were changed too which is also incorrect.

Changes to this file be/src/http/mongoose.h 

 violate license and copyright of Sergey Lyubka

GitHub makes you expand each diff after awhile.

There are dependency licenses that might be issues too.

These licenses have not been evaluated by LEGAL.
* OpenLdap (OpenLDAP Software License)

http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=LICENSE;hb=e5f8117f0ce088d0bd7a8e18ddf37eaa40eb09b1
* rapidjson (Tencent)
Unknown
* cyrus-sasl (CMU License)
https://spdx.org/licenses/MIT-CMU.html
AKA MIT-CMU

Lots of work in evaluating licenses.

> On Jun 8, 2018, at 9:46 AM, Ted Dunning  wrote:
> 
> Ouch.
> 
> The copyright in question was attached to code from the source code for
> mySQL. There is no way that code can be in an Apache project.
> 
> Given the cut and paste history, it seems like it will require a very
> detailed audit of code history or web searches to find where the original
> code came from. The my_aes.c and .h files, for instance, have no hint in
> their history that they came from GPL'ed code.

Yeah. Lot’s of oversight.

If we accept this proposal we need a Mentor who has time to help with this mess.

I don’t know that I have the time to lead that effort. Anyone?

Regards,
Dave

> 
> On Fri, Jun 8, 2018 at 5:37 PM Todd Lipcon  wrote:
> 
>> ...
>> 
>> +1. Also briefly browsing the code I found suspicious commits like this
>> one:
>> 
>> https://github.com/baidu/palo/commit/6486be64c319fe0beb8c6b4430c1662de54f182e
>> 
>> ... in which a GPL license copyright by Oracle was "fixed" to be an Apache
>> license copyright Baidu.
>> 
>> So if this project does enter incubation I think we should be extra careful
>> to audit the origins of all of the source code.
>> 
>> 



signature.asc
Description: Message signed with OpenPGP

Re: Looking for Champion

[Ted Dunning]

Ouch.

The copyright in question was attached to code from the source code for
mySQL. There is no way that code can be in an Apache project.

Given the cut and paste history, it seems like it will require a very
detailed audit of code history or web searches to find where the original
code came from. The my_aes.c and .h files, for instance, have no hint in
their history that they came from GPL'ed code.

On Fri, Jun 8, 2018 at 5:37 PM Todd Lipcon  wrote:

> ...
>
> +1. Also briefly browsing the code I found suspicious commits like this
> one:
>
> https://github.com/baidu/palo/commit/6486be64c319fe0beb8c6b4430c1662de54f182e
>
> ... in which a GPL license copyright by Oracle was "fixed" to be an Apache
> license copyright Baidu.
>
> So if this project does enter incubation I think we should be extra careful
> to audit the origins of all of the source code.
>
>

Re: Looking for Champion

[Todd Lipcon]

On Fri, Jun 8, 2018 at 9:18 AM, Tim Armstrong 
wrote:

> > Meanwhile we found Impala is a very good MPP SQL query engine, so we
> integrated
> them together.
>
> Palo didn't integrate with Impala, it forked Impala's codebase and embedded
> it in its own repository. I don't remember any attempts from the Palo team
> to engage with the Impala community or attempt to work with us to
> contribute any improvements.
>
> It looks like Palo is still pulling in new code from Impala.  E.g. this
> commit includes a bunch of code I wrote as part of IMPALA-3200:
> https://github.com/baidu/palo/commit/2419384e8a211f10e7636afc6d3423
> 700ba22b5a#diff-1c501d9a8b5c3d1d1cce48d5e1fb0edf
>
> The code isn't owned by any individual, I contributed it to Apache and it's
> free for anyone to do what they want to do with it, but pulling in
> improvements from other projects without any attempt to attribute it or
> contribute improvements back seems contrary to the Apache way.
>

+1. Also briefly browsing the code I found suspicious commits like this one:
https://github.com/baidu/palo/commit/6486be64c319fe0beb8c6b4430c1662de54f182e

... in which a GPL license copyright by Oracle was "fixed" to be an Apache
license copyright Baidu.

So if this project does enter incubation I think we should be extra careful
to audit the origins of all of the source code.

-Todd


> On Fri, Jun 8, 2018 at 9:12 AM, Todd Lipcon  wrote:
>
> > On Thu, Jun 7, 2018 at 11:55 PM, Li,De(BDG)  wrote:
> >
> > > Hi, Jim
> > >
> > > Thank you for your response.
> > > Actually, we start Palo in several years ago, and that time we
> developed
> > > the storage engine based on Mesa technology.
> > > Meanwhile we found Impala is a very good MPP SQL query engine, so we
> > > integrated them together.
> > >
> >
> > From what I can tell of the Palo source, it's not so much an integration
> as
> > a copied-and-modified codebase, right? i.e Palo does not use Impala as a
> > dependency, but rather shares a lot of code from the Impala project that
> > has since diverged.
> >
> >
> > >
> > > With this integration, the goal of Palo is to implement a single,
> > > full-featured, mysql protocol compatible data warehousing.
> > >
> >
> > That sounds pretty similar to the goals of the Impala project. Impala
> isn't
> > MySQL-compatible at the moment but that seems more like a particular
> > feature that could be added rather than a distinct identity of the
> project.
> > Otherwise, Impala's goal is to be a full featured data warehouse engine
> as
> > well.
> >
> > Generally Apache has no rules against multiple projects fulfilling
> similar
> > goals or use cases, even when those projects might compete. However I
> think
> > it would be relatively unusual to incubate a project that appears to be
> > derived from a fork of an existing project, at least without first
> > considering whether the additional feature set could be contributed back
> to
> > the existing community.
> >
> > -Todd
> >
> >
> > > 在 2018/6/8 下午1:55， "Jim Apple"  写入:
> > >
> > > >Hello! As a contributor to Impala, I’d be interested in hearing
> thoughts
> > > >from the Palo community about integration between Impala and Palo.
> > > >
> > > >For instance, are there any apparent design goals of Impala that the
> > Palo
> > > >community thinks are fundamentally incompatible with Palo?
> > > >
> > > >Thanks,
> > > >Jim
> > > >
> > > >On 2018/06/08 04:45:32, "Li,De(BDG)"  wrote:
> > > >> Hi all,
> > > >>
> > > >> I am Reed, as a developer worked with the team for Palo (a MPP-based
> > > >>interactive SQL data warehousing).
> > > >> https://github.com/baidu/palo/wiki/Palo-Overview
> > > >>
> > > >> We propose to contribute Palo as an Apache Incubator project, and
> > > >> we are still looking for possible Champion if anyone would like to
> > > >>volunteer. Thanks a lot.
> > > >>
> > > >> Best Regards,
> > > >> Reed
> > > >>
> > > >> ===
> > > >> The draft of the proposal as below:
> > > >>
> > > >> #Apache Palo
> > > >>
> > > >> ##Abstract
> > > >>
> > > >> Palo is a MPP-based interactive SQL data warehousing for reporting
> and
> > > >>analysis.
> &

Re: Looking for Champion

[Tim Armstrong]

> Meanwhile we found Impala is a very good MPP SQL query engine, so we 
> integrated
them together.

Palo didn't integrate with Impala, it forked Impala's codebase and embedded
it in its own repository. I don't remember any attempts from the Palo team
to engage with the Impala community or attempt to work with us to
contribute any improvements.

It looks like Palo is still pulling in new code from Impala.  E.g. this
commit includes a bunch of code I wrote as part of IMPALA-3200:
https://github.com/baidu/palo/commit/2419384e8a211f10e7636afc6d3423700ba22b5a#diff-1c501d9a8b5c3d1d1cce48d5e1fb0edf

The code isn't owned by any individual, I contributed it to Apache and it's
free for anyone to do what they want to do with it, but pulling in
improvements from other projects without any attempt to attribute it or
contribute improvements back seems contrary to the Apache way.

Anyway, maybe incubation is an opportunity for us to work together, but I'd
hope that if Palo does go into incubation that it will rethink some of the
practices it's been following.

On Fri, Jun 8, 2018 at 9:12 AM, Todd Lipcon  wrote:

> On Thu, Jun 7, 2018 at 11:55 PM, Li,De(BDG)  wrote:
>
> > Hi, Jim
> >
> > Thank you for your response.
> > Actually, we start Palo in several years ago, and that time we developed
> > the storage engine based on Mesa technology.
> > Meanwhile we found Impala is a very good MPP SQL query engine, so we
> > integrated them together.
> >
>
> From what I can tell of the Palo source, it's not so much an integration as
> a copied-and-modified codebase, right? i.e Palo does not use Impala as a
> dependency, but rather shares a lot of code from the Impala project that
> has since diverged.
>
>
> >
> > With this integration, the goal of Palo is to implement a single,
> > full-featured, mysql protocol compatible data warehousing.
> >
>
> That sounds pretty similar to the goals of the Impala project. Impala isn't
> MySQL-compatible at the moment but that seems more like a particular
> feature that could be added rather than a distinct identity of the project.
> Otherwise, Impala's goal is to be a full featured data warehouse engine as
> well.
>
> Generally Apache has no rules against multiple projects fulfilling similar
> goals or use cases, even when those projects might compete. However I think
> it would be relatively unusual to incubate a project that appears to be
> derived from a fork of an existing project, at least without first
> considering whether the additional feature set could be contributed back to
> the existing community.
>
> -Todd
>
>
> > 在 2018/6/8 下午1:55， "Jim Apple"  写入:
> >
> > >Hello! As a contributor to Impala, I’d be interested in hearing thoughts
> > >from the Palo community about integration between Impala and Palo.
> > >
> > >For instance, are there any apparent design goals of Impala that the
> Palo
> > >community thinks are fundamentally incompatible with Palo?
> > >
> > >Thanks,
> > >Jim
> > >
> > >On 2018/06/08 04:45:32, "Li,De(BDG)"  wrote:
> > >> Hi all,
> > >>
> > >> I am Reed, as a developer worked with the team for Palo (a MPP-based
> > >>interactive SQL data warehousing).
> > >> https://github.com/baidu/palo/wiki/Palo-Overview
> > >>
> > >> We propose to contribute Palo as an Apache Incubator project, and
> > >> we are still looking for possible Champion if anyone would like to
> > >>volunteer. Thanks a lot.
> > >>
> > >> Best Regards,
> > >> Reed
> > >>
> > >> ===
> > >> The draft of the proposal as below:
> > >>
> > >> #Apache Palo
> > >>
> > >> ##Abstract
> > >>
> > >> Palo is a MPP-based interactive SQL data warehousing for reporting and
> > >>analysis.
> > >>
> > >> ##Proposal
> > >>
> > >> We propose to contribute the Palo codebase and associated artifacts
> > >>(e.g. documentation, web-site content etc.) to the Apache Software
> > >>Foundation with the intent of forming a productive, meritocratic and
> > >>open community around Palo’s continued development, according to the
> > >>‘Apache Way’.
> > >>
> > >> Baidu owns several trademarks regarding Palo, and proposes to transfer
> > >>ownership of those trademarks in full to the ASF.
> > >>
> > >> ###Overview of Palo
> > >>
> > >> Palo’s implementation consists of two daemons: Frontend (FE) an

Re: Looking for Champion

[Todd Lipcon]

On Thu, Jun 7, 2018 at 11:55 PM, Li,De(BDG)  wrote:

> Hi, Jim
>
> Thank you for your response.
> Actually, we start Palo in several years ago, and that time we developed
> the storage engine based on Mesa technology.
> Meanwhile we found Impala is a very good MPP SQL query engine, so we
> integrated them together.
>

>From what I can tell of the Palo source, it's not so much an integration as
a copied-and-modified codebase, right? i.e Palo does not use Impala as a
dependency, but rather shares a lot of code from the Impala project that
has since diverged.


>
> With this integration, the goal of Palo is to implement a single,
> full-featured, mysql protocol compatible data warehousing.
>

That sounds pretty similar to the goals of the Impala project. Impala isn't
MySQL-compatible at the moment but that seems more like a particular
feature that could be added rather than a distinct identity of the project.
Otherwise, Impala's goal is to be a full featured data warehouse engine as
well.

Generally Apache has no rules against multiple projects fulfilling similar
goals or use cases, even when those projects might compete. However I think
it would be relatively unusual to incubate a project that appears to be
derived from a fork of an existing project, at least without first
considering whether the additional feature set could be contributed back to
the existing community.

-Todd


> 在 2018/6/8 下午1:55， "Jim Apple"  写入:
>
> >Hello! As a contributor to Impala, I’d be interested in hearing thoughts
> >from the Palo community about integration between Impala and Palo.
> >
> >For instance, are there any apparent design goals of Impala that the Palo
> >community thinks are fundamentally incompatible with Palo?
> >
> >Thanks,
> >Jim
> >
> >On 2018/06/08 04:45:32, "Li,De(BDG)"  wrote:
> >> Hi all,
> >>
> >> I am Reed, as a developer worked with the team for Palo (a MPP-based
> >>interactive SQL data warehousing).
> >> https://github.com/baidu/palo/wiki/Palo-Overview
> >>
> >> We propose to contribute Palo as an Apache Incubator project, and
> >> we are still looking for possible Champion if anyone would like to
> >>volunteer. Thanks a lot.
> >>
> >> Best Regards,
> >> Reed
> >>
> >> ===
> >> The draft of the proposal as below:
> >>
> >> #Apache Palo
> >>
> >> ##Abstract
> >>
> >> Palo is a MPP-based interactive SQL data warehousing for reporting and
> >>analysis.
> >>
> >> ##Proposal
> >>
> >> We propose to contribute the Palo codebase and associated artifacts
> >>(e.g. documentation, web-site content etc.) to the Apache Software
> >>Foundation with the intent of forming a productive, meritocratic and
> >>open community around Palo’s continued development, according to the
> >>‘Apache Way’.
> >>
> >> Baidu owns several trademarks regarding Palo, and proposes to transfer
> >>ownership of those trademarks in full to the ASF.
> >>
> >> ###Overview of Palo
> >>
> >> Palo’s implementation consists of two daemons: Frontend (FE) and
> >>Backend (BE).
> >>
> >> **Frontend daemon** consists of query coordinator and catalog manager.
> >>Query coordinator is responsible for receiving users’ sql queries,
> >>compiling queries and managing queries execution. Catalog manager is
> >>responsible for managing metadata such as databases, tables, partitions,
> >>replicas and etc. Several frontend daemons could be deployed to
> >>guarantee fault-tolerance, and load balancing.
> >>
> >> **Backend daemon** stores the data and executes the query fragments.
> >>Many backend daemons could also be deployed to provide scalability and
> >>fault-tolerance.
> >>
> >> A typical Palo cluster generally composes of several frontend daemons
> >>and dozens to hundreds of backend daemons.
> >>
> >> Users can use MySQL client tools to connect any frontend daemon to
> >>submit SQL query. Frontend receives the query and compiles it into query
> >>plans executable by the Backend. Then Frontend sends the query plan
> >>fragments to Backend. Backend will build a query execution DAG. Data is
> >>fetched and pipelined into the DAG. The final result response is sent to
> >>client via Frontend. The distribution of query fragment execution takes
> >>minimizing data movement and maximizing scan locality as the main goal.
> >>
> >> ##Background
> >>
> >> At 

Re: Looking for Champion

[Willem Jiang]

Hi,

I'm willing to be the Mentor.
Please count me in.



Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Jun 8, 2018 at 8:59 PM, Dave Fisher  wrote:

> Hi -
>
> I’m willing to Champion and Mentor. I have a couple of comments inline.
> I’ll look at dependency licenses later today. It’s early for me.
>
>
> > On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
> >
> > Hi all,
> >
> > I am Reed, as a developer worked with the team for Palo (a MPP-based
> interactive SQL data warehousing).
> > https://github.com/baidu/palo/wiki/Palo-Overview
> >
> > We propose to contribute Palo as an Apache Incubator project, and
> > we are still looking for possible Champion if anyone would like to
> volunteer. Thanks a lot.
> >
> > Best Regards,
> > Reed
> >
> > ===
> > The draft of the proposal as below:
> >
> > #Apache Palo
> >
> > ##Abstract
> >
> > Palo is a MPP-based interactive SQL data warehousing for reporting and
> analysis.
> >
> > ##Proposal
> >
> > We propose to contribute the Palo codebase and associated artifacts
> (e.g. documentation, web-site content etc.) to the Apache Software
> Foundation with the intent of forming a productive, meritocratic and open
> community around Palo’s continued development, according to the ‘Apache
> Way’.
> >
> > Baidu owns several trademarks regarding Palo, and proposes to transfer
> ownership of those trademarks in full to the ASF.
> >
> > ###Overview of Palo
> >
> > Palo’s implementation consists of two daemons: Frontend (FE) and Backend
> (BE).
> >
> > **Frontend daemon** consists of query coordinator and catalog manager.
> Query coordinator is responsible for receiving users’ sql queries,
> compiling queries and managing queries execution. Catalog manager is
> responsible for managing metadata such as databases, tables, partitions,
> replicas and etc. Several frontend daemons could be deployed to guarantee
> fault-tolerance, and load balancing.
> >
> > **Backend daemon** stores the data and executes the query fragments.
> Many backend daemons could also be deployed to provide scalability and
> fault-tolerance.
> >
> > A typical Palo cluster generally composes of several frontend daemons
> and dozens to hundreds of backend daemons.
> >
> > Users can use MySQL client tools to connect any frontend daemon to
> submit SQL query. Frontend receives the query and compiles it into query
> plans executable by the Backend. Then Frontend sends the query plan
> fragments to Backend. Backend will build a query execution DAG. Data is
> fetched and pipelined into the DAG. The final result response is sent to
> client via Frontend. The distribution of query fragment execution takes
> minimizing data movement and maximizing scan locality as the main goal.
> >
> > ##Background
> >
> > At Baidu, Prior to Palo, different tools were deployed to solve diverse
> requirements in many ways. And when a use case requires the simultaneous
> availability of capabilities that cannot all be provided by a single tool,
> users were forced to build hybrid architectures that stitch multiple tools
> together, but we believe that they shouldn’t need to accept such inherent
> complexity. A storage system built to provide great performance across a
> broad range of workloads provides a more elegant solution to the problems
> that hybrid architectures aim to solve. Palo is the solution.
> >
> > Palo is designed to be a simple and single tightly coupled system, not
> depending on other systems. Palo provides high concurrent low latency point
> query performance, but also provides high throughput queries of ad-hoc
> analysis. Palo provides bulk-batch data loading, but also provides near
> real-time mini-batch data loading. Palo also provides high availability,
> reliability, fault tolerance, and scalability.
> >
> > ##Rationale
> >
> > Palo mainly integrates the technology of Google Mesa and Apache Impala.
> >
> > Mesa is a highly scalable analytic data storage system that stores
> critical measurement data related to Google's Internet advertising
> business. Mesa is designed to satisfy complex and challenging set of users’
> and systems’ requirements, including near real-time data ingestion and
> query ability, as well as high availability, reliability, fault tolerance,
> and scalability for large data and query volumes.
> >
> > Impala is a modern, open-source MPP SQL engine architected from the
> ground up for the Hadoop data processing environment. At present, by virtue
> of its superior performance and rich functionality， Imp

Re: Looking for Champion

[Dave Fisher]

Hi -

I’m willing to Champion and Mentor. I have a couple of comments inline. I’ll 
look at dependency licenses later today. It’s early for me.


> On Jun 7, 2018, at 9:45 PM, Li,De(BDG)  wrote:
> 
> Hi all,
> 
> I am Reed, as a developer worked with the team for Palo (a MPP-based 
> interactive SQL data warehousing).
> https://github.com/baidu/palo/wiki/Palo-Overview
> 
> We propose to contribute Palo as an Apache Incubator project, and
> we are still looking for possible Champion if anyone would like to volunteer. 
> Thanks a lot.
> 
> Best Regards,
> Reed
> 
> ===
> The draft of the proposal as below:
> 
> #Apache Palo
> 
> ##Abstract
> 
> Palo is a MPP-based interactive SQL data warehousing for reporting and 
> analysis.
> 
> ##Proposal
> 
> We propose to contribute the Palo codebase and associated artifacts (e.g. 
> documentation, web-site content etc.) to the Apache Software Foundation with 
> the intent of forming a productive, meritocratic and open community around 
> Palo’s continued development, according to the ‘Apache Way’.
> 
> Baidu owns several trademarks regarding Palo, and proposes to transfer 
> ownership of those trademarks in full to the ASF.
> 
> ###Overview of Palo
> 
> Palo’s implementation consists of two daemons: Frontend (FE) and Backend (BE).
> 
> **Frontend daemon** consists of query coordinator and catalog manager. Query 
> coordinator is responsible for receiving users’ sql queries, compiling 
> queries and managing queries execution. Catalog manager is responsible for 
> managing metadata such as databases, tables, partitions, replicas and etc. 
> Several frontend daemons could be deployed to guarantee fault-tolerance, and 
> load balancing.
> 
> **Backend daemon** stores the data and executes the query fragments. Many 
> backend daemons could also be deployed to provide scalability and 
> fault-tolerance.
> 
> A typical Palo cluster generally composes of several frontend daemons and 
> dozens to hundreds of backend daemons.
> 
> Users can use MySQL client tools to connect any frontend daemon to submit SQL 
> query. Frontend receives the query and compiles it into query plans 
> executable by the Backend. Then Frontend sends the query plan fragments to 
> Backend. Backend will build a query execution DAG. Data is fetched and 
> pipelined into the DAG. The final result response is sent to client via 
> Frontend. The distribution of query fragment execution takes minimizing data 
> movement and maximizing scan locality as the main goal.
> 
> ##Background
> 
> At Baidu, Prior to Palo, different tools were deployed to solve diverse 
> requirements in many ways. And when a use case requires the simultaneous 
> availability of capabilities that cannot all be provided by a single tool, 
> users were forced to build hybrid architectures that stitch multiple tools 
> together, but we believe that they shouldn’t need to accept such inherent 
> complexity. A storage system built to provide great performance across a 
> broad range of workloads provides a more elegant solution to the problems 
> that hybrid architectures aim to solve. Palo is the solution.
> 
> Palo is designed to be a simple and single tightly coupled system, not 
> depending on other systems. Palo provides high concurrent low latency point 
> query performance, but also provides high throughput queries of ad-hoc 
> analysis. Palo provides bulk-batch data loading, but also provides near 
> real-time mini-batch data loading. Palo also provides high availability, 
> reliability, fault tolerance, and scalability.
> 
> ##Rationale
> 
> Palo mainly integrates the technology of Google Mesa and Apache Impala.
> 
> Mesa is a highly scalable analytic data storage system that stores critical 
> measurement data related to Google's Internet advertising business. Mesa is 
> designed to satisfy complex and challenging set of users’ and systems’ 
> requirements, including near real-time data ingestion and query ability, as 
> well as high availability, reliability, fault tolerance, and scalability for 
> large data and query volumes.
> 
> Impala is a modern, open-source MPP SQL engine architected from the ground up 
> for the Hadoop data processing environment. At present, by virtue of its 
> superior performance and rich functionality， Impala has been comparable to 
> many commercial MPP database query engine. Mesa can satisfy the needs of many 
> of our storage requirements, however Mesa itself does not provide a SQL query 
> engine; Impala is a very good MPP SQL query engine, but the lack of a perfect 
> distributed storage engine. So in the end we chose the combination of these 
> two technologies.
> 
> Lea

Re: Looking for Champion

[Tan,Zhongyi]

Hi，guys, 

palo is one good project ,

Is there anyone who volunteer to be the champion of it to
help us to go through process to become an apache project?

Thanks

>
>On 2018/06/08 04:45:32, "Li,De(BDG)"  wrote:
>> Hi all,
>> 
>> I am Reed, as a developer worked with the team for Palo (a MPP-based
>>interactive SQL data warehousing).
>> https://github.com/baidu/palo/wiki/Palo-Overview
>> 
>> We propose to contribute Palo as an Apache Incubator project, and
>> we are still looking for possible Champion if anyone would like to
>>volunteer. Thanks a lot.
>> 
>> Best Regards,
>> Reed
>> 
>> ===
>> The draft of the proposal as below:
>> 
>> #Apache Palo
>> 
>> ##Abstract
>> 
>> Palo is a MPP-based interactive SQL data warehousing for reporting and
>>analysis.
>> 
>> ##Proposal
>> 
>> We propose to contribute the Palo codebase and associated artifacts
>>(e.g. documentation, web-site content etc.) to the Apache Software
>>Foundation with the intent of forming a productive, meritocratic and
>>open community around Palo’s continued development, according to the
>>‘Apache Way’.
>> 
>> Baidu owns several trademarks regarding Palo, and proposes to transfer
>>ownership of those trademarks in full to the ASF.
>> 
>> ###Overview of Palo
>> 
>> Palo’s implementation consists of two daemons: Frontend (FE) and
>>Backend (BE).
>> 
>> **Frontend daemon** consists of query coordinator and catalog manager.
>>Query coordinator is responsible for receiving users’ sql queries,
>>compiling queries and managing queries execution. Catalog manager is
>>responsible for managing metadata such as databases, tables, partitions,
>>replicas and etc. Several frontend daemons could be deployed to
>>guarantee fault-tolerance, and load balancing.
>> 
>> **Backend daemon** stores the data and executes the query fragments.
>>Many backend daemons could also be deployed to provide scalability and
>>fault-tolerance.
>> 
>> A typical Palo cluster generally composes of several frontend daemons
>>and dozens to hundreds of backend daemons.
>> 
>> Users can use MySQL client tools to connect any frontend daemon to
>>submit SQL query. Frontend receives the query and compiles it into query
>>plans executable by the Backend. Then Frontend sends the query plan
>>fragments to Backend. Backend will build a query execution DAG. Data is
>>fetched and pipelined into the DAG. The final result response is sent to
>>client via Frontend. The distribution of query fragment execution takes
>>minimizing data movement and maximizing scan locality as the main goal.
>> 
>> ##Background
>> 
>> At Baidu, Prior to Palo, different tools were deployed to solve diverse
>>requirements in many ways. And when a use case requires the simultaneous
>>availability of capabilities that cannot all be provided by a single
>>tool, users were forced to build hybrid architectures that stitch
>>multiple tools together, but we believe that they shouldn’t need to
>>accept such inherent complexity. A storage system built to provide great
>>performance across a broad range of workloads provides a more elegant
>>solution to the problems that hybrid architectures aim to solve. Palo is
>>the solution.
>> 
>> Palo is designed to be a simple and single tightly coupled system, not
>>depending on other systems. Palo provides high concurrent low latency
>>point query performance, but also provides high throughput queries of
>>ad-hoc analysis. Palo provides bulk-batch data loading, but also
>>provides near real-time mini-batch data loading. Palo also provides high
>>availability, reliability, fault tolerance, and scalability.
>> 
>> ##Rationale
>> 
>> Palo mainly integrates the technology of Google Mesa and Apache Impala.
>> 
>> Mesa is a highly scalable analytic data storage system that stores
>>critical measurement data related to Google's Internet advertising
>>business. Mesa is designed to satisfy complex and challenging set of
>>users’ and systems’ requirements, including near real-time data
>>ingestion and query ability, as well as high availability, reliability,
>>fault tolerance, and scalability for large data and query volumes.
>> 
>> Impala is a modern, open-source MPP SQL engine architected from the
>>ground up for the Hadoop data processing environment. At present, by
>>virtue of its superior performance and rich functionality， Impala has
>>been comparable to many commercial MPP database query

Re: Looking for Champion

[Li,De(BDG)]

Hi, Jim

Thank you for your response.
Actually, we start Palo in several years ago, and that time we developed
the storage engine based on Mesa technology.
Meanwhile we found Impala is a very good MPP SQL query engine, so we
integrated them together.

With this integration, the goal of Palo is to implement a single,
full-featured, mysql protocol compatible data warehousing.


Best regards,
Reed

在 2018/6/8 下午1:55， "Jim Apple"  写入:

>Hello! As a contributor to Impala, I’d be interested in hearing thoughts
>from the Palo community about integration between Impala and Palo.
>
>For instance, are there any apparent design goals of Impala that the Palo
>community thinks are fundamentally incompatible with Palo?
>
>Thanks,
>Jim
>
>On 2018/06/08 04:45:32, "Li,De(BDG)"  wrote:
>> Hi all,
>> 
>> I am Reed, as a developer worked with the team for Palo (a MPP-based
>>interactive SQL data warehousing).
>> https://github.com/baidu/palo/wiki/Palo-Overview
>> 
>> We propose to contribute Palo as an Apache Incubator project, and
>> we are still looking for possible Champion if anyone would like to
>>volunteer. Thanks a lot.
>> 
>> Best Regards,
>> Reed
>> 
>> ===
>> The draft of the proposal as below:
>> 
>> #Apache Palo
>> 
>> ##Abstract
>> 
>> Palo is a MPP-based interactive SQL data warehousing for reporting and
>>analysis.
>> 
>> ##Proposal
>> 
>> We propose to contribute the Palo codebase and associated artifacts
>>(e.g. documentation, web-site content etc.) to the Apache Software
>>Foundation with the intent of forming a productive, meritocratic and
>>open community around Palo’s continued development, according to the
>>‘Apache Way’.
>> 
>> Baidu owns several trademarks regarding Palo, and proposes to transfer
>>ownership of those trademarks in full to the ASF.
>> 
>> ###Overview of Palo
>> 
>> Palo’s implementation consists of two daemons: Frontend (FE) and
>>Backend (BE).
>> 
>> **Frontend daemon** consists of query coordinator and catalog manager.
>>Query coordinator is responsible for receiving users’ sql queries,
>>compiling queries and managing queries execution. Catalog manager is
>>responsible for managing metadata such as databases, tables, partitions,
>>replicas and etc. Several frontend daemons could be deployed to
>>guarantee fault-tolerance, and load balancing.
>> 
>> **Backend daemon** stores the data and executes the query fragments.
>>Many backend daemons could also be deployed to provide scalability and
>>fault-tolerance.
>> 
>> A typical Palo cluster generally composes of several frontend daemons
>>and dozens to hundreds of backend daemons.
>> 
>> Users can use MySQL client tools to connect any frontend daemon to
>>submit SQL query. Frontend receives the query and compiles it into query
>>plans executable by the Backend. Then Frontend sends the query plan
>>fragments to Backend. Backend will build a query execution DAG. Data is
>>fetched and pipelined into the DAG. The final result response is sent to
>>client via Frontend. The distribution of query fragment execution takes
>>minimizing data movement and maximizing scan locality as the main goal.
>> 
>> ##Background
>> 
>> At Baidu, Prior to Palo, different tools were deployed to solve diverse
>>requirements in many ways. And when a use case requires the simultaneous
>>availability of capabilities that cannot all be provided by a single
>>tool, users were forced to build hybrid architectures that stitch
>>multiple tools together, but we believe that they shouldn’t need to
>>accept such inherent complexity. A storage system built to provide great
>>performance across a broad range of workloads provides a more elegant
>>solution to the problems that hybrid architectures aim to solve. Palo is
>>the solution.
>> 
>> Palo is designed to be a simple and single tightly coupled system, not
>>depending on other systems. Palo provides high concurrent low latency
>>point query performance, but also provides high throughput queries of
>>ad-hoc analysis. Palo provides bulk-batch data loading, but also
>>provides near real-time mini-batch data loading. Palo also provides high
>>availability, reliability, fault tolerance, and scalability.
>> 
>> ##Rationale
>> 
>> Palo mainly integrates the technology of Google Mesa and Apache Impala.
>> 
>> Mesa is a highly scalable analytic data storage system that stores
>>critical measurement data related to Google's Internet advertising
>>busine

Re: Looking for Champion

[Jim Apple]

Hello! As a contributor to Impala, I’d be interested in hearing thoughts from 
the Palo community about integration between Impala and Palo.

For instance, are there any apparent design goals of Impala that the Palo 
community thinks are fundamentally incompatible with Palo?

Thanks,
Jim

On 2018/06/08 04:45:32, "Li,De(BDG)"  wrote: 
> Hi all,
> 
> I am Reed, as a developer worked with the team for Palo (a MPP-based 
> interactive SQL data warehousing).
> https://github.com/baidu/palo/wiki/Palo-Overview
> 
> We propose to contribute Palo as an Apache Incubator project, and
> we are still looking for possible Champion if anyone would like to volunteer. 
> Thanks a lot.
> 
> Best Regards,
> Reed
> 
> ===
> The draft of the proposal as below:
> 
> #Apache Palo
> 
> ##Abstract
> 
> Palo is a MPP-based interactive SQL data warehousing for reporting and 
> analysis.
> 
> ##Proposal
> 
> We propose to contribute the Palo codebase and associated artifacts (e.g. 
> documentation, web-site content etc.) to the Apache Software Foundation with 
> the intent of forming a productive, meritocratic and open community around 
> Palo’s continued development, according to the ‘Apache Way’.
> 
> Baidu owns several trademarks regarding Palo, and proposes to transfer 
> ownership of those trademarks in full to the ASF.
> 
> ###Overview of Palo
> 
> Palo’s implementation consists of two daemons: Frontend (FE) and Backend (BE).
> 
> **Frontend daemon** consists of query coordinator and catalog manager. Query 
> coordinator is responsible for receiving users’ sql queries, compiling 
> queries and managing queries execution. Catalog manager is responsible for 
> managing metadata such as databases, tables, partitions, replicas and etc. 
> Several frontend daemons could be deployed to guarantee fault-tolerance, and 
> load balancing.
> 
> **Backend daemon** stores the data and executes the query fragments. Many 
> backend daemons could also be deployed to provide scalability and 
> fault-tolerance.
> 
> A typical Palo cluster generally composes of several frontend daemons and 
> dozens to hundreds of backend daemons.
> 
> Users can use MySQL client tools to connect any frontend daemon to submit SQL 
> query. Frontend receives the query and compiles it into query plans 
> executable by the Backend. Then Frontend sends the query plan fragments to 
> Backend. Backend will build a query execution DAG. Data is fetched and 
> pipelined into the DAG. The final result response is sent to client via 
> Frontend. The distribution of query fragment execution takes minimizing data 
> movement and maximizing scan locality as the main goal.
> 
> ##Background
> 
> At Baidu, Prior to Palo, different tools were deployed to solve diverse 
> requirements in many ways. And when a use case requires the simultaneous 
> availability of capabilities that cannot all be provided by a single tool, 
> users were forced to build hybrid architectures that stitch multiple tools 
> together, but we believe that they shouldn’t need to accept such inherent 
> complexity. A storage system built to provide great performance across a 
> broad range of workloads provides a more elegant solution to the problems 
> that hybrid architectures aim to solve. Palo is the solution.
> 
> Palo is designed to be a simple and single tightly coupled system, not 
> depending on other systems. Palo provides high concurrent low latency point 
> query performance, but also provides high throughput queries of ad-hoc 
> analysis. Palo provides bulk-batch data loading, but also provides near 
> real-time mini-batch data loading. Palo also provides high availability, 
> reliability, fault tolerance, and scalability.
> 
> ##Rationale
> 
> Palo mainly integrates the technology of Google Mesa and Apache Impala.
> 
> Mesa is a highly scalable analytic data storage system that stores critical 
> measurement data related to Google's Internet advertising business. Mesa is 
> designed to satisfy complex and challenging set of users’ and systems’ 
> requirements, including near real-time data ingestion and query ability, as 
> well as high availability, reliability, fault tolerance, and scalability for 
> large data and query volumes.
> 
> Impala is a modern, open-source MPP SQL engine architected from the ground up 
> for the Hadoop data processing environment. At present, by virtue of its 
> superior performance and rich functionality， Impala has been comparable to 
> many commercial MPP database query engine. Mesa can satisfy the needs of many 
> of our storage requirements, however Mesa itself does not provide a SQL query 
> engine; Impala is a very good MPP SQL query engine, but the lack o

Looking for Champion

[Li,De(BDG)]

Hi all,

I am Reed, as a developer worked with the team for Palo (a MPP-based 
interactive SQL data warehousing).
https://github.com/baidu/palo/wiki/Palo-Overview

We propose to contribute Palo as an Apache Incubator project, and
we are still looking for possible Champion if anyone would like to volunteer. 
Thanks a lot.

Best Regards,
Reed

===
The draft of the proposal as below:

#Apache Palo

##Abstract

Palo is a MPP-based interactive SQL data warehousing for reporting and analysis.

##Proposal

We propose to contribute the Palo codebase and associated artifacts (e.g. 
documentation, web-site content etc.) to the Apache Software Foundation with 
the intent of forming a productive, meritocratic and open community around 
Palo’s continued development, according to the ‘Apache Way’.

Baidu owns several trademarks regarding Palo, and proposes to transfer 
ownership of those trademarks in full to the ASF.

###Overview of Palo

Palo’s implementation consists of two daemons: Frontend (FE) and Backend (BE).

**Frontend daemon** consists of query coordinator and catalog manager. Query 
coordinator is responsible for receiving users’ sql queries, compiling queries 
and managing queries execution. Catalog manager is responsible for managing 
metadata such as databases, tables, partitions, replicas and etc. Several 
frontend daemons could be deployed to guarantee fault-tolerance, and load 
balancing.

**Backend daemon** stores the data and executes the query fragments. Many 
backend daemons could also be deployed to provide scalability and 
fault-tolerance.

A typical Palo cluster generally composes of several frontend daemons and 
dozens to hundreds of backend daemons.

Users can use MySQL client tools to connect any frontend daemon to submit SQL 
query. Frontend receives the query and compiles it into query plans executable 
by the Backend. Then Frontend sends the query plan fragments to Backend. 
Backend will build a query execution DAG. Data is fetched and pipelined into 
the DAG. The final result response is sent to client via Frontend. The 
distribution of query fragment execution takes minimizing data movement and 
maximizing scan locality as the main goal.

##Background

At Baidu, Prior to Palo, different tools were deployed to solve diverse 
requirements in many ways. And when a use case requires the simultaneous 
availability of capabilities that cannot all be provided by a single tool, 
users were forced to build hybrid architectures that stitch multiple tools 
together, but we believe that they shouldn’t need to accept such inherent 
complexity. A storage system built to provide great performance across a broad 
range of workloads provides a more elegant solution to the problems that hybrid 
architectures aim to solve. Palo is the solution.

Palo is designed to be a simple and single tightly coupled system, not 
depending on other systems. Palo provides high concurrent low latency point 
query performance, but also provides high throughput queries of ad-hoc 
analysis. Palo provides bulk-batch data loading, but also provides near 
real-time mini-batch data loading. Palo also provides high availability, 
reliability, fault tolerance, and scalability.

##Rationale

Palo mainly integrates the technology of Google Mesa and Apache Impala.

Mesa is a highly scalable analytic data storage system that stores critical 
measurement data related to Google's Internet advertising business. Mesa is 
designed to satisfy complex and challenging set of users’ and systems’ 
requirements, including near real-time data ingestion and query ability, as 
well as high availability, reliability, fault tolerance, and scalability for 
large data and query volumes.

Impala is a modern, open-source MPP SQL engine architected from the ground up 
for the Hadoop data processing environment. At present, by virtue of its 
superior performance and rich functionality， Impala has been comparable to many 
commercial MPP database query engine. Mesa can satisfy the needs of many of our 
storage requirements, however Mesa itself does not provide a SQL query engine; 
Impala is a very good MPP SQL query engine, but the lack of a perfect 
distributed storage engine. So in the end we chose the combination of these two 
technologies.

Learning from Mesa’s data model, we developed a distributed storage engine. 
Unlike Mesa, this storage engine does not rely on any distributed file system. 
Then we deeply integrate this storage engine with Impala query engine. Query 
compiling, query execution coordination and catalog management of storage 
engine are integrated to be frontend daemon; query execution and data storage 
are integrated to be backend daemon. With this integration, we implemented a 
single, full-featured, high performance state the art of MPP database, as well 
as maintaining the simplicity.

##Current Status

Palo has been an open source project on GitHub (https://github.com/baidu/palo).

###Meritocracy

Palo has been

Re: Jt Pattern Oriented Framework (looking for champion/mentors)

[David S]

Hi folks,

I've updated the proposal with names:

http://wiki.apache.org/incubator/JtPatternFrameworkProposal

I'll need to update the page again since a couple of people joined the project 
recently.

Regards,

Edgar

P.S. Jt 2.7 has been released.


Jt Proposal 
Project Name: Jt Pattern Oriented Framework 

 

Introduction

This proposal describes a Pattern Oriented Framework for the rapid
implementation of Java applications. This integrated framework is based
on a messaging architecture which provides strong encapsulation and
loose coupling; framework components can be interchangeably plugged
into complex framework applications using a “Lego approach. This
framework provides capabilities for the implementation of applications
based on design patterns. The framework itself is conceived, from the
ground up, based on design patterns. Jt is probably one of the first
Pattern Oriented Frameworks (open source). 

Goals

The framework addresses the following goals: 
A) The pattern oriented framework implements and/or facilitates the
implementation of well-known design patterns like Gang Of Four design
patterns (GoF) and J2EE Design patterns. The framework itself is
conceived and implemented based on design patterns (from the ground
up). The framework also facilitates and accelerates the implementation
of applications based on design patterns. 
b) The framework architecture is based on a messaging design
pattern: framework objects are able to interchange information and
perform computations by sending, receiving and processing messages. A
messaging API provides strong encapsulation and loose coupling;
framework components can be interchangeably plugged into complex
framework applications using a “lego/messaging” architecture. The
framework takes full advantage of the power and simplicity of the
messaging design pattern/API. 
C) The framework lego/messaging architecture provides transparent
access to remote components: remote framework objects are treated as
local objects. Design patterns implemented by the framework (adapters,
remote proxies and facades) make this possible by hiding the
complexities associated with remote APIs. 
D) The framework provides transparent integration with other
technologies via framework adapters, proxies and the implementation of
related design patterns. These technologies include BPM, Data Access
Object implementations (DAO), Model View Controller implementations
(MVC), EJBs, AJAX, JMS, XML and Web Services. 
E) The framework is designed to be lightweight and fast (low overhead/small 
footprint). 
F) The framework messaging/lego architecture should improve and
simplify design/development efforts. There should be a tight
correspondence between UML design diagrams and the framework messaging
based applications and components needed for the implementation. The
framework should provide wizards and automated capabilities for
generating framework applications. Framework components should be
easily added to BPM process diagrams. In future versions of the
framework, it should be possible for application modules to be
generated directly from the UML design diagrams. This goal is still
work in progress. There is an early version of the Jt Wizard. 
G) The framework messaging architecture facilitates testing and
debugging efforts. It provides capabilities for testing components as
independent units by sending messages to the component and verifying
the expected reply messages. 
H) In order to provide additional productivity, the framework has been 
integrated with open source IDEs. 

Main Features

- Implemented J2EE design patterns include J2EE business delegate,
J2EE Session Facade, J2EE Service Locator and J2EE Value Object. 
- Web Services integration via the implementation of Web Services
adapters and proxies. The Jt messaging API greatly simplifies the
development and deployment of web services. 
- Integration with the MVC (Model View Controller) design pattern
and Ajax. Universal Jt components and adapters provide a transparent
interface between the Jt framework API and these technologies. The
business logic (controller piece) can be implemented using Jt framework
components and/or BPM business processes. 
- Integration with J2EE Enterprise Java Beans (EJBs) via Jt Adapters
and proxies. EJB clients are able to gain transparent access to remote
framework objects. No need to deal with the complexities of EJB
application development. An implementation of the J2EE Service Locator
pattern is also provided. 
- Easy customization of framework applications. This is done via
resource files: object attributes can be automatically loaded from a
resource file. 
- Integration with the XML APIs via XML adapters, helpers and built-in bean/XML 
mapping capabilities. 
- Built-in logging/debugging capabilities. Messages between
framework objects are automatically logged. This simplifies the
debugging and testing tasks. 
- Built-in  testing capabilities. 
- Efficient and lightweight in terms of memory 

Re: Jt Pattern Oriented Framework (looking for champion/mentors)

[David S]

I'll update the project proposal with names as soon as I get the chance. As 
explained in the proposal, we plan to move the project to a central location. 
Some of the internal project
info/documentation (email, etc) is scattered around. The main focus/goal has 
been completing the core functionality of the pattern oriented framework. 

Regards,

Ed

--- On Tue, 7/22/08, Roland Weber [EMAIL PROTECTED] wrote:
From: Roland Weber [EMAIL PROTECTED]
Subject: Re: Jt Pattern Oriented Framework (looking for champion/mentors)
To: general@incubator.apache.org
Date: Tuesday, July 22, 2008, 4:22 AM

David S (or rather Ed) wrote:
 
 Community
 
 One of the next objectives is to continue growing an active community of
 users and contributors. It is expected that community will continue to
grow.

So you already have an active community of users and contributors?
Any public record of that? Names and/or numbers?





  

RE: Jt Pattern Oriented Framework (looking for champion/mentors)

[David S]

Hi folks,

We've put together a draft proposal for the Jt pattern Oriented Framework. I 
hope it
answers some of the questions regarding project status, community, licensing, 
etc.


Regards,

Ed



Jt Pattern Oriented Framework 



Introduction

This proposal describes a Pattern Oriented Framework for the rapid 
implementation
of Java applications. This integrated framework is based on a messaging 
architecture
which provides strong encapsulation and loose coupling; framework components 
can be 
interchangeably plugged into complex framework applications using a “Lego 
approach. 
This framework provides capabilities for the implementation of applications 
based on design patterns. The framework itself is conceived, from the ground 
up, 
based on design patterns. Jt is probably one of the first Pattern Oriented 
Frameworks
(open source).


Goals


The framework addresses the following goals:


A) The pattern oriented framework implements and/or facilitates the 
implementation of 
well-known design patterns like Gang Of Four design patterns (GoF) and J2EE 
Design patterns. The framework itself  is conceived and implemented based on 
design patterns (from the ground up). The framework also facilitates and 
accelerates the implementation of applications based on design patterns.

B) The framework architecture is based on a messaging design pattern: framework 
objects 
are able to interchange information and perform computations by sending, 
receiving and 
processing messages. A messaging API provides strong encapsulation and loose 
coupling;
framework components can be interchangeably plugged into complex framework 
applications using a “lego/messaging” architecture. The framework takes full 
advantage of the power and simplicity of the messaging design pattern/API.

C) The framework lego/messaging architecture provides transparent access to 
remote components: remote framework objects are treated as local objects. 
Design patterns implemented by the framework (adapters, remote proxies and 
facades) make this possible by hiding the complexities associated with remote 
APIs. 

D) The framework provides transparent integration with other technologies via 
framework 
adapters, proxies and the implementation of related design patterns. These 
technologies include BPM,  Data Access Object implementations (DAO), Model View 
Controller implementations (MVC), EJBs, AJAX, JMS, XML and Web Services.  

E) The framework is designed to be lightweight and fast (low overhead/small 
footprint).

F) The framework messaging/lego architecture should improve and simplify 
design/development efforts. There should be a tight correspondence between UML 
design diagrams and the framework messaging based  applications and components 
needed for the implementation. The framework should provide wizards and 
automated capabilities for generating framework applications. Framework 
components should be easily added to BPM process diagrams. In future versions 
of the framework, it should 
be possible for application modules to be generated directly from the UML 
design diagrams.
This goal is still work in progress. There is an early version of the Jt 
Wizard.  

G) The framework  messaging architecture facilitates testing and debugging 
efforts. 
It provides capabilities for testing components as independent units by 
sending messages to the component and verifying the expected reply messages..
 
H) In order to provide additional productivity, the framework has been 
integrated 
with open source IDEs.

Criteria

Current Status

The current release of the framework (2.6) meets most of the goals outlined 
above.
Item F is still work in progress. The software base is very stable (production 
quality). 
Several production applications have been built based on the Jt framework. 
Documentation, reference framework applications and examples are available.


Meritocracy

Meritocracy will be fostered and encouraged within the project. We will follow 
the guidelines of the Apache Software Foundation. Community contributions and 
feedback are always welcome.We also plan to actively encourage individuals to 
get involved in the project and be
recognized based on Merit.


Community

One of the next objectives is to continue growing an active community of users 
and contributors. It is expected that community will continue to grow. So far 
the main focus has been the completion of the core framework functionality. We 
see Jt becoming an ASF incubator project as a next step in its evolution. We 
plan to open the project to a wider audience in order to achieve a larger and 
more diverse community.



Alignment

Jt is aligned well with existing Apache projects and technologies. The framework
has been integrated with several Apache technologies including Struts (MVC 
design pattern) and Axis (Web Services Adapter). The Jt automated Wizard 
capabilities has also been built based on Apache products.



Known Risks

Orphaned products: The projects has been 

Re: Jt Pattern Oriented Framework (looking for champion/mentors)

[Roland Weber]

David S (or rather Ed) wrote:


Community

One of the next objectives is to continue growing an active community of
users and contributors. It is expected that community will continue to grow.


So you already have an active community of users and contributors?
Any public record of that? Names and/or numbers?


Orphaned products: The projects has been growing as an open source project
for several years. The team is committed to continue this work therefore
the risk is fairly small.


Names or numbers on the team? Public records of the growing?
The CVS mails show no relevant activity before October 2007,
nor afterwards.


Homogenous developers: The people involved with the project work for
several  organizations who are geographically distributed across the world.


The only account used on the project site is wwwfswcom,
an obvious reference to a website that seems to belong to
a software consulting company.
Can you give some details on distributed across the world?
Number of people by country or continent, for example?


Reliance on salaried developers: This project does not rely
on salaried  contributors. They work on a volunteer basis.


Is the above mentioned software consulting company aware of
the fact that a diverse team of volunteers is indirectly
referencing its website when releasing open source software?

Project information and complete documentation/sources can be downloaded from 
http://jt.dev.java.net/. java.net forums and mailings lists are not used.


So which forums and/or mailing lists do you use?
As far as I can see you didn't use the CVS repo either,
except for index.html and one drop of code in October 2007.

cheers,
  Roland


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jt Pattern Oriented Framework (looking for champion/mentors)

[Niclas Hedhman]

On Fri, Jul 18, 2008 at 11:24 AM, David S [EMAIL PROTECTED] wrote:
 Hi Eelco,

 The project site contains mainly technical/download information. We haven't 
 been using it for anything else (mailing list, forums, etc).

Where then???

You will soon notice that we care more about the community, then
probably licensing difficulties and lastly the codebase itself.


Also, *I* am particularly concerned over David S sending mail,
'signed' Edgar...


Cheers
Niclas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jt Pattern Oriented Framework (looking for champion/mentors)

[Roland Weber]

a cursory assessment...

License currently is LGPL.
CVS history goes back to August 2006.
All commits by wwwfswcom.
Not a single message on the dev list.
Not a single posting in the forum.

Looks like a case of open source, closed development.
On the plus side, changing the license shouldn't be
a problem.

cheers,
  Roland

https://jt.dev.java.net/servlets/ProjectMailingListList
https://jt.dev.java.net/servlets/SummarizeList?listName=cvsby=author
https://jt.dev.java.net/servlets/SummarizeList?listName=dev
https://jt.dev.java.net/servlets/ProjectForumView



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jt Pattern Oriented Framework (looking for champion/mentors)

[Eelco Hillenius]

Hi Ed,

Judging from http://jt.dev.java.net/, there is one active person on
the project, and now discussion or other signs of community
whatshowever. Wouldn't it be a good idea to start building up a
community on that site first?

Regards,

Eelco


On Wed, Jul 16, 2008 at 8:19 PM, David S [EMAIL PROTECTED] wrote:

 Hi folks,

 Our project (Jt Pattern Oriented Framework) is interested in joining the ASF 
 incubator.

 After getting familiar with the incubator policies and procedures, we are 
 looking for people interested in becoming a champion or a mentor.  We hope to 
 learn more about ASF and pursue the proposal process.

 Additional information about this Open Source project can be found at 
 http://jt.dev.java.net/

 The framework should address the following goals:

 A) The pattern oriented framework should implement and/or facilitate the 
 implementation of well-known design patterns like GoF design patterns and 
 J2EE Design patterns. The framework itself should be conceived and 
 implemented based on design patterns (from the ground up). The framework 
 should also facilitate and accelerate the implementation of applications 
 based on design patterns.
 B) The framework architecture should be based on a messaging design pattern: 
 framework objects should be able to interchange information and perform 
 computations by sending, receiving and processing messages. A messaging API 
 provides strong encapsulation and loose coupling; framework components can be 
 easily plugged into complex framework applications using a lego/messaging 
 architecture. The framework should take full advantage of the power and 
 simplicity of the messaging design pattern.
 C) The framework lego/messaging architecture should provide transparent 
 access to remote components: remote framework objects should be treated as 
 local objects. Design patterns implemented by the framework (adapters, remote 
 proxies and facades) should make this posible by hiding the complexities 
 associated with remote APIs.
 D) The framework should provide transparent integration with other 
 technologies via framework adapters, proxies and the implementation of 
 related design patterns. These technologies include BPM, DAO implementations, 
 MVC implementations, EJBs, JMS, XML and Web Services.
 E) The framework should be designed to be lightweight and fast in terms of 
 performance (low overhead).
 F) The framework messaging/lego architecture should improve and simplify 
 design/development efforts. There should be a tight correspondence between 
 UML design diagrams and the framework messaging based applications and 
 components needed for the implementation. Ideally, the framework should 
 provide wizards and automated capabilities for generating framework 
 applications. Framework components should be easily added to BPM process 
 diagrams. In future versions of the framework, it should be possible for 
 applications to be generated directly from the UML design diagrams.
 G) The framework messaging architecture should facilitate testing and 
 debugging efforts. The framework should provide capabilities for testing 
 components independently (each component as a unit) by sending messages and 
 verifying the reply (output) messages.
 H) In order to provide additional productivity benefits, the framework should 
 be integrated with open source IDEs.

 Thanks in advance for your feedback and suggestions.  I look forward to 
 hearing from you.

 Ed




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jt Pattern Oriented Framework (looking for champion/mentors)

[David S]

Hi Eelco,

The project site contains mainly technical/download information. We haven't 
been using it for anything else (mailing list, forums, etc). We believe the 
Apache incubator would be a better venue for building community. Everyone 
interested in contributing is welcome. On the other hand the framework is 
probably one of the few pattern oriented frameworks (especially open source). 
The framework (version 2.6) has also been used as part of several production 
applications.

Regards,

Edgar

--- On Thu, 7/17/08, Eelco Hillenius [EMAIL PROTECTED] wrote:
From: Eelco Hillenius [EMAIL PROTECTED]
Subject: Re: Jt Pattern Oriented Framework (looking for champion/mentors)
To: general@incubator.apache.org
Date: Thursday, July 17, 2008, 7:41 AM

Hi Ed,

Judging from http://jt.dev.java.net/, there is one active person on
the project, and now discussion or other signs of community
whatshowever. Wouldn't it be a good idea to start building up a
community on that site first?

Regards,

Eelco


On Wed, Jul 16, 2008 at 8:19 PM, David S [EMAIL PROTECTED] wrote:

 Hi folks,

 Our project (Jt Pattern Oriented Framework) is interested in joining the
ASF incubator.

 After getting familiar with the incubator policies and procedures, we are
looking for people interested in becoming a champion or a mentor.  We hope to
learn more about ASF and pursue the proposal process.

 Additional information about this Open Source project can be found at
http://jt.dev.java.net/

 The framework should address the following goals:

 A) The pattern oriented framework should implement and/or facilitate the
implementation of well-known design patterns like GoF design patterns and J2EE
Design patterns. The framework itself should be conceived and implemented based
on design patterns (from the ground up). The framework should also facilitate
and accelerate the implementation of applications based on design patterns.
 B) The framework architecture should be based on a messaging design
pattern: framework objects should be able to interchange information and
perform computations by sending, receiving and processing messages. A messaging
API provides strong encapsulation and loose coupling; framework components can
be easily plugged into complex framework applications using a
lego/messaging architecture. The framework should take full
advantage of the power and simplicity of the messaging design pattern.
 C) The framework lego/messaging architecture should provide transparent
access to remote components: remote framework objects should be treated as
local objects. Design patterns implemented by the framework (adapters, remote
proxies and facades) should make this posible by hiding the complexities
associated with remote APIs.
 D) The framework should provide transparent integration with other
technologies via framework adapters, proxies and the implementation of related
design patterns. These technologies include BPM, DAO implementations, MVC
implementations, EJBs, JMS, XML and Web Services.
 E) The framework should be designed to be lightweight and fast in terms of
performance (low overhead).
 F) The framework messaging/lego architecture should improve and simplify
design/development efforts. There should be a tight correspondence between UML
design diagrams and the framework messaging based applications and components
needed for the implementation. Ideally, the framework should provide wizards
and automated capabilities for generating framework applications. Framework
components should be easily added to BPM process diagrams. In future versions
of the framework, it should be possible for applications to be generated
directly from the UML design diagrams.
 G) The framework messaging architecture should facilitate testing and
debugging efforts. The framework should provide capabilities for testing
components independently (each component as a unit) by sending messages and
verifying the reply (output) messages.
 H) In order to provide additional productivity benefits, the framework
should be integrated with open source IDEs.

 Thanks in advance for your feedback and suggestions.  I look forward to
hearing from you.

 Ed




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  

RE: Jt Pattern Oriented Framework (looking for champion/mentors)

[David S]

Noel,

We plan to prepare a preliminary proposal that should address many of these 
questions (technical state, membership, interfaces with other technologies, 
etc). I'll send it to the mailing list for discussion as soon as possible.. I 
can tell you that the current version of the framework meets many of the 
original design goals (should, will). It is a version 2.5 (fairly mature 
software base). Actually there are several production applications that have 
been built on top of  this pattern oriented framework.

We look forward to having this discussion.

Regards,

Edgar




--- On Thu, 7/17/08, Noel J. Bergman [EMAIL PROTECTED] wrote:
From: Noel J. Bergman [EMAIL PROTECTED]
Subject: RE: Jt Pattern Oriented Framework (looking for champion/mentors)
To: general@incubator.apache.org
Date: Thursday, July 17, 2008, 3:22 PM

David Sheppard wrote:

 Our project (Jt Pattern Oriented Framework [http://jt.dev.java.net/]) is
 interested in joining the ASF incubator.

 After getting familiar with the incubator policies and procedures, we are
 looking for people interested in becoming a champion or a mentor.  We hope
 to learn more about ASF and pursue the proposal process.

As you can see, several people have already taken a look at the project,
each from their own perspective.  I, for example, looked at it last night,
and wondered how it would tie into/relate with Ode, Tuscany, and other
similar/related ASF projects, given the emphasis on messaging, BPM, etc.

Can you tell us more about who is currently involved, and the current
technical state of the project (q.v. a number of the statements in the
proposal were phrased as will and should)?

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  

Jt Pattern Oriented Framework (looking for champion/mentors)

[David S]

Hi folks,

Our project (Jt Pattern Oriented Framework) is interested in joining the ASF 
incubator. 
 
After getting familiar with the incubator policies and procedures, we are 
looking for people interested in becoming a champion or a mentor.  We hope to 
learn more about ASF and pursue the proposal process.

Additional information about this Open Source project can be found at 
http://jt.dev.java.net/

The framework should address the following goals:

A) The pattern oriented framework should implement and/or facilitate the 
implementation of well-known design patterns like GoF design patterns and J2EE 
Design patterns. The framework itself should be conceived and implemented based 
on design patterns (from the ground up). The framework should also facilitate 
and accelerate the implementation of applications based on design patterns.
B) The framework architecture should be based on a messaging design pattern: 
framework objects should be able to interchange information and perform 
computations by sending, receiving and processing messages. A messaging API 
provides strong encapsulation and loose coupling; framework components can be 
easily plugged into complex framework applications using a “lego/messaging” 
architecture. The framework should take full advantage of the power and 
simplicity of the messaging design pattern.
C) The framework lego/messaging architecture should provide transparent access 
to remote components: remote framework objects should be treated as local 
objects. Design patterns implemented by the framework (adapters, remote proxies 
and facades) should make this posible by hiding the complexities associated 
with remote APIs. 
D) The framework should provide transparent integration with other technologies 
via framework adapters, proxies and the implementation of related design 
patterns. These technologies include BPM, DAO implementations, MVC 
implementations, EJBs, JMS, XML and Web Services. 
E) The framework should be designed to be lightweight and fast in terms of 
performance (low overhead).
F) The framework messaging/lego architecture should improve and simplify 
design/development efforts. There should be a tight correspondence between UML 
design diagrams and the framework messaging based applications and components 
needed for the implementation. Ideally, the framework should provide wizards 
and automated capabilities for generating framework applications. Framework 
components should be easily added to BPM process diagrams. In future versions 
of the framework, it should be possible for applications to be generated 
directly from the UML design diagrams. 
G) The framework messaging architecture should facilitate testing and debugging 
efforts. The framework should provide capabilities for testing components 
independently (each component as a unit) by sending messages and verifying the 
reply (output) messages. 
H) In order to provide additional productivity benefits, the framework should 
be integrated with open source IDEs.

Thanks in advance for your feedback and suggestions.  I look forward to hearing 
from you.

Ed