Re: [VOTE] Release Apache Kyuubi(Incubating) v1.6.1-incubating rc0

[Daniel Widdis]

For my own education, I dug into this particular LICENSE [1] which is not just 
plain GPL2, it is granted under the Universal FOSS License version 1.0 [2].

But it's still Category X despite this.

The question for this specific software is answered at [3] with suggestions for 
what to do instead.

[1] - https://repo1.maven.org/maven2/mysql/mysql-connector-java/8.0.30/LICENSE
[2] - https://oss.oracle.com/licenses/universal-foss-exception/ 
[3] - https://issues.apache.org/jira/browse/LEGAL-200

On 10/26/22, 9:28 PM, "Justin Mclean"  wrote:

Hi,

Sorry it’s -1 (binding) from me as the source file contains a Category X 
licensed jar.

I checked:
- incubating in name
- signatures and hashes are fine
- disclaimer exists
- license and notice files look good
- file have correct ASF headers
- source release including compiled code [1]
- did not try to compile

I also note that [1] is licensed under the GPLv2 license which is not 
allowed to be included in an ASF release.

Kind Regards,
Justin

1. 
./integration-tests/kyuubi-jdbc-it/src/test/resources/mysql/mysql-connector-java-8.0.30.jar
-
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: [VOTE] Accept StreamPark into the Apache Incubator

[Daniel Widdis]

A few additional comments here:

1. As Justin said, you can select which one you want to choose (and ALv2 is a 
good choice!). Some projects take extra measures to explicitly state which of 
the two options they elect.

2. The ALv2 + LGPL option is common, primarily to accommodate projects under 
GPLv2 which consider the additional patent terms of ALv2 incompatible.  The 
LGPL alternative is generally offered as an alternative to permit GPLv2 
projects to use the project as a dependency.

For those of us who want to make our libraries accessible to anyone, we're 
stuck with either MIT or dual ALv2/LGPL licensing.  Projects choosing to go 
ALv2 only are going to be incompatible to be used as a dependency with GPLv2 
projects.

On 8/29/22, 12:26 AM, "Justin Mclean"  wrote:

Hi,

> hi，In the process of sorting through all the X class dependencies, we 
found
> that many of them are dual protocol, for example
> 
> org.codehaus.jackson:jackson-xc is dual-licensed.
> 1) GNU Lesser General Public License (LGPL), Version 2.1
> 2) The Apache Software License, Version 2.0

Jackson looks to be dual licensed [1] so you can select which license of 
the two you want to use. (Hint you would select ALv2.). Not all code bases with 
multiple licenses work that way. In each case you'll need to look at them to 
see if they are dual licensed or if they contain code under both licenses.

Kind Regards,
Justin

1. https://github.com/codehaus/jackson
-
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: [IP CLEARANCE] Arrow Flight SQL JDBC Driver

[Daniel Widdis]

Thanks, that email link satisfies my curiosity and any hint of concerns.

On 7/18/22, 7:43 AM, "David Li"  wrote:

The contributors are all (sub)contractors of Dremio, who were retained to 
work on this project. I checked with the lead author (Kyle Porter) and he 
confirmed all IP is with Dremio, who filed the software grant - is that what 
we're looking to confirm? A CCLA was not filed with Apache, as we followed a 
similar process to a prior grant from Dremio [1]. Unless you mean the agreement 
between the contributors and Dremio?

[1]: https://lists.apache.org/thread/w3btsx6l8gf0ognds8b6bng1ng4ccg00

-David

On 2022/07/18 04:58:00 Daniel Widdis wrote:
> Thanks for the clarity, David.
> 
> Given the clear "commit trail" for individual committers and the ICLAs I 
don't see a problem there.   I think the only question that may need a bit more 
clarity is the relationship of Dremio to the contributions.  I know my own 
employer has boilerplate legal claims on any open source work I do using 
company equipment or during "working hours" but there is also a process to 
allow/approve contributions.  
> 
> Can you elaborate on any corporate relationship to the contributions and 
if there is a process for open source contributions, particularly if the 
contributors used corporate computers or labor, and whether this is addressed 
in the CCLA?
> 
> On 7/17/22, 8:15 PM, "David Li"  wrote:
> 
> Hello,
> 
> Sorry for some of the confusion here, I'll try to explain. (Apologies 
if this does not get linked back up correctly to the thread - Pony Mail does 
not let me login and the mailto: link generates a URL which is too long).
> 
> I did preemptively ask the contributors to add the Apache license 
boilerplate before final submission, so apologies for the confusion there. The 
original files as I recall either had the header or did not have any header. 
> 
> There was a short discussion on the Arrow dev@ list at [1] where we 
decided to go through the IP clearance process to make sure everything was 
clear, since when the PR was first submitted, it had been developed for a long 
time outside the community (with commits dating back to 2020, although the PR 
was submitted in 2022).
> 
> I believe Abner submitted an ICLA. I will re-confirm with the authors 
(I can't appear to view this information myself on the Apache side). 
> 
> [1]: https://lists.apache.org/thread/xytqttpov1d3q9mhd6nrlz7xkl7q5zjp
> 
> Hopefully this helps,
> David
> 
> 
> 
> -
> 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: [IP CLEARANCE] Arrow Flight SQL JDBC Driver

[Daniel Widdis]

Thanks for the clarity, David.

Given the clear "commit trail" for individual committers and the ICLAs I don't 
see a problem there.   I think the only question that may need a bit more 
clarity is the relationship of Dremio to the contributions.  I know my own 
employer has boilerplate legal claims on any open source work I do using 
company equipment or during "working hours" but there is also a process to 
allow/approve contributions.  

Can you elaborate on any corporate relationship to the contributions and if 
there is a process for open source contributions, particularly if the 
contributors used corporate computers or labor, and whether this is addressed 
in the CCLA?

On 7/17/22, 8:15 PM, "David Li"  wrote:

Hello,

Sorry for some of the confusion here, I'll try to explain. (Apologies if 
this does not get linked back up correctly to the thread - Pony Mail does not 
let me login and the mailto: link generates a URL which is too long).

I did preemptively ask the contributors to add the Apache license 
boilerplate before final submission, so apologies for the confusion there. The 
original files as I recall either had the header or did not have any header. 

There was a short discussion on the Arrow dev@ list at [1] where we decided 
to go through the IP clearance process to make sure everything was clear, since 
when the PR was first submitted, it had been developed for a long time outside 
the community (with commits dating back to 2020, although the PR was submitted 
in 2022).

I believe Abner submitted an ICLA. I will re-confirm with the authors (I 
can't appear to view this information myself on the Apache side). 

[1]: https://lists.apache.org/thread/xytqttpov1d3q9mhd6nrlz7xkl7q5zjp

Hopefully this helps,
David



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

Re: [IP CLEARANCE] Arrow Flight SQL JDBC Driver

[Daniel Widdis]

> > Isn't developing on a fork of the project and submitting a PR 
considered "developed inside the project”?  

> Sure, but then you usually don’t need a software grant.

Ah, but I do.  When submitting a PR to an ASF project (e.g., [1]) I have had to 
either submit an ICLA (which I have) or check a box in my PR that explicitly 
states that my contribution is AL2.0 licensed which is effectively a "grant" of 
permission, which you acknowledge:

> Why you may not claim it it exists. But the ASF doesn’t mind that as long 
as we have permission to use it under the Apache license and distribute it.

More to the point of this conversation, I included the project's license 
headers in my contribution, rather than including my own headers and waiting 
for the maintainers to review my ICLA.

> > The only difference here is that there were multiple contributors to 
that fork, and it is likely that some or all of them did so during working 
hours or using equipment by a company, which normally claims IP in such 
conditions; thus the explicit donation/grant.

> Right and that is usually sorted out by those people getting permission 
from their employers and signing ICLAs. Some employers may require CCLAs.

Neither you nor I know the internal Open Source contribution requirements of 
Dremio corporation, nor should we need to do so.  We simply need to evaluate 
whether Dremio, and the individuals involved, have granted ASF sufficient 
rights.   IMO the IP clearance status document [2] makes that clear, with 
appropriate due diligence to verify its contents.

> All I was saying that having ASF headers make checking IP difficult. 

In this case, "checking IP" is no more difficult than "checking IP" in any pull 
request, hundreds/thousands of which occur on ASF projects each year, and none 
of which require a separate license header before the PR is reviewed, and all 
of which include the project's standard headers.

All I am trying to do is point out that the contribution was coordinated with 
the PMC before it even started (with company representation on the PMC), with 
the apparent intention of donation throughout, with the majority of changes in 
already ASF-licensed files and the project's standard header added to any new 
files.  This does not look like a product developed separately and eventually 
donated; this looks like an intentional open source contribution before a 
single line of code was written, and a nice paper-trail to back it up.

I certainly support due diligence to confirm an ICLA from each contributor and 
a CCLA from the company which likely paid these developers for their work.  I 
don't think headers matter much here.


[1] - https://github.com/apache/maven-compiler-plugin/pull/95/files 
[2] - 
https://incubator.apache.org/ip-clearance/arrow-flight-sql-jdbc-driver.html 



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

Re: [IP CLEARANCE] Arrow Flight SQL JDBC Driver

[Daniel Widdis]

Isn't developing on a fork of the project and submitting a PR considered 
"developed inside the project"?  

When I contribute to Apache projects, I fork the project, write code using the 
project's headers, and submit a PR from my fork.  I never claim copyright as my 
own or use my own header.  This is exactly what happened here.

The only difference here is that there were multiple contributors to that fork, 
and it is likely that some or all of them did so during working hours or using 
equipment by a company, which normally claims IP in such conditions; thus the 
explicit donation/grant.

What headers do you propose they should have used instead on (1) code they 
altered that already carried the ASF header, and (2) new files they created?

On 7/16/22, 4:30 PM, "Justin Mclean"  wrote:

Hi,

Which is an issue as the header has "Licensed to the Apache Software 
Foundation (ASF) under one or more contributor license agreements”. That is not 
really the case yet. Normally wth a software grant you replace the headers and 
move the original copyright line to the NOTICE file. I'm curious why was this 
not developed inside the project?

Kind Regards,
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: [IP CLEARANCE] Arrow Flight SQL JDBC Driver

[Daniel Widdis]

To elaborate and be more specific, the proposal identifies this fork [5] as the 
"source".  [6] is an exhaustive list of the 1491 commits involved, constituting 
the donated IP.  A spot check of commits with "license header" in the 
description shows ASF headers were used and there does not appear to have ever 
been any different headers.

[5] - https://github.com/rafael-telles/arrow/tree/flight-jdbc-driver 
[6] - 
https://github.com/apache/arrow/compare/master...rafael-telles:arrow:flight-jdbc-driver
 

On 7/16/22, 11:13 AM, "Daniel Widdis"  wrote:

Based on this blog post [1] it appears that the entire development was done 
in a sequence of draft PRs on the Arrow site (and on a fork), with the 
intention of donating it, and using ASF headers.

Proposal: [2]
Initial POC work: [3]
Experimental version: [4]

[1] - 
https://www.dremio.com/subsurface/arrow-flight-sql-a-universal-jdbc-driver/ 
[2] - 
https://docs.google.com/document/d/1WQz32bDF06GgMdEYyzhakqUigBZkALFwDF2y1x3DTAI/
 
[3] - https://github.com/apache/arrow/pull/9368 
[4] - https://github.com/apache/arrow/pull/10906

On 7/16/22, 7:47 AM, "Justin Mclean"  wrote:

Hi,

What were the original headers on the files and/or where did the 
original code come from? The code pointed to has ASF headers which make 
determining the origin a little difficult.

Kind Regards,.
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: [IP CLEARANCE] Arrow Flight SQL JDBC Driver

[Daniel Widdis]

Based on this blog post [1] it appears that the entire development was done in 
a sequence of draft PRs on the Arrow site (and on a fork), with the intention 
of donating it, and using ASF headers.

Proposal: [2]
Initial POC work: [3]
Experimental version: [4]

[1] - 
https://www.dremio.com/subsurface/arrow-flight-sql-a-universal-jdbc-driver/ 
[2] - 
https://docs.google.com/document/d/1WQz32bDF06GgMdEYyzhakqUigBZkALFwDF2y1x3DTAI/
 
[3] - https://github.com/apache/arrow/pull/9368 
[4] - https://github.com/apache/arrow/pull/10906

On 7/16/22, 7:47 AM, "Justin Mclean"  wrote:

Hi,

What were the original headers on the files and/or where did the original 
code come from? The code pointed to has ASF headers which make determining the 
origin a little difficult.

Kind Regards,.
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: [DISCUSSION] Incubating Proposal of Uniffle

[Daniel Widdis]

This was stated in the other thread: Unified/Universal Shuffle

On 5/24/22, 10:04 PM, "XiaoYu"  wrote:

Hi

Uniffle  as a project name， What does he mean~

thanks

Weiwei Yang  于2022年5月25日周三 12:57写道：
>
> +1 (binding)
> Good luck!
>
> On Tue, May 24, 2022 at 8:49 PM Ye Xianjin  wrote:
>
> > +1 (non-binding).
> >
> > Sent from my iPhone
> >
> > > On May 25, 2022, at 9:59 AM, Goson zhang  
wrote:
> > >
> > > +1 (non-binding)
> > >
> > > Good luck!
> > >
> > > Daniel Widdis  于2022年5月25日周三 09:53写道：
> > >
> > >> +1 (non-binding) from me!  Good luck!
> > >>
> > >> On 5/24/22, 9:05 AM, "Jerry Shao"  wrote:
> > >>
> > >>Hi all,
> > >>
> > >>Due to the name issue in thread (
> > >>https://lists.apache.org/thread/y07xjkqzvpchncym9zr1hgm3c4l4ql0f),
> > we
> > >>figured out a new project name "Uniffle" and created a new Thread.
> > >> Please
> > >>help to discuss.
> > >>
> > >>We would like to propose Uniffle[1] as a new Apache incubator
> > project,
> > >> you
> > >>can find the proposal here [2] for more details.
> > >>
> > >>Uniffle is a high performance, general purpose Remote Shuffle 
Service
> > >> for
> > >>distributed compute engines like Apache Spark
> > >><https://spark.apache.org/>, Apache
> > >>Hadoop MapReduce <https://hadoop.apache.org/>, Apache Flink
> > >><https://flink.apache.org/> and so on. We are aiming to make
> > >> Firestorm a
> > >>universal shuffle service for distributed compute engines.
> > >>
> > >>Shuffle is the key part for a distributed compute engine to 
exchange
> > >> the
> > >>data between distributed tasks, the performance and stability of
> > >> shuffle
> > >>will directly affect the whole job. Current “local file pull-like
> > >> shuffle
> > >>style” has several limitations:
> > >>
> > >>   1. Current shuffle is hard to support super large workloads,
> > >> especially
> > >>   in a high load environment, the major problem is IO problem
> > (random
> > >> disk IO
> > >>   issue, network congestion and timeout).
> > >>   2. Current shuffle is hard to deploy on the disaggregated 
compute
> > >>   storage environment, as disk capacity is quite limited on 
compute
> > >> nodes.
> > >>   3. The constraint of storing shuffle data locally makes it 
hard to
> > >> scale
> > >>   elastically.
> > >>
> > >>Remote Shuffle Service is the key technology for enterprises to 
build
> > >> big
> > >>data platforms, to expand big data applications to disaggregated,
> > >>online-offline hybrid environments, and to solve above problems.
> > >>
> > >>The implementation of Remote Shuffle Service -  “Uniffle”  - is
> > heavily
> > >>adopted in Tencent, and shows its advantages in production. Other
> > >>enterprises also adopted or prepared to adopt Firestorm in their
> > >>environments.
> > >>
> > >>Uniffle's key idea is brought from Salfish shuffle
> > >><
> > >>
> > 
https://www.researchgate.net/publication/262241541_Sailfish_a_framework_for_large_scale_data_processing
> > >>> ,
> > >>it has several key design goals:
> > >>
> > >>   1. High performance. Firestorm’s performance is close enough to
> > >> local
> > >>   file based shuffle style for small workloads. For large 
workloads,
> > >> it is
> > >>   far better than the current shuffle style.
> > >>   2. Fault tolerance. Firestorm provides high availability for
> > >> Coordinated
> > >>   nodes, and failover for Shuffle node

Re: [DISCUSSION] Incubating Proposal of Uniffle

[Daniel Widdis]

+1 (non-binding) from me!  Good luck!

On 5/24/22, 9:05 AM, "Jerry Shao"  wrote:

Hi all,

Due to the name issue in thread (
https://lists.apache.org/thread/y07xjkqzvpchncym9zr1hgm3c4l4ql0f), we
figured out a new project name "Uniffle" and created a new Thread. Please
help to discuss.

We would like to propose Uniffle[1] as a new Apache incubator project, you
can find the proposal here [2] for more details.

Uniffle is a high performance, general purpose Remote Shuffle Service for
distributed compute engines like Apache Spark
, Apache
Hadoop MapReduce , Apache Flink
 and so on. We are aiming to make Firestorm a
universal shuffle service for distributed compute engines.

Shuffle is the key part for a distributed compute engine to exchange the
data between distributed tasks, the performance and stability of shuffle
will directly affect the whole job. Current “local file pull-like shuffle
style” has several limitations:

   1. Current shuffle is hard to support super large workloads, especially
   in a high load environment, the major problem is IO problem (random disk 
IO
   issue, network congestion and timeout).
   2. Current shuffle is hard to deploy on the disaggregated compute
   storage environment, as disk capacity is quite limited on compute nodes.
   3. The constraint of storing shuffle data locally makes it hard to scale
   elastically.

Remote Shuffle Service is the key technology for enterprises to build big
data platforms, to expand big data applications to disaggregated,
online-offline hybrid environments, and to solve above problems.

The implementation of Remote Shuffle Service -  “Uniffle”  - is heavily
adopted in Tencent, and shows its advantages in production. Other
enterprises also adopted or prepared to adopt Firestorm in their
environments.

Uniffle's key idea is brought from Salfish shuffle

,
it has several key design goals:

   1. High performance. Firestorm’s performance is close enough to local
   file based shuffle style for small workloads. For large workloads, it is
   far better than the current shuffle style.
   2. Fault tolerance. Firestorm provides high availability for Coordinated
   nodes, and failover for Shuffle nodes.
   3. Pluggable. Firestorm is highly pluggable, which could be suited to
   different compute engines, different backend storages, and different
   wire-protocols.

We believe that Uniffle project will provide the great value for the
community if it is accepted by the Apache incubator.

I will help this project as champion and many thanks to the 3 mentors:

   -

   Felix Cheung (felixche...@apache.org)
   - Junping du (junping...@apache.org)
   - Weiwei Yang (w...@apache.org)
   - Xun liu (liu...@apache.org)
   - Zhankun Tang (zt...@apache.org)


[1] https://github.com/Tencent/Firestorm
[2] https://cwiki.apache.org/confluence/display/INCUBATOR/UniffleProposal

Best regards,
Jerry



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

Re: [DISCUSSION] Incubating Proposal of Firestorm

[Daniel Widdis]

Adding onto this, even if there may be no legal trademark issue, there is other 
software by this name which makes it less than desirable.  Quoted from [1]

> Avoiding search-results confusion is important for another reason. Apache 
> projects are often very quickly highly ranked. An Apache project with a 
> similar name to another application in the same technical space may quickly 
> come to dominate searches in that space. If someone else holds a related 
> trademark, this may lead to a legal dispute. As a non-profit organization, 
> the ASF and Apache projects have no business conflicting with an existing 
> trademark for software products or related services.

A current search for "firestorm software" reveals multiple sites related to 
[2]. Searching "firestorm download" links to [3].  Searching "apache firestorm" 
links to sites providing parts for remote control model cars, of which two 
models compatible with such parts are "Apache" and "Firestorm" [4].

1 - https://infra.apache.org/project-names.html 
2 - https://www.zotac.com/us/page/firestorm 
3 - https://www.firestormviewer.org/choose-your-platform/ 
4 - https://www.competitionx.com/hpi-racing-manuals/ 

Not my call, I am not a lawyer and have no binding votes on the incubator, just 
adding my observations.

On 5/22/22, 8:04 PM, "Justin Mclean"  wrote:

HI,

> According to the trademarks@ current cursory feedback, looks like project
> name "Firestorm" is OK.

I don’t this that is the case. Trademark checked “FlameStorm”, and said 
that if Firestorm was as issue then FlameStorm would also be an issue. I don’t 
believe they have checked FireStorm.

Please don’t under estimate the cost of a project name change, I seen 
several project go through this and it it is always much more effort than you 
realise. Based on previous experience, Infra are not likely to make it a 
priority to help with a name change mid incubation or just before gradation.

Kind Regards,
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: Proposal

[Daniel Widdis]

Speaking only for myself, I’ll say I am interested in the open source software 
model and am not interested in participating in any private group.

 

Additionally, GPT3 is a closed source model with the only “free” part being a 
public-facing API, with usage primarily benefiting one company.

 

I would expect you might get more interest in building a product around GPT-J 
[1], which is an Apache License 2.0 product.  But I also expect most people on 
this list would like to see what is proposed and discussed in the open.  

 

[1] https://github.com/kingoflolz/mesh-transformer-jax/

 

 

 

From: m sacks 
Date: Wednesday, May 18, 2022 at 5:58 PM
To: Daniel Widdis , 
Subject: Re: Proposal

 

So I’m not sure if this made it either: is there at least one person interested 
in collaborating on this project it involves GPT three?

 

On Mon, May 16, 2022 at 10:47 PM m sacks  wrote:

Not sure if this made it:

Just a term of endearment, mot taken to be meant literally. 

 

Sure. 

 

Initially the community would be a private group put together by me. 

 

Then we can discuss building it once others have decided if it’s even a useful 
application first?

 

On Mon, May 16, 2022 at 10:20 PM Daniel Widdis  wrote:

I'm not an ASF warlord or general.  In fact, I don't think such things exist. 
It's about community.  Decisions are made by communities.  Warlords, generals, 
and benevolent dictators don't fit well.

Related, I don't see anything "community" in your post. You state "I" have got 
code, not "we".

You can have the best code in the universe, but if you don't have a community 
developing it, it's not really a good fit here.

So tell us less about your code and more about your community developing it.


On 5/16/22, 10:05 PM, "m sacks"  wrote:

I have some gpt3 based python code to simulate leonardo da vinci as a
chatbot proof of concept. I think it could be useful, but i am not sure, so
i leave it to the council of ASF warlords and generals to decide if the
code should be incubated?


I have not shared sources as of yet.

Re: [DISCUSSION] Incubating Proposal of Firestorm

[Daniel Widdis]

+1 to this.  Would love to see both groups come together.

On 5/17/22, 11:50 PM, "Sheng Wu"  wrote:

Hi Firestorm community

Considering what Yu Li is proposing, I would recommend you could do
some discussions directly, maybe off the list if you want.
Both of the projects are young and very new to the community, it may
be not a concern from my perspective(may be concerned by some IPMC),
as one/both could fail in the incubating. But with you are going to
work on the similar things, the challenge would be for both of your
projects to establish the incubating process. Also, when we talk about
graduation in the future, it would be my concern of causing confusion
to users.

Two TLPs are nearly the same is really not a good practice from the
foundation level.

> We heartfully welcome you to join Firestorm project and community.

So, I suggest not just saying joining Firestorm, this may be a simple
reaction, I hope you could do more.
This is an opportunity to do a bigger and more powerful project
supported by Tencent and Alibaba's initial teams.

I know it is not easy to do a joint project, but it is actually much
better to see you two competing with each other in the next 1-2 years.
In the ASF, we hope to create a better project for the whole industry.


Sheng Wu 吴晟
Twitter, wusheng1108

Jerry Shao  于2022年5月18日周三 14:38写道：
>
> Hi Yu，
>
> IMO, I think we're open and welcome all the contributions. We heartfully
> welcome you to join Firestorm project and community.
>
> Best regards,
> Jerry
>
> Yu Li  于2022年5月18日周三 13:36写道：
>
> > Hi Jerry,
> >
> > Good to see the proposal for incubating a uniform remote shuffle 
service.
> > Coincidently, we are preparing an incubating proposal for the same
> > direction based on two open source projects Alibaba is driving [1] [2], 
and
> > I'm the champion for that. Our proposal is still not fully prepared 
because
> > the merge of the two projects is still in progress, and I'm writing this
> > email to check whether it's possible that we have a joint force to 
achieve
> > the same goal. I believe it will be cool if we could do this together,
> > although there will be a lot (more) work to do to make this happen.
> >
> > Please let me know your thoughts and let's have more discussions if 
you're
> > also interested. Thanks.
> >
> > Best Regards,
> > Yu
> >
> > [1] https://github.com/flink-extended/flink-remote-shuffle
> > [2] https://github.com/alibaba/RemoteShuffleService
> >
> >
> > On Wed, 18 May 2022 at 12:15, Jerry Shao  wrote:
> >
> > > Sure Felix, let me add you to the list.
> > >
> > > Best,
> > > Jerry
> > >
> > > Felix Cheung  于2022年5月18日周三 11:59写道：
> > >
> > > > Same here, would love to see if I can help, Jerry.
> > > >
> > > >
> > > > On Mon, May 16, 2022 at 10:31 PM Saisai Shao 

> > > > wrote:
> > > >
> > > > > Thanks Weiwei, let me add you to the mentor list.
> > > > >
> > > > > Best regards,
> > > > > Jerry
> > > > >
> > > > > Weiwei Yang  于2022年5月17日周二 12:18写道：
> > > > >
> > > > > > +1
> > > > > > This is an interesting project, I'd be happy to help the 
project's
> > > > > > incubation process.
> > > > > > Let me know if you need my help, Thanks
> > > > > >
> > > > > > On Mon, May 16, 2022 at 8:09 PM Saisai Shao <
> > sai.sai.s...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Got it, thanks a lot Justin.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Jerry
> > > > > > >
> > > > > > > Justin Mclean  于2022年5月17日周二 
10:59写道：
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > The new project name doesn’t need to be a registered 
trademark,
> > > but
> > > > > you
> > > > > > > > would still need to pick a name that is now likely to have 
any
> > > > > > trademark
> > > > > > > > issues.
> > > > > > > >
> > > > > > > > The project may want to get the ASF to register the mark at 
a
> > > later
> > > > > > date,
> > > > > > > > but it wold be best to talk abut that on the trademarks@ 
list.
> > > > > > > >
> > > > > > > > Kind Regards,
> > > > > > > > Justin
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > 
-
> > > > > > > > To unsubscribe, e-mail:
> > general-unsubscr...@incubator.apache.org
> > > > > > > > For additional commands, e-mail:
> > > general-h...@incubator.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >

-
To unsubscribe, e-mail: 

Re: Proposal

[Daniel Widdis]

I'm not an ASF warlord or general.  In fact, I don't think such things exist. 
It's about community.  Decisions are made by communities.  Warlords, generals, 
and benevolent dictators don't fit well.

Related, I don't see anything "community" in your post. You state "I" have got 
code, not "we".

You can have the best code in the universe, but if you don't have a community 
developing it, it's not really a good fit here.

So tell us less about your code and more about your community developing it.


On 5/16/22, 10:05 PM, "m sacks"  wrote:

I have some gpt3 based python code to simulate leonardo da vinci as a
chatbot proof of concept. I think it could be useful, but i am not sure, so
i leave it to the council of ASF warlords and generals to decide if the
code should be incubated?


I have not shared sources as of yet.




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

Re: [DISCUSSION] Incubating Proposal of Firestorm

[Daniel Widdis]

I trust your lawyer will know better than I will about the trademark.  I simply 
entered "firestorm software" into a search engine and got a product that's not 
yours, available since at least July 2017. 

This site [1] has the general naming guidance and the existence of the other 
software may be of concern with some of the considerations.

1 - https://infra.apache.org/project-names.html


On 5/16/22, 6:43 PM, "Saisai Shao"  wrote:

Hi Daniel and Justin,

Thanks for your reply. The trademark "firestorm" as a software has already
been submitted the registration by Tencent in China, I'm not sure is that
enough or not.

Is there any guidance in ASF about naming or trademark things? I will
consult this to our company lawyer.

Thanks
Jerry

Justin Mclean  于2022年5月17日周二 05:59写道：

> Hi,
>
> Sounds like an interesting project. I also think the name may be
> problematic from a trademark point of view. It might be best to do a
> trademark search as see if there are any issues. Changing the name is
> difficult, but is much much harder if it needs to be done later.
>
> Kind Regards,
> 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: [VOTE] graduate Apache Doris (Incubating) as a Top Level Project

[Daniel Widdis]

+1 (non-binding)

On 4/23/22, 7:26 PM, "陈明雨"  wrote:

Dear Incubator Community,

After having the discussion in Doris community[1][2], we have passed the 
community vote[3].

And then made a discussion in general@incubator[4]. We got a lot of 
positive responses.

And have responded and addressed all suggestions and comments raised.




I would like to start this voting thread to request graduating the Doris 
project from the incubator as a TLP.

Please provide your vote as one of the following options:




[ ] +1 - Recommend graduation of Apache Doris as a TLP

[ ] 0 - I don't feel strongly about it, but don't object

[ ] -1 - Do not recommend the graduation of Apache Doris because…




The VOTE will remain open for at least 72 hours.




The following is a brief overview of the progress of the Doris project and 
community since entering the incubator:

1. Community

- 9 new PPMC members were added, from five different companies, bringing 
the total number of PPMC members to 22.

- 20 new Committers were added (including the new PPMC members), bringing 
the total number of Committers to 33.

- The number of Contributors is now 305 and growing[5].

- The dev@doris mailing list currently has 328 subscribers, and all major 
project discussions are happening in the dev@doris.




2. Project

- 7 releases by 6 release managers. All compliance issues have been 
resolved.

- Doris official website[6] is compliant with Apache Foundation 
requirements[7].

- Project maturity model is detailed in [8].

- See Doris Project Incubation Status[9] for more info.




[1] https://lists.apache.org/thread/90fd2pd3r6wgn4hnfdo3rd0wqkv23cgr

[2] https://lists.apache.org/thread/xc5qj7m2k1ph0mc97otj0nf8vskdfrzv

[3] https://lists.apache.org/thread/9yklv4vbp39jhrzbcx3qgpcs1osk3lyf

[4] https://lists.apache.org/thread/nbncjl8fdq0bcjop6l4747c8x9c06q00

[5] https://github.com/apache/incubator-doris

[6] http://doris.incubator.apache.org/

[7] https://whimsy.apache.org/pods/project/doris

[8] 
https://cwiki.apache.org/confluence/display/DORIS/Maturity+Assessment+for+Doris

[9] https://incubator.apache.org/projects/doris.html





==

Establish the Apache Doris Project




WHEREAS, the Board of Directors deems it to be in the best interests of

the Foundation and consistent with the Foundation's purpose to establish

a Project Management Committee charged with the creation and maintenance

of open-source software, for distribution at no charge to the public,

related to a MPP-based interactive SQL data warehousing for reporting

and analysis.




NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee

(PMC), to be known as the "Apache Doris Project", be and hereby is

established pursuant to Bylaws of the Foundation; and be it further




RESOLVED, that the Apache Doris Project be and hereby is responsible for

the creation and maintenance of software related to a MPP-based

interactive SQL data warehousing for reporting and analysis; and be it

further




RESOLVED, that the office of "Vice President, Apache Doris" be and

hereby is created, the person holding such office to serve at the

direction of the Board of Directors as the chair of the Apache Doris

Project, and to have primary responsibility for management of the

projects within the scope of responsibility of the Apache Doris Project;

and be it further




RESOLVED, that the persons listed immediately below be and hereby are

appointed to serve as the initial members of the Apache Doris Project:




* Bin Ling 

* Bo Wang 

* Chaoyong Li 

* Chun Zhao 

* Conghui Cai 

* Dayue Gao 

* De Li 

* Hangyuan Liu 

* Hao Chen 

* HaoPeng Li 

* Jiafeng Zhang 

* Kaisen Kang 

* Ling Miao 

* Ming Wen 

* Mingyu Chen 

* Ruyue Ma 

* Shao Feng Shi 

* Sijie Guo 

* Willem Ning Jiang 

* Zheng Shao 

* Zhengguo Yang 

* Zuo Wei 




NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mingyu Chen be appointed to

the office of Vice President, Apache Doris, to serve in accordance with

and subject to the direction of the Board of Directors and the Bylaws of

the Foundation until death, resignation, retirement, removal or

disqualification, or until a successor is appointed; and be it further




RESOLVED, that the Apache Doris Project be and hereby is tasked with the

migration and rationalization of the Apache Incubator Doris podling; and

be it further




RESOLVED, that all responsibilities pertaining to the Apache Incubator

Doris podling encumbered upon the Apache Incubator PMC are hereafter

discharged.




--

此致！Best Regards

Re: Chunjun Proposal

[Daniel Widdis]

Hi, LuNing.

I am not an IPC member, just an interested open source enthusiast looking for a 
project to contribute to.  

I was excited about contributing to another project that recently joined the 
incubator but as someone who only speaks English, I have had a challenge when a 
large number of issues are written in Chinese without enough translation for me 
to help.

Reading your proposal I thought this may be another opportunity for me to help, 
but I just visited your github site and found that most of the current open 
issues are not understandable to me, and while I am enthusiastic and want to 
help, I do not see how I can do so.

I  am concerned about your ability to gain members of your project who do not 
speak your language.

On 2/23/22, 9:15 PM, "LuNing Wang"  wrote:

Hi,

I am LuNing Wang who sent the Chunjun proposal using 'apa...@dtstack.com'
and I'm one of the maintainer of Chunjun project.
As Apache is a community of peers, I will use this email to reply to all
questions and issues in this thread, after I read The Apache Incubator
Cookbook.

May I use this email to continue to communicate with the Apache community
in this thread?

Best,
LuNing Wang 王鲁宁


Apache  于2022年2月24日周四 09:57写道：

>
>
> --
> 发件人：Calvin Kirs 
> 发送时间：2022年2月23日(星期三) 00:07
> 收件人：general 
> 主 题：Re: Chunjun Proposal
>
> Hi,
>
> I second with Tison and I'm glad to see your proposal,
> you must have put a lot of effort into drafting this proposal,
> but it needs to be clear what you expect and what you know about 
Apache[1],
> and are we are on the same page?
>
>
> You can see the following information:
> The Apache Incubator Cookbook[2]
> The Apache Way[3]
>
> I'd be happy to help you if you need it.
>
> [1]https://www.apache.org/
> [2]https://incubator.apache.org/cookbook/
> [3]https://www.apache.org/theapacheway/index.html
>
> tison  于2022年2月22日周二 23:17写道：
>
> > Hi,
> >
> > I have two questions here:
> >
> > 1. How should I name you in this thread? Apache is a community of peers.
> I
> > can't image I'm talking to the whole Chunjun community or "Apache" 
expect
> > its your name.
> > 2. What's your expectations on going into the incubator? Among the whole
> > proposal it's almost about what the current state of Chunjun and the 
only
> > statement about your expectations is:
> >
> > > we seek to further prosper the community with the aid of Apache
> >
> > Could you elaborate a bit the motivation here? What help are you 
seeking?
> >
> > Also I second to Sheng's comment that it's confused about your
> expressions
> > of contributors and initial committers. If your community continuously
> > promote contributors , why the initial committer list is quite a bit
> > limited?
> >
> > Best,
> > tison.
> >
> >
> > Sheng Wu  于2022年2月22日周二 20:54写道：
> >
> > > I think this description is incorrect.
> > >
> > > > Our initial committers will submit iCLA(s), SGA, and CCLA(s).
> > >
> > > Committers are individuals, who should only submit ICLA, their
> > > employers are recommended to submit CCLA, the owner of the project
> > > should sign the SGA.
> > > ___
> > >
> > > Also, I noticed a conflict in your description
> > > On one side, you mentioned `The initial committers are employees of
> > > DTStack.` with only 5 initial committers, and on the other hand, you
> > > gave a very long vendor list and core contributors list.
> > > So, which is an accurate description? If you have those contributors,
> > > why were all of them invited as PPMC members? Do you have any public
> > > discussion about this decision?
> > > Such as GitHub ID(demotto) is the #8 in the contributor list, and also
> > > listed in the core contributor list, but can't find it in the initial
> > > committer list.
> > >
> > >
> > > Sheng Wu 吴晟
> > > Twitter, wusheng1108
> > >
> > > Lidong Dai  于2022年2月22日周二 20:41写道：
> > > >
> > > > I am curious that Chunjun(was Flinkx) is built on the Flink CDC, so
> > what
> > > is
> > > > its innovation?
> > > >
> > > > BTW, you shouldn't use the mail(apa...@dtstack.com) as your user
> > > account,
> > > > apache is a registered trademark of ASF
> > > >
> > > >
> > > >
> > > > Best Regards
> > > >
> > > >
> > > >
> > > > ---
> > > > Apache DolphinScheduler PMC Chair
> > > > Lidong Dai
> > > > lidong...@apache.org
> > > > Linkedin: https://www.linkedin.com/in/dailidong
> > > > Twitter: @WorkflowEasy 
> > > >
> > > > ---
> > > >
> > > >
> > > > On 

Re: [VOTE] Accept Hugegraph into the Apache Incubator

[Daniel Widdis]

+1 (non-binding)

On 1/15/22, 3:22 PM, "Willem Jiang"  wrote:

Hi all,

Following up the [DISCUSS] thread on Hugegraph[1], I would like to call a
VOTE to accept Hugegraph into the Apache Incubator.

Please cast your vote:

  [ ] +1, bring Hugegraph into the Incubator
  [ ] +0, I don't care either way
  [ ] -1, do not bring Hugegraph into the Incubator, because...

The vote will open at least for 72 hours, and only votes from the
Incubator PMC are binding, but votes from everyone are welcome.

Please check out the Hugegraph Proposal from the incubator wiki[2].

[1]https://lists.apache.org/thread/31k4jsgmmfhl3vggnbko1rjsmqjymh29
[2]https://cwiki.apache.org/confluence/display/INCUBATOR/HugeGraphProposal

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

-
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: Can we use the GitHub's "transferring a repository" feature after IP clearance

[Daniel Widdis]

I can't speak to the specifics of Apache, but I have used the repository 
transfer feature to move a project from a personal account to an organizational 
account, and it preserves all the issues, PRs, commit history, etc., simply 
changing the Github URL.   I wouldn't think there would be any issues at all 
from an IP standpoint.

The only "hiccup" I experienced the presence of older releases with older 
coordinates in a central repository, for which there should be a one-time 
special release process to redirect the groupid for the first release at new 
coordinates, e.g. [1]

[1] - https://maven.apache.org/guides/mini/guide-relocation.html

On 11/23/21, 6:33 PM, "Sutou Kouhei"  wrote:

Hi,

I'm not sure that here is a right place to discuss this. If
this is not a right place, please tell me where is a right
place.

Question:

Can we use the GitHub's "transferring a repository"[1] after
IP clearance is passed? Apache Arrow project used pull
requests to import donated codes that pass IP clearance but
has never used the GitHub's "transferring a repository". If
there is a case that uses the GitHub's "transferring a
repository", please share it. Any advice is appreciated as
well.

Background:

Apache Arrow project has accepted the donation of the Julia
implementation before[2]. But there is a problem in
development process, https://github.com/JuliaData/Arrow.jl
is upstream and
https://github.com/apache/arrow/tree/master/julia/Arrow is
downstream[3].

So, Apache Arrow project wants to restart the Julia
implementation with the Apache way development process from
IP clearance. Apache Arrow project wants to use a separated
repository https://github.com/apache/arrow-julia instead of
Apache Arrow's monorepo https://github.com/apache/arrow with
the new development process. Apache Arrow PMC accepted
this[4][5].

I assumed that Apache Arrow project uses a pull request for
IP clearance and importing passed codes at import
https://github.com/JuliaData/Arrow.jl . So I've created an
empty Git repository https://github.com/apache/arrow-julia
. But an idea is raised: How about using the GitHub's
"transferring a repository" feature to move existing issues
and pull requests as-is, set redirect to
https://github.com/apache/arrow-julia from
https://github.com/JuliaData/Arrow.jl and so on?

But I don't know that Apache Arrow project can use the
GitHub's "transferring a repository" feature. So I'm asking
this here.


[1] 
https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
[2] https://lists.apache.org/thread/w7szf06rf0qomc5dolhg57x0pcxvqvxr
[3] https://lists.apache.org/thread/1ofhjn37rrlvyv9phhg34hnbrk0dgf4r
[4] https://lists.apache.org/thread/6q333y875v7mfyl2g988b01hqtgr52pt
[5] https://lists.apache.org/thread/0fty9370vt5rmp48kbjkdzc0g8vc5cgf


Thanks,
-- 
kou

-
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: [VOTE] Release Apache Wayang (Incubating) 0.6.0-RC5

[Daniel Widdis]

Generally in agreement, but:

> given there may be a license issue and it's very easy to fix, why not fix it?

Any "fix" will look like the old code and thus be "modified".  

The new graph in this case happens to have the same number of nodes and arcs as 
the original copyrighted artwork, but arranged in a completely different way.  
Your position seems to be this might not "fix" the problem.

I think we are all in agreement that a randomly generated set of nodes and arcs 
would be compliant, even if the code still looks similar.


On 11/6/21, 11:40 PM, "Justin Mclean"  wrote:

Hi,

> And sure, the image labeled with B and C is based on the non-labeled 
image with smiley faces, so I'll concede that image, and even the exact network 
it represents, may fall under CC-BY-SA, and thus it was correct to remove the 
old code.

This main issue I think as the old code wasn’t replaced but modified. 
Modified stuff in general keeps the same license the original. That may apply 
here, but I’m not 100% sure, but I don’t think it a serious issue. But given 
there may be a license issue and it's very easy to fix, why not fix it? Also 
other IPMC members can still vote +1 and this become a release, but I suggest 
the project fixes it in a future release. If you had used teh WIP progress 
disclaimer I would have votes +1 and suggested that.

> Are you asserting that any directed graph is CC-BY-SA licensed?  If not, 
what is the threshold for difference that you would accept?

I would assume not, but you'd need to get actually legal advice to regards 
what the threshold would be. As is every user of this software may need to seek 
that advice in order to use it without that risk. The risk could be minimal or 
nonexistent, but IANAL it's best IMO to err on the side of caution with stuff 
like this.

> Would it be acceptable to generate a completely random graph using [1] 
and represent that in the code?

Sure, but so would one that the project came up with itself that wasn’t 
based on another one, or one that was under compatible license.

Kind Regards,
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: [VOTE] Release Apache Wayang (Incubating) 0.6.0-RC5

[Daniel Widdis]

> It unclear what has been used from that page, there is text, code and images 
> on it all under different licenses.

It's very clear to me.  The code you linked to is simply a representation of 
what nodes link to what other nodes by a directed arc.  For example, the top 
two sites labeled B and C point to each other.  C doesn't point to anything 
else and isn't pointed to by anything other than B.

The original network clearly directly matched the graphic including the 
labeling of the sites by letter and matching links.  

There is no code on the website which refers to this graphic in any way; in 
fact, the algorithm text elsewhere on the page refers to a simplified 4-node 
network with A, B, C, and D which doesn't match the image at all.

> Assuming it is this just this image, then it is based on this image

The "based on" is the linking of sites represented by arrows.  For example, 
these two lines in the removed code represent the bidirectional link in the 
upper right of the image.

new char[]{'B', 'C'},
new char[]{'C', 'B'},

Of note, C only connects to B, and is connected to by B.  

And sure, the image labeled with B and C is based on the non-labeled image with 
smiley faces, so I'll concede that image, and even the exact network it 
represents, may fall under CC-BY-SA, and thus it was correct to remove the old 
code.

However, the PR changed to a different set of links, creating a different 
graph.  As a quick proof, there is no node like C in the previous version which 
only has a single bidirectional link to another node, so it clearly does not 
represent the same graph.  There may be some similarities, but how much of a 
difference is required?

Are you asserting that any directed graph is CC-BY-SA licensed?  If not, what 
is the threshold for difference that you would accept?

Would it be acceptable to generate a completely random graph using [1] and 
represent that in the code?

[1] - http://bl.ocks.org/erkal/9746513





On 11/6/21, 9:58 PM, "Justin Mclean"  wrote:

Hi,

It unclear what has been used from that page, there is text, code and 
images on it all under different licenses.

In general content on wikipedia is not in the public domain and care needs 
to be taken with is use, also what “public domain” means varies. For how to 
treat public domain works in an ASF project please see [1]. It would need to 
mentioned in the LICENSE at a minimum.

Assuming it is this just this image, then it is based on this image [2] 
which is in not public domain but CC-by-SA which complicates things.

I did suggest that the project uses the WIP disclaimer which is a good idea 
until issue like this have been sorted out.

Kind Regards,
Justin

1. 
https://www.apache.org/legal/resolved.html#handling-public-domain-licensed-works
2. https://en.wikipedia.org/wiki/File:PageRank-hi-res.png
-
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: [VOTE] Release Apache Wayang (Incubating) 0.6.0-RC5

[Daniel Widdis]

> taking creative common license code and making modifications to it 

I visited the indicated page [1] and there is no code there.  The code appears 
to have represented connecting letters to match the image on that page.

The license on the image itself [2] indicates that it is public domain.

I see no issue. 

[1] - https://en.wikipedia.org/wiki/PageRank
[2] - https://en.wikipedia.org/wiki/PageRank#/media/File:PageRanks-Example.svg


On 11/6/21, 6:28 PM, "Justin Mclean"  wrote:

Hi,

+0 on this. while some issues have been fixed, I'm concerned that taking 
creative common license code and making modifications to it [1] and removing 
the comment to where it was originally from doesn’t actually change the 
original license of that code.

I checked:
- incubating in name
- LICENSE OK
- NOTICE needs some more work (see below)
- All source files have ASF headers
- No unexpected binary files
- Can compile from source

In your NOTICE file please do not use "Copyright 2020 and onwards”, instead 
use ""Copyright 2020-20XX” when XX is the year of publication/ release. 
Copyright does expire and doesn’t last forever.

Also in the NOTICE please include the copyright line from Sebastian Kruse. 
While it is good idea to provide a link, that linked to content could change 
over time or the link no longer be valid.

Please fix the NOTICE issues in your next release.

Thanks,
Justin

1. 
https://github.com/apache/incubator-wayang/commit/aaa47e07d762ddc838e5ba52cc7af7727e1b821a#diff-ec94e28e6d97642f6769f117cd47f8b34eb7f9a388eb2e9d4978775450587acc


-
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: [IP CLEARANCE] Apache Maven - Mvndaemon

[Daniel Widdis]

I agree in general, and due diligence is specifically warranted for the case 
you cite here:
> often with software grants the license changes to ALv2 just before donation

So to narrow the conversation for this specific case:

The LICENSE file was added to the repo 2019-09-30 and all files in the repo had 
AL2.0 license headers added on 2020-06-18. Only the "top two" had made 
contributions at this point; the remaining 11 contributors submitted their 
contribution to files which already carried the AL2 header at the time of their 
submission.

Accordingly, as those 11 contributors did not explicitly state their 
contribution was under a different license, I do not think CLAs are required, 
no matter the size of their commits.

On 9/5/21, 8:08 PM, "Justin Mclean"  wrote:

Hi,

While some of that conversation may apply here, and I don’t think there is 
any issues, please note the conversation is in a slightly different context to 
a software grant. When contributing to an ASF project it is clear under what 
terms you are contributing. When contributing to a 3rd party repo it may not be 
clear, and often with software grants the license changes to ALv2 just before 
donation or a whole lot of other things can occur.

Kind Regards,
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: [IP CLEARANCE] Apache Maven - Mvndaemon

[Daniel Widdis]

On 9/5/21, 7:46 PM, "Justin Mclean"  wrote:

You’ll note [1] says "All contributors of ideas, code, or documentation to 
any Apache projects must complete, sign, and submit via email an Individual 
Contributor License Agreement(ICLA).’ however we do allow people to contribute 
without signing an ICLA and as the code is under an Apache license the intent 
would be clear here.


That seems to be in conflict to the license itself [2] which states:

> 5. Submission of Contributions. Unless You explicitly state otherwise, any 
> Contribution intentionally submitted for inclusion in the Work by You to the 
> Licensor shall be under the terms and conditions of this License, without any 
> additional terms or conditions.

The author of the license clarified this in [3]:

> Yes, that opinion comes from me speaking as a board member and
author of the Apache License, and has previously been cleared
with Apache's legal team for a long ago discussion with Incubator.
We don't need a CLA on file to accept contributions from non-committers.
We just need a clear intent by the author to contribute under
our normal terms.

> The authors do not need to have a CLA
on file even if the contribution is massive -- CLAs are only
required for the people who want an account at Apache and thus
are allowed to make the decision to push those bits into our
repository.


1. https://www.apache.org/licenses/contributor-agreements.html
2. https://www.apache.org/licenses/LICENSE-2.0
3. 
http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/201112.mbox/%3ca603ffce-623b-43e9-87f8-39baa51c7...@gbiv.com%3E







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

Re: [IP CLEARANCE] Apache Maven - Mvndaemon

[Daniel Widdis]

On 9/5/21, 7:16 PM, "Olivier Lamy"  wrote:
Again the project is already Apache license from the start so any
contribution will be de facto ASF compliant

***

Linked from the blog post I cited earlier justifies this statement.

http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/201112.mbox/%3ca603ffce-623b-43e9-87f8-39baa51c7...@gbiv.com%3E

See the last paragraph, especially the last 3 lines.  I do not think any CLA is 
required for pull requests by non-committers on an already-AL licensed project

From"Roy T. Fielding" 

Contributions can
be contributed using any of our communication forums and they are
considered to be under the Apache License 2.0.  If the author happens
to have a CLA on file, then the CLA overrides the normal contribution
license automatically -- there is no need to check that.

There is no reason to apply this extra level of control within
infrastructure for checking things that any reasonably competent
committer can be trusted to do themselves.  And there is a known
reason not to do so, namely that the committer field in git has
nothing to do with the provenance of the code, but may in fact
vary for the same individual depending on whether they are
interacting with a public repository or their work's repository,
or maybe even their club's repository.  Github is certainly one
example where the committer names will not match our avail names,
and one of the goals of this effort is to enable folks to
use Github as one of many forums for collaborating with potential
recruits.

Yes, that opinion comes from me speaking as a board member and
author of the Apache License, and has previously been cleared
with Apache's legal team for a long ago discussion with Incubator.
We don't need a CLA on file to accept contributions from non-committers.
We just need a clear intent by the author to contribute under
our normal terms.




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

Re: [IP CLEARANCE] Apache Maven - Mvndaemon

[Daniel Widdis]

My concern is the habit of some using lines of code as a measure of 
significance.  One can make a "significant" commit of a few lines, and an 
insignificant commit of thousands of lines.  It is better to assess the 
intellectual property content of the submission.

I did look through all contributions other than the top two contributors and 
found only two commits that I would consider "copyrightable" IP.

All that said:

I do not have any concern with the two contributors who made these two commits 
having not signed CLAs. I do not believe CLAs are required if:
 - the individuals submitting the PR are not committers on the project 
(committers must sign CLAs)
 - the individuals submitted a pull request to the project when it already had 
AL2.0 license
 - the submission was voluntary
 - they did not explicitly state their contribution was under any other license

I posted a few links earlier.  See 
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201606.mbox/%3ccanq7ko_z_cfflju_7hoonno4duo7bxufdzutk3yntsnxvu1...@mail.gmail.com%3E
 which references this blog post:

https://apetro.ghost.io/apache-contributors-no-cla/


On 9/5/21, 7:19 PM, "Olivier Lamy"  wrote:

On Mon, 6 Sept 2021 at 12:13, Daniel Widdis  wrote:

> Code size is not the only measure of significance.
>
> Without any specialty knowledge of the domain, I would consider this
> security fix probably significant.
> https://github.com/mvndaemon/mvnd/pull/391 fixing
> https://github.com/mvndaemon/mvnd/issues/390


I don't understand your concern?
every project can have security issues but if it's fixed what is the
problem?
At least the first release under ASF will contain the fix because it's
already fixed.



>
>
> However, the AL2.0 license states:
> > Unless You explicitly state otherwise, any Contribution intentionally
> submitted for inclusion in the Work by You to the Licensor shall be under
> the terms and conditions of this License, without any additional terms or
> conditions.
>
> Given the project was AL2.0 licensed at the time of the contribution,
> submitting a PR to the repository should constitute a "Contribution
> intentionally submitted for inclusion in the Work" and should require no
> additional terms.
>
> Also see
> 
https://issues.apache.org/jira/browse/LEGAL-156?focusedCommentId=13554864=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13554864
> > Any contribution - in any form (patch to the mailing list, blog post,
> JIRA attchment, git pull request, Bugzilla attachment, scrawled on the 
back
> of a napkin) - may be included as long as two conditions are met:
> >
> > 1. As per section 5 of AL2 the person providing the patch does not
> explicitly state that the patch provided is not licensed under ALv2
> >
> > 2. The project's PMC is happy that the person providing the contribution
> has the necessary rights to do so.
>
>
>
> On 9/5/21, 6:46 PM, "Olivier Lamy"  wrote:
> looking at this https://github.com/mvndaemon/mvnd/graphs/contributors
> except the 2 main contributors we can't really qualify other
> contributions
> as really significant in terms of code size :)
>
>
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy



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

Re: [IP CLEARANCE] Apache Maven - Mvndaemon

[Daniel Widdis]

Code size is not the only measure of significance. 

Without any specialty knowledge of the domain, I would consider this security 
fix probably significant.
https://github.com/mvndaemon/mvnd/pull/391 fixing 
https://github.com/mvndaemon/mvnd/issues/390

However, the AL2.0 license states:
> Unless You explicitly state otherwise, any Contribution intentionally 
> submitted for inclusion in the Work by You to the Licensor shall be under the 
> terms and conditions of this License, without any additional terms or 
> conditions.

Given the project was AL2.0 licensed at the time of the contribution, 
submitting a PR to the repository should constitute a "Contribution 
intentionally submitted for inclusion in the Work" and should require no 
additional terms.  

Also see 
https://issues.apache.org/jira/browse/LEGAL-156?focusedCommentId=13554864=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13554864
> Any contribution - in any form (patch to the mailing list, blog post, JIRA 
> attchment, git pull request, Bugzilla attachment, scrawled on the back of a 
> napkin) - may be included as long as two conditions are met:
> 
> 1. As per section 5 of AL2 the person providing the patch does not explicitly 
> state that the patch provided is not licensed under ALv2
> 
> 2. The project's PMC is happy that the person providing the contribution has 
> the necessary rights to do so.



On 9/5/21, 6:46 PM, "Olivier Lamy"  wrote:
looking at this https://github.com/mvndaemon/mvnd/graphs/contributors
except the 2 main contributors we can't really qualify other contributions
as really significant in terms of code size :)





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

Re: [IP CLEARANCE] Apache Maven - Mvndaemon

[Daniel Widdis]

I looked into every commit to this repository.
https://github.com/mvndaemon/mvnd/graphs/contributors

I understand from the thread there are CLAs from the two main contributors.  Of 
the remaining 11 committers:
- lanmaoxinqing had one substantive commit of +87/-9 lines.
- Syquel had one substantive commit of +60/-7 lines.

All other commits were minor documentation, config file, versioning, workflow, 
cleanup, and typo fix changes.

On 9/5/21, 6:08 PM, "Justin Mclean"  wrote:

Hi,

> ?? You mean we need CLAs for every person who contributed a Pull Request 
to
> an Apache License project?

No we don’t, but it’s best to have them from everyone who has made a 
significant contribution.

> we need to address the native part. Not sure how ATM

You probably need to work this out before merging the code into the ASF 
repo.

Kind Regards,
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: IP clearance officer for accepting Terraform

[Daniel Widdis]

I have no concerns.  I am not a member of the IPMC, just an interested 
participant in the conversation.

On 7/11/21, 11:25 PM, "Rohit Yadav"  wrote:

Hi Daniel, Justin, IPMC,

Are you happy with the answers to satisfaction? Do you have any other
questions/concerns, or can we continue with the IP clearance vote?
It has been three weeks since this thread, while the Apache CloudStack
PMC has passed the vote to accept donations in April 2021. If there
are any, can you advise by the end of tomorrow?

Regards.

On Sat, Jul 10, 2021 at 10:56 AM Rohit Yadav  wrote:
>
> Hi Justin,
>
> Yes that's right, there's no 3rd party code in the latest codebase/tags 
that is being donated. And yes, the large commits that brought the 3rd party 
code in vendor directory have been all removed too.
>
> Regards.
>
> On Sat, 10 Jul, 2021, 6:26 am Justin Mclean,  
wrote:
>>
>> Hi,
>>
>> > However, if you compare the changes in above commits against the
>> > repositories being donated the "vendor" directory does not exist now
>> > in both the repositories being donated:
>> > https://github.com/xanzy/go-cloudstack
>> > https://github.com/xanzy/terraform-provider-cloudstack (for example
>> > vendor removed in this commit -
>> > 
https://github.com/xanzy/terraform-provider-cloudstack/commit/4db2f701592b5af74376f5b138624bff75763152)
>>
>> So what you are saying is that all of those large commits have been 
removed? What I would be concerned about happening is if a large amount of 3rd 
party code incorrectly gets an ASF header on it. There no issue with 3rd party 
code in the repo but it must be clearly marked, have the correct non ASF header 
and its license compatible with the Apache license. Looking at the repos all 
headers are ASF ones, is there any 3rd party code in the donated code?
>>
>> Thanks,
>> Justin
>>



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

Re: IP clearance officer for accepting Terraform

[Daniel Widdis]

I've been following this thread and continue to see phrases such as "major 
contributors" and "significant contributions".

Given the entire premise of the conversation here is on whether there are legal 
claims to IP, could you clarify, objectively, what defines "major" and/or 
"significant"?

On 6/22/21, 11:49 PM, "Justin Mclean"  wrote:

Hi,

> Alright, I'll create a Github issue as suggested in the example to track 
IP
> clearance with list of all people and will try to reach out to all
> contributors within a limited time period and see if they can agree over
> the other legal thread and submit their ICLAs.

While having an ICLA is ideal, I think a recorded agreement from the major 
contributors is probably enough given the history here. You already have that 
from most of them. If some don’t answer then just record that and continue. It 
might be possible that other IPMC members might have a different view on this.

> This however wasn't advised on the IP clearance process:
> https://incubator.apache.org/ip-clearance/ip-clearance-template.html

It does say "Either an Individual CLA or Corporate CLA is preferred to a 
Software Grant. All authors must sign an Individual CLA; or all owners of IP 
must sign one of the three documents and send to secretary “. I’m still 
slightly unclear on who the IP owners are. Sander is obviously one, but I would 
guess it’s the other 8 or so other major contributors or possibly in some cases 
their employers. Having an ICLA clears that up as the person states that any 
contributions they make they are allowed to do so and have their employers 
permission to do so.

Kind Regards,
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: [VOTE] Release Apache NLPCraft - Java Client (incubating) 0.7.5

[Daniel Widdis]

It seems to me that knowing who has carryover votes is not important for a lazy 
consensus vote.

The +1 votes are not really required except in the rare case they might be 
needed to counter a -1; in which case I'd suggest intentional action following 
the -1 would make more sense than saying "oh well, we had 4 carryover votes so 
we can ignore the -1".

On 5/22/21, 8:44 PM, "Justin Mclean"  wrote:

Hi,

> I think that IPMC votes of Mentors must automatically carryover. (Means 
the VOTE thread is clearly linked, not just RESULTS (This one was not.))

IMO The IPMC members (if any) who voted on the podlings dev list need to be 
clearly stated in the vote email sent to the IPMC general list. The IPMC 
composition changes over time and not listing them may make it difficult when 
looking at historical votes.

Thanks,
Justin



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

Re: [VOTE] Release Apache Sedona 1.0.1-incubating RC1

[Daniel Widdis]

The scala configuration file [1] appears to be a copy from [2] or its github 
source at [3].

[1] ./examples/sql/src/test/resources/scalastyle_config.xml
[2] http://www.scalastyle.org/scalastyle_config.xml
[3] 
https://github.com/scalastyle/scalastyle/blob/master/src/test/resources/config/scalastyle_config.xml
 

On 5/22/21, 8:00 PM, "Justin Mclean"  wrote:

Hi,

+1 (binding) 

I checked:
- incubating in name
- signatures and hashes are fine
- DISCLAIMER (WIP) exists
- LICENSE and NOTICE are fine
- No unexpected binary file
- ASF files have ASF headers
- Can compile from source

I would be interesting to know where this file come from [1] and I'd be 
curious to know why the BSD file [2] has "Copyright (c) 2020-2021, Apache 
Sedona” in it.

The NASA license may need to be run past legal discuss to see if it is 
compatible with the Apache license.

Thanks,
Justin

1. ./examples/sql/src/test/resources/scalastyle_config.xml
2. ./licenses/LICENSE-zeppelin-helium-plugin
-
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: [RESULT] [VOTE] Release Apache NLPCraft - Java Client (incubating) 0.7.5

[Daniel Widdis]

1. Calvin Kirs's vote was non-binding.
2. The only two binding votes were carried over from the PPMC.  Seems the main 
purpose of posting on this list is to get review from IPMC members who have not 
yet seen it.
3. As Justin pointed out, 72 hours haven't passed, giving IPMC members other 
than those who have already seen it a chance to review.

On 5/22/21, 10:33 AM, "Aaron Radzinski"  wrote:

Hi,
The vote to release Apache NLPCraft - Java Client (incubating) 0.7.5 has
passed with 3 +1 binding votes.

[3] +1 Binding votes:
- Paul King
- Furkan KAMACI
- Calvin Kirs

[ 0 ] +0  Binding votes
[ 0 ] -1  Binding votes

The vote is successful.

Thank you to the above IPMC members for taking the time to review and
provide guidance on our release!

We will proceed with publishing the approved artifacts and sending out the
appropriate announcements in the coming days.

Aaron,
--
On behalf of NLPCraft community,


On Sat, May 22, 2021 at 9:09 AM Calvin Kirs  wrote:

> +1 non-binding
>
> I checked:
>
>  Download links are valid.
>
>  Checksums and PGP signatures are valid.
>
>  LICENSE, NOTICE, and DISCLAIMER-WIP files are fine.
>
>  All files have license headers if necessary.
>
> The year of NOTICE has not been updated, it is best to modify it in the
> next version.
>
> Paul King  于2021年5月22日周六 下午10:53写道：
>
> > +1 binding from me, carrying over my vote
> >
> > On Sat, May 22, 2021 at 11:29 AM Aaron Radzinski 
> > wrote:
> >
> > > Hello all,
> > > This is a call for a vote to release Apache NLPCraft - Java Client
> > > (incubating) version 0.7.5. Apache NLPCraft is a library for adding a
> > > natural language interface to any application.
> > >
> > > The Apache NLPCraft community has voted on and approved a proposal to
> > > release Apache NLPCraft - Java Client (Incubating) version 0.7.5. We
> > would
> > > like to request the Incubator PMC members review and vote on this
> > incubator
> > > release.
> > >
> > > Release information:
> > > 1. PPMC vote result thread:
> > > https://mail-archives.apache.org/mod_mbox/nlpcraft-dev/202105.mbox/
> > >  40mail.gmail.com>
> > > 2. Release location:
> > >
> > >
> >
> 
https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/java-client/0.7.5/
> > > 3. Git tag:
> > > https://github.com/apache/incubator-nlpcraft-java-client/tree/v0.7.5
> > > 4. JIRA issues fixed in release:
> > > https://issues.apache.org/jira/projects/NLPCRAFT/versions/12349604
> > > 5. KEYS file:
> > > https://dist.apache.org/repos/dist/release/incubator/nlpcraft/KEYS
> > >
> > > PPMC vote has already provided a required majority approval and hence
> > this
> > > vote is a lazy consensus vote open for 72 hours.
> > >
> > > Please vote accordingly:
> > > +1 approve
> > > +0 no opinion
> > > -1 disapprove with the reason
> > >
> > > Thank you,
> > > Aaron.
> > > ---
> > > On behalf of NLPCraft community
> > >
> >
>
>
> --
> Best  wishes！
> CalvinKirs
>



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

Re: JPMS Projects?

[Daniel Widdis]

After considering this email I wrote, I regret sending it and want to apologize 
if I have overstepped any bounds.

I am not a member of the IPMC or associated in any formal way with Apache and 
am certainly not in any position to make any judgments regarding code quality 
or your wise choice to begin your search with such projects.

I'll back out of this conversation now and let others answer or redirect you to 
other resources.

Dan


On 3/17/21, 10:21 PM, "Daniel Widdis"  wrote:

Thanks for your clarifications.

Regarding "Apache" = "Quality", I'd be careful.  Apache asserts [1] a maxim 
of "Community over code".  While certainly a broad community inevitably leads 
to better code, and Apache is a good starting point, given the specificity of 
your request I might start there but not exclude other established projects 
(not random code) which follow many of the same principles.

I do hope those on this list are aware of some projects they can recommend 
to you!

As for the technical specifications, I'd also recommend you'd separate 
those out as well.  Some of your concerns seem to deal with native code access 
which seems a separate issue than modular design of code.  I have also been 
looking around for good Panama/FMA examples and haven't seen anything 
non-trivial yet.  But even those can be done with/without the Java Module 
System (JPMS).

Looking forward to any other replies with interest.

Dan

[1] - https://www.apache.org/theapacheway/

On 3/17/21, 10:08 PM, "leerho"  wrote:

Daniel,
Thank you for your reply.


> Can you clarify what you mean by an "Apache Java project"?


I would prefer to examine a project that has a formal release process 
and
an active community. So a TLP or incubating project would be great.  In
this case I was equating "Apache" = "Quality"  :)

I'm not so interested in random code on the Internet that just happens 
to
be Apache licensed :)

Is there a particular use case you are interested in?


I am seriously looking at *redesigning* our JDK8 Library using Java 
Modules
leveraging JDK16+/Panama/FMA and completely replacing the need for 
Unsafe,
etc.  (Not just adapting our JDK8 code to run on JDK9+ and accessing 
Java
internals using JVM args.)

This is a major undertaking so being able to look at projects that have
already gone through that process would be helpful.

Thank you,

Lee.

On Wed, Mar 17, 2021 at 3:42 PM Daniel B. Widdis  
wrote:

> Can you clarify what you mean by an "Apache Java project"?
>  - A TLP?
>  - An incubating project?
>  - A project anywhere that is released under the Apache license?
>
> There's actually no need to "migrate code" in many cases, just add 
some
> files. Is there a particular use case you are interested in?
>
> On Wed, Mar 17, 2021 at 3:11 PM leerho  wrote:
>
> > Folks,
> > Is anyone aware of an Apache Java project that has actually migrated
> their
> > code from Java 8 to the Java Platform Module System (JPMS)?
> >
> > Thanks,
> > Lee.
> >
>
>
> --
> Dan Widdis
>



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

Re: JPMS Projects?

[Daniel Widdis]

Thanks for your clarifications.

Regarding "Apache" = "Quality", I'd be careful.  Apache asserts [1] a maxim of 
"Community over code".  While certainly a broad community inevitably leads to 
better code, and Apache is a good starting point, given the specificity of your 
request I might start there but not exclude other established projects (not 
random code) which follow many of the same principles.

I do hope those on this list are aware of some projects they can recommend to 
you!

As for the technical specifications, I'd also recommend you'd separate those 
out as well.  Some of your concerns seem to deal with native code access which 
seems a separate issue than modular design of code.  I have also been looking 
around for good Panama/FMA examples and haven't seen anything non-trivial yet.  
But even those can be done with/without the Java Module System (JPMS).

Looking forward to any other replies with interest.

Dan

[1] - https://www.apache.org/theapacheway/

On 3/17/21, 10:08 PM, "leerho"  wrote:

Daniel,
Thank you for your reply.


> Can you clarify what you mean by an "Apache Java project"?


I would prefer to examine a project that has a formal release process and
an active community. So a TLP or incubating project would be great.  In
this case I was equating "Apache" = "Quality"  :)

I'm not so interested in random code on the Internet that just happens to
be Apache licensed :)

Is there a particular use case you are interested in?


I am seriously looking at *redesigning* our JDK8 Library using Java Modules
leveraging JDK16+/Panama/FMA and completely replacing the need for Unsafe,
etc.  (Not just adapting our JDK8 code to run on JDK9+ and accessing Java
internals using JVM args.)

This is a major undertaking so being able to look at projects that have
already gone through that process would be helpful.

Thank you,

Lee.

On Wed, Mar 17, 2021 at 3:42 PM Daniel B. Widdis  wrote:

> Can you clarify what you mean by an "Apache Java project"?
>  - A TLP?
>  - An incubating project?
>  - A project anywhere that is released under the Apache license?
>
> There's actually no need to "migrate code" in many cases, just add some
> files. Is there a particular use case you are interested in?
>
> On Wed, Mar 17, 2021 at 3:11 PM leerho  wrote:
>
> > Folks,
> > Is anyone aware of an Apache Java project that has actually migrated
> their
> > code from Java 8 to the Java Platform Module System (JPMS)?
> >
> > Thanks,
> > Lee.
> >
>
>
> --
> Dan Widdis
>



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

Re: [VOTE] Release Apache TubeMQ (Incubating) 0.8.0-incubating RC2

[Daniel Widdis]

To continue to provide clarity:

The current version (7.5.11) still has AL2.0 licensing; I just downloaded it to 
confirm.  Any version from 7.3.7 and newer (at this point in time) is an 
acceptable dependency.

If Oracle chooses to change the license again for future releases that could 
pose a problem, but personally I don't think that's likely.


On 2/10/21, 9:58 PM, "Goson zhang"  wrote:

Yes, restricting the use of its version number in the project is still a
relatively passive solution: if we want to upgrade the version, but the
corresponding version authorization is adjusted, our project still has
restrictions.

The biggest dependency of replacing this component lies in the
active/standby switching function: currently we are not considering
expanding its scope of use, and we are analyzing the new active/standby
switching scheme, and want to temporarily maintain the existing method
before completing this task, until the real-time active/standby switching
is provided.

I plan to explain this problem in detail in the supplementary binary
dependency package LICENSE, until the solution is adjusted to completely
solve it.

See if this is OK?


Justin Mclean  于2021年2月11日周四 下午1:46写道：

> Hi,
>
> > 1. Can we meet the requirements of this open source agreement by
> > restricting the version of this component to 7.X.Y?
> > For Berkeley DB JE (Java Edition), this component itself is TubeMQ to
> store
> > metadata and switch between active and standby. It is not very deep, but
> it
> > need to take some time to adjust.
>
> Possibly if 7.X.Y is clearly Apache licensed, however as time goes on you
> may need to move to a newer version (due to security concerns) and what
> will be become an issue.
>
> > 2. Or have to switch to other components?
> > If so, for this release,  do I restore the "WIP" label to complete the
> > version release first?
> > Then adjust the implementation plan later, and finally remove this
> > component in the final version.
>
> That would be a valid path forward.
>
> Thanks,
> Justin



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

Re: [VOTE] Release Apache TubeMQ (Incubating) 0.8.0-incubating RC2

[Daniel Widdis]

I believe that as long as you are using 7.3.7 or newer (such as the current 
7.5.11 version) of the Java Edition you are fine to include this as a 
dependency.

 

I will defer to more experienced people on this list on the most appropriate 
language to indicate this minimum version and the JE specification in your 
LICENSE file, and whether there are any additional actions you should take to 
require this minimum version.

 

 

From: Goson zhang 
Reply-To: 
Date: Wednesday, February 10, 2021 at 9:20 PM
To: Daniel Widdis 
Cc: 
Subject: Re: [VOTE] Release Apache TubeMQ (Incubating) 0.8.0-incubating RC2

 

Hi Daniel && Justin && all:

 

What should we do in this situation?

When we open sourced the project, we did a LICENSE analysis for all dependent 
packages, and adjusted to exclude unfriendly protocol components; for Berkeley 
DB JE (Java Edition), as Daniel said, the Berkeley DB JE (Java Edition) 
LICENSEs are Inconsistent before and after version, the version before 7.XY was 
the GNU AGPL v3 protocol, but it became the Apache V2 version in 7.XY, so we 
adopted the 7.X.Y version as our dependent component.


We are not very professional in this area, so we would like to seek the 
opinions of experts:

1. Can we meet the requirements of this open source agreement by restricting 
the version of this component to 7.X.Y?
For Berkeley DB JE (Java Edition), this component itself is TubeMQ to store 
metadata and switch between active and standby. It is not very deep, but it 
need to take some time to adjust.

2. Or have to switch to other components?
If so, for this release,  do I restore the "WIP" label to complete the version 
release first? 
Then adjust the implementation plan later, and finally remove this component in 
the final version.

 

Thanks!!

 

Daniel Widdis  于2021年2月11日周四 下午12:49写道：

I believe there may be some confusion between Berkeley DB which is indeed GNU 
AGPL v3, and Berkeley DB JE (Java Edition) which was previously GNU AGPL v3 but 
switched to Apache License 2.0 with the 7.3.7 release.

Current Berkeley DB JE license is at [3]

3. https://www.oracle.com/downloads/licenses/berkeleydb-jeoslicense.html

On 2/10/21, 8:25 PM, "Justin Mclean"  wrote:

Hi,

> We should have discussed this issue [1], and in August 2020, I sent an
> email to berkeleydb-info...@oracle.com in accordance with the requirements
> of [2] to clarify my question, but it not responded to me. And the LICENSE
> of we choosed 7.3.7 berkeleydb,  is licensed under Apache V2 license.

My concern is that is not under the Apache license. The link here (which 
you provided) is that it is OS only is it is not for commercial use [1]. Also 
[1] points to [2] which states it’s GPL which is not compatible with the Apache 
V2 license.

Thanks,
Justin

1. 
https://www.oracle.com/database/technologies/related/berkeleydb-downloads.html
2. 
https://www.oracle.com/database/technologies/related/berkeleydb/berkeleydb-licensing.html
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache TubeMQ (Incubating) 0.8.0-incubating RC2

[Daniel Widdis]

I believe there may be some confusion between Berkeley DB which is indeed GNU 
AGPL v3, and Berkeley DB JE (Java Edition) which was previously GNU AGPL v3 but 
switched to Apache License 2.0 with the 7.3.7 release.

Current Berkeley DB JE license is at [3]

3. https://www.oracle.com/downloads/licenses/berkeleydb-jeoslicense.html

On 2/10/21, 8:25 PM, "Justin Mclean"  wrote:

Hi,

> We should have discussed this issue [1], and in August 2020, I sent an
> email to berkeleydb-info...@oracle.com in accordance with the requirements
> of [2] to clarify my question, but it not responded to me. And the LICENSE
> of we choosed 7.3.7 berkeleydb,  is licensed under Apache V2 license.

My concern is that is not under the Apache license. The link here (which 
you provided) is that it is OS only is it is not for commercial use [1]. Also 
[1] points to [2] which states it’s GPL which is not compatible with the Apache 
V2 license.

Thanks,
Justin

1. 
https://www.oracle.com/database/technologies/related/berkeleydb-downloads.html
2. 
https://www.oracle.com/database/technologies/related/berkeleydb/berkeleydb-licensing.html
-
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: Travis job on github

[Daniel Widdis]

The delays at Travis were primarily due to a few things:
-  Limited capacity and high demand
-  Abuse of the free service by cryptocurrency miners

The problem of the crypto miners has been pretty much resolved, but 1 would 
still be an issue on Travis if there hadn't been a mass exit to GHA last year.

As GHA runs on the Azure cloud, where there's hundreds of thousands of servers 
available and typically a lot of idle capacity, I doubt we'll see anything like 
the delays at Travis.

If capacity does become an issue there are many simple steps Microsoft/Github 
could take first to reduce the load, such as:
 - limiting concurrent jobs for free accounts
 - allowing auto-terminating a set of jobs when it's triggered again in a short 
time frame
 - allowing re-run of only a single failed job instead of an entire matrix

All of these were features/requirements at Travis because they were capacity 
limited. The fact that such features don't (yet) exist indicates there is not a 
capacity concern (yet).  Seems they're focusing more on building out the 
service and gaining more customers and open source contributions to the 
available actions.


On 2/3/21, 6:07 PM, "Weiwei Yang"  wrote:

Hi Greg

Agreed. No assumption has been made.
I was just hoping that GitHub can hold it up. Just in case the delays come
back again, the Apache community can look for a solution together.
Asking for help from Microsoft is just one possible option.

Weiwei


On Wed, Feb 3, 2021 at 2:40 AM Greg Stein  wrote:

> On Wed, Feb 3, 2021, 01:36 Weiwei Yang  wrote:
> >...
>
> > we can communicate with Microsoft about giving the Apache
> > repo some extra resources.
> > I guess it won't be a big problem to such a wealthy company 
> >
>
> Their wealth does not mean they can give us anything we want. That is a
> fallacy. Their wealth means they can be kind to us, and we should be
> thankful. Microsoft is extremely generous to the Foundation, across many
> paths (sponsorship, Azure, MSDN, etc). Let us not presume that we can keep
> asking for more.
>
> Regards,
> -g
>



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

Re: Travis job on github

[Daniel Widdis]

t; > > > >
> > > > >
> > > >
> > >
> >
> 
https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
> > > > > > >
> > > > > > > On Sun, 31 Jan 2021 at 00:53, leerho  wrote:
> > > > > > > >
> > > > > > > > I am trying to move from Travis to GitHub actions for 
exactly
> > > this
> > > > > > > reason,
> > > > > > > > but in that process discovered that our coverage reporting
> > chain
> > > of
> > > > > > > > Maven/Java/Jacoco/Coveralls does not port to GHA because the
> > > > current
> > > > > > GHA
> > > > > > > > adapter for Coveralls only supports LCOV format which Jacoco
> > > > doesn’t
> > > > > > > > generate.  Converting to CodeCov is a nonstarter because
> > CodeCov
> > > is
> > > > > $$!
> > > > > > > >
> > > > > > > > If anybody has any ideas, please let me know!
> > > > > > > >
> > > > > > > > Lee.
> > > > > > > >
> > > > > > > > On Thu, Jan 28, 2021 at 10:02 PM Weiwei Yang <
> w...@apache.org>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > Oh, that's good. Then we have no problem at all.
> > > > > > > > > Thank you Daniel for pointing this out : )
> > > > > > > > >
> > > > > > > > > On Thu, Jan 28, 2021 at 9:48 PM Daniel Widdis <
> > > wid...@gmail.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > The quota is for private repos.  Public/open-source 
repos
> > are
> > > > > > > essentially
> > > > > > > > > > unlimited.
> > > > > > > > > >
> > > > > > > > > > On 1/28/21, 9:44 PM, "Weiwei Yang" 
> > wrote:
> > > > > > > > > >
> > > > > > > > > > Thank you all for the suggestions.
> > > > > > > > > > Looks like github action is an option, we'll give a
> > try.
> > > > > > > > > > Noticed they offer 2000 action minutes/month[1] for
> > > free, I
> > > > > > think
> > > > > > > > > that
> > > > > > > > > > should be enough for most cases.
> > > > > > > > > >
> > > > > > > > > > [1]
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 
https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions
> > > > > > > > > >
> > > > > > > > > > On Thu, Jan 28, 2021 at 6:36 PM Matt Sicker <
> > > > > boa...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > There's also some hosted CI services here like
> > Jenkins,
> > > > > > > BuildBot,
> > > > > > > > > > > etc., which may have less queueing issues 
depending
> > on
> > > > > which
> > > > > > > > > service
> > > > > > > > > > > attracts the most build minute usage.
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 28 Jan 2021 at 20:23, Jon Malkin <
> > > > > > jon.mal...@gmail.com
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > &

Re: [VOTE] Graduate Apache Ratis as TLP Project

[Daniel Widdis]

Adding my congratulations and a non-binding +1

On 1/29/21, 12:32 PM, "Uma gangumalla"  wrote:

Dear Incubator Community,

 We have discussed Apache Ratis Podling graduation in the incubator general
DISCUSS thread[1] and We did not see any objections to proceed for voting.
Here is the official vote for graduating Apache Ratis project as TLP.

Please provide your in the following options:
[ ] +1 - Recommend graduation of Apache Ratis as a TLP
[ ]  0 - I don't feel strongly about it, but don't object
[ ] -1 - Do not recommend graduation of Apache Ratis because...

The VOTE will open for at least 72 hours.

Just to summarize again:
Apache Ratis project is a very active project and the community has grown
well by following the Apache way in the process. It produced several
releases by having diverse people as release managers. I and the community
strongly believe that it's ready for graduation.

The Apache Ratis project has been an Apache incubator project for nearly 3
year. Since then the community has grown and followed Apache Way. Some
highlights include:
* 7 releases given ( including 1.0.0 and 0.0.1 alpha ) by having
different people as release managers
* 50 contributors ( from report)
* 28 committers
* More than 1161 Jiras created, 905 resolved or closed
* > 293 pull requests in github
* One of the biggest positives for this community is that most of the
members in this community have a lot of experience in other Apache projects
already.

Some additional note about the resolution below:
The current PPMC will be transitioned to the PMC. We have invited some of
the mentors in the current PPMC who like to stay involved.
We are also adding Siddharth and Jie Wang into PMC as we believe they are
committed to the project and a good addition to PMC.

We have already voted for Ratis TLP in the Ratis Podling community. Please
find the voting threads for reference. Ratis PPMC DISCUSS thread: [2],
Ratis PPMC Vote: [3] and Ratis Community: [4]

To make easy for you to review, here is the *resolution text*[5] copied:
==
Establish the Apache Ratis Project

WHEREAS, the Board of Directors deems it to be in the best interests of
the Foundation and consistent with the Foundation's purpose to establish
a Project Management Committee charged with the creation and maintenance
of open-source software, for distribution at no charge to the public,
related to A java implementation for RAFT consensus protocol.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
(PMC), to be known as the "Apache Ratis Project", be and hereby is
established pursuant to Bylaws of the Foundation; and be it further

RESOLVED, that the Apache Ratis Project be and hereby is responsible for
the creation and maintenance of software related to A java
implementation for RAFT consensus protocol; and be it further

RESOLVED, that the office of "Vice President, Apache Ratis" be and
hereby is created, the person holding such office to serve at the
direction of the Board of Directors as the chair of the Apache Ratis
Project, and to have primary responsibility for management of the
projects within the scope of responsibility of the Apache Ratis Project;
and be it further

RESOLVED, that the persons listed immediately below be and hereby are
appointed to serve as the initial members of the Apache Ratis Project:

 * Anu Engineer  [Hadoop, Ozone PMC,
Incubator Committer]
 * Arpit Agarwal [ ASF Member, Hadoop, Ozone,
Incubator PMC]
 * Enis Soztutar [ASF Member, Hadoop, HBase,
Incubator PMC and also PMC in curator, gora, phoenix]
 * Hanisha Koneru[Hadoop, Ozone PMC,
Incubator Committer]
 * Jie Wang  [Incubator, Ozone Committer]
 * Jing Zhao [Hadoop PMC, Incubator Committer]
 * Jitendra Nath Pandey   [ASF Member, Hadoop, Ozone,
Incubator PMC and also PMC in ambari, atlas, tez]
 * Josh Elser [ASF Member, HBase, Incubator
PMC, and also PMC in accumulo, calcite, fluo, phoenix, rya]
 * Lokesh Jain   [Hadoop, Ozone PMC, Incubator
Committer]
 * Marton Elek[Hadoop, Ozone PMC, Incubator
Committer]
 * Mingliang Liu  [Hadoop PMC, Incubator
Committer]
 * Mukul Kumar Singh  [Hadoop, Ozone PMC, Incubator
Committer]
 * Shashikant Banerjee   [Hadoop, Ozone PMC,
Incubator Committer]
 * Siddharth Wagle[Ambari, Ozone PMC, Hadoop,
Incubator Committer]
 * Tsz-wo Sze [ASF Member, Hadoop, Ozone
PMC, Incubator Committer]
 * Uma Maheswara Rao G   [ASF Member, Hadoop, Ozone,
Incubator PMC and PMC in bookkeeper, carbondata]
 * Xiaoyu Yao  

Re: Travis job on github

[Daniel Widdis]

The quota is for private repos.  Public/open-source repos are essentially 
unlimited.

On 1/28/21, 9:44 PM, "Weiwei Yang"  wrote:

Thank you all for the suggestions.
Looks like github action is an option, we'll give a try.
Noticed they offer 2000 action minutes/month[1] for free, I think that
should be enough for most cases.

[1]

https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions

On Thu, Jan 28, 2021 at 6:36 PM Matt Sicker  wrote:

> There's also some hosted CI services here like Jenkins, BuildBot,
> etc., which may have less queueing issues depending on which service
> attracts the most build minute usage.
>
> On Thu, 28 Jan 2021 at 20:23, Jon Malkin  wrote:
> >
> > There was an issue a few months ago where the GitHub Actions queue was
> very
> > laggy for Apache jobs, so just make sure you're trying to be efficient
> > about it. It's also a shared resource.
> >
> > That said, (part of) our recently graduated project uses GitHub Actions
> and
> > we've been happy overall. Another part is currently moving to it from
> > Travis for the exact same reason.
> >
> >   jon
> >
> > On Thu, Jan 28, 2021, 6:15 PM Juan Pan  wrote:
> >
> > > Hi Weiwei,
> > >
> > >
> > > +1 for Jeff’s suggestion.
> > > We also transfer to GitHub Action, and It generally works well so far.
> > >
> > >
> > >
> > >
> > > 
> > >Juan Pan (Trista)
> > >
> > > Senior DBA & PMC of Apache ShardingSphere
> > > E-mail: panj...@apache.org
> > >
> > >
> > >
> > >
> > > On 01/29/2021 08:00，Jeff Zhang wrote：
> > > Hi Weiwei,
> > >
> > > May you can consider to use github action for CI
> > >
> > >
> > >
> > > Weiwei Yang  于2021年1月29日周五 上午7:58写道：
> > >
> > > Hi,
> > >
> > > The Apache YuniKorn (Incubating) team leverages Travis to run
> pre-commit
> > > checks, but recently the Travis Job stays in the queue for long hours
> (6+
> > > hours, sometimes more than 10 hours) . This is highly impacting the
> > > productivity. I have reached the Travis support and the response I got
> was
> > > the jobs got rate limited under Apache repo. Is there any suggestion
> how to
> > > fix this issue?
> > >
> > > Thanks
> > > Weiwei
> > >
> > >
> > >
> > > --
> > > Best Regards
> > >
> > > Jeff Zhang
> > >
>
> -
> 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: Where to get feedback on a project before formulating a proposal

[Daniel Widdis]

Yes, of course.  Still will need a few others. 

I’ll try to put together a mentor recruitment post and send it here in a few 
weeks. 

> On 25 Nov 2020, at 16:24, Justin Mclean  wrote:
> 
> Hi,
> 
>> The idea was first brought up over a year ago by a member of the community,
>> although it's been me dragging my feet.  They are actually an ASF member.
> 
> Being an ASF member that can be a mentor or the champion. Have you asked them 
> if they would be willing to do that?
> 
> 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

Where to get feedback on a project before formulating a proposal

[Daniel Widdis]

I manage a mature open source project (as the “benevolent dictator”) and am 
considering transitioning my project to community management in the Apache Way. 
 I have spent a few weeks reading about the Apache Incubator process including 
most documentation I can find on the site, conference presentations, and other 
materials.  I am still interested, but would like to speak more with other 
community members prior to creating a proposal.

The guide for formulating a proposal [1] has a "Preparation" section and I am 
working through those steps.  It says, in part:
> Before starting on the formal proposal, recruit a Champion. The Champion 
> understands Apache and should be able to help navigate the process and put 
> your proposal together.

In addition, the Cookbook [2] states:
> To enter the Incubator, your project needs a champion and at least two or 
> three mentors.
>
> These people need to be part of the Incubator PMC, which ASF Members can join 
> just by asking.
> 
> The Champion helps the incoming podling in the process of creating their 
> proposal and acts as a liaison between the podling and the Incubator PMC for 
> the initial steps, at least until the podling’s proposal is accepted.

However, none of the documents states exactly how I am supposed to recruit a 
champion and mentors or where I should find them.  The first official step in 
the incubation process seems to be a proposal to this mailing list, but it does 
not suggest where to conduct pre-proposal communications.  I hope I am 
addressing this email to the correct audience.  If not, please redirect me to a 
more appropriate list.

I am interested in:

1. Evaluating whether my project is a good fit for Apache and, if so, finding a 
Champion and Mentors.

2. Discussing the experience of members of other projects which began their 
life with a "benevolent dictator" and transitioned to a community project.

Thank you for any information you can provide to help me start this journey.


[1] - https://incubator.apache.org/guides/proposal.html 
[2] - https://incubator.apache.org/cookbook/#finding_a_champion_and_mentors



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