Re: [VOTE] Retire Gearpump podling

[Dave Fisher]

+1 retire

Sent from my iPhone

> On Sep 16, 2018, at 2:31 AM, Manu Zhang  wrote:
> 
> Hi mentors,
> 
> The Gearpump podling has voted to retire from incubation. Here are the
> relevant discussion and vote threads from the dev list. The vote passed
> unanimously with 6 +1s.
> 
> DISCUSS:
> https://lists.apache.org/thread.html/77946cfff4557cf10c13c2d35fc165223583e58c2f7705319acabcf4@%3Cdev.gearpump.apache.org%3E
> VOTE:
> https://lists.apache.org/thread.html/03fc0421bb425f79d623863335bc2b81e4b6c77a169f508aadce7785@%3Cdev.gearpump.apache.org%3E
> 
> Please vote to ratify this request for retirement. It will be open for at
> least 72 hours.
> 
> Thanks,
> Manu Zhang


-
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

[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, 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 

Re: [VOTE] Retire Gearpump podling

[Andrew Purtell]

+1


> On Sep 16, 2018, at 2:31 AM, Manu Zhang  wrote:
> 
> Hi mentors,
> 
> The Gearpump podling has voted to retire from incubation. Here are the
> relevant discussion and vote threads from the dev list. The vote passed
> unanimously with 6 +1s.
> 
> DISCUSS:
> https://lists.apache.org/thread.html/77946cfff4557cf10c13c2d35fc165223583e58c2f7705319acabcf4@%3Cdev.gearpump.apache.org%3E
> VOTE:
> https://lists.apache.org/thread.html/03fc0421bb425f79d623863335bc2b81e4b6c77a169f508aadce7785@%3Cdev.gearpump.apache.org%3E
> 
> Please vote to ratify this request for retirement. It will be open for at
> least 72 hours.
> 
> Thanks,
> Manu Zhang

-
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

[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
>>> 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, 

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.

 ## 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 

Re: Email to be sent to inactive mentors

[Justin Mclean]

Hi,

Current 1/3 of those asked have responded with:
-17 mentors have asked to retire/step down
- 3 will continue (including one who asked to step down but changed their mind 
and has been added back)

Of the total above 1 mentor was miss-identified as missing as they are mostly 
active in GitHub and not on the mailing list.

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

Re: Default project guidelines

[Justin Mclean]

Hi,

> Thank you for such a short and informative article. I'll definitely link to
> it from Apache Ignite wiki space.
> 
> What do you think about including a link to
> http://community.apache.org/newcommitter.html  This page also gives a good
> level of understanding what should and should not a potential committer or
> PMC do.

I was trying to link to other policy rather than guidelines, but that is a good 
explanation of the process, it does however suggest that voting is required for 
new committers (it’s normally done that way but it’s not mandated). I note it 
also uses consensual voting (ie 3 +1 votes with no vetos) which is a little 
unclear if this is the default. This discussion has come up a few time(s) but 
the official docs still need to be updated. e.g. [1]

> I've also don't understand how the process of committer removal connected
> with principles:
> - Meritocracy
> - Merit does not expire
> 
> How and when committer may be removed? Is it applicable to TLP projects?

Well hopefully very rarely or not at all, but there been a handful of cases 
where committer and PMC members have been removed. The majority of project 
bylaws / guidelines, created when a project becomes a TLP, do contain a way for 
it to happen. Some of them have incorrectly stated that the PMC can remove PMC 
members, when only the board can do that. That’s what started this whole thread.

But I think it is valid question should PMC actually be allowed to remove 
committers given merit shouldn’t expire?

Thanks,
Justin

1. 
https://lists.apache.org/thread.html/3c1a4887cc1b31bb85fcdbd0481d9f70895738740610aace15a7c9a3@1380595285@%3Cgeneral.incubator.apache.org%3E
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [ANNOUNCE] Apache OpenWhisk Wskdeploy (incubating) 0.9.8 released

[Henry Saputra]

Congrats!

On Fri, Sep 14, 2018, 12:01 PM Vincent S Hou  wrote:

> Hi everyone,
>
> We are pleased to announce that Apache OpenWhisk Wskdeploy (incubating)
> 0.9.8 are released.
>
> Apache OpenWhisk Wskdeploy is a utility to help you describe and deploy
> any part of the OpenWhisk programming model using a Manifest file written
> in YAML.
>
> The download links of the current release is available at:
> https://openwhisk.apache.org/downloads.html
>
> Vincent Hou
> On behalf of the OpenWhisk team
>
> =
> *DISCLAIMER*
> Apache OpenWhisk Wskdeploy(incubating) is an effort undergoing incubation
> at The
> Apache Software
> Foundation (ASF), sponsored by Incubator.
> Incubation is required of all newly accepted projects until a further
> review indicates that the infrastructure, communications, and decision
> making process have stabilized in a manner consistent with other successful
> ASF projects.
> While incubation status is not necessarily a reflection of the completeness
> or stability of the code, it does indicate that the project has yet to be
> fully endorsed by the ASF.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Retire Gearpump podling

[Suneel Marthi]

+1 to retire

Very sad to see this retire - initially conceived by the former Intel
Hadoop Engg core team back in the day

On Sun, Sep 16, 2018 at 5:45 PM Ted Dunning  wrote:

> +1 from here as well.
>
> Good luck to the project participants.
>
>
> On Sun, Sep 16, 2018, 16:32 John D. Ament  wrote:
>
> > +1 to retire
> >
> > Like all podlings, the source code will continue to be available in a
> read
> > only fashion, if others ever want to pick it back up or restart a podling
> > with the name.  Best of luck to all.
> >
> > On Sun, Sep 16, 2018 at 5:32 AM Manu Zhang 
> > wrote:
> >
> > > Hi mentors,
> > >
> > > The Gearpump podling has voted to retire from incubation. Here are the
> > > relevant discussion and vote threads from the dev list. The vote passed
> > > unanimously with 6 +1s.
> > >
> > > DISCUSS:
> > >
> > >
> >
> https://lists.apache.org/thread.html/77946cfff4557cf10c13c2d35fc165223583e58c2f7705319acabcf4@%3Cdev.gearpump.apache.org%3E
> > > VOTE:
> > >
> > >
> >
> https://lists.apache.org/thread.html/03fc0421bb425f79d623863335bc2b81e4b6c77a169f508aadce7785@%3Cdev.gearpump.apache.org%3E
> > >
> > > Please vote to ratify this request for retirement. It will be open for
> at
> > > least 72 hours.
> > >
> > > Thanks,
> > > Manu Zhang
> > >
> >
>

Re: [VOTE] Retire Gearpump podling

[Ted Dunning]

+1 from here as well.

Good luck to the project participants.


On Sun, Sep 16, 2018, 16:32 John D. Ament  wrote:

> +1 to retire
>
> Like all podlings, the source code will continue to be available in a read
> only fashion, if others ever want to pick it back up or restart a podling
> with the name.  Best of luck to all.
>
> On Sun, Sep 16, 2018 at 5:32 AM Manu Zhang 
> wrote:
>
> > Hi mentors,
> >
> > The Gearpump podling has voted to retire from incubation. Here are the
> > relevant discussion and vote threads from the dev list. The vote passed
> > unanimously with 6 +1s.
> >
> > DISCUSS:
> >
> >
> https://lists.apache.org/thread.html/77946cfff4557cf10c13c2d35fc165223583e58c2f7705319acabcf4@%3Cdev.gearpump.apache.org%3E
> > VOTE:
> >
> >
> https://lists.apache.org/thread.html/03fc0421bb425f79d623863335bc2b81e4b6c77a169f508aadce7785@%3Cdev.gearpump.apache.org%3E
> >
> > Please vote to ratify this request for retirement. It will be open for at
> > least 72 hours.
> >
> > Thanks,
> > Manu Zhang
> >
>

Re: [VOTE] Retire Gearpump podling

[John D. Ament]

+1 to retire

Like all podlings, the source code will continue to be available in a read
only fashion, if others ever want to pick it back up or restart a podling
with the name.  Best of luck to all.

On Sun, Sep 16, 2018 at 5:32 AM Manu Zhang  wrote:

> Hi mentors,
>
> The Gearpump podling has voted to retire from incubation. Here are the
> relevant discussion and vote threads from the dev list. The vote passed
> unanimously with 6 +1s.
>
> DISCUSS:
>
> https://lists.apache.org/thread.html/77946cfff4557cf10c13c2d35fc165223583e58c2f7705319acabcf4@%3Cdev.gearpump.apache.org%3E
> VOTE:
>
> https://lists.apache.org/thread.html/03fc0421bb425f79d623863335bc2b81e4b6c77a169f508aadce7785@%3Cdev.gearpump.apache.org%3E
>
> Please vote to ratify this request for retirement. It will be open for at
> least 72 hours.
>
> Thanks,
> Manu Zhang
>

Re: [VOTE] Retire Gearpump podling

[Jean-Baptiste Onofré]

+1 (binding)

As discussed on the gearpump mailing list, obviously, we don't have a
wide enough community to move forward on graduation.
I'm still thinking that Gearpump is really an interesting project, but
not enough traction around.

Regards
JB

On 16/09/2018 11:31, Manu Zhang wrote:
> Hi mentors,
> 
> The Gearpump podling has voted to retire from incubation. Here are the
> relevant discussion and vote threads from the dev list. The vote passed
> unanimously with 6 +1s.
> 
> DISCUSS:
> https://lists.apache.org/thread.html/77946cfff4557cf10c13c2d35fc165223583e58c2f7705319acabcf4@%3Cdev.gearpump.apache.org%3E
> VOTE:
> https://lists.apache.org/thread.html/03fc0421bb425f79d623863335bc2b81e4b6c77a169f508aadce7785@%3Cdev.gearpump.apache.org%3E
> 
> Please vote to ratify this request for retirement. It will be open for at
> least 72 hours.
> 
> Thanks,
> Manu Zhang
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

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

Re: Mentor capactity of the incubator

[Willem Jiang]

Hi

>From my podling experience,  it's really hard for a new podling
project to find a mentor by himself, so sometime new podling project
just ask help in the mailing list.
The warm hearted mentors who response the mail will be put put into
the podling proposal, and we never ask them about if they have time to
perform the duty of mentor.
Maybe we can setup a reminder email once the mentor is adding to the
podling project to let him know about the role, duties, and how much
time he need to put into the Podling project. In this way, we may
reduce the inactive mentor situations in the future.

But how much time do we need to spend for mentoring the project. From
my experience, there are some work for the project initial setup and
release mentoring, but other time,the mentor just need to keep an eye
on the project and response the question from Podling projects.  But
it could be different from project to project, so please add your
comments here.

BTW, it's hard for the podling project to ask for release checking as
there are only few IPMC members vote the release kit. If we talk about
the Mentor capacity, IMO we need to take this issue into
consideration.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sun, Sep 16, 2018 at 3:18 PM Justin Mclean  wrote:
>
> Hi,
>
> We have a large number of IPMC members (280+). I wondering if any IPMC 
> members could indicate if they have any capacity/free cycles and a 
> willingness for mentoring projects. It looks like we are going to have a 
> number of inactive mentors step down in the near future and we may end up 
> with some podlings only having one or two mentors. Three mentors seems to the 
> the number that works best.
>
> Of course I understand it may have to be the right sort of project, but I’m 
> just trying the gauge the current mentor capacity of the incubator, so if you 
> think you could be a mentor if the right project came along then please 
> indicate it here.
>
> For IPMC members who are unable to be a mentor I’m curious to know what the 
> reasons are, I’m sure that “not having the time" is probably the number one 
> reason, but are is there any thing else stopping member (in particular first 
> time ones) from coming forward and volunteering?
>
> The mentor capacity we have may in the future have an impact on if and how 
> often we accept new podlings. I'd hate to turn away podlings, but if we can’t 
> effectively mentor them I’m not sure what else we can do. anyone have any 
> ideas?
>
> For myself currently I could only realistically mentor one more project.
>
> 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: Mentor capactity of the incubator

[Gunnar Tapper]

I don't know if I have the status to help but the will is there.


Thanks,
Gunnar
 Original message From: Justin Mclean 
 Date: 9/16/18  2:18 AM  (GMT-06:00) To: 
general@incubator.apache.org Subject: Mentor capactity of the incubator 
Hi,

We have a large number of IPMC members (280+). I wondering if any IPMC members 
could indicate if they have any capacity/free cycles and a willingness for 
mentoring projects. It looks like we are going to have a number of inactive 
mentors step down in the near future and we may end up with some podlings only 
having one or two mentors. Three mentors seems to the the number that works 
best.

Of course I understand it may have to be the right sort of project, but I’m 
just trying the gauge the current mentor capacity of the incubator, so if you 
think you could be a mentor if the right project came along then please 
indicate it here.

For IPMC members who are unable to be a mentor I’m curious to know what the 
reasons are, I’m sure that “not having the time" is probably the number one 
reason, but are is there any thing else stopping member (in particular first 
time ones) from coming forward and volunteering?

The mentor capacity we have may in the future have an impact on if and how 
often we accept new podlings. I'd hate to turn away podlings, but if we can’t 
effectively mentor them I’m not sure what else we can do. anyone have any ideas?

For myself currently I could only realistically mentor one more project.

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

Re: Mentor capactity of the incubator

[Greg Stein]

On Sun, Sep 16, 2018 at 2:18 AM Justin Mclean 
wrote:
>...

> For IPMC members who are unable to be a mentor I’m curious to know what
> the reasons are, I’m sure that “not having the time" is probably the number
> one reason, but are is there any thing else stopping member (in particular
> first time ones) from coming forward and volunteering?
>

For myself, it is because I conflate my personal time into my job time,
working on Infra-related stuff. I've found that I cannot distinguish my ASF
time between the two aspects, so cannot reliably provide dedicated ASF time
to personal stuff.

I remain on the IPMC, however, because I *do* find that I can be responsive
to Incubator-related concerns. (and I do the same for other ASF projects;
responsive time, rather than allocated time)

Cheers,
-g

[VOTE] Retire Gearpump podling

[Manu Zhang]

Hi mentors,

The Gearpump podling has voted to retire from incubation. Here are the
relevant discussion and vote threads from the dev list. The vote passed
unanimously with 6 +1s.

DISCUSS:
https://lists.apache.org/thread.html/77946cfff4557cf10c13c2d35fc165223583e58c2f7705319acabcf4@%3Cdev.gearpump.apache.org%3E
VOTE:
https://lists.apache.org/thread.html/03fc0421bb425f79d623863335bc2b81e4b6c77a169f508aadce7785@%3Cdev.gearpump.apache.org%3E

Please vote to ratify this request for retirement. It will be open for at
least 72 hours.

Thanks,
Manu Zhang

Re: Default project guidelines

[Dmitriy Pavlov]

Hi Justin,

Thank you for such a short and informative article. I'll definitely link to
it from Apache Ignite wiki space.

What do you think about including a link to
http://community.apache.org/newcommitter.html  This page also gives a good
level of understanding what should and should not a potential committer or
PMC do.

I've also don't understand how the process of committer removal connected
with principles:
- Meritocracy
- Merit does not expire

How and when committer may be removed? Is it applicable to TLP projects?

Sincerely,
Dmitriy Pavlov

вс, 16 сент. 2018 г. в 10:20, Justin Mclean :

> Hi,
>
> [1] being this link
> https://wiki.apache.org/incubator/DefaultProjectGuidelines <
> https://wiki.apache.org/incubator/DefaultProjectGuidelines> sorry I
> forgot to add it in the last email.
>
> Thanks,
> Justin

Re: Default project guidelines

[Justin Mclean]

Hi,

[1] being this link https://wiki.apache.org/incubator/DefaultProjectGuidelines 
 sorry I forgot to 
add it in the last email.

Thanks,
Justin

Mentor capactity of the incubator

[Justin Mclean]

Hi,

We have a large number of IPMC members (280+). I wondering if any IPMC members 
could indicate if they have any capacity/free cycles and a willingness for 
mentoring projects. It looks like we are going to have a number of inactive 
mentors step down in the near future and we may end up with some podlings only 
having one or two mentors. Three mentors seems to the the number that works 
best.

Of course I understand it may have to be the right sort of project, but I’m 
just trying the gauge the current mentor capacity of the incubator, so if you 
think you could be a mentor if the right project came along then please 
indicate it here.

For IPMC members who are unable to be a mentor I’m curious to know what the 
reasons are, I’m sure that “not having the time" is probably the number one 
reason, but are is there any thing else stopping member (in particular first 
time ones) from coming forward and volunteering?

The mentor capacity we have may in the future have an impact on if and how 
often we accept new podlings. I'd hate to turn away podlings, but if we can’t 
effectively mentor them I’m not sure what else we can do. anyone have any ideas?

For myself currently I could only realistically mentor one more project.

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

Re: [RESULT][VOTE] Accept Zipkin into the Apache Incubator

[Justin Mclean]

Hi,

I notice one of the proposed mentors is not very active in other project they 
mentor. There may of course be a perfectly good reasons for this, and I assume 
it's not going to be an issue here, but I thought I’d point it out rather than 
it becoming a possible issue down the track.

Are all the mentors committed to performing their duties as described here? [1] 
You have four mentors so certainly have some wriggle room if ione of them for 
one reason or another is not able perform their duties.

Thanks,
Justin

1. https://incubator.apache.org/policy/roles_and_responsibilities.html#mentor 

Re: [RESULT][VOTE] Accept Marvin-AI into Apache Incubator

[Justin Mclean]

Hi,

I notice one of the proposed mentors is not very active in some of the other 
projects they mentor. There may of course be perfectly good reasons for this, 
(for instance one of those projects I know doesn’t have a lot activity going 
on), and assume it not going to be the case here. But I thought I’d point it 
out rather than it becoming a possible issue down the track.

Are all the mentors committed to performing their duties as described here? [1] 
A prodding can have still operate with only two mentors, but it’s seems that 
having three mentors are usually best.

Thanks,
Justin

1. https://incubator.apache.org/policy/roles_and_responsibilities.html#mentor