Re: [VOTE] Release Apache KIE(incubating) v10.0.0-rc2

[Alex Porcelli]

The binary variations would take quite some time to get there… would be
possible to - for the first release - limit the scope of the first
incubating release to the first step you mentioned (vanilla LICENSE,
NOTICE, DISCLAIMER-WIP)?

I’m afraid would take quite a lot to get to the level of details provided
by Spark binary variations.

I’m also still not 100% sure about container images, what about base image
like OS (take Red Hat UBI for example). How to proceed?

Thank you again for the clarifications.

Regards,
Alex


On Thu, Oct 10, 2024 at 6:59 PM PJ Fanning  wrote:

> You could start by adding the vanilla LICENSE, NOTICE, DISLAIMER-WIP
> from https://github.com/apache/incubator-kie-tools into each tar.gz.
>
> Later, you would need to update the LICENSE and NOTICE to comply with
> the licenses/notices of any 3rd party source or binaries that appear
> in the tar.gz.
>
> If you look at Apache Spark, they have LICENSE/NOTICE and
> LICENSE-binary/NOTICE-binary.
> https://github.com/apache/spark
>
> The LICENSE/NOTICE pair is copied into the source release and includes
> details of 3rd party source in the release.
> The LICENSE-binary/NOTICE-binary pair is copied into their binary
> artifacts and includes details of 3rd party binaries (jars) in those
> artifacts.
>
> On Thu, 10 Oct 2024 at 23:33, Alex Porcelli  wrote:
> >
> > PJ,
> >
> > There are about 22 container images that are .tar.gz files, all those
> > files were generated with docker export command. My question is it
> > really needed to add to those image .tar.gz the LICENSE, NOTICE and
> > DISCLAIMER-WIP files?
> >
> > If yes... is there any example how to write a NOTICE file for container
> images?
> >
> > Thank you for your support!
> >
> > Regards,
> > Alex
> >
> > On Thu, Oct 10, 2024 at 11:02 AM PJ Fanning 
> wrote:
> > >
> > > The KIE PPMC will need to vote on the RC3. Usually votes in PPMC
> > > happen before the IPMC vote. I'm not 100% sure if there is an absolute
> > > requirement that the 2 votes need to be held at different times.
> > > Ideally the mentors of the KIE project will get involved in the PPMC
> > > vote because they know what to check wrt a valid IPMC release.
> > >
> > > On Thu, 10 Oct 2024 at 15:24, Jason Porter 
> wrote:
> > > >
> > > > PJ, since we're new to doing the release,  for RC3 do we need to do
> another 72 hour voting period for the KIE PPMC, or do we roll an RC3 and
> start a new vote here?
> > > >
> > > > On 2024/10/09 23:17:48 PJ Fanning wrote:
> > > > > Thanks for your explanation. I fully understand where you are
> coming from. I don't want to delay you unduly.
> > > > >
> > > > > For me, if you sort out the names of the release files that would
> be the main thing for me. Ideally, you would also use the filename
> 'DISCLAIMER-WIP' for the DISCLAIMER file.
> > > > >
> > > > > For instance, with
> > > > > 10.0.0-rc2/incubator-kie-10.0.0-rc2-sources.zip
> > > > >
> > > > > Could you call the rc3?
> > > > > 10.0.0-rc3/apache-kie-10.0.0-incubating-src.zip (or something of
> this ilk)
> > > > >
> > > > > I would also appreciate it if you left it a day or 2 before
> creating the RC3 to allow other IPMC members to have a look at the RC2.
> > > > > I suspect that you might save a little bit of time getting
> feedback now instead of hitting issues with the RC3.
> > > > >
> > > > >
> > > > > On 2024/10/09 23:03:07 Alex Porcelli wrote:
> > > > > > Thank you for all the valuable feedback. I appreciate the time
> you've
> > > > > > taken to review the release candidate so thoroughly.
> > > > > >
> > > > > > I'd like to provide some context about Apache KIE podling. We're
> a
> > > > > > mature project with over 15 years of history, and we've been on
> the
> > > > > > Apache Incubation journey for more than a year now. During this
> time,
> > > > > > we've made many changes to fit into the Apache Foundation,
> including
> > > > > > adjusting headers, changing CI, tweaking code, and untangling
> > > > > > dependencies and removing legal restricted dependencies. We've
> also
> > > > > > simplified the structure, going from 23 separate repositories to
> just
> > > > > > a handful.
> > > > > >
> > > > &g

Re: [VOTE] Release Apache KIE(incubating) v10.0.0-rc2

[Alex Porcelli]

PJ,

There are about 22 container images that are .tar.gz files, all those
files were generated with docker export command. My question is it
really needed to add to those image .tar.gz the LICENSE, NOTICE and
DISCLAIMER-WIP files?

If yes... is there any example how to write a NOTICE file for container images?

Thank you for your support!

Regards,
Alex

On Thu, Oct 10, 2024 at 11:02 AM PJ Fanning  wrote:
>
> The KIE PPMC will need to vote on the RC3. Usually votes in PPMC
> happen before the IPMC vote. I'm not 100% sure if there is an absolute
> requirement that the 2 votes need to be held at different times.
> Ideally the mentors of the KIE project will get involved in the PPMC
> vote because they know what to check wrt a valid IPMC release.
>
> On Thu, 10 Oct 2024 at 15:24, Jason Porter  wrote:
> >
> > PJ, since we're new to doing the release,  for RC3 do we need to do another 
> > 72 hour voting period for the KIE PPMC, or do we roll an RC3 and start a 
> > new vote here?
> >
> > On 2024/10/09 23:17:48 PJ Fanning wrote:
> > > Thanks for your explanation. I fully understand where you are coming 
> > > from. I don't want to delay you unduly.
> > >
> > > For me, if you sort out the names of the release files that would be the 
> > > main thing for me. Ideally, you would also use the filename 
> > > 'DISCLAIMER-WIP' for the DISCLAIMER file.
> > >
> > > For instance, with
> > > 10.0.0-rc2/incubator-kie-10.0.0-rc2-sources.zip
> > >
> > > Could you call the rc3?
> > > 10.0.0-rc3/apache-kie-10.0.0-incubating-src.zip (or something of this ilk)
> > >
> > > I would also appreciate it if you left it a day or 2 before creating the 
> > > RC3 to allow other IPMC members to have a look at the RC2.
> > > I suspect that you might save a little bit of time getting feedback now 
> > > instead of hitting issues with the RC3.
> > >
> > >
> > > On 2024/10/09 23:03:07 Alex Porcelli wrote:
> > > > Thank you for all the valuable feedback. I appreciate the time you've
> > > > taken to review the release candidate so thoroughly.
> > > >
> > > > I'd like to provide some context about Apache KIE podling. We're a
> > > > mature project with over 15 years of history, and we've been on the
> > > > Apache Incubation journey for more than a year now. During this time,
> > > > we've made many changes to fit into the Apache Foundation, including
> > > > adjusting headers, changing CI, tweaking code, and untangling
> > > > dependencies and removing legal restricted dependencies. We've also
> > > > simplified the structure, going from 23 separate repositories to just
> > > > a handful.
> > > >
> > > > We understand there are some issues with the current release
> > > > candidate. We're starting a RC3 now and will make sure to include
> > > > 'incubating' in the filenames and revise the NOTICE file to focus on
> > > > source code rather than binary dependencies. We'll also check how it's
> > > > possible to add the LICENSE, NOTICE, and DISCLAIMER-WIP files to the
> > > > container image exports (I'm not sure if this is possible, to be
> > > > honest.. but we'll check).
> > > >
> > > > We know that some changes might take more time due to the project's
> > > > complexity. We see incubation as a journey and we're committed to
> > > > improving step by step. Right now, the main goal is to get the first
> > > > release out after over a year of hard work, while we keep working
> > > > towards meeting all Apache standards. We have a large community of
> > > > users that are anxious to get access to this release... as this is the
> > > > first time in 15 years that we don't have a release in more than a
> > > > year.
> > > >
> > > > Best,
> > > > Alex
> > > >
> > > > On Wed, Oct 9, 2024 at 6:36 PM PJ Fanning  wrote:
> > > > >
> > > > > I chose one of the binary artifacts at random.
> > > > > incubator-kie-10.0.0-rc2-sonataflow-operator-image.tar.gz
> > > > >
> > > > > It contains no LICENSE file. I don't think this is right. I think all
> > > > > the zips and tar.gz files in the RC folder [1] should contain a
> > > > > LICENSE, NOTICE and DISCLAIMER-WIP.
> > > > >
> > > > > The 

Re: [VOTE] Release Apache KIE(incubating) v10.0.0-rc2

[Alex Porcelli]

For rc3 we’ll make the adjustments for the names.

We’ll start changing the pipelines to accommodate the new naming, and wait
a bit longer to additional feedback - thank you for the tip!

Regards,
Alex


On Wed, Oct 9, 2024 at 7:18 PM PJ Fanning  wrote:

> Thanks for your explanation. I fully understand where you are coming from.
> I don't want to delay you unduly.
>
> For me, if you sort out the names of the release files that would be the
> main thing for me. Ideally, you would also use the filename
> 'DISCLAIMER-WIP' for the DISCLAIMER file.
>
> For instance, with
> 10.0.0-rc2/incubator-kie-10.0.0-rc2-sources.zip
>
> Could you call the rc3?
> 10.0.0-rc3/apache-kie-10.0.0-incubating-src.zip (or something of this ilk)
>
> I would also appreciate it if you left it a day or 2 before creating the
> RC3 to allow other IPMC members to have a look at the RC2.
> I suspect that you might save a little bit of time getting feedback now
> instead of hitting issues with the RC3.
>
>
> On 2024/10/09 23:03:07 Alex Porcelli wrote:
> > Thank you for all the valuable feedback. I appreciate the time you've
> > taken to review the release candidate so thoroughly.
> >
> > I'd like to provide some context about Apache KIE podling. We're a
> > mature project with over 15 years of history, and we've been on the
> > Apache Incubation journey for more than a year now. During this time,
> > we've made many changes to fit into the Apache Foundation, including
> > adjusting headers, changing CI, tweaking code, and untangling
> > dependencies and removing legal restricted dependencies. We've also
> > simplified the structure, going from 23 separate repositories to just
> > a handful.
> >
> > We understand there are some issues with the current release
> > candidate. We're starting a RC3 now and will make sure to include
> > 'incubating' in the filenames and revise the NOTICE file to focus on
> > source code rather than binary dependencies. We'll also check how it's
> > possible to add the LICENSE, NOTICE, and DISCLAIMER-WIP files to the
> > container image exports (I'm not sure if this is possible, to be
> > honest.. but we'll check).
> >
> > We know that some changes might take more time due to the project's
> > complexity. We see incubation as a journey and we're committed to
> > improving step by step. Right now, the main goal is to get the first
> > release out after over a year of hard work, while we keep working
> > towards meeting all Apache standards. We have a large community of
> > users that are anxious to get access to this release... as this is the
> > first time in 15 years that we don't have a release in more than a
> > year.
> >
> > Best,
> > Alex
> >
> > On Wed, Oct 9, 2024 at 6:36 PM PJ Fanning  wrote:
> > >
> > > I chose one of the binary artifacts at random.
> > > incubator-kie-10.0.0-rc2-sonataflow-operator-image.tar.gz
> > >
> > > It contains no LICENSE file. I don't think this is right. I think all
> > > the zips and tar.gz files in the RC folder [1] should contain a
> > > LICENSE, NOTICE and DISCLAIMER-WIP.
> > >
> > > The LICENSE and NOTICE files should be tailored to the contents of
> > > each zips and tar.gz file.
> > >
> > > [1] https://dist.apache.org/repos/dist/dev/incubator/kie/10.0.0-rc2/
> > >
> > > On Wed, 9 Oct 2024 at 23:27, PJ Fanning  wrote:
> > > >
> > > > Incubator PMC members expect to find no jars or zips in source
> > > > releases. There may be good reasons to have them as test resources
> but
> > > > you should document them to make it easier for reviewers. Many IPMC
> > > > members will use tools like Apache Rat to validate the release and
> the
> > > > binary files will be reported as out of the ordinary.
> > > >
> > > > I would also suggest that source release zip should have a base
> > > > directory that includes everything instead of having the LICENSE etc
> > > > in the root folder. It makes it easier for reviewers if the zip
> > > > doesn't unzip files into their working dir. Again, I would encourage
> > > > you to look at other ASF Incubator or non-Incubator source releases
> to
> > > > see what they look like.
> > > >
> > > > I still remain -1 because of the 'incubating' part of the file name
> > > > not being there.
> > > >
> > > > On Wed, 9 Oct 2024 at 23:20, Alex Por

Re: [VOTE] Release Apache KIE(incubating) v10.0.0-rc2

[Alex Porcelli]

Thank you for all the valuable feedback. I appreciate the time you've
taken to review the release candidate so thoroughly.

I'd like to provide some context about Apache KIE podling. We're a
mature project with over 15 years of history, and we've been on the
Apache Incubation journey for more than a year now. During this time,
we've made many changes to fit into the Apache Foundation, including
adjusting headers, changing CI, tweaking code, and untangling
dependencies and removing legal restricted dependencies. We've also
simplified the structure, going from 23 separate repositories to just
a handful.

We understand there are some issues with the current release
candidate. We're starting a RC3 now and will make sure to include
'incubating' in the filenames and revise the NOTICE file to focus on
source code rather than binary dependencies. We'll also check how it's
possible to add the LICENSE, NOTICE, and DISCLAIMER-WIP files to the
container image exports (I'm not sure if this is possible, to be
honest.. but we'll check).

We know that some changes might take more time due to the project's
complexity. We see incubation as a journey and we're committed to
improving step by step. Right now, the main goal is to get the first
release out after over a year of hard work, while we keep working
towards meeting all Apache standards. We have a large community of
users that are anxious to get access to this release... as this is the
first time in 15 years that we don't have a release in more than a
year.

Best,
Alex

On Wed, Oct 9, 2024 at 6:36 PM PJ Fanning  wrote:
>
> I chose one of the binary artifacts at random.
> incubator-kie-10.0.0-rc2-sonataflow-operator-image.tar.gz
>
> It contains no LICENSE file. I don't think this is right. I think all
> the zips and tar.gz files in the RC folder [1] should contain a
> LICENSE, NOTICE and DISCLAIMER-WIP.
>
> The LICENSE and NOTICE files should be tailored to the contents of
> each zips and tar.gz file.
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/kie/10.0.0-rc2/
>
> On Wed, 9 Oct 2024 at 23:27, PJ Fanning  wrote:
> >
> > Incubator PMC members expect to find no jars or zips in source
> > releases. There may be good reasons to have them as test resources but
> > you should document them to make it easier for reviewers. Many IPMC
> > members will use tools like Apache Rat to validate the release and the
> > binary files will be reported as out of the ordinary.
> >
> > I would also suggest that source release zip should have a base
> > directory that includes everything instead of having the LICENSE etc
> > in the root folder. It makes it easier for reviewers if the zip
> > doesn't unzip files into their working dir. Again, I would encourage
> > you to look at other ASF Incubator or non-Incubator source releases to
> > see what they look like.
> >
> > I still remain -1 because of the 'incubating' part of the file name
> > not being there.
> >
> > On Wed, 9 Oct 2024 at 23:20, Alex Porcelli  wrote:
> > >
> > > All those `binary` files (jar, zips) are needed for testing purposes.
> > >
> > > On Wed, Oct 9, 2024 at 6:16 PM PJ Fanning  wrote:
> > > >
> > > > The NOTICE in the source release is not valid. It is a long list of
> > > > binary dependencies. NOTICE files in source releases are about the
> > > > source code not about binary dependencies that are linked and not
> > > > included directly in the release.
> > > >
> > > > There are compiled jars in the source release. This is not normally 
> > > > allowed.
> > > >
> > > > ./incubator-kie-kogito-runtimes/quarkus/integration-tests/integration-tests-quarkus-gradle/integration-tests-quarkus-gradle-project/gradle/wrapper/gradle-wrapper.jar
> > > > ./incubator-kie-kogito-runtimes/.mvn/wrapper/maven-wrapper.jar
> > > > ./incubator-kie-kogito-runtimes/kogito-codegen-modules/kogito-codegen-core/src/test/resources/empty.jar
> > > > ./incubator-kie-tools/packages/stunner-editors/errai-ui/src/test/resources/less.jar
> > > > ./incubator-kie-kogito-apps/.mvn/wrapper/maven-wrapper.jar
> > > > ./incubator-kie-drools/efesto/efesto-core/efesto-common-api/src/test/resources/TestJar.jar
> > > > ./incubator-kie-drools/efesto/efesto-core/efesto-runtime-manager/efesto-runtime-manager-core/src/test/resources/TestJar.jar
> > > > ./incubator-kie-drools/efesto/efesto-core/efesto-common-core/src/test/resources/TestJar.jar
> > > > ./incubator-kie-drools/drools-compiler/src/test/resources/primespoc.jar
> > > > ./incubator-kie-drool

Re: [VOTE] Release Apache KIE(incubating) v10.0.0-rc2

[Alex Porcelli]

All those `binary` files (jar, zips) are needed for testing purposes.

On Wed, Oct 9, 2024 at 6:16 PM PJ Fanning  wrote:
>
> The NOTICE in the source release is not valid. It is a long list of
> binary dependencies. NOTICE files in source releases are about the
> source code not about binary dependencies that are linked and not
> included directly in the release.
>
> There are compiled jars in the source release. This is not normally allowed.
>
> ./incubator-kie-kogito-runtimes/quarkus/integration-tests/integration-tests-quarkus-gradle/integration-tests-quarkus-gradle-project/gradle/wrapper/gradle-wrapper.jar
> ./incubator-kie-kogito-runtimes/.mvn/wrapper/maven-wrapper.jar
> ./incubator-kie-kogito-runtimes/kogito-codegen-modules/kogito-codegen-core/src/test/resources/empty.jar
> ./incubator-kie-tools/packages/stunner-editors/errai-ui/src/test/resources/less.jar
> ./incubator-kie-kogito-apps/.mvn/wrapper/maven-wrapper.jar
> ./incubator-kie-drools/efesto/efesto-core/efesto-common-api/src/test/resources/TestJar.jar
> ./incubator-kie-drools/efesto/efesto-core/efesto-runtime-manager/efesto-runtime-manager-core/src/test/resources/TestJar.jar
> ./incubator-kie-drools/efesto/efesto-core/efesto-common-core/src/test/resources/TestJar.jar
> ./incubator-kie-drools/drools-compiler/src/test/resources/primespoc.jar
> ./incubator-kie-drools/drools-compiler/src/test/resources/eventing-example.jar
> ./incubator-kie-drools/drools-compiler/src/test/resources/KAModelTest.jar
> ./incubator-kie-drools/drools-compiler/src/test/resources/JarWithSourceFiles.jar
> ./incubator-kie-drools/drools-test-coverage/test-compiler-integration/src/test/resources/only-jar-pojo-not-kjar-no-kmodule-1.0.0.jar
> ./incubator-kie-drools/drools-test-coverage/test-compiler-integration/src/test/resources/org/drools/mvel/compiler/compiler/xml/changeset/changeset.jar
> ./incubator-kie-drools/drools-test-coverage/test-compiler-integration/src/test/resources/billasurf.jar
> ./incubator-kie-drools/drools-test-coverage/test-compiler-integration/src/test/resources/kie-project-simple-1.0.0.jar
> ./incubator-kie-drools/drools-test-coverage/test-compiler-integration/src/test/resources/testEnum.jar
> ./incubator-kie-drools/drools-verifier/drools-verifier-drl/src/test/resources/org/drools/verifier/model.jar
> ./incubator-kie-drools/kie-ci/src/test/resources/kjar/kjar-module-before.jar
> ./incubator-kie-drools/kie-ci/src/test/resources/kjar/kjar-module-after.jar
> ./incubator-kie-drools/drools-legacy-test-util/src/test/resources/billasurf.jar
>
> On Wed, 9 Oct 2024 at 23:11, PJ Fanning  wrote:
> >
> > I guess it's fine to use that key then. Do you have the pub, uid, sub
> > headers though? The KEYS file looks strange without them.
> >
> > On Wed, 9 Oct 2024 at 23:08, Alex Porcelli  wrote:
> > >
> > > PJ,
> > >
> > > Apache KIE has a fully automated release (we followed the requirements
> > > from Apache security of reproducible builds etc), so we are able to
> > > use the priv...@kie.apache.org because it was signed directly by the
> > > pipelines.
> > >
> > > The KEYS file content for the priv...@kie.apache.org was provided by
> > > Apache Infra.
> > >
> > > On Wed, Oct 9, 2024 at 6:03 PM PJ Fanning  wrote:
> > > >
> > > > May I also enquire about the signing key? It is usually a personal
> > > > signing key not a shared signing key (priv...@kie.apache.org).
> > > >
> > > > The KEYS file is not ideal afaic. It has no header bit for that
> > > > priv...@kie.apache.org key. Can you add that?
> > > > https://downloads.apache.org/incubator/kie/KEYS
> > > >
> > > > I'm talking about the missing pub, uid, sub headers.
> > > >
> > > > On Wed, 9 Oct 2024 at 22:55, PJ Fanning  wrote:
> > > > >
> > > > > The names of the files in the RC directory [1] seem incorrect.
> > > > > It is good to include the '-rc2' in the directory name but the source
> > > > > and binary archives should omit the '-rc2' part. This is because if
> > > > > and when the votes passes, you need to release the files that were
> > > > > voted on. This means you can't rename them after the vote.
> > > > >
> > > > > -1 binding (fanningpj IPMC)
> > > > > because the source release does not have 'incubating' in the name of
> > > > > the file. I know it has incubating but the requirement is for it to be
> > > > > 'incubating'. You have 'incubator-kie-10.0.0-rc2-sources.zip'
> > > > > In fact, it is 

Re: [VOTE] Release Apache KIE(incubating) v10.0.0-rc2

[Alex Porcelli]

PJ,

Apache KIE has a fully automated release (we followed the requirements
from Apache security of reproducible builds etc), so we are able to
use the priv...@kie.apache.org because it was signed directly by the
pipelines.

The KEYS file content for the priv...@kie.apache.org was provided by
Apache Infra.

On Wed, Oct 9, 2024 at 6:03 PM PJ Fanning  wrote:
>
> May I also enquire about the signing key? It is usually a personal
> signing key not a shared signing key (priv...@kie.apache.org).
>
> The KEYS file is not ideal afaic. It has no header bit for that
> priv...@kie.apache.org key. Can you add that?
> https://downloads.apache.org/incubator/kie/KEYS
>
> I'm talking about the missing pub, uid, sub headers.
>
> On Wed, 9 Oct 2024 at 22:55, PJ Fanning  wrote:
> >
> > The names of the files in the RC directory [1] seem incorrect.
> > It is good to include the '-rc2' in the directory name but the source
> > and binary archives should omit the '-rc2' part. This is because if
> > and when the votes passes, you need to release the files that were
> > voted on. This means you can't rename them after the vote.
> >
> > -1 binding (fanningpj IPMC)
> > because the source release does not have 'incubating' in the name of
> > the file. I know it has incubating but the requirement is for it to be
> > 'incubating'. You have 'incubator-kie-10.0.0-rc2-sources.zip'
> > In fact, it is also the norm to have 'apache' in the file name too.
> > Have a look at the Apache Uniffle candidate [2] to see the format of
> > the filenames.
> >
> > The rule about 'incubating' in the name appears in our Release Guide [3]
> >
> >
> >
> >
> > [1] https://dist.apache.org/repos/dist/dev/incubator/kie/10.0.0-rc2/
> > [2] https://dist.apache.org/repos/dist/dev/incubator/uniffle/0.9.1-rc1/
> > [3] https://incubator.apache.org/guides/releasemanagement.html
> >
> > On Wed, 9 Oct 2024 at 22:40, Alex Porcelli  wrote:
> > >
> > > Hello everyone,
> > >
> > > This is a call for the vote to release Apache KIE(Incubating) v10.0.0-rc2.
> > >
> > > The Apache KIE community has voted and approved the release of Apache
> > > KIE(incubating) v10.0.0-rc2. We now kindly request the IPMC members
> > > review and vote for this release.
> > >
> > > Apache KIE(incubating) - The home of the most popular business
> > > automation open-source technologies including Drools, jBPM,
> > > SonataFlow, Optaplanner, Kogito and Tools.
> > >
> > > KIE community vote thread:
> > > https://lists.apache.org/thread/t72b95d3q1qvcyd7lbqkrt8cdx2cgsp2
> > >
> > > Vote result thread:
> > > https://lists.apache.org/thread/tjbbhlo3bo8dqqxs30f9sbj1wpxgxpyp
> > >
> > > The release candidate:
> > > https://dist.apache.org/repos/dist/dev/incubator/kie/10.0.0-rc2/
> > >
> > > The maven staging repos for this release:
> > > - Drools: 
> > > https://repository.apache.org/content/repositories/orgapachekie-1046
> > > - Optaplanner: 
> > > https://repository.apache.org/content/repositories/orgapachekie-1047
> > > - Kogito Runtimes:
> > > https://repository.apache.org/content/repositories/orgapachekie-1048
> > > - Kogito Apps: 
> > > https://repository.apache.org/content/repositories/orgapachekie-1049
> > > - Kogito Apps - JITExecutor Native Linux:
> > > https://repository.apache.org/content/repositories/orgapachekie-1050
> > > - Kogito Apps - JITExecutor Native Windows:
> > > https://repository.apache.org/content/repositories/orgapachekie-1051
> > > - Kogito Apps - JITExecutor Native MacOS:
> > > https://repository.apache.org/content/repositories/orgapachekie-1052
> > > - KIE Tools - JBPM Quarkus DevUI:
> > > https://repository.apache.org/content/repositories/orgapachekie-1053
> > > - KIE Tools - Sonataflow Quarkus DevUI:
> > > https://repository.apache.org/content/repositories/orgapachekie-1054
> > >
> > > The artifacts are signed with PGP key corresponding to
> > > [priv...@kie.apache.org], found in the KEYS file:
> > >
> > > https://downloads.apache.org/incubator/kie/KEYS
> > >
> > > The vote will be open for at least 72 hours until the necessary number
> > > of votes are reached.
> > >
> > > Please vote accordingly:
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > > To learn more ab

[VOTE] Release Apache KIE(incubating) v10.0.0-rc2

[Alex Porcelli]

Hello everyone,

This is a call for the vote to release Apache KIE(Incubating) v10.0.0-rc2.

The Apache KIE community has voted and approved the release of Apache
KIE(incubating) v10.0.0-rc2. We now kindly request the IPMC members
review and vote for this release.

Apache KIE(incubating) - The home of the most popular business
automation open-source technologies including Drools, jBPM,
SonataFlow, Optaplanner, Kogito and Tools.

KIE community vote thread:
https://lists.apache.org/thread/t72b95d3q1qvcyd7lbqkrt8cdx2cgsp2

Vote result thread:
https://lists.apache.org/thread/tjbbhlo3bo8dqqxs30f9sbj1wpxgxpyp

The release candidate:
https://dist.apache.org/repos/dist/dev/incubator/kie/10.0.0-rc2/

The maven staging repos for this release:
- Drools: https://repository.apache.org/content/repositories/orgapachekie-1046
- Optaplanner: 
https://repository.apache.org/content/repositories/orgapachekie-1047
- Kogito Runtimes:
https://repository.apache.org/content/repositories/orgapachekie-1048
- Kogito Apps: 
https://repository.apache.org/content/repositories/orgapachekie-1049
- Kogito Apps - JITExecutor Native Linux:
https://repository.apache.org/content/repositories/orgapachekie-1050
- Kogito Apps - JITExecutor Native Windows:
https://repository.apache.org/content/repositories/orgapachekie-1051
- Kogito Apps - JITExecutor Native MacOS:
https://repository.apache.org/content/repositories/orgapachekie-1052
- KIE Tools - JBPM Quarkus DevUI:
https://repository.apache.org/content/repositories/orgapachekie-1053
- KIE Tools - Sonataflow Quarkus DevUI:
https://repository.apache.org/content/repositories/orgapachekie-1054

The artifacts are signed with PGP key corresponding to
[priv...@kie.apache.org], found in the KEYS file:

https://downloads.apache.org/incubator/kie/KEYS

The vote will be open for at least 72 hours until the necessary number
of votes are reached.

Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

To learn more about KIE, please see https://kie.apache.org/

Checklist for reference:

[ ] Download KIE artifacts are valid.
[ ] Checksums and PGP signatures are valid.
[ ] Source code distributions have correct names matching the current release.
[ ] LICENSE and NOTICE files are correct.
[ ] All files have license headers if necessary.
[ ] No compiled archives bundled in source archive.
[ ] Can compile from source.

For updated information on how to verify the release, please refer to:
https://kie.apache.org/docs/community/verify

For updated information on how to build from source zip, please refer to:
https://kie.apache.org/docs/community/build

Best,
Alex

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

Re: [VOTE] Accept CloudBerry into the ASF Incubator

[Alex Porcelli]

+1 (non-binding)


On Thu, Oct 3, 2024 at 8:38 PM Francis Chuang 
wrote:

> +1 (binding)
>
> On 4/10/2024 10:10 am, Roman Shaposhnik wrote:
> > Hi folks,
> >
> > Following the discussion about CloudBerry
> > (https://lists.apache.org/thread/1f8jwpjnn430bhsjq98qxlgjojpqrfdh),
> > and after seeing a few updates to the proposal, I would like to
> > start the formal vote to accept CloudBerry into the ASF Incubator.
> >
> > As reminder, this is the CloudBerry Proposal:
> >
> https://cwiki.apache.org/confluence/display/INCUBATOR/CloudberryProposal
> >
> > Please cast your vote:
> > [ ] +1, accept CloudBerry into the ASF Incubator
> > [ ] 0, I don't care either way
> > [ ] -1, do not accept CloudBerry into the ASF Incubator, because ...
> >
> > The vote will run for one week starting from today.
> >
> > Thanks,
> > Roman.
> >
> > -
> > 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 Polaris into the ASF Incubator

[Alex Porcelli]

+ 1 (non-binding)

On Sat, Aug 3, 2024 at 7:30 AM Zhang Yonglun 
wrote:

> +1 (binding)
>
> Best Regards,
> Zhang Yonglun
>
> Jean-Baptiste Onofré  于2024年8月3日周六 01:27写道：
> >
> > Hi folks,
> >
> > Following the discussion about Polaris
> > (https://lists.apache.org/thread/ymz26dr3bzldbntdgpctbtkb787x311d),
> > and after updating the proposal based on comments, I would like to
> > start the formal vote to accept Polaris into the ASF Incubator.
> >
> > As reminder, this is the Polaris Proposal:
> > https://cwiki.apache.org/confluence/display/INCUBATOR/PolarisProposal
> >
> > Please cast your vote:
> > [ ] +1, accept Polaris into the ASF Incubator
> > [ ] 0, I don't care either way
> > [ ] -1, do not accept Polaris into the ASF Incubator, because ...
> >
> > The vote will run for one week starting from today.
> >
> > Thanks !
> > Regards
> > JB
> >
> > -
> > 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: Request for SVN Robot Access for KIE Podling

[Alex Porcelli]

Thank you for the detailed information, Daniel!

Although I'm not an IPMC member, I'd like to express that option 3
looks almost like a no brainer :)

Looking forward to hearing from IPMC members.

On Thu, Aug 1, 2024 at 7:02 AM Daniel Gruno  wrote:
>
> On 8/1/24 12:42, Alex Porcelli wrote:
> > Dear IPMC members,
> >
> > The KIE podling is preparing for its first Apache release. Due to the
> > numerous artifacts we build across various repositories (container
> > images, Java libraries, web apps, etc.), we seek to automate the SVN
> > upload as part of our release procedures.
> >
> > Note: Currently, the KIE podling already has robot access [1] [2] for
> > our Git repositories as part of our existing automation processes.
> >
> > As KIE is under the Incubator, the Apache Infra team recommended we
> > contact the IPMC directly.
>
> To be very specific here, the issue arises from the fact that while TLPs
> have their own [/dev/foo] and [/release/foo] auth settings where we can
> add in a role account for automated release candidates (only for /dev,
> not for /release !), all podlings belong to the /dev/incubator
> structure, meaning any role account we would create would currently have
> r/w to all podling release candidate dirs, and would be just one
> catch-all role account for the entire incubator.
>
> While I would personally have reservations against a global incubator
> role account for release staging, it's also worth noting that anyone in
> the incubator ldap group can stage anywhere inside it, so perhaps it is
> a moot subject.
>
> How the incubator wishes to proceed is largely up to them, with three
> basic options to suggest:
>
> 1. no automated staging for podlings
> 2. automated staging is allowed, with a shared incubator role account
> 3. automated staging is allowed, we'll sort out individual podling role
> accounts for their sub-dir.
>
> >
> > Regards,
> > Alex
> >
> > [1] https://issues.apache.org/jira/browse/INFRA-25088
> > [2] 
> > https://github.com/apache/incubator-kie-tools/commit/f0c8b8c080581fbdbe660a96d4e25c3831f6c29b
> >
> > -
> > 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
>

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

Request for SVN Robot Access for KIE Podling

[Alex Porcelli]

Dear IPMC members,

The KIE podling is preparing for its first Apache release. Due to the
numerous artifacts we build across various repositories (container
images, Java libraries, web apps, etc.), we seek to automate the SVN
upload as part of our release procedures.

Note: Currently, the KIE podling already has robot access [1] [2] for
our Git repositories as part of our existing automation processes.

As KIE is under the Incubator, the Apache Infra team recommended we
contact the IPMC directly.

Regards,
Alex

[1] https://issues.apache.org/jira/browse/INFRA-25088
[2] 
https://github.com/apache/incubator-kie-tools/commit/f0c8b8c080581fbdbe660a96d4e25c3831f6c29b

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

Re: KIE - Question about "staging" binaries/artifacts

[Alex Porcelli]

Thank you all for the inputs, but we still seeking clarity on NPM.

We - Apache KIE podling - are trying to get a single release procedure for
all binaries, but with lack of NPM infra for staging makes it really
complex.

I notice that OpenDAL publishes to NPM, is there anyone involved in OpenDAL
here that could help us sort this out?

For container images, we have similar issue with staging… less of issue is
the build.


On Mon, May 13, 2024 at 5:50 PM PJ Fanning  wrote:

> I may be misinterpreting 'live website' but it is quite common for Apache
> projects to have a 'staged' version of their website (i.e. a pre-release
> version of the web site).
> https://kie.apache.org/ could also have a https://kie.staged.apache.org/
>
> https://pekko.staged.apache.org/ is a staged version of
> https://pekko.apache.org/ (for instance)
>
> See the .asf.yaml docs:
>
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Stagingawebsitepreviewdomain
>
> For quay.io, you could raise a JIRA for INFRA team to discuss supporting
> an
> account for deployments. Or maybe, the KIE PPMC could set up an account and
> share the credentials among the KIE release managers.
>
>
>
>
>
> On Mon, 13 May 2024 at 22:30, Tiago Bento  wrote:
>
> > Thank you for the prompt responses.
> >
> > We're aware that for Maven artifacts we could "promote" them after
> > publishing them to a staging repo.
> >
> > But for container images, for example, I'm not sure I understand how such
> > process would look like. Prior to being in Apache, we used to push images
> > to Quay.io under a "[version]-prerelease" tag for "staging". Then we
> would
> > have a completely new build when we would be ready for a actual release.
> >
> > I guess for other kinds of artifacts, like the NPM packages, live
> > websites, and Chrome and VS Code Extensions, I also still don't
> understand
> > very well how this could be achieved... Any advice? It's hard to tell
> what
> > "promoting" those would look like, as for example, one of our live
> websites
> > is hosted in GitHub Pages.
> >
> > Thanks again!
> >
> > Regards,
> >
> > Tiago Bento
> >
> >
> >
> > On 2024/05/13 20:35:35 PJ Fanning wrote:
> > > For Java jars, the ASF has repository.apache.org - a Nexus instance
> that
> > > can be used to stage and later release jars.
> > > The login credentials are the same credentials you use to access other
> > ASF
> > > resources.
> > >
> > >
> > > On Mon, 13 May 2024 at 21:28, Enrico Olivelli 
> > wrote:
> > >
> > > > Tiago,
> > > >
> > > >
> > > > Il Lun 13 Mag 2024, 22:11 Tiago Bento  ha
> > scritto:
> > > >
> > > > > Hello general@incubator,
> > > > >
> > > > > My name is Tiago Bento (@tiagobento on GitHub), and I’m one of the
> > > > > committers of the KIE project of the incubator.
> > > > >
> > > > > We’re gearing towards our first release under Apache, and we’re
> very
> > > > > excited to be approaching this important milestone.
> > > > >
> > > > > Some resources [1] [2] that we found already guided us in the right
> > > > > direction, but still, some questions remain about the release
> process
> > > > > itself.
> > > > >
> > > > > We understand that in Apache, releases are done from the source
> code
> > > > > perspective, not the binaries/artifacts’. However, we still don’t
> > > > > understand very clearly how Apache verifies signatures and
> checksums
> > > > > of the binaries that are eventually published.
> > > > >
> > > >
> > > > It is better that in case you provide binaries to your users those
> > binaries
> > > > are released together with the sources during the same VOTE.
> > > >
> > > > Having reproducible builds would help a lot, but that's not always
> > easy to
> > > > do.
> > > >
> > > > In your VOTE you should stage all the sources and binaries, signed
> > with the
> > > > same signature (by the release manager) and the same artifacts will
> be
> > > > promoted in case of a successful VOTE.
> > > >
> > > > The PMC can at least verify the signatures and any digests that are
> > staged
> > > > as part of the VOTE.
> > > >
> > > > Please note that if you don't have a reproducible build the PMC will
> > never
> > > > be able to verify that the binaries match the sources.
> > > >
> > > >
> > > > > The KIE project has three main types of consumable artifacts: Maven
> > > > > modules, Container images, and NPM packages; and we also maintain
> > some
> > > > > live web pages like https://sandbox.kie.org, and extensions for
> > Chrome
> > > > > [3] and VS Code [4].
> > > > >
> > > > > For the release to be voted, we understand we have to provide a
> .zip
> > > > > file containing the source code along with instructions on how to
> > > > > build it. Once/if approved, our understanding is that the exact
> same
> > > > > approved source code could be used to build and publish
> > > > > binaries/artifacts of any sort to public registries/repositories.
> > > > >
> > > > > I’m laying out all the information I could gather so 

Re: [VOTE] Drop the incubator- prefix for podling's GitHub repo name

[Alex Porcelli]

+1 (non-binding)

Alex

On Tue, May 7, 2024 at 8:35 PM Francis Chuang 
wrote:

> +1 (binding)
>
> I think this is a pragmatic and well-thought out approach.
>
> Francis
>
> On 8/05/2024 10:31 am, tison wrote:
> > Hi,
> >
> > Following the discussion thread [1], I'd start a vote on the following
> > proposals:
> >
> > 1. Establish a consensus to allow and finally converge podling's GitHub
> repo to
> > have a name without the incubator- prefix.
> > 2. Allow existing ongoing podlings to ask the INFRA to drop their
> > incubator- prefix by now, not MUST during the graduation.
> > 3. Update the docs on incubator.apache.org everywhere if the description
> > can conflict with this consensus.
> > 4. Update the docs on incubator.apache.org to guide how to describe
> > podling's incubating status on the GitHub repo (namely, including
> > "incubating" in the repo description and README, point to the DISCLAIMER
> > content).
> >
> > [1] https://lists.apache.org/thread/kxvdkrf8g8yr6hww1n08r21xdy67y4ok
> >
> > +1 allow podling's GitHub repo to have a name without the incubator-
> > prefix, and other items above
> > +0 do not care strongly
> > -1 disagree the proposals above, because ...
> >
> > Please vote with your ASF ID followed by (binding) if you are a member of
> > the Incubator PMC or (not binding) if not.
> >
> > Vote will be open for at least 72 hours.
> >
> > Best,
> > tison.
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Accept GraphAr into the ASF Incubator

[Alex Porcelli]

+1 (non-binding)


On Fri, Mar 15, 2024 at 5:08 AM Charles Zhang 
wrote:

> +1 (binding)
>
> Best wishes,
> Charles Zhang
> from Apache InLong
>
>
> Xiaoqiao He  于2024年3月15日周五 16:44写道：
>
> > +1 (binding)
> > Good Luck!
> >
> > Best Regards,
> > - He Xiaoqiao
> >
> > On Fri, Mar 15, 2024 at 4:33 PM PJ Fanning  wrote:
> >
> > > +1 binding
> > >
> > > On Fri, 15 Mar 2024 at 09:18, Kent Yao  wrote:
> > > >
> > > > +1 binding & Good luck!
> > > >
> > > > Kent Yao
> > > >
> > > > Calvin Kirs  于2024年3月15日周五 14:02写道：
> > > > >
> > > > > +1 binding
> > > > >
> > > > > On Fri, Mar 15, 2024 at 1:58 PM Yu Li  wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > With positive feedback from the proposal discussion [1], I am
> > > starting
> > > > > > this official vote to accept GraphAr into the Incubator. Here is
> > the
> > > > > > proposal:
> > > > > >
> > > > > >
> > > https://cwiki.apache.org/confluence/display/INCUBATOR/GraphArProposal
> > > > > >
> > > > > > Please cast your vote:
> > > > > > [ ] +1, accept GraphAr into the Incubator
> > > > > > [ ] +0, I don't care either way
> > > > > > [ ] -1, do not accept GraphAr into the Incubator, because...
> > > > > >
> > > > > > The vote will open for one week from today, 15 March, 2024.
> Thanks.
> > > > > >
> > > > > > Best Regards,
> > > > > > Yu
> > > > > >
> > > > > > [1]
> > https://lists.apache.org/thread/bldz3rnp8nvhlmrd2gqkl30fgk9z3zhx
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > > > For additional commands, e-mail:
> general-h...@incubator.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Best wishes！
> > > > > CalvinKirs
> > > >
> > > > -
> > > > 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] Podling web sites: make (incubator.) optional in podling urls

[Alex Porcelli]

+1 (non-binding)

On Tue, Mar 12, 2024 at 6:14 PM Justin Mclean  wrote:
>
> +1 binding
>
> -
> 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: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling

[Alex Porcelli]

tison,

First and foremost, as a past Hibernate contributor with personal
relationship with Hibernate team members I’m very aware of this plan to
change license… and they are finally reaching a point that this has been
communicated in public :) - so I have a high level of confidence that the
team behind this is actively working on this…

But, relicensing is not simple… and we definitely should plan for the
situation that Hibernate just can’t do it. In this case, we have a few
options (non-exclusive):

- adjust API level to just JPA and hack around some tests using OpenJPA
- in case of core operations, that might be risky to use unsupported
library (ie. OpenJPA for Quarkus in a production code)… we can always go
back to JDBC.

So, we are not neglecting and are prepared to react in different ways.


On Tue, Mar 5, 2024 at 12:39 PM tison  wrote:

> Thanks for reaching out Alex :D
>
> I agree with PJ and emphasize that we should highlight the license
> issue on release.
>
> Also, for others in this thread, the thorough solution described above is:
>
> > The Hibernate team is in the process of relicensing from LGPL to Apache
> License 2.0.
>
> To Alex:
>
> How much confidence do you have in this direction? Are you involved in
> this effort?
>
> What if the relicensing doesn't happen? Do you have an alternative plan?
>
> Best,
> tison.
>
> Alex Porcelli  于2024年3月6日周三 01:25写道：
> >
> > Thank you PJ! This is very helpful!
> >
> > On Tue, Mar 5, 2024 at 12:23 PM PJ Fanning  wrote:
> > >
> > > https://incubator.apache.org/policy/incubation.html#disclaimers
> > >
> > > Have a look at the Disclaimers doc. If you use the WIP Disclaimer then
> you
> > > can do releases that are not fully ASF compliant. It would be good to
> > > document clearly about this dependency license issue.
> > >
> > >
> > >
> > > On Tue 5 Mar 2024, 17:53 Alex Porcelli,  wrote:
> > >
> > > > Dear Members of the Apache Incubator,
> > > >
> > > > I hope this email finds you well. My name is Alex Porcelli, and I am
> > > > part of the Apache KIE podling community [1]. I am reaching out to
> > > > discuss a matter regarding a dependency we have under LGPL, which
> > > > falls under Category X according to Apache guidelines.
> > > >
> > > > The dependency is Hibernate ORM [2], the only supported JPA provider
> > > > for Quarkus [3] - the primary runtime provider for Apache KIE
> podling.
> > > >
> > > > However, I'd like to emphasize the urgency of our situation. Our
> > > > community has dedicated substantial effort over the past six months
> to
> > > > prepare for our initial Apache release. Unfortunately, this delay in
> > > > releasing Apache KIE is unprecedented for this community, and it is
> > > > critical for us to deliver new releases promptly. Not only does our
> > > > large user base eagerly anticipate a new release, but older versions
> > > > may also pose security vulnerabilities (CVEs). Additionally, with our
> > > > previous release process through Red Hat decommissioned, Apache now
> > > > stands as our sole means of distribution.
> > > >
> > > > Given these circumstances, I kindly ask the Apache Incubator to
> > > > consider granting us a temporary exception to maintain the LGPL
> > > > dependency for our initial releases. We understand the importance of
> > > > adhering to Apache licensing requirements and are willing to make
> > > > necessary adjustments while ensuring compliance. However, we believe
> > > > that allowing us to proceed with proper disclaimers in place would
> > > > enable us to maintain momentum and meet the expectations of our user
> > > > community.
> > > >
> > > > Furthermore, I would like to inform you that the Hibernate team is in
> > > > the process of relicensing from LGPL to ASLv3, as indicated in their
> > > > recent blog post [4]. This transition aligns with our long-term goals
> > > > and demonstrates our commitment to compliance with Apache guidelines.
> > > >
> > > > We are open to any guidance or suggestions from the Incubator PMC on
> > > > how best to proceed.
> > > >
> > > > Thank you for considering our request.
> > > >
> > > > Best regards,
> > > > Alex Porcelli
> > > > Apache KIE Podling Community Member
> > > >
> > > > [1] - Apache KIE: https://kie.apache.org/
> > >

Re: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling

[Alex Porcelli]

Thank you PJ! This is very helpful!

On Tue, Mar 5, 2024 at 12:23 PM PJ Fanning  wrote:
>
> https://incubator.apache.org/policy/incubation.html#disclaimers
>
> Have a look at the Disclaimers doc. If you use the WIP Disclaimer then you
> can do releases that are not fully ASF compliant. It would be good to
> document clearly about this dependency license issue.
>
>
>
> On Tue 5 Mar 2024, 17:53 Alex Porcelli,  wrote:
>
> > Dear Members of the Apache Incubator,
> >
> > I hope this email finds you well. My name is Alex Porcelli, and I am
> > part of the Apache KIE podling community [1]. I am reaching out to
> > discuss a matter regarding a dependency we have under LGPL, which
> > falls under Category X according to Apache guidelines.
> >
> > The dependency is Hibernate ORM [2], the only supported JPA provider
> > for Quarkus [3] - the primary runtime provider for Apache KIE podling.
> >
> > However, I'd like to emphasize the urgency of our situation. Our
> > community has dedicated substantial effort over the past six months to
> > prepare for our initial Apache release. Unfortunately, this delay in
> > releasing Apache KIE is unprecedented for this community, and it is
> > critical for us to deliver new releases promptly. Not only does our
> > large user base eagerly anticipate a new release, but older versions
> > may also pose security vulnerabilities (CVEs). Additionally, with our
> > previous release process through Red Hat decommissioned, Apache now
> > stands as our sole means of distribution.
> >
> > Given these circumstances, I kindly ask the Apache Incubator to
> > consider granting us a temporary exception to maintain the LGPL
> > dependency for our initial releases. We understand the importance of
> > adhering to Apache licensing requirements and are willing to make
> > necessary adjustments while ensuring compliance. However, we believe
> > that allowing us to proceed with proper disclaimers in place would
> > enable us to maintain momentum and meet the expectations of our user
> > community.
> >
> > Furthermore, I would like to inform you that the Hibernate team is in
> > the process of relicensing from LGPL to ASLv3, as indicated in their
> > recent blog post [4]. This transition aligns with our long-term goals
> > and demonstrates our commitment to compliance with Apache guidelines.
> >
> > We are open to any guidance or suggestions from the Incubator PMC on
> > how best to proceed.
> >
> > Thank you for considering our request.
> >
> > Best regards,
> > Alex Porcelli
> > Apache KIE Podling Community Member
> >
> > [1] - Apache KIE: https://kie.apache.org/
> > [2] - Hibernate ORM: https://hibernate.org/orm/
> > [3] - Quarkus: https://quarkus.io/
> > [4] - Blog post on relicensing: https://in.relation.to/2023/11/18/license/
> >
> > -
> > 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

Request for Temporary Exception for LGPL Dependency in Apache KIE Podling

[Alex Porcelli]

Dear Members of the Apache Incubator,

I hope this email finds you well. My name is Alex Porcelli, and I am
part of the Apache KIE podling community [1]. I am reaching out to
discuss a matter regarding a dependency we have under LGPL, which
falls under Category X according to Apache guidelines.

The dependency is Hibernate ORM [2], the only supported JPA provider
for Quarkus [3] - the primary runtime provider for Apache KIE podling.

However, I'd like to emphasize the urgency of our situation. Our
community has dedicated substantial effort over the past six months to
prepare for our initial Apache release. Unfortunately, this delay in
releasing Apache KIE is unprecedented for this community, and it is
critical for us to deliver new releases promptly. Not only does our
large user base eagerly anticipate a new release, but older versions
may also pose security vulnerabilities (CVEs). Additionally, with our
previous release process through Red Hat decommissioned, Apache now
stands as our sole means of distribution.

Given these circumstances, I kindly ask the Apache Incubator to
consider granting us a temporary exception to maintain the LGPL
dependency for our initial releases. We understand the importance of
adhering to Apache licensing requirements and are willing to make
necessary adjustments while ensuring compliance. However, we believe
that allowing us to proceed with proper disclaimers in place would
enable us to maintain momentum and meet the expectations of our user
community.

Furthermore, I would like to inform you that the Hibernate team is in
the process of relicensing from LGPL to ASLv3, as indicated in their
recent blog post [4]. This transition aligns with our long-term goals
and demonstrates our commitment to compliance with Apache guidelines.

We are open to any guidance or suggestions from the Incubator PMC on
how best to proceed.

Thank you for considering our request.

Best regards,
Alex Porcelli
Apache KIE Podling Community Member

[1] - Apache KIE: https://kie.apache.org/
[2] - Hibernate ORM: https://hibernate.org/orm/
[3] - Quarkus: https://quarkus.io/
[4] - Blog post on relicensing: https://in.relation.to/2023/11/18/license/

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

Re: [VOTE] Have Amoro join the Incubator

[Alex Porcelli]

+1 (non-binding)

On Sat, Mar 2, 2024 at 8:44 PM Justin Mclean 
wrote:

> Hi,
>
> Following on from the discussion of the Amoro proposal [1][2], let's vote
> on having it join the Incubator.
>
> Please cast your vote:
>
> [ ] +1, have it join the Incubator as an incubating project
> [ ] +0, I have no strong opinion either way
> [ ] -1, do not have it join the Incubator because...
>
> Kind Regards,
> Justin
>
> 1. https://cwiki.apache.org/confluence/display/INCUBATOR/AmoroProposal
> 2. https://lists.apache.org/thread/7t2bm6x19zq2d79cn8jj2wqd3f2t3k00

Re: Podling web sites: .incubator. required?

[Alex Porcelli]

+1 (non-binding)

On Wed, Feb 28, 2024 at 10:01 AM Suyan  wrote:
>
> +1 non-binding
>
> This looks a little more concise.
>
> Sincerely,
> Suyan
>
> Craig Russell  于2024年2月28日周三 08:18写道：
> >
> > It was policy at one point for podlings to have .incubator. in their home 
> > page url. But many podlings now have transitioned away from this and simply 
> > use their podling.apache.org name. The policy document is a bit iffy on the 
> > subject:
> > https://incubator.apache.org/guides/branding.html
> >
> > > After a podling has been approved, the lists are created, and the initial 
> > > code drop has commenced, you MUST refer to the podling as Apache 
> > > Podling-Name AND mention that the project is under Incubation. Suitable 
> > > mentions include:
> > >
> > >   • Inclusion of the http://podling-name.incubator.apache.org/ URL
> > >
> > >   • Apache Podling-Name is currently undergoing Incubation at the 
> > > Apache Software Foundation.
> > >
> > > The Incubator PMC (IPMC) must approve other references before you publish 
> > > them. You only need to make these statements upon the first reference to 
> > > the podling in a document.
> >
> > I feel this is very much like the former requirement for mail lists to 
> > include incubator.apache.org as part of their name. This turned out to be a 
> > huge waste of time for the podling as well as for infra when upon 
> > graduation all of the documentation and tooling for mail lists had to 
> > change.
> >
> > I would propose that as part of our official policy we recommend the 
> > podling's url as https://podling.apache.org and get rid of the .incubator. 
> > in the url.
> >
> > WDYT?
> >
> > Craig L Russell
> > c...@apache.org
> >
> >
> > -
> > 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
>

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

Re: Update Website Template (WAS: Help to get the Wayang project website in shape)

[Alex Porcelli]

+1 (non-binding)

Awesome initiative!


On Wed, Feb 14, 2024 at 7:48 AM Twice  wrote:

> +1.
>
> Docusaurus is super suitable for building open-source project
> websites, and currently being used by lots of ASF projects.
>
> Replacing the original website template makes sense to me.
>
> Best,
> Twice
>
> On Wed, Feb 14, 2024 at 3:54 PM Suyan  wrote:
> >
> > +1, that's great!
> >
> > Sincerely,
> > Suyan
> >
> > tison  于2024年2月4日周日 23:17写道：
> > >
> > > Hi,
> > >
> > > I finally find some time to prepare a demo for the new website
> template [1].
> > >
> > > It may still open to be improved including a download page template
> > > and a community page template, as well as some guides as its docs. But
> > > I'd like to first collecting feedback and finding which PMC is
> > > responsible for this repository [2].
> > >
> > > The background is that our current template is quite old and not
> > > updated for the past six years. Few people understand those techniques
> > > and have a hard time to build their own site. Also, new policy
> > > compliance and new techniques benefits can be included in the template
> > > to help new projects (podlings) build a wonderful site.
> > >
> > > I'm glad to maintain this repo but I find myself has no permission
> > > over this repo. So again, which PMC is responsible for this
> > > repository?
> > >
> > > Best,
> > > tison.
> > >
> > > [1]
> https://github.com/tisonkun/apache-website-template/tree/docusaurus
> > > [2] https://github.com/apache/apache-website-template/
> > >
> > > Alex Porcelli  于2024年1月30日周二 04:53写道：
> > > >
> > > > Another shout-out for tison and the Apache Fury to provide such a
> nice
> > > > starting point for new websites.
> > > >
> > > > I managed to put, for now, a simple placeholder website for Apache
> KIE
> > > > (incubation).
> > > >
> > > > Thank you tison and the Apache Fury community!
> > > >
> > > > On Fri, Jan 26, 2024 at 4:10 AM Xuanwo  wrote:
> > > > >
> > > > > > I managed to move our old website to Docusaurus in one day -
> using the template
> > > > > > structure from Fury, if you don’t mind.
> > > > >
> > > > > Congrats!
> > > > >
> > > > > On Fri, Jan 26, 2024, at 17:07, Alexander Alten-Lorenz wrote:
> > > > > > Hey tison,
> > > > > >
> > > > > > Thank you for the head-up. I managed to move our old website to
> > > > > > Docusaurus in one day - using the template structure from Fury,
> if you
> > > > > > don’t mind. Awesome stuff, would love when we’d had a template
> for the
> > > > > > podlings to setup a good looking, SEO friendly project page.
> That’s
> > > > > > needed to grow the community!
> > > > > >
> > > > > > Cheers, thanks again,
> > > > > >  —Alex
> > > > > >
> > > > > >> On Jan 25, 2024, at 12:01, tison  wrote:
> > > > > >>
> > > > > >> Hi Alexander,
> > > > > >>
> > > > > >> I use Docusaurus for Kvrocks and Fury. Their configuration
> should be
> > > > > >> straightforward to follow already. The most simple one now is
> > > > > >> https://github.com/apache/incubator-fury-site.
> > > > > >>
> > > > > >> Also, Docu is well-documented https://docusaurus.io/docs.
> > > > > >>
> > > > > >> I'm thinking of updating the website template [1] with Docu but
> have
> > > > > >> not yet had time and understand which PMC manages this project.
> > > > > >>
> > > > > >> Best,
> > > > > >> tison.
> > > > > >>
> > > > > >> [1] https://github.com/apache/apache-website-template
> > > > > >>
> > > > > >> Alexander Alten-Lorenz 
> 于2024年1月25日周四 18:20写道：
> > > > > >>>
> > > > > >>> Hi Xuanwo,
> > > > > >>>
> > > > > >>> Thank you, highly appreciated! Do you have any how-to for
> setting Docusaurus up?
> > > > > >>>
> 

Re: Help to get the Wayang project website in shape

[Alex Porcelli]

Another shout-out for tison and the Apache Fury to provide such a nice
starting point for new websites.

I managed to put, for now, a simple placeholder website for Apache KIE
(incubation).

Thank you tison and the Apache Fury community!

On Fri, Jan 26, 2024 at 4:10 AM Xuanwo  wrote:
>
> > I managed to move our old website to Docusaurus in one day - using the 
> > template
> > structure from Fury, if you don’t mind.
>
> Congrats!
>
> On Fri, Jan 26, 2024, at 17:07, Alexander Alten-Lorenz wrote:
> > Hey tison,
> >
> > Thank you for the head-up. I managed to move our old website to
> > Docusaurus in one day - using the template structure from Fury, if you
> > don’t mind. Awesome stuff, would love when we’d had a template for the
> > podlings to setup a good looking, SEO friendly project page. That’s
> > needed to grow the community!
> >
> > Cheers, thanks again,
> >  —Alex
> >
> >> On Jan 25, 2024, at 12:01, tison  wrote:
> >>
> >> Hi Alexander,
> >>
> >> I use Docusaurus for Kvrocks and Fury. Their configuration should be
> >> straightforward to follow already. The most simple one now is
> >> https://github.com/apache/incubator-fury-site.
> >>
> >> Also, Docu is well-documented https://docusaurus.io/docs.
> >>
> >> I'm thinking of updating the website template [1] with Docu but have
> >> not yet had time and understand which PMC manages this project.
> >>
> >> Best,
> >> tison.
> >>
> >> [1] https://github.com/apache/apache-website-template
> >>
> >> Alexander Alten-Lorenz  于2024年1月25日周四 18:20写道：
> >>>
> >>> Hi Xuanwo,
> >>>
> >>> Thank you, highly appreciated! Do you have any how-to for setting 
> >>> Docusaurus up?
> >>>
> >>> —Alex
> >>>
> >>>> On Jan 25, 2024, at 11:01, Xuanwo  wrote:
> >>>>
> >>>> Hi, alexander
> >>>>
> >>>>> We aren't web designers and we would love to find helping hands to get
> >>>>> the page in order, including re-organizing and rewriting.
> >>>>
> >>>> I'm with the OpenDAL Community, and we also lack web designers. Our 
> >>>> community
> >>>> opted for Docusaurus[1], which we found easy to start with and set up. It
> >>>> offers a decent theme suitable for open-source projects. For reference, 
> >>>> you
> >>>> can check out OpenDAL's homepage[2]. We hope our experience proves 
> >>>> useful.
> >>>>
> >>>> [1] https://docusaurus.io/
> >>>> [2] https://opendal.apache.org/
> >>>>
> >>>> On Thu, Jan 25, 2024, at 16:26, Alexander Alten wrote:
> >>>>> Hi incubator community,
> >>>>>
> >>>>> Would anyone be willing to help the Wayang project with our website?
> >>>>> We aren't web designers and we would love to find helping hands to get
> >>>>> the page in order, including re-organizing and rewriting.
> >>>>>
> >>>>> thank you, cheers,
> >>>>> --alexander
> >>>>>
> >>>>> -
> >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>>>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>>>
> >>>> --
> >>>> Xuanwo
> >>>>
> >>>> -
> >>>> 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
> >>>
> >>
> >> -
> >> 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
>
> --
> Xuanwo
>
> -
> 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: [QUESTION] Reproducible build for container images

[Alex Porcelli]

Daniel,

That’s exactly the reason. There’s also this link referencing the
requirement [1].

https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=287607354#content/view/287607354


Regards,
_
Alex Porcelli
http://porcelli.me


On Tue, Jan 23, 2024 at 9:58 AM Daniel Gruno  wrote:

> On 1/23/24 15:49, PJ Fanning wrote:
> > Hi Alex,
> >
> > While reproducible builds are a great idea, the Incubator PMC does not
> > require them. Plugging away at improving things so that reproducible
> > builds can be produced in future is a useful thing to do.
>
> This may be related to https://issues.apache.org/jira/browse/INFRA-25140
> which *does* require reproducible builds for KIE.
>
> >
> > Regards,
> > PJ
> >
> > On Tue, 23 Jan 2024 at 14:58, Alex Porcelli  wrote:
> >>
> >> In the KIE podling, we regularly publish container images as part of
> >> our releases. We've achieved semantically identical images, verified
> >> using the 'diffoci' tool. However, due to current Docker/OCI engine
> >> limitations, we can't eliminate variations in file metadata caused by
> >> automatically appended timestamps.
> >>
> >> The latest version of Buildkit offers a solution but still needs to be
> >> integrated into the build engines. I want to ask the Incubator PMC: Is
> >> achieving semantically verifiable images sufficient for now, as we
> >> await the integration of Buildkit changes into Docker/OCI build
> >> engines?
> >>
> >> Regards,
> >> -
> >> Alex
> >> Apache KIE PPMC
> >>
> >> -
> >> 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
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[QUESTION] Reproducible build for container images

[Alex Porcelli]

In the KIE podling, we regularly publish container images as part of
our releases. We've achieved semantically identical images, verified
using the 'diffoci' tool. However, due to current Docker/OCI engine
limitations, we can't eliminate variations in file metadata caused by
automatically appended timestamps.

The latest version of Buildkit offers a solution but still needs to be
integrated into the build engines. I want to ask the Incubator PMC: Is
achieving semantically verifiable images sufficient for now, as we
await the integration of Buildkit changes into Docker/OCI build
engines?

Regards,
-
Alex
Apache KIE PPMC

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

Re: [QUESTION] Oracle JDBC Driver as a test dependency

[Alex Porcelli]

Thank you all for the valuable inputs... to play safe I opened a
ticket [1] with legal for better clarity.

[1] https://issues.apache.org/jira/browse/LEGAL-663

On Wed, Jan 10, 2024 at 8:30 PM Justin Mclean  wrote:
>
> Hi,
>
> > In your source release anything in Category A is fair game.  Things in
> > Category B are not.  Things in Category X never are.
>
> While correct, that’s not the full story; you also can’t have anything as a 
> dependency whose license is a category X one.
>
> Kind Regards,
> Justin

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

[QUESTION] Oracle JDBC Driver as a test dependency

[Alex Porcelli]

In KIE podling we have reference for the Oracle JDBC driver being used
only for tests [1], however based on this ticket [2], it's not clear
if we can continue to use it or this dependency has to be removed.

Guidance on this topic would be highly appreciated!

Regards,
Alex

[1] 
https://github.com/apache/incubator-kie-kogito-runtimes/blob/3aa26113d7e88f0fd7d0331ec20fe392f343afb6/kogito-test-utils/pom.xml#L89-L99
[2] https://issues.apache.org/jira/browse/LEGAL-526

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

Re: [KIE] Code import question

[Alex Porcelli]

Brian hope you don’t mind if I share additional details for the members of
the mailing list.

Some of the repositories have several stars, followers, historical list of
Pull Request and several other relevant metadata associated with them.

If a transfer between existing kiegroup and Apache organizations is
allowed, all that metadata are preserved. Hopefully this would be possible.

Regarding code cleanup, what Brian meant is the files headers changes from
existing copyright to the proper Apache headers.

Regards,
Alex Porcelli
PPMC KIE

On Fri, Aug 25, 2023 at 4:34 PM Brian Proffitt  wrote:

> Hey all,
>
> I was reading the Initial Code Import document[1] and while it says
> Infra needs the code attached to a JIRA ticket (after the SGA or CCLA
> has been completed), it also seems to say that you can pull all of it
> in via a GitHub export-> import operation[2].
>
> So, my questions:
>
> 1) Is a direct import allowed?
> 2) If this is yes, I should then create the JIRA ticket to build the
> "receiving" Apache repos, and attach the SGA to that, correct?
> 3) Cleanup can happen after the code is imported, correct?
>
> Thanks for your help!
> BKP
>
> [1] https://incubator.apache.org/guides/transitioning_asf.html
> [2]
> https://incubator.apache.org/guides/transitioning_asf.html#importing_history
>
>
> Brian Proffitt
> VP, Marketing & Publicity
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
> --
Regards,
_
Alex Porcelli
http://porcelli.me

Apache infrastructure for CI?

[Alex Porcelli]

Is there an infrastructure in Apache for CI (Jenkins, etc) for its projects?

If yes, where can we find more information on how to onboard?

If not, how do projects deal with CI infrastructure?

Regards,
Alex Porcelli
KIE Podling

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

Re: [VOTE] Graduate Apache EventMesh(incubating) as an Apache Top Level Project

[Alex Luo]

+1

Alex Luo

On 2023/02/13 10:44:48 vongosling wrote:
> +1, binding
> 
> Nice to see we have good practice for Apache Way. When we bring this
> project here, we are all looking forward to a promising road for the Event
> First Platform. Apache EventMesh seems to be ready to open the door for us.
> Good luck to the community ：-）
> 
> Eason Chen  于2023年2月10日周五 10:32写道：
> 
> > Dear Apache Incubator Community and IPMC members,
> >
> > After having the graduation discussion in the EventMesh community [1],
> > we passed the vote within the EventMesh community [2] and the vote
> > result was published[3].
> > We then discussed the graduation for EventMesh in the Apache Incubator
> > Community [4], where no issues were raised and positive replies were
> > received.
> >
> > I would like to start this voting thread to request graduating Apache
> > EventMesh(incubating) from Apache Incubator as a Top Level Project.
> >
> > Please provide your vote accordingly:
> > [ ] +1 Yes, I support the EventMesh project to graduate from the
> > Apache Incubator.
> > [ ] +0 No opinion.
> > [ ] -1 No, the EventMesh project is not ready to graduate, because...
> >
> > Thank you for participating in the vote. This vote will stay open for
> > at least 72 hours.
> >
> > Here is an overview of the Apache EventMesh(incubating) to help with the
> > vote.
> >
> > *Community*
> >
> > ● 5 new PPMC members were added, bringing the total number of PPMC
> > members to 14 from at least 9 different organizations.
> > ● 20 new Committers were added, bringing the total number of
> > committers to 42 from at least 30 different organizations.
> > ● 220+ new contributors participate in the community. The number of
> > contributors is now 250+ and growing.
> > ● 20 Bi-weekly online meetings were held among the committers,
> > contributors, and users. The meeting minutes are recorded on the
> > mailing list[5] and cwiki [6].
> > ● The dev@eventmesh mailing list currently has 117 subscribers.
> > ● We've confirmed the VP, PMC, and Committers in the preparation
> > discussion at private@eventmesh [7]. Eason
> > Chen(chenguangsh...@apache.org) was recommended as Vice President.
> >
> > *Project*
> >
> > ● Apache EventMesh(incubating) builds a fully serverless platform for
> > distributed event-driven applications.
> > ● Project maturity model is detailed in [8].
> > ● EventMesh has been incubating [9] since 2021-02-18 for over 23 months.
> > ● EventMesh community released a total of 7 Apache releases [10] by 6
> > different release managers from 5 different organizations.
> > ● 1300+ issues created, and 1100+ issues closed [11].
> > ● 1600+ pull requests created, and 1600+ pull requests closed [12],
> > 2500+ commits added.
> > ● The release cadence is about 3 months, with an average of 180+
> > issues and 230+ pull requests per release.
> > ● Please refer to the EventMesh project incubation status [13][14] for
> > more information.
> >
> > *Brands, License, and Copyright*
> >
> > ● We applied the brand [15], which has been reviewed and approved.
> > ● EventMesh community maintains project code on GitHub and all modules
> > code is under Apache 2.0 license. We have reviewed all the
> > dependencies and ensured they do not bring any license issues [16].
> > All the status files, license headers, and copyright are up to date.
> > ● EventMesh official website [17] is compliant with Apache Foundation
> > requirements[18].
> >
> > -
> > BEGINNING OF DRAFT RESOLUTION
> > -
> >
> > Establish the Apache EventMesh 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 fully serverless platform used to build distributed
> > event-driven applications.
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > (PMC), to be known as the "Apache EventMesh Project", be and hereby is
> > established pursuant to Bylaws of the Foundation; and be it further
> >
> > RESOLVED, that the Apache EventMesh Project be and hereby is responsible
> > for the creation and maintenance of software related to a fully
> > serverle

Re: [VOTE] Graduate Apache EventMesh(incubating) as an Apache Top Level Project

[Alex Luo]

+1

Alex Luo

On 2023/02/09 13:45:01 Wei Liu wrote:
> +1
> 
> On 2023/02/09 12:19:14 Eason Chen wrote:
> > Dear Apache Incubator Community and IPMC members,
> > 
> > After having the graduation discussion in the EventMesh community [1],
> > we passed the vote within the EventMesh community [2] and the vote
> > result was published[3].
> > We then discussed the graduation for EventMesh in the Apache Incubator
> > Community [4], where no issues were raised and positive replies were
> > received.
> > 
> > I would like to start this voting thread to request graduating Apache
> > EventMesh(incubating) from Apache Incubator as a Top Level Project.
> > 
> > Please provide your vote accordingly:
> > [ ] +1 Yes, I support the EventMesh project to graduate from the
> > Apache Incubator.
> > [ ] +0 No opinion.
> > [ ] -1 No, the EventMesh project is not ready to graduate, because...
> > 
> > Thank you for participating in the vote. This vote will stay open for
> > at least 72 hours.
> > 
> > Here is an overview of the Apache EventMesh(incubating) to help with the 
> > vote.
> > 
> > *Community*
> > 
> > ● 5 new PPMC members were added, bringing the total number of PPMC
> > members to 14 from at least 9 different organizations.
> > ● 20 new Committers were added, bringing the total number of
> > committers to 42 from at least 30 different organizations.
> > ● 220+ new contributors participate in the community. The number of
> > contributors is now 250+ and growing.
> > ● 20 Bi-weekly online meetings were held among the committers,
> > contributors, and users. The meeting minutes are recorded on the
> > mailing list[5] and cwiki [6].
> > ● The dev@eventmesh mailing list currently has 117 subscribers.
> > ● We've confirmed the VP, PMC, and Committers in the preparation
> > discussion at private@eventmesh [7]. Eason
> > Chen(chenguangsh...@apache.org) was recommended as Vice President.
> > 
> > *Project*
> > 
> > ● Apache EventMesh(incubating) is a fully serverless platform used to
> > build distributed event-driven applications.
> > ● Project maturity model is detailed in [8].
> > ● EventMesh has been incubating [9] since 2021-02-18 for over 23 months.
> > ● EventMesh community released a total of 7 Apache releases [10] by 6
> > different release managers from 5 different organizations.
> > ● 1300+ issues created, and 1100+ issues closed [11].
> > ● 1600+ pull requests created, and 1600+ pull requests closed [12],
> > 2500+ commits added.
> > ● The release cadence is about 3 months, with an average of 180+
> > issues and 230+ pull requests per release.
> > ● Please refer to the EventMesh project incubation status [13][14] for
> > more information.
> > 
> > *Brands, License, and Copyright*
> > 
> > ● We applied the brand [15], which has been reviewed and approved.
> > ● EventMesh community maintains project code on GitHub and all modules
> > code is under Apache 2.0 license. We have reviewed all the
> > dependencies and ensured they do not bring any license issues [16].
> > All the status files, license headers, and copyright are up to date.
> > ● EventMesh official website [17] is compliant with Apache Foundation
> > requirements[18].
> > 
> > -
> > BEGINNING OF DRAFT RESOLUTION
> > -
> > 
> > Establish the Apache EventMesh 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 fully serverless platform used to build distributed
> > event-driven applications.
> > 
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > (PMC), to be known as the "Apache EventMesh Project", be and hereby is
> > established pursuant to Bylaws of the Foundation; and be it further
> > 
> > RESOLVED, that the Apache EventMesh Project be and hereby is responsible
> > for the creation and maintenance of software related to EventMesh is a
> > fully serverless platform used to build distributed event-driven
> > applications; and be it further
> > 
> > RESOLVED, that the office of "Vice President, Apache EventMesh" be and
> > hereby is created, the person holding such offi

Re: [DISCUSS] Graduate Apache EventMesh(incubating) as an Apache Top Level Project

[Alex Luo]

+1 non-binding

Alex Luo

On 2023/02/06 14:09:50 李晓双 wrote:
> +1 non-binding
> 
> 李晓双  于2023年2月6日周一 21:05写道：
> 
> > +1 binding
> >
> > peacewong  于2023年2月6日周一 19:48写道：
> >
> >> +1 (non-binding)
> >>
> >> Congratulations!
> >>
> >> Wei Liu  于2023年2月6日周一 19:26写道：
> >>
> >> > +1
> >> >
> >> > Congratulations!
> >> >
> >> > On 2023/02/06 09:27:26 Eason Chen wrote:
> >> > > Dear Apache Incubator Community,
> >> > >
> >> > > Apache EventMesh has been incubating [1] since 2021-02-18 for over 23
> >> > > months. The EventMesh community has grown rapidly under the guidance
> >> > > of mentors and the Apache Way. After self-checking the EventMesh
> >> maturity
> >> > > model [2] and having a discussion [3], we started a vote [4] for
> >> > > graduation within the EventMesh community and got unanimous positive
> >> > > feedback [5]. We believe Apache EventMesh (Incubating) is now ready to
> >> > > graduate to be a Top Level Project. We'd like to have a discussion
> >> > > with the incubator community and get more feedback.
> >> > >
> >> > > Here is an overview of the Apache EventMesh(incubating) to help with
> >> > > the discussion.
> >> > >
> >> > > *Community*
> >> > >
> >> > > ● 5 new PPMC members were added, bringing the total number of PPMC
> >> > > members to 14 from at least 9 different organizations.
> >> > > ● 20 new Committers were added, bringing the total number of
> >> > > committers to 42 from at least 23 different organizations.
> >> > > ● 210+ new contributors participate in the community. The number of
> >> > > contributors is now 240+ and growing.
> >> > > ● 20 Bi-weekly online meetings were held among the committers,
> >> > > contributors, and users. The meeting minutes are recorded on the
> >> > > mailing list[6] and wiki [7].
> >> > > ● The dev@eventmesh mailing list currently has 117 subscribers.
> >> > > ● We've confirmed the VP, PMC, and Committers in the preparation
> >> > > discussion at private@eventmesh [8]. Eason
> >> > > Chen(chenguangsh...@apache.org) was recommended as Vice President.
> >> > >
> >> > > *Project*
> >> > >
> >> > > ● Apache EventMesh(incubating) builds a fully serverless platform used
> >> > > to build distributed event-driven applications.
> >> > > ● EventMesh community released a total of 7 Apache releases [9] by 6
> >> > > different release managers from 5 different organizations.
> >> > > ● 1300+ issues created, and 1100+ issues closed [10].
> >> > > ● 1600+ pull requests created, and 1600+ pull requests closed [11],
> >> > > 2500+ commits added.
> >> > > ● The release cadence is about 3 months, with an average of 180+
> >> > > issues and 230+ pull requests per release.
> >> > >
> >> > > *Brands, License, and Copyright*
> >> > >
> >> > > ● We submitted an application for the brand [12], which has been
> >> > > reviewed and approved.
> >> > > ● EventMesh community maintains project code on GitHub and all modules
> >> > > code is under Apache 2.0 license. We have reviewed all the
> >> > > dependencies and ensured they do not bring any license issues [13].
> >> > > All the status files, license headers, and copyright are up to date.
> >> > > ● EventMesh official website [14] is compliant with Apache Foundation
> >> > > requirements.
> >> > >
> >> > > -
> >> > > BEGINNING OF DRAFT RESOLUTION
> >> > > -
> >> > >
> >> > > Establish the Apache EventMesh 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 Ev

[ANNOUNCE] Apache EventMesh (incubating) 1.7.0 available

[Alex Luo]

Hi all,

Apache EventMesh (incubating) Team is glad to announce the new release of
Apache EventMesh (incubating) 1.7.0.

Apache EventMesh (incubating) is a dynamic cloud-native eventing
infrastructure used to decouple the application and backend middleware
layer, which supports a wide range of use cases that encompass complex
multi-cloud, widely distributed topologies using diverse technology stacks.

Download Links: https://eventmesh.apache.org/projects/eventmesh/download/

Release Notes: https://eventmesh.apache.org/events/release-notes/v1.7.0/

Website: https://eventmesh.apache.org/

EventMesh Resources:
- Issue: https://github.com/apache/incubator-eventmesh/issues
- Mailing list: d...@eventmesh.apache.org



Apache EventMesh (incubating) Team

[RESULT][VOTE] Release Apache EventMesh (incubating) 1.7.0-rc1

[Alex Luo]

Hi all,

Thanks for reviewing and voting for Apache EventMesh(Incubating)
version 1.7.0-rc1 release, I am happy to announce the release voting has
passed with 3 binding votes, no +0 or -1 votes.

 Binding votes are from IPMC
   +1 Francois Papon
   +1 Junping Du
   +1 Jean-Baptiste Onofré

 Non-binding votes:
   +1 Eason Chen
  +1 walterzywei
  +1 jay Taylor
  +1 Jallybo Mai
  +1 ShanPeng Qing
  +1 Jelly
  +1 Pengcheng Ma
  +1 Jacob
  +1 timcross
  +1 mx
  +1 horoc
  +1 bingyan
  +1 heng du

  No further +0 votes and -1 votes


The voting thread is:
• https://lists.apache.org/thread/4fl5hkjbjxsw0lv2hlcckrcdfgoq9sts

Many thanks for all our mentors helping us with the release procedure,
and all IPMC helped us to review and vote for Apache EventMesh(Incubating)
release.
I will be working on publishing the artifacts soon.

Thanks,
On behalf of Apache EventMesh(Incubating) community

Re: [VOTE] Release Apache EventMesh (incubating) 1.7.0-rc1

[Alex Luo]

Thank you all for your check and vote , and I also want to carry over the
vote by Francois Papon from dev, so I would like to send the result later.

Thanks,
Your EventMesh Release Manager

On Thu, Dec 1, 2022 at 4:21 AM Eason Chen  wrote:

> Thank you Junping.
>
> On Thu, Dec 1, 2022 at 5:17 PM 俊平堵  wrote:
> >
> > +1 (binding).
> >
> > I have checked:
> > - Download links are valid.
> > - Checksums and PGP signatures looks good
> > - ASF headers are present in source files
> > - LICENSE, NOTICE and DISCLAIMER files are there and look good
> > - No binaries found in the source distribution
> >
> > Thanks,
> >
> > Junping
> >
> > Alex Luo  于2022年11月25日周五 13:02写道：
> >
> > > Hello Incubator Community,
> > >
> > > This is a call for a vote to release Apache EventMesh(Incubating)
> > > version 1.7.0-rc1
> > >
> > > The Apache EventMesh community has voted on and approved a
> proposal to
> > > release
> > > Apache EventMesh(Incubating) version 1.7.0-rc1
> > >
> > > We now kindly request the Incubator PMC members review and vote on
> this
> > > incubator release.
> > >
> > > EventMesh community vote thread:
> > > • https://lists.apache.org/thread/0t8lz5d3ypbnd1094tkrc57ql12w6ckl
> > >
> > > Vote result thread:
> > > • https://lists.apache.org/thread/p4zm61p636gjj7msmj8smyx8nsthn9kx
> > >
> > > The release candidate:
> > > •
> https://dist.apache.org/repos/dist/dev/incubator/eventmesh/1.7.0-rc1
> > >
> > > Git tag for the release:
> > > • https://github.com/apache/incubator-eventmesh/tree/v1.7.0-rc1
> > > Release notes:
> > > • https://eventmesh.apache.org/events/release-notes/v1.7.0
> > >
> > > The artifacts signed with PGP key
> > > 235DBB05A82D0D8C1492D50079CD973EA1DBF237, corresponding to
> > > alex...@apache.org, that can be found in keys file:
> > > • https://downloads.apache.org/incubator/eventmesh/KEYS
> > >
> > > The vote will be open for at least 72 hours or until the necessary
> > > number of votes are reached.
> > >
> > > Please vote accordingly:
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > > Thanks,
> > > On behalf of Apache EventMesh(Incubating) community
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@eventmesh.apache.org
> For additional commands, e-mail: dev-h...@eventmesh.apache.org
>
>

-- 
Sincerely,

Alex

Re: [VOTE] Graduate Apache Linkis(incubating) as an Apache Top Level Project

[Alex Young]

> established pursuant to Bylaws of the Foundation; and be it further
> >
> > RESOLVED, that the Apache Linkis Project be and hereby is responsible
> > for the creation and maintenance of software related to a computation
> > middleware to facilitate connection, governance and orchestration
> > between the upper applications and the underlying data engines; and be
> > it further
> >
> > RESOLVED, that the office of "Vice President, Apache Linkis" 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 Linkis
> > Project, and to have primary responsibility for management of the
> > projects within the scope of responsibility of the Apache Linkis
> > 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 Linkis
> > Project:
> >
> > ●  Alex Young 
> > ●  Deyi Hua 
> > ●  Duo Zhang 
> > ●  HuaJin Zhang 
> > ●  Hui Zhu 
> > ●  Jacky Xie 
> > ●  Jerry Shao 
> > ●  Junping Du 
> > ●  Ke Zhou 
> > ●  Kelu Tao 
> > ●  Le Bai 
> > ●  Lidong Dai 
> > ●  Ling Xu 
> > ●  Longping Jie 
> > ●  Peacewong 
> > ●  Qiang Yin 
> > ●  Rong Zhang 
> > ●  Shao Feng Shi 
> > ●  Shuai Di 
> > ●  Xiaogang Wang 
> > ●  Xiaohua Yi 
> > ●  Zhen Wang 
> > ●  Zhiyue Yang 
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Shuai Di be appointed to
> > the office of Vice President, Apache Linkis, 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 Linkis Project be and hereby is tasked with
> > the migration and rationalization of the Apache Incubator Linkis
> > podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache Incubator
> > Linkis podling encumbered upon the Apache Incubator PMC are hereafter
> > discharged.
> >
> > --
> > END OF DRAFT RESOLUTION
> > --
> >
> > [1] https://lists.apache.org/thread/yvps9rwx8y1660t12o6034hczj05ko5o
> > [2] https://lists.apache.org/thread/sc8vj2hqrsj6c1gp97n6x8hkscxo8pyj
> > [3] https://lists.apache.org/thread/tnp165hs0k9rvntqz2f025sxsjlk6xsf
> > [4] https://lists.apache.org/thread/7ovjddrpywg5yr97bqtc0ds0jffjztsx
> > [5] https://cwiki.apache.org/confluence/display/LINKIS/Meetings
> > [6] https://lists.apache.org/list.html?d...@linkis.apache.org
> > [7] https://lists.apache.org/thread/m3ny1rwstr38do65ltcqyt4nl9mzhwdj
> > [8]
> > https://github.com/apache/incubator-linkis-website/blob/dev/maturity.md
> > [9] https://cwiki.apache.org/confluence/display/INCUBATOR/LinkisProposal
> > [10] https://github.com/apache/incubator-linkis/releases
> > [11] https://github.com/apache/incubator-linkis/pulls and
> > https://github.com/apache/incubator-linkis-website/pulls
> > [12] https://github.com/apache/incubator-linkis/issues and
> > https://github.com/apache/incubator-linkis-website/issues
> > [13] https://incubator.apache.org/projects/linkis.html
> > [14] https://incubator.apache.org/clutch/
> > [15] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-192
> > [16] https://github.com/apache/incubator-linkis/blob/master/LICENSE
> > [17] https://linkis.apache.org/
> > [18] https://whimsy.apache.org/pods/project/linkis
> >
> > Best regards,
> > Shuai Di
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>

[VOTE] Release Apache EventMesh (incubating) 1.7.0-rc1

[Alex Luo]

Hello Incubator Community,

This is a call for a vote to release Apache EventMesh(Incubating)
version 1.7.0-rc1

The Apache EventMesh community has voted on and approved a proposal to
release
Apache EventMesh(Incubating) version 1.7.0-rc1

We now kindly request the Incubator PMC members review and vote on this
incubator release.

EventMesh community vote thread:
• https://lists.apache.org/thread/0t8lz5d3ypbnd1094tkrc57ql12w6ckl

Vote result thread:
• https://lists.apache.org/thread/p4zm61p636gjj7msmj8smyx8nsthn9kx

The release candidate:
•https://dist.apache.org/repos/dist/dev/incubator/eventmesh/1.7.0-rc1

Git tag for the release:
• https://github.com/apache/incubator-eventmesh/tree/v1.7.0-rc1
Release notes:
• https://eventmesh.apache.org/events/release-notes/v1.7.0

The artifacts signed with PGP key
235DBB05A82D0D8C1492D50079CD973EA1DBF237, corresponding to
alex...@apache.org, that can be found in keys file:
• https://downloads.apache.org/incubator/eventmesh/KEYS

The vote will be open for at least 72 hours or until the necessary
number of votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Thanks,
On behalf of Apache EventMesh(Incubating) community

RE: Proposal to Revive Apache Livy Community

[Alex Bozarth]

As the only Livy PPMC still responding to the Mentors on the private list, I 
have updated the Livy Podling report for November with the status of the 
project and a request to the IPMC to review this proposal since there are not 
enough active Livy PPMC members to reach a quorum to pass the proposal. 

As a current Livy PPMC I strongly support this proposal for revitalization as I 
do not have enough bandwidth to dedicate to Livy. 

 
Alex Bozarth
Jupyter Architect, IBM CODAIT
GitHub: ajbozarth

On 10/24/22, 1:41 PM, "larry mccay"  wrote:

Gentle reminder that we need to determine next steps here.
We have an updated proposal on this thread.
Do we need a VOTE or can we move forward directly to adjusting the members,
etc?

Thanks!

--larry

On Thu, Oct 20, 2022 at 3:26 PM larry mccay  wrote:

> @Justin Mclean  - any insights on next steps here?
>
>
> On Tue, Oct 18, 2022 at 5:44 PM larry mccay  wrote:
>
>> Very good, here is the latest revision with updated Mentors.
>> Sunil and I have been added to the IPMC as well.
>> Welcome Madhawa and thanks for stepping up as a Mentor for Livy!
>>
>> Abstract
>>
>> Livy is a web service that exposes a REST interface for managing long
>> running Apache Spark contexts in your cluster. With Livy, new 
applications
>> can be built on top of Apache Spark that require fine grained interaction
>> with many Spark contexts [1].
>>
>> While this project has been well regarded and used in many contexts as
>> the defacto standard API to Spark environments, it has been incubating 
for
>> over 5 years without graduation to a TLP and it has become difficult to
>> impossible for fixes and improvements to be contributed as the current
>> community seems to have moved on.
>>
>> There has been discussion regarding retirement of this podling where
>> there seems to be some increasing interest in joining and reviving the
>> community [2].
>>
>> The intent of this proposal is to avoid retiring a well regarded,
>> actively used and rather mature project by reviving the PPMC and 
community
>> with new folks that have a vested interest in the project and health of 
the
>> community.
>> Proposal
>>
>> We propose to revive the PPMC with a set of contributors and maintainers
>> as mentors, PPMC members and committers.
>>
>> The retirement DISCUSS thread [2] has shown a growing interest in
>> providing new committers and bringing improvements and fixes from
>> organization’s internally maintained forks back to a revived community.
>>
>> General Approach to Revival:
>>
>>-
>>
>>Add new Mentors
>>-
>>
>>   Larry McCay, lmc...@apache.org , Cloudera
>>   -
>>
>>   Sunil Govindan, sun...@apache.org, Cloudera
>>   -
>>
>>   Jean-Baptiste Onofré, jbono...@apache.org, Talend
>>   -
>>
>>   Madhawa Gunasekara, madhaw...@gmail.com, Independent
>>
>>
>>
>>-
>>
>>Add new Committers/PPMC
>>-
>>
>>   Larry McCay, lmc...@apache.org, Cloudera
>>   -
>>
>>   Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
>>   -
>>
>>   Imran Rashid - iras...@apache.org, Cloudera
>>   -
>>
>>   Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
>>   -
>>
>>   Wing Yew Poon, wyp...@cloudera.com, Cloudera
>>   -
>>
>>   Xilang Yan, xilang@gmail.com, Shopee
>>   -
>>
>>   Jianzhen Wu, myjianz...@gmail.com, Shopee
>>   -
>>
>>   Nagella Jagadeewara Rao, jnage...@visa.com, Visa
>>   -
>>
>>   Pralab Kumar, pralk...@visa.com, Visa
>>   -
>>
>>   Prasad Shrikant, shrikant@gmail.com, Visa
>>   -
>>
>>   Brahma Reddy Battula, bra...@apache.org, Visa
>>
>>
>>
>>-
>>
>>Invite existing PPMC members to opt-in or otherwise go emeritus
>>-
>>
>>   Jean-Baptiste Onofré, jbono...@apache.org, Talend (opted-in via
>>   Retirement DISCUSS thread [2])
>>
>>
>>
>>-
>&g

Re: [VOTE] Graduate Apache AGE (Incubating) as a TLP

[Alex Kwak]

+1 [non-binding]

On 2022/05/12 23:53:18 신한별 wrote:
> +1 non-binding
> 
>  Good luck!
> 
> 2022년 5월 9일 (월) 오전 8:34, Eya Badal 님이 작성:
> 
> > Dear Apache Incubator Community,
> >
> > Having passed the Community Graduation Vote [1] by the AGE community with a
> > vote result to graduate the incubation [2], we have discussed Apache AGE's
> > graduation in the general@incubator [DISCUSS] thread [3], where no issues
> > were raised and lots of positive responses were received.
> >
> > I would like to start this voting thread to request graduating Apache AGE
> > (incubating) from the incubator as a TLP.
> >
> > Please provide your vote as one of the following options:
> >
> > [ ] +1 - Recommend graduation of Apache AGE as a Top Level
> >
> > [ ] 0   - I don't feel strongly about it, but don't object
> >
> > [ ] -1  - Do not recommend the graduation of Apache AGE because …
> >
> > The VOTE will remain open for at least 72 hours.
> >
> >
> >
> > In addition to building and releasing the AGE software the Apache Way, the
> > Apache AGE (Incubating) project community has grown in the following areas:
> >
> >
> >-
> >
> >Close to 1000 commits
> >-
> >
> >Added 9 new committers (from 7 different companies/institutions in 7
> >different countries) and elevated 4 committers to PPMC
> >-
> >
> >7 Apache releases (AGE 0.3, 0.4, 0.5, 0.6, 0.7 and 1.0 and sub-project
> >AGE Viewer 1.0) from different release managers [4]
> >-
> >
> >4 mentors, 13 PPMC members / committers (mentors excluded)
> >-
> >
> >50+ unique contributors - Contributions span more than 20 countries
> >across the globe
> >
> >
> >-
> >
> >Developed and maintained the Apache AGE website [5]
> >-
> >
> >Created an online user guide updated automatically to support new
> >version of AGE. [6]
> >-
> >
> >Assessed ourselves against the Apache Project maturity matrix [7] and
> >didn't find any issues
> >
> >
> >
> >
> > [1] https://lists.apache.org/thread/q2cgbnhvpzk2k0m8yfh89lzc75qym9k9
> >
> > [2] https://lists.apache.org/thread/lr3x9bm8jyv6o5kvyh7cf3tyxrpp2kwm
> >
> > [3] https://lists.apache.org/thread/fhdc27bp8lp7nsklq0ttc3cvyx7543ky
> >
> > [4] Apache AGE website release page <https://age.apache.org/?l=versions>
> >
> > [5] https://age.apache.org/
> >
> > [6] Online user guide at Apache AGE website <https://age.apache.org/#>
> > under the Documentation menu
> >
> > [7] Apache AGE maturity assessment <https://age.apache.org/?l=maturity>
> >
> >
> >
> >
> > 
> >
> > Establish the Apache AGE 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 multi-model database that enables graph and relational
> >
> > models built on PostgreSQL.
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> >
> > (PMC), to be known as the "Apache AGE Project", be and hereby is
> >
> > established pursuant to Bylaws of the Foundation; and be it further
> >
> > RESOLVED, that the Apache AGE Project be and hereby is responsible for
> >
> > the creation and maintenance of software related to a multi-model
> >
> > database that enables graph and relational models built on PostgreSQL;
> >
> > and be it further
> >
> > RESOLVED, that the office of "Vice President, Apache AGE" 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 AGE Project, and to
> >
> > have primary responsibility for management of the projects within the
> >
> > scope of responsibility of the Apache AGE 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 AGE Project:
> >
> >  * Alex Kwak  

Re: [DISCUSS] Graduate Apache AGE (Incubating) as a TLP

[Alex Kwak]

AGE has been a fun project to be a part of especially because of the feedback 
and ideas from the graph data community.
I would love to see the project moving forward and keep contributing!

On 2022/04/27 03:45:33 Eya Badal wrote:
> Dear Apache Incubator Community,
> 
> Apache AGE (Incubating) passed the Community Graduation Vote [1] on Nov 9
> 2021 with a vote result to graduate the incubation [2].
> 
> After unsuccessfully closing the IPMC Graduation Discussion Jan this year,
> we believe that Apache AGE (Incubating) has resolved all the issues raised
> at the previous IPMC Graduation and matured well enough to graduate to a
> TLP.
> 
> Therefore we would like to raise the topic to graduate again for discussion
> with the IPMC.
> 
> The following is a brief summary of the progress of the Apache AGE project
> and its community during the incubation:
> 
> 
> 
>-
> 
>Close to 1000 commits
>-
> 
>Added 9 new committers (from 7 different companies/institutions in 7
>different countries) and elevated 4 committers to PPMC
>-
> 
>7 Apache releases (AGE 0.3, 0.4, 0.5, 0.6, 0.7 and 1.0 and sub-project
>AGE Viewer 1.0) from different release managers [3]
>-
> 
>4 mentors, 13 PPMC members / committers (mentors excluded)
>-
> 
>50+ unique contributors - Contributions span more than 20 countries
>across the globe
> 
> 
>-
> 
>Developed and maintained the Apache AGE website [4]
>-
> 
>Created an online user guide updated automatically to support new
>version of AGE. [5]
>-
> 
>Assessed ourselves against the Apache Project maturity matrix [6] and
>didn't find any issues
> 
> 
> 
> 
> [1] https://lists.apache.org/thread/q2cgbnhvpzk2k0m8yfh89lzc75qym9k9
> 
> [2] https://lists.apache.org/thread/lr3x9bm8jyv6o5kvyh7cf3tyxrpp2kwm
> 
> [3] Apache AGE website release page <https://age.apache.org/?l=versions>
> 
> [4] https://age.apache.org/
> 
> [5] Online user guide at Apache AGE website <https://age.apache.org/#>
> under the Documentation menu
> 
> [6] Apache AGE maturity assessment <https://age.apache.org/?l=maturity>
> 
> Please see the proposed board resolution below and let us know what you
> think.
> 
> The discussion will remain open for at least 72 hours.
> 
> 
> 
> Establish the Apache AGE 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 multi-model database that enables graph and relational
> 
> models built on PostgreSQL.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> 
> (PMC), to be known as the "Apache AGE Project", be and hereby is
> 
> established pursuant to Bylaws of the Foundation; and be it further
> 
> RESOLVED, that the Apache AGE Project be and hereby is responsible for
> 
> the creation and maintenance of software related to a multi-model
> 
> database that enables graph and relational models built on PostgreSQL;
> 
> and be it further
> 
> RESOLVED, that the office of "Vice President, Apache AGE" 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 AGE Project, and to
> 
> have primary responsibility for management of the projects within the
> 
> scope of responsibility of the Apache AGE 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 AGE Project:
> 
>  * Alex Kwak   
> 
>  * Dehowe Feng 
> 
>  * Eya Badal   
> 
>  * Felix Cheung
> 
>  * Jasper Blues
> 
>  * John Gemignani  
> 
>  * Josh Innis  
> 
>  * Juan Pan
> 
>  * Kevin Ratnasekera   
> 
>  * Nick Sorrell
> 
>  * Pieterjan De Potter 
> 
>  * Von Gosling 
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Eya Badal be appointed to
> 
> the office of Vice President, Apache AGE, to serve in accordance with
> 
> and subject to the direction of the Board of Directors and the Bylaws of
> 
> the Foundation until death, resignation, retir

[RESULT][VOTE] Apache AGE Viewer 1.0.0 (rc2) Release

[Alex Kwak]

Hello Incubator Community,

Thanks to everyone that participated. The vote to release AGE Viewer 1.0.0 in 
general@incubator is now closed and PASSED.

Vote thread : https://lists.apache.org/thread/dxgdpptnhp3p5vyp61wy5lopn304k8nt?


This vote passed with  14 +1 votes (3 bindings and 11 non-bindings) and no 0 or 
-1 votes.

+3 (Bindings)
--
* Trista Pan
* Kevin Ratnasekera
* Felix Cheung

+11 (Non-bindings )
--
* Joe Fagen 
* Jasper Blues 
* Mohammad Shaobib
* Young Seung Andrew Ko
* DongHu Kim
* Zhang Yonglun
* Eya Badal 
* Josh Innis 
* VUONG QUOC Viet
* John Gemignani 
* Nicholas Sorrell

I will be working on publishing the artifacts of Apache AGE Viewer (Incubating) 
1.0.0 and post an announcement.

Regards,
Alex Kwak 

Apache AGE (Incubating)

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

Re: [VOTE] Apache AGE Viewer 1.0.0 (rc2) Release

[Alex Kwak]

Dear everyone,

I am happy to announce that the vote passed successfully. I will announce the 
results shortly.

Best regards,
Alex Kwak


On 2022/03/04 05:54:39 Alex Kwak wrote:
> Dear Apache Community,
> 
> This is a call for releasing Apache AGE Viewer 1.0.0 (rc2).
> 
> The community vote thread can be found here: 
> https://lists.apache.org/thread/647z95htsgqbdwbt2xsmn3b245mj1g42
> The results of the community vote can be found here: 
> https://lists.apache.org/thread/z5xjwzttccr84g1xl30wz0b8pn1j34vh
> 
> 7 +1 Non Bindings
> Andrew Ko
> Joe Fagan
> Eya Badal
> Josh Innis
> VUONG QUOC Viet
> John Gemignani
> Nicholas Sorrell
> 
> To learn more about Apache AGE (Incubating), please see 
> http://age.apache.org/
> 
> *
> 
> Functionalities included and addressed in this release:
> - Graph visualization for AGE.
> - Extends edge and vertex point by point.
> 
> *
> 
> The git tag to be discussed and voted upon
> https://github.com/apache/incubator-age-viewer/releases/tag/v1.0.0-rc2
> 
> The git commit hash:
> commit 63ed1882e372ef8cdf6677e9850237650e586848
> 
> The release files, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/age/viewer/apache-age-viewer-1.0.0-incubating-rc2/
> 
> The SHA512 Checksum for these artifacts is:
> 683f17b6bfc84d9fd8c88f0856b4dd18fdb24ab429517134880594243601f6810fefe9f7d9da7d5a802e2236622974c4297cee874e0f06685e85a40d5ac90d3d
> 
> Release artifacts are signed with the following key:
> https://downloads.apache.org/incubator/age/KEYS
> 
> The fingerprint of key to sign release artifacts:
> 0E7F 408D 8C6A 1952 329C B379 D471 FDCE 5F5C 5B82
> 
> For more information about the contents of this release, see:
> https://github.com/apache/incubator-age-viewer/releases/tag/v1.0.0-rc2
> 
> *
> 
> The vote will be open for 72 hours.
> [ ] +1 release this package
> [ ] +0 no opinion
> [ ] -1 do not release this package because...
> 
> Thank you for all your time,
> Alex Kwak
> 
> 
> 
> -
> 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] Apache AGE Viewer 1.0.0 (rc2) Release

[Alex Kwak]

Hello IPMC,

Could you please support us in moving forward with this release? We need two 
more binding votes and would appreciate your time and help here.

The vote to release AGEViewer has been open for almost a quarter of a year and 
we are trying to make this release happen.

We put a lot of work and effort into this release, and this is our first 
AGEViewer release.

With @panjuan who reviewed and voted +1 binding, other mentors @Kevin 
Ratnasekera  @Felix Cheng  @vongosling would appreciate your support as well.

Thank you very much.
Alex Kwak

On 2022/03/04 05:54:39 Alex Kwak wrote:
> Dear Apache Community,
> 
> This is a call for releasing Apache AGE Viewer 1.0.0 (rc2).
> 
> The community vote thread can be found here: 
> https://lists.apache.org/thread/647z95htsgqbdwbt2xsmn3b245mj1g42
> The results of the community vote can be found here: 
> https://lists.apache.org/thread/z5xjwzttccr84g1xl30wz0b8pn1j34vh
> 
> 7 +1 Non Bindings
> Andrew Ko
> Joe Fagan
> Eya Badal
> Josh Innis
> VUONG QUOC Viet
> John Gemignani
> Nicholas Sorrell
> 
> To learn more about Apache AGE (Incubating), please see 
> http://age.apache.org/
> 
> *
> 
> Functionalities included and addressed in this release:
> - Graph visualization for AGE.
> - Extends edge and vertex point by point.
> 
> *
> 
> The git tag to be discussed and voted upon
> https://github.com/apache/incubator-age-viewer/releases/tag/v1.0.0-rc2
> 
> The git commit hash:
> commit 63ed1882e372ef8cdf6677e9850237650e586848
> 
> The release files, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/age/viewer/apache-age-viewer-1.0.0-incubating-rc2/
> 
> The SHA512 Checksum for these artifacts is:
> 683f17b6bfc84d9fd8c88f0856b4dd18fdb24ab429517134880594243601f6810fefe9f7d9da7d5a802e2236622974c4297cee874e0f06685e85a40d5ac90d3d
> 
> Release artifacts are signed with the following key:
> https://downloads.apache.org/incubator/age/KEYS
> 
> The fingerprint of key to sign release artifacts:
> 0E7F 408D 8C6A 1952 329C B379 D471 FDCE 5F5C 5B82
> 
> For more information about the contents of this release, see:
> https://github.com/apache/incubator-age-viewer/releases/tag/v1.0.0-rc2
> 
> *
> 
> The vote will be open for 72 hours.
> [ ] +1 release this package
> [ ] +0 no opinion
> [ ] -1 do not release this package because...
> 
> Thank you for all your time,
> Alex Kwak
> 
> 
> 
> -
> 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

[VOTE] Apache AGE Viewer 1.0.0 (rc2) Release

[Alex Kwak]

Dear Apache Community,

This is a call for releasing Apache AGE Viewer 1.0.0 (rc2).

The community vote thread can be found here: 
https://lists.apache.org/thread/647z95htsgqbdwbt2xsmn3b245mj1g42
The results of the community vote can be found here: 
https://lists.apache.org/thread/z5xjwzttccr84g1xl30wz0b8pn1j34vh


7 +1 Non Bindings
Andrew Ko
Joe Fagan
Eya Badal
Josh Innis
VUONG QUOC Viet
John Gemignani
Nicholas Sorrell

To learn more about Apache AGE (Incubating), please see 
http://age.apache.org/


*

Functionalities included and addressed in this release:
- Graph visualization for AGE.
- Extends edge and vertex point by point.

*

The git tag to be discussed and voted upon
https://github.com/apache/incubator-age-viewer/releases/tag/v1.0.0-rc2

The git commit hash:
commit 63ed1882e372ef8cdf6677e9850237650e586848

The release files, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/age/viewer/apache-age-viewer-1.0.0-incubating-rc2/

The SHA512 Checksum for these artifacts is:
683f17b6bfc84d9fd8c88f0856b4dd18fdb24ab429517134880594243601f6810fefe9f7d9da7d5a802e2236622974c4297cee874e0f06685e85a40d5ac90d3d

Release artifacts are signed with the following key:
https://downloads.apache.org/incubator/age/KEYS

The fingerprint of key to sign release artifacts:
0E7F 408D 8C6A 1952 329C B379 D471 FDCE 5F5C 5B82

For more information about the contents of this release, see:
https://github.com/apache/incubator-age-viewer/releases/tag/v1.0.0-rc2

*

The vote will be open for 72 hours.
[ ] +1 release this package
[ ] +0 no opinion
[ ] -1 do not release this package because...

Thank you for all your time,
Alex Kwak



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

Re: [DISCUSS] NuttX Proposal

[Alex Harui]

Might be less risk and disruption for a few experienced ASF folks to go "live 
amongst" the NuttX folks where they are now and verify that that the founder's 
authority and reputation will not result in a BDFL effect.

Just a thought,
-Alex

On 12/2/19, 12:48 PM, "Ted Dunning"  wrote:

Very well said.

I am optimistic.

On Mon, Dec 2, 2019 at 9:26 PM Gregory Nutt  wrote:

>
> > This is a good discussion to have had before entering the incubator, and
> I'm satisfied that the intent is good, and the podling can demonstrate
> during incubation that the founder will in fact step back and allow the
> project to move forward without the founder's undue influence.
> >
> > Note that it's fine for the founder to continue to work on the project,
> but in a different role.
>
> I have been standing back and not getting deeply involved with this
> discussion because it pertains too closely to me.  It is my intention to
> divest myself of total authority over the project just as stated in the
> Proposal.  Further, it is my intention to stay out of the initial
> formation of the project as much as possible, in partial fulfillment of
> Ted Dunning's "thought experiment."  I intend to vote 0 on all decisions
> before the PPMC -- unless, I suppose, I had some very strong opinion
> about some topic.  I cannot imagine what topic that might be, however.
>
> I will be available as needed for information needed by the others to
> accomplish this transition but for the most part, just consider me as on
> vacation in place.  I will help as much as needed and stay out of the
> way as much as possible.
>
> I suppose I should say a little more about my motivations in this.
> Without some understanding, is is reasonable to be skeptical.  Yes, the
> project is very dear to me and the result of many years of blood, sweat,
> and tears and years of work mostly done alone for crazy long hours.
> Being a "benevolent dictator" does not proper describe my past role
> because I was the ONLY person on the project.  I did everything.  I
> still do.
>
> There are two things that motivate me:  First, the workload has gotten
> to be far too much for one person.  I dispose of around 60-100 changes
> per week and really have no personal life left.  It is more than I can
> do (and much more than I can do well).  The only real way to solve that
> is to open the project up to others working as equals.  The second, and
> more important, motivation is the I am closing in on 70 years old now.
> I retired 8 retires ago and I cannot realistically control this project
> long into the future.   For my personal health and sanity, I really need
> to detach and let the project take a life of its own that does not
> depend on me in any way.
>
> I would see the biggest risk to a new PPMC would not be me, but rather
> the sheer volume of work that the PPMC is stepping into.  I am prepared
> for some initial chaos and perhaps a missed release cycle.  But I have
> come to accept that that is a reasonable price to pay for a clean
> knife-edge hand-off.
>
> Greg
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Podlings & IP Clearance

[Alex Harui]

IIRC, the main thing that matters is that all incoming code that was developed 
outside the ASF gets cleared.  For podlings, there is frequently one big code 
donation that eventually gets turned into a release.  The podling gets to put 
the code in a repo and then clear it.  I believe that's mainly to help get the 
community going with the least delay.  Podlings often do that one release and 
then graduate to TLP.

But once you have clean code in your repo, before you mix a bunch of other code 
into it, it is advised to clear it before mixing that code.  The IP Clearance 
process is the main way to do that and the Incubator is the central log of 
these big donations being cleared.

I don't think Weex had to go through IP Clearance if the mentors felt they 
could inspect and clear the code, but it doesn't hurt to ask for more eyes on 
it.

At least, that's how I remember it from my podling days.  Flex received several 
donations before and after graduation.

My 2 cents,
-Alex

On 10/4/19, 12:36 AM, "申远"  wrote:

Hi

As a PPMC member of Weex, I didn’t find any documentation about the IP
clearance process for Podlling project, so I just followed what other PPMC
did after asking in this mailing list [4]. I am Ok to do it in another way
if it’s written in the documentation clearly.

IMO, the problem here is that we don’t have an IP clearance process for
podllings, so podllings have no other way but follow the standard IP
process of TLP project.

[4]

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail-archives.apache.org%2Fmod_mbox%2Fincubator-general%2F201909.mbox%2F%253cDAEE7CD2-C05A-4A09-867C-37F1C1B19DF8%40classsoftware.com%253e&data=02%7C01%7Caharui%40adobe.com%7Cb9f970fbe1274b9a4d5608d7489da1b4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637057714181342086&sdata=Ak%2BXNWhu2ltjgGm7vksfmzyyxcbWHhwHNyUnuv8FjB4%3D&reserved=0

Dave Fisher 于2019年10月4日 周五13:18写道：

> Hi -
>
> > On Oct 3, 2019, at 9:12 PM, Justin Mclean 
> wrote:
> >
> > Hi,
> >
> >> The recent vote from Weex [1] made me think about the IP Clearance
> >> process.  Per [2], podlings should not follow this process and instead
> are
> >> directed to look at [3].
> >
> > I always assumed that that was advised about the initial codebase and
> don’t see an issue with following [2] past that. It certainly could be 
made
> clearer.
>
> I’ve always considered it to be the mentor’s job to assure IP was
> considered for podlings donations.
>
> A greybeard told me recently that the board added IP clearance to the IPMC
> for TLPs
>
> Regards,
> Dave
>
> >
> > 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
>
> --
Best Regards
York Shen
申远

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

[Alex Harui]

IMO, the key change as already been made:  There is now a WIP-disclaimer.

AFAICT, the rest of this thread has been an attempt to create an objective 
process around a subjective topic (in this case risk).  The better use of time 
may be to just launch an experiment by making the one change suggested by Greg: 
 That Infra and the board will allow a podling to put packages containing the 
WIP-disclaimer on dist.a.o as long as those packages also include "-incubating" 
or "-incubator" in the package name.

IMO, if that can be agreed to by the stakeholders, those stakeholders are 
agreeing that any risks to the foundation and RMs posed by Justin are worth 
taking and we can hopefully just move on and find out what happens.

Ideally, the WIP-disclaimer makes the IPMC vote:
1) optional
2) helpful
3) advisory

...instead of "potentially blocking".

This new disclaimer should allow mentors to allow the podlings to publish 
packages for their users the way they probably did before entering incubation.  
The podlings will have the option to push the packages to dist.a.o and then, if 
they want the legal shield protection, call for a vote from the IPMC if they 
don't have 3 mentor votes.  The key risk here is whether the WIP disclaimer 
will help ward off possible legal action by a user of the package.  IOW, is it 
too risky that something really awful will be missed by the mentors and PPMC in 
these packages?  I doubt it.  There might be GPL or proprietary code that needs 
to be replaced eventually.  But the new disclaimer helps and I just think folks 
aren't going to try to sue the ASF or a podling RM during this transition 
period.

If a podling is lucky enough to have 3 mentors review the packages, then that 
should make those packages an official ASF release and thus protect the RM.  If 
there aren't 3 mentors reviewing the packages, then the podling will have a 
reason to call for an IPMC vote to get the 3 votes.  The new disclaimer should 
greatly reduce the chances of a -1 vote.  Instead, issues found will be logged 
in the podling's bug tracker.

If the 3 mentors are certain enough of their review of the packages, then the 
podling can go on its merry way towards graduation.  Otherwise, the podling 
should call for additional IPMC reviews of their packages in order to avoid 
major surprises before graduation.  They just don't need to do it prior to 
publishing their packages, which makes the IPMC review helpful and advisory 
instead of potentially blocking.  Yeah, there is a risk that a published 
package will be so awful it needs to be pulled in spite of the new disclaimer, 
but IMO, there is always a chance we've missed something.  Practically 
speaking, if Justin is one of the 3 mentors, the podiing is probably in good 
shape heading towards graduation, of not, it probably is a good idea to get 
Justin to review the packages at some point.

IMO, it shouldn't take a special team of Greg/Ross/David to do this experiment. 
 As long as podlings can publish before the vote/review, and the new disclaimer 
makes the chance of pulling something back almost zero, every podling can 
choose this new route and the IPMC vote will rarely if ever be a gate.  It was 
this late gate which was stricter with the old disclaimer that was the problem 
for Zipkin.

HTH,
-Alex

On 8/14/19, 8:50 AM, "Sam Ruby"  wrote:

On Wed, Aug 14, 2019 at 1:24 AM Justin Mclean  
wrote:
>
> Hi,
>
> >> This is because of ASF bylaws i.e only PMC votes are binding on 
releases.
> >
> > That is not in the Bylaws. Stop making stuff up.
>
> That the way it’s been explained to me, several times, by experienced ASF 
people, that only PMC votes are binding on releases and podlings are not 
mentioned in the ASF bylaws. Bylaw wise see section 6.3.  But you're right, it 
would be more precise to say, it's a combination of 6.3 of the bylaws of the 
ASF and the ASF's policy on voting on releases. [1]

Concrete suggestion, and an offer to help.

The ASF bylaws contain a lot of curiosities such as "each member of a
Project Management Committee shall serve on such committee for a
period of one year or until his or her successor is elected and
qualified or until his or her earlier resignation or removal", and
have been interpreted as the board is the one that determines
membership of PMCs.  Over time, that understanding has evolved, and is
currently implemented as a notification requirement[2].

Perhaps something similar can be made to work here.  Outline of
proposed process:

1) Concurrent with the start of a release vote by a PPMC, the IPMC is
to be notified that that vote is happening.  IPMC members are
encouraged to participate in the vote process on the PPMC list where
it is happening.

2) If anybody o

Re: New disclaimer text

[Alex Harui]

Suggestion:  The DISCLAIMER references a detached copy of the DISCLAIMER at 
dist.a.o/releases/incubator/project and that detached copy is the one that gets 
updated with late breaking stuff.

Re-rolling required re-GPG-signing, new hashes, etc.

-Alex

On 7/3/19, 2:08 PM, "Daniel Shahaf"  wrote:

Dave Fisher wrote on Wed, 03 Jul 2019 12:16 -0700:
> This only works for issues known before a release is cut. It does NOT 
> WORK if the issue is discovered during the release vote. Why? Because we 
> are trying to allow the release to go through without redoing it and 
> this would require reworking the release.
> 
> I would rather do it outside of the release. Policing the actual 
> DISCLAIMER is not easily feasible and decreases the burden.

I recommend to put the information in DISCLAIMER.  Yes, that means bugs
in DISCLAIMER require re-rolling, but:

1. Bugs in DISCLAIMER should be found before the first artifact is
   rolled.  It's simply an audit and it can be done directly on the
   source tree in version control.

2. Re-rolling shouldn't be an expensive step that should be avoided. It
   should be "Edit DISCLAIMER, commit, run script to roll" followed by
   everyone diffing the old artifact to the new one and re-casting their
   votes based on the work they already did to review the old artifact.
   (And yes, it's still some effort, about which, see #1.)

3. Artifacts should state their exact license terms — accurately,
   completely, and (de facto standard) in-band.

Daniel

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

Re: Podlings, the Incubator, relationships and Apache

[Alex Harui]

FWIW, I reconcile it as:

Incubator is a PMC and must record a business decision to call something an ASF 
release in order to place that release under the legal protection of the ASF.  
ASF releases may have policy non-compliance issues.  No TLP can decide on its 
own to never comply with policy.  But the business decision of the costs of 
delaying a release to correct non-compliance vs risks of distributing a release 
with any non-compliance is up to the TLP.  VP Legal will assert a risk profile 
for any non-compliance and VP Legal or any ASF Member or PMC Member should try 
to stop a release if a TLP decides to distribute something highly risky.   But 
it is up to any TLP.  Including the IPMC.  And so the Incubator can do whatever 
it wants within limits.  Any of us should protest if the IPMC starts allowing 
releases with high risk.  But with the disclaimer and -incubating suffixes, the 
risk of many non-compliance issues are low, even CatX and binary inclusions.

Whether the incubator needs to have a secondary vote is not required by the 
above.  IPMC members could drop in on the podling vote thread.  Podlings with 3 
active mentors that vote on the podling's vote thread could be deemed 
sufficient.

My 2 cents,
-Alex

On 6/30/19, 12:11 PM, "Davor Bonaci"  wrote:

I do -not- have a problem where this is all tracking towards and believe it
is right, but I do have a problem with how it is justified and explained.

People say: "Incubator is a PMC/TLP", "Incubator takes on the resultant
legal obligations associated w/ any PMC doing a release", "we can NOT allow
any relaxation of the ASF release policy for a TLP", and then conclude that
Incubator can do ~whatever it wants. This logic does not pass the
consistency test.

So... if you want that [new] people in the future don't trip on this, it is
*necessary* to break this logic somehow.

On Fri, Jun 28, 2019 at 8:31 PM Greg Stein  wrote:

> On Fri, Jun 28, 2019 at 9:59 PM Justin Mclean 
> wrote:
> >...
>
> > >   It appears there is general consensus that "right to distribute
> closed
> > source" would be the main and potentially only blocker for podlings.
> >
> > That is not the case (re this is a blocker) I suggest you read that 
legal
> > thread again. Also infra makes distribution policy.
> >
>
> *distribution*
>
> Infra does not care about the contents. If a PMC says "we +1 the 
contents",
> then Infra will not second-guess that. Leave out LICENSE, NOTICE, or do
> those files wrong. Include jars, Cat X source. Whatever. We aren't going 
to
> police that. Binaries in there? Knock yourself out. Legal might get on 
your
> case, but that's Not Our Problem(tm).
>
> If the IPMC says "here is a podling tarball that we will allow", then it
> can be put into distribution. Use whatever rules you want for the 
contents,
> or lack of rules. Infra just wants it placed into our distribution system
> in a specific way, to ensure correctness, auditing, and resilience.
>
> VP Infra has already stated the above. As an Officer of Infrastructure, I
> concur and reiterate that position.
>
> Regards,
> Greg Stein
> InfraAdmin, ASF
>

Re: Podlings, the Incubator, relationships and Apache

[Alex Harui]

On 6/27/19, 10:57 PM, "Justin Mclean"  wrote:

But VP legal said as much the other day. "we can NOT allow any relaxation 
of the ASF release policy for a TLP.”

 I interpret that to mean that a TLP must eventually get around to fixing 
non-compliance.  A TLP cannot stop attempting to find non-compliance before 
shipping a release as well.  An "exception" would be a potentially permanent 
allowance of non-compliance.  And since I think VP Legal said that the legal 
committee mainly does risk profiling of non-compliance and the "business 
decision" is up to the PMC, I think that gives the IPMC the ability to be give 
podlings even more time to deal with non-compliance about most things.  It 
appears there is general consensus that "right to distribute closed source" 
would be the main and potentially only blocker for podlings.

My 2 cents,
-Alex   


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

Re: Podlings, the Incubator, relationships and Apache

[Alex Harui]

While you've been going through the history and other docs:  Does it actually 
say somewhere that a true ASF release MUST NOT contain any non-compliance of 
policy?  Or is it possible that the communities must fix some non-compliance 
issues right away and can fix others later?  Then it isn't about relaxing 
policy or exceptions to policy, it is just acceptance that not all policy 
non-compliance issues are "must fix now".

Sebb just reported that something like 3 TLPs have releases that are not 
compliant with the NOTICE file policy.  I don't think the legal shield has been 
damaged nor will the board shut down those projects.  I imagine they will 
simply take note and fix it in their next release.  They may not even have to 
drop everything there are currently working on and push out a release with the 
fix.

Again, the restaurant food handling codes allow the restaurant owners to fix 
some non-compliance issues over time.

HTH,
-Alex

On 6/27/19, 4:58 PM, "Justin Mclean"  wrote:

Hi,

> The Incubator itself is a PMC.

OK that's sorted.

> Now let's talk about podling releases... When the IPMC votes on accepting 
a podling release, and it passes, my opinion is that the Incubator takes on the 
resultant legal obligations associated w/ any PMC doing a release. Now the 
podling releases themselves are noted and described as "not GA" and "not 
official", et.al. but this is, again IMO, simply to make it clear to anyone who 
is downloading and using the software that the expectations normally associated 
with "regular" Apache releases do not apply, such that there could be some 
licensing issues, etc, that would be verboten in "official" releases, but may 
exist here. In other words: this is a podling release; expect issues and 
mistakes and churn.

Except it's not, as it seems the IPMC doesn’t need to abide by what other 
PMCs need to abide by when making releases :-) (Which is ironic given the IPMC 
is tasked with teaching and passing that knowledge on.) And that policy 
exception is not documented anywhere. :-) Nor has the board, to my knowledge, 
approved such an exception. Yay! So how is a voted on PMC release, an act which 
make it official, is not an official release? Do you see how this might be 
confusing or open to a board range of interpretations?

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

Re: Podlings, the Incubator, relationships and Apache

[Alex Harui]

On 6/24/19, 9:12 AM, "Roman Shaposhnik"  wrote:

> What kinds of policy violations truly affect the legal shield if the 
non-compliance:

You're asking the wrong question. You're still asking the TLP question.

I'm asking the TLP question to understand how big the difference is between TLP 
and Podlings.  If we allow podlings the ability to make releases with certain 
kinds of issues until they eventually get one release right, the question still 
remains that once they graduate and add some new dependency and make some (what 
I consider minor) non-compliance, will they be required to consider all 
non-compliance a release-blocker?  That would be a big cliff to jump off of and 
probably make for some unhappy newly-minted TLPs.

If you are saying that the TLPs get to make a "business decision" that sounds 
good to me.  IMO, it would be nice to have some sort of risk profile assessment 
associated with each release policy to help TLPs make better business decisions.

My 2 cents,
-Alex


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

Re: Podlings, the Incubator, relationships and Apache

[Alex Harui]

But, IMO, the reason the question went to VP Legal is that it doesn't really 
matter what the IPMC thinks if their "business decision" will have an impact on 
the "Legal Shield" and the insurance premiums that go with it.  So I think the 
question got lost on legal-discuss.  The "space of options" should probably be 
constrained by the "Legal Shield".

What kinds of policy violations truly affect the legal shield if the 
non-compliance:
1) is actually released
2) released but noted in RELEASE_NOTES or DISCLAIMER
3) released but not corrected in the next release

Ted, Roy, Hen, seem to say that only "no rights to distribute" and "CatX" 
should not be released by TLPs but "CatX" should be ok for podlings.  My 
takeaway from Roman is that all policy non-compliance issues are release 
breakers and Incubator should either be granted special status or not.  But I'd 
like to see the first question be answered so we can understand how special the 
Incubator status would have to be.  How different would it be from TLP releases 
and what risks to the foundation would that pose and could a DISCLAIMER or 
other means mitigate that risk?  Without knowing how the Legal Shield works, it 
is hard to know what the options truly are.

HTH,
-Alex

On 6/23/19, 10:43 PM, "Davor Bonaci"  wrote:

On Sun, Jun 23, 2019 at 10:04 PM Greg Stein  wrote:

> I disagree. I see a number of people who think that podling releases are
> TLP-level releases from the Incubator itself. I see people wanting
> structure/policy/rules to ensure these TLP releases are done properly. And
> that some want to "fix a few things" to make it easier for podlings to 
make
> these releases.
>

Perhaps you are right, but it is not necessary to debate it. (The
'disagreement' is about what other people think; we can let them speak up
and/or measure consensus or lack thereof in the usual ways.)

The balls rolls forward by understanding the space of options, and then
discussing it. (... the first part of which is happening on other threads.)

Re: Podlings, the Incubator, relationships and Apache

[Alex Harui]

IMO, there's an actual test case going on right now.  On 6/14, the Weex folks 
asked about an LGPL dependency which became LEGAL-464.  Personally, I think it 
could be classified as a "runtime/platform" so that the CatX rules don't apply. 
 But they have been held up for 9 days and counting.

Who could/should make the call that they should just put their packages on 
dist.a.o assuming it is a runtime and over time fix things, or must they wait 
for a careful analysis?

-Alex

On 6/23/19, 8:26 PM, "Roman Shaposhnik"  wrote:

On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen  wrote:
>
> A couple of thoughts:

And a couple of thoughts on top of that.

> Podlings are not permitted to call themselves "Apache Foo" because they 
are
> not yet full Apache projects.

Correct. The I way I see this thread is this: *when it comes to
releases*, there's
always been two camps in Incubator. One thinks that Incubator is a TLP just
like Apache Commons that happens to produce release artifacts that have
nothing in common (just like Apache Commons'  JXPath has very little to do
with Compress and). A second camp thinks that Incubator is actually a 
special
construct within a foundation (after all, if it was just like Apache 
Commons why
would we make them put DISCLAIMER into release tarballs?).

It seems that David is closer to the 1st camp, and Rich and I are
closer to the 2nd.

Looking at the community benefits, I really think we should acknowledge that
Incubator is a special construct and optimize that special construct
for a particular
outcome: which is effectiveness of the graduation process.

> While in the incubator we should expect podlibgs to fail at the rules.
> They're new to them and many of them feel arbitrary, even capricious, to
> those coming in from outside. We should make it safe to fail until they 
are
> ready to graduate. We should nurture them as long as they are moving
> towards that goal.

Yup.

> I cannot disagree with your reading of our resolutions. But I wonder if
> that reality is producing good citizen projects or a bunch of resentful
> people following rules they don't understand or embrace because they know
> they have to.
>
> Zipkin is only the latest project which clearly didn't get it and has left
> angry. I would rather a project realize that they don't fit and be able to
> leave with their dignity without having also to leave hating what we stand
> for.
>
> I want our new graduates to love and understand the ASF not merely 
tolerate
> it.
>
> I want the incubator to respond to failure with gentle correction rather
> than scoldings.
>
> Specifically I think podlings should be able to produce releases that are
> not asf complient and have them clearly labeled as such. Because they are
> not TLPs yet and so cannot be held to the same standard. This must be
> accompanied by a movement towards being a TLP, not some eternal 
incubation.

With my IPMC member hat on -- huge +1 to the above.

With my VP Legal hat on: I have no dog in this race. The IPMC needs to make
a *business* (well, community in this case) decision and then we can work
with a risk profile of that decision.

Like I said -- the decision to make is: 1st vs. 2nd camp.

Thanks,
Roman.

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

Re: Podlings, the Incubator, relationships and Apache

[Alex Harui]

It all makes sense to me.  I think there are two key points that are driving 
all of this discussion:

"5. Disclaimers generally don't remove liability"

IANAL so I don't know if that's true or not.  For sure there are lots of 
disclaimers in the world.  I do not know the history of the current DISCLAIMER 
(and labeling of releases with -incubating).  What was the DISCLAIMERs original 
purpose?  Should it be modified to cover less-than-perfect podling releases, 
especially around CatX inclusions?  Who gets to make that call?

" It's not perfect compliance vs. failure.
IMO, the IPMC has been delegated the decision making process, and may
often find themselves making the business decision that an imperfect
release is better than a community stalled for months or years. Don't
let the perfect be the enemy of the good."

I think several "prominent" ASF members are saying this same thing, but nobody 
really wants to make it official.  The responsibility seems to have been passed 
around between IPMC, Board, and VP Legal.  How can the ASF get closure on this 
topic?

My 2 cents,
-Alex

On 6/20/19, 10:04 AM, "David Nalley"  wrote:

There's been a lot of discussion in various threads about bureaucracy,
whether podlings are part of the ASF, etc. As a result of that I've
spent a good deal of time reading resolutions and older discussions
and organizing those thoughts from a legal and community perspective.
I've also read a number of conversations from the more august members
of our body about this subject. Altogether it has somewhat changed
some of my opinions and assumptions. I've also sensed that there is a
community/business/legal disconnect in our conversations. We're using
the same words to mean very different things in each of those
contexts. That said I am but one member of the IPMC, but maybe this
will be helpful to someone else - I've tried to avoid my assumptions
in this.

The IPMC's first 'job'[1] is "accepting new products into the
Foundation" The second 'job' of the IPMC is to "provide guidance and
support to ensure that the Incubator's sub-projects[2] develop
products according to the Foundation's philosophy and guidelines". The
final 'job' is evaluating the products and determining whether they
should be abandoned, continue to receive guidance and support, or be
promoted to "full project status".

So there are several realizations I gained from this from the
Incubator perspective.
1. Acceptance into the Incubator is acceptance of the product into the
Foundation.
2. That product is then a sub-project of the Incubator.
3. The IPMC has the "primary responsibility for the management of
those subprojects".

From the Foundation's perspective there are a number of things that
come to mind:
1. We aren't a github/sourceforge/google code type platform where
random people can upload/post what they want.
2. We do not have DMCA Safe Harbor protection - e.g. we are
responsible for everything that we publish or distribute. With the
exception of wikis and bug trackers anyone who can put something up on
an Apache property has some form of legal relationship with the
Foundation. This could be as simple as an ICLAs where you've
contractually said you won't contribute anything you don't have rights
to.
3. Most of the project's who have come to us aren't entities in and of
themselves. E.g. the 'project' doesn't truly exist from a legal entity
perspective - and even those who do are at best an unincorporated
association of individuals. From a legal perspective - projects can't
make or distribute a release - they don't exist - only the ASF and the
individual(s) doing the work. Given that one of the explicit reasons
the Foundation was created was to[5]: "provide a means for individual
volunteers to be sheltered from legal suits"; we want them to create
and distribute releases as the Foundation.
4. Whether we like it or not - the Foundation is judged on the output
from our projects and subprojects. We have a reputation of having
clean IP, permissively licensed open source code, with clear
provenance. Many people explicitly copy our standards, guidelines, and
policies because they are the gold standard for good open source
governance.
5. Disclaimers generally don't remove liability, and even if they did,
our disclaimer talks about the maturity of our projects. - And it
certainly doesn't remove the public's expectations from us - frankly -
losing the publics trust is as scary as the potential legal liability.
6. Th

Re: Incubation Pain Points

[Alex Harui]

I know this isn't the latest posts on this thread, but this is the post that 
best suits what I want to say.

Almost all of my posts recently have been about trying to determine if all 
policies must be attached to the same pendulum.  I think I'm seeing from Ted, 
Roy (in the past), and Hen that some policies are more important than others.

IMO, each policy could be graded under 4 categories:
1) inflexibility/ambiguity - are there different ways to interpret/implement 
the policy
2) effort to prevent non-compliance
3) cost/effort to fix non-compliance
4) cost/effort of non-compliance

I'm going to assume that the cost of canceling a release candidate is 
significant, not just in person-time, but momentum, and time due to restarting 
the 72-hour vote clock.

When a policy has ambiguity, or requires effort to prevent non-compliance, 
including understanding the policy and how to apply it, and it can result in a 
high cost effort to fix, you have the perfect storm, and so you'll receive 
feedback to try to eliminate ambiguity or reduce effort to prevent, or make the 
policy easier to understand and apply (or improve tools to find 
non-compliance).  But if it turns out you can simply reduce the cost to fix by 
not having that policy be a release breaker, then I don't think you'll get as 
much feedback asking for the policy or tools to be more specific.

I think I see consensus that the only truly important release policies are 
around:
1) Legal right to distribute.  IMO, this is inflexible, and not ambiguous.  The 
policy is easy to understand: you either have documentation that says you can 
distribute each line of code or you don't.  There is effort required to check 
each line of code, but the cost of non-compliance is significant.
2) No usage restrictions.  IMO, this is inflexible for TLPs.  It is ambiguous 
only in the sense that new situations could come up that haven't been covered 
before, but I think we could just list the most common things that cause usage 
restrictions and that would help folks get a sense of what this is all about.

The only wiggle room in these two may be in the quality of the documents.  It 
should be ok to ship something where there is general consensus that there is a 
right to distribute even though the supporting documents aren't perfect.  For 
example, a file is not listed in an SGA but doesn't really contain anything 
important, or the words chosen to document a re-licensing from GPL to MIT could 
be better, or the license was changed from GPL to MIT in every file but one due 
to a clerical error.

Everything else related to releases could be fixed later, significantly 
reducing the cost to fix.

And then the only other thing I would suggest beyond that is trying to get 
advisors to preface advice with "this is how I would (or have) done it", 
especially for the more ambiguous or hard-to-understand policies.  And that, I 
think would stop the pendulum from swinging.

For Podlings, the cost of fixing a usage restriction issue can be significant 
if they have been relying on, say,  a GPL dependency before coming to the ASF.  
I hope someone with authority (VP Legal, Board) finally decides that the 
DISCLAIMER is enough to let podlings have the time to replace that dependency 
or make it optional.

IMO, the Maturity Model contains a lot of things that are ambiguous because 
there are multiple ways to implement it.  I think that's totally fine: I 
thought the ASF was ok with diversity in how projects execute.  And so the 
introductory materials about the Incubator should state that you may get 
differing opinions and that is fine.  Maybe the MM should indicate which ones 
are not flexible (where you shouldn't be getting different advice from 
different people on how to execute).  I think it would be LC10-40, RE20&30.

To close with Justin's bread analogy:  A bread maker that just says "just add 
yeast and flour and water, kneed, let rise and bake" and then makes you toss 
out the results and start over is not going to attract nearly as many students 
as the bread making expert who can more clearly provide instructions in a 
friendly way, helps you catch your mistakes before you go too far down the 
road, and doesn't make you start over except in a few extreme cases.  For sure, 
if you sign up to be a bread making apprentice at the most prestigious bakery, 
then you can expect less leniency and stricter standards.  It is up to the ASF 
to decide if they want the reputation of being that picky or not.  I hope not.

My 2 cents,
-Alex

On 6/18/19, 10:33 AM, "Ted Dunning"  wrote:

Alex, Jim, Bertrand,

This discussion is re-inventing a discussion that has been had before. At
one time, the incubator tried to present principles to incoming podling
(albeit not in a very well documented fashion). The reaction was that
podlings strongly wanted specifics, no

Re: Incubation Pain Points

[Alex Harui]

On 6/18/19, 5:03 AM, "Jim Jagielski"  wrote:



> On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz 
 wrote:
> 
> On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski  wrote:
>> ...prepping the existing community regarding what "moving to the ASF 
means" is the job of the Champion, no?...
> 
> I agree but it has to be based on written docs, not oral tradition as
> that does not scale.
> 

Of course... but lack of it being on written docs does not make it invalid 
nor not policy.

Just trying to follow these threads, it isn't clear there is agreement, even 
among the "old-timers", as to what the invariants really are whether written or 
oral.

For example, I'm a bit surprised that none of the old-timers disagreed that 
there is an Apache Culture and that incubation is about assimilating into that 
culture.  I thought I read many times on various ASF lists that the ASF is 
comprised of many projects each with their own culture.  And that the only 
common ground is a "Way" not a "Culture".  But then various folks try to define 
the "Apache Way" and other folks disagree with their definition.

At least in the US, there are many places where the residents have formed or 
retained their own culture.  Folks immigrating to the US are not required to 
assimilate into any particular aspect of US culture.  They are only asked to 
obey certain laws.  And even then, the strictness of law enforcement is 
somewhat influenced by the local culture and context.

What really are the invariants at the ASF that require strict inflexible 
immediate enforcement?  I think there are really only a relatively small number 
of them:

1) No closed source in a release
2) No CatX in a release
3) No corporation owns decision making
4) Majority vote on releases
5) No advertising the general availability of non-releases.
6) A protocol for handling security issues.
7) ASF does not pay developers
8) Don't violate US Non-Profit rules

A podling could be granted more flexibility around #2 and #5 with the 
additional requirement of DISCLAIMER and -incubating labels.

Could everything else really be seen as goals for a community?  Then it would 
be "Community over Code and Policy except these 8 things".

My 2 cents,
-Alex

-
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: LGPL dependency

[Alex Harui]

Some  things I don't think have been mentioned in this thread so far:

1) Even if you make Webkit optional by offering V8, I believe the ASF criteria 
for "optional" includes "less than half of your users will use that option" and 
so if Webkit offers better performance and most of the users select Webkit over 
V8, it won't really qualify Webkit as optional.
2) AIUI, the ASF does not care about the licensing of RUNTIMES (my emphasis) 
your project's code runs on.  Otherwise, no ASF project could run on Windows or 
OSX.  Apache Flex runs on Adobe Flash/AIR runtimes.
3) I could not quickly find a direct quote for this, but I believe the ASF does 
not care about the licensing of BUILD TOOLS (emphasis mine) used to manipulate 
the source in the source release as long as the license of those tools does not 
constrain usage of that code (like some non-commercial restriction, or even a 
"no evil" restriction.

AIUI, the whole purpose of these restrictions is to not place restrictions on 
modifications to source or use of source when that source is eventually 
executed (whether interpreted or compiled or other).

So, if I've made that clear so far, the question I have for Weex is:  How is 
Webkit used in Weex?  Is it just a runtime and libraries for that runtime?  If 
so, then I believe it is ok to have a dependency on LGPL Webkit, but I would 
recommend that you find a way to not bundle Webkit in the release artifacts.  
Have it downloaded or make it a "prerequisite" just like I think every ASF 
Java-based project says you must install a Java JDK and don't bundle Java JDKs.

Other questions to ask relative to whether Webkit is a runtime or build tool:

A) Will anybody realistically want to modify the Webkit sources in order to use 
Weex?  If no, that's great, and another reason to not bundle those header files 
with your sources.
B) Will use of the WebKit header files and other binaries you depend on create 
a restriction on use?  If no, that's great as well, and I think if the answer 
to A and B are both "no", the IPMC should consider Webkit to be a 
runtime/build-tool dependency and let it go.

HTH,
-Alex


On 6/14/19, 5:09 AM, "York Shen"  wrote:

It depends on the definition of optional dependency. Weex targets iOS, 
Android and Browser environment and Webkit header files and shared library are 
only bundled for Android environment. As for other environments, the OS or 
browser itself has exposed enough API for Weex. 

PS: I am pretty sure that the iOS system itself uses almost the same code 
of Webkit as Weex does to build its WKWebView. It’s really strange that’s ok 
for Weex iOS and not ok for Weex Android.

> 在 2019年6月14日，19:17，Justin Mclean  写道：
> 
> Hi,
> 
>> Well, what if Weex copies some BSD header files in Webkit then run on 
Webkit? IMHO, the Webkit is also an environment for Weex in this case.
> 
> You still didi not answer if this is an optional dependancy? But again 
either way I suggest you ask on legal discuss.
> 
> 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




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

Re: [IMPORTANT] Board proposal on podling releases

[Alex Harui]

Maybe the next question is: Are all release policy violations showstoppers?  I 
suspect the answer is no.  And thus, if any TLP can punt release policy 
violations to a future release, then so can podlings, and the IPMC can let more 
things go without really needing another decision from the board.  Or maybe the 
only question for board or some authority is:  Can the IPMC be authorized to 
allow CatX in podling releases?

Ted gave an example in this thread of a legal issue where an attribution 
required by a dependency's license is missing.  I believe I've seen some 
long-timers say that those are not showstoppers.  Nobody is going to sue the 
ASF over that legal mistake as long as we respond positively towards fixing it 
in the next release.

I also think Ted explained in this thread the "why" behind many release 
policies more clearly and in fewer words than I recall from incubator 
documentation when I was in the incubator in 2012.  And that might better 
educate podlings and TLPs on how to make good choices on what can be deferred 
to a future release.

Seems like the only showstoppers for TLPs are:
1) content we have no right to distribute
2) content that distribution would break a law (maybe export restrictions, 
adult content)
3) CatX content

Maybe other legal issues like missing attributions MUST be fixed in the next 
release.

Other release policy violations SHOULD be fixed in the next release.

Not sure where to put inclusion of CatB source.  Would that also be a 
showstopper?

Podlings would be given flexibility on CatX/CatB, but also have showstoppers for
A) missing DISCLAIMER
B) missing "-incubating" in the source artifact package name.

My 2 cents,
-Alex

On 6/12/19, 11:44 PM, "Hen"  wrote:

On Sun, Jun 9, 2019 at 4:11 PM Justin Mclean 
wrote:

> Hi,
>
> > I agree with other respondents that 'serious' seems bad here. To me the
> > serious ones are the only ones they can't release with.
>
> So we just continue as is then? You have any suggests to what we change?
>

I don't think we're using the same word meanings.

I think that serious = release blocker; but I equally think there are very
few items that are serious.


>
> > ReleaseBlocking:  Has a LICENSE.  Legally permitted to release and
> complies
> > with the license via some mechanism.
>
> We currently allow releases that are not strictly legal. This would be a
> step backwards.
>
>
I'd love to hear some examples. I suspect they are all legal.

Speculating hypothetically:

* We should never make a release that we know there is some content in that
we explicitly do not have permission to publish.
* We should never make a release that we know contains content that is
criminal (for whatever that would mean).

Other than that... I'm not sure what else would come under 'all legal'
label.


> > GraduationBlocking:  Everything else; including complying with the
> license
> > via our preferred mechanism (i.e. we might want the MIT license text in
> our
> > LICENSE file, but would accept it being in the source header of the 
files
> > themselves).
>
> We currently allow podlings to graduate with some issues as longs as the
> PPMC is dealing with them. This would be a step backwards.
>
>
Yeah. We need a third category for "MehNotBlockingPleaseFix".


> > I don't see a need to go to the board on this :)
>
> If we don’t want to change anything - sure there's no need to go to the
> board.
>

I'd definitely like to see change. My feeling is that there's a lot we can
make that falls comfortably within the scope of the Incubator PMC. IIRC the
release policies came out of the Incubator; I don't recall there being a
request for the board to ratify them, but I might be failing to remember
something a decade+ ago :)


>
> >> issues have been fixed. The IPMC will add additional information to the
> > incubator DISCLAIMER to cover that podling release may not abide by all
> >
> > The IPMC? That sounds like a people scaling problem. The podling
> committee
> > should handle it.
>
> I mean just changing this page [1] , podlings can update their own
> disclaimers.
>

Gotya :)


>
> > "This release still has the following issues that will need to be
> resolved
> > before the Foo Project can graduate to an Apache vetted Top Level
> Project”
>
> What about unknown issues?
>

By th

Re: [IMPORTANT] Board proposal on podling releases

[Alex Harui]

The "legal shield" has been brought up by others as the reason for being so 
strict on policy compliance, hence my questions.

My takeaway from your responses is that the key factors are:
1) legal right to distribute.
2) no downstream limitations on field of use.

which I agree with and see no reason to change it.  However, that implies that 
other policy compliance issues (missing source headers, not-quite-right 
handling of LICENSE and maybe NOTICE) are not showstoppers and can be addressed 
in a future release, and that would save time not only for podlings, but for 
TLPs as well.

Then the main decision point for this thread is whether to allow podlings more 
slack on #2 given their artifacts are appropriately labelled and disclaimed.

Could an incentive be offered to podlings that if their release complies with 
both #1 and #2 that they can remove the -incubating label when copying the 
artifacts to dist.a.o?

Thanks,
-Alex

On 6/10/19, 11:13 AM, "Ted Dunning"  wrote:

The content of a release and the downstream limitations on field of use are
not a matter of legal shield. It has always been the case that the
fundamental promise of Apache has been that Apache software is easy and
safe to adopt and use.

Easy and safe meaning that you won't have nasty surprises like somebody
suing you for "being evil" or, worse, having your own lawyers veto a
critical release because a dependency of a dependency is GPL licensed or is
restricted from being used in anything that competes with smart plumbing
accessories.

Getting the foundation to relax that attitude of no downstream restrictions
is going to be nearly impossible.

    On Sun, Jun 9, 2019 at 10:53 PM Alex Harui  wrote:

> There's been a lot of discussion on relaxing requirements, but I don't
> recall any long-time ASF person explaining how fragile or durable the
> legal-shield and the insurance rates for it are.
>
> ...
>
> Unless someone can explain why that would ruin the legal-shield or raise
> insurance rates, I think that would save lots of community time getting
> releases out.  Otherwise, we might be expending precious energy
> overzealously trying to protect a legal-shield that doesn't need that 
level
> of protection.
>
> Does anybody truly know what will and will not ruin the legal-shield?  I
> have to imagine that releases have been shipped by the ASF and later found
> to be non-compliant with policy and that didn't ruin the legal shield or
> raise insurance rates.
>

Re: [IMPORTANT] Board proposal on podling releases

[Alex Harui]

There's been a lot of discussion on relaxing requirements, but I don't recall 
any long-time ASF person explaining how fragile or durable the legal-shield and 
the insurance rates for it are.

Ted and Roy (in other threads) seem to have said that Ted's bucket #1 is the 
only thing that is a true showstopper.  And Ted's adds a bucket #2 for TLPs.  
So maybe even for TLPs, all other issues can be punted to a next release.  
Maybe that's the only clarification that is needed from the board.  That no TLP 
will be frowned upon for deferring anything outside of bucket #1 and #2 to a 
future release and additionally no Podling will be frowned upon for deferring 
anything in bucket #2 to a future release.

Unless someone can explain why that would ruin the legal-shield or raise 
insurance rates, I think that would save lots of community time getting 
releases out.  Otherwise, we might be expending precious energy overzealously 
trying to protect a legal-shield that doesn't need that level of protection.

Does anybody truly know what will and will not ruin the legal-shield?  I have 
to imagine that releases have been shipped by the ASF and later found to be 
non-compliant with policy and that didn't ruin the legal shield or raise 
insurance rates.

Of course, I could be wrong...
-Alex

On 6/9/19, 9:13 PM, "Greg Stein"  wrote:

On Sun, Jun 9, 2019 at 8:27 PM Justin Mclean 
wrote:
>...

> Hi,
>
> > It takes a new mindset. What is the *bare* minimum MUST? Two items?
> > maaaybe three?
>
> Given this is probably a radical departure, would it be best to do as an
> experiment with a couple of podlings? Small reversible steps. Would you be
> willing to work on a proposal to the board and act a mentor on one or more
> podlings who took this path?
>

Not me. Any of my spare/hobby time goes to supplement my work for Infra.
There is no way that I could sustainably mentor a podling.

> And keep the IPMC out of it. No votes on releases. Stop second-guessing
> the
> > mentors and the podling communities.
>
> I don't see how IPMC votes are second guessing. IPMC votes are required.


"required"? Said who?

Be honest now. We are not talking a TLP release. This is "some code" from a
podling. It may have stuff in it that would make a Director stroke out
(maybe not Ted, it seems :p ) ... Why does the IPMC feel a need to put its
"imprimatur" on the release? And who/when said they must? And let's say we
can dig that up from the past ... why not remove/relax it?

It seems there is some consensus that podling releases are getting jammed
up by IPMC rules. Assuming that is true, then why not question the vote
process itself?

Let's say at least ONE of a podling's Mentors MUST give a +1. Then the PPMC
gets at least (2) more, majority blah blah. Then they throw some code into
the release directory. Go out for a beer.

Wouldn't that be acceptable?

>...

> That's ASF policy / bylaws not incubator policy.


Again: I disagree. This is not a TLP release. It is "some code" from a
podling.


> We could look into changing this, but probably best discussed in another
> thread.
>

Seems to apply here. Aren't we talking about releases from podlings?


> Not all mentors (who are IPMC members) vote on releases and podlings in
> most cases need to ask for extra votes from the wider IPMC. I would guess
> 90% of them, so I’m not sure how your proposal deals with that.


Just stop having the IPMC vote. No need to ask for votes. Done. Easy Peasy.

>...

> The IPMC already added one way for releases to get reviewed by the IPMC
> without a vote, but so far no podling has taken the IPMC up on the offer.
>

What other way? Link? Publicity for this? Never heard of it. One wonders
how podlings could do this, if they never learn of it. Now, I'm not
"steeped" in Incubator like you are, and apparently missed this. But I do
tend to follow much of the goings-on ...

And:

On Sun, Jun 9, 2019 at 9:30 PM Roman Shaposhnik 
wrote:
>...

> > I would expect that any graduating podling has this under control before
> > graduating and will not make any TLP releases with this kind of defect.
>
> I would suggest we make it a policy to document those exceptions in
> the DISCLAIMER file.
>

I would posit that most are not known at release time, but yes: it would be
a Best Practice to add those to a project's DISCLAIMER when found, to
inform downstream on the next release. And let's please not hold a
podling's release until things get added. ("no! stop! add to disclaimer".
rinse. repeat.)

Cheers,
-g

Re: [IMPORTANT] Board proposal on podling releases

[Alex Harui]

IMO, there could be several kinds of scenarios under the category of "copyright 
 violations".  Such as:

1) Taking something under someone else's copyright and claiming it under a 
different copyright.
2) No mention of the copyright or the entity owning the IP at all anywhere in 
the release files.
3) Mentioning the entity owning the IP but not actually copying the Copyright 
notice
4) Same as #3, but the root problem is the entity owning the IP did not 
properly place their copyright.
5) Not following recommended practices for placing copyrights in LICENSE or 
NOTICE
6) Not copying an upstream Copyright in a NOTICE file into the release's NOTICE 
file

And more.  

IMO, only #1 should hold up the release and only if the IP is not under some 
sort of Open Source license.  Otherwise, I think I recall past discussion where 
the entity owning the IP will probably just ask for attribution in the next 
release and not sue anybody as a first reaction.  After all they intended to 
share their code by putting it under an OS license.

My 2 cents,
-Alex

On 6/7/19, 11:46 AM, "Sam Ruby"  wrote:

On Fri, Jun 7, 2019 at 2:00 PM Craig Russell  wrote:
>
> Hi Justin,
>
> As a board member, I'm not comfortable with granting a blanket exception 
to policy that might put us at legal risk.
>
> As an IPMC member, I think that we do not want to allow podlings to 
release material that might put us at legal risk. I do think that the IPMC 
under today's policy has the ability to decide whether a podling release puts 
us at risk and therefore should be blocked. So I am not convinced that the IPMC 
needs to ask for this waiver from the board.
>
> My understanding as an IPMC member is that there are some items in a 
release that can be  allowed where they would not be in a TLP release. These 
things have historically drawn -1 votes from IPMC members.
>
> I think there is consensus that a podling release does not have to 
conform in every respect to what we expect from a TLP release.
>
> I think that the incubator IPMC should first flesh out (on the general@ 
list) which materials in a podling release are
> a) fine;
> b) minor issue (file a JIRA and fix before graduation); or
> c) blocker (puts the foundation at risk).
>
> The detail of what is minor versus what it a blocker is the most 
important thing that needs clarity. As of now, I don't see consensus although I 
see movement.

Drilling down by taking the contents of the draft incubator report:

"Serious problems, such as; including GPL licensed software, including
compiled code, or copyright violations, in a release is currently seen
as a reason to vote -1 on a release."

Picking them off one by one:

1) Is it legal to include GPL licensed software in releases?  The
answer is yes... as long as we comply with the terms of that license.
In the case of strong copyleft licenses, that could mean that the
podling release itself may need also be GPL licensed.

2) Is it legal to include compiled code in releases?  Yes.

3) Is it legal to include copyright violations in releases?  No.

> Craig

- Sam Ruby

> > On Jun 6, 2019, at 11:45 PM, Justin Mclean  
wrote:
> >
> > Hi,
> >
> > As suggested I’ve collated information from several threads and turned 
it into a proposal for the board. Any edits, feedback, agreement, disagreement 
etc etc is welcome. In particular it would be nice  to hear some feedback from 
people who are in favour of this.
> >
> > Note that this is important as it probably changes the advice mentors 
will give their podlings on releases and change in a positive way how we vote 
on releases with serious issues in them. If you are a mentor or vote on 
releases please read it. Again feedback welcome.
> >
> > If the board agrees with the proposal I think we'll need to update the 
incubator DISCLAIMER. I’ve suggested what we might add in the proposal but the 
exact changes can to be discussed here. If the board disagrees with the 
proposal I suggest we discuss and come up with a list of serious issues that 
the IPMC recommends voting -1 vote on a release. This is just guidance, not 
rules, and there may of course be exceptions. (For instance you could ask VP 
legal for an exception as has been done in the past.)  That way mentors and 
podlings have clear expectations on releases must contain.
> >
> > The proposal can be found in the draft board report. [1]
> >
> > Thanks,
> > Justin
> >
> > 1. 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FINCUBATOR%2FJ

Re: [IMPORTANT] Board proposal on podling releases

[Alex Harui]

IMO, it all comes down to the definition of "serious issues".  Some say that 
the only real blockers should be legal issues about the right to distribute 
some IP.

My 2 cents,
-Alex

On 6/7/19, 8:29 AM, "Kevin A. McGrail"  wrote:

On 6/7/2019 11:26 AM, Bertrand Delacretaz wrote:
> On Fri, Jun 7, 2019 at 5:22 PM Justin Mclean  
wrote:
>> ...I assume from your response that you disagree with the proposal or 
want it modified? If so how?...
> I don't think it's reasonable to allow releases with "serious" issues.
> But let's see what the Board thinks.

I would urge you to see the lengthy thread on the matter.

There are some requirements that were discussed like: acknowledging the
problem with a ticket, having a more descriptive disclaimer for
incubating releases, making progress on issues, etc. that can allow more
leniency.

-- 
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fkmcgrail&data=02%7C01%7Caharui%40adobe.com%7C4515751a25cc425ce81a08d6eb5cecc8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636955181672569755&sdata=gLFvGUjqgRTUwYUGgMiLGshWG7gac%2F9VcU%2BhBNYZ1yM%3D&reserved=0
 - 703.798.0171

Re: Podling releases and release policy

[Alex Harui]

Given that [1] says "may" and not "will" and that Roy has said that if it isn't 
illegal and better than the last release it is ok to ship a release candidate, 
maybe the ASF should adopt the approach that every release policy issue that 
isn't about the legal right to distribute some IP can be addressed in the next 
release if a TLP, and by graduation if a podling.

My 2 cents,
-Alex

On 6/4/19, 8:00 PM, "Justin Mclean"  wrote:

Hi,

Thanks Sam for the advice.

> Been lurking.  Before I proceed, I will note that you have two members
> of the board and one infrastructure representative participating.
> Each has either explicitly or implicitly supported the idea of the
> incubator setting direction for podlings.

Set direction sure, but does that include ignoring board policy? While we 
do currently for minor issues, I’m reasonably sure the board is OK with that, 
well none have complained. I’m not sure if doing that for serious issues is 
overstepping the mark or not.

See, for example, "why a foundation wide policy is needed”:  [1]
"Deviations from this policy may have an adverse effect on the legal 
shield's effectiveness, or the insurance premiums Apache pays to protect 
officers and directors, so are strongly discouraged without prior, explicit 
board approval”

> Now my observation.  My experience is that when a PMC comes to the
> board with an open ended question asking for advice, the responses are
> not crisp.

Understood. I was asked by a board member to ask the question in the next 
report, although they may not of been wearing that hat at the time.

> An approach I have found much more successful: come up with a
> proposal.  Often times it will get approved.  Some times you will be
> asked to make changes. 

OK I've written down what we currently do and that some have expressed an 
opinion that podling should be able to ignore distribution policy up until 
graduation in the current report. There is some support for it and no strong 
objection if that is OK by the board which is I think close to consensus.

If I am mistaken there please speak up.

Personally I don’t really care either way other than A) if I vote on or am 
a release manger for a release do I have the ASF legal protection (even if that 
release has serious issues) and B) it’s clearer when podlings need to fix 
issues.

I’m happy to change what I’ve written in the report into a proposal with 
the view that, from now on that IPMC will allow serious issues in podling 
releases, so the board only needs to say yes/no either explicitly or implicitly 
rather than choose from a list of options a sit currently worded.

If permission is given, then we’ll modify documentation and the DISCLAIMER 
to cover this and you’ll see fewer -1 votes. Podlings will be expected (as 
before) to fix all issues before graduation, so this may potentially block some 
podlings from graduation.

If they say no then we'll refine the list of serious issues we vote -1 on 
and communicate that to podlings. I think we can reasonably agree on that list 
with perhaps one possible exception (compiled code in binaries).

If anyone disagrees with this approach, or has an alternative suggestion, 
please speak up.

Thanks,
Justin

1.  
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23why&data=02%7C01%7Caharui%40adobe.com%7Cbc987bf1219d42bfa17e08d6e961fdd1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953004417339794&sdata=6yunnE%2BTZmQrD1mYiDpmgMRblswB4D1FX3NIYIrvX%2Fk%3D&reserved=0


-
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: Podling status Copyright section

[Alex Harui]

Hi Matt,

I'm not sure what "add" means, but there have been several past discussions 
where it appears that new code was brought in under a CCLA without an SGA.

https://lists.apache.org/thread.html/d77183d7efd5faf331534edf7ee2de993e908cffa4feb7454f9a6ab1@%3Cgeneral.incubator.apache.org%3E
https://issues.apache.org/jira/browse/LEGAL-236
https://lists.apache.org/thread.html/2814bd99f77325f80c6bfbf1156debd22bf556bfd4b9786996c9217c@1423476452@%3Cgeneral.incubator.apache.org%3E
http://s.apache.org/YPe

It is also my understanding (from Roy) that in some cases existing code can 
come in under an ICLA.

HTH,
-Alex

On 5/15/19, 4:27 PM, "Matt Sicker"  wrote:

You can add a software grant to a CCLA concurrently, but not vice versa.

On Wed, May 15, 2019 at 03:28, sebb  wrote:

> On Wed, 15 May 2019 at 06:55, Alex Harui  wrote:
> >
> > I do not like the words "transfer rights".  It could be interpreted as
> transfer of copyright.  Copyright of existing code is not transferred to
> the ASF, AIUI.  How about "Check to make sure that an SGA or CCLA has been
> received."
> >
> > I don't like hypotheticals, but I can imagine some individual starting a
> project on GitHub, has only a few files already under ALv2, and gets a
> project going at the ASF?  Wouldn't we accept those few files under his
> ICLA and not require an SGA or CCLA?
> >
> > I'd suggest dropping the second sentence ("it is necessary to transfer
> rights...").  AIUI, it is only necessary to grant a perpetual license to
> the ASF.
>
> Also, the CCLA is not required, and is not an alternative to the SGA
> -- as may perhaps be inferred by some from the phrase "(SGA or CCLA)"
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flicenses%2Fcla-faq.html%23cclas-not-required&data=02%7C01%7Caharui%40adobe.com%7C7b354edcc5b244d70e7c08d6d98ced18%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636935596691256488&sdata=xS2K8uFmOV367uU65bfbmB6XR5IGsdY8OirvNAiyNO4%3D&reserved=0
>
> > I like your third sentence.
> >
> > HTH,
> > -Alex
> >
> > On 5/13/19, 5:28 PM, "Craig Russell"  wrote:
> >
> > The Copyright section of the podling status page says "Check and
> make sure that the papers that transfer rights to the ASF been received. 
It
> is only necessary to transfer rights for the package, the core code, and
> any new code produced by the project.".
> >
> > I'd propose a change:
> >
> > "Check to make sure that the papers that transfer rights to the ASF
> been received (SGA or CCLA). It is necessary to transfer rights for any
> existing package and core code. Any new code produced by the project must
> be covered by ICLA."
> >
> > This change is proposed because it might not be obvious to everyone
> what "the papers that transfer rights" are. And new code produced must be
> committed by a person who has filed an ICLA.
> >
> > Patches welcome.
> >
> > Craig L Russell
> > c...@apache.org
> >
> >
> > 
-
> > 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
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
> --
Matt Sicker 



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

Re: Podling status Copyright section

[Alex Harui]

I do not like the words "transfer rights".  It could be interpreted as transfer 
of copyright.  Copyright of existing code is not transferred to the ASF, AIUI.  
How about "Check to make sure that an SGA or CCLA has been received."

I don't like hypotheticals, but I can imagine some individual starting a 
project on GitHub, has only a few files already under ALv2, and gets a project 
going at the ASF?  Wouldn't we accept those few files under his ICLA and not 
require an SGA or CCLA?

I'd suggest dropping the second sentence ("it is necessary to transfer 
rights...").  AIUI, it is only necessary to grant a perpetual license to the 
ASF.

I like your third sentence.

HTH,
-Alex

On 5/13/19, 5:28 PM, "Craig Russell"  wrote:

The Copyright section of the podling status page says "Check and make sure 
that the papers that transfer rights to the ASF been received. It is only 
necessary to transfer rights for the package, the core code, and any new code 
produced by the project.".

I'd propose a change:

"Check to make sure that the papers that transfer rights to the ASF been 
received (SGA or CCLA). It is necessary to transfer rights for any existing 
package and core code. Any new code produced by the project must be covered by 
ICLA."

This change is proposed because it might not be obvious to everyone what 
"the papers that transfer rights" are. And new code produced must be committed 
by a person who has filed an ICLA.

Patches welcome.

Craig L Russell
c...@apache.org


-
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: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Alex Harui]

As a peanut, IMO, it could be that the root problem is that the drive-by folks 
are discussing topics that are too subjective at a critical time (to get a 
release out), not the number of folks who can drive-by.  I'm not even in the 
IPMC, and I can still follow general@ and offer opinions.

Podlings would have their lives improved if there were more folks available to 
help in little increments if the help was consistent.  It would be a stronger 
community if more people could help pound a nail or fix a flat tire.  It would 
take the load off the folks in charge.  More people would get more done with 
less burnout.

In some ways, Roy's suggestion to stop having an IPMC vote as a gate for a 
podling release can help by making it less critical to get someone official to 
rule on something "now".  Just ship it, note it in the bug tracker, and get to 
it when you can find someone to help you or take your time resolving it, 
gathering different opinions and coming up with a solution, even a temporary 
one.  Not all issues need to be addressed before graduation, IMO.  Some issues 
just aren't stop-ship and won't ruin the legal shield or put the ASF in legal 
jeopardy.  Policy issues are not always legal issues.  In fact, I think most 
aren't.

Maybe we should try to reduce subjectivity by getting more consensus on what 
issues are really important and which ones aren't.  That might get more 
consistency from the drive-bys.  But some of these issues are judgement calls 
and folks will have different opinions and podlings might be better served by 
being advised to get second opinions.

Reducing the number of volunteers and holding them to a higher standard seems 
anti-volunteer.  It is why I've never asked to join the IPMC.   I can pound a 
nail and fix a flat tire, though.  Finding ways to reduce the size of the tasks 
and requirements on the timing seems like it would attract more volunteers and 
be more helpful.  Instead of having to review an entire release in order to 
cast a binding vote on it, maybe I could spend 5 minutes to just run RAT on it 
and if it finds a binary, open a ticket asking why.

HTH,
-Alex

On 3/2/19, 3:55 AM, "Greg Stein"  wrote:

On Sat, Mar 2, 2019 at 5:17 AM sebb  wrote:

> On Sat, 2 Mar 2019 at 10:49, Greg Stein  wrote:
> >
> > On Sat, Mar 2, 2019 at 2:50 AM sebb  wrote:
> >
> > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean 
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > > I agree that it's not ideal but it is not a symptom of a big
> problem
> > > either. We have inactive IPMC members who might become active again
> later
> > > if a community wants to join the incubator but it's a hassle to leave
> and
> > > then join again.
> > > >
> > > > Some context, over 300 projects have gone through the incubator, 50
> are
> > > there currently, each requires a champion and 3 mentors at the start
> (all
> > > IPMC members), even with some mentors working on multiple podling it's
> not
> > > surprising the IPMC is 300 people or so. Nor should it be that a large
> > > number of them are inactive as most of the projects they were involved
> in
> > > have graduated (or retired).
> > >
> > > +1
> > >
> > > > But despite this some still think it is an issue so we IMO we should
> > > address it, unless they change their minds, and say so here.
> > >
> > > Personally, I don't think that is a reason to reduce the IPMC count.
> > > I think it needs to be established WHY it is thought to be an issue
> first.
> > >
> >
> > It encourages drive-by bikeshedding. "I'm an IPMC Member from a few 
years
> > back. I see $foo, and OMG need to comment on it."
> >
> > Did anybody stop and read the concerns recently raised to the Board? 
Much
> > of the focus on that email was about such drive-by commenting.
> >
> > Thus, reduce the opportunity for drive-by.
>
> Since the general@ list is public, I don't think reducing the IPMC
> will stop comments.
>

So? It is to reduce the number of people who feel empowered to meddle into
everything every podling does. You want to fix general@ ??, then go ahead.
I want to see people who choose not to *participate* in the IPMC [by
subscribing to private@] dropped from the roster. The whole world can chat
on general@. But if you want to be *part* of the IPMC, and want a binding
vote, and want to really throw

Re: Welcome Wagon

[Alex Harui]

Hi Dave,

IMO, the Incubator is the "welcome wagon".  Unfortunately, it often greets new 
neighbors with a huge list of policies which is not welcoming.  That makes the 
incubator more iike a bad Homeowner's Association from a movie.  Or maybe a 
Boot Camp where only the tough survive and everyone else washes out.  When I 
think of the word Incubator, I think of baby incubators in hospitals where 
staff goes out of their way to help each baby survive and then thrive, not one 
where the goal is selection of a few.

-Alex

On 2/25/19, 11:48 AM, "Dave Fisher"  wrote:

Hi -

There has been mentions about lack of documentation, not being able to find 
documentation, not being responsible for a policy, and not including the 
rationale for a policy.

This morning I remembered something that happened some 49 years ago when I 
was a child and we moved to the suburbs of Chicago. A nice lady came over to 
the house from a group that called themselves the “Welcome Wagon”. She provided 
goodies and all kinds of information about both the local subdivision and the 
village.

I wonder if this is something that the Incubator could help build and 
disseminate?

An Incubator Welcome Wagon could be a Guide of Guides and include 
introductory information about:

(0) Onboarding
(1) Community Development
(2) Infrastructure and Builds
(3) Legal Policy
(4) Release Policy
(5) Press
(6) Foundation Structure

This information would come from the definitive committee and the mentors 
and podlings could provide feedback to the appropriate committees.

I think something like this would help the Incubator and Mentors be more 
facilitator and less police.

Regards,
Dave
-
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: Binary jars in the source release which are only for testing

[Alex Harui]

Or, can you change your build script to download the jar instead of packaging 
it in the source release?

On 2/23/19, 6:02 PM, "Ted Dunning"  wrote:

Willem,

This issue of embedded binaries for testing purposes has come up before.
Examples include network intercepts for testing malware detection or class
files for a byte code manipulator. The network files can't easily be
recreated since they were observed in the wild and the class files might
have been produced by a specific (possibly broken) compiler version that
isn't widely available.

The key question is whether these binaries are derived from some source
that could be compiled instead of distributing the binary objects. Failing
that, can the provenance and justification for the binary object be
described?




On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang  wrote:

> Hi
>
> Thanks Justin for the clarification.  I guess the policy imply the
> source materials cannot have any binary.
> But what if the binary is only for testing, which cannot be part of
> the released software.
> From my point of view, we don't need to modify the source materials
> testing binary to do the software release as it is not a part of the
> binary release of the software.
>
> Any thoughts?
>
> Regards,
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > > 
[1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23what&data=02%7C01%7Caharui%40adobe.com%7Cf5a610c610a847bf492408d699fc1ad8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636865705492422828&sdata=aLOPz6UB1Fz4oNJYUYf6LZKwNeTkGhfNC1Q9Nmq6vok%3D&reserved=0
> >
> > It’s explained in that link there i.e.  "The Apache Software Foundation
> produces open source software. All releases are in the form of the source
> materials needed to make changes to the software being released”.
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [ANNOUNCE] Apache Dubbo(incubating) 2.7.0 has been released

[Alex Lv]

Nice to hear that, cons!

 Outlook for Android


From: Taosheng, Wei 
Sent: Tuesday, January 29, 2019 6:16:30 PM
To: dev; dev; Incubator General
Subject: Re: [ANNOUNCE] Apache Dubbo(incubating) 2.7.0 has been released

Congratulations :)
It??s an exciting news!


-- Original --
From: Huxing Zhang 
Date: Tue,Jan 29,2019 6:00 PM
To: dev , Incubator General 

Subject: Re: [ANNOUNCE] Apache Dubbo(incubating) 2.7.0 has been released



Hi community,

The Apache Dubbo(incubating) team is pleased to announce that the
2.7.0 has just been released.

Both the source release[1] and the maven binary release[2] are available
now, you can also find the detailed release notes in here[3].

2.7.0 is a major milestone, when migration from 2.6.x to 2.7.0, please
refer to this guide[4].

If you have any usage questions, or have problems when upgrading or find
any problems about enhancements included in this release, please don??t
hesitate to let us know by sending feedback to this mailing list or filing
an issue on GitHub[5].

[1] 
https://www.apache.org/dyn/closer.cgi?path=incubator/dubbo/2.7.0/apache-dubbo-incubating-2.7.0-source-release.zip
[2] http://central.maven.org/maven2/org/apache/dubbo
[3] https://github.com/apache/incubator-dubbo/releases
[4] http://dubbo.apache.org/zh-cn/docs/user/versions/version-270.html
[5] https://github.com/apache/incubator-dubbo/issues

--
The Apache Dubbo(incubating) Team

Re: licenses and copyrights of dependencies

[Alex Harui]

IIRC, we use the food allergy analogy for these situations.  AIUI, the goal is 
for the top-level LICENSE to make it convenient for someone to see what the 
ingredients are, because some folks are "allergic" to certain licenses.  I 
think you can still use "pointers" instead of copying full texts of licenses, 
but having people open jar files to read the licenses seems to defeat the 
"convenience" of reading the ingredients.  If your packaging can extract a 
LICENSE from each jar you could point to those files.

My 2 cents,
-Alex

On 11/7/18, 8:07 AM, "Jonas Pfefferle"  wrote:

Hi Vincent,


At least right now we have the source code part covered since we do not 
ship 
any third party code/jars etc. with it. However, as you pointed it is a 
concern for the binary release. We just want this to be easy to  manage. At 
the moment we have 80+ jars that we ship as dependencies in the binary 
release. As pointed out before all of them have the license at least 
mentioned in the pom or have a license file in META-INF. Best case scenario 
we could just list all jars in the LICENSE file and refer to their license 
in the jar instead of copying everything. This makes it much easier to 
add/remove dependencies or change versions...
Does this make sense?

Thanks,
Jonas

  On Wed, 7 Nov 2018 15:56:45 +
  "Vincent S Hou"  wrote:
> Hi Jonas,
> 
> I totally understand your situation right now, because I have just 
>gone through the release process for my project Apache OpenWhisk as 
>well.
> 
> Regarding whether you should add the copyright, to me, it depends on 
>the source code release or the binary release.
> If you only care about the source code release, you can only focus 
>on the "SOURCE CODE". For example, if one or some of your SOURCE CODE 
>come from another library with a certain copyright, you should add it 
>into your LICENSE file. If your code depends on jar or any other 
>packages shipped by other parties, you do not need to add their 
>copyright into your LICENSE, because your source code release do not 
>and should not include any jar or packages. You can document 
>somewhere that these jars or packages are dependencies to run your 
>code.
> 
> If you come to binary release, and all the dependencies play a role 
>in order to compile your source code, you need to have the LICENSE 
>file with all the copyright for the dependencies.
> 
> In a nutshell, source code release is relatively easier to edit your 
>LICENSE, but binary release may be a hassle. 
> 
>For folks with different comments, welcome to chime in.
> 
> 
> Best wishes.
> Vincent Hou (侯胜博)
> 
> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, 
>IBM Cloud
> 
> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: s...@us.ibm.com,
> Phone: +1(919)254-7182
> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, 
>United States
> 
> -"Jonas Pfefferle"  wrote: -
> To: "general@incubator.apache.org" 
>From: "Jonas Pfefferle" 
> Date: 11/07/2018 07:35AM
> Subject: licenses and copyrights of dependencies
> 
> Hi all,
> 
> 
> We are just preparing a new release and are wondering how and what 
>is 
> required for licenses and copyrights of components shipped with an 
>artifact. 
> According to the release 
> policy 

>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23distribute-other-artifacts&data=02%7C01%7Caharui%40adobe.com%7C22616922cce64b8fc10a08d644cb21ff%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772036594764319&sdata=5MSLi36WDsEVlzgZxdUpPmUmFP0PIh0upgPgVsRmJnU%3D&reserved=0
> 
> we need to include licenses of all components shipped in an 
>artifact. The 
> example just appends all licenses to the LICENSE file including the 
> copyrights. Is the copyright required? Shouldn't the copyright be 
>appended 
> to the NOTICE file instead?
> 
> Also we found that some artifacts have contradicting or missing 
>licenses 
> e.g. in the pom of one artifact a BSD clause 2 license is mentioned 
>but no 
> LICENSE files are shipped in the jars, however the source contains a 
>BSD 
> clause 3 license.
> 
> Thanks,
> Jonas
> 
> 
> -
> To unsubscribe, e-mail: general

Re: [VOTE] Graduate Apache Griffin (incubating) as a TLP

[Alex Lv]

+1

Alex Lv

From: 吴晟 Sheng Wu 
Sent: Thursday, November 1, 2018 16:52
To: general
Cc: dev
Subject: Re: [VOTE] Graduate Apache Griffin (incubating) as a TLP

+1 Be better.


--
Sheng Wu
Apache SkyWalking







-- Original --
From:  "ShaoFeng Shi";
Date:  Thu, Nov 1, 2018 04:48 PM
To:  "general";
Cc:  "dev";
Subject:  Re: [VOTE] Graduate Apache Griffin (incubating) as a TLP



+1 (non-binding)

Gook luck Griffin!

Eugene Liu  于2018年11月1日周四 下午3:57写道：

> It's time to graduate now!
>
> totally agree +1
> 
> From: jenny li 
> Sent: Thursday, November 1, 2018 3:53 PM
> To: d...@griffin.incubator.apache.org
> Cc: general@incubator.apache.org
> Subject: Re: [VOTE] Graduate Apache Griffin (incubating) as a TLP
>
> +1 Can‘t wait to see this great project Apache Griffin from the Incubator
> to Graduation.
>
> Best regards,
> Jenny
>
> On Thu, Nov 1, 2018 at 3:31 PM William Guo  wrote:
>
> > +dev
> >
> > -- Forwarded message -
> > From: William Guo 
> > Date: Thu, Nov 1, 2018 at 11:21 AM
> > Subject: [VOTE] Graduate Apache Griffin (incubating) as a TLP
> > To: 
> >
> >
> > Hi all,
> >
> > Given that we've got positive feedback on the DISCUSS
> > thread, after we had made some changes based on DISCUSS feedback.
> > I'd like to start an official VOTE thread now.
> >
> >
> > Please vote on the resolution pasted below to graduate
> > Apache Griffin from the incubator to the top level project.
> >
> > [ ] +1 Graduate Apache Griffin from the Incubator.
> > [ ] +0 Don't care.
> > [ ] -1 Don't graduate Apache Griffin from the Incubator because...
> >
> > This vote will be open for at least 72 hours.
> >
> >
> > Many thanks to our mentors and everyone else for their support,
> >
> > William Guo (on behalf of the Apache Griffin PPMC).
> >
> >
> > ## Resolution to create a TLP from graduating Incubator podling
> >
> > X. Establish the Apache Griffin 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 data quality solution for big data, including both streaming
> > and batch mode.
> >
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > (PMC), to be known as the "Apache Griffin Project", be and hereby is
> > established pursuant to Bylaws of the Foundation; and be it further
> >
> > RESOLVED, that the Apache Griffin Project be and hereby is
> > responsible for the creation and maintenance of software related to
> > a data quality solution for big data, including both streaming and batch
> > mode;
> > and be it further
> >
> > RESOLVED, that the office of "Vice President, Apache Griffin" 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
> > Griffin Project, and to have primary responsibility for management
> > of the projects within the scope of responsibility of the Apache
> > Griffin 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 Griffin Project:
> >
> > * Alex Lv 
> > * Deyi Yao 
> > * Eugene Liu 
> > * Grant Guo 
> > * He Wang 
> > * Henry Saputra 
> > * Jason Liao 
> > * John Liu 
> > * Juan Li 
> > * Liang Shao 
> > * Lionel Liu 
> > * Luciano Resende 
> > * Nick Sokolov 
> > * Shawn Sha 
> > * Vincent Zhao 
> > * William Guo 
> > * Yuqin Xuan 
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that William Guo be
> > appointed to the office of Vice President, Apache Griffin, 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 Griffin Project be and hereby is tasked
> > with the migration and rationalization of the Apache Incubator
> > Griffin podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache Incubator
> > Griffin podling encumbered upon the Apache Incubator PMC are
> > here after discharged.
> >
>


--
Best regards,

Shaofeng Shi 史少锋

Re: How to review so-called "binary releases"?

[Alex Harui]

Hi Greg,

I think the fact that LICENSE policy that Justin linked to applies to 
convenience binaries creates confusion about reviewing binaries.

My 2 cents,
-Alex

On 10/25/18, 6:39 PM, "Greg Stein"  wrote:

On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde  wrote:

> Jim, you’re re-iterating the premise of my question. In the context of my
> question, it doesn’t matter what these things are called. But we need to
> know how reviewers are to handle them.
>
> Since I asked the original question, I have found the following policy[1]:
>
> > COMPILED PACKAGES
> >
> > The Apache Software Foundation produces open source software. All
> > releases are in the form of the source materials needed to make
> > changes to the software being released.
> >
> > As a convenience to users that might not have the appropriate tools to
> > build a compiled version of the source, binary/bytecode packages MAY
> > be distributed alongside official Apache releases. In all such cases, 
the
> > binary/bytecode package MUST have the same version number as the
> > source release and MUST only add binary/bytecode files that are the
> > result of compiling that version of the source code release and its
> > dependencies.
>
> This policy clarifies what these things may contain. I still need
> clarification on what is the responsibility of a reviewer.


It has been repeated several times already. There is no such thing as
"reviewer" since these are not official releases. So they certainly
shouldn't be voted upon. They are just some binaries hanging out on our
server.

I propose:
>
> 1. Reviewers have no way to verify the contents of the binaries and
> therefore they have to trust that the release manager has built them
> according to the documented release process.
>

And this is exactly why they are unofficial.

-g

Re: How to review so-called "binary releases"?

[Alex Harui]

Julian,

Since binaries are provided as a convenience with no official standing, it 
doesn't matter if the "binaries" are "verified" or not.  They could contain a 
virus or other malware.  Users take the risks.

However, folks have used the policy you reference to come up with several 
checks such as:

1) Does the binary run (and pass tests)?
2) Is the list of files the same as the results of building the source package?
3) Do the LICENSE and NOTICE contain the required information from bundled 
binaries?
4) Do the JAR files contain the correct LICENSE and NOTICE files for the 
content of the JARs.

HTH,
-Alex

On 10/25/18, 10:25 AM, "Julian Hyde"  wrote:

Jim, you’re re-iterating the premise of my question. In the context of my 
question, it doesn’t matter what these things are called. But we need to know 
how reviewers are to handle them.

Since I asked the original question, I have found the following policy[1]:

> COMPILED PACKAGES
>
> The Apache Software Foundation produces open source software. All
> releases are in the form of the source materials needed to make
> changes to the software being released.
>
> As a convenience to users that might not have the appropriate tools to
> build a compiled version of the source, binary/bytecode packages MAY
> be distributed alongside official Apache releases. In all such cases, the
> binary/bytecode package MUST have the same version number as the
> source release and MUST only add binary/bytecode files that are the
> result of compiling that version of the source code release and its
> dependencies.

This policy clarifies what these things may contain. I still need 
clarification on what is the responsibility of a reviewer. I propose:

1. Reviewers have no way to verify the contents of the binaries and 
therefore they have to trust that the release manager has built them according 
to the documented release process.

2. Reviewers should check that the binaries contain LICENSE and NOTICE 
files compatible with that is believed to be in the binaries.

Julian

[1] 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23compiled-packages&data=02%7C01%7Caharui%40adobe.com%7C335f6f5bcaeb4f46779008d63a9ee1f6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636760851402047786&sdata=scRmJjXdyQCGA2ymR3H4M4dnx6OKuuF3tMnUv64Kf%2FQ%3D&reserved=0

> On Oct 25, 2018, at 4:48 AM, Jim Jagielski  wrote:
> 
> +1. That distinction is important. The ASF, and our projects, release 
source code.
> 
>> On Oct 25, 2018, at 6:39 AM, Greg Stein  wrote:
>> 
>> Those are "convenience binaries" ... not "binary releases".
>> 
>> On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende 
>> wrote:
>> 
>>> While I agree that binary artifacts are for convenience purposes, if one
>>> searches  our dist folder they will find lots of projects with binary
>>> releases.
>>> 
>>> When reviewing binary archives we need to make sure that the license 
file
>>> is updated with the shiped dependencies licenses appropriately and that
>>> they are all compatible with the Apache License (notice file might also
>>> need to be updated).
>>> 
>>> 
>>> On Thu, Oct 25, 2018 at 05:38 Greg Stein  wrote:
>>> 
>>>> On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde  wrote:
>>>>> ...
>>>> 
>>>>> As a reviewer, how am I to vote on this release candidate?
>>>> 
>>>> 
>>>> You do NOT vote on binary artifacts. Since you cannot release binaries,
>>> you
>>>> should not put the Foundation's imprimatur on those artifacts (and as 
PMC
>>>> Member, that is what your vote represents).
>>>> 
>>>> 
>>>>> Should I vote -1 because the RC contains binaries?
>>>> 
>>>> 
>>>> Vote on the source artifacts only. Clarify that your vote does not 
apply
>>> to
>>>> the binaries.
>>>> 
>>>> Cheers,
>>>> -g
>>>> 
>>> --
>>> Sent from my Mobile device
>>> 
> 
> 
> -
> 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: [DISCUSS] Graduate Apache Griffin (incubating) as a TLP

[Alex Lv]

+1
Agree to graduate to TLP.

获取 Outlook for Android<https://aka.ms/ghei36>



发件人: William Guo
发送时间: 10月16日星期二 上午8:51
主题: [DISCUSS] Graduate Apache Griffin (incubating) as a TLP
收件人: general@incubator.apache.org
抄送: d...@griffin.incubator.apache.org, Henry Saputra, lrese...@apache.org, 
kasper...@apache.org, umamah...@apache.org


Hi all, After an enthusiastic discussion with the community: 
https://lists.apache.org/thread.html/ba389dd1f7a9e8c82912d4dbf06abceda5461429806f5f7b112fc05d@%3Cdev.griffin.apache.org%3E
 culminating with a positive vote: 
https://lists.apache.org/thread.html/df9c3a36d66c140b82ae655d49e6d3437564cb895724689ff266d954@%3Cdev.griffin.apache.org%3E
 
https://lists.apache.org/thread.html/3fdf92ae3510b6bca3ac25f51200c0b1e48a4ea1185945733259a7b7@%3Cdev.griffin.apache.org%3E
 We'd like to bring this to a discussing at the IPMC. Please see the proposed 
resolution below and let us know what do you think. A few stats to help with 
the discussion: Now we have the developer team[1,2] from eBay, VMWARE, NetEase, 
Pingan Bank, Huawei, Grid Dynamics, Paypal, Alipay, Yitu, JD, Ontario Institute 
for Cancer Research. 458 commits on development of the project. 437 PRs on the 
Github 31 contributors 206+ issues created 180+ issues resolved dev has 76 
subscribers 285 emails sent by 24 people, divided into 139 topics in last 
month.[3] Please check out Apache Maturity Model Assessment for Griffin[4] For 
more information. [1]http://griffin.incubator.apache.org/docs/community.html 
[2]http://griffin.incubator.apache.org/docs/contributors.html 
[3]https://lists.apache.org/trends.html?d...@griffin.apache.org:2018-9 [4] 
https://cwiki.apache.org/confluence/display/GRIFFIN/ASF+Maturity+Evaluation 
Thanks, William. Establish the Apache Griffin 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 data quality solution for 
big data, including both streaming and batch mode. It offers an unified process 
to measure data quality from different perspectives. NOW, THEREFORE, BE IT 
RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache 
Griffin Project", be and hereby is established pursuant to Bylaws of the 
Foundation; and be it further RESOLVED, that the Apache Griffin Project be and 
hereby is responsible for the creation and maintenance of software related to a 
data quality solution for big data, including both streaming and batch mode. It 
offers an unified process to measure data quality from different perspectives; 
and be it further RESOLVED, that the office of "Vice President, Apache Griffin" 
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 Griffin Project, 
and to have primary responsibility for management of the projects within the 
scope of responsibility of the Apache Griffin 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 Griffin Project: * Alex Lv * Deyi 
Yao * Eugene Liu * Grant Guo * He Wang * Henry Saputra * Jason Liao * John Liu 
* Juan Li * Liang Shao * Lionel Liu * Luciano Resende * Nick Sokolov * Shawn 
Sha * Vincent Zhao * William Guo * Yuqin Xuan NOW, THEREFORE, BE IT FURTHER 
RESOLVED, that William Guo be appointed to the office of Vice President, Apache 
Griffin, 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 initial Apache Griffin PMC be and hereby is 
tasked with the creation of a set of bylaws intended to encourage open 
development and increased participation in the Apache Griffin Project; and be 
it further RESOLVED, that the Apache Griffin Project be and hereby is tasked 
with the migration and rationalization of the Apache Incubator Griffin podling; 
and be it further RESOLVED, that all responsibilities pertaining to the Apache 
Incubator Griffin podling encumbered upon the Apache Incubator Project are 
hereafter discharged.

Re: Does Zipkin need to sign a SGA ?

[Alex Harui]

I may be mis-remembering, but I thought that an SGA wasn't required for ALv2 
code.  OpenZipkin appears to be ALv2.  The licenses in the SGA are pretty much 
the same as in ALv2.
I thought that for ALv2 code, we mostly cared that the community documented 
that it was willing to make the move from wherever the code is now to the ASF, 
and it wasn't super important to get approval from folks with minor 
contributions as long as we were confident their contributions were under ALv2.

Once the community has approved the move to the ASF, any copyright holder or an 
agent can replace the headers with the ASF header.

Of course, I could be wrong...
-Alex

On 9/18/18, 7:00 PM, "Adrian Cole"  wrote:

Hi, John

Thanks for the input. So, I would hazard a guess that Twitter folks
would like to help with this. I'm not sure who would want to hunt
through the management chain to find someone to reverse-own a decision
made 3 years ago, though! Regardless, on my part, I'll see if I can
find a champion inside Twitter to resurrect and SGA.

Best,
-A
On Wed, Sep 19, 2018 at 9:36 AM John D. Ament  wrote:
>
> Thanks Adrian.  Some comments/banter below.
>
> Migrating a repository from one org to another does not require an SGA.  
If
> it did, we would not be able to have code living in our repos that had
> headers other than the ASF standard headers (e.g. BSD licenses, or Apache
> License w/ different copyright statements).  The SGA is used to replace 
the
> headers with the standard ASF headers.  We should not block migrating the
> repositories over while the SGA/ICLA is worked out.
>
> Resolving the SGA/ICLA situation would block graduation - we should ensure
> that the provenance is in place, which is part of the incubation process.
> This doesn't need to be solved on day 1, but by the time the podling is
> ready to graduate.
>
> With that said, from a pure foundation standpoint it would be ideal to
> receive a SGA from Twitter.  Even if the current code doesn't match the
> code at the time of Twitter's conversion, it gives us a better IP history
> for the codebase to answer questions and deal with any potential problems
> that may come up along the way.  However, to be realistic I believe if we
> receive an ICLA from the primary contributors based on [1], that should
> satisfy enough providence of the codebase, in addition to the contribution
> process that Adrian has pointed out below.
>
> Thoughts?
>
> John
>
> [1]: 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenzipkin%2Fzipkin%2Fgraphs%2Fcontributors&data=02%7C01%7Caharui%40adobe.com%7Cb6688cfbd5c643fd589d08d61dd3a1dd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636729192122171615&sdata=uM8FYSSrTEoprQjlxBn7CaGMUUKN1q5kFIKZbwJK5OI%3D&reserved=0
>
> On Tue, Sep 18, 2018 at 9:25 PM Adrian Cole  
wrote:
>
> > There was a process involved at Twitter when we first moved it to the
> > openzipkin organization. It was 100% clear that this was an act for
> > the community to control the code.  Senior management were involved
> > 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fzipkin-user%2FfbOgEZpuQx4%2FbWH1-__EmCoJ&data=02%7C01%7Caharui%40adobe.com%7Cb6688cfbd5c643fd589d08d61dd3a1dd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636729192122171615&sdata=zCuH4RUT5mF8O8%2FuE1Q2LF7ug6XxieKzTY%2FixIPnupo%3D&reserved=0
> >
> > After that, all the repositories had contributing files like the below
> > indicating that all changes we to be redistributable under ASL
> >
> > 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenzipkine%2Fzipkin%2Fblob%2Fmaster%2F.github%2FCONTRIBUTING.md%23license&data=02%7C01%7Caharui%40adobe.com%7Cb6688cfbd5c643fd589d08d61dd3a1dd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636729192122171615&sdata=KUQH3PeI%2FQvQ2dzs1CYdGZVtSRCS0wOnJaPIYAvbMYs%3D&reserved=0
> > 
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenzipkin%2Fzipkin%2Fblob%2Fmaster%2F.github%2FCONTRIBUTING.md%23license&data=02%7C01%7Caharui%40adobe.com%7Cb6688cfbd5c643fd589d08d61dd3a1dd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636729192122171615&sdata=8%2Fx%2BpmxlUvivCroYblZxO7XmCoSlqH%2BLyYTaEeqD3GM%3D&reserved=0>
> >
> > There was no collection of contributor agreements beyond this. Most of
> > the code except save some UI assets have been completely rewritten
> > since the migration to OpenZipkin a few years back.
> >
> >

[jira] [Commented] (INCUBATOR-214) IP clearance for Apache Brooklyn UI from Angular

[Alex Heneveld (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16558138#comment-16558138
 ] 

Alex Heneveld commented on INCUBATOR-214:
-

Successful votes for IP clearance and accepting the contribution:
 * IP Clearance request:  
[http://mail-archives.apache.org/mod_mbox/incubator-general/201807.mbox/%3Ca22628a2-792a-2999-a29f-b617640a6c2f%40cloudsoft.io%3E]
 * IP Clearance result:  
[http://mail-archives.apache.org/mod_mbox/incubator-general/201807.mbox/%3Cd741cebf-8d92-27f2-3ede-9851be49810f%40cloudsoft.io%3E]
 * Brooklyn PMC acceptance vote:  
[http://mail-archives.apache.org/mod_mbox/brooklyn-dev/201807.mbox/%3C5dc7ad59-795e-fa7a-af32-918848229b32%40CloudsoftCorp.com%3E]

 

Closing this issue as accepted.

 

> IP clearance for Apache Brooklyn UI from Angular
> 
>
> Key: INCUBATOR-214
> URL: https://issues.apache.org/jira/browse/INCUBATOR-214
> Project: Incubator
>  Issue Type: Task
>Reporter: Alex Heneveld
>Priority: Major
> Attachments: brooklyn-ui-angular.tgz
>
>
> Cloudsoft are contributing to the Apache Brooklyn project a new UI written in 
> Angular.
> The clearance tasks are in progress and recorded at:  
> [http://incubator.apache.org/ip-clearance/brooklyn-ui-angular.html] .
> The HTML does not update immediately, so for very recent changes please see:  
> http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/brooklyn-ui-angular.xml?view=markup
> This issue is partly to track that and primarily to provide an official 
> record of the code drop contribution.  The contributed code is attached to 
> this issue as `brooklyn-ui-angular.tgz`.
> The checksum is as follows:
> {{% md5 brooklyn-ui-angular.tgz}}
>  {{MD5 (brooklyn-ui-angular.tgz) = 56a3a76768339ba25b89b35b20a3047f}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (INCUBATOR-214) IP clearance for Apache Brooklyn UI from Angular

[Alex Heneveld (JIRA)]

 [ 
https://issues.apache.org/jira/browse/INCUBATOR-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Heneveld resolved INCUBATOR-214.
-
Resolution: Fixed

> IP clearance for Apache Brooklyn UI from Angular
> 
>
> Key: INCUBATOR-214
> URL: https://issues.apache.org/jira/browse/INCUBATOR-214
> Project: Incubator
>  Issue Type: Task
>    Reporter: Alex Heneveld
>Priority: Major
> Attachments: brooklyn-ui-angular.tgz
>
>
> Cloudsoft are contributing to the Apache Brooklyn project a new UI written in 
> Angular.
> The clearance tasks are in progress and recorded at:  
> [http://incubator.apache.org/ip-clearance/brooklyn-ui-angular.html] .
> The HTML does not update immediately, so for very recent changes please see:  
> http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/brooklyn-ui-angular.xml?view=markup
> This issue is partly to track that and primarily to provide an official 
> record of the code drop contribution.  The contributed code is attached to 
> this issue as `brooklyn-ui-angular.tgz`.
> The checksum is as follows:
> {{% md5 brooklyn-ui-angular.tgz}}
>  {{MD5 (brooklyn-ui-angular.tgz) = 56a3a76768339ba25b89b35b20a3047f}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[RESULT] [IP-CLEARANCE] "brooklyn-ui-angular" contribution of new UI to Apache Brooklyn

[Alex Heneveld]

Hi Incubator PMC,

With 72h elapsed and no -1's I understand this to have passed. This 
thread is now closed.2


I will update the forn [3] and we will continue the process in the 
Brooklyn PMC.


Best
Alex


On 23/07/2018 09:56, Alex Heneveld wrote:


Hi Incubator PMC,

// cc dev@brooklyn

The top-level Apache Brooklyn project has been donated code for a new 
UI, being referred to as "brooklyn-ui-angular".


This is the formal request for IP clearance to be checked as per [1]. 
The donated code can be found at [2] (*), along with links to the 
completed (but for vote email records) XML and HTML clearance records 
[3] detailing the grant form and other compliance requirements.


Thanks in advance,
Alex


[1] 
https://incubator.apache.org/ip-clearance/ip-clearance-template.html#form-filling

[2] https://issues.apache.org/jira/browse/INCUBATOR-214
[3] 
http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/brooklyn-ui-angular.xml?view=markup


(*) The "incubator drop area (/repos/asf/incubator/donations)" 
referred to in step 5 of the instructions at [1] does not exist (svn: 
E17 -- URL doesn't exist), and I saw a few issues where it had 
been attached to a Jira issue, so that's what I've done.  If there is 
a better method please accept my apologies and advise.

[IP-CLEARANCE] "brooklyn-ui-angular" contribution of new UI to Apache Brooklyn

[Alex Heneveld]

Hi Incubator PMC,

// cc dev@brooklyn

The top-level Apache Brooklyn project has been donated code for a new 
UI, being referred to as "brooklyn-ui-angular".


This is the formal request for IP clearance to be checked as per [1]. 
The donated code can be found at [2] (*), along with links to the 
completed (but for vote email records) XML and HTML clearance records 
[3] detailing the grant form and other compliance requirements.


Thanks in advance,
Alex


[1] 
https://incubator.apache.org/ip-clearance/ip-clearance-template.html#form-filling

[2]  https://issues.apache.org/jira/browse/INCUBATOR-214
[3] 
http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/brooklyn-ui-angular.xml?view=markup


(*) The "incubator drop area (/repos/asf/incubator/donations)" referred 
to in step 5 of the instructions at [1] does not exist (svn: E17 -- 
URL doesn't exist), and I saw a few issues where it had been attached to 
a Jira issue, so that's what I've done.  If there is a better method 
please accept my apologies and advise.

[jira] [Updated] (INCUBATOR-214) IP clearance for Apache Brooklyn UI from Angular

[Alex Heneveld (JIRA)]

 [ 
https://issues.apache.org/jira/browse/INCUBATOR-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Heneveld updated INCUBATOR-214:

Description: 
Cloudsoft are contributing to the Apache Brooklyn project a new UI written in 
Angular.

The clearance tasks are in progress and recorded at:  
[http://incubator.apache.org/ip-clearance/brooklyn-ui-angular.html] .

The HTML does not update immediately, so for very recent changes please see:  
http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/brooklyn-ui-angular.xml?view=markup

This issue is partly to track that and primarily to provide an official record 
of the code drop contribution.  The contributed code is attached to this issue 
as `brooklyn-ui-angular.tgz`.

The checksum is as follows:

{{% md5 brooklyn-ui-angular.tgz}}
 {{MD5 (brooklyn-ui-angular.tgz) = 56a3a76768339ba25b89b35b20a3047f}}

 

  was:
Cloudsoft are contributing to the Apache Brooklyn project a new UI written in 
Angular.

The clearance tasks are in progress and recorded at 
[http://incubator.apache.org/ip-clearance/brooklyn-ui-angular.html] .

This issue is partly to track that and primarily to provide an official record 
of the code drop contribution.  The contributed code is attached to this issue 
as `brooklyn-ui-angular.tgz`.

The checksum is as follows:

{{% md5 brooklyn-ui-angular.tgz 
MD5 (brooklyn-ui-angular.tgz) = 56a3a76768339ba25b89b35b20a3047f}}

 


> IP clearance for Apache Brooklyn UI from Angular
> 
>
> Key: INCUBATOR-214
> URL: https://issues.apache.org/jira/browse/INCUBATOR-214
> Project: Incubator
>  Issue Type: Task
>    Reporter: Alex Heneveld
>Priority: Major
> Attachments: brooklyn-ui-angular.tgz
>
>
> Cloudsoft are contributing to the Apache Brooklyn project a new UI written in 
> Angular.
> The clearance tasks are in progress and recorded at:  
> [http://incubator.apache.org/ip-clearance/brooklyn-ui-angular.html] .
> The HTML does not update immediately, so for very recent changes please see:  
> http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/brooklyn-ui-angular.xml?view=markup
> This issue is partly to track that and primarily to provide an official 
> record of the code drop contribution.  The contributed code is attached to 
> this issue as `brooklyn-ui-angular.tgz`.
> The checksum is as follows:
> {{% md5 brooklyn-ui-angular.tgz}}
>  {{MD5 (brooklyn-ui-angular.tgz) = 56a3a76768339ba25b89b35b20a3047f}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (INCUBATOR-214) IP clearance for Apache Brooklyn UI from Angular

[Alex Heneveld (JIRA)]

Alex Heneveld created INCUBATOR-214:
---

 Summary: IP clearance for Apache Brooklyn UI from Angular
 Key: INCUBATOR-214
 URL: https://issues.apache.org/jira/browse/INCUBATOR-214
 Project: Incubator
  Issue Type: Task
Reporter: Alex Heneveld
 Attachments: brooklyn-ui-angular.tgz

Cloudsoft are contributing to the Apache Brooklyn project a new UI written in 
Angular.

The clearance tasks are in progress and recorded at 
[http://incubator.apache.org/ip-clearance/brooklyn-ui-angular.html] .

This issue is partly to track that and primarily to provide an official record 
of the code drop contribution.  The contributed code is attached to this issue 
as `brooklyn-ui-angular.tgz`.

The checksum is as follows:

{{% md5 brooklyn-ui-angular.tgz 
MD5 (brooklyn-ui-angular.tgz) = 56a3a76768339ba25b89b35b20a3047f}}

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Who has the experiences to assemble NOTICE file?

[Alex Harui]

Writing code is error prone too.  Just like code, make a good effort, let
the code reviewers catch things, make more changes, review it again.

The key thing is to do the work and get the reviews in a timely fashion
instead of at release vote time.  No big deal if you miss something.
That's why there are reviewers and at least 2 other people have to ok it.

My 2 cents,
-Alex

On 3/30/18, 7:29 AM, "Ying Chun Guo"  wrote:

>Hi, friends
>
>I'd like to learn from people who has the experience to assemble the
>legal NOTICE file before. I need to do this for Apache OpenWhisk repos. I
>find manually assembling NOTICE is a complex and error-prone task
>especially for a non-legal person like me. Is there a tool to help on
>that ? Does anyone share any experiences on that?
>
>Best regards
>Ying Chun Guo (Daisy)
>
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

[ANNOUNCE] Apache Livy 0.5.0-incubating released

[Alex Bozarth]

The Apache Livy team is proud to announce the release of Apache Livy
0.5.0-incubating

Livy is web service that exposes a REST interface for managing long running
Apache Spark contexts in your cluster.
With Livy, new applications can be built on top of Apache Spark that
require fine grained interaction with many Spark contexts.

Download Apache Livy 0.5.0-incubating:
http://livy.incubator.apache.org/download/

Release Notes:
http://livy.incubator.apache.org/history/

For more about Livy check our website:
http://livy.incubator.apache.org/

On behalf of your Apache Livy team,

   
 Alex Bozarth   
   
 Software Engineer  
   
 Spark Technology Center
   

   

 

 

 
 E-mail: ajboz...@us.ibm.com
 
 GitHub: github.com/ajbozarth   
 
   505 Howard 
Street 
 San Francisco, CA 
94105 
   United 
States 

 

[RESULTS] [VOTE] Release Apache Livy 0.5.0-incubating (RC2)

[Alex Bozarth]

This vote has passed with three +1 binding votes and no -1s or 0s.

+1 (binding):
Justin Mclean
Luciano Resende
Jean-Baptiste Onofré (carried over from the Livy dev vote)

Thank you to those that voted, I will follow up with the release and
announcement at the start of next week.

   
 Alex Bozarth   
   
 Software Engineer  
   
 Spark Technology Center
   

   

 

 

 
 E-mail: ajboz...@us.ibm.com
 
 GitHub: github.com/ajbozarth   
 
   505 Howard 
Street 
 San Francisco, CA 
94105 
   United 
States 

 








From:   "Alex Bozarth" 
To: general@incubator.apache.org
Cc: d...@livy.incubator.apache.org
Date:   01/29/2018 08:56 PM
Subject:[VOTE] Release Apache Livy 0.5.0-incubating (RC2)





The Apache Livy community has voted on and approved a proposal to release
Apache Livy 0.5.0-incubating (RC2). We would like to request that the
Incubator PMC members review and vote on this incubator release candidate.

Apache Livy (incubating) is web service that exposes a REST interface for
managing long running Apache Spark contexts in your cluster. With Livy, new
applications can be built on top of Apache Spark that require fine grained
interaction with many Spark contexts.


The livy dev voting thread can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_dev-40livy.incubator.apache.org_msg00297.html&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo&m=KMyzqbWH-_wvXigmaGS87yHcYzpZNbJiY8bTu_mzt88&s=A4Zj9gq_lY03yGNaX1_vdv2qhHnUGV4L977gCZNZ9SI&e=


And the results here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_dev-40livy.incubator.apache.org_msg00308.html&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo&m=KMyzqbWH-_wvXigmaGS87yHcYzpZNbJiY8bTu_mzt88&s=bkZOidHCkYJLm_b8zKiBTgmrMwPVokBfx1RwY81U4po&e=


Git tag: v0.5.0-incubating-rc2
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dlivy_tree_v0.5.0-2Dincubating-2Drc2&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo&m=KMyzqbWH-_wvXigmaGS87yHcYzpZNbJiY8bTu_mzt88&s=O_kxYpiepl0wVaKyaz8eCsYl-MH4tUR33TVpv3FPjuY&e=


All distribution packages, including signatures, digests, etc. can be found
at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__dist.apache.org_repos_dist_dev_incubator_livy_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo&m=KMyzqbWH-_wvXigmaGS87yHcYzpZNbJiY8bTu_mzt88&s=p94R0sDvo-3IQsQ7K6hCpkyQw-7I-jDjFkBnnzT2O7o&e=


Staging artifacts can be found at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__repository.apache.org_content_repositories_orgapachelivy-2D1005_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo&m=KMyzqbWH-_wvXigmaGS87yHcYzpZNbJiY8bTu_mzt88&s=io8fHD48IMg_fp25H7oJMG29WbUK012gQ-U9F5oB-bQ&e=



The vote is open for at least 72 hours and passes if a majority of at least
3 +1 PMC votes are cast.

 [ ] +1 Release this package as Apache Livy 0.5.0-incubating

 [ ] -1 Do not release this package because ...


Thank you on behalf of the Apache Livy community,

 Alex Bozarth

 Software Engineer

 Spark Technology Center





 E-mail: ajboz...@us.ibm.com

 GitHub: github.com/ajbozarth

   505
Howard Street
 San Francisco,
CA 94105

United States

Need write access to the wiki

[Alex Bozarth]

For those it applies,

I am preparing Livy's PMC report for February 2018 and need write access
for the Incubator wiki to include my update. Is there an admin willing to
grant me access?

Thank you,

   
 Alex Bozarth   
   
 Software Engineer  
   
 Spark Technology Center
   

   

 

 

 
 E-mail: ajboz...@us.ibm.com
 
 GitHub: github.com/ajbozarth   
 
   505 Howard 
Street 
 San Francisco, CA 
94105 
   United 
States 

 

[VOTE] Release Apache Livy 0.5.0-incubating (RC2)

[Alex Bozarth]

The Apache Livy community has voted on and approved a proposal to release
Apache Livy 0.5.0-incubating (RC2). We would like to request that the
Incubator PMC members review and vote on this incubator release candidate.

Apache Livy (incubating) is web service that exposes a REST interface for
managing long running Apache Spark contexts in your cluster. With Livy, new
applications can be built on top of Apache Spark that require fine grained
interaction with many Spark contexts.


The livy dev voting thread can be found here:
https://www.mail-archive.com/dev@livy.incubator.apache.org/msg00297.html

And the results here:
https://www.mail-archive.com/dev@livy.incubator.apache.org/msg00308.html

Git tag: v0.5.0-incubating-rc2
https://github.com/apache/incubator-livy/tree/v0.5.0-incubating-rc2

All distribution packages, including signatures, digests, etc. can be found
at:
https://dist.apache.org/repos/dist/dev/incubator/livy/

Staging artifacts can be found at:
https://repository.apache.org/content/repositories/orgapachelivy-1005/


The vote is open for at least 72 hours and passes if a majority of at least
3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Livy 0.5.0-incubating

[ ] -1 Do not release this package because ...


Thank you on behalf of the Apache Livy community,

   
 Alex Bozarth   
   
 Software Engineer  
   
 Spark Technology Center
   

   

 

 

 
 E-mail: ajboz...@us.ibm.com
 
 GitHub: github.com/ajbozarth   
 
   505 Howard 
Street 
 San Francisco, CA 
94105 
   United 
States 

 

Re: License headers on test data (was Re: [VOTE] Release Apache NetBeans 9.0 Beta (incubating) rc2)

[Alex Harui]

FWIW,  some build and test processes have a "generate-sources" and/or
"generate-test-sources" step.  Have you considered having a step in your
test processes copy the source test files into a temporary folder and
remove the headers as part of that step?   Then you may not need to change
the test harness and expected result set.

HTH,
-Alex

On 1/23/18, 5:46 AM, "Geertjan Wielenga"
 wrote:

>OK, makes sense, thanks for these insights and ideas.
>
>Gj
>
>On Tue, Jan 23, 2018 at 2:40 PM, Bertrand Delacretaz
> wrote:
>> Hi,
>>
>> On Tue, Jan 23, 2018 at 2:35 PM, Geertjan Wielenga
>>  wrote:
>>
>>>...
>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
>>>com%2Fapache%2Fincubator-netbeans%2Fblob%2Fmaster%2Fnbbuild%2Fbuild.xml&
>>>data=02%7C01%7Caharui%40adobe.com%7C0a91dd1e925e467c4bed08d56267bfbc%7Cf
>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636523120091967780&sdata=flP%2
>>>BmQUSLXLED3puYUrZzALhDD3adb%2F%2BSkgekR07mOQ%3D&reserved=0
>>> This is what line 2105 says:
>>>   ...
>>
>> Maybe grouping those exclusions by families would make it easier for
>> reviewers to understand them: first the ones which are not creative,
>> then those where a header would cause tests to fail etc.
>>
>>> ...You're saying the comment isn't needed in the README...
>>
>> What I'm saying is that it shouldn't be duplicated - have the README
>> point to that build.xml file,or as discussed a file that just has RAT
>> exclusions, and add the comments next to the exclusions, pointing to
>> apache.org docs where useful.
>>
>>> ...can NETBEANS-306 be closed as resolved?...
>>
>> I suggest grouping the exclusions that fall in that family and adding
>> a pointer to the Apache docs that mention that the header is not
>> required if it causes tests to fail.
>>
>> You then get links from README -> commented RAT exclusions -> Apache
>> documentation which provide a clear justification.
>>
>> -Bertrand
>>
>> -
>> 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 of Apache-Griffin-0.1.6-incubating [RC2]

[Lv Alex]

+1


Regards,

Alex


From: umaganguma...@gmail.com  on behalf of Uma 
gangumalla 
Sent: Thursday, November 16, 2017 7:38
To: d...@griffin.incubator.apache.org
Cc: general@incubator.apache.org
Subject: Re: [Vote] Release of Apache-Griffin-0.1.6-incubating [RC2]

forwarding my +1 from dev list

+1 (binding)

Regards,
Uma

On Tue, Nov 14, 2017 at 4:53 PM, William Guo  wrote:

> Hi all,
> The Apache Griffin community has voted on and approved a proposal to
> release Apache Griffin 0.1.6-rc2.
> We now kindly request that the Incubator PMC members review and vote
> on this incubator release candidate.
>
> Apache Griffin is data quality service for modern data system, it
> defines a standard process to define, measure data quality for well-known
> dimensions. With Apache Griffin, users will be able to quickly define their
> data quality requirements and then get the result in near real time in
> systematical approach.
>
>
> Griffin vote thread
> https://lists.apache.org/thread.html/c538bf4293d410bfdb574f605b6da9
> e508f3ef9dc64127e1945888e9@%3Cdev.griffin.apache.org%3E
> Griffin vote result thread
> https://lists.apache.org/thread.html/769d1c7ad3da35cc02cca960763965
> 48d199126f6e9d6da33ecaf581@%3Cdev.griffin.apache.org%3E
>
> The source tarball, including signatures, digests, etc. can be found
> at:
> https://dist.apache.org/repos/dist/dev/incubator/griffin/0.
> 1.6-incubating
>
> The tag to be voted upon is 0.1.6-incubating:
> https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.
> git;a=shortlog;h=refs/tags/0.1.6-incubating
>
> The release hash is :
> https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.
> git;a=commit;h=60e23edc96656f7382b74956bfb057e3eee9dda6
>
> The Nexus Staging URL:
> https://repository.apache.org/content/repositories/
> orgapachegriffin-1009
>
> Release artifacts are signed with the following key:
> 753AD8D8DF507D7232A9BDBD9B403B9B1BFBCC23
>
> KEYS file available:
> https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS
>
> For information about the contents of this release, see:
> https://dist.apache.org/repos/dist/dev/incubator/griffin/0.
> 1.6-incubating/CHANGES.txt
>
>
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, run and test.
> Please vote on releasing this package as Apache Griffin
> 0.1.6-incubating
> The vote will be open for 72 hours.
> [ ] +1 Release this package as Apache Griffin 0.1.6-incubating
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>
>
> Thanks,
> William
> on behalf of Apache Griffin PPMC
>
>

Re: [VOTE] Do not accept software grants with conditionals or exclusions

[Alex Harui]

I don't have a vote here, but I"m now confused about what problem is being
solved.  Is it, as Stian says, that an entity is being lazy and did not
attempt to review the contents of the grant before donating?  I thought
the goal is to just keep folks from bothering us with additional language
on these grants.

I would think it is still required of the receiving project to review the
contents assuming the donor made a good faith attempt to review the
contents as well.  But as I think Stian is saying (and I'm saying since I
experienced it), mistakes are going to happen and things that shouldn't
have been donated will be accidentally listed in exhibit A.  Do our legal
advisors think that some conditional or exclusion for accidents is built
into the grant wording already or should some language about that be added
to software-grant.txt ?

What is the protocol if, even after IP clearance/grant acceptance, that
something is found in the included files that shouldn't be in there?  I
assume Apache takes the friendly approach of "Oops, that probably
shouldn't have been in there" and just deletes that file?

Thanks,
-Alex

On 9/7/17, 2:51 AM, "Stian Soiland-Reyes"  wrote:

>+1
>
>
>However it should be OK (and perhaps even encouraged) for the archive
>to list in NOTICE or similar that some of the files are not legally
>owned by the donating entity, for instance other open source files
>that have been used – legally they can’t be part of the IP grant
>(unless the donating entity have gained shared copyright after further
>modifications - but their upstream license would still apply).
>
>
>This does not mean the donated archive has to be fully IP cleared
>before donation.. of course the opposite could be true – the grant
>donates some code, which the podling later chooses not to keep – for
>instance by discovering an LGPL-licensed file from outside.
>
>
>What is not OK is as you suggest, to include files which ARE owned by
>the donating entity, but which are somehow not included in the grant.
>
>
>On 7 September 2017 at 09:32, Ted Dunning  wrote:
>> +1
>>
>>
>> On Sep 7, 2017 10:11, "Jacques Le Roux" 
>> wrote:
>>
>>> +1 (not binding, not part of IPMC)
>>>
>>> Jacques
>>>
>>>
>>> Le 07/09/2017 à 10:07, Bertrand Delacretaz a écrit :
>>>
>>>> Hi Incubator PMC.
>>>>
>>>> We recently received a software grant pointing to an archive file for
>>>> the code donation, but mentioning that some material contained in that
>>>> archive might not be donated.
>>>>
>>>> This was discussed on the PMC private list and it looks like we have
>>>> consensus for rejecting such grants in the future: software donations
>>>> should only include the files that are donated, without conditionals
>>>> or exclusions. Anything else puts an unnecessary burden on our
>>>> podlings and mentors, for sorting out what's donated or not.
>>>>
>>>> This is a vote to formalize the decision to reject such grants in the
>>>> future.
>>>>
>>>> This majority vote is open for at least 72 hours.
>>>>
>>>> Here's my +1.
>>>>
>>>> -Bertrand
>>>>
>>>> -
>>>> 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
>>>
>>>
>
>
>
>-- 
>Stian Soiland-Reyes
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Forcid.org%
>2F-0001-9842-9718&data=02%7C01%7C%7C4ccc95b5bed04f674d6c08d4f5d61513%7
>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636403747211522975&sdata=RAK%2
>FkockH7FRLShyGRSaXCQuTDyDEXgXUrjfsC9xS8w%3D&reserved=0
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: Urgent: Regarding Java package name change to org.apache.*

[Alex Harui]

OK, so to summarize a more refined recommendation:

1) package names with reverse domains MUST be renamed before graduation or
have an IPMC approved plan for renaming
2) Projects who expect that their future users outnumber current users are
highly encouraged to rename packages
3) Other projects are not required to rename packages and backward
compatibility is sufficient reason to not rename packages.

Or should #2 also be a MUST?

-Alex

On 8/3/17, 8:34 AM, "Andy Seaborne"  wrote:

>
>
>On 03/08/17 15:51, Julian Hyde wrote:
>> It rarely comes down to the IPMC or the Board dictating how a project
>>names its java classes (does anyone recall an instance?), so it’s mainly
>>the project’s discretion. In my opinion, where the project is on its
>>adoption curve is an important consideration.
>
>+1
>
>> Most projects that enter the incubator are early on the adoption curve.
>>Their future users outnumber their current users. The earlier these
>>projects make the change to org.apache, the fewer people they will
>>ultimately impact. It seems that gobblin is in this category.
>> 
>> A few projects, such as Flex, are already near the top of their
>>adoption curve. The cost/benefit of renaming is not as compelling.
>
>Jena was not early on the adoption curve. Long term compatibility has
>been, and is, a major element of the project culture.  Importantly,
>there are active users who answer questions (here, elsewhere), external
>web tutorials, books etc referring to the pre-ASF API.  We have a
>responsibility to them as well.
>
>"add an API" is more stuff that a small set of volunteer contributors
>(Jena has had no paid contributors working on) could not have coped
>with.  If a project has the capacity, sure. Not all project will.
>
>Set the expectations too high and it is implicitly a filter for a
>certain kind of project in size and structure.
>
> Andy
>
>
>> 
>> Julian
>> 
>> 
>>> On Aug 3, 2017, at 7:37 AM, Alex Harui 
>>>wrote:
>>>
>>>  From the peanut gallery:
>>>
>>> Does the PPMC get to decide what constitutes a "very good reason" or
>>>does
>>> the IPMC and after graduation, the board?
>>>
>>> Flex has not changed its packages in the 5 years at Apache.  We felt
>>> backward compatibility was and is a "very good reason".  It was way
>>>more
>>> important to not require folks to alter their code in order to move to
>>>the
>>> Apache versions of Flex.  Also, we are not using Java/Maven so there
>>>isn't
>>> really a shading option.
>>>
>>> On the other hand, it seems like it could be confusing for Apache
>>>projects
>>> to have packages starting with "com.".  Flex's packages start with
>>>"mx" or
>>> "spark" (the component set names).
>>>
>>> Seems like a more refined guidance would be that:
>>> 1) packages starting with "com" (and maybe
>>>org.somethingOtherThanApache)
>>> should be changed as soon as possible/practical
>>> 2) there is no recommendation for other package prefixes
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 8/3/17, 5:42 AM, "Shane Curcuru" >><mailto:a...@shanecurcuru.org>> wrote:
>>>
>>>> John D. Ament wrote on 8/2/17 9:13 PM:
>>>>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik
>>>>>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
>>>>>> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> In regards to the recently incubated project - Gobblin, we were
>>>>>>> wondering
>>>>>>> about the policy around renaming Java package names to
>>>>>>>org.apache.* Is
>>>>>> it a
>>>>>>> mandatory requirement or good to have?
>>>>>>>
>>>>>>> The reason to ask this is that while we see many projects have
>>>>>>> migrated
>>>>>> to
>>>>>>> use org.apache.* package name for their Java source files, the
>>>>>>>Kafka
>>>>>>> project uses kafka.* for Scala sources and org.apache.kafka.* for
>>>>>>>Java
>>>>>>> sources.
>>>>>>>
>>>>>>> Please let us know as soon as possible, because we are in process
>>>>>>>of

Re: Urgent: Regarding Java package name change to org.apache.*

[Alex Harui]

From the peanut gallery:

Does the PPMC get to decide what constitutes a "very good reason" or does
the IPMC and after graduation, the board?

Flex has not changed its packages in the 5 years at Apache.  We felt
backward compatibility was and is a "very good reason".  It was way more
important to not require folks to alter their code in order to move to the
Apache versions of Flex.  Also, we are not using Java/Maven so there isn't
really a shading option.

On the other hand, it seems like it could be confusing for Apache projects
to have packages starting with "com.".  Flex's packages start with "mx" or
"spark" (the component set names).

Seems like a more refined guidance would be that:
1) packages starting with "com" (and maybe org.somethingOtherThanApache)
should be changed as soon as possible/practical
2) there is no recommendation for other package prefixes

My 2 cents,
-Alex

On 8/3/17, 5:42 AM, "Shane Curcuru"  wrote:

>John D. Ament wrote on 8/2/17 9:13 PM:
>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
>> wrote:
>> 
>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
>>>wrote:
>>>> Hi all,
>>>>
>>>> In regards to the recently incubated project - Gobblin, we were
>>>>wondering
>>>> about the policy around renaming Java package names to org.apache.* Is
>>> it a
>>>> mandatory requirement or good to have?
>>>>
>>>> The reason to ask this is that while we see many projects have
>>>>migrated
>>> to
>>>> use org.apache.* package name for their Java source files, the Kafka
>>>> project uses kafka.* for Scala sources and org.apache.kafka.* for Java
>>>> sources.
>>>>
>>>> Please let us know as soon as possible, because we are in process of
>>>> renaming the  packages but if not mandatory we would want to keep
>>> gobblin.*
>>>> package name and avoid the cost of downstream migrations and backwards
>>>> incompatibility.
>>>
>>> You don't have to do it right away, but it is a requirement unless you
>>> have a really,
>>> really, really good reason of why you can't do that.
>>>
>>>
>> I'm not aware of any requirement around Java package naming.  IN fact,
>>last
>> time it came up it was clear that its a best practice only, and doesn't
>> have any actual naming requirements.
>
>John: Do you have a link to that discussion?  I'm of the mind that it's
>an expected best practice, unless you have a really, really good reason
>otherwise.
>
>Abhishek: Can you describe in more detail what these packages do in the
>context of your software product?
>
>In general, yes, I'd echo Roman's point strongly for the primary
>external API that most users would call:
>
>>> Or to put it a different way: during your eventual graduation this
>>> question will be
>>> asked and you better have a really, really good explanation if you're
>>> still using
>>> something other than o.a.
>
>That is, supporting packages, or things that are standards, or things
>that are specific plugins that integrate with external code - those I
>could understand staying with a non-a.o package name for compatibility
>or other reasons.
>
>But the main program that users run in the JVM, or the primary Gobblin
>classes that users integrating the code into their application?  That
>should be in an org.apache.gobblin.* package.
>
>Simple "backwards compatibility for users" as an argument is only
>suitable if you're deprecating and have a plan to switch in the
>reasonably-near future after graduation.  Not for the long term.
>
>Thanks for raising the question early!
>
>>>
>>> Thanks,
>>> Roman.
>
>-- 
>
>- Shane
>  
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apach
>e.org%2Ffoundation%2Fmarks%2Fresources&data=02%7C01%7C%7Cef18c5e74b0141378
>79a08d4da6d0e5c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363736093056
>90124&sdata=OyrEoidSvoONvFJksGYjhhz%2FatAd4b%2FyjmHcfoGeI%2B0%3D&reserved=
>0
>
>-
>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 of Apache Griffin-0.1.5-incubating [rc3]

[Lv Alex]

copy +1 from dev list



Alex Lv


From: William Guo 
Sent: Thursday, July 13, 2017 7:55:36 AM
To: general@incubator.apache.org; d...@griffin.incubator.apache.org
Subject: [VOTE] Release of Apache Griffin-0.1.5-incubating [rc3]

Hi all,
The Apache Griffin community has voted on and approved a proposal to 
release Apache Griffin 0.1.5-rc3.
We now kindly request that the Incubator PMC members review and vote on 
this incubator release candidate.

Apache Griffin is data quality service for modern data system, it defines a 
standard process to define, measure data quality for well-known dimensions.
With Apache Griffin, users will be able to quickly define their data 
quality requirements and then get the result in near real time in systematical 
approach.


Griffin vote thread

https://lists.apache.org/thread.html/b8b2c5e9349fe30f3bcb80416303d37f576f5bcff37f73ebdcaba891@%3Cdev.griffin.apache.org%3E
Griffin vote result thread

https://lists.apache.org/thread.html/4a0a003624649225e148aee780a83013cf443cfdc3a91bde21151fc3@%3Cdev.griffin.apache.org%3E

The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.5-incubating

The tag to be voted upon is 0.1.5-incubating:

https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=shortlog;h=refs/tags/0.1.5-incubating

The release hash is :

https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=commit;h=fb3c197ff801127a21838969be5392d4ed67c878

The Nexus Staging URL:
https://repository.apache.org/content/repositories/orgapachegriffin-1006

Release artifacts are signed with the following key:
753AD8D8DF507D7232A9BDBD9B403B9B1BFBCC23

KEYS file available:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS

For information about the contents of this release, see:

https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.5-incubating/CHANGES.txt



Please vote on releasing this package as Apache Griffin 0.1.5-incubating

The vote will be open for 72 hours.
[ ] +1 Release this package as Apache Griffin 0.1.5-incubating
[ ] +0 no opinion
[ ] -1 Do not release this package because ...




Thanks,
William
on behalf of Apache Griffin PPMC

Re: [VOTE] Release of Apache Griffin-0.1.5-incubating [rc2]

[Lv Alex]

Copying my non-binding +1 from dev@griffin


validated signature

checked license

run mvn clean install successfully




Alex Lv


From: William Guo 
Sent: Thursday, July 6, 2017 9:09:30 AM
To: general@incubator.apache.org
Cc: jmcl...@apache.org; Henry Saputra; luke...@apache.org; efrie...@cisco.com; 
kasper...@apache.org; umamah...@apache.org; lrese...@apache.org
Subject: Re: [VOTE] Release of Apache Griffin-0.1.5-incubating [rc2]

Hi all,

This is a call for a vote on releasing Apache Griffin 0.1.5-incubating, 
release candidate 2. This is the first release of Griffin.

Apache Griffin is data quality service for modern data system, it defines a 
standard process to define, measure data quality for well-known dimensions. 
With Apache Griffin, users will be able to quickly define their data quality 
requirements and then get the result in near real time in systematical approach.


   Griffin vote thread


https://lists.apache.org/thread.html/bb6d39a0cffc1265df5dc1db00d22101ba85357242ce1efd5fedb854@%3Cdev.griffin.apache.org%3E


   Griffin vote result thread

https://lists.apache.org/thread.html/f7179ae14dd49bbbe23daf4e10b68b7a8662153d40ee03871febb1c4@%3Cdev.griffin.apache.org%3E

We have cleaned up bundled software for license issues.
https://github.com/apache/incubator-griffin/blob/master/LICENSE.md



The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.5-incubating



The tag to be voted upon is 0.1.5-incubating:

https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=shortlog;h=refs/tags/0.1.5-incubating



The release hash is 87f71017dc4bd925e309a540ca5783cf4c59dfff:

https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=commit;h=87f71017dc4bd925e309a540ca5783cf4c59dfff


The Nexus Staging URL:
https://repository.apache.org/content/repositories/orgapachegriffin-1005



Release artifacts are signed with the following key:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS


KEYS file available:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS



For information about the contents of this release, see:

https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.5-incubating/CHANGES.txt



Please vote on releasing this package as Apache Griffin 0.1.5-incubating

The vote will be open for 72 hours.

[ ] +1 Release this package as Apache Griffin ${RELEASE_VERSION}-incubating
[ ] +0 no opinion
[ ] -1 Do not release this package because ...

Thanks,
William


From: William Guo 
Sent: Thursday, July 6, 2017 8:46:25 AM
To: general@incubator.apache.org
Cc: jmcl...@apache.org; Henry Saputra; luke...@apache.org; efrie...@cisco.com; 
kasper...@apache.org; umamah...@apache.org; lrese...@apache.org
Subject: [VOTE] Release of Apache Griffin-0.1.5-incubating [rc2]

Hi all,

This is a call for a vote on releasing Apache Griffin 0.1.5-incubating, 
release candidate 2. This is the first release of Griffin.

Apache Griffin is data quality service for modern data system, it defines a 
standard process to define, measure data quality for well-known dimensions. 
With Apache Griffin, users will be able to quickly define their data quality 
requirements and then get the result in near real time in systematical approach.

We have cleaned up bundled software for license issues.
https://github.com/apache/incubator-griffin/blob/master/LICENSE.md



The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.5-incubating



The tag to be voted upon is 0.1.5-incubating:

https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=shortlog;h=refs/tags/0.1.5-incubating



The release hash is 87f71017dc4bd925e309a540ca5783cf4c59dfff:

https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=commit;h=87f71017dc4bd925e309a540ca5783cf4c59dfff


The Nexus Staging URL:
https://repository.apache.org/content/repositories/orgapachegriffin-1005



Release artifacts are signed with the following key:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS


KEYS file available:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS



For information about the contents of this release, see:

https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.5-incubating/CHANGES.txt



Please vote on releasing this package as Apache Griffin 0.1.5-incubating

The vote will be open for 72 hours.

[ ] +1 Release this package as Apache Griffin ${RELEASE_VERSION}-incubating
[ ] +0 no opinion
[ ] -1 Do not release this package because ...

Thanks,
William

Re: [VOTE] Release of Apache Griffin 0.1.4-incubating [rc2]

[Lv Alex]

+1


Alex Lv


From: William Guo 
Sent: Friday, June 23, 2017 10:21:24 AM
To: general@incubator.apache.org; d...@griffin.incubator.apache.org
Subject: [VOTE] Release of Apache Griffin 0.1.4-incubating [rc2]

Dear IPMC,

This is a call for a vote on releasing Apache Griffin 0.1.4-incubating, release 
candidate 2. This is the first release of Griffin.

Apache Griffin is data quality service for modern data system, it defines a 
standard process to define, measure data quality for well-known dimensions. 
With Apache Griffin, users will be able to quickly define their data quality 
requirements and then get the result in near real time in systematical approach.


PPMC vote threads:
https://lists.apache.org/thread.html/a298cdc88e7da94e88e3483342a8fc1e647061c9cc4c32aeb12f1ca9@%3Cdev.griffin.apache.org%3E
PPMC vote result threads:
https://lists.apache.org/thread.html/f94c56da6d2b3f777898443a349634e3c76c6c047b205de52cd6643c@%3Cdev.griffin.apache.org%3E


The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating

The tag to be voted upon is 0.1.4-incubating:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=shortlog;h=refs/tags/0.1.4-incubating

The release hash is f1ad4b7b6390b988f3625df3eba652a7fb59ad68:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=commit;h=f1ad4b7b6390b988f3625df3eba652a7fb59ad68

The Nexus Staging URL:
https://repository.apache.org/content/repositories/orgapachegriffin-1002

Release artifacts are signed with the following key:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS

KEYS file available:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS

For information about the contents of this release, see:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating/CHANGES.txt

Please vote on releasing this package as Apache Griffin 0.1.4-incubating

The vote will be open for 72 hours.

[ ] +1 Release this package as Apache Griffin 0.1.4-incubating
[ ] +0 no opinion
[ ] -1 Do not release this package because ...

Thanks,
Apache Griffin Team

Re: [VOTE] Release of Apache Griffin 0.1.4-incubating [rc2]

[Alex Lv]

+1


Alex Lv


From: William GUO  on behalf of William Guo 

Sent: Friday, June 23, 2017 11:01:34 AM
To: William Guo; general@incubator.apache.org; d...@griffin.incubator.apache.org
Subject: Re: [VOTE] Release of Apache Griffin 0.1.4-incubating [rc2]

update text as links, not sure why it was not links in email.

PPMC vote threads:
https://lists.apache.org/thread.html/a298cdc88e7da94e88e3483342a8fc1e647061c9cc4c32aeb12f1ca9@%3Cdev.griffin.apache.org%3E

PPMC vote result threads:
https://lists.apache.org/thread.html/f94c56da6d2b3f777898443a349634e3c76c6c047b205de52cd6643c@%3Cdev.griffin.apache.org%3E



The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating

The tag to be voted upon is 0.1.4-incubating:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=shortlog;h=refs/tags/0.1.4-incubating


The release hash is f1ad4b7b6390b988f3625df3eba652a7fb59ad68:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=commit;h=f1ad4b7b6390b988f3625df3eba652a7fb59ad68


The Nexus Staging URL:
https://repository.apache.org/content/repositories/orgapachegriffin-1002


Release artifacts are signed with the following key:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS


KEYS file available:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS


For information about the contents of this release, see:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating/CHANGES.txt


William


From: William Guo 
Sent: Friday, June 23, 2017 10:21:24 AM
To: general@incubator.apache.org; d...@griffin.incubator.apache.org
Subject: [VOTE] Release of Apache Griffin 0.1.4-incubating [rc2]


Dear IPMC,

This is a call for a vote on releasing Apache Griffin 0.1.4-incubating, release 
candidate 2. This is the first release of Griffin.

Apache Griffin is data quality service for modern data system, it defines a 
standard process to define, measure data quality for well-known dimensions. 
With Apache Griffin, users will be able to quickly define their data quality 
requirements and then get the result in near real time in systematical approach.


PPMC vote threads:
https://lists.apache.org/thread.html/a298cdc88e7da94e88e3483342a8fc1e647061c9cc4c32aeb12f1ca9@%3Cdev.griffin.apache.org%3E
PPMC vote result threads:
https://lists.apache.org/thread.html/f94c56da6d2b3f777898443a349634e3c76c6c047b205de52cd6643c@%3Cdev.griffin.apache.org%3E


The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating

The tag to be voted upon is 0.1.4-incubating:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=shortlog;h=refs/tags/0.1.4-incubating

The release hash is f1ad4b7b6390b988f3625df3eba652a7fb59ad68:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=commit;h=f1ad4b7b6390b988f3625df3eba652a7fb59ad68

The Nexus Staging URL:
https://repository.apache.org/content/repositories/orgapachegriffin-1002

Release artifacts are signed with the following key:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS

KEYS file available:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS

For information about the contents of this release, see:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating/CHANGES.txt

Please vote on releasing this package as Apache Griffin 0.1.4-incubating

The vote will be open for 72 hours.

[ ] +1 Release this package as Apache Griffin 0.1.4-incubating
[ ] +0 no opinion
[ ] -1 Do not release this package because ...

Thanks,
Apache Griffin Team

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Alex Harui]

Is the use of Google Analytics also prohibited by #4?

-Alex

On 6/5/17, 8:16 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
 wrote:

>On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  wrote:
>> Thanks for the explanation, Roman. I had no idea that policies for
>>hosted binaries
>> were stricter than for source code (other than the obvious effect on
>>licensing when you bundle in dependencies).
>
>Btw, this one is serious enough that I'd like us to update our release
>policy based on the
>learnings here.
>
>So far it seems that there's an agreement on that having this type of
>capability...
>   1 ... in the source code disabled by default -- totally OK
>   2 ... in the source code enabled by default -- questionable, but OK
>   3 ... in the binary hosted by ASF disabled by default -- OK
>   4 ... in the binary hosted by ASF enabled by default -- NOT OK
>
>#4 can get nuanced if we want to invest in ASF managed infrastructure
>that is
>responsible for update tracking and user data collection. With my ASF hat
>on,
>I'd say that INFRA should probably stay away from user data
>collection/retention.
>
>That still leaves a possibility of a a ping/pong API that only
>consumes a name of ASF
>project and its version and returns a JSON object of some kind as per
>PMC choice.
>
>
>Thanks,
>Roman.
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: [VOTE] Livy to enter Apache Incubator

[Alex Bozarth]

+1 (non-binding)

On 2017-05-31 17:27 (-0700), "Saisai sh...@gmail.com> wrote:
>  1 (non-binding)>
>
> ->
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org>
> For additional commands, e-mail: general-h...@incubator.apache.org>
>
>

    
   
 Alex Bozarth   
   
 Software Engineer  
   
 Spark Technology Center
   

   

 

 

 
 E-mail: ajboz...@us.ibm.com
 
 GitHub: github.com/ajbozarth   
 
   505 Howard 
Street 
 San Francisco, CA 
94105 
   United 
States 

 

Re: Airflow voting on release artifacts

[Alex Harui]

On 5/1/17, 2:00 PM, "Bolke de Bruin"  wrote:
>
>In Python we are used to install through so called source distributions
>“sdist”. Package managers (e.g. pip) use the filename to determine
>whether to download a new package and if they do they examine the
>contents of the package to find out it they need to install the package.
>They do this by examining the version contained inside the package. Thus
>while a different filename will trigger a new download, it might not
>install updated parts of the package. This is different from your example
>as no installer is examining both the name of the tar ball and the
>contents of your javascript files for a version identifier.
>
>But maybe you have a point. We could just do a "git clone”, update the
>version (not push it to git until final release), tar it. We then ask
>people to vote on it. Then we could provide the convenience package (that
>everyone will use) next to it. Or if we consider the “sdist” a binary
>release officially we vote on that one as well after the first vote. Two
>downsides to this are: if only option 1) nobody would user the tar, as
>the sdist is essentially the same and works with the package managers.
>Might be a bit excessive? 2) that would be a 2+2 vote again.
>
>Option 1 could work, it isn’t ideal, but will satisfy the procedure.

Many projects produce two packages: the actual sources, and something most
customers want to use.  The main reason ASF projects focus on the source
is because we are an "Open Source" foundation, but also because you can
verify that a source package isn't infected by a virus more easily than
reviewing other kinds of files.  AIUI, there are customers who are
concerned enough about the safety of a release that they only work with
source packages and compile everything from source.  So, whatever you call
your "source" package that is officially voted on must meet this criteria.

The customer package can be collection of files, but it must meet certain
requirements like having a LICENSE and NOTICE and detached signature that
the voters verify.

Many release examiners want to verify the source package against a Git
hash or SVN tag. That isn't a "must do", but a good thing if you can do
it.  So, I'm not sure delaying pushing the tag is a good idea.  What we do
in our project is pick whatever hash is the point in history for the
release and tag is as RC1, then when the vote passes, tag whatever hash
finally passes with the release tag.

So, if an sdist is entirely source, IMO, you can just make two sdist
packages (one for customers and one with "RC1" appended to the version
number) and offer both to the voters.  If the voters can easily validate
that the RC1 version they test is essentially the same as the other
package, then I think you are good to go.

HTH,
-Alex

Re: Airflow voting on release artifacts

[Alex Harui]

On 5/1/17, 11:44 AM, "Bolke de Bruin"  wrote:

>
>> On 1 May 2017, at 17:36, Alex Harui  wrote:
>> 
>> 
>> 
>> On 5/1/17, 7:44 AM, "Hitesh Shah"  wrote:
>> 
>>> Hi Justin,
>>> 
>>> Currently, the podling has been modifying the contents and hence this
>>> discussion.
>> 
>> I agree with Justin and others that modification after the vote is not a
>> good thing.  So my assumption was that if you add your 2a step and
>>modify
>> the binary before the vote, it will be acceptable.  IMO, all you need
>>is a
>> way to verify that the binary the voters test is essentially the same as
>> the binary you want to actually release.
>> 
>> -Alex
>> 
>> 
>
>Hi Alex,
>
>As mentioned earlier this is not possible in a clean way. Version
>information is contained within the source package and it is required by
>specification to be. Installation happens from this source package. There
>are no “binaries”.
>
>We understand the need to vote on the artefacts, however the way it is
>required to work put us between a rock and a hard place: either our users
>can end up with an outdated pre-release while reporting they have the
>release installed or we need to vote 2+2 times (PMC+IPMC).
>
>We are looking to optimize this process either technically or
>procedurally, but until so far haven’t been able to distill anything that
>really helps.

Well, I'm quite confused now.  Hitesh seems to say there are binaries.
And I have proposed a couple of ideas where you create different artifacts
for voters vs. customers that I think get around all of these issues.
AFAIK, nobody on this list has objected to those proposals.

Maybe there is something about Python I don't understand, but if I had to
ship a set of Javascript files with an embedded version number in one of
those files, I would use what I proposed.  AFAICT, there is no obligation
to make your customers (not your voters) consume the source package, it
just has to be possible to generate what the customers use from the source
package.

HTH,
-Alex

Re: Airflow voting on release artifacts

[Alex Harui]

On 5/1/17, 7:44 AM, "Hitesh Shah"  wrote:

>Hi Justin,
>
>Currently, the podling has been modifying the contents and hence this
>discussion.

I agree with Justin and others that modification after the vote is not a
good thing.  So my assumption was that if you add your 2a step and modify
the binary before the vote, it will be acceptable.  IMO, all you need is a
way to verify that the binary the voters test is essentially the same as
the binary you want to actually release.

-Alex