Re: [VOTE]Release Apache Liminal (incubating) 0.0.5rc2-INCUBATING

[Davor Bonaci]

+1 (binding)

On Mon, Jan 23, 2023 at 12:16 PM Lidor Ettinger 
 wrote:

> Hi All,
>
> We would like to vote on RC1 of version 0.0.5. The main purpose of V
> 0.0.5 is to provide a clear extensibility API for developers to add
> their own implementations of liminal abstractions - executor, task,
> image builder. In addition this version supports Apache Airflow 2.0.
>
> Liminal community vote and result threads:
> Vote:
> https://lists.apache.org//thread/yftpyhfzszmhbtfr6xjdyhfkpyocfy11
>
> Result:
> https://lists.apache.org//thread/9hsm5z4hygv4f0l059crp5bmp3hgg3m4
>
> Installation and testing instructions can be found in the README included.
>
> The release files, including signatures, digests, etc. can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/0.0.5rc2-INCUBATING/
>
>
> The tag to be voted on:
>
>
> https://github.com/apache/incubator-liminal/releases/tag/0.0.5rc2-INCUBATING
>
>
> The SHA512 Checksum for these artifacts is:
>
> apache-liminal-0.0.5rc1-incubating-source.tar.gz:
>
>
> 1937572ef1296d6f182ee855513b9884a290134d033afecaccb31c2208578d46395579192c37721d01e1807e3838915c96e55a8156e24871bf8aaf340e533500
>
>
> Release artifacts are signed with the following key:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/KEYS
>
>
> For more information about the contents of this release,
> see:https://issues.apache.org/jira/projects/LIMINAL/versions/12352738
>
>
> Please vote on releasing this package as Apache Liminal
> 0.0.5-INCUBATING. A majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Liminal 0.0.5
> [ ] +0 No opinion
> [ ] -1 Do not release this package because ...
>
> Regards,
> Lidor Ettinger
>

Re: [VOTE]Release Apache Liminal (incubating) 0.0.5rc1-incubating

[Davor Bonaci]

+1 (binding)

On Thu, Jan 12, 2023 at 12:41 AM Lidor Ettinger 
wrote:

> Hi All,
>
> We would like to vote on RC1 of version 0.0.5. The main purpose of V
> 0.0.5 is to provide a clear extensibility API for developers to add
> their own implementations of liminal abstractions - executor, task,
> image builder. In addition this version supports Apache Airflow 2.0.
>
> Liminal community vote and result threads:
> Vote:
> https://lists.apache.org//thread/rko6z3c2vxk4hrg201n72lxjhycjwkh4
>
> Result:
> https://lists.apache.org//thread/zqtj82nh3mm33k2ddfby7442d901h0qo
>
> Installation and testing instructions can be found in the README included.
>
> The release files, including signatures, digests, etc. can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/0.0.5rc1-incubating/
>
> The tag to be voted on:
>
>
> https://github.com/apache/incubator-liminal/releases/tag/0.0.5rc1-incubating
>
>
> The SHA512 Checksum for these artifacts is:
>
> apache-liminal-0.0.5rc1-incubating-source.tar.gz:
>
>
> bebd119326ffe455f6b8f4227e36af5452648e7ffefc6d864ee9ec0a050b71e7701dbe1b90354b5d164191a505a3f50191be41be8e474379755d1a36934e4516
>
>
> Release artifacts are signed with the following key:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/KEYS
>
> For more information about the contents of this release,
> see:https://issues.apache.org/jira/projects/LIMINAL/versions/12352738
>
> Please vote on releasing this package as Apache Liminal
> 0.0.5-INCUBATING. A majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Liminal 0.0.5
> [ ] +0 No opinion
> [ ] -1 Do not release this package because ...
>
> Regards,
> Lidor Ettinger
>

Re: [VOTE]Release Apache Liminal (incubating) 0.0.4rc2-incubating

[Davor Bonaci]

+1 (binding)

On Tue, Feb 15, 2022 at 8:21 AM Lior Schachter  wrote:

> Hi All,
>
> We would like to vote on RC2 of version 0.0.4. The main purpose of V 0.0.4 is 
> to provide a clear extensibility API for developers to add their own 
> implementations of liminal abstractions - executor, task, image builder. In 
> addition this version supports Apache Airflow 2.0.
>
> Liminal community vote and result threads:
> Vote:
> https://lists.apache.org/thread/1sw1zvyq45ozml09l7g2lhbdcd995lqw
>
> Result:
> https://lists.apache.org/thread/tcn3bmkc76hjx1f39p06xsq8jz9b2hgs
>
> Installation and testing instructions can be found in the README included.
>
> The release files, including signatures, digests, etc. can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/0.0.4rc2-INCUBATING/
>
> The tag to be voted on:
>
> https://github.com/apache/incubator-liminal/releases/tag/0.0.4rc2-incubating
>
> The SHA512 Checksum for these artifacts is:
>
> apache-liminal-0.0.4rc2-incubating-source.tar.gz:
> BEC25A76 9E5C12BD F262FF95 3AE3E26D 8F19294C 16E45605 49F027F1 6A31ECC5 
> 62BD7001 2E63D66B BEBBE319 D829FA04 B1051C1A DFC9A13D 6C861E62 5796B396
>
> Release artifacts are signed with the following key:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/KEYS
>
> For more information about the contents of this release, 
> see:https://issues.apache.org/jira/projects/LIMINAL/versions/12350079
>
> Please vote on releasing this package as Apache Liminal 0.0.4-INCUBATING. A 
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Liminal 0.0.4
> [ ] +0 No opinion
> [ ] -1 Do not release this package because ...
>
> Regards,
> Lior Schachter
>
>

Re: [VOTE]Release Apache Liminal (incubating) 0.0.3rc4-INCUBATING

[Davor Bonaci]

+1 (binding)

On Mon, Aug 9, 2021 at 7:17 AM Lior Schachter  wrote:

> We would like to have a re-vote on RC4 of version 0.0.3 - after fixing the 
> packaging of the tag and uploading it to SVN.
>
> This version introduces out-of-the-box functionality to author and execute ML 
> workflows (data fetching-feature engineering-training-inference) in the local 
> machine and in AWS using Airflow, Kubernetes and Spark.
>
> Liminal community vote and result threads:
> Vote:
> https://lists.apache.org/thread.html/rcdc714d4de15cb12e2387e8dc8fe2eac1497ed2af55e760bb42ecc64%40%3Cdev.liminal.apache.org%3E
>
> Result:
> https://lists.apache.org/thread.html/ra05372eed5c9ab5c3cf97c16ca93a33ffcc4b797cc341bf4ceaac079%40%3Cdev.liminal.apache.org%3E
>
> Installation and testing instructions can be found in the README included.
>
> The release files, including signatures, digests, etc. can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/0.0.3rc4-INCUBATING/
>
> The tag to be voted on:
>
> https://github.com/apache/incubator-liminal/releases/tag/0.0.3rc4-incubating
>
> The SHA512 Checksum for these artifacts is:
>
> apache-liminal-0.0.3rc4-incubating-source.tar.gz:
>
> 1BC663C2 6317E840 3292B7BE E2023011 EE0DBAD8 8D05A908 3D68534C 360F2125 
> B7981E90 082466C0 F16314E6 14434C60 584357C6 8E8207EB BA9FD21E E0AC110A
>
> Release artifacts are signed with the following key:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/KEYS
>
> For more information about the contents of this release, 
> see:https://issues.apache.org/jira/projects/LIMINAL/versions/12349981
>
>
> Please vote on releasing this package as Apache Liminal 0.0.3-INCUBATING:
>
> [ ] +1 Release this package as Apache Liminal 0.0.3-INCUBATING
> [ ] +0 No opinion
> [ ] -1 Do not release this package because ...
>
> Regards,
> Lior Schachter
>
>

Re: [VOTE] Release Apache Liminal (incubating) 0.0.3rc4-INCUBATING

[Davor Bonaci]

+1 (binding)

On Tue, Aug 3, 2021 at 11:40 PM Lior Schachter  wrote:

> Hi All,
>
> We would like to vote on RC4 of version 0.0.3.
>
> This version introduces out-of-the-box functionality to author and execute ML 
> workflows (data-fetching-feature-engineering-training-inference) in the local 
> machine and in AWS using Airflow, Kubernetes and Spark.
>
> Liminal community vote and result threads:
> Vote:
> https://lists.apache.org/thread.html/r8871d3685fb85ffd8f767642b393eb0418430e02f9a3d0e13f3e802b%40%3Cdev.liminal.apache.org%3E
>
> Result:
> https://lists.apache.org/thread.html/ra05372eed5c9ab5c3cf97c16ca93a33ffcc4b797cc341bf4ceaac079%40%3Cdev.liminal.apache.org%3E
>
> Installation and testing instructions can be found in the README included.
>
> The release files, including signatures, digests, etc. can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/0.0.3rc4-INCUBATING/
>
> The tag to be voted on:
>
> https://github.com/apache/incubator-liminal/releases/tag/0.0.3rc4-incubating
>
> The SHA512 Checksum for these artifacts is:
>
> ist/apache-liminal-0.0.3rc4-incubating.tar.gz:
> 237479C5 94E944C2 4CE800A4 4316C726 3C6503AD 35D21416 D1D375F1 29AFC6EA 
> 2AA37732 DBD9923F DEB9995C F0148457 F298CB40 633CC653 71A7A3A4 9209A0B5
>
> Release artifacts are signed with the following key:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/KEYS
>
> For more information about the contents of this release, 
> see:https://issues.apache.org/jira/projects/LIMINAL/versions/12349981
>
>
> Please vote on releasing this package as Apache Liminal 0.0.3-INCUBATING:
>
> [ ] +1 Release this package as Apache Liminal 0.0.3
> [ ] +0 No opinion
> [ ] -1 Do not release this package because ...
>
> Regards,
> Lior Schachter
>
>

Re: [VOTE] Release Apache Liminal (incubating) 0.0.2rc2-INCUBATING

[Davor Bonaci]

+1 (binding)

On Fri, Apr 23, 2021 at 7:04 AM Lior Schachter  wrote:

> Hi All,
>
> We would like to vote on RC2 of version 0.0.2. The main purpose of V 0.0.2 is 
> to fix issues found with AWS deployment. In RC2 we are addressing a licensing 
> issue - a LGPL transitive required dependency - chardet V 4.0.0 (LGPL V 2.1). 
> We added it to the DISCLAIMER-WIP file.
>
> Liminal community vote and result threads:
> Vote:
> https://lists.apache.org/thread.html/r338e01fd18d3f204c5bc9d6b5f1ccff3d10a3f28e8e474dee81870bc%40%3Cdev.liminal.apache.org%3E
>
> Result:
> https://lists.apache.org/thread.html/r82ab23b0b965533297239341143293ab806845ea5a1aea13a8c2aac6%40%3Cdev.liminal.apache.org%3E
>
> Installation and testing instructions can be found in the README included.
>
> The release files, including signatures, digests, etc. can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/0.0.2rc2-INCUBATING/
>
> The tag to be voted on:
>
> https://github.com/apache/incubator-liminal/releases/tag/0.0.2rc2-INCUBATING
>
> The SHA512 Checksum for these artifacts is:
>
> apache-liminal-0.0.2rc2-INCUBATING-source.tar.gz:
> 0F4158BA 25D9A7D3 135807AD 1B952442 9A00AF6F 496BD8FC 37ADD5A1 CA1F21F7 
> 4E69F5BA 580DFD5E 271B42AE 71FABA2C D320D0FA 1BFB819A 5F3C120E 47430127
>
> Release artifacts are signed with the following key:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/KEYS
>
> For more information about the contents of this release, 
> see:https://issues.apache.org/jira/projects/LIMINAL/versions/12349600
>
>
> Please vote on releasing this package as Apache Liminal (Incubating) 0.0.2:
>
> [ ] +1 Release this package as Apache Liminal 0.0.2
> [ ] +0 No opinion
> [ ] -1 Do not release this package because ...
>
> Regards,
> Lior Schachter
>
>

Re: [VOTE] Release Apache Liminal (incubating) 0.0.2rc1-INCUBATING

[Davor Bonaci]

+1 (binding)

On Mon, Apr 19, 2021 at 8:18 AM Lior Schachter  wrote:

> Hi All,
> We would like to initiate a vote on Apache Liminal (Incubating) V 0.0.2. The 
> main purpose of this version is to fix issues found with Liminal deployment 
> in AWS.
>
> Liminal community vote and result threads:
> Vote:
> https://lists.apache.org/thread.html/r3da51381394f5ef5c871402bd5216786935cc02211d277df84292d1b%40%3Cdev.liminal.apache.org%3E
>
> Result:
> https://lists.apache.org/thread.html/r7e2a515da16f32481056c9c5cfcf5c366c457436faa60234b7c231df%40%3Cdev.liminal.apache.org%3E
>
> Installation and testing instructions can be found in the README included.
>
> The release files, including signatures, digests, etc. can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/0.0.2rc1-INCUBATING/
>
> The tag to be voted on:
>
> https://github.com/apache/incubator-liminal/releases/tag/0.0.2rc1-INCUBATING
>
> The SHA512 Checksum for these artifacts is:
>
> apache-liminal-0.0.2rc1-INCUBATING-source.tar.gz:
> 61309CD0 EAF70454 A1480B8C 73D3B0B4 6949D947 97B0B261 2348B363 06051142 
> C414EA0B F55D5BBC 8894CE95 C91FC993 40074242 9FDF0B3D 61EC5526 863EB89D
>
> Release artifacts are signed with the following key:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/KEYS
>
> For more information about the contents of this release, 
> see:https://issues.apache.org/jira/projects/LIMINAL/versions/12349600
>
> Please vote on releasing this package as Apache Liminal (Incubating) 0.0.2.
>
> [ ] +1 Release this package as Apache Liminal 0.0.2
> [ ] +0 No opinion
> [ ] -1 Do not release this package because ...
>
>
> Regards,
> Lior Schachter
>
>

Re: [VOTE] Release Apache Liminal (incubating) 0.0.1rc6-INCUBATING

[Davor Bonaci]

+1 (binding)

Can we get another vote or two please to close the first release? I know
the Liminal community would appreciate it -- thanks so much!

On Sat, Feb 27, 2021 at 09:59 AM Juan Pan  wrote:

> Hi, +1(unbinding)
>
>
>
> [x] Download links are valid.
>
> [x] Checksums and PGP signatures are valid.
>
> [x] LICENSE, NOTICE and DISCLAIMER files are correct.
>
> [x] All files have license headers if necessary.
>
> [x] Source code building successfully.
>
>
>
>
>
>
>
> Good luck.
>
>
>
>
> Trista
>
>
>
>
>
>
> ---
> Email：panj...@apache.org
> Juan Pan(Trista) Apache ShardingSphere
>
>
> On 02/25/2021 23:52，Lior Schachter wrote：
> Hi All,
> We would like to have another round of vote for the first release of
> Apache Liminal (Incubating), after fixing the licensing issues found
> at the previous voting round.
>
> This release enables seamless Liminal installation in Local mode and
> in AWS cloud to execute machine-learning pipelines.
>
> Liminal community vote and result threads:
> Vote:
>
> https://lists.apache.org/thread.html/rdce94a657da705a454846b3fd9ff37b58c37245c3c588b2bb16cf70b%40%3Cdev.liminal.apache.org%3E
>
> Result:
>
> https://lists.apache.org/thread.html/r067f0351e693282ef5c2f2f511bdd388c86d8bf38feff9663e21135a%40%3Cdev.liminal.apache.org%3E
>
> Installation and testing instructions can be found in the README included.
>
> The release files, including signatures, digests, etc. can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/0.0.1rc6-INCUBATING/
>
> The tag to be voted on:
>
>
> https://github.com/apache/incubator-liminal/releases/tag/0.0.1rc6-INCUBATING
>
> The SHA512 Checksum for these artifacts is:
>
> apache-liminal-0.0.1rc6-INCUBATING-source.tar.gz:
>
> 3A0462B6 2F572AF0 DD860FD3 1D1845DA DFAF04C0 D4B43694 9044A1F5
> 8FFA07AB 21793233 6DA2392D 10AA1B70 9723E105 91F6E789 2EF7B523
> 422AF387 04FFE035
>
> Release artifacts are signed with the following key:
>
> https://dist.apache.org/repos/dist/dev/incubator/liminal/KEYS
>
> For more information about the contents of this release,
> see:https://issues.apache.org/jira/projects/LIMINAL/versions/12349599
>
> Please vote on releasing this package as Apache Liminal
> 0.0.1rc6-INCUBATING. A majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Liminal 0.0.1
> [ ] +0 No opinion
> [ ] -1 Do not release this package because ...
>
> Regards,
> Lior Schachter
>

Re: [MENTORS] IPMC Policy change work in progress disclaimer

[Davor Bonaci]

Great work Justin; this is a huge improvement for the podlings (and the
most significant policy update in years).

On Sat, Aug 3, 2019 at 6:09 AM Willem Jiang  wrote:

> +1.  I cannot agree more with that.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Aug 2, 2019 at 2:17 PM Paul King  wrote:
> >
> > Kudos for progressing this idea. I really like it. It should allow
> > improvements from the perspective of both podlings and reviewers.
> >
> > Cheers, Paul.
> >
> > On Fri, Aug 2, 2019 at 12:25 PM Justin Mclean 
> > wrote:
> >
> > > Hi,
> > >
> > > The work in progress progress disclaimer (DISCLAIMER-WIP) has been
> added
> > > to the IPMC policy page. [1]
> > >
> > > Podlings can now select which disclaimer they want to use. If they
> want to
> > > use the standard disclaimer then their releases must comply with all
> ASF
> > > policy. If they want the incubator to be more lenient in voting on
> their
> > > release or know that the release has some issues not in line with ASF
> > > policy then the work in progress disclaimer can be used.
> > >
> > > Unless the release is simple and straightforward, I would recommend
> that a
> > > podling uses the work in progress disclaimer for the first couple of
> > > releases.
> > >
> > > For what is allowed under the work in progress disclaimer please see
> this
> > > legal JIRA [2]. This allows a lot more in a release but not everything.
> > > Certain things are required like having a LICENSE, NOTICE and
> > > DISCLAIMER-WIP, and while it would be OK to include compiled code you
> still
> > > need to comply with any licensing for that code.
> > >
> > > By the time a podling graduates it's expected that they are making
> > > releases with the standard disclaimer.
> > >
> > > Here is the text of the DISCLAIMER-WIP where the Incubator is the
> sponsor:
> > > 
> > > Apache  #Podling-Name# is an effort
> > > undergoing incubation at The Apache Software Foundation (ASF),
> > > sponsored by the Apache Incubator. Incubation is required of all
> > > newly accepted projects until a further review indicates that the
> > > infrastructure, communications, and decision making process have
> > > stabilized in a manner consistent with other successful ASF projects.
> > > While incubation status is not necessarily a reflection of the
> > > completeness or stability of the code, it does indicate that the
> > > project has yet to be fully endorsed by the ASF.
> > >
> > > Some of the incubating project's releases may not be fully compliant
> > > with ASF policy. For example, releases may have incomplete or
> > > un-reviewed licensing conditions. What follows is a list of known
> > > issues the project is currently aware of (note that this list, by
> > > definition, is likely to be incomplete):
> > > #List of known issues go here#
> > >
> > > If you are planning to incorporate this work into your
> > > product/project, please be aware that you will need to conduct a
> > > thorough licensing review to determine the overall implications of
> > > including this work. For the current status of this project through the
> > > Apache
> > > Incubator visit:
> > > http://incubator.apache.org/project/#Podling-Name#.html
> > > 
> > >
> > > Just fill in #Podling-Name# with your podling name and list the known
> > > issues in the correct place.
> > >
> > > Thanks,
> > > Justin
> > >
> > > 1. https://incubator.apache.org/policy/incubation.html#disclaimers
> > > 2. https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-469
> > > -
> > > 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: Podlings, the Incubator, relationships and Apache

[Davor Bonaci]

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

[Davor Bonaci]

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

[Davor Bonaci]

I wouldn't say that there are 2 camps. The IPMC seems to be overwhelmingly
in the "2nd camp", with its desire to be lenient with the releases and
rules.

What I see is:
[1] David is saying (correctly) how Incubator is structured right now. He
hasn't expressed ~any opinions; it is just an interpretation of the facts
from past resolutions and decisions made. I don't think anything said there
is questionable as the current state of affairs.
[2] Most of IPMC agrees that the current state of affairs is [1], and
desires to relax it somewhat.
[3] Hence, Justin is asking for clarification regarding IPMC's authority to
depart from the current state of affairs described in [1].

The IPMC is capable of making the business decision; Justin is not asking
for the decision to be made, but instead to better understand the IPMC's
authority of possible decisions.

On Sun, Jun 23, 2019 at 8:53 PM Dave Fisher  wrote:

> Thanks Roman!
>
> +1 to the 2nd camp!
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Jun 23, 2019, at 8:25 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
> >
>
>
> -
> 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

[Davor Bonaci]

I second every single sentence said here. Every. Single. Sentence.

On Thu, Jun 20, 2019 at 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. The Board has delegated the responsibility of managing and ensuring
> adherence to policies and guidelines to the IPMC. I don't see this
> responsibility as boolean. 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.
>
> From a podling's perspective:
> 1. Once you join the incubator you're a part of the ASF (Yay!?)
> 2. Your project is now a subproject of the IPMC.
> 3. There are rules, and you're entering a world of pain[4] In fact,
> you're likely to find that the ASF has more rules and structure that
> apply to projects than virtually any other home your project could
> choose. This is good and bad.
> 4. The incubator has a long, storied history of producing successful
> projects that flourish.
>
>
> [1]
> http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt
> [2] What we call Podlings, the initial resolution refers to as
> subprojects of the Incubator
> [3] It's worth noting that there were two resolutions proposed to
> create the Incubator - small differences, but interesting to read the
> differences.
> [4] https://youtu.be/3vB9U2hx6Qg
> [5] https://www.apache.org/foundation/faq.html#why
>
> 

Re: [IMPORTANT] Board proposal on podling releases

[Davor Bonaci]

I think my position is well-known, but I'll restate it for completeness:

(1) Podling releases are foundation releases; no exceptions. They are
distributed in the same way, adopted by a foundation PMC in the same
manner, and they being with word "Apache". We are responsible for them.
(2) IPMC desires to foster learning and iterative improvement. We want to
be lenient with releases, and waive various *ASF policies* as deemed in the
best interest of the podling and the foundation.
(3) IPMC does not have authority to waive any legal requirements (like
someone's license) or policies of others (like someone's trademark policy).
If such an issue in a release *against a third party* is discovered, even
if minor, the IPMC should block such a release unconditionally. Note that
accidental and unintentional omission is fine, but known and willful is not.
(4) Given the above, it would be beneficial for the IPMC if the Board would
explicitly confirm IPMC's discretionary authority in waiving ASF release
and distribution policy.

I feel less strongly about:
(5) IPMC doesn't need to specify what is "may", "should", or "must" too
precisely. The precision above is good enough. In fact, "best interests"
doesn't mean "equality". Even if two releases suffer from the same issue,
it may be fine for a podling in early stages, but be blocked for a podling
where they have a regression compared to a previous release. "Committee
discretion" is much better than "rules". No new rules please.

On Sat, Jun 8, 2019 at 9:31 AM Julian Hyde  wrote:

> We’re trying to nail down the definition of “serious”.  May I suggest that
> we divide the guidelines into MAY, SHOULD and MUST. Anything with MUST is
> mandatory for all podling releases.
>
> The list may or may not be the same as for TLP releases.
>
> Julian
>
>
>
> Sent from my iPad
> > On Jun 7, 2019, at 5:56 PM, Justin Mclean 
> wrote:
> >
> > Hi,
> >
> >> 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.
> >
> > And in cases where this has happened, it’s been ALv2 licensed, so I
> guess that wouldn’t be legal. But we also allow minor stuff like this a lot
> of the time e.g forgetting to add  MIT license text to LICENSE.
> >
> >> 2) Is it legal to include compiled code in releases?  Yes.
> >
> > But certainly against ASF policy and one of it core values.
> >
> >> 3) Is it legal to include copyright violations in releases?  No.
> >
> > In most cases, where this has occurred this has been minor, like
> including a cat photo, and can be easily sorted by removing or asking for
> permission. If someone did come along as say you don’t have permission to
> do that, we’d say we were very sorry and fix it.
> >
> > Perhaps rewording the proposal to say "serious issue typically found in
> podling releases” would help? Podlings generally make some effort to try
> and get things right.
> >
> > Thanks,
> > Justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Podling use of StackOverflow

[Davor Bonaci]

I am aware. I'd say it doesn't (or shouldn't) apply in this case. Nobody is
taking a library out of SO and putting it into a project -- they don't have
such a thing. Reading a generic answer how to do something from a 5-line
code snippet, and then applying the (derivative) learning should not be an
issue.

On Sun, Apr 7, 2019 at 12:51 AM Justin Mclean 
wrote:

> Hi,
>
> > - We should -not- stress about whether SO is used by our contributors (to
> > create contributions) and/or (its derivatives are) included in Apache
> > projects.
>
> Did you read currently legal policy on including CC-BY-SA licensed code?
> (not matter where it comes from) It’s considered category X so that would
> be against current ASF legal advice. [1],"Thus their inclusion shall be
> appropriately labelled and only in binary form.”, but if in doubt ask on
> legal discuss. CC-BY-SA images, sounds, fonts etc can be included. [2]
>
> But that is a seperate issue from having people use the service as you
> point out.
>
> Thanks,
> Justin
>
> 1. http://www.tavfrna.incubator.apache.org/legal/resolved.html#cc-by
> 2. http://www.tavfrna.incubator.apache.org/legal/resolved.html#cc-sa
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Podling use of StackOverflow

[Davor Bonaci]

It feels this thread has somewhat veered off the initial question. My
position on this is non-purist, and perhaps more pragmatic.

SO licensing:
- Their licensing is reasonable for what they are trying to do. Just as
many social networks, they don't want somebody to suck up their (users')
content, create a better UX, and steel away the traffic. Therefore,
creating an archive of questions and answers from SO to an Apache mailing
list is a *big* no-no. Apache projects should not subscribe notifications
from SO to a mailing list, as it may be perceived as creating an archive.

- We should -not- stress about whether SO is used by our contributors (to
create contributions) and/or (its derivatives are) included in Apache
projects. The whole project is not a derivative of SO, their posts are
generic and often just a few lines, and the world would have to very
different place before we'd be affected. We should just drop this tangent,
and should not overwhelm our contributors with this. (To all purists out
there, I'm sorry.)

- We should -not- avoid SO simply because (some of) our users may be
concerned with SO licensing. Let them worry about each channel and their
consequences (if any). If they are worried about it, they'd probably use a
different channel in the first place.

My (personal) recommendation:
- Embrace SO. Have a tag. Help people. Do engage with everyone wherever
they may be. Recognize contributions, and all that comes with it.
- Do -not- try to steer traffic towards or away from SO, and avoid adding
barriers by forcing anybody to reach you in a different way (than they
already have).
- Do -not- try to create an archive of SO, but otherwise no need to worry
about SO licensing in any other direction.

On SO itself:
They solved a pain point and they have lots of traffic (today). Great for
them. Anything can happen in the future. They may start charging a
subscription fee to read the answers. All answers may be lost -- who knows.
Nothing should concern us here, as long as we don't try to steer traffic in
any direction, and simply use their system to engage with our communities
for our benefit.

Hope this helps (to Superset and others).

Davor

On Sat, Apr 6, 2019 at 8:28 AM Ted Dunning  wrote:

> Craig
>
> You are correct. I missed the distinction between their content and user
> content.
>
> As you say, nothing on SO can be incorporated into Apache anything without
> separate licensing. This is a good argument for redundant answers on Apache
> mailing lists.
>
>
> On Sat, Apr 6, 2019, 6:45 AM Craig Russell  wrote:
>
> >
> >
> > > On Apr 5, 2019, at 8:03 PM, Justin Mclean  wrote:
> > >
> > > Hi,
> > >
> > >> Not by my reading. Contributions to the content are licensed to SO by
> a
> > grant similar to the way contributions to Apache are licensed by a grant.
> > It's not copyright assignment, it's "just a grant.
> > >
> > > I believe they become a little more friendlier and it use to be that
> > they did own everything but now it CC-SA licensed, but it looks like that
> > non-commercial clause also applies? Either it's best to ask owners
> > permission to use anything from there code wise that end up in an Apache
> > project.
> >
> > I totally agree. By Apache standards, any code/documentation/thing posted
> > there is not available for inclusion into a project unless we get
> explicit
> > permission from the owner. Just like anything you find by trawling the
> > internet.
> >
> > Craig
> > >
> > > Thanks,
> > > Justin
> > >
> >
> > Craig Russell
> > Member, Apache Incubator PMC
> > apache@gmail.com
> >
> >
> >
> >
>

Re: Voting on releases with serious unaddressed issues

[Davor Bonaci]

The issue at hand is simply called theft, and everyone (both inside and
outside the community) is most welcome to point it out and ask for it to be
fixed. We thank those individuals who point it out, whether in IPMC or
otherwise, and look for ways to address it as soon as possible.

Fixing this issue is in the best interest of the foundation, the project,
the community, the release manager, the copyright owner... everyone. We
don't push back on this. We don't look for reasons why the individual has
no standing in pointing it out. We don't find excuses. (If we do and/or
continue as nothing happened, we'd just make a case that the theft was
willful and action negligent -- we do not do that.)

So... to be direct -- just fix the damn problem, thank Justin for pointing
it out, and stop arguing.

You may find that fixing the problem requires no code changes. If you'd
just politely email the copyright owner, explain the situation, that ASF is
a charity, offer to promote the photographer in legal notices, you may find
that a reasonable person will just grant you the permission you need and
thank you for helping promote his work. This is particularly true if you
ask for a few photos, out of the photographer's huge collection. It is
often as simple as that. (Try that instead of arguing here, but make sure
to phrase things properly so that everyone understands all implications of
licensing downstream and upstream.)

On Sat, Mar 30, 2019 at 2:31 PM Craig Russell  wrote:

> Hi Ted,
>
> > On Mar 30, 2019, at 2:22 PM, Ted Dunning  wrote:
> >
> > On Sat, Mar 30, 2019 at 1:57 PM Craig Russell 
> wrote:
> >
> >> 
> >>> copyright issues on the cute cat and rabbit photos [1] probably mean
> >> that they cannot put that release in the ASF distribution area even if
> they
> >> do get 3 +1s without legal and infra approval.
> >>
> >> We have to look at risk here. Is there a risk that the owner of the
> images
> >> is going to make trouble?
> >>
> >
> > I am kind of stunned to hear this.
>
> >
> > The web site where the images came from says:
> >
> > We have an extensive commercial picture library of professional Nature
> and
> >> Pet photographs. Our images are sold on a rights managed basis and can
> be
> >> bought for specific and exclusive uses. All the images on this website
> are
> >> ©Warren Photographic and watermarked with our logo.
> >
> > (see https://www.warrenphotographic.co.uk/about.php)
> >
> > This sounds a lot like serious photographers trying to make a living.
> > Anybody who goes to the trouble of watermarking their images is pretty
> > serious about their work and about people stealing that work.
> >
> > But aside from that, quite frankly, Apache is not in the business of
> > judging whether somebody is powerful enough or aware enough or rich
> enough
> > or even just cantankerous enough to make trouble for us about copyright
> > infringement.
>
> This is way over the top. Please don't go there.
>
> > We don't even do adversarial forks of open source material
> > where the license says that it is perfectly fine to do.
> >
> > So how can anybody imagine that it is OK to steal some images from people
> > who do not grant the rights to use just because they aren't likely to
> "make
> > trouble"?
> >
>
> I am not arguing that the image issue does not need to be resolved. Just
> the opposite.
>
> Perhaps I should have elaborated: Is there a risk that during the next few
> weeks that it will take us to either get permission or remove the image
> that the owner is going to make trouble?
>
> Craig
> >
> >
> >>>
> >>> What do other IPMC members think?
> >>
> >> I think that if others want to dig into the details, I would encourage
> >> them to do so. But at this point, I do not believe that the issues you
> >> raised warrant a -1 on the release.
> >
> >
> > The issue of the photos has been previously raised. The suggested
> solution
> > was to delete the photos.
> >
> > It should be done.
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org  http://db.apache.org/jdo <
> http://db.apache.org/jdo>
>

Re: A smaller IPMC

[Davor Bonaci]

As framed herein, #4 for sure. (But, that doesn't necessarily exclude
support for various ideas that rework how IPMC operates, and where reducing
the size may be a small part of something larger and intentional.)

On Thu, Mar 7, 2019 at 9:13 PM Ross Gardler  wrote:

> I think this thread misses the point of the original observation.
>
> Firstly, I've not seen anyone suggest that removing inactive IPMC members
> will make any difference. What I've seen is a suggestion that active IPMC
> members on general@ should be expected to be on the private list.
>
> While there aren't many conversations over there. When there is one it is
> important.
>
> Secondly, I think the framing of #4 (which I agree with in the context of
> this thread, given the above observation) incorrectly identifies the "real"
> problem. While inactive mentors a problem for individual podlings I don't
> believe they are the cause of the inteference the IPMC can display when it
> comes to things like podling releases.
>
> In other words I consider this whole thread a distraction.
>
> Get Outlook for Android
>
> 
> From: Kenneth Knowles 
> Sent: Thursday, March 7, 2019 7:49:29 PM
> To: general@incubator.apache.org
> Subject: Re: A smaller IPMC
>
> +1 for #4 noop, at least until there's evidence of a problem.
>
> Kenn
>
> On Thu, Mar 7, 2019 at 6:27 PM Woonsan Ko  wrote:
>
> > On Thu, Mar 7, 2019 at 6:33 PM Justin Mclean 
> > wrote:
> > >
> > > Hi,
> > >
> > > It’s been suggested that the IPMC is too large, what do other IPMC
> > members think might be a way to address this?
> > >
> > > Please discuss and indicate +1 what you would think would help, you can
> > vote for more than one.
> > >
> > > Some suggestions:
> > > 1. Ask all inactive IPMC if they want to continue being on the IPMC and
> > see who steps down. Being inactive they are probably not following this
> > list so we need to identify and send each one email them personally.
> > > 2. There were some questions around merit raised, remove all IPMC
> > members who were not on the initial proposal and who were voted in. Those
> > left on the IPMC vote back in those who are currently active.
> > > 3. Get rid of all IPMC members, and vote (with ASF members vote being
> > binding - not sure how else it could be done?) currently active ones back
> > in.
> > > 4. Do nothing as this is not actually a problem but instead address
> > other underlying issues. e.g. lack of mentor engagement.
> >
> > +1 to my modified version from #2 (and 0 to the others as I don't
> > think they will help a lot):
> > "Remove all IPMC members who were not on the initial proposal and who
> > were voted in. Those left on the IPMC vote for those, as members, who
> > can recruit, guide mentors, and review podling graduations, and they
> > also vote for those, as mentors (committers), who have ever been
> > active mentors for podlings."
> >
> > Mentors are committers: if someone starts contributing in this
> > community, they are to be recognized and invited to a mentor
> > (committer) in this project; if they contribute more for the community
> > consistently, they are to be invited to a IPMC member. In smaller
> > IPMC, IPMC members focus more on helping/guiding mentors and reviewing
> > graduations in various aspects, and mentors focus more on detail
> > issues in podlings, providing enough overview and information to IPMC.
> > I think this will make it a fairer merit-earning game, to new comers
> > getting helps from mentors and (graduation and/or high-level) reviews
> > from members, watchers considering to help, mentors eager to help
> > graduations, more focused members, ...
> >
> > >
> > > Also re point 2 do you think we should drop that ASF members can
> > automatically get IPMC membership and change it to requiring a vote by
> the
> > IPMC? It’s has always seem odd to me that this is the case. We’ve
> recently
> > voted more people in that we’ve had requests from ASF members.
> >
> > +1 to always be voting, whether they are ASF members or not, like other
> > PMCs.
> >
> > >
> > > Any other sugestions?
> > >
> > > Options 2 and 3 may cause some issues around mentors, but if they were
> > not active then I guess it’s no big loss.
> >
> > My modified version includes all active people as mentors (committers)
> > at least, so there's no loss as well.
> >
> > Regards,
> >
> > Woonsan
> >
> > >
> > > And any suggestions on level of activity? Such as:
> > > - Emailed the list in the last year.
> > > - Reviewed at least one release in that time.
> > >
> > > It’s already been determined that some (about 15%) of the less than
> > active PMC members (out of the 100 odd that are not signed up to the IPMC
> > private list) do help out infrequently but that help is very useful. That
> > may also apply to other inactive IPMC members, so I would suggest the bar
> > for what consider active be kept low.
> > >
> > > Thanks,
> > > Justin
> > > 

Re: [VOTE] Release Apache Nemo (Incubating) 0.1

[Davor Bonaci]

+1, binding, carried from dev@

On Thu, Dec 27, 2018 at 12:52 AM David Meikle  wrote:

> +1 (binding). I checked; name, sig and hashes (only checked sha512),
> notice, license, source headers, compiles from source (Ubuntu).
>
> As Justin says, you can remove the MD5 file.
>
> Cheers,
> Dave
>
> > On 27 Dec 2018, at 01:57, Joo Yeon Kim  wrote:
> >
> > Please refer to the information below to vote on this release, and vote:
> > (Please mark your vote as binding if so)
> > [ ] +1 Release this package as Apache Nemo (incubating) 0.1
> > [ ] 0 I don't feel strongly about it, but the release seems okay.
> > [ ] -1 Please do not release this package because...
>
>

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

[Davor Bonaci]

+1 (binding)

On Wed, Sep 12, 2018 at 8:41 AM Dave Fisher  wrote:

> +1 - binding - Graduate Pulsar!
>
> Regards,
> Dave
>
> On Sep 12, 2018, at 8:40 AM, Dave Fisher  wrote:
>
> Hi -
>
> The Apache Pulsar project is ready to graduate as a TLP. They entered
> Incubation on June 1, 2017, have had many releases and have grown the
> community.
>
> Vote:
> [ ] +1 - Recommend Graduation of Apache Pulsar as a TLP
> [ ] -1 - Do not recommend graduation of Apache Pulsar because ….
>
> At the mentors request they did a maturity model analysis [1] and wrote
> contribution guidelines. [2]
>
> The Graduation Proposal was written and discussed on the dev list. [3] At
> the mentor's recommendation the By-Laws Clause was removed.
>
> The new prospective PMC is set and the VOTE thread in the podling is here
> [4] with these results. [5]
>
> Regards,
> Dave
>
> [1]
> https://github.com/apache/incubator-pulsar/wiki/Apache-Maturity-Model-Assessment-for-Pulsar
> [2] http://pulsar.incubator.apache.org/en/contributing/
> [3]
> https://lists.apache.org/thread.html/b0914461f57253237e4a3c9151342f6d4fa37359dfc98a07adf9f36f@%3Cdev.pulsar.apache.org%3E
> [4]
> https://lists.apache.org/thread.html/93198abe36564a9e11a2a1bfe3ea8f35998444dbafea830f8b39df7b@%3Cdev.pulsar.apache.org%3E
> [5]
> https://lists.apache.org/thread.html/64841a07ba3dee2271f4098f9142afd41acffae1736275592aab4c83@%3Cdev.pulsar.apache.org%3E
>
>
> 
>
> Establish the Apache Pulsar 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 highly scalable, low latency messaging platform running on
> commodity hardware. It provides simple pub-sub and queue semantics over
> topics, lightweight compute framework, automatic cursor management for
> subscribers, and cross-datacenter replication.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Pulsar Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache Pulsar Project be and hereby is responsible
> for the creation and maintenance of software related to a highly
> scalable, low latency messaging platform running on commodity hardware.
> It provides simple pub-sub and queue semantics over topics, lightweight
> compute framework, automatic cursor management for subscribers, and
> cross-datacenter replication; and be it further
>
> RESOLVED, that the office of "Vice President, Apache Pulsar" 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 Pulsar
> Project, and to have primary responsibility for management of the
> projects within the scope of responsibility of the Apache Pulsar
> 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 Pulsar Project:
>
> * Boyang Jerry Peng 
> * Brad McMillen 
> * David Fisher 
> * Francis Christopher Liu 
> * Hiroyuki Sakai 
> * Ivan Brendan Kelly 
> * Jai Asher 
> * Jia Zhai 
> * Jim Jagielski 
> * Joe Francis 
> * Ludwig Pummer 
> * Masahiro Sakamoto 
> * Masakazu Kitajo 
> * Matteo Merli 
> * Nozomi Kurihara 
> * P. Taylor Goetz 
> * Rajan Dhabalia 
> * Sahaya Andrews 
> * Sanjeev Kulkarni 
> * Sebastián Schepens 
> * Siddharth Boobna 
> * Sijie Guo 
> * Yuki Shiga 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matteo Merli be appointed
> to the office of Vice President, Apache Pulsar, 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 Pulsar Project be and hereby is tasked with
> the migration and rationalization of the Apache Incubator Pulsar
> podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> Pulsar podling encumbered upon the Apache Incubator PMC are hereafter
> discharged.
>
>
>

Re: [DISCUSS] Graduate Apache Pulsar (incubating) as a TLP

[Davor Bonaci]

Strong +1.

I've been following from a distance: growth of the community is obvious, as
well as maturing project governance evidenced by working through *all*
issues that have been brought up. Mentors are continuing onto the PMC. I'm
confident that Pulsar is ready to be a TLP.

On Mon, Sep 10, 2018 at 8:49 PM Dave Fisher  wrote:

> Hi -
>
> The Apache Pulsar project is ready to graduate as a TLP. They entered
> Incubation on June 1, 2017, have had many releases and have grown the
> community.
>
> At the mentors request they did a maturity model analysis [1] and wrote
> contribution guidelines. [2]
>
> The Graduation Proposal was written and discussed on the dev list. [3] At
> the mentor's recommendation the By-Laws Clause was removed.
>
> The new prospective PMC is set and the VOTE thread in the podling is here
> [4] with these results. [5]
>
> Let’s see if there is any discussion here on general@incubator before
> moving onto a VOTE.
>
> Regards,
> Dave
>
> [1]
> https://github.com/apache/incubator-pulsar/wiki/Apache-Maturity-Model-Assessment-for-Pulsar
> [2] http://pulsar.incubator.apache.org/en/contributing/
> [3]
> https://lists.apache.org/thread.html/b0914461f57253237e4a3c9151342f6d4fa37359dfc98a07adf9f36f@%3Cdev.pulsar.apache.org%3E
> [4]
> https://lists.apache.org/thread.html/93198abe36564a9e11a2a1bfe3ea8f35998444dbafea830f8b39df7b@%3Cdev.pulsar.apache.org%3E
> [5]
> https://lists.apache.org/thread.html/64841a07ba3dee2271f4098f9142afd41acffae1736275592aab4c83@%3Cdev.pulsar.apache.org%3E
>
>
> 
>
> Establish the Apache Pulsar 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 highly scalable, low latency messaging platform running on
> commodity hardware. It provides simple pub-sub and queue semantics over
> topics, lightweight compute framework, automatic cursor management for
> subscribers, and cross-datacenter replication.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Pulsar Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache Pulsar Project be and hereby is responsible
> for the creation and maintenance of software related to a highly
> scalable, low latency messaging platform running on commodity hardware.
> It provides simple pub-sub and queue semantics over topics, lightweight
> compute framework, automatic cursor management for subscribers, and
> cross-datacenter replication; and be it further
>
> RESOLVED, that the office of "Vice President, Apache Pulsar" 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 Pulsar
> Project, and to have primary responsibility for management of the
> projects within the scope of responsibility of the Apache Pulsar
> 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 Pulsar Project:
>
> * Boyang Jerry Peng 
> * Brad McMillen 
> * David Fisher 
> * Francis Christopher Liu 
> * Hiroyuki Sakai 
> * Ivan Brendan Kelly 
> * Jai Asher 
> * Jia Zhai 
> * Jim Jagielski 
> * Joe Francis 
> * Ludwig Pummer 
> * Masahiro Sakamoto 
> * Masakazu Kitajo 
> * Matteo Merli 
> * Nozomi Kurihara 
> * P. Taylor Goetz 
> * Rajan Dhabalia 
> * Sahaya Andrews 
> * Sanjeev Kulkarni 
> * Sebastián Schepens 
> * Siddharth Boobna 
> * Sijie Guo 
> * Yuki Shiga 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matteo Merli be appointed
> to the office of Vice President, Apache Pulsar, 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 Pulsar Project be and hereby is tasked with
> the migration and rationalization of the Apache Incubator Pulsar
> podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> Pulsar podling encumbered upon the Apache Incubator PMC are hereafter
> discharged.
>
>

Re: [PROPOSAL] Zipkin for Apache Incubator

[Davor Bonaci]

+1; this sounds great.

On Sun, Aug 19, 2018 at 6:34 AM, 吴晟 Sheng Wu  wrote:

> > I think Skywalking may face the same issue, few people register the
> mailing
> list because lots of discussion happen in the github issues.
>
> Yes. Many people used to discuss on GitHub. We are OK with that. We have
> 38 discussion issues[1] in this 5.0.0-RC development iteration(only a
> month).
>
>
> > I'd be happy to be the mentor of this project if you are interested.I
> guess
> there is still a room for additional mentor.
> As some part of my daily work[2] is based on the work of zipkin, I can
> devote more time on this project.
>
>
> I added you in the mentor list. Thanks.
>
>
> [1] https://github.com/apache/incubator-skywalking/issues?q=
> is%3Aissue+is%3Aclosed+label%3Aquestion+milestone%3A5.0.0-RC
>
>
> --
> Sheng Wu
> Apache SkyWalking
>
>
>
>
>
>
>
> -- Original --
> From:  "willem.jiang";
> Date:  Sun, Aug 19, 2018 07:36 AM
> To:  "general";
>
> Subject:  Re: [PROPOSAL] Zipkin for Apache Incubator
>
>
>
> +1. It's great that Zipkin can be a part of Apache Incubator project.
>
> After going through the discussion here[1], I can see Zipkin leverage
> Github infrastructure  a lot, we may need to figure out if we need to setup
> the user mailing list for this project.
> I agree with what John has said, you may consider twice for migration user
> discussion from github to apache mailing list.
> I think Skywalking may face the same issue, few people register the mailing
> list because lots of discussion happen in the github issues.
>
> I'd be happy to be the mentor of this project if you are interested.I guess
> there is still a room for additional mentor.
> As some part of my daily work[2] is based on the work of zipkin, I can
> devote more time on this project.
>
> [1] https://github.com/openzipkin/openzipkin.github.io/issues/51
> [2] https://github.com/apache/incubator-servicecomb-saga
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Aug 17, 2018 at 5:29 PM, Adrian Cole 
> wrote:
>
> > I would like to propose Zipkin as an Apache Incubator project.
> >
> > The text of the proposal can be found below as well as on the Incubator
> > wiki:
> >
> > https://wiki.apache.org/incubator/ZipkinProposal
> >
> > I believe we should have 3 mentors.. currently we have 2 (plus Wu
> > Sheng and I who are familiar but not mentor-grade :P). If another
> > person can volunteer to mentor us, would be sweet.
> >
> > -Adrian
> >
> > = Abstract =
> > Zipkin is a distributed tracing system. It helps gather timing data
> > needed to troubleshoot latency problems in microservice architectures.
> > It manages both the collection and lookup of this data. Zipkin’s
> > design is based on the Google Dapper paper.
> >
> > = Proposal =
> > Zipkin provides a defined data model and payload type for distributed
> > trace data collection. It also provides an UI and http api for
> > querying the data. Its server implements this api and includes
> > abstractions for storage and transport of trace payloads. The
> > combination of these parts avoid lock-in to a specific tracing
> > backend. For example, Zipkin includes integration with different open
> > source storage mechanisms like Apache Cassandra and Elasticsearch. It
> > also includes bridges to convert collected data and forward it to
> > service offerings such as Amazon X-Ray and Google Stackdriver.
> > Ecosystem offering extend this portability further.
> >
> > While primarily focused on the system, Zipkin also includes tracing
> > libraries which applications use to report timing information.
> > Zipkin's core organization includes tracer libraries written in Java,
> > Javascript, Go, PHP and Ruby. These libraries use the formats
> > mentioned above to report data, as well "B3" which is a header format
> > needed to send trace identifiers along with production requests. Many
> > Zipkin libraries can also send data directly to other services such as
> > Amazon X-Ray and Google Stackdriver, skipping any Zipkin
> > infrastructure. There are also more Zipkin tracing libraries outside
> > the core organization than inside it. This is due to the "OpenZipkin"
> > culture of promoting ecosystem work.
> >
> > = Background =
> > Zipkin began in 2012 at Twitter during a time they were investigating
> > performance problems underlying the "fail whale" seen by users. The
> > name Zipkin is from the Turkish word for harpoon: the harpoon that
> > will kill the failures! Incidentally, Zipkin was not the first tracing
> > system, it had roots in a former system at Twitter named
> > BigBrotherBird. It is due to BigBrotherBird that the de-facto tracing
> > headers we still use today include the prefix "X-B3".
> >
> > In 2015, a community of users noticed the project was not healthy in
> > so far as it hadn't progressed and often didn't accept pull requests,
> > and the Cassandra backend was stuck on an unmaintained library. For
> > example, the 

Re: [VOTE] Release Apache Amaterasu (incubating) 0.2.0 (rc4)

[Davor Bonaci]

+1 (carried over)

On Sun, Jul 8, 2018 at 12:15 AM, Justin Mclean 
wrote:

> Hi,
>
> +1 (binding)
>
> Sorry did this a while back but forgot to send
>
> I checked:
> - incubating in name
> - signatures and hashes correct
> - DISCLAIMER exists
> - LICENSE is OK but could be improved
> - NOTICE year needs updating
> - no unexpected binary files
> - all ASF source files have correct headers
> - can compile from source
>
> For the license it would be nice to mention the version of the bundled
> software and what the license is rather than just pointing to the license
> file.Also the license files pointed to also contain multiple licenses which
> is a little surprising, it’s may be better to put that info in the LICENSE
> file an/or only have a single license per file.
>
> The source release also contains multiple archives [2][3][4][5] which
> makes it harder to review, could these be expanded in the release?
>
> Thanks,
> Justin
>
> 1. incubator-amaterasu-version-0.2.0-incubating-rc4 <
> http://localhost:8081/repo/?mod=license=2=6>/executor <
> http://localhost:8081/repo/?mod=license=2=54>/src <
> http://localhost:8081/repo/?mod=license=2=56>/main <
> http://localhost:8081/repo/?mod=license=2=57>/resources <
> http://localhost:8081/repo/?mod=license=2=58>/codegen.py
> 2. incubator-amaterasu-version-0.2.0-incubating-rc4/executor/
> src/test/resources/py4j-0.10.4-src.zip
> 3. incubator-amaterasu-version-0.2.0-incubating-rc4/executor/
> src/test/resources/py4j.tar.gz
> 4. incubator-amaterasu-version-0.2.0-incubating-rc4/executor/
> src/test/resources/pyspark.tar.gz
> 5. incubator-amaterasu-version-0.2.0-incubating-rc4/executor/
> src/test/resources/pyspark.zip

Re: [VOTE] Release Apache Amaterasu (incubating) 0.2.0 (rc3)

[Davor Bonaci]

+1 (binding), carried over.

On Thu, Jun 14, 2018 at 9:37 PM, Yaniv Rodenski  wrote:

> Hi,
>
> I've removed the md5's, and will update the Amaterasu release procedure
> accordingly.
>
> Cheers,
> Yaniv
>
> On Fri, Jun 15, 2018 at 1:04 AM, Henk P. Penning  wrote:
>
> > On Thu, 14 Jun 2018, Yaniv Rodenski wrote:
> >
> > Date: Thu, 14 Jun 2018 16:32:19 +0200
> >> From: Yaniv Rodenski 
> >> To: general@incubator.apache.org
> >> Subject: [VOTE] Release Apache Amaterasu (incubating) 0.2.0 (rc3)
> >>
> >
> >   Please remove the .md5's ; see policy :
> >
> > https://www.apache.org/dev/release-distribution#sigs-and-sums
> >
> >   This does NOT affect the VOTE ; please continue ...
> >
> >   Regards,
> >
> >   Henk Penning
> >
> >    _
> > Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> > Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> > Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> > http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/
> >
> >
> > The Apache Amaterasu (incubating) community has voted on and approved a
> >> proposal to release Apache Amaterasu 0.2.0-rc3.
> >>
> >> We now kindly request that the Incubator PMC members review and vote on
> >> this incubator release candidate.
> >>
> >> Apache Amaterasu is a Configuration Managment and Deployment Framework
> for
> >> Big Data Pipelines.
> >>
> >> The vote thread is at:
> >> http://mail-archives.apache.org/mod_mbox/amaterasu-dev/20180
> >> 5.mbox/%3CCAKm_
> >> 3C0qT7pYPjZm_C4JRiruQasW6be2F1xLx%2Bf2zfQvxBWJTA%40mail.gmail.com%3E
> >>
> >> and the result is at:
> >> http://mail-archives.apache.org/mod_mbox/amaterasu-dev/20180
> >> 6.mbox/%3CCAKm_3C1qYgM9%3DaOxt7JNo4R23UvoeP%3DhUi7GQpiVEc5Ad
> >> vAwMg%40mail.gmail.com%3E
> >>
> >>
> >> This is the first incubator release and it includes much-awaited
> >> improvements such as YARN support, PySpark and SparkSQL support and
> >> stability improvements.
> >>
> >> All distribution packages, including signatures, digests, etc. can be
> >> found at:
> >>
> >> https://dist.apache.org/repos/dist/dev/incubator/amaterasu/0.2.0rc3/
> >>
> >>
> >> This release has been signed with PGP key corresponding to
> >> ya...@apache.org, which is included in the repository's KEYS file (
> >> https://dist.apache.org/repos/dist/dev/incubator/amaterasu/KEYS).
> >>
> >> The release candidate has been tagged in git with
> >> version-0.2.0-incubating-rc3:
> >> https://github.com/apache/incubator-amaterasu/releases/tag/
> >> version-0.2.0-incubating-rc3
> >>
> >> Please review and vote. The vote will be open for at least 72 hours.
> >>
> >> Thank you very much,
> >> Yaniv
> >>
> >>
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> --
> Yaniv Rodenski
>
> +61 477 778 405
> ya...@shinto.io
>

[RESULT] [IP CLEARANCE] Apache Beam Go SDK

[Davor Bonaci]

Considered reviewed / adopted by lazy consensus. Thanks.

Davor

On Thu, May 31, 2018 at 7:09 PM, Davor Bonaci  wrote:

> Apache Beam has received a code donation of the Go SDK from Google [1].
> This has already happened, and the paperwork is now catching up in
> anticipation of the first release containing this donation.
>
> The IP clearance paperwork is ready for review, via a lazy consensus
> majority vote, per the IP clearance process [2], open for at least 72 hours.
>
> Thanks!
>
> Davor
>
> [1] http://incubator.apache.org/ip-clearance/beam-go-sdk.html
> [2] http://incubator.apache.org/ip-clearance/
>

[IP CLEARANCE] Apache Beam Go SDK

[Davor Bonaci]

Apache Beam has received a code donation of the Go SDK from Google [1].
This has already happened, and the paperwork is now catching up in
anticipation of the first release containing this donation.

The IP clearance paperwork is ready for review, via a lazy consensus
majority vote, per the IP clearance process [2], open for at least 72 hours.

Thanks!

Davor

[1] http://incubator.apache.org/ip-clearance/beam-go-sdk.html
[2] http://incubator.apache.org/ip-clearance/

Re: [VOTE] Accept Druid into the Apache Incubator

[Davor Bonaci]

+1 (binding)

On Thu, Feb 22, 2018 at 11:57 AM, P. Taylor Goetz  wrote:

> +1 (binding)
>
> -Taylor
>
> > On Feb 22, 2018, at 2:03 PM, Julian Hyde  wrote:
> >
> > Hi all,
> >
> > After some discussion on the Druid proposal[1], I'd like to
> > start a vote on accepting Druid into the Apache Incubator,
> > per the ASF policy[2] and voting rules[3].
> >
> > A vote for accepting a new Apache Incubator podling is a
> > majority vote for which only Incubator PMC member votes are
> > binding. Votes from other people are also welcome as an
> > indication of people's enthusiasm (or lack thereof).
> >
> > Please do not use this VOTE thread for discussions.  If
> > needed, start a new thread instead.
> >
> > This vote will run for at least 72 hours. Please VOTE as
> > follows:
> > [ ] +1 Accept Druid into the Apache Incubator
> > [ ] +0 Abstain
> > [ ] -1 Do not accept Druid into the Apache Incubator
> >because ...
> >
> > The proposal is listed below, but you can also access it on
> > the wiki[4].
> >
> > Julian
> >
> > [1] https://lists.apache.org/thread.html/b95f90a30b6e8587e9b108f368b07c
> 1b3e23e25ca592448d9c9f81e2@%3Cgeneral.incubator.apache.org%3E
> >
> > [2] https://incubator.apache.org/policy/incubation.html#
> approval_of_proposal_by_sponsor
> >
> > [3] http://www.apache.org/foundation/voting.html
> >
> > [4] https://wiki.apache.org/incubator/DruidProposal
> >
> >
>
>

Re: [VOTE] Accept Coral into the Apache Incubator

[Davor Bonaci]

+1 (binding)

Also, happy to help, mentor, or be a connection with the Beam PMC, as
appropriate.

On Thu, Feb 1, 2018 at 9:54 AM, Kevin A. McGrail 
wrote:

> +1 Binding
>
>
> On 2/1/2018 9:07 AM, Byung-Gon Chun wrote:
>
>> Hi all,
>>
>> I would like to start a VOTE to propose the Coral project as a podling
>> into
>> the Apache Incubator.
>>
>> The ASF voting rules are described at https://www.apache.org/foundation/
>> voting.html
>>
>> A vote for accepting a new Apache Incubator podling is a majority vote for
>> which only Incubator PMC member votes are binding.
>>
>> This vote will run for at least 72 hours. Please VOTE as follows.
>> [] +1 Accept Coral into the Apache Incubator
>> [] +0 Abstain
>> [] -1 Do not accept Coral into the Apache Incubator because ...
>>
>> The proposal is listed below, but you can also access it on the wiki:
>> https://wiki.apache.org/incubator/CoralProposal
>>
>> = CoralProposal =
>>
>> == Abstract ==
>> Coral is a data processing system for flexible employment with
>> different execution scenarios for various deployment characteristics
>> on clusters.
>>
>> == Proposal ==
>> Today, there is a wide variety of data processing systems with
>> different designs for better performance and datacenter efficiency.
>> They include processing data on specific resource environments and
>> running jobs with specific attributes. Although each system
>> successfully solves the problems it targets, most systems are designed
>> in the way that runtime behaviors are built tightly inside the system
>> core to hide the complexity of distributed computing. This makes it
>> hard for a single system to support different deployment
>> characteristics with different runtime behaviors without substantial
>> effort.
>>
>> Coral is a data processing system that aims to flexibly control the
>> runtime behaviors of a job to adapt to varying deployment
>> characteristics. Moreover, it provides a means of extending the
>> system’s capabilities and incorporating the extensions to the flexible
>> job execution.
>>
>> In order to be able to easily modify runtime behaviors to adapt to
>> varying deployment characteristics, Coral exposes runtime behaviors to
>> be flexibly configured and modified at both compile-time and runtime
>> through a set of high-level graph pass interfaces.
>>
>> We hope to contribute to the big data processing community by enabling
>> more flexibility and extensibility in job executions. Furthermore, we
>> can benefit more together as a community when we work together as a
>> community to mature the system with more use cases and understanding
>> of diverse deployment characteristics. The Apache Software Foundation
>> is the perfect place to achieve these aspirations.
>>
>> == Background ==
>> Many data processing systems have distinctive runtime behaviors
>> optimized and configured for specific deployment characteristics like
>> different resource environments and for handling special job
>> attributes.
>>
>> For example, much research have been conducted to overcome the
>> challenge of running data processing jobs on cheap, unreliable
>> transient resources. Likewise, techniques for disaggregating different
>> types of resources, like memory, CPU and GPU, are being actively
>> developed to use datacenter resources more efficiently. Many
>> researchers are also working to run data processing jobs in even more
>> diverse environments, such as across distant datacenters. Similarly,
>> for special job attributes, many works take different approaches, such
>> as runtime optimization, to solve problems like data skew, and to
>> optimize systems for data processing jobs with small-scale input data.
>>
>> Although each of the systems performs well with the jobs and in the
>> environments they target, they perform poorly with unconsidered cases,
>> and do not consider supporting multiple deployment characteristics on
>> a single system in their designs.
>>
>> For an application writer to optimize an application to perform well
>> on a certain system engraved with its underlying behaviors, it
>> requires a deep understanding of the system itself, which is an
>> overhead that often requires a lot of time and effort. Moreover, for a
>> developer to modify such system behaviors, it requires modifications
>> of the system core, which requires an even deeper understanding of the
>> system itself.
>>
>> With this background, Coral is designed to represent all of its jobs
>> as an Intermediate Representation (IR) DAG. In the Coral compiler,
>> user applications from various programming models (ex. Apache Beam)
>> are submitted, transformed to an IR DAG, and optimized/customized for
>> the deployment characteristics. In the IR DAG optimization phase, the
>> DAG is modified through a series of compiler “passes” which reshape or
>> annotate the DAG with an expression of the underlying runtime
>> behaviors. The IR DAG is then submitted as an execution plan for the
>> Coral 

Re: [PROPOSAL] Onyx - proposal for Apache Incubation

[Davor Bonaci]

Great work -- I think this technology has a lot of promise, and I'd love to
see its evolution inside the Foundation.

Parts of it, like the Onyx Intermediate Representation [1], overlap with
the work-in-progress inside the Apache Beam project ("portability"). We'd
love to work together on this -- would you be open to such collaboration?
If so, it may not be necessary to start from scratch, and leverage the work
already done.

Regarding the name, Onyx would likely have to be renamed, due to a conflict
with a related technology [2].

Davor

[1] https://snuspl.github.io/onyx/docs/ir/
[2] http://www.onyxplatform.org/

On Thu, Jan 25, 2018 at 3:28 PM, Byung-Gon Chun  wrote:

> Dear Apache Incubator Community,
>
> Please accept the following proposal for presentation and discussion:
> https://wiki.apache.org/incubator/OnyxProposal
>
> Onyx is a data processing system that aims to flexibly control the runtime
> behaviors of a job to adapt to varying deployment characteristics (e.g.,
> harnessing transient resources in datacenters, cross-datacenter deployment,
> changing runtime based on job characteristics, etc.). Onyx provides ways to
> extend the system’s capabilities and incorporate the extensions to the
> flexible job execution.
> Onyx translates a user program (e.g., Apache Beam, Apache Spark) into an
> Intermediate Representation (IR) DAG, which Onyx optimizes and deploys
> based on a deployment policy.
>
> I've attached the proposal below.
>
> Best regards,
> Byung-Gon Chun
>
> = OnyxProposal =
>
> == Abstract ==
> Onyx is a data processing system for flexible employment with
> different execution scenarios for various deployment characteristics
> on clusters.
>
> == Proposal ==
> Today, there is a wide variety of data processing systems with
> different designs for better performance and datacenter efficiency.
> They include processing data on specific resource environments and
> running jobs with specific attributes. Although each system
> successfully solves the problems it targets, most systems are designed
> in the way that runtime behaviors are built tightly inside the system
> core to hide the complexity of distributed computing. This makes it
> hard for a single system to support different deployment
> characteristics with different runtime behaviors without substantial
> effort.
>
> Onyx is a data processing system that aims to flexibly control the
> runtime behaviors of a job to adapt to varying deployment
> characteristics. Moreover, it provides a means of extending the
> system’s capabilities and incorporating the extensions to the flexible
> job execution.
>
> In order to be able to easily modify runtime behaviors to adapt to
> varying deployment characteristics, Onyx exposes runtime behaviors to
> be flexibly configured and modified at both compile-time and runtime
> through a set of high-level graph pass interfaces.
>
> We hope to contribute to the big data processing community by enabling
> more flexibility and extensibility in job executions. Furthermore, we
> can benefit more together as a community when we work together as a
> community to mature the system with more use cases and understanding
> of diverse deployment characteristics. The Apache Software Foundation
> is the perfect place to achieve these aspirations.
>
> == Background ==
> Many data processing systems have distinctive runtime behaviors
> optimized and configured for specific deployment characteristics like
> different resource environments and for handling special job
> attributes.
>
> For example, much research have been conducted to overcome the
> challenge of running data processing jobs on cheap, unreliable
> transient resources. Likewise, techniques for disaggregating different
> types of resources, like memory, CPU and GPU, are being actively
> developed to use datacenter resources more efficiently. Many
> researchers are also working to run data processing jobs in even more
> diverse environments, such as across distant datacenters. Similarly,
> for special job attributes, many works take different approaches, such
> as runtime optimization, to solve problems like data skew, and to
> optimize systems for data processing jobs with small-scale input data.
>
> Although each of the systems performs well with the jobs and in the
> environments they target, they perform poorly with unconsidered cases,
> and do not consider supporting multiple deployment characteristics on
> a single system in their designs.
>
> For an application writer to optimize an application to perform well
> on a certain system engraved with its underlying behaviors, it
> requires a deep understanding of the system itself, which is an
> overhead that often requires a lot of time and effort. Moreover, for a
> developer to modify such system behaviors, it requires modifications
> of the system core, which requires an even deeper understanding of the
> system itself.
>
> With this background, Onyx is designed to represent all of 

Re: svn commit: r1809666 - /incubator/public/trunk/content/projects/amaterasu.xml

[Davor Bonaci]

(All done.)

On Mon, Sep 25, 2017 at 1:34 PM, John D. Ament <johndam...@apache.org>
wrote:

> Don't forget to also apply this change to the podling roster.
>
> https://whimsy4.apache.org/roster/ppmc/amaterasu
>
> John
>
> On Mon, Sep 25, 2017 at 4:27 PM <da...@apache.org> wrote:
>
> > Author: davor
> > Date: Mon Sep 25 20:27:05 2017
> > New Revision: 1809666
> >
> > URL: http://svn.apache.org/viewvc?rev=1809666=rev
> > Log:
> > Amaterasu: list davor@ as an incubation mentor
> >
> > Modified:
> > incubator/public/trunk/content/projects/amaterasu.xml
> >
> > Modified: incubator/public/trunk/content/projects/amaterasu.xml
> > URL:
> > http://svn.apache.org/viewvc/incubator/public/trunk/
> content/projects/amaterasu.xml?rev=1809666=1809665=1809666=diff
> >
> > 
> ==
> > --- incubator/public/trunk/content/projects/amaterasu.xml [utf-8]
> > (original)
> > +++ incubator/public/trunk/content/projects/amaterasu.xml [utf-8] Mon
> Sep
> > 25 20:27:05 2017
> > @@ -82,6 +82,11 @@
> >  
> >  
> >.
> > +  davor
> > +  Davor Bonaci
> > +
> > +
> > +  .
> >olamy
> >Olivier Lamy
> >  
> >
> >
> >
> > -
> > To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: cvs-h...@incubator.apache.org
> >
> >
>

Re: [VOTE] Graduate Apache Streams project from Incubator

[Davor Bonaci]

+1

On Mon, Jul 10, 2017 at 1:35 PM, Ate Douma  wrote:

> +1 (binding)
>
> Ate
>
>
> On 2017-07-10 17:09, sblackmon wrote:
>
>>   In concert with the discussion started last week [1], please vote on
>> the draft resolution which establishes Apache Streams as a new top-level
>> project at the Apache Software Foundation, as follows:
>>
>> [ ] +1, Graduate Apache Streams from the Incubator.
>> [ ] +0, Don't care.
>> [ ] -1, Don't graduate Apache Streams from the Incubator (provide details)
>>
>> The full text of the resolution is below.
>>
>> If approved by the Apache Incubator PMC members, the proposed resolution
>> will be submitted to the Board of Directors for their consideration.
>>
>> Thanks !
>>
>> [1] https://lists.apache.org/thread.html/60d676ad7b190323f8479bc
>> cff8ae996f98bf5fcd0d0ff4d54b71006@
>>
>> Establish the Apache Streams 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 interoperability of online profiles and activity feeds.
>>
>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
>> (PMC), to be known as the "Apache Streams Project", be and hereby is
>> established pursuant to Bylaws of the Foundation; and be it further
>>
>> RESOLVED, that the Apache Streams Project be and hereby is responsible
>> for the creation and maintenance of software related to interoperability of
>> online profiles and activity feeds; and be it further
>>
>> RESOLVED, that the office of "Vice President, Apache Streams" 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 Streams Project, and
>> to have primary responsibility for management of the projects within the
>> scope of responsibility of the Apache Streams 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 Streams Project:
>>
>>   * Stephen D Blackmon   
>>   * Robert Baker Douglas 
>>   * Ate Douma
>>   * Ryan Edward Ebanks   
>>   * Matt Franklin
>>   * Joey Frazee  
>>   * Trevor Grant 
>>   * Suneel Marthi
>>
>> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Stephen D Blackmon be
>> appointed to the office of Vice President, Apache Streams, 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 Streams 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 Streams Project; and be it further
>>
>> RESOLVED, that the Apache Streams Project be and hereby is tasked with
>> the migration and rationalization of the Apache Incubator Streams podling;
>> and be it further
>>
>> RESOLVED, that all responsibilities pertaining to the Apache Incubator
>> Streams podling encumbered upon the Apache Incubator PMC are hereafter
>> discharged.
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Graduate Apache Beam

[Davor Bonaci]

This vote is now *cancelled*. Per John's request, the vote is restarted in
a separate thread with clarified alternatives [1].

If you have already voted, please copy-paste your response into the new
thread. I apologize for the trouble!

[1]
https://lists.apache.org/thread.html/2057aab0702f36f366fc7809921a4f87108ba39b951b63598953bc6f@%3Cgeneral.incubator.apache.org%3E

On Mon, Dec 5, 2016 at 1:27 PM, Thomas Weise <t...@apache.org> wrote:

> +1
>
> Thanks,
> Thomas
>
>
> On 2016-12-05 10:28 (-0800), Davor Bonaci <da...@apache.org> wrote:
> > Hi everyone,
> > Please vote to approve/disapprove the draft resolution proposed by the
> > Apache Beam PPMC below, which establishes Apache Beam as a new top-level
> > project at the Apache Software Foundation, as follows:
> >
> > [ ] Approve the proposed resolution
> > [ ] Disapprove the proposed resolution
> >
> > Before voting, please see the corresponding discussion thread [1], and
> vote
> > only after you feel ready to do so. The vote will be open for at least 72
> > hours. This is a procedural vote [2]; it is adopted by a simple majority
> of
> > qualified votes (with no minimum).
> >
> > If approved by the Apache Incubator, the proposed resolution will be
> > submitted to the Board of Directors for their consideration.
> >
> > Thank you!
> >
> > Davor
> >
> > [1]
> > https://lists.apache.org/thread.html/b9c1071b35558846836814575ada3c
> dca61c72dc1e672ab994a9c936@%3Cgeneral.incubator.apache.org%3E
> > [2] http://apache.org/foundation/voting.html
> >
> > The full-text of the draft resolution proposed by the Apache Beam PPMC:
> >
> > X. Establish the Apache Beam 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 unified programming model for both
> >batch and streaming data processing, enabling efficient
> >execution across diverse distributed execution engines
> >and providing extensibility points for connecting to different
> >technologies and user communities.
> >
> >NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> >Committee (PMC), to be known as the "Apache Beam Project",
> >be and hereby is established pursuant to Bylaws of the
> >Foundation; and be it further
> >
> >RESOLVED, that the Apache Beam Project be and hereby is
> >responsible for the creation and maintenance of software
> >related to a unified programming model for both batch and
> >streaming data processing, enabling efficient execution across
> >diverse distributed execution engines and providing extensibility
> >points for connecting to different technologies and user
> >communities; and be it further
> >
> >RESOLVED, that the office of "Vice President, Apache Beam" 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 Beam Project, and to have primary responsibility
> >for management of the projects within the scope of
> >responsibility of the Apache Beam 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 Beam Project:
> >
> >  * Tyler Akidau <taki...@apache.org>
> >  * Davor Bonaci <da...@apache.org>
> >  * Robert Bradshaw <rober...@apache.org>
> >  * Ben Chambers <bchamb...@apache.org>
> >  * Luke Cwik <lc...@apache.org>
> >  * Stephan Ewen <se...@apache.org>
> >  * Dan Halperin <dhalp...@apache.org>
> >  * Kenneth Knowles <k...@apache.org>
> >  * Aljoscha Krettek <aljos...@apache.org>
> >  * Maximilian Michels <m...@apache.org>
> >  * Jean-Baptiste Onofré <jbono...@apache.org>
> >  * Frances Perry <fran...@apache.org>
> >  * Amit Sela <amits...@apache.org>
> >  * Josh Wills <jwi...@apache.org>
> >
> >NOW, THEREFORE, BE IT FURTHER RES

[DISCUSS] Apache Beam podling graduation readiness

[Davor Bonaci]

Hi everyone,
Apache Beam entered incubation in early February. Over the past 10 months,
the podling has made great progress across various areas: refactoring the
project to remove any special treatment given to a runner or a vendor,
building processes that encourage open development, evangelizing the
project, and growing the community.

Now, with the support of our mentors and overwhelming support from the
wider Beam community [1], I’d like start a discussion on the progress we
have made and a possible graduation recommendation as a new top-level
project.

To prepare for the discussion, we have published our self-assessment [2]
against the Apache Maturity Model. We tried to include links and evidence
whenever applicable. I’ll summarize the commonly asked questions here, but
please see the self-assessment for additional information, various details,
graphs, evidence, etc.

> Releases?

Three -- all unanimously approved, all driven by different release
managers, across different organizations. A detailed release guide is
available on the website.

> Community growth?

There has been a clear growth month-over-month. We have had 1500+ pull
requests on GitHub and 110+ individual code contributors. In terms of
mailing list activity, over the past 30 days, we have had 50+ individual
participants on dev@ and 35+ on user@.

> Organizational influence?

We have worked hard to remove any special treatment given to any
organization. The bulk of the initial code donation came from Google, but
now both the project’s code and branding have a clean separation between
the project and Google Cloud Dataflow (which has become just one of many
runners that can be used within Beam).

While it is true that Googlers continue to provide the majority of commits,
over the last three months no single organization has had more than ~50% of
unique monthly contributors. (Please see the graph in the self-assessment.)
Diverse influences are also particularly clear when you look across modules
within the project. Beam has about ~22 large modules in the codebase, at
least 10 modules have been developed with little to no contribution from
Googlers.

Now, if we were to graduate, the Beam PPMC recommends the following
information for the Board resolution:
* Project name: Apache Beam
* Project description and scope: a unified programming model for both
batch and streaming data processing, enabling efficient execution across
diverse distributed execution engines and providing extensibility points
for connecting to different technologies and user communities.
* PMC composition:
 * Tyler Akidau <taki...@apache.org>
     * Davor Bonaci <da...@apache.org>
 * Robert Bradshaw <rober...@apache.org>
 * Ben Chambers <bchamb...@apache.org>
 * Luke Cwik <lc...@apache.org>
 * Stephan Ewen <se...@apache.org>
 * Dan Halperin <dhalp...@apache.org>
 * Kenneth Knowles <k...@apache.org>
 * Aljoscha Krettek <aljos...@apache.org>
 * Maximilian Michels <m...@apache.org>
 * Jean-Baptiste Onofré <jbono...@apache.org>
 * Frances Perry <fran...@apache.org>
 * Amit Sela <amits...@apache.org>
 * Josh Wills <jwi...@apache.org>
(The ratification of the full text of the draft resolution is nearing
completion.)

While we have made great progress across the board (thanks to so many of
you in this community), I’m sure there’s still plenty to do. We continue to
be focused on community growth, and processes that encourage open
development. Regardless of the outcome of this discussion, we’d love to get
specific feedback on what can be improved going forward.

Any thoughts, comments, questions or concerns? Thank you.

Davor

[1]
https://lists.apache.org/thread.html/f133fb6bf2d1851d1bd5880c772e4b050700154fa178fdb00a5b66bf@%3Cdev.beam.apache.org%3E
[2] http://beam.incubator.apache.org/contribute/maturity-model/

[RESULT] [VOTE] Release Apache Beam, version 0.1.0-incubating

[Davor Bonaci]

I'm happy to announce that the Apache Incubator has unanimously approved
this release.

There are 6 approving votes, all of which are binding:
* Sergio Fernández
* Jakob Homan
* Julian Hyde
* Justin Mclean
* Jean-Baptiste Onofré
* Seetharam Venkatesh

There are no disapproving votes.

We'll proceed with this release as staged, and will make sure we address
all feedback before the next release.

Thanks everyone!

On Sat, Jun 11, 2016 at 4:54 PM, Davor Bonaci <da...@google.com> wrote:

> Hi everyone,
> Here's the first vote for the first release of Apache Beam -- version
> 0.1.0-incubating!
>
> The complete staging area is available for your review, which includes:
> * the official Apache source release to be deployed to dist.apache.org [1],
> and
> * all artifacts to be deployed to the Maven Central Repository [2].
>
> This corresponds to the tag "v0.1.0-incubating-RC3" in source control, [3].
>
> The Apache Beam community has unanimously approved this release, [4], [5],
> [6].
>
> Please vote as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
> As customary, the vote will be open for at least 72 hours. It is adopted
> by a majority approval with at least three PMC affirmative votes. If
> approved, we will proceed with the release.
>
> Thanks,
> Davor
>
> [1]
> https://dist.apache.org/repos/dist/dev/incubator/beam/0.1.0-incubating/RC3/
> [2] https://repository.apache.org/content/repositories/orgapachebeam-1002/
> [3] https://github.com/apache/incubator-beam/tree/v0.1.0-incubating-RC3
> [4]
> https://lists.apache.org/thread.html/68bf80b386dde080126b51ddf3497c6801015903a705411d435d64a1@%3Cdev.beam.apache.org%3E
> [5]
> https://lists.apache.org/thread.html/32c991987e0abf2a09cd8afad472cf02e482af02ac35418ee8731940@%3Cdev.beam.apache.org%3E
> [6]
> https://lists.apache.org/thread.html/e6ffcba94ef4514e8cf5c6fed39100ee359b954c4876d3275b1bc33a@%3Cdev.beam.apache.org%3E
>

Re: [VOTE] Release Apache Beam, version 0.1.0-incubating

[Davor Bonaci]

This vote is now complete. We'll summarize the results and next steps in
the [RESULT] thread.

Thanks everyone!

On Mon, Jun 13, 2016 at 12:18 PM, Jakob Homan  wrote:

> +1 (binding)
>
> + sigs look good
> + LICENSE, NOTICE, DISCLAIMER look good
> + licenses in source and xml files look good.
> + tests compile and pass, mvn package compiles
>
> -Jakob
>
> On 13 June 2016 at 12:13, Julian Hyde  wrote:
> >
> >> On Jun 13, 2016, at 12:08 PM, Marvin Humphrey 
> wrote:
> >>
> >> On Mon, Jun 13, 2016 at 11:37 AM, Julian Hyde  wrote:
> >>
> >>> But I imported
> >>>
> https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS
> >>> <
> https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS>
> >>> easily enough.
> >>
> >> Bundling PGP keys inside a package is worse than worthless -- an
> attacker can
> >> just bundle spoofed keys with a bogus distort!
> >
> > My mistake — thanks for the correction!
> >
> > Julian
> >
> >
> > -
> > 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] Release Apache Beam, version 0.1.0-incubating

[Davor Bonaci]

Hi everyone,
Here's the first vote for the first release of Apache Beam -- version
0.1.0-incubating!

The complete staging area is available for your review, which includes:
* the official Apache source release to be deployed to dist.apache.org [1],
and
* all artifacts to be deployed to the Maven Central Repository [2].

This corresponds to the tag "v0.1.0-incubating-RC3" in source control, [3].

The Apache Beam community has unanimously approved this release, [4], [5],
[6].

Please vote as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)

As customary, the vote will be open for at least 72 hours. It is adopted by
a majority approval with at least three PMC affirmative votes. If approved,
we will proceed with the release.

Thanks,
Davor

[1]
https://dist.apache.org/repos/dist/dev/incubator/beam/0.1.0-incubating/RC3/
[2] https://repository.apache.org/content/repositories/orgapachebeam-1002/
[3] https://github.com/apache/incubator-beam/tree/v0.1.0-incubating-RC3
[4]
https://lists.apache.org/thread.html/68bf80b386dde080126b51ddf3497c6801015903a705411d435d64a1@%3Cdev.beam.apache.org%3E
[5]
https://lists.apache.org/thread.html/32c991987e0abf2a09cd8afad472cf02e482af02ac35418ee8731940@%3Cdev.beam.apache.org%3E
[6]
https://lists.apache.org/thread.html/e6ffcba94ef4514e8cf5c6fed39100ee359b954c4876d3275b1bc33a@%3Cdev.beam.apache.org%3E