AW: [QUESTION] Reproducible build for container images

[Christofer Dutz]

HI Alex,

I would like to go even further: Having any form of reproducibility actually 
isn’t a required attribute of any Apache releases (TLP or Podling).

I do think that in the future there will be more strict requirements, however 
currently we don’t have any such rules.

Chris


Von: PJ Fanning 
Datum: Dienstag, 23. Januar 2024 um 15:50
An: general@incubator.apache.org 
Betreff: Re: [QUESTION] Reproducible build for container images
Hi Alex,

While reproducible builds are a great idea, the Incubator PMC does not
require them. Plugging away at improving things so that reproducible
builds can be produced in future is a useful thing to do.

Regards,
PJ

On Tue, 23 Jan 2024 at 14:58, Alex Porcelli  wrote:
>
> In the KIE podling, we regularly publish container images as part of
> our releases. We've achieved semantically identical images, verified
> using the 'diffoci' tool. However, due to current Docker/OCI engine
> limitations, we can't eliminate variations in file metadata caused by
> automatically appended timestamps.
>
> The latest version of Buildkit offers a solution but still needs to be
> integrated into the build engines. I want to ask the Incubator PMC: Is
> achieving semantically verifiable images sufficient for now, as we
> await the integration of Buildkit changes into Docker/OCI build
> engines?
>
> Regards,
> -
> Alex
> Apache KIE PPMC
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

AW: [QUESTION] Handling of licensing issues for dependencies of dependencies

[Christofer Dutz]

You might be lucky, and this third-party dependency might be pulled in, but not 
be required to use the parts of the library you are using in your project. In 
that case a simple “exclusion” could solve the problem.

However, if it’s an essential part of the functionality, I agree with Justin … 
you might need to replace that library.

Also, possibly worth reporting an issue with the library using it to possibly 
replace it with something else, because technically licenses such as GPL are 
infectious. If I depend on a GPL library, I can call it “Apache” as much as I 
like, technically it’s also GPL (I hope that’s correct)

Chris


Von: Justin Mclean 
Datum: Mittwoch, 10. Januar 2024 um 01:26
An: incubator general apache 
Betreff: Re: [QUESTION] Handling of licensing issues for dependencies of 
dependencies
HI,

> I was performing a more thorough check of our dependencies in preparation of 
> opening graduation discussions with the Incubator PMC and found at least one 
> package that, while not directly used in the code, is installed as a 
> dependency of multiple top-level dependencies that is LGPL licensed. The 
> dependencies that rely on this are themselves not a license issue (BSD-3 & 
> MIT licenses). How is this situation usually handled?

You will need to remove or replace that dependency.

> I also found a package that has a license that isn't listed on the 3rd party 
> licenses page: HPND [1][2] which, from what I can tell, is similar to the 
> BSD-3 or MIT licenses, though I just wanted to double-check on that...

HPND looks fine to me, as it could be treated as a BSD-like or MIT-like 
license, depending on what parts you include.

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

[REMINDER] The Apache Answer project has been waiting for votes for quite some time now

[Christofer Dutz]

I tink the subject says it all…

The Apache Answer project has been waiting for votes  way too long … would be 
great, if at least one IPMC member could spare a bit of time to provide the 
missing third vote.

Chris

AW: [VOTE] Release Apache Answer(Incubating) v1.2.1-RC1 (Round2)

[Christofer Dutz]

Oh sorry for the late reply … I must have missed these … sorry,

But I agree with Wilfried … for me these files are just as in other projects a 
maven pom.
A manual decision of the project to what goes in the project. Therefore would I 
also think a header is appropriate. In PLC4Go we have it exactly that way: the 
go.mod has a header and the go.sum doesn’t (It’s actually not even checked in … 
I think)

Chris


Von: tison 
Datum: Mittwoch, 3. Januar 2024 um 10:33
An: general@incubator.apache.org 
Betreff: Re: [VOTE] Release Apache Answer(Incubating) v1.2.1-RC1 (Round2)
> I would agree with adding a header.

Yep it's easily to add one, like what Fury did [1].

> It is maintained mostly by hand

... while I generally just run `go mod tidy` and `go get` to let it
generate the necessary go.mod.

Best,
tison.

[1] https://github.com/apache/incubator-fury/blob/main/go/fury/go.mod

Wilfred Spiegelenburg  于2024年1月3日周三 17:29写道：
>
> On 2024/01/03 08:24:10 tison wrote:
> > > go.mod could have an apache header
> >
> > go.mod doesn't seems something creative but a bookkeeping index. I
> > wonder if we should add license header for such files.
>
> go.mod is part of the project and lists the import and versions. It is 
> maintained mostly by hand, partially via tools (layout and indirect ref etc), 
> I would agree with adding a header.
> go.sum on the other hand is maintained by tools only based on the go.mod 
> content. No header in that file as it causes issues,
>
> Wilfred
>
> >
> > Best,
> > tison.
> >
> > Christofer Dutz  于2024年1月3日周三 16:19写道：
> > >
> > > +1 (binding)
> > >
> > > However, I did find, that it seems to be impossible to build from 
> > > sources, if the sources are unpacked from the src-archive instead of 
> > > checked out. This should be addressed in future releases.
> > >
> > > Chris
> > >
> > > [OK] Download all staged artifacts under the url specified in the release 
> > > vote email.
> > > [OK] Verify the signature is correct.
> > > [OK] Check if the signature references an Apache email address.
> > > [OK] Verify the SHA512 hashes.
> > > [OK] Unzip the archive.
> > > [OK] Verify the artifacts have “apache” and “incubating” in their names
> > > [OK] Verify the existence of LICENSE, NOTICE, README, DISCLAIMER files in 
> > > the extracted source bundle.
> > > [OK] Verify the content of LICENSE, NOTICE, README, DISCLAIMER files in 
> > > the extracted source bundle.
> > >
> > >   *   Using non-WIP disclaimer, doing the thorough checks.
> > >   *   NOTICE contains 2023, but as the RC was created 2023, no issue
> > > [OK] Run RAT externally to ensure there are no surprises.
> > >
> > >   *   go.mod could have an apache header
> > >   *   docs/img/logo.svg could have an apache header
> > >   *   ui/src/assets/images/default-avatar.svg could have an apache header
> > > [OK] Search for SNAPSHOT references
> > > [OK] Search for Copyright references, and if they are in headers, make 
> > > sure these files containing them are mentioned in the LICENSE file.
> > > [MINOR] Build the project according to the information in the README.md 
> > > file.
> > >
> > >   *   Readme could use an addition to add mockgen to the prerequisites
> > >   *   When building the second part “make build” I’m getting a fatal 
> > > error:
> > >  *   “fatal: not a git repository (or any of the parent directories): 
> > > .git”
> > >
> > >
> > > Von: Justin Mclean 
> > > Datum: Mittwoch, 27. Dezember 2023 um 06:26
> > > An: incubator general apache 
> > > Betreff: Re: [VOTE] Release Apache Answer(Incubating) v1.2.1-RC1 (Round2)
> > > Hi,
> > >
> > > +1 (binding)
> > >
> > > In the source release, I checked:
> > > - incubating in artifacts name
> > > - signatures and hashes are correct
> > > - LICENSE and NOTICE are fine
> > > - DISCLAIMER exists
> > > - all files have ASF headers
> > > - no unexpected binary files
> > > - my system isn't setup to compile it
> > >
> > > In the REDME.md it suggests that people run the latest non-released 
> > > version; please don't do this. [1]
> > >
> > > Kind Regards,
> > > Justin
> > >
> > > 1. https://www.apache.org/legal/release-policy.html#what
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

AW: [VOTE] Release Apache Answer(Incubating) v1.2.1-RC1 (Round2)

[Christofer Dutz]

+1 (binding)

However, I did find, that it seems to be impossible to build from sources, if 
the sources are unpacked from the src-archive instead of checked out. This 
should be addressed in future releases.

Chris

[OK] Download all staged artifacts under the url specified in the release vote 
email.
[OK] Verify the signature is correct.
[OK] Check if the signature references an Apache email address.
[OK] Verify the SHA512 hashes.
[OK] Unzip the archive.
[OK] Verify the artifacts have “apache” and “incubating” in their names
[OK] Verify the existence of LICENSE, NOTICE, README, DISCLAIMER files in the 
extracted source bundle.
[OK] Verify the content of LICENSE, NOTICE, README, DISCLAIMER files in the 
extracted source bundle.

  *   Using non-WIP disclaimer, doing the thorough checks.
  *   NOTICE contains 2023, but as the RC was created 2023, no issue
[OK] Run RAT externally to ensure there are no surprises.

  *   go.mod could have an apache header
  *   docs/img/logo.svg could have an apache header
  *   ui/src/assets/images/default-avatar.svg could have an apache header
[OK] Search for SNAPSHOT references
[OK] Search for Copyright references, and if they are in headers, make sure 
these files containing them are mentioned in the LICENSE file.
[MINOR] Build the project according to the information in the README.md file.

  *   Readme could use an addition to add mockgen to the prerequisites
  *   When building the second part “make build” I’m getting a fatal error:
 *   “fatal: not a git repository (or any of the parent directories): .git”


Von: Justin Mclean 
Datum: Mittwoch, 27. Dezember 2023 um 06:26
An: incubator general apache 
Betreff: Re: [VOTE] Release Apache Answer(Incubating) v1.2.1-RC1 (Round2)
Hi,

+1 (binding)

In the source release, I checked:
- incubating in artifacts name
- signatures and hashes are correct
- LICENSE and NOTICE are fine
- DISCLAIMER exists
- all files have ASF headers
- no unexpected binary files
- my system isn't setup to compile it

In the REDME.md it suggests that people run the latest non-released version; 
please don't do this. [1]

Kind Regards,
Justin

1. https://www.apache.org/legal/release-policy.html#what

AW: [VOTE] Release Apache Answer(Incubating) v1.2.0-RC1

[Christofer Dutz]

Would be cool, if one more IPMC member would be willing to give this release a 
vote…. Admittedly it’s in really good shape and therefore just a minimal bit of 
work.

Chris


Von: Feng Dong 
Datum: Dienstag, 28. November 2023 um 10:41
An: general@incubator.apache.org 
Betreff: Re: [VOTE] Release Apache Answer(Incubating) v1.2.0-RC1
+1 (non-binding)

On Mon, Nov 20, 2023 at 5:31 PM Christofer Dutz 
wrote:

> +1 (binding)
>
> Chris
>
> [OK] Download all staged artifacts under the url specified in the release
> vote email.
> [OK] Verify the signature is correct.
> [OK] Check if the signature references an Apache email address.
> [OK] Verify the SHA512 hashes.
> [OK] Unzip the archive.
> [OK] Verify the existence of LICENSE, NOTICE, DISCLAIMER, README files in
> the extracted source bundle.
> [OK] Verify the content of LICENSE, NOTICE, DISCLAIMER, README files in
> the extracted source bundle.
>
>   *   No WIP disclaimer, doing full checks.
> [OK] Run RAT externally to ensure there are no surprises.
> [OK] Search for Copyright references, and if they are in headers, make
> sure these files containing them are mentioned in the LICENSE file.
> [SKIPPED] Build the project according to the information in the README.md
> file.
>   - No guides on how to build the project
>
>
> Von: Justin Mclean 
> Datum: Sonntag, 19. November 2023 um 22:46
> An: incubator general apache 
> Betreff: Re: [VOTE] Release Apache Answer(Incubating) v1.2.0-RC1
> Hi,
>
> +1 (binding) - carrying over my vote from the dev list.
>
> Kind Regards,
> Justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

AW: [VOTE] Release Apache Answer(Incubating) v1.2.0-RC1

[Christofer Dutz]

+1 (binding)

Chris

[OK] Download all staged artifacts under the url specified in the release vote 
email.
[OK] Verify the signature is correct.
[OK] Check if the signature references an Apache email address.
[OK] Verify the SHA512 hashes.
[OK] Unzip the archive.
[OK] Verify the existence of LICENSE, NOTICE, DISCLAIMER, README files in the 
extracted source bundle.
[OK] Verify the content of LICENSE, NOTICE, DISCLAIMER, README files in the 
extracted source bundle.

  *   No WIP disclaimer, doing full checks.
[OK] Run RAT externally to ensure there are no surprises.
[OK] Search for Copyright references, and if they are in headers, make sure 
these files containing them are mentioned in the LICENSE file.
[SKIPPED] Build the project according to the information in the README.md file.
  - No guides on how to build the project


Von: Justin Mclean 
Datum: Sonntag, 19. November 2023 um 22:46
An: incubator general apache 
Betreff: Re: [VOTE] Release Apache Answer(Incubating) v1.2.0-RC1
Hi,

+1 (binding) - carrying over my vote from the dev list.

Kind Regards,
Justin

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

Re: [VOTE] Accept Answer into the Apache Incubator

[Christofer Dutz]

+1 (binding)

Chris

Gesendet von Outlook für Android

From: Uma Maheswara Rao Gangumalla 
Sent: Tuesday, October 3, 2023 3:50:39 AM
To: general@incubator.apache.org 
Subject: Re: [VOTE] Accept Answer into the Apache Incubator

+1 (binding)

Regards,
Uma

On Mon, Oct 2, 2023 at 5:17 PM Willem Jiang  wrote:

> Following up the [DISCUSS] thread on Answer [1] I would like to call a
> VOTE to accept into the Apache Incubator.
>
> Answer is a question-and-answer (Q) platform software for teams at
> any scale to build a help center, knowledge base, community forum,
> etc.
>
> Please cast your vote:
>
>   [ ] +1, bring into the Incubator
>   [ ] +0, I don't care either way
>   [ ] -1, do not bring Answer into the Incubator, because...
>
> The vote will open at least for 72 hours and only votes from the
> Incubator PMC are binding, but votes from everyone are welcome.
>
> Please check out the Answer Proposal from the incubator wiki[2].
>
> [1]https://lists.apache.org/thread/42tvz3rqfy4w5poqgslh71sm1o1td7zn
> [2]https://cwiki.apache.org/confluence/display/INCUBATOR/Answer+Proposal
>
> Best Regards,
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

AW: [VOTE] Release Apache Wayang (Incubating) v0.7.1 RC3

[Christofer Dutz]

Well … carrying mine over as well:

+1 (binding)

Chris


Von: Alexander Alten-Lorenz 
Datum: Montag, 11. September 2023 um 13:48
An: general@incubator.apache.org 
Betreff: Re: [VOTE] Release Apache Wayang (Incubating) v0.7.1 RC3
Hi,

Carry my vote over.

+1 (non-binding)

—Alexander

> On 9. Sep 2023, at 19:18, Gláucia Esppenchutz  wrote:
>
> Hello everyone,
>
> This calls for a vote to release Release Apache Wayang (Incubating) v0.7.1
> RC3.
> The Apache Wayang voted on and approved a proposal to release Apache Wayang
> (Incubating) version v0.7.1 RC3.
>
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
>
> Community vote thread:
>
> https://lists.apache.org/thread/c6d59nfmjq4gs2sfhh1n5gf4c6hxy5vb
>
> Community vote result thread:
>
> https://lists.apache.org/thread/hlc0dh2mwbpwmd9oc1s1oh7l7lj7od36
>
> The release candidates:
>
> https://dist.apache.org/repos/dist/dev/incubator/wayang/0.7.1/rc3/
>
> Git tag for the release:
>
> https://github.com/apache/incubator-wayang/tree/wayang-0.7.1
>
> Keys to verify the Release Candidate:
>
> https://downloads.apache.org/incubator/wayang/KEYS
>
> How to build:
>
> https://github.com/apache/incubator-wayang/tree/wayang-0.7.1#building
>
> The vote will be open for at least 72 hours or until the necessary number
> of votes are reached.
>
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> --
> Gláucia Esppenchutz


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

AW: Little "upsie" at the Wayang podling

[Christofer Dutz]

(Also fixed what my mail client thought I wanted to say, to what I said in the 
subject ;-) )

And I think the main problem with the leftpad was the general usage of the 
Maven equivalent of “LATEST” as a dependency version.
So, anyone with a LATEST dependency that has built today, will have the 0.7.0 
version everyone with a sensible build management won’t be affected.

Alternatively, most things that caused me to vote -1 actually don’t have an 
effect on the produced binaries.
It was mostly stuff that applies for the source-distribution.
So, I would in this case be in favor that they stage a new release candidate 
for 0.7.0, release that, and simply drop the nexus repo instead of re-releasing 
it.

Chris

Von: PJ Fanning 
Datum: Dienstag, 25. Juli 2023 um 14:54
An: general@incubator.apache.org 
Betreff: Re: Little "upside" at the Wayang podling
The difference here is that this release has just been made and has
only been announced on the Wayang dev list. I find no evidence of it
on the Wayang web site nor in the Apache announce mailing list.

I understand the leftpad case but I don't think this is a similar
case. Users who have upgraded to Wayang 0.7.0 can downgrade to Wayang
0.6.0.

On Tue, 25 Jul 2023 at 13:19, tison  wrote:
>
> >So I guess we have to check how we can remove the artifacts.
>
> A central repository should not _remove_ artifacts. Rust's cargo crate can
> mark as yanked and prevent further dependent but remain all the existing
> one. Revoke artifacts can cause significant downstream effect - you may
> take leftpad on npmjs as an example.
>
> Best,
> tison.
>
>
> Christofer Dutz  于2023年7月25日周二 19:14写道：
>
> > Hi PJ,
> >
> > Unfortunately, I had to vote -1 on the release and there’s no way on earth
> > it would pass Justin ;-) …
> > So, there will be another one.
> >
> > So I guess we have to check how we can remove the artifacts.
> >
> > Chris
> >
> >
> > Von: PJ Fanning 
> > Datum: Dienstag, 25. Juli 2023 um 11:47
> > An: general@incubator.apache.org 
> > Betreff: Re: Little "upside" at the Wayang podling
> > It does seem like a good idea to do a 2 phase release to the Apache Nexus
> > Repository. I think a lot of Apache projects use that approach. It means
> > that the binary artifacts can be checked during the release voting along
> > side the source release. Nexus allows you the drop the artifacts or to
> > release them and this can be a good way to handle unsuccessful and
> > successful release votes (respectively).
> >
> > It might make sense to bring the 0.7.0 release to an Incubator vote and if
> > it passes then there isn't much harm. The Wayang team have announced this
> > release on their dev mailing list but don't appear to have updated their
> > download page [1] yet. Could we get them to respond to all the announcement
> > emails to say that release vote is not yet complete and to ask people not
> > use this release until the vote is finished?
> >
> > If the Incubator vote fails, I'm not sure but it may be feasible to see if
> > the Maven team can remove the 0.7.0 artifacts.
> >
> > [1] https://wayang.apache.org/download/
> >
> > On 2023/07/25 09:28:00 Christofer Dutz wrote:
> > > Hi all,
> > >
> > > yesterday the Wayang podling was following the “release documentation”
> > of a TLP and “forgot” to do the round over the IPMC.
> > > However, they’ve already moved things to the release distro area (from
> > where they’ve removed it after me contacting them) but in Nexus they
> > clicked on “release” and the artifacts are out in the wild.
> > >
> > > How to generally deal with this situation? I think in general it would
> > be good, if releasing maven artifacts in Nexus was a two step thing … a)
> > the project clicks on “release” and then an IPMC member has to confirm that.
> > >
> > > Chris
> > >
> > >
> >
> > -
> > 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

AW: Little "upside" at the Wayang podling

[Christofer Dutz]

Hi PJ,

Unfortunately, I had to vote -1 on the release and there’s no way on earth it 
would pass Justin ;-) …
So, there will be another one.

So I guess we have to check how we can remove the artifacts.

Chris


Von: PJ Fanning 
Datum: Dienstag, 25. Juli 2023 um 11:47
An: general@incubator.apache.org 
Betreff: Re: Little "upside" at the Wayang podling
It does seem like a good idea to do a 2 phase release to the Apache Nexus 
Repository. I think a lot of Apache projects use that approach. It means that 
the binary artifacts can be checked during the release voting along side the 
source release. Nexus allows you the drop the artifacts or to release them and 
this can be a good way to handle unsuccessful and successful release votes 
(respectively).

It might make sense to bring the 0.7.0 release to an Incubator vote and if it 
passes then there isn't much harm. The Wayang team have announced this release 
on their dev mailing list but don't appear to have updated their download page 
[1] yet. Could we get them to respond to all the announcement emails to say 
that release vote is not yet complete and to ask people not use this release 
until the vote is finished?

If the Incubator vote fails, I'm not sure but it may be feasible to see if the 
Maven team can remove the 0.7.0 artifacts.

[1] https://wayang.apache.org/download/

On 2023/07/25 09:28:00 Christofer Dutz wrote:
> Hi all,
>
> yesterday the Wayang podling was following the “release documentation” of a 
> TLP and “forgot” to do the round over the IPMC.
> However, they’ve already moved things to the release distro area (from where 
> they’ve removed it after me contacting them) but in Nexus they clicked on 
> “release” and the artifacts are out in the wild.
>
> How to generally deal with this situation? I think in general it would be 
> good, if releasing maven artifacts in Nexus was a two step thing … a) the 
> project clicks on “release” and then an IPMC member has to confirm that.
>
> Chris
>
>

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

Little "upside" at the Wayang podling

[Christofer Dutz]

Hi all,

yesterday the Wayang podling was following the “release documentation” of a TLP 
and “forgot” to do the round over the IPMC.
However, they’ve already moved things to the release distro area (from where 
they’ve removed it after me contacting them) but in Nexus they clicked on 
“release” and the artifacts are out in the wild.

How to generally deal with this situation? I think in general it would be good, 
if releasing maven artifacts in Nexus was a two step thing … a) the project 
clicks on “release” and then an IPMC member has to confirm that.

Chris

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

[Christofer Dutz]

Hi Tison,

well with most projects that use Maven as distribution chanel, the RC artifacts 
are in a staging repo in Nexus. If the vote fails, then this repo is dropped 
and nothing is released to the outside world. If it passes, we click on 
"release" and the artifacts are released to the outside world.

And just because some projects do something in a certain way, doesn't always 
imply that this is the right way to do things. 

I personally have come across several Apache projects, that are not doing 
things according to Apache policies and that need to change some parts of what 
they are doing. 

But as I mentioned, currently we're internally discussing how to deal with 
binary releases for various reasons ... because till now officially we only 
have source releases and convenience binaries. 


Chris



Am 04.07.23, 13:55 schrieb "tison" mailto:wander4...@gmail.com>>:


> if It's ok to still publish RCs without a vote


I think we vote for RCs so we always provide RCs without a vote. At least
it's what I'm experiencing among Flink, Pulsar, and so on.


Best,
tison.




Christofer Dutz mailto:christofer.d...@c-ware.de>> 
于2023年7月4日周二 19:52写道：


> Hi Tison,
>
> Well, it definitely is better than without, however I am still not sure,
> if It's ok to still publish RCs without a vote.
> Currently there's quite a bit of discussion on the matter of releasing
> binary artifacts, so I would call this part a bit in flux right now.
>
> But hopefully someone else will be able to provide more information on
> this.
>
> Chris
>
>
>
> Am 04.07.23, 13:48 schrieb "tison"  <mailto:wander4...@gmail.com>  wander4...@gmail.com <mailto:wander4...@gmail.com>>>:
>
>
> Hi Chris.
>
>
> 1. Is -rc suffix a satisfied alternative to you?
> 2. This can be part of binary release topics. I read our policy to release
> sources only so I don't push an alert for doing so. But I do assume -rc
> suffix could be an improvement before the podling getting graduated.
>
>
> Best,
> tison.
>
>
>
>
> Christofer Dutz mailto:christofer.d...@c-ware.de> 
>  christofer.d...@c-ware.de <mailto:christofer.d...@c-ware.de>>> 于2023年7月4日周二 
> 19:45写道：
>
>
> > Hi all,
> >
> > I don't think this procedure is ok according to our policies.
> >
> > Simply not listing a release on the project page will not help anyone
> > using this as a dependency.
> >
> > At least, every time I update a dependency, I never check the projects
> > page, if this is even a released version.
> >
> > Chris
> >
> >
> >
> > Am 04.07.23, 13:37 schrieb "tison"  > <mailto:wander4...@gmail.com>  wander4...@gmail.com <mailto:wander4...@gmail.com>>  > wander4...@gmail.com <mailto:wander4...@gmail.com> 
> > <mailto:wander4...@gmail.com <mailto:wander4...@gmail.com>>>>:
> >
> >
> > Here are four workflows to release Rust, Node.js, Python and Ruby
> libraries
> > to their conventional repository.
> >
> >
> > 1. Rust Cargo -
> >
> >
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
>  
> <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
>  
> <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
>  
> <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
>  
> <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> >
> > >
> > 2. Python PyPi -
> >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
>  
> <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
>  
> <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml>
> >
> > <
> >
> https://github.com/apache/incubator-opendal/b

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

[Christofer Dutz]

Hi Tison,

Well, it definitely is better than without, however I am still not sure, if 
It's ok to still publish RCs without a vote.
Currently there's quite a bit of discussion on the matter of releasing binary 
artifacts, so I would call this part a bit in flux right now.

But hopefully someone else will be able to provide more information on this.

Chris



Am 04.07.23, 13:48 schrieb "tison" mailto:wander4...@gmail.com>>:


Hi Chris.


1. Is -rc suffix a satisfied alternative to you?
2. This can be part of binary release topics. I read our policy to release
sources only so I don't push an alert for doing so. But I do assume -rc
suffix could be an improvement before the podling getting graduated.


Best,
tison.




Christofer Dutz mailto:christofer.d...@c-ware.de>> 
于2023年7月4日周二 19:45写道：


> Hi all,
>
> I don't think this procedure is ok according to our policies.
>
> Simply not listing a release on the project page will not help anyone
> using this as a dependency.
>
> At least, every time I update a dependency, I never check the projects
> page, if this is even a released version.
>
> Chris
>
>
>
> Am 04.07.23, 13:37 schrieb "tison"  <mailto:wander4...@gmail.com>  wander4...@gmail.com <mailto:wander4...@gmail.com>>>:
>
>
> Here are four workflows to release Rust, Node.js, Python and Ruby libraries
> to their conventional repository.
>
>
> 1. Rust Cargo -
>
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
>  
> <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
>  
> <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> >
> 2. Python PyPi -
>
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
>  
> <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
>  
> <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml>
> >
> 3. Ruby Gems -
>
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
>  
> <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
>  
> <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml>
> >
> 4. Node.js npm -
>
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
>  
> <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
>  
> <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml>
> >
>
>
> All of them, different from the Apache Maven Nexus repository, are
> maintained by third-party platforms. So we request a token and share it
> among the Podling PMC via 1Password (a free team provision provided by the
> team[1]).
>
>
> > revoked
>
>
> For the source releases, if the vote failed, it won't be copied to the
> release svn directory.
>
>
> For the binary releases, although all of these platforms should support -rc
> in version tag, we release an X.Y.Z for each candidate and leave it there
> if vote failed. The version won't be listed at the official page[2].
>
>
> I ever advice the PPMC that using a -rc suffix would be better but they use
> this way now for convenient development. As you can see, the version number
> is 0.X so users should already use it at their risk. If it's requested, I
> believe the PPMC would be glad to add a notice for which ones are Apache
> voted releases or use a different version tag strategy to distinguish that.
> There should not be any blocker technically.
>
>
> OpenDAL has a release document[3] that you can refer to and do not hesitate
> to open an issue if you find anything is unclear or unexpected.
>
>
> Best,
> tison.
>
>
> [1] https://github.com/1Password/1password-teams-open-source/pull/742 
> <https://github.com/1Password/1password-teams-open-source/pull/742> <
> https://github.com/1Password/1password-teams-open-source/pull/742> 
> <https://git

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

[Christofer Dutz]

Hi all,

I don't think this procedure is ok according to our policies.

Simply not listing a release on the project page will not help anyone using 
this as a dependency.

At least, every time I update a dependency, I never check the projects page, if 
this is even a released version.

Chris



Am 04.07.23, 13:37 schrieb "tison" mailto:wander4...@gmail.com>>:


Here are four workflows to release Rust, Node.js, Python and Ruby libraries
to their conventional repository.


1. Rust Cargo -
https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
 

2. Python PyPi -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
 

3. Ruby Gems -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
 

4. Node.js npm -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
 



All of them, different from the Apache Maven Nexus repository, are
maintained by third-party platforms. So we request a token and share it
among the Podling PMC via 1Password (a free team provision provided by the
team[1]).


> revoked


For the source releases, if the vote failed, it won't be copied to the
release svn directory.


For the binary releases, although all of these platforms should support -rc
in version tag, we release an X.Y.Z for each candidate and leave it there
if vote failed. The version won't be listed at the official page[2].


I ever advice the PPMC that using a -rc suffix would be better but they use
this way now for convenient development. As you can see, the version number
is 0.X so users should already use it at their risk. If it's requested, I
believe the PPMC would be glad to add a notice for which ones are Apache
voted releases or use a different version tag strategy to distinguish that.
There should not be any blocker technically.


OpenDAL has a release document[3] that you can refer to and do not hesitate
to open an issue if you find anything is unclear or unexpected.


Best,
tison.


[1] https://github.com/1Password/1password-teams-open-source/pull/742 

[2] https://opendal.apache.org/download 
[3] https://opendal.apache.org/docs/contributing/release 







PJ Fanning mailto:fannin...@gmail.com>> 于2023年7月4日周二 
19:17写道：


> Hi Tison,
>
> Would it be possible to provide us with links to documentation about
> how you deploy your binary artifacts and how they can be revoked if a
> vote fails?
>
> I think this is useful for IPMC members when they are reviewing your
> release candidates. It's nice to review the binaries as well as the
> source artifacts, even if the source artifacts are the main point of
> the vote.
>
> When staging RCs for review, I tend to use
> * dist.apache.org (this is where the source artifacts go anyway)
> * repository.apache.org (jars)
>
> Files on dist.apache.org can be deleted when votes fail.
> With repository.apache.org, the release is a 2 phase process. You
> first push to 'staging' and then you can use its Nexus UI to drop or
> release the staged artifacts after the vote.
>
> OpenDAL is mainly in Rust but you also have a large number of language
> bindings (see libraries list [1]), existing and planned. So
> presumably, you are using a large number of different packaging tools
> for your binary releases. Many of us in the IPMC would not be familiar
> with all these packaging tools.
>
> You may already have documentation and if so, could you share a link?
>
> If there is no shareable documentation, would you be able to tell us
> which Crate Registry do you use for your RC Rust binaries? Do we have
> a custom registry that allows us to remove the binaries for releases
> that fail?
>
> Any information would be appreciated.
>
> Regards,
> PJ
>
> [1] https://github.com/apache/incubator-opendal 
> 
>




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

Re: do we need to go through an Incubator PMC for a build tool?

[Christofer Dutz]

Hi all,

in PLC4X we have a maven-plugin that we use to generate code for PLC4X itself. 
In order to avoid super-messy releases, we have that plugin and similar 
build-tools in a separate repo.
This is released using the normal release process. 

It does help however to cut the build-tools to work in a modular way, so while 
our code-generator plugin is in the build-tools, the templates themselves are 
in the main repo. This reduces the frequency in which we need releases of the 
tools dramatically. So having the plugin look for templates in the runtime 
classpath of the module, makes the build super-easy.

Perhaps something worth considering.

But yes: If you want the artifacts in Maven-Central, then you'll need a full 
release cycle.

You could probably however stage a RC in repository.apache.org and close it. 
Then you get a temporary maven repo URL. If you then add this url to the 
project, so Maven/SBT is able to use that, and then you could create and stage 
an RC for the main project in parallel ... you would then have two closed repos 
in Nexus and could do the vote on both artifacts in one round. If the vote 
passes, then you simply release both repositories.

Chris


Am 04.07.23, 13:22 schrieb "Ryan Skraba" mailto:rskr...@apache.org>>:


Hello! I think, in principle, the vote is the right thing to do. Is
this artifact likely to change frequently? My experience with sbt
plugins is that they are usually pretty tightly integrated with the
projects that depend on them. If this is the case you might want to
have it released at the same cadence as the projects that are using it
(i.e. validated with the project that uses it). I know this is tricky
with sbt.


In any case, I can definitely be more present for validating these
releases and getting these through. The "incubator process" shouldn't
prevent you from doing the right thing for your project and community!


All my best, Ryan










On Tue, Jul 4, 2023 at 11:52 AM PJ Fanning mailto:fannin...@gmail.com>> wrote:
>
> Thanks Claude but I am not familiar with the terminology of 'Petri
> route'. Would you be able to provide more detail?
>
> So far based on the existing feedback - the aim is to just set up an
> RC for this component and go through the regular voting process on it.
> A Pekko community discussion and vote followed by an Incubator team
> vote.
>
>
> On Tue, 4 Jul 2023 at 10:44, Claude Warren  > wrote:
> >
> > You could try the Petri route if the devs are ASF members.
> >
> > On Mon, Jul 3, 2023 at 5:12 PM Sheng Wu  > > wrote:
> >
> > > Hi
> > >
> > > If we want that jar under asf package on maven central, yes, a new version
> > > is required a vote on dev first, then incubator.
> > > Meanwhile, if we have all mentors(ipmc members as well) voted, we just
> > > need to carry votes to incubator mail list, and another 3 days.
> > >
> > > Just one thing, if the jar has dependencies, we need to check license
> > > compatibility.
> > >
> > > PJ Fanning mailto:fannin...@gmail.com>>于2023年7月3日 
> > > 周一17:06写道：
> > >
> > >> Adding the Pekko mentors to the thread if that's ok.
> > >>
> > >> It's not a blocker for us to use a snapshot version of the
> > >> Pekko-specific build tool but it would be tidier if we could release a
> > >> stable version to Maven Central. If this requires us to release a
> > >> source artifact via the full voting procedure then that is fine. I
> > >> just want to make sure that this is a necessary step before going that
> > >> route.
> > >>
> > >> On Wed, 28 Jun 2023 at 18:38, PJ Fanning  > >> > wrote:
> > >> >
> > >> > Hi everyone,
> > >> >
> > >> > The Apache Pekko community has a tool that is used as part of building
> > >> > our web site [1].
> > >> > sbt-paradox-pekko [2] applies the theme to the Pekko web site. It is
> > >> > not useful for outside users.
> > >> > We require that a Java/Scala jar is published because this tool is
> > >> > used in a number of different Pekko projects (ie different Apache git
> > >> > repos that the Pekko team maintain).
> > >> > We haven't yet released an official 1.0.0 jar and are using a snapshot
> > >> jar.
> > >> > If we wanted to publish an official 1.0.0 jar, would we need to have
> > >> > an Incubator PMC vote on it. We will have a Pekko discussion and
> > >> > possibly a vote if it seems appropriate.
> > >> >
> > >> > Any insights would be appreciated.
> > >> >
> > >> > Regards,
> > >> > PJ
> > >> >
> > >> > [1] https://pekko.apache.org 
> > >> > [2] https://github.com/apache/incubator-pekko-sbt-paradox 
> > >> > 
> > >>
> > > --
> > > Sheng Wu 吴晟
> > >
> > > Apache SkyWalking
> > > Apache Incubator
> > > Apache ShardingSphere, ECharts, DolphinScheduler podlings
> > > Zipkin
> > > Twitter, wusheng1108
> > >


-
To unsubscribe, e-mail: 

AW: AW: [DISCUSS] Graduate Apache DataLab (Incubating) as a Top Level Project

[Christofer Dutz]

Hi Ruslan,

thanks for clarifying that … well Apache Jira is absolutely ok in that case.

However, I did look into your list in order to check what was up with the PPMC 
member removal and I find this really odd.
There was a discussion on the private list about removing a PPMC member because 
he is involved in another project.
First off all … I would assume 90% of all Incubator mentors are involved in 
more than one project here, so that’s a realy strange reason for proposing to 
remove someone.

I would really like to hear his side of the story … because I think there 
probably is a story … considering that you are willing to keep people in the 
PPMC/PMC that don’t even actively contribute code at all.

I did a quick check, and he did indeed stop contributing in 2017, however for 
bhliva and OlehMartushevskyi I have nothing on file, dzenbuddiii and 
VadymKuznetsov seem to also have stopped contributing code in 2017, ioleksandr 
stopped contributing in 2019.
So why remove only him?

When looking for his contributions (cause it seems he’s also no longer a 
committer … or never was), I noticed the last commit having been done in early 
February and commit activity in general has dropped to almost 0 … it seems 
other IPMC members have also noticed that and your response was, that 
development is happening in peoples branches … however 
https://github.com/apache/incubator-datalab/branches
Shows that the epm-v2.5.2.1 branch was the last one to be updated and that was 
2 months ago … “master” was even last updated 4 months ago.

So, are you referring to people working on datalab in their own forks? But 
https://github.com/apache/incubator-datalab/forks?include=active=1=2y_by=last_updated
doesn’t seem to be confirming this. I can see that there are 2 forks on which 
something is happening … one seems to be a repo in which someone is running a 
dependency update bot, and only one with active work (Guess that’s the new 
committer prospect).

So … the more I look, the more the project feels aiming for retirement more 
than for graduation. (Not implying it should retire)

Chris




Von: Ruslan Kulynych 
Datum: Freitag, 9. Juni 2023 um 11:56
An: general@incubator.apache.org 
Betreff: Re: AW: [DISCUSS] Graduate Apache DataLab (Incubating) as a Top Level 
Project
Hi,

I apologize for the misunderstanding.
By 'centralized project management system,' we mean  ASF Jira. We do not use 
any other project management systems.
Link to Jira: 
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=307=DATALAB=planning=100

Thanks.

Best regards,
Ruslan Kulynych

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

AW: [DISCUSS] Graduate Apache DataLab (Incubating) as a Top Level Project

[Christofer Dutz]

Hi all,

let me jump into this too …

First of all, the “centralized project management system” sort of triggered me 
at first and it seems Justin feels the same way.
Is this system available someehre? If not, using this has to stop and 
“management” has to be moved to the email lists.

A pretty common way to generally handle the transition to TLP, is to do a 
role-call … simply ask on your private list, who of the current PPMC members 
wants to be part of the new PMC. This usually skims off the people that have 
become inactive and the ones not signed up to the private list (which also 
should not happen). I would assume a large number of the non-contributing folks 
will be removed by this and hereby reducing Justin’s reluctance to vote +1.

If a PPMC member whishes to be removed, this must be on file on one of your 
Mailing-lists. Everything else is not in line with ASF policy.


Chris


Von: Justin Mclean 
Datum: Donnerstag, 8. Juni 2023 um 14:30
An: incubator general apache 
Betreff: Re: [DISCUSS] Graduate Apache DataLab (Incubating) as a Top Level 
Project
Hi,

I'm sorry, but your response raises further concerns:
- Project communication need to occur on the mailing list, not on other 
channels.
- The "centralized project management system" doesn't seem visible to people 
outside the project. ASF projects need to operate openly and transparently.
- All ASF project participants are volunteers. There's not an assigned group of 
reviewers.
- Removing a PPMC member was not in line with ASF policy.
- No answer was given why PMC members who have not contributed to the project 
should be included in the PMC list.

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

AW: ASF Maven credential in a project-wise token?

[Christofer Dutz]

Hi,

and sorry for the late response.

Assuming it’s a Maven build, that you’re talking about.

The Jenkins machines (at least the ones labeled “ubuntu”) have maven 
credentials available in their settings.xml.
However, for the build to pick them up it’s important that you didn’t change 
the names of the repository ids.
So, if you correctly set the most recent apache parent as parent of your 
project, this should be setup automatically.

Then it’s as simple as doing a “mvn deploy” on Jenkins.

Hope that helps.


Chris



Von: tison 
Datum: Montag, 29. Mai 2023 um 11:05
An: general@incubator.apache.org , 
d...@opendal.apache.org 
Betreff: Re: ASF Maven credential in a project-wise token?
Thanks for your reference, Martin!

cc dev@opendal.a.o - I'm going to open a branch on the upstream repo to
verify this setting when I find some time.

Best,
tison.


Martin Grigorov  于2023年5月29日周一 16:21写道：

> Hi,
>
> Here is a setup using username and password provided by the Infra team -
>
> https://github.com/apache/avro/blob/0be01a58bd7586982953dda45d53ac3551c7b6c4/.github/workflows/java-publish-snapshot.yml#L56-L62
>
>  - name: Deploy Maven snapshots
> env:
>   ASF_USERNAME: ${{ secrets.NEXUS_USER }}
>   ASF_PASSWORD: ${{ secrets.NEXUS_PW }}
> run: |
>   echo
>
> "apache.snapshots.https$ASF_USERNAME$ASF_PASSWORD"
> > settings.xml
>   mvn --settings settings.xml -U -B -e -fae -ntp -DskipTests deploy
>
> I am not sure whether those are available per project or globally for the
> 'apache' Github organization.
> Try it and if it fails then contact the Infra team to add them for your
> project.
>
> On Sat, May 27, 2023 at 6:19 AM tison  wrote:
>
> > Hi Christofer,
> >
> > Thanks for your reply! Two questions here:
> >
> > 1. Are there instructions to set up such Jenkins workflow? I remember
> that
> > the last few time I try to set up a hello-world workflow for another ASF
> > project but fail to get it right. I read some of the INFRA pages but
> still
> > I don't know how to create a project and how to properly configure the
> > workflow.
> >
> > > the credentials are there
> >
> > 2. Who's credentials?
> >
> > Best,
> > tison.
> >
> >
> > Christofer Dutz  于2023年5月27日周六 05:08写道：
> >
> > > If you run the build on asf Jenkins the credentials are there. You just
> > > need to inherit from the latest apache pom and it should work.
> > >
> > > Chris
> > >
> > > Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> > > 
> > > From: tison 
> > > Sent: Friday, May 26, 2023 1:33:29 PM
> > > To: Maven Developers List ; Incubator <
> > > general@incubator.apache.org>
> > > Subject: ASF Maven credential in a project-wise token?
> > >
> > > Hi,
> > >
> > > I'm configuring tokens for automatically deploying artifacts to the ASF
> > > snapshot repository[1].
> > >
> > > It requires configuring a user token to auth to the repository.
> Although
> > > I'm wondering if I must use my personal token or if there is some
> > > project-wise token to use. Even asking for an INFRA member to help
> > > configure, passing over a personal token to another one increases the
> > risk.
> > >
> > > Best,
> > > tison.
> > >
> > > [1]
> > >
> >
> https://github.com/tisonkun/opendal/actions/runs/5090173050/workflow#L129
> > >
> >
>

Re: ASF Maven credential in a project-wise token?

[Christofer Dutz]

If you run the build on asf Jenkins the credentials are there. You just need to 
inherit from the latest apache pom and it should work.

Chris

Gesendet von Outlook für Android

From: tison 
Sent: Friday, May 26, 2023 1:33:29 PM
To: Maven Developers List ; Incubator 

Subject: ASF Maven credential in a project-wise token?

Hi,

I'm configuring tokens for automatically deploying artifacts to the ASF
snapshot repository[1].

It requires configuring a user token to auth to the repository. Although
I'm wondering if I must use my personal token or if there is some
project-wise token to use. Even asking for an INFRA member to help
configure, passing over a personal token to another one increases the risk.

Best,
tison.

[1]
https://github.com/tisonkun/opendal/actions/runs/5090173050/workflow#L129

AW: License question when including other ASF projects

[Christofer Dutz]

Hi Alex,

sorry for the late response ... I also checked and the Eclipse Distribution 
Licence 1.0 seems to be Category A and EPL 2.0 cat B, so it should be ok as 
long as you only have dependencies to it.

However I don’t know the plugin that you are using, so I can’t really help 
about how to resolve false-positives ... might have a look at it thoug.

Chris


Von: Alexander Alten-Lorenz 
Datum: Dienstag, 2. Mai 2023 um 16:05
An: general@incubator.apache.org 
Betreff: Re: License question when including other ASF projects
Can anyone give us a tip regarding this one?

Thanks,
 —alex

> On 30. Apr 2023, at 18:13, Alexander Alten-Lorenz  
> wrote:
>
> Hey Dominik,
>
> Sry for bugging, any chance you know how to tune the license check that the 
> Eclipse License passes?
> https://github.com/apache/incubator-wayang/actions/runs/4845087374/jobs/8633774880#step:6:1151
>
> It’s merged, but we’d love to have a green build :)
>
> Cheers,
>  —Alex
>
>
>> On 29. Apr 2023, at 11:40, Alexander Alten-Lorenz  
>> wrote:
>>
>> Hey Dominik,
>>
>> Thank you for confirming. I try to merge now, let’s hope :)
>>
>> Cheers,
>> —Alex
>>
>>> On 29. Apr 2023, at 11:36, Dominik Riemer  wrote:
>>>
>>> Hi Alex,
>>>
>>> EPL 2.0 should be fine in case it is included in binary-only form (see 
>>> Category B under [1]).
>>>
>>> Cheers
>>> Dominik
>>>
>>>
>>> [1] https://www.apache.org/legal/resolved.html
>>>
>>>
>>> -Original Message-
>>> From: Alexander Alten-Lorenz 
>>> Sent: Saturday, April 29, 2023 11:29 AM
>>> To: general@incubator.apache.org
>>> Subject: License question when including other ASF projects
>>>
>>> Hi,
>>>
>>> We use Apache Calcite, dependabot suggests a bump, but the automation 
>>> failed since Calcite uses a non-compatible license (if I’m right)
>>>
>>> https://github.com/apache/incubator-wayang/actions/runs/4751917613/jobs/8441627979?pr=302#step:6:1117
>>>
>>> How can we solve this, except not to update ;) Or is this just a false 
>>> alarm?
>>>
>>> Thanks for the help,
>>> —Alex
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>

Re: Looking for a champion: HyperIoT

[Christofer Dutz]

Hi,

So, I did have a look at the website and indeed it looks interesting.
However, when I looked at the GitHub repo and the GPL2 yelled at me.

Are you able to do a re-licensing? I mean … can you ask everyone who 
contributed to the project if they agree to re-licensing it under the Apache 
2.0 license?

If that’s not possible, I guess this is the end of the line for Apache. If it’s 
possible I am still keeping my hand up for being your Mentor and possibly 
championing the project.

Chris



From: Christofer Dutz 
Date: Thursday, 12. January 2023 at 14:22
To: general@incubator.apache.org 
Subject: Re: Looking for a champion: HyperIoT
Hi all,

well … it being used is not a requirement … some projects have been joining 
Apache even without a single user, but we want at least a minimum on community 
around it.

As I’m really into the (I)IoT topic and I currently have one Mentoring slot 
open … I would be raising my hand for being interested to help.

Give me a bit of time to read up on what the project is about.

Chris


From: Enrico Olivelli 
Date: Thursday, 12. January 2023 at 11:26
To: general@incubator.apache.org 
Subject: Re: Looking for a champion: HyperIoT
Piergiorgio,
Is this project already OSS ?
Is this project already used by other companies?

If it doesn't meet those requirements I don't think that it will have
a happy story in the Incubator.

I have never been a Mentor for an incubating project but I have been
following this list for quite some time,
and my understanding is that a project that wants to enter the ASF
MUST already be an OSS project with active users.

just my 2 cents
Enrico

Il giorno gio 12 gen 2023 alle ore 09:17 tison 
ha scritto:
>
> > I'm an ASF Member, I could also help here for writing the proposal but I'm
> > not a PMC member for the Incubator project, I'm a committer for my past
> > incubation experience related to Apache ManifoldCF.
>
> FYI, as an ASF Member, you can request to become a IPMC member anytime:
>
> > Individuals may be nominated to join the IPMC after a vote which passes.
> Individuals may choose to bring themselves or others to the attention of
> the IPMC. Additionally, any Member of the Apache Software Foundation may
> join the IPMC by request.
>
> ... from https://incubator.apache.org/guides/roles_and_responsibilities.html
> .
>
> Best,
> tison.
>
>
> Piergiorgio Lucidi  于2023年1月12日周四 16:06写道：
>
> > Hi folks,
> >
> > ACSoftware contacted me because they would like to donate their platform
> > named HyperIoT to the Foundation. I'm searching for a champion to build the
> > incubation proposal.
> >
> > I'm an ASF Member, I could also help here for writing the proposal but I'm
> > not a PMC member for the Incubator project, I'm a committer for my past
> > incubation experience related to Apache ManifoldCF.
> >
> > They currently published only the backend services on their GitHub account
> > but they are going to also share all the UI modules:
> > https://github.com/ACSoftwareTeam/HyperIoT-Platform
> >
> > You can find more information and some screenshots here:
> > https://hyperiot.cloud/
> >
> > Below is an overview of this platform.
> >
> > HyperIoT is an OpenSource Cloud Native platform entirely based on Apache
> > Technologies for managing big data from any IoT network.
> > The platform captures the information sent from any source by managing data
> > compression, running statistics or machine/deep learning algorithms,
> > presenting data to the end user in realtime and offline mode (saved data).
> >
> > It consists of the following macro-components (entirely built on top of
> > Apache Technologies):
> >
> > - Realtime and Enrichments (Kafka and Storm): Realtime configuration and
> > visualization of data coming from sources with the possibility of defining
> > enrichment rules on incoming data
> >
> > - Events and Alarm Management (Storm): Data are analyzed in real time with
> > the possibility of reporting any alarms by sending timely notifications
> > either to the device or using other channels such as email
> >
> > - Persistence (HBase and Hadoop) : Data is saved in a secure mode
> >
> > - Statistics and Machine Learning (Apache Spark): It is possible to run
> > periodically, on the saved data, machine learning algorithms or generic
> > statistics presenting the results of these computations in the user's
> > dashboard.
> >
> > HyperIoT cloud infrastructure constitutes a generic server-side
> > architecture suitable for cross-cutting applications in various
> > manufacturing sectors. The infrastructure allows a user, without the
> > intervention of external developers, to be able to:
> >
&g

Re: Looking for a champion: HyperIoT

[Christofer Dutz]

Hi all,

well … it being used is not a requirement … some projects have been joining 
Apache even without a single user, but we want at least a minimum on community 
around it.

As I’m really into the (I)IoT topic and I currently have one Mentoring slot 
open … I would be raising my hand for being interested to help.

Give me a bit of time to read up on what the project is about.

Chris


From: Enrico Olivelli 
Date: Thursday, 12. January 2023 at 11:26
To: general@incubator.apache.org 
Subject: Re: Looking for a champion: HyperIoT
Piergiorgio,
Is this project already OSS ?
Is this project already used by other companies?

If it doesn't meet those requirements I don't think that it will have
a happy story in the Incubator.

I have never been a Mentor for an incubating project but I have been
following this list for quite some time,
and my understanding is that a project that wants to enter the ASF
MUST already be an OSS project with active users.

just my 2 cents
Enrico

Il giorno gio 12 gen 2023 alle ore 09:17 tison 
ha scritto:
>
> > I'm an ASF Member, I could also help here for writing the proposal but I'm
> > not a PMC member for the Incubator project, I'm a committer for my past
> > incubation experience related to Apache ManifoldCF.
>
> FYI, as an ASF Member, you can request to become a IPMC member anytime:
>
> > Individuals may be nominated to join the IPMC after a vote which passes.
> Individuals may choose to bring themselves or others to the attention of
> the IPMC. Additionally, any Member of the Apache Software Foundation may
> join the IPMC by request.
>
> ... from https://incubator.apache.org/guides/roles_and_responsibilities.html
> .
>
> Best,
> tison.
>
>
> Piergiorgio Lucidi  于2023年1月12日周四 16:06写道：
>
> > Hi folks,
> >
> > ACSoftware contacted me because they would like to donate their platform
> > named HyperIoT to the Foundation. I'm searching for a champion to build the
> > incubation proposal.
> >
> > I'm an ASF Member, I could also help here for writing the proposal but I'm
> > not a PMC member for the Incubator project, I'm a committer for my past
> > incubation experience related to Apache ManifoldCF.
> >
> > They currently published only the backend services on their GitHub account
> > but they are going to also share all the UI modules:
> > https://github.com/ACSoftwareTeam/HyperIoT-Platform
> >
> > You can find more information and some screenshots here:
> > https://hyperiot.cloud/
> >
> > Below is an overview of this platform.
> >
> > HyperIoT is an OpenSource Cloud Native platform entirely based on Apache
> > Technologies for managing big data from any IoT network.
> > The platform captures the information sent from any source by managing data
> > compression, running statistics or machine/deep learning algorithms,
> > presenting data to the end user in realtime and offline mode (saved data).
> >
> > It consists of the following macro-components (entirely built on top of
> > Apache Technologies):
> >
> > - Realtime and Enrichments (Kafka and Storm): Realtime configuration and
> > visualization of data coming from sources with the possibility of defining
> > enrichment rules on incoming data
> >
> > - Events and Alarm Management (Storm): Data are analyzed in real time with
> > the possibility of reporting any alarms by sending timely notifications
> > either to the device or using other channels such as email
> >
> > - Persistence (HBase and Hadoop) : Data is saved in a secure mode
> >
> > - Statistics and Machine Learning (Apache Spark): It is possible to run
> > periodically, on the saved data, machine learning algorithms or generic
> > statistics presenting the results of these computations in the user's
> > dashboard.
> >
> > HyperIoT cloud infrastructure constitutes a generic server-side
> > architecture suitable for cross-cutting applications in various
> > manufacturing sectors. The infrastructure allows a user, without the
> > intervention of external developers, to be able to:
> >
> > - Configure communication between the IoT network and the cloud (without
> > writing code but following graphically guided processes)
> > - Have a set of predefined statistics for the data being processed
> > - Upload your own analytics algorithms (for more technical users)
> > - Access an intuitive web interface for configurations and access to
> > real-time and historical data via different graphical widgets
> > - Share the information collected
> >
> > The easy use of the platform through graphically guided processes allows it
> > to be used even by personnel who do not have specific knowledge about IoT
> > topics, data streaming, big data, etc...
> >
> > This will help spread the benefits of IoT and Industry 4.0 technologies
> > even to personnel who are not exactly experts.
> >
> > Thank you for your support.
> >
> > Cheers,
> > PJ
> >
> > --
> > Piergiorgio
> >

-
To unsubscribe, e-mail: 

Re: [RESULT][VOTE] Apache Tuweni graduation

[Christofer Dutz]

Sooo … assuming we let Tuweni graduate,

If you could only release with binding votes from the incubator.
How would you be able to release without it?

Because technically as a TLP there is nowhere, where you could get those 
missing votes.

And if a project can’t release because there are too little PMC members able to 
vote, that’s the direct path to the Attic.

So please invest some time and effort into growing and engaging your community.
Trust them with making changes and decisions.
Promote your project publicly and promote that people are welcome to come and 
contribute.
Offer them to be their mentor for their first contributions.

That’s my advice and happy to chat if you want some help with that all.
(Help like in guidance, not help, like in doing the work)

Chris

From: Antoine Toulme 
Date: Thursday, 22. December 2022 at 08:48
To: general 
Subject: Re: [RESULT][VOTE] Apache Tuweni graduation


> On Dec 21, 2022, at 12:55 AM, Christofer Dutz  
> wrote:
>
> Hi all,
>
> I still think just because a resolution is added that it doesn’t mean the 
> board will accept it.
>
> Having barely 3 +1 votes also seems an indicator that the rest of the IPMC 
> doesn’t clearly believe Tuweni is ready for graduation.
> The incubator is for projects to learn how to do things the Apache way and to 
> grow its community into a sustainable project.
> I see that the first part seems to be done, but the second part is completely 
> missing.
>
> I also don’t agree that being in the incubator will keep anyone from 
> contributing, I even think that most people know that incubating projects are 
> usually the ones easiest to get involved in.
> So I would like to bring the counter-argument to the table, that growing the 
> community might become harder, once Tuweni is a TLP.
>
> The problem I see is perfectly reflected by this:
> https://github.com/apache/incubator-tuweni/graphs/contributors
>
> Has anyone besides you – Antoine – ever done a release?
> Also did I have a look at your last release thread:
> There you had exactly 3 +1 votes, however one of them was from “Danno Ferrin” 
> who seems to “only” be a Committer.
> A PPMC +1 vote would have been required here, so technically this release 
> wasn’t ok.
Because this release didn’t have enough votes, we moved it to the general 
incubator list where it was duly voted.

>
> I think this project should focus on building the community, having others be 
> the Release Manager for one or two releases and then to aim for graduation.
>
> Maybe I should make my opinion a bit more explicit by officially voting -1
>
> So here goes:
>
> -1 binding
>
> Chris
>
>
> From: Antoine Toulme 
> Date: Wednesday, 21. December 2022 at 07:02
> To: general 
> Subject: [RESULT][VOTE] Apache Tuweni graduation
> Folks,
>
> Thank you for your participation in the Apache Tuweni graduation vote.
>
> The results are as follows:
> +1: 3 Antoine Toulme (binding), Larry Mccay (binding), Dave Fisher (binding)
> +0: 0
> -1: 0
>
> Thanks all! We will proceed to the next step of voting for a PMC chair and 
> drafting a resolution for the board.
>
> Cheers,
>
> Antoine
>
>> On Dec 20, 2022, at 8:45 AM, Antoine Toulme  wrote:
>>
>> I’ve let the vote go on for a bit. I’d like to make sure we get a chance for 
>> final votes and comments and I will close it by tonight PT time.
>>
>> Cheers,
>>
>> Antoine
>>
>>> On Dec 19, 2022, at 6:45 AM, Josh Fischer  wrote:
>>>
>>> To build on what Dave is saying (from my experience at least) is projects
>>> will enter the incubator and they tend to focus on building new features on
>>> top of new features. Instead of focusing on how they can transfer that deep
>>> knowledge of the system to anyone who is willing to learn.
>>>
>>> Getting those people to feel comfortable stepping up can be a challenge.
>>> Making new comers (whoever they are) feel welcome to ask questions and
>>> contribute on mailing list discussion, prs, code contributions, etc is the
>>> most important part of building a self-sustaining community.
>>>
>>>
>>> I’ll get off my soapbox now.
>>>
>>> - Josh
>>>
>>>
>>>
>>> On Mon, Dec 19, 2022 at 2:40 AM Christofer Dutz 
>>> wrote:
>>>
>>>> Sorry for asking,
>>>>
>>>> but Dave, could you please explain that reply … admittedly I didn’t
>>>> understand what you wanted to say
>>>> (Guess I would consider it advanced English and I simply didn’t understand
>>>> it).
>>>>
>>>> Chris
>>>>
>>>> From: Dave Fisher 

Re: [RESULT][VOTE] Apache Tuweni graduation

[Christofer Dutz]

Hi all,

I still think just because a resolution is added that it doesn’t mean the board 
will accept it.

Having barely 3 +1 votes also seems an indicator that the rest of the IPMC 
doesn’t clearly believe Tuweni is ready for graduation.
The incubator is for projects to learn how to do things the Apache way and to 
grow its community into a sustainable project.
I see that the first part seems to be done, but the second part is completely 
missing.

I also don’t agree that being in the incubator will keep anyone from 
contributing, I even think that most people know that incubating projects are 
usually the ones easiest to get involved in.
So I would like to bring the counter-argument to the table, that growing the 
community might become harder, once Tuweni is a TLP.

The problem I see is perfectly reflected by this:
https://github.com/apache/incubator-tuweni/graphs/contributors

Has anyone besides you – Antoine – ever done a release?
Also did I have a look at your last release thread:
There you had exactly 3 +1 votes, however one of them was from “Danno Ferrin” 
who seems to “only” be a Committer.
A PPMC +1 vote would have been required here, so technically this release 
wasn’t ok.

I think this project should focus on building the community, having others be 
the Release Manager for one or two releases and then to aim for graduation.

Maybe I should make my opinion a bit more explicit by officially voting -1

So here goes:

-1 binding

Chris


From: Antoine Toulme 
Date: Wednesday, 21. December 2022 at 07:02
To: general 
Subject: [RESULT][VOTE] Apache Tuweni graduation
Folks,

Thank you for your participation in the Apache Tuweni graduation vote.

The results are as follows:
+1: 3 Antoine Toulme (binding), Larry Mccay (binding), Dave Fisher (binding)
+0: 0
-1: 0

Thanks all! We will proceed to the next step of voting for a PMC chair and 
drafting a resolution for the board.

Cheers,

Antoine

> On Dec 20, 2022, at 8:45 AM, Antoine Toulme  wrote:
>
> I’ve let the vote go on for a bit. I’d like to make sure we get a chance for 
> final votes and comments and I will close it by tonight PT time.
>
> Cheers,
>
> Antoine
>
>> On Dec 19, 2022, at 6:45 AM, Josh Fischer  wrote:
>>
>> To build on what Dave is saying (from my experience at least) is projects
>> will enter the incubator and they tend to focus on building new features on
>> top of new features. Instead of focusing on how they can transfer that deep
>> knowledge of the system to anyone who is willing to learn.
>>
>> Getting those people to feel comfortable stepping up can be a challenge.
>> Making new comers (whoever they are) feel welcome to ask questions and
>> contribute on mailing list discussion, prs, code contributions, etc is the
>> most important part of building a self-sustaining community.
>>
>>
>> I’ll get off my soapbox now.
>>
>> - Josh
>>
>>
>>
>> On Mon, Dec 19, 2022 at 2:40 AM Christofer Dutz 
>> wrote:
>>
>>> Sorry for asking,
>>>
>>> but Dave, could you please explain that reply … admittedly I didn’t
>>> understand what you wanted to say
>>> (Guess I would consider it advanced English and I simply didn’t understand
>>> it).
>>>
>>> Chris
>>>
>>> From: Dave Fisher 
>>> Date: Monday, 12. December 2022 at 06:19
>>> To: general@incubator.apache.org 
>>> Subject: Re: [VOTE] Apache Tuweni graduation
>>> Thanks. I think you are onto an idea of community that could be somehow
>>> explicitly part of the incubator’s curriculum. That’s a separate discussion.
>>>
>>> Best,
>>> Dave
>>>
>>> Sent from my iPhone
>>>
>>>> On Dec 11, 2022, at 7:17 PM, Willem Jiang 
>>> wrote:
>>>>
>>>> I agree we don't need to hold the Tuweni graduation for the release
>>> checking.
>>>> But if we want to build a sustainable Open Source project, we still
>>>> need to pay lots of attention to community building.
>>>>
>>>>
>>>> Willem Jiang
>>>>
>>>> Twitter: willemjiang
>>>> Weibo: 姜宁willem
>>>>
>>>>> On Sun, Dec 11, 2022 at 9:24 AM Antoine Toulme 
>>> wrote:
>>>>>
>>>>> Hello folks,
>>>>>
>>>>> Apache Tuweni had a much smaller community when it started its
>>> incubation at Apache. The path of this project has been impacted by the
>>> domain it applies to and the pandemic certainly hasn't helped. Still it has
>>> managed to create enough momentum to make regular releases and check off
>>> all incubation checks.
>>>>> Community bu

Re: [VOTE] Apache Tuweni graduation

[Christofer Dutz]

Sorry for asking,

but Dave, could you please explain that reply … admittedly I didn’t understand 
what you wanted to say
(Guess I would consider it advanced English and I simply didn’t understand it).

Chris

From: Dave Fisher 
Date: Monday, 12. December 2022 at 06:19
To: general@incubator.apache.org 
Subject: Re: [VOTE] Apache Tuweni graduation
Thanks. I think you are onto an idea of community that could be somehow 
explicitly part of the incubator’s curriculum. That’s a separate discussion.

Best,
Dave

Sent from my iPhone

> On Dec 11, 2022, at 7:17 PM, Willem Jiang  wrote:
>
> I agree we don't need to hold the Tuweni graduation for the release checking.
> But if we want to build a sustainable Open Source project, we still
> need to pay lots of attention to community building.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>> On Sun, Dec 11, 2022 at 9:24 AM Antoine Toulme  wrote:
>>
>> Hello folks,
>>
>> Apache Tuweni had a much smaller community when it started its incubation at 
>> Apache. The path of this project has been impacted by the domain it applies 
>> to and the pandemic certainly hasn't helped. Still it has managed to create 
>> enough momentum to make regular releases and check off all incubation checks.
>> Community building is definitely still on the menu - right now and later as 
>> well. We will continue building and including folks. We have onboarded 
>> successfully multiple committers and have received contributions. I expect 
>> this trend to continue and mature.
>>
>> The question is whether the best place for us to continue growing is the 
>> incubator. The incubator adds additional checks on our releases and slows 
>> down our cycles, which has historically driven folks to fork and move away 
>> from the project.
>>
>> The incubator doesn't offer opportunities for community building, from what 
>> I know. We will need to continue to build our image and presence to attract 
>> contributors on our own.
>>
>> The project mentors have been nothing short of fantastic. They have been 
>> helpful in maturing the project. In my opinion, we are using their precious 
>> time when they should be engaged in helping other projects of the incubator.
>>
>> With this, I want to thank the incubator. We had a great experience building 
>> with you all. I personally believe we should free the incubator's time and 
>> attention to concentrate on other projects. I also believe the project is 
>> mature enough to function outside of the incubator.
>>
>> I vote +1 to graduate Tuweni from the incubator.
>>
>> Thanks,
>>
>> Antoine
>>
>>>> On Dec 7, 2022, at 3:37 PM, larry mccay  wrote:
>>>
>>> We have also recently seen long term incubating projects with considerable
>>> adoption falter.
>>> I consider the fact that they did not graduate early enough a contributing
>>> factor here.
>>>
>>> Nothing wrong with incubation but staying in the incubator and encountering
>>> attrition is different from TLP
>>> with some churn with new folks coming into an official TLP project while
>>> others can fall off in a healthy way.
>>>
>>> Again, having the community test and release 14 separate releases
>>> demonstrates contributors in the community
>>> even if they aren't all materially contributing code.
>>>
>>>
>>>
>>> On Wed, Dec 7, 2022 at 3:45 AM Christofer Dutz 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> And in the last few months the ASF has sadly seen enough cases, in which
>>>> even big projects suffered from the lack of diversity.
>>>> So, I would also consider this to be a blocker.
>>>>
>>>> Community building isn’t something that happens or comes for free.
>>>> It’s actually hard work, but it needs to be done.
>>>>
>>>> Just my opinion on this topic.
>>>>
>>>> Chris
>>>>
>>>> From: Willem Jiang 
>>>> Date: Wednesday, 7. December 2022 at 02:59
>>>> To: general@incubator.apache.org 
>>>> Subject: Re: [VOTE] Apache Tuweni graduation
>>>> It looks like we need a dedicated community leader[1] to build a
>>>> diverse community (just borrow a pattern from InnerSource Common[2]).
>>>>
>>>> " Communication takes up a significant percentage of a community
>>>> leader's daily work. At the same time, he or she will likely also have
>>>> to spearhead the initial development, too. I

Re: [DISCUSS] KIE Proposal

[Christofer Dutz]

Hi Jason,

now this looks a lot more like something we can help support :-)

And projects don’t necessarily have to be mono repos. Stuff like examples, 
project websites … that’s quite common to be in separate repositories.

I guess the amount of additional work would not be that much … yeah … the 
reports have to be written, but most use templates for that and just fill in 
special things being noted.
Writing the reports for a project usually doesn’t take much time.

Regarding setting up of infra … I guess you would go a GitHub approach and not 
sign up for Jira and Confluence now that public user registrations are disabled.
I would dare to say the amount of work to set this up for one project and 
multiple project would be identical.

Chris


From: Jason Porter 
Date: Tuesday, 6. December 2022 at 17:27
To: general@incubator.apache.org 
Subject: Re: [DISCUSS] KIE Proposal

> On Dec 6, 2022, at 01:43, Christofer Dutz  wrote:
>
> Hi Jason,
>
> Well, those numbers are a bit better than the initial ones.
> Thing is: Mentors will not only have to help onboard people to Apache and 
> teach them how to do things, if they are doing their job correctly, they 
> should also really audit the releases being done and help get the codebase 
> into shape first.
>
> Even with 12 sub-projects, work-wise that would put a load on the mentors, as 
> if they signed up for mentoring 12 projects.
>
> So how about bringing in projects separately (where it makes sense)? There 
> each project could have their initial PPMC and committer lists and it would 
> spread out the load a bit. However I would expect staffing 12 projects with 
> enough work-willing mentors will still be challenging and I would assume not 
> all of them to find enough of them, but it could be one first step.
>
> Or is there an advantage of considering all projects as one unity?
>
> Chris
>
> [snip]

That is part of a broader question. Some of those repos are things like 
examples for kogito, the website, etc. Things that are part of the projects 
themselves, but don’t have a life outside of the project to which they belong. 
I understand we’ll probably have to collapse the structures within Apache and 
have a single repo per project. What we’re really looking at as far as projects 
being donated:

Kogito
Drools
jBPM

Then there are the supporting repos for things like examples, docs, website, 
tooling, etc. Many of the people working on these projects work on all of them, 
so it would probably be the same group of people with very little deviation in 
the list of committers. Could they be different PPMCs, but they’d basically be 
the same group, just more work with the reports, setup, infra, etc.

Jason Porter
Software Engineer
He/Him/His

IBMB�CB��[��X��ܚX�KK[XZ[
��[�\�[ ][��X��ܚX�P[��X�]܋�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
��[�\�[ Z[[��X�]܋�\X�K�ܙ�B

Re: [VOTE] Apache Tuweni graduation

[Christofer Dutz]

Hi all,

And in the last few months the ASF has sadly seen enough cases, in which even 
big projects suffered from the lack of diversity.
So, I would also consider this to be a blocker.

Community building isn’t something that happens or comes for free.
It’s actually hard work, but it needs to be done.

Just my opinion on this topic.

Chris

From: Willem Jiang 
Date: Wednesday, 7. December 2022 at 02:59
To: general@incubator.apache.org 
Subject: Re: [VOTE] Apache Tuweni graduation
It looks like we need a dedicated community leader[1] to build a
diverse community (just borrow a pattern from InnerSource Common[2]).

" Communication takes up a significant percentage of a community
leader's daily work. At the same time, he or she will likely also have
to spearhead the initial development, too. In the face of limited
capacity, inexperienced leaders will tend to focus on development and
neglect communication. The barrier for potential contributors to make
their first contribution and to commit to the community will be much
higher if the community leader is hard to reach or is slow to respond
to feedback and questions for lack of time."

[1]https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/2-structured/dedicated-community-leader.md#forces
[2]https://innersourcecommons.org/

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Dec 6, 2022 at 9:51 AM larry mccay  wrote:
>
> I'm not so sure that I see this as a blocker for graduation.
> There was enough consensus and testing to spin and publish 14 releases.
> There has been healthy conversation about this very topic among the mentors
> and contributors on the private list.
>
> The nature of this project is that the consumption of these libraries are
> going to get less traction while in incubation and a community may grow
> larger as a TLP as confidence is instilled by that status.
>
> The Tuweni community has demonstrated the ability to publish releases
> within that Apache Way and guidelines, has welcomed new contributors, etc.
> The long term success will require a larger active community but I don't
> think that needs to block graduation as the incubation goals have been met.
>
> My 2 cents.
>
> On Mon, Dec 5, 2022 at 7:41 PM Willem Jiang  wrote:
>
> > I agree with Gang Li. The Bus factor[1] of this project is relatively high.
> >
> > [1]https://en.wikipedia.org/wiki/Bus_factor
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, Dec 5, 2022 at 11:06 PM li gang  wrote:
> > >
> > > I checked the contributions of the Tuweni project[1],the traffic of the
> > > mail list d...@tuweni.apache.org[2] and the KEYS[3].
> > >
> > > It looks like the project is mainly maintained by Antoine Toulme self,
> > > I have a concern this is not comply with the diversity.
> > >
> > > [1]https://github.com/apache/incubator-tuweni/graphs/contributors
> > > [2]https://lists.apache.org/list?d...@tuweni.apache.org
> > > [3]https://downloads.apache.org/incubator/tuweni/KEYS
> > >
> > > Antoine Toulme  于2022年12月5日周一 15:14写道：
> > >
> > > > Dear Apache Incubator Community and IPMC members,
> > > >
> > > > We discussed the graduation for Tuweni in the Apache Incubator
> > > > Community [4], where no issues were raised and positive replies were
> > > > received.
> > > > After having the graduation discussion in the Tuweni community [1], we
> > > > have passed the vote within Tuweni community [2] and the vote result
> > > > was published [3].
> > > >
> > > > I would like to start this voting thread to request graduating Apache
> > > > Tuweni(incubating) from Apache Incubator as a Top Level Project.
> > > >
> > > > Please provide your vote accordingly:
> > > > [ ] +1 Yes, I support Tuweni project to graduate from the Apache
> > Incubator.
> > > > [ ] +0 No opinion.
> > > > [ ] -1 No, the Tuweni project is not ready to graduate, because...
> > > >
> > > > Thank you for participating in the vote. This vote will stay open for
> > at
> > > > least 72 hours.
> > > >
> > > > Here is an overview of the Apache Tuweni(incubating) to help with the
> > > > vote.
> > > >
> > > > *Community*
> > > >
> > > > ● The PPMC is active, with PMC members voting for graduation along with
> > > > mentors.
> > > > ● 6 new committers were added, bringing the total number of committers
> > to
> > > > 14 from 12 different
> > > > organizations.
> > > > ● The number of contributors is now 25 and growing.
> > > > ● The dev@Tuweni mailing list currently has 33 subscribers [4].
> > > >
> > > > *Project*
> > > >
> > > > ● Apache Tuweni (incubating) is a set of libraries and other tools to
> > aid
> > > > development of blockchain and other  decentralized software in Java and
> > > > other JVM languages. It includes a low-level bytes library,
> > serialization
> > > > and deserialization codecs (e.g. RLP), various cryptography functions
> > and
> > > > primitives, and lots of other helpful utilities. Tuweni is developed
> > for
> > > > JDK 11 or higher.
> > > > 

Re: [DISCUSS] KIE Proposal

[Christofer Dutz]

Hi Jason,

Well, those numbers are a bit better than the initial ones.
Thing is: Mentors will not only have to help onboard people to Apache and teach 
them how to do things, if they are doing their job correctly, they should also 
really audit the releases being done and help get the codebase into shape first.

Even with 12 sub-projects, work-wise that would put a load on the mentors, as 
if they signed up for mentoring 12 projects.

So how about bringing in projects separately (where it makes sense)? There each 
project could have their initial PPMC and committer lists and it would spread 
out the load a bit. However I would expect staffing 12 projects with enough 
work-willing mentors will still be challenging and I would assume not all of 
them to find enough of them, but it could be one first step.

Or is there an advantage of considering all projects as one unity?

Chris

From: Jason Porter 
Date: Monday, 5. December 2022 at 19:08
To: general@incubator.apache.org 
Subject: Re: [DISCUSS] KIE Proposal
On Dec 5, 2022, at 01:23, Christofer Dutz  wrote:

Hi all,

as you already mentioned PLC4X, I think in general supporting something to do 
logic-decisions based on industrial data-streams would be a nice addition.  I 
do also agree that adding 80 projects might be quite a big gulp for us to 
ingest.

How many people are we talking about being on the IPMC/committers? Mentoring a 
project with hundreds of people would probably require a fleet of mentors.

Hey Chris,

The size of the PPMC is a good question. Per the Incubator site 
[https://incubator.apache.org/guides/ppmc.html] it is typically made up of the 
initial committers and mentors. We have 51 people currently tagged for being 
initial committers and three people as mentors. Most have not done anything 
with Apache. That feels like a lot of people for an initial PPMC. We were 
initially thinking of something small around 7 people initially. Not sure how 
that plays in with the list of initial committers though, unless we par that 
down as well and bring people in during the incubation.

WRT the number of projects, we’re not looking at donating all of those. We’re 
still in discussion on the final list, but that list is considerably smaller. 
Discussions are leaning toward 12 or so.

Jason Porter
Software Engineer
He/Him/His

IBM

Chris

From: Willem Jiang mailto:willem.ji...@gmail.com>>
Date: Monday, 5. December 2022 at 04:15
To: general@incubator.apache.org<mailto:general@incubator.apache.org> 
mailto:general@incubator.apache.org>>
Subject: Re: [DISCUSS] KIE Proposal
We need to go through the IP clearance and help the project to do the
release that follows the Apache police.
It could be a nightmare for the incubator if we donate an "Umbrella Project."
Can we consider donating sub-projects such as kogito one by one?


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Dec 2, 2022 at 9:21 AM Niall Pemberton
 wrote:

Wow, 137 GitHub repositories!

OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
have a rough idea of how many of those would be part of the incubation?

Historically, Apache has been against "Umbrella Projects" - encouraging
them to break up and become individual Top Level Projects (TLP) in their
own right - the biggest example of that was Jakarta which used to be
anything java related - but there have been others where sub-projects which
have a life of their own have moved out to become TLPs.

To me this looks like it should be 4 or 5 projects - its not clear whether
kie is a product in its own right (with releasable artifcats) or just the
umbrella that the others are grouped under?
 * drools
 * jbpm
 * kogito
 * optaplanner
 * kie ???

Niall


On Thu, 1 Dec 2022 at 21:36, Jason Porter  wrote:

Abstract

KIE (Knowledge is Everything) is a community of solutions and supporting
tooling for knowledge engineering and process automation, focusing on
events, rules, and workflows.

Proposal<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal


KIE is a community dedicated to supporting knowledge engineering and
process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
comprised of leading open-source projects (like Drools and jBPM), which
provide modeling and code authoring tools in this space. The work has a
strong emphasis on being a first-class citizen for Kubernetes but will
continue to support embedded and other environments such as edge computing.
Drools and jBPM are well-known projects in their areas of rules and
workflow and they will be joined by another project, building on a shared
core with jBPM, for CNCF’s Serverless Workflow - this project is going
through a naming process at the time of this application. Kogito is the
foundation project for workflow which jBPM and CNCF’s Serverless Workflow
build on. Services and frameworks are pro

Re: [DISCUSS] KIE Proposal

[Christofer Dutz]

Hi all,

as you already mentioned PLC4X, I think in general supporting something to do 
logic-decisions based on industrial data-streams would be a nice addition.  I 
do also agree that adding 80 projects might be quite a big gulp for us to 
ingest.

How many people are we talking about being on the IPMC/committers? Mentoring a 
project with hundreds of people would probably require a fleet of mentors.

Chris

From: Willem Jiang 
Date: Monday, 5. December 2022 at 04:15
To: general@incubator.apache.org 
Subject: Re: [DISCUSS] KIE Proposal
We need to go through the IP clearance and help the project to do the
release that follows the Apache police.
It could be a nightmare for the incubator if we donate an "Umbrella Project."
Can we consider donating sub-projects such as kogito one by one?


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Dec 2, 2022 at 9:21 AM Niall Pemberton
 wrote:
>
> Wow, 137 GitHub repositories!
>
> OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
> have a rough idea of how many of those would be part of the incubation?
>
> Historically, Apache has been against "Umbrella Projects" - encouraging
> them to break up and become individual Top Level Projects (TLP) in their
> own right - the biggest example of that was Jakarta which used to be
> anything java related - but there have been others where sub-projects which
> have a life of their own have moved out to become TLPs.
>
> To me this looks like it should be 4 or 5 projects - its not clear whether
> kie is a product in its own right (with releasable artifcats) or just the
> umbrella that the others are grouped under?
>   * drools
>   * jbpm
>   * kogito
>   * optaplanner
>   * kie ???
>
> Niall
>
>
> On Thu, 1 Dec 2022 at 21:36, Jason Porter  wrote:
>
> > Abstract
> >
> > KIE (Knowledge is Everything) is a community of solutions and supporting
> > tooling for knowledge engineering and process automation, focusing on
> > events, rules, and workflows.
> >
> > Proposal<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal
> > >
> >
> > KIE is a community dedicated to supporting knowledge engineering and
> > process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
> > CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
> > comprised of leading open-source projects (like Drools and jBPM), which
> > provide modeling and code authoring tools in this space. The work has a
> > strong emphasis on being a first-class citizen for Kubernetes but will
> > continue to support embedded and other environments such as edge computing.
> > Drools and jBPM are well-known projects in their areas of rules and
> > workflow and they will be joined by another project, building on a shared
> > core with jBPM, for CNCF’s Serverless Workflow - this project is going
> > through a naming process at the time of this application. Kogito is the
> > foundation project for workflow which jBPM and CNCF’s Serverless Workflow
> > build on. Services and frameworks are provided to enable those projects in
> > a cloud-native environment and tooling is made available through KIE Tools.
> >
> > Background<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background
> > >
> >
> > Experience has shown that a holistic approach is a practical requirement
> > for any  knowledge engineering and process automation. This requires a
> > breadth of capabilities able to model and execute an application’s data
> > models, rules, workflows, and events. These projects aim to provide a
> > holistic approach with a strong emphasis on congruency across them.
> >
> > Rationale<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale
> > >
> >
> > Knowledge engineering and process automation have been and continue to
> > play a large part in today’s software lifecycle. To date, there have been
> > few truly open-source implementations of any of the specifications (DMN,
> > PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement
> > these standards and fill that gap of having an open-source implementation.
> >
> >
> > The projects within KIE also mesh well with other Apache projects such as
> > Apache Camel and Apache Airavata. Integrations could be done at the IoT
> > level with Apache PLC4X and others.
> >
> >
> > Developers need a solution that follows, implements, and collaborates with
> > these industry specifications. The Apache Software Foundation would allow
> > these projects to continue to grow in a vendor-neutral environment and
> > promote further collaboration with existing integrations and future
> > partners.
> >
> > Initial Goals<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-goals
> > >
> >
> > First and foremost, we aim to enlarge the community. KIE has primarily
> > been an open-source community of Red Hat Developers and users outside of
> > Red Hat. 

Re: [MENTORS] December report timeline - reports due December 2022

[Christofer Dutz]

I guess StreamPipes will not be filing an incubator report, but a board report 
this month ;-)

Holen Sie sich Outlook für Android

From: jmcl...@apache.org 
Sent: Friday, November 18, 2022 5:53:28 AM
To: general@incubator.apache.org 
Subject: [MENTORS] December report timeline - reports due December 2022

Dates for next board report:
Wed December 07 - Podling reports due by end of day
Sun December 11 - Shepherd reviews due by end of day
Sun December 11 - Summary due by end of day
Tue December 13 - Mentor signoff due by end of day
Wed December 14 - Report submitted to Board
Wed December 21 - Board meeting


Expected to report this month are:
 - baremaps
 - brpc
 - celeborn
 - kyuubi
 - marvin-ai
 - nemo
 - spot
 - streampark
 - streampipes
 - teaclave
 - uniffle
 - wayang


Reports as usual can be submitted here [1]

Thanks,
Justin


1. https://s.apache.org/incubator-report
1. https://cwiki.apache.org/confluence/display/INCUBATOR/Report
1. https://cwiki.apache.org/confluence/display/INCUBATOR/December2022

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

Re: [VOTE] Graduate Apache StreamPieps to a TLP

[Christofer Dutz]

Renewing my +1 (binding) from the SP mailing list.

I think this project has made some great progress … best of luck to you as TLP.

Chris


From: Jean-Baptiste Onofré 
Date: Monday, 7. November 2022 at 08:41
To: general@incubator.apache.org 
Subject: Re: [VOTE] Graduate Apache StreamPieps to a TLP
+1

Regards
JB

On Sun, Nov 6, 2022 at 10:32 PM Dominik Riemer  wrote:
>
> Hi everyone,
>
> following the [DISCUSS] thread at [0], I'd like to call a vote to graduate 
> StreamPipes to a TLP.
>
> Please vote accordingly:
>
> [ ] +1 Apache StreamPipes (incubating) is ready to graduate from the
> Apache Incubator to a TLP.
>
> [ ] +0 No opinion.
>
> [ ] -1 Apache StreamPipes (Incubating) is not ready to graduate (please state 
> reasons)
>
> Thank you for participating in the vote!
>
> Cheers
> Dominik
>
>
> ---
> Project highlights
> ---
>
> * Incubating since 2019-11-11
> * 5 releases (0.66.0, 0.67.0, 0.68.0, 0.69.0, 0.70.0)
> * 3 different release managers
> * 13 PPMC members (almost all from different organizations), including 5 
> mentors
> * 8 additional committers
> * active community with all discussions happening on the mailing list and 
> dedicated user mailing list as support channel
> * community building & talks at ACNA19, 20, 21, 22 + Asia, SF Big Data 
> Analytics and many other webinars
> * over 9.000 commits
> * 52 subscribers on the dev list, 57 subscribers on the users list
> * Articles about StreamPipes in the US Linux Magazine [4], and StreamPipes 
> was named one of the
> top 5 open source tools for IoT Analytics by OpenSourceForU [5]
> * Number of Github stars has increased to currently 350
> * Website [6], extensive documentation [7] and a developer wiki [8]
> * Strong connection and integration with other projects in the Apache IoT 
> space (e.g., PLC4X)
> * Completed maturity self-assessment [9]
>
>
> ---
> Draft resolution
> ---
>
> Establish the Apache StreamPipes 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 self-service Industrial IoT toolbox which enables
> non-technical users to connect, analyze and explore IoT
> data streams.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache StreamPipes Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache StreamPipes Project be and hereby is
> responsible for the creation and maintenance of software related to a
> self-service Industrial IoT toolbox which enables non-technical users to
> connect, analyze and explore IoT data streams; and be it
> further
>
> RESOLVED, that the office of "Vice President, Apache StreamPipes" 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
> StreamPipes Project, and to have primary responsibility for management
> of the projects within the scope of responsibility of the Apache
> StreamPipes 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 StreamPipes
> Project:
>
> * Christofer Dutz 
> * Dominik Riemer 
> * Grainier Perera 
> * Jean-Baptiste Onofré 
> * Johannes Tex 
> * Julian Feinauer 
> * Justin Mclean 
> * Kenneth Knowles 
> * Marco Heyden 
> * Patrick Wiener 
> * Philipp Zehnder 
> * Stefan Obermeier 
> * Tim Bossenmaier 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Philipp Zehnder be
> appointed to the office of Vice President, Apache StreamPipes, 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 StreamPipes Project be and hereby is tasked
> with the migration and rationalization of the Apache Incubator
> StreamPipes podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> StreamPipes podling encumbered upon the Apache Incubator PMC are
> hereafter discharged.
>
> ---
>
> [0] https://lists.apache.org/thread/dg3z175h2szcg3wgz9tmq770krvscvp8
>
> [1] https://lists.apache.org/thread/18vgpw0jq93rwh9mj9bb27nj7gjhmldg
>
> [2] ht

Re: [VOTE] Accept Pekko into the Apache Incubator

[Christofer Dutz]

+1 (binding)

Chris

From: Furkan KAMACI 
Date: Thursday, 20. October 2022 at 10:47
To: general@incubator.apache.org 
Subject: Re: [VOTE] Accept Pekko into the Apache Incubator
+1 (binding)

On 20 Oct 2022 Thu at 10:17 Jean-Baptiste Onofré  wrote:

> +1 (binding)
>
> Regards
> JB
>
> On Wed, Oct 19, 2022 at 10:04 AM Claude Warren, Jr
>  wrote:
> >
> > After reviewing the [DISCUSS] threads concerning bringing Pekko into the
> > incubator [1][2], and finding that there is no further comment, I am
> > calling for a VOTE to accept Pekko into the Apache Incubator.  The text
> of
> > the proposal is included below for convenience, final and definitive text
> > is in the Pekko Proposal from the Incubator wiki.[3] .
> >
> > Thank you for your time and consideration,
> > Claude
> >
> > [1] https://lists.apache.org/thread/1t0x6d815td9dgjxhck51b5txcjm28rr
> > [2] https://lists.apache.org/thread/cjo86gdwvqlqslq68gd0c8hxq6ds6yrz
> > [3] https://cwiki.apache.org/confluence/display/INCUBATOR/PekkoProposal
> >
> > *Pekko Proposal*
> >
> > *Abstract*
> >
> > Pekko is a toolkit and an ecosystem for building highly concurrent,
> > distributed, reactive and resilient applications for Java and Scala.
> >
> > *Proposal*
> >
> > Pekko is a toolkit that brings the actor model (popularised by Erlang) to
> > the JVM, providing the basis for building both locally and distributed
> > concurrency. On top of this Pekko provides a rich set of libraries built
> on
> > top of Actors to solve modern problems, including:
> >
> >- Streams: Fully bi-directional backpressured streams following the
> >Reactive manifesto
> >- HTTP: A fully streamed HTTP client/server built on top of streams
> that
> >also provides expected tools (such as connection pooling) necessary
> for
> >highly available web services
> >- connectors: A rich set of connectors for various databases,
> messaging,
> >persistent services built on top of streams
> >- grpc: A gRPC server/client
> >- projection: Provides abstractions necessary for CQRS pattern such as
> >envelope, necessary for systems such as Kafka.
> >
> > *Background*
> >
> > Pekko is a fork of the Akka project just before its licence changed from
> > Apache 2 to Business Source License 1.1. The project provides a set of
> > tools and frameworks that covers the complex problem space of distributed
> > concurrent systems. It is designed to support the design principles of
> the
> > Reactive Manifesto by providing components to efficiently scale up
> systems
> > within a server or scale out across multiple servers, are high
> performance,
> > resilient to failure, distributed systems without a single point of
> failure.
> >
> > *Rationale*
> >
> > There is a large cohort of applications and libraries that were dependent
> > upon the original open source version of this project. Numerous
> developers
> > contributed their time in the belief that the project would stay open
> > source. When the licence was changed the work of those developers was
> > locked up and a vital resource for the cohort of applications and
> libraries
> > disappeared. Apache Flink is an example of a library that used the
> original
> > library upon which this project is based. This project is to continue the
> > open source development that was promised under the original Apache 2
> > licence. We ask that the Apache Foundation accept this project so as to
> > prevent any future incompatible licence switch in the future.
> >
> > Apache has a long standing tradition of not accepting hostile forks.
> There
> > has been some discussion of whether this project violates that tradition.
> > We believe that it does not.
> >
> > For many years, Lightbend has been a steward for this open source
> project,
> > attracting contributions from many developers and building a community
> > under the Apache License. It's within their rights to offer their future
> > work under a different licence. The Pekko project will provide the
> > continuity of an Apache-licensed home for long-term support, maintenance
> > and new features for the developers that wish to continue using and
> > building on their previous work. The major historical reason why Apache
> > would be a good home for Pekko is that it will protect the project from
> > licence changes similar to what is instigating the initial incubation
> > proposal. If Pekko becomes part of Apache then it gives confidence to the
> > community/users of Pekko that such an incident won’t happen in the future
> > again. There are also currently existing Apache projects such as Flink
> that
> > use Akka to varying degrees and hence having Pekko to be part of Apache
> > gives confidence to these other Apache projects. We believe that this
> fork
> > is a maintenance of the pre-existing Apache 2 licence and ask that the
> > Apache community view it as such.
> >
> > In general, Akka had a very large penetration in both Scala and Java
> > codebases, particularly in large scale 

Re: [DISCUSS] Remove 72 hour waiting time to add PPMC members.

[Christofer Dutz]

Hi,

Well, I guess one of the reasons for the 72 hour was, that others can express 
their doubts before the person is invited.
If we now exercise our means to object a nomination after it’s executed, we 
have this odd unpleasant situation of the person knowing what happened.

But I guess we could try it and put it back in place if we see things go south.

Chris


From: Justin Mclean 
Date: Friday, 14. October 2022 at 17:39
To: general@incubator.apache.org 
Subject: Re: [DISCUSS] Remove 72 hour waiting time to add PPMC members.
Hi,

> I’m a bit worried that in contrast to PMCs PPMCs are usually not quite 
> familiar with how things work at Apache.
> Would we still have an option to intervene, if for example one PPMC bunch 
> adds people from the same company, for example?

I have a slight concern there as well, but this would very rarely occur. The 
IPMC can remove people from the PPMC if they were inappropriately added.

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

Re: [DISCUSS] Remove 72 hour waiting time to add PPMC members.

[Christofer Dutz]

+/-0 (binding)

I’m a bit worried that in contrast to PMCs PPMCs are usually not quite familiar 
with how things work at Apache.
Would we still have an option to intervene, if for example one PPMC bunch adds 
people from the same company, for example?

Chris

From: Goson zhang 
Date: Friday, 14. October 2022 at 02:41
To: general@incubator.apache.org 
Subject: Re: [DISCUSS] Remove 72 hour waiting time to add PPMC members.
+1 non-binding

peacewong  于2022年10月14日周五 15:05写道：

>   +1(non binding) to keep the NOTICE and remove 72 hours of waiting.
>
> Best Regards!
>
>
>
> Willem Jiang  于2022年10月14日周五 14:24写道：
>
> > +1 for removing the 72-hour wait time to add a PPMC member.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Oct 14, 2022 at 6:45 AM Justin Mclean 
> > wrote:
> > >
> > > Hi,
> > >
> > > The board recently changed the 72-hour waiting time to add a PMC member
> > to a top level project. We have the same 72-hour waiting time to add PPMC
> > members to a podling.
> > >
> > > Do we want to consider removing this 72-hour waiting time and just
> > require a PMC to notify the IPMC that they want to add someone?
> > >
> > > Kind Regards,
> > > Justin
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [DISCUSS] Incubating Proposal for StreamPark

[Christofer Dutz]

How about simply changing to Postgres?
I wouldn't expect StreamPark to depend on some MySQL special features.
Simply changing to Postgres should probably resolve the problem, right?

Chris

On 25.08.22, 08:43, "Calvin Kirs"  wrote:

Yes, this is consistent with what Justin said. If he is optional, then
OK. I misunderstood what you meant by 1 :(
But if the software does not work without mysql, even if you remove it
(mysql) when you distribute it, and then leave it to users to add it
themselves.
that's not okay either

Cheng Pan  于2022年8月25日周四 14:33写道：
>
> > 1. the project hardly depends on mysql-connector, w/o mysql-connector,
> > the project can not work totally.
> > 2. some optional functionalities of the project require
> > mysql-connector, w/o mysql-connector, the project still works.
> > 3. the project use mysql-connector for testing-only purpose,
> > mysql-connector is not required in runtime at all, e.g. the project
> > implements MySQL transport protocol, it uses mysql-connector for
> > testing to ensure compatibility.
>
> Thanks Calvin, from my understanding of [1], 2 and 3 are allowed, but 1 
is not.
>
> [1] https://apache.org/legal/resolved.html#optional
>
> Thanks,
> Cheng Pan
>
> On Thu, Aug 25, 2022 at 2:04 PM tison  wrote:
> >
> > Hi JB,
> >
> > With Beam: Beam provides a unified programming model (dataflow), while
> > StreamPark is a platform to package, deploy and operate streaming
> > applications.
> >
> > I'm not quite familiar with Wayang and NiFi, though.
> >
> > Best,
> > tison.
> >
> >
> > Jean-Baptiste Onofré  于2022年8月25日周四 13:26写道：
> >
> > > Hi,
> > >
> > > Interesting proposal. How do you compare StreamPark with Apache Beam,
> > > Wayang, NiFI ?
> > >
> > > Thanks
> > >
> > > Regards
> > > JB
> > >
> > > On Wed, Aug 17, 2022 at 3:13 AM tison  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I would like to propose StreamPark[1] as a new apache incubator 
project,
> > > > you can find the proposal[2] of StreamPark for more detail.
> > > >
> > > > StreamPark is a streaming application development platform. Aimed 
at ease
> > > > building and managing streaming applications, StreamPark provides
> > > > scaffolding for writing streaming process logic with Apache Flink 
and
> > > > Apache Spark. Also, StreamPark provides a dashboard for controlling 
and
> > > > monitoring streaming tasks. It was initially known as StreamX and 
renamed
> > > > to StreamPark in August 2022.
> > > >
> > > > StreamPark abstracts the environment and program parameters of task
> > > > development and deployment in a convention over configuration 
manner for
> > > > low code development. It initializes a runtime environment and 
context
> > > and
> > > > combines it with a series of connectors to simplify development. 
From the
> > > > aspect of a task management platform, StreamPark is a streaming data
> > > > management platform based on the JVM platform.
> > > >
> > > > So far, StreamPark has accumulated a few users, and the accrued 
download
> > > > time is over 5,000. The representative users are Baidu, China 
Unicom,
> > > > Ziroom, Yonghui Supermarket, InMobi, YTO Express, and so on. 
StreamPark
> > > has
> > > > built an open-source community with 52 developers and released over 
ten
> > > > versions in the past year.
> > > >
> > > > The proposed initial committers are interested in joining ASF to 
increase
> > > > the connections in the open-source world. Based on extensive
> > > collaboration,
> > > > it is possible to build a community of developers and committers 
that
> > > live
> > > > longer than the founder. Also, the Apache Brand can help encourage 
more
> > > > organizations to use StreamPark more confidently.
> > > >
> > > > We believe that the StreamPark project will provide diversity value 
for
> > > the
> > > > community if StreamPark is introduced into the Apache incubator.
> > > >
> > > > I (@tison) will help this project as the champion and many thanks 
to four
> > > > other mentors:
> > > >
> > > > * Willem Ning Jiang [ningji...@apache.org]
> > > > * Stephan Ewen [se...@apache.org]
> > > > * Thomas Weise [t...@apache.org]
> > > > * Duo Zhang [zhang...@apache.org]
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > > [1] https://github.com/streamxhub/streamx
> > > > [2]
> > > >
> > > 
https://cwiki.apache.org/confluence/display/INCUBATOR/StreamPark+Proposal
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: 

Re: [DISCUSS] Incubating Proposal for StreamPark

[Christofer Dutz]

Hmmm how does it differentiate to what StreamPipes does?

Chris

Holen Sie sich Outlook für Android

From: Kelu Tao 
Sent: Thursday, August 18, 2022 4:39:28 PM
To: general@incubator.apache.org 
Subject: Re: [DISCUSS] Incubating Proposal for StreamPark

+1 (non-binding)

Look forward to see StreamPark in Apache "Park" :)

Best wishes,
Kelu

On 2022/08/17 01:13:14 tison wrote:
> Hi all,
>
> I would like to propose StreamPark[1] as a new apache incubator project,
> you can find the proposal[2] of StreamPark for more detail.
>
> StreamPark is a streaming application development platform. Aimed at ease
> building and managing streaming applications, StreamPark provides
> scaffolding for writing streaming process logic with Apache Flink and
> Apache Spark. Also, StreamPark provides a dashboard for controlling and
> monitoring streaming tasks. It was initially known as StreamX and renamed
> to StreamPark in August 2022.
>
> StreamPark abstracts the environment and program parameters of task
> development and deployment in a convention over configuration manner for
> low code development. It initializes a runtime environment and context and
> combines it with a series of connectors to simplify development. From the
> aspect of a task management platform, StreamPark is a streaming data
> management platform based on the JVM platform.
>
> So far, StreamPark has accumulated a few users, and the accrued download
> time is over 5,000. The representative users are Baidu, China Unicom,
> Ziroom, Yonghui Supermarket, InMobi, YTO Express, and so on. StreamPark has
> built an open-source community with 52 developers and released over ten
> versions in the past year.
>
> The proposed initial committers are interested in joining ASF to increase
> the connections in the open-source world. Based on extensive collaboration,
> it is possible to build a community of developers and committers that live
> longer than the founder. Also, the Apache Brand can help encourage more
> organizations to use StreamPark more confidently.
>
> We believe that the StreamPark project will provide diversity value for the
> community if StreamPark is introduced into the Apache incubator.
>
> I (@tison) will help this project as the champion and many thanks to four
> other mentors:
>
> * Willem Ning Jiang [ningji...@apache.org]
> * Stephan Ewen [se...@apache.org]
> * Thomas Weise [t...@apache.org]
> * Duo Zhang [zhang...@apache.org]
>
> Best,
> tison.
>
> [1] https://github.com/streamxhub/streamx
> [2]
> https://cwiki.apache.org/confluence/display/INCUBATOR/StreamPark+Proposal
>

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

RE: [DISCUSS] Tweak the incubator report template?

[Christofer Dutz]

Yeah,

I know that it will not propagate instantly. I just noticed that I generally 
would have added a comment to very many podlings about this and it should be 
easily fixable by adjusting the question.

And of course ... doesn't have to be that wording ... just generally say which 
information we'd like to see.

We might even kick the "since the last report... if no one was added since the 
last report ..." ... perhaps simply 
"when were the last PPMC members added and who were they?" and "when were the 
last committers added and who were they" should be ok too. At least for me it's 
important to see, if podlings are voting in new people, or not.

Chris


-Original Message-
From: Justin Mclean  
Sent: Freitag, 13. Mai 2022 09:59
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Tweak the incubator report template?

Hi,

It’s easy enough to change the headings, we would need to regenerate the 
pre-generated reports but’s that’s not a big deal.

The first change seems fine to me, for the second we might what to come up with 
something shorter.

Note that when we have tweaked the titles in the past, it tends to catch out 
projects that just copy and paste from previous reports :-)

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


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

[DISCUSS] Tweak the incubator report template?

[Christofer Dutz]

Hi all,



Just some things where I have been thinking of adding comments for 
clarification to the incubator report. Perhaps we could in general make this a 
bit simpler by tweaking the topics:



### Date of last release:

### Date and version of last release:





### When were the last committers or PPMC members elected?

### Who, when and in which role were new committers or PPMC members last 
elected? (If none were elected in the current reporting range, please add the 
last ones added)




Chris

Re: May 2022 Podling Reporting Timeline

[Christofer Dutz]

But reporting isn't the incubators way of punishing podling. It's the way we 
know how they are doing.

Yes it was our fault for not pinging them in time, but I really would love to 
see reports, that we missed.

But what do the others think?

Chris

Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg>

From: John D. Ament 
Sent: Thursday, April 21, 2022 2:29:16 PM
To: general 
Subject: Re: May 2022 Podling Reporting Timeline

Hi Christofer

On Thu, Apr 21, 2022 at 4:47 AM Christofer Dutz 
wrote:

> Hi John,
>
> guess I missed the second part of your email ;-)
>
> Well, I am a bit unsure if we really should skip the ones that for example
> missed to submit last month because nobody reminded them, but I think in
> such a case it would be half a year of information missing. Even if this
> might not be too useful for the board, I think it's useful to the IPMC.
>

Basically, I can't (personally) fault a podling for not reporting when no
reminders were sent out.  We failed to hold up our side of the agreement in
my mind.  It's great that some podlings still did the work to get a report
put together.  Perhaps we review those in the past 3 months of missed
reports and also report them? I'm not sure.


>
> So, I think podlings that missed filling in their parts in the last 3
> months, should still report this time. But that's just my opinion.
>

I agree with you, the problem is that every podling (other than new
podlings possibly) has missed a report (at least from the board's point of
view).  While there's the main review the IPMC takes on the podlings'
reports, the board also reviews them.  Since the IPMC lapsed on maintaining
this, it may end up over burdening the board to put out a report that has
every single podling reporting in it.


>
> Chris
>
> -Original Message-
> From: Christofer Dutz 
> Sent: Donnerstag, 21. April 2022 10:42
> To: general@incubator.apache.org
> Subject: RE: May 2022 Podling Reporting Timeline
>
> I should also add that some projects have failed to submit in the last 3
> months, so I would add to this list:
>
> - brpc
> - Annotator
> - Crail
> - EventMesh
> - Flagon
> - Hivemail
> - InLong
> - Liminal
> - Marvin-AI
> - Milagro
> - Nemo
> - Pony Mail
> - Spot
> - Teaclave
> - Wayang
>
> So, we're also expecting these projects to report this month.
>
> Chris
>
> -Original Message-
> From: John D. Ament 
> Sent: Mittwoch, 20. April 2022 18:24
> To: general 
> Subject: May 2022 Podling Reporting Timeline
>
> Note - I'm sending this a week early per procedure as we have some catch
> up to do.
>
> May 2022 Incubator report timeline:
>
> https://cwiki.apache.org/confluence/display/INCUBATOR/May2022
>
> Wed May 04 -- Podling reports due by end of day
> Sun May 08 -- Shepherd reviews due by end of day
> Sun May 08 -- Summary due by end of day
> Tue May 10 -- Mentor signoff due by end of day
> Wed May 11 -- Report submitted to Board
> Wed May 18 -- Board meeting
>
> According to podlings.xml, the following podlings are expected to report:
> - Training
> - Heron
> - Tuweni
> - Pagespeed
> - Toree
> - Livy
> - NLPCraft
> - Sedona
> - Doris
> - SDAP
> - Linkis
>
> I'm suggesting that right now we keep the current reporting periods as we
> the Incubator PMC have failed to report to the Board, rather than it
> necessarily being a failing of podlings.  If your podling is on this list
> but isn't present on the confluence page, please add it with the necessary
> sections.  i'll take a look in the next few days and make sure podlings.xml
> represents reality.
>
> - John, your friendly neighborhood Report Manager
>

RE: May 2022 Podling Reporting Timeline

[Christofer Dutz]

Hi John,

guess I missed the second part of your email ;-)

Well, I am a bit unsure if we really should skip the ones that for example 
missed to submit last month because nobody reminded them, but I think in such a 
case it would be half a year of information missing. Even if this might not be 
too useful for the board, I think it's useful to the IPMC.

So, I think podlings that missed filling in their parts in the last 3 months, 
should still report this time. But that's just my opinion.

Chris

-Original Message-
From: Christofer Dutz  
Sent: Donnerstag, 21. April 2022 10:42
To: general@incubator.apache.org
Subject: RE: May 2022 Podling Reporting Timeline

I should also add that some projects have failed to submit in the last 3 
months, so I would add to this list:

- brpc
- Annotator
- Crail
- EventMesh
- Flagon
- Hivemail
- InLong
- Liminal
- Marvin-AI
- Milagro
- Nemo
- Pony Mail
- Spot
- Teaclave
- Wayang

So, we're also expecting these projects to report this month.

Chris

-Original Message-
From: John D. Ament  
Sent: Mittwoch, 20. April 2022 18:24
To: general 
Subject: May 2022 Podling Reporting Timeline

Note - I'm sending this a week early per procedure as we have some catch up to 
do.

May 2022 Incubator report timeline:

https://cwiki.apache.org/confluence/display/INCUBATOR/May2022

Wed May 04 -- Podling reports due by end of day
Sun May 08 -- Shepherd reviews due by end of day
Sun May 08 -- Summary due by end of day
Tue May 10 -- Mentor signoff due by end of day
Wed May 11 -- Report submitted to Board
Wed May 18 -- Board meeting

According to podlings.xml, the following podlings are expected to report:
- Training
- Heron
- Tuweni
- Pagespeed
- Toree
- Livy
- NLPCraft
- Sedona
- Doris
- SDAP
- Linkis

I'm suggesting that right now we keep the current reporting periods as we the 
Incubator PMC have failed to report to the Board, rather than it necessarily 
being a failing of podlings.  If your podling is on this list but isn't present 
on the confluence page, please add it with the necessary sections.  i'll take a 
look in the next few days and make sure podlings.xml represents reality.

- John, your friendly neighborhood Report Manager

RE: May 2022 Podling Reporting Timeline

[Christofer Dutz]

I should also add that some projects have failed to submit in the last 3 
months, so I would add to this list:

- brpc
- Annotator
- Crail
- EventMesh
- Flagon
- Hivemail
- InLong
- Liminal
- Marvin-AI
- Milagro
- Nemo
- Pony Mail
- Spot
- Teaclave
- Wayang

So, we're also expecting these projects to report this month.

Chris

-Original Message-
From: John D. Ament  
Sent: Mittwoch, 20. April 2022 18:24
To: general 
Subject: May 2022 Podling Reporting Timeline

Note - I'm sending this a week early per procedure as we have some catch up to 
do.

May 2022 Incubator report timeline:

https://cwiki.apache.org/confluence/display/INCUBATOR/May2022

Wed May 04 -- Podling reports due by end of day
Sun May 08 -- Shepherd reviews due by end of day
Sun May 08 -- Summary due by end of day
Tue May 10 -- Mentor signoff due by end of day
Wed May 11 -- Report submitted to Board
Wed May 18 -- Board meeting

According to podlings.xml, the following podlings are expected to report:
- Training
- Heron
- Tuweni
- Pagespeed
- Toree
- Livy
- NLPCraft
- Sedona
- Doris
- SDAP
- Linkis

I'm suggesting that right now we keep the current reporting periods as we the 
Incubator PMC have failed to report to the Board, rather than it necessarily 
being a failing of podlings.  If your podling is on this list but isn't present 
on the confluence page, please add it with the necessary sections.  i'll take a 
look in the next few days and make sure podlings.xml represents reality.

- John, your friendly neighborhood Report Manager
--- Begin Message ---
I should also add that some projects have failed to submit in the last 3 
months, so I would add to this list:

-

-Original Message-
From: John D. Ament 
Sent: Mittwoch, 20. April 2022 18:24
To: general 
Subject: May 2022 Podling Reporting Timeline

Note - I'm sending this a week early per procedure as we have some catch up to 
do.

May 2022 Incubator report timeline:

https://cwiki.apache.org/confluence/display/INCUBATOR/May2022

Wed May 04 -- Podling reports due by end of day
Sun May 08 -- Shepherd reviews due by end of day
Sun May 08 -- Summary due by end of day
Tue May 10 -- Mentor signoff due by end of day
Wed May 11 -- Report submitted to Board
Wed May 18 -- Board meeting

According to podlings.xml, the following podlings are expected to report:
- Training
- Heron
- Tuweni
- Pagespeed
- Toree
- Livy
- NLPCraft
- Sedona
- Doris
- SDAP
- Linkis

I'm suggesting that right now we keep the current reporting periods as we the 
Incubator PMC have failed to report to the Board, rather than it necessarily 
being a failing of podlings.  If your podling is on this list but isn't present 
on the confluence page, please add it with the necessary sections.  i'll take a 
look in the next few days and make sure podlings.xml represents reality.

- John, your friendly neighborhood Report Manager
--- End Message ---

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

RE: [VOTE] Apache StreamPipes 0.69.0 (incubating) RC1 release

[Christofer Dutz]

Hmmm ... 

ok ... so it seems the other mentors of SP aren't responding or voting.

Perhaps we should instead start looking for a fresh batch of mentors. 

However, I think the project is doing great and I was thinking of suggesting 
them to go for graduation soon ... so we're just looking for one more +1 vote 
right now.

Would be great if someone here could spare a bit of time for doing that. The 
Release is pretty straightforward and doesn't contain loads of "special stuff", 
that needs manually being checked. They merged everything into one repo so it's 
only one artifact that needs to be validated.

Chris


-Original Message-
From: Calvin Kirs  
Sent: Mittwoch, 16. März 2022 07:00
To: general@incubator.apache.org
Subject: RE: [VOTE] Apache StreamPipes 0.69.0 (incubating) RC1 release

Hi,

+1(binding)

I checked:

- Download links are valid.
- LICENSE, DISCLAIMER, and NOTICE are good.
   (The NOTICE year should be 2019-2022, we better update it in the next 
version.)
- .sha & .asc checked
- Source files have license headers if necessary.

On 2022/03/15 11:32:15 Christofer Dutz wrote:
> Hi all ... 
> 
> it would be great if we could get at least one more IPMC to vote on 
> this
> 
> The StreamPipes team put specially a lot of effort into merging the initially 
> 3 separate repos into one to also make validating releases a lot easier. It 
> would be cool, if we could thank them by finally finding a 3rd vote (ideally 
> a +1 ;-) ).
> 
> Thanks,
> Chris
> 
> -Original Message-
> From: Zhang Yonglun 
> Sent: Dienstag, 15. März 2022 07:09
> To: general@incubator.apache.org
> Subject: Re: [VOTE] Apache StreamPipes 0.69.0 (incubating) RC1 release
> 
> Hi,
> 
> +1 (non binding)
> 
> I checked:
> - incubating in name
> - signatures and hashes are fine
> - Disclaimer exists
> - LICENSE and NOTICE exist
> - No unexpected binary files
> 
> Kindly reminder that maybe you would like to update the year in the NOTICE 
> file from 2022 to 2019-2022 before the next release.
> 
> --
> 
> Zhang Yonglun
> Apache ShenYu (Incubating)
> Apache ShardingSphere
> 
> Philipp Zehnder  于2022年3月11日周五 16:53写道：
> >
> > Hi all,
> >
> > this is a call for a vote to release Apache StreamPipes (incubating) 0.69.0.
> > Apache StreamPipes (incubating) is self-service Industrial IoT toolbox to 
> > enable non-technical users to connect, analyze and explore IIoT data 
> > streams.
> > The Apache StreamPipes community has voted on and approved a proposal to 
> > release Apache StreamPipes (incubating) 0.69.0.
> >
> > We now kindly request the Incubator PMC members to review and vote on this 
> > release.
> >
> > Vote and result threads from the StreamPipes community:
> > Result: 
> > https://lists.apache.org/thread/hmx9wtyjw6tqbx70gpvnr8tqcg0xxlcc
> > Vote: 
> > https://lists.apache.org/thread/b58pym522yqn4qbdym549xh440boy52p
> >
> > From the PPMC vote, we carry over 1 binding IPMC votes:
> > Christofer Dutz
> >
> > The vote will be open for at least 72 hours.
> >
> > Please vote accordingly:
> >
> > [] +1 approve (indicate what you validated - e.g., performed the 
> > checklist at [6]) [] +0 no opinion [] -1 reject (explanation 
> > required)
> >
> > One artifact is relevant for this vote:
> >
> > incubator-streampipes, staged at [1], available in Nexus at [2], 
> > release tag: release/0.69.0, hash for the release tag:
> > 6893604222cb9c3efc4bf66dc0c21e3223c2c84e
> >
> >
> > Per [3] "Before voting +1, [P]PMC members are required to download 
> > the signed source code package, compile it as provided, and test the 
> > resulting executable on their own platform, along with also verifying that 
> > the package meets the requirements of the ASF policy on releases."
> >
> > A release validation guide is available at [4]. The KEYS file is 
> > available at [5]
> >
> >
> > Thanks for taking your time for validating this release!
> >
> > Philipp
> >
> >
> > [1]
> > https://dist.apache.org/repos/dist/dev/incubator/streampipes/0.69.0/
> > rc
> > 1/ [2]
> > https://repository.apache.org/content/repositories/orgapachestreampi
> > pe
> > s-1016 [3] 
> > https://www.apache.org/dev/release.html#approving-a-release
> > [4]
> > https://cwiki.apache.org/confluence/display/STREAMPIPES/Validating+a
> > +r
> > elease [5]
> > https://dist.apache.org/repos/dist/dev/incubator/streampipes/KEYS
> >
> >
> >
> > 
> > - To u

RE: [VOTE] Apache StreamPipes 0.69.0 (incubating) RC1 release

[Christofer Dutz]

Hi all ... 

it would be great if we could get at least one more IPMC to vote on this

The StreamPipes team put specially a lot of effort into merging the initially 3 
separate repos into one to also make validating releases a lot easier. It would 
be cool, if we could thank them by finally finding a 3rd vote (ideally a +1 ;-) 
).

Thanks,
Chris

-Original Message-
From: Zhang Yonglun  
Sent: Dienstag, 15. März 2022 07:09
To: general@incubator.apache.org
Subject: Re: [VOTE] Apache StreamPipes 0.69.0 (incubating) RC1 release

Hi,

+1 (non binding)

I checked:
- incubating in name
- signatures and hashes are fine
- Disclaimer exists
- LICENSE and NOTICE exist
- No unexpected binary files

Kindly reminder that maybe you would like to update the year in the NOTICE file 
from 2022 to 2019-2022 before the next release.

--

Zhang Yonglun
Apache ShenYu (Incubating)
Apache ShardingSphere

Philipp Zehnder  于2022年3月11日周五 16:53写道：
>
> Hi all,
>
> this is a call for a vote to release Apache StreamPipes (incubating) 0.69.0.
> Apache StreamPipes (incubating) is self-service Industrial IoT toolbox to 
> enable non-technical users to connect, analyze and explore IIoT data streams.
> The Apache StreamPipes community has voted on and approved a proposal to 
> release Apache StreamPipes (incubating) 0.69.0.
>
> We now kindly request the Incubator PMC members to review and vote on this 
> release.
>
> Vote and result threads from the StreamPipes community:
> Result: 
> https://lists.apache.org/thread/hmx9wtyjw6tqbx70gpvnr8tqcg0xxlcc
> Vote: https://lists.apache.org/thread/b58pym522yqn4qbdym549xh440boy52p
>
> From the PPMC vote, we carry over 1 binding IPMC votes:
> Christofer Dutz
>
> The vote will be open for at least 72 hours.
>
> Please vote accordingly:
>
> [] +1 approve (indicate what you validated - e.g., performed the 
> checklist at [6]) [] +0 no opinion [] -1 reject (explanation required)
>
> One artifact is relevant for this vote:
>
> incubator-streampipes, staged at [1], available in Nexus at [2], 
> release tag: release/0.69.0, hash for the release tag: 
> 6893604222cb9c3efc4bf66dc0c21e3223c2c84e
>
>
> Per [3] "Before voting +1, [P]PMC members are required to download the 
> signed source code package, compile it as provided, and test the 
> resulting executable on their own platform, along with also verifying that 
> the package meets the requirements of the ASF policy on releases."
>
> A release validation guide is available at [4]. The KEYS file is 
> available at [5]
>
>
> Thanks for taking your time for validating this release!
>
> Philipp
>
>
> [1] 
> https://dist.apache.org/repos/dist/dev/incubator/streampipes/0.69.0/rc
> 1/ [2] 
> https://repository.apache.org/content/repositories/orgapachestreampipe
> s-1016 [3] https://www.apache.org/dev/release.html#approving-a-release
> [4] 
> https://cwiki.apache.org/confluence/display/STREAMPIPES/Validating+a+r
> elease [5] 
> https://dist.apache.org/repos/dist/dev/incubator/streampipes/KEYS
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

RE: [VOTE] Release Apache Wayang (Incubating) 0.6.0-RC9

[Christofer Dutz]

Common' folks ... 

please could some more people vote on this release ... the team worked so hard 
to resolve all of the issues pointed out, now let's help them get their first 
release out the door :-)

Chris

-Original Message-
From: Zhang Yonglun  
Sent: Dienstag, 7. Dezember 2021 12:51
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache Wayang (Incubating) 0.6.0-RC9

Hi,

+1 (non binding)

I checked:
- incubating in name
- signatures and hashes are fine
- Disclaimer exists
- LICENSE and NOTICE are fine
- All source have ASF headers
- No unexpected binary files

Hope this helps.
Maybe you would like to use this command to generate the hashes:
shasum -a 512
apache-wayang-${RELEASE.VERSION}-incubating-source-release.zip >
apache-wayang-${RELEASE.VERSION}-incubating-source-release.zip.sha512
After done that, one can check the hashes more simply by:
shasum -c
apache-wayang-${RELEASE.VERSION}-incubating-source-release.zip.sha512

--

Zhang Yonglun
Apache ShenYu (Incubating)
Apache ShardingSphere


Bertty Contreras  于2021年12月6日周一 19:02写道：

> Hello Incubator Community,
>
> The Apache Wayang community has voted on and approved a proposal to 
> release Apache Wayang(Incubating) version v0.6.0-RC9.
>
> We now kindly request the Incubator PMC members review and vote on 
> this incubator release.
>
> Wayang community vote thread:
> *https://www.mail-archive.com/dev@wayang.apache.org/msg00594.html
> *
>
> Vote result thread:
> *https://www.mail-archive.com/dev@wayang.apache.org/msg00608.html
> *
>
> [ ] +1 Release this package as Apache Wayang v0.6.0 [ ] +0 [ ] -1 Do 
> not release this package because ...
>
> To learn more about Apache Wayang (Incubating), please see 
> https://wayang.apache.org/
>
> Release notes:
> https://github.com/apache/incubator-wayang/blob/rel/0.6.0/RELEASE_NOTE
> S
>
> The tag to be voted on is wayang-0.6.0 (commit cb464b6):
> https://github.com/apache/incubator-wayang/tree/rel/0.6.0
>
> The release files, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/wayang/0.6.0/rc9
>
> Signatures used for Wayang RC's can be found in this file:
> *https://downloads.apache.org/incubator/wayang/KEYS
> *
>
> The staging repository for this release can be found at:
>
> https://repository.apache.org/content/repositories/orgapachewayang-101
> 0/org/apache/wayang/
>
> Build instructions:
>
> https://github.com/apache/incubator-wayang/blob/rel/0.6.0/README.md#ho
> w-to-use-wayang
>
> Thanks,
> Bertty Contreras Rojas
>

AW: [VOTE] Release Apache Wayang (Incubating) 0.6.0-RC5

[Christofer Dutz]

Hi all,

I have had a look at the code in question. And I have to admit that I agree 
with the Wayang folks. 

Yes ... it's about 10 lines of "code" initializing an array-like data structure 
... even if there might be a patten regarding the line lengths. It's not a 
simple substitution of letters, but the resulting graph has a different 
structure.

I wouldn't consider this something really being a violation of any copyrights.

I mean ... the code fragment in question is:

new char[]{'B', 'D'},
new char[]{'C', 'I'},
new char[]{'D', 'F', 'B'},
new char[]{'E', 'H', 'D', 'K'},
new char[]{'F', 'A', 'B'},
new char[]{'G', 'A', 'B'},
new char[]{'H', 'A', 'B'},
new char[]{'I', 'A', 'B'},
new char[]{'J', 'G'},
new char[]{'K', 'H'}

This is neither anything I would consider an algorithm, nor any form of 
notation, that I would see as being problematic.

So I hope I'll be able to find some time today to do my vote on this release 
... I would expect it to be a +1 considering the states the prior RCs have been 
in.

Chris



-Ursprüngliche Nachricht-
Von: Alexander Alten  
Gesendet: Sonntag, 7. November 2021 12:43
An: general@incubator.apache.org
Betreff: Re: [VOTE] Release Apache Wayang (Incubating) 0.6.0-RC5

Hi,

Ya, you’re right :) 

+1 (non-binding)

Compiled on Arm M1
Compiled on Windows
Licenses checked (rat)
Checksum checked
Incubation in name
ASF headers


> On 7. Nov 2021, at 12:34, Justin Mclean  wrote:
> 
> Hi,
> 
> I’ll also note that Alexander’s vote is non binding, best practice to 
> indicate it as such like so “+1 (non-binding)”. It also a good idea to list 
> what was checked in the release rather than just voting “+1". Only IPMC 
> members votes are binding on ASF incubator releases.
> 
> Kind Regards,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

AW: [VOTE] Release Apache Wayang (Incubating) 0.6.0

[Christofer Dutz]

+1 binding

Carrying over my +1 from the vote on the project list

Chris


-Ursprüngliche Nachricht-
Von: Alexander Alten  
Gesendet: Samstag, 23. Oktober 2021 14:44
An: general@incubator.apache.org
Betreff: Re: [VOTE] Release Apache Wayang (Incubating) 0.6.0

+1 (binding)

--alex

On Sat, Oct 23, 2021, 13:52 Bertty Contreras  wrote:

> Hello Incubator Community,
>
> The Apache Wayang community has voted on and approved a proposal to 
> release Apache Wayang(Incubating) version v0.6.0-RC4.
>
> We now kindly request the Incubator PMC members review and vote on 
> this incubator release.
>
> Wayang community vote thread:
> https://www.mail-archive.com/dev@wayang.apache.org/msg00446.html
>
> Vote result thread:
> https://www.mail-archive.com/dev@wayang.apache.org/msg00458.html
>
> [ ] +1 Release this package as Apache Wayang v0.6.0 [ ] +0 [ ] -1 Do 
> not release this package because ...
>
> To learn more about Apache Wayang (Incubating), please see 
> https://wayang.apache.org/
>
> Release notes:
> https://github.com/apache/incubator-wayang/blob/rel/0.6.0/RELEASE_NOTE
> S
>
> The tag to be voted on is wayang-0.6.0 (commit 9fe19a1):
> https://github.com/apache/incubator-wayang/tree/rel/0.6.0
>
> The release files, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/wayang/0.6.0/rc4
>
> Signatures used for Wayang RC's can be found in this file:
> https://dist.apache.org/repos/dist/dev/incubator/wayang/KEYS
>
> The staging repository for this release can be found at:
>
> https://repository.apache.org/content/repositories/orgapachewayang-100
> 5/org/apache/wayang
>
> Build instructions:
>
> https://github.com/apache/incubator-wayang/blob/rel/0.6.0/README.md#ho
> w-to-use-wayang
>
> Thanks,
> Bertty Contreras Rojas
>

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

Re: [VOTE] Apache StreamPipes 0.68.0 (incubating) RC1 release

[Christofer Dutz]

Hi Dominik,

replying as I can't recall the last email landing in my inbox.

Would be cool if some fellow IPMCs could provide at least two more votes 
on this release.

Thanks,
Chris



On 19.07.21 10:12, Dominik Riemer wrote:
> Hi,
> 
> thanks for everyone who has voted so far!
> 
> We are currently missing two IPMC-binding votes for release approval.
> 
> It would be great if two more IPMC members could find some time to vote on 
> our release candidate.
> 
> Thanks!
> Dominik
> 
> On 2021/07/15 02:13:00, Xun Liu  wrote:
>> +1 (non-binding) from me, I have checked the following items:
>>
>> - Incubating in name
>> - NOTICE is fine
>> - DISCLAIMER exists
>> - All links are valid
>> - All ASF files have ASF headers
>> - Download all staged artifacts under the url specified in the release vote
>> email
>> - Unzip the archive
>> - Run RAT
>> - Build Backend
>> - Build UI
>> - Build Extensions
>> - Build and Run Test system on Docker
>> - Verify the signature is correct
>> - Verify the SHA512 checksum
>>
>> Best regards
>> Xun Liu
>>
>> On Thu, Jul 15, 2021 at 4:00 AM Dominik Riemer  wrote:
>>
>>> Hi all,
>>>
>>> this is a call for a vote to release Apache StreamPipes (incubating)
>>> 0.68.0.
>>> Apache StreamPipes (incubating) is self-service Industrial IoT toolbox to
>>> enable non-technical users to connect, analyze and explore IIoT data
>>> streams.
>>> The Apache StreamPipes community has voted on a proposal to release Apache
>>> StreamPipes (incubating) 0.68.0
>>>
>>> We now kindly ask the Incubator PMC members to review and vote on this
>>> release.
>>>
>>> Vote and result threads from the StreamPipes community:
>>> Result:
>>>
>>> https://lists.apache.org/thread.html/r61928e5e971812dc271fe678c7e9e3202622a8
>>> 442635da94f9034f00%40%3Cdev.streampipes.apache.org%3E
>>> Vote:
>>>
>>> https://lists.apache.org/thread.html/r0164a14c229a459a05ff305506238608575270
>>> bf5a57111eed2dff3d%40%3Cdev.streampipes.apache.org%3E
>>>
>>>  From the PPMC vote, we carry over 1 binding IPMC vote:
>>> Christofer Dutz
>>>
>>> The vote will be open for at least 72 hours.
>>>
>>> Please vote accordingly:
>>>
>>> [] +1 approve (indicate what you validated - e.g., performed the checklist
>>> at [6])
>>> [] +0 no opinion
>>> [] -1 reject (explanation required)
>>>
>>> Three artifacts are relevant for this vote:
>>>
>>> incubator-streampipes, staged at [1], available in Nexus at [2], release
>>> tag: release/0.68.0, hash for the release tag:
>>> 46859a0e7e9003186e82cc9b96068e83993bd3f0
>>> incubator-streampipes-extensions, staged at [3], release tag:
>>> release/0.68.0, hash for the release tag:
>>> e387384a52470ab771e2f19c9e9347355b699e7e
>>> incubator-streampipes-installer, staged at [4], release tag:
>>> release/0.68.0,
>>> hash for the release tag: 1d6bc511debc83f63b78cf33f1bfc5efef2da0ce
>>>
>>> Per [5] "Before voting +1, [P]PMC members are required to download the
>>> signed source code package,
>>> compile it as provided, and test the resulting executable on their own
>>> platform,
>>> along with also verifying that the package meets the requirements of the
>>> ASF
>>> policy on releases."
>>>
>>> A release validation guide is available at [6]. The KEYS file is available
>>> at [7]
>>>
>>> As we are missing two more IPMC-binding votes, we would really appreciate
>>> if
>>> any IPMC member would be willing to review our release candidate. Thanks
>>> for
>>> your support!
>>>
>>> Dominik
>>>
>>> [1]
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/streampipes/core/0.68.0/rc1
>>> [2]
>>>
>>> https://repository.apache.org/content/repositories/orgapachestreampipes-1012
>>> [3]
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/streampipes/extensions/0.68
>>> .0/rc1
>>> [4]
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/streampipes/installer/0.68.
>>> 0/rc1
>>> <https://dist.apache.org/repos/dist/dev/incubator/streampipes/installer/0.68.0/rc1>
>>> [5] https://www.apache.org/dev/release.html#approving-a-release
>>> [6]
>>>
>>> https://cwiki.apache.org/confluence/display/STREAMPIPES/Validating+a+release
>>> [7] https://dist.apache.org/repos/dist/dev/incubator/streampipes/KEYS
>>>
>>>
>>>
>>>
>>> -
>>> 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: Champion and Mentors wanted for new potential Apache SST incubator project

[Christofer Dutz]

Hi Lothar,

after a call with you and comparing that to the proposal, I think it 
would be great if you could explain a little bit more on a concrete 
example what SST does, which problem it solves and how it differs from 
existing solutions.

For me at first the proposal was pretty lengthy but stayed so vague with 
WHAT it actually is, that this didn't trigger my interest at first. 
Perhaps being a little more concrete will help get some responses here.

Chris










On 09.06.21 14:07, Lothar Klein wrote:
> Dear IPMC members,
> 
> We are looking for a Champion and Mentors for the new SST incubator 
> project proposal; see below.
> So far I contacted Justin Mclean and Christofer Dutz and they are 
> considering to become mentors.
> 
> Best Regards
> Lothar
> 
> 
> === Abstract ===
> 
> SST (Semantic STEP Technology) is an optimized RDF/OWL API with
> GIT like revision control capabilities as an enabler for a new
> comprehensive CAD/CAx data model derived from ISO 10303 (STEP)
> and ISO 15926 (Oil & Gas) standards.
> 
> === Rationale: The Problem to solve ===
> 
> There are many different kinds of Computer-aided technology
> (CAx) systems around. Some are listed here:
> => https://en.wikipedia.org/wiki/Computer-aided_technologies
> 
> For all organizations that are involved in the design,
> production, maintenance and commercial use of industrial
> products a smooth exchange of data between these tools would be
> needed. Also please have in mind that for most industrial
> production a big supply network has be coordinated; each with
> it’s own specific tools.
> 
> The reality is that data exchange between these system is often
> not possible and if available the interface tools are
> incomplete as they exchange only some, but not all needed data.
> The problem get even worse as often the systems have to be used
> in a cyclic iterative way to deal with design changes. The
> truth is also that for all CAx systems a big part of the
> software development power (if not the biggest part) is spent
> on the interfaces to other system, not on the core
> functionality the system provides.
> 
> STEP is a big attempt to address this issue. In the
> introduction of ISO 10303-1:1994 "Overview and fundamental
> principles" and extended in the 2021 edition we can read:
> 
> "ISO 10303 is an International Standard for the
> computer-interpretable representation of product information
> and for the exchange of product data. The objective is to
> provide a neutral mechanism capable of describing products
> throughout their life cycle. This mechanism is suitable not
> only for neutral file exchange, but also as a basis for
> implementing and sharing product databases, and as a basis for
> archiving. The information generated about a product during its
> design, manufacture, use, maintenance, and disposal is used for
> many purposes. The use can involve many computer systems,
> including some that can be located in different organizations.
> In order to support such uses, organizations need to be able to
> represent their product information in a common
> computer-interpretable form that is required to remain complete
> and consistent when exchanged among different computer
> systems."
> => https://www.iso.org/obp/ui/#iso:std:iso:10303:-1:ed-2:v1:en
> 
> In the introduction of ISO 15926-1:2004 "Overview and
> fundamental principles" we can see slightly different but
> highly overlapping goals:
> => https://www.iso.org/obp/ui/#iso:std:iso:15926:-1:ed-1:v1:en
> 
> The goals of the ISO 10303 and 15926 series of standards are
> only very partially achieved in practice today.
> 
> The aim of the SST project is to make the visions of these
> standards a reality by providing an open source environment
> that is suitable to directly operate on distributed data on servers
> managed by different organizations.
> 
> === Background ===
> 
> ISO 10303 and ISO 15926 and other series of standards are
> developed by the ISO Technical Committee 184: Automation
> Systems and Integration, Subcommittee 4: Industrial data. In
> its resolution number 9 from March 1985 the overall goal was
> expressed as: "To develop as soon as possible a single
> international standard for the exchange of product definition
> data to be called the standard for the exchange of product
> model data (STEP)." It took almost 10 years (1994/95) till the
> publication of the first set of standards. The geometric data
> models and assembly structures developed back then are today
> widely implemented by CAD and other systems. Since then the
> STEP standard grew constantly with lots of new application
> areas and layers of abstraction; but with

AW: [VOTE] Graduate Apache Daffodil to a top-level project

[Christofer Dutz]

+1 (binding)

Chris

-Ursprüngliche Nachricht-
Von: Dave Fisher  
Gesendet: Mittwoch, 10. Februar 2021 01:01
An: general@incubator.apache.org
Betreff: Re: [VOTE] Graduate Apache Daffodil to a top-level project

+1 (binding)

Regards,
Dave

Sent from my iPhone

> On Feb 9, 2021, at 2:03 PM, Mike Beckerle  wrote:
> 
> Folks,
> 
> I would now call for people to please officially vote on this proposal.
> 
> This vote thread will be open for 72 hours - ending on Friday Feb 12, 
> 5:15pm ET.US (UTC-5)
> 
> The discussion thread already contained votes (eleven +1, including 4 
> binding, and no 0 or -1), and no negative discussion points, so I am 
> incorporating that thread by reference here.
> 
> Discussion thread:
> https://lists.apache.org/thread.html/r1340f079a36ccc7498231eebbe9a5a0e
> 69570f436d213fa665ca48c0%40%3Cgeneral.incubator.apache.org%3E
> 
> 
> The draft board proposal is below for your review. As you all know 
> this is business boilerplate except for our project name, charter 
> statement, the original PMC slate, and VP/Chairperson put forward.
> 
> 
> Regards,
> Mike Beckerle
> Daffodil PMC Chair Elect, Committer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *Establish the Apache Daffodil 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 an
> implementation of the Data Format Description Language (DFDL) used to
> convert between fixed format data and more readily processed forms such
> as XML or JSON.*
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee 
> (PMC), to be known as the "Apache Daffodil Project", be and hereby is 
> established pursuant to Bylaws of the Foundation; and be it further 
> RESOLVED, that the Apache Daffodil Project be and hereby is 
> responsible for the creation and maintenance of software related to an 
> implementation of the Data Format Description Language (DFDL) used to 
> convert between fixed format data and more readily processed forms 
> such as XML or JSON; and be it further*
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *RESOLVED, that the office of "Vice President, Apache Daffodil" 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 
> Daffodil Project, and to have primary responsibility for management of 
> the projects within the scope of responsibility of the Apache Daffodil
> 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 Daffodil Project:*
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *  * Brandon Sloane>  *
> Christofer Dutz   >  * Dave Fisher
>  >  * Dave Thompson
> >  * John Interrante
> >  * John Wass
> >  * Joshua Adams
> >  * Kevin Ratnasekera
> >  * Mike Beckerle
> >  * Steve Lawrence
> >  * Taylor Wise
> >  * Olabusayo Kilo
> >*
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> * NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mike Beckerle be 
> appointed  to the office of Vice President, Apache Daffodil, 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 Daffodil Project be and hereby is
> tasked with the migration and rationalization of the Apache Incubator
> Daffodil podling; and be it further RESOLVED, that all
> responsibilities pertaining to the Apache Incubator Daffodil 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

AW: [DISCUSS] Graduate Apache Daffodil to a top-level project

[Christofer Dutz]

Carrying over my +1 (binding) from the project

Chris

-Ursprüngliche Nachricht-
Von: Alexander Alten-Lorenz  
Gesendet: Donnerstag, 4. Februar 2021 22:51
An: general@incubator.apache.org
Betreff: Re: [DISCUSS] Graduate Apache Daffodil to a top-level project

+1 non-binding. 

Apache Daffodil is a great addition the the ASF community and codebase, it’s 
active and in use. And I personally like it :) 

Thanks,
—Alex 

Sent from my iPhone

> On 4. Feb 2021, at 21:35, Dave Fisher  wrote:
> 
> Hi -
> 
> I’m +1 for Daffodil to go to TLP.
> 
> They have been active and operating in the Apache Way for a long time. They 
> participate in Apachecon.
> 
> Slowness was with Community Growth and they have managed to grow their 
> community in the last year.
> 
> Regards,
> Dave
> 
>> On Feb 4, 2021, at 11:01 AM, Mike Beckerle  wrote:
>> 
>> Incubator Folks,
>> 
>> We have completed a vote on our community list 
>> d...@daffodil.apache.org as
>> follows:
>> 
>> Vote Thread:
>> https://lists.apache.org/thread.html/r91af73ae28284945ffe881cea787776
>> 6213eaa405da21e233d85eb83%40%3Cdev.daffodil.apache.org%3E
>> 
>> In summary, we have all +1 votes including all 3 mentors.
>> 
>> Our maturity model can be reviewed here:
>> 
>> https://cwiki.apache.org/confluence/display/DAFFODIL/Apache+Daffodil+
>> Maturity+Model+Assesment
>> 
>> If there is anyone in the IPMC that has any questions or concerns 
>> that would block our ability to graduate, please bring these issues 
>> into this discussion.
>> 
>> Unless there are issues that need to be resolved, this discussion 
>> will end next Tuesday, Feb 8 2021. 5pm ET.US (UTC-5) (that is 72 
>> hours of weekdays)
>> 
>> If this discussion produces a positive consensus or no objections, I 
>> will proceed to a vote using lazy consensus 
>> https://www.apache.org/foundation/voting.html.
>> 
>> Regards,
>> Mike Beckerle
>> Daffodil PPMC, Committer
> 
> 
> -
> 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

[RESULT] [VOTE] Accept Wayang into the Apache Incubator

[Christofer Dutz]

So the vote passes:

8 binding +1 votes (All nominated  mentors voted)
3 non-binding +1 votes

No 0 or -1 votes

https://lists.apache.org/thread.html/ra8e804fadca573af0f053df56686c98dbeaf1e8d1cba7228b16a637e%40%3Cgeneral.incubator.apache.org%3E

Binding:
Dave Fisher
Kevin Ratnasekera
Furkan KAMACI
Byung-Gon Chun
Sheng Wu
Lars George
Jean-Baptiste Onofre
Bernd Fondermann

Non-Binding:
Alexander Alten-Lorenz
Daniel B. Widdis
Xiangdong Huang


-Ursprüngliche Nachricht-
Von: Xiangdong Huang 
Gesendet: Montag, 14. Dezember 2020 07:28
An: general@incubator.apache.org
Betreff: Re: [VOTE] Accept Wayang into the Apache Incubator

+1 (non-binding)
---
Xiangdong Huang
School of Software, Tsinghua University


Lars George  于2020年12月12日周六 下午8:19写道：

> +1 binding
>
> On Sat, Dec 12, 2020 at 2:24 AM Sheng Wu 
> wrote:
>
> > +1 binding
> >
> > Sheng Wu 吴晟
> > Twitter, wusheng1108
> >
> >
> > Byung-Gon Chun  于2020年12月12日周六 上午5:59写道：
> >
> > > +1 (binding)
> > >
> > > -Gon
> > >
> > > On Sat, Dec 12, 2020 at 2:35 AM Furkan KAMACI
> > > 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > +1 (binding)
> > > >
> > > > Kind Regards,
> > > > Furkan KAMACI
> > > >
> > > > On 11 Dec 2020 Fri at 20:04 Daniel B. Widdis 
> wrote:
> > > >
> > > > > +1 (non-binding).  I'm interested in getting involved in this
> > project!
> > > > >
> > > > > On Fri, Dec 11, 2020 at 8:33 AM Christofer Dutz <
> > > > christofer.d...@c-ware.de
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > following up the [DISCUSS] thread on Wayang (
> > > > > >
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/r5fc03ae014f44c7c31a509a6db4ac07f
> aedb2e1c6245cd917b744826%40%3Cgeneral.incubator.apache.org%3E
> > > > > )
> > > > > > I would like to call a VOTE to accept Wayang Aka Rheem into
> > > > > > the
> > > Apache
> > > > > > Incubator.
> > > > > >
> > > > > > Please cast your vote:
> > > > > >
> > > > > >   [ ] +1, bring Wayang into the Incubator
> > > > > >   [ ] +0, I don't care either way
> > > > > >   [ ] -1, do not bring Wayang into the Incubator, because...
> > > > > >
> > > > > > The vote will open at least for 72 hours and only votes from
> > > > > > the
> > > > > Incubator
> > > > > > PMC are binding, but votes from everyone are welcome.
> > > > > >
> > > > > > Chris
> > > > > >
> > > > > > -
> > > > > >
> > > > > > Wayang Proposal (
> > > > > >
> > https://cwiki.apache.org/confluence/display/INCUBATOR/WayangProposal
> > > )
> > > > > >
> > > > > > == Abstract ==
> > > > > >
> > > > > > Wayang is a cross-platform data processing system that aims
> > > > > > at
> > > > decoupling
> > > > > > the business logic of data analytics applications from
> > > > > > concrete
> > data
> > > > > > processing platforms, such as Apache Flink or Apache Spark.
> Hence,
> > it
> > > > > tames
> > > > > > the complexity that arises from the "Cambrian explosion" of
> > > > > > novel
> > > data
> > > > > > processing platforms that we currently witness.
> > > > > >
> > > > > > Note that Wayang project is the Rheem project, but we have
> renamed
> > > the
> > > > > > project because of trademark issues.
> > > > > >
> > > > > > You can find the project web page at:
> > > > https://rheem-ecosystem.github.io/
> > > > > >
> > > > > > = Proposal =
> > > > > >
> > > > > > Wayang is a cross-platform system that provides an
> > > > > > abstraction
> over
> > > > data
> > > > > > processing platforms to free users from the burdens of (i)
> > performing
> > > > > > tedious and costly data migration a

[VOTE] Accept Wayang into the Apache Incubator

[Christofer Dutz]

ome for Wayang to achieve this.

=== Documentation ===

Further details, documentation, and publications related to Wayang can be found 
at https://docs.rheem.io/rheem/

=== Initial Source ===

The current source code of Wayang resides in Github:
https://github.com/rheem-ecosystem/rheem

=== External Dependencies ===

Wayang depends on the following Apache projects:

* Maven
* HDFS
* Hadoop
* Spark

Wayang depends on the following other open source projects organized by license:

org.json.json: Json (http://json.org/license.html) 
SnakeYAML: Apache 2.0
Java Unified Expression Language API (Juel): Apache 2.0
ProfileDB Instrumentation: Apache 2.0
Gson: Apache 2.0
Hadoop: Apache 2.0
Scala: Apache 2.0
Antlr 4: BSD
Jackson: Apache 2.0
Junit 5: EPL 2.0
Mockito: MIT
Assertj: Apache 2.0
logback-classic: EPL 1.0 LGPL 2.1
slf4j: MIT
GNU Trove: LGPL 2.1
graphchi: Apache 2.0
SQLite JDBC: Apache 2.0
PostgreSQL: BSD 2-clause
jcommander: Apache 2.0
Koloboke Collections API: Apache 2.0
Snappy Java: Apache 2.0
Apache Spark: Apache 2.0
HyperSQL Database: BSD Modified (http://hsqldb.org/web/hsqlLicense.html) 
Apache Giraph: Apache 2.0
Apache Flink: Apache 2.0
Apache Commons IO: Apache 2.0
Apache Commons Lang: Apache 2.0
Apache Maven: Apache 2.0

=== Cryptography ===

(not applicable)

=== Required Resources ===

** Mailing Lists **

* mailto:priv...@wayang.incubator.apache.org
* mailto:d...@wayang.incubator.apache.org
* mailto:comm...@wayang.incubator.apache.org

** Git repositories **

git://git.apache.org/repos/asf/incubator/wayang

** Issue tracking **

https://issues.apache.org/jira/browse/RHEEM

=== Initial Committers ===

The following list gives the planned initial committers (in alphabetical order):

* Bertty Contreras-Rojas http://scalytics.io>
* Rodrigo Pardo-Meza http://scalytics.io>
* Alexander Alten-Lorenz http://scalytics.io>
* Zoi Kaoudi http://tu-berlin.de>
* Haralampos Gavriilidis http://tu-berlin.de>
* Jorge-Arnulfo Quiane-Ruiz http://tu-berlin.de>
* Anis Troudi http://hbku.edu.qa>
* Wenceslao Palma-Muñoz http://pucv.cl>

** Affiliations **

* Scalytics Inc.
** Bertty Contreras-Rojas
** Rodrigo Pardo-Meza
** Alexander Alten-Lorenz
* Berlin Institute of Technology (TU Berlin)
** Zoi Kaoudi
** Haralampos Gavriilidis
** Jorge-Arnulfo Quiane-Ruiz
* Hamad Bin Khalifa University (HBKU)
** Anis Troudi
* Pontifical Catholic University of Valparaiso, Chile (PUCV)
** Wenceslao Palma-Muñoz

=== Sponsors ===

** Champion **

* Christofer Dutz (christofer.dutz at c-ware dot de)

** Mentors **

. (cdutz) Christofer Dutz
. (larsgeorge) Lars George
. (berndf) Fondermann
. (jbonofre) Jean-Baptiste Onofré

** Sponsoring Entity **

The Apache Incubator









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

AW: [DISCUSS] Wayang Proposal

[Christofer Dutz]

Hi Bernd,

I just didn't want to leave the impression, that "we're full". So if anyone 
here would be interested in joining, he/she is more than welcome.

I know that 3 is enough, but I also have seen that when starting with 3 initial 
mentors, usually 1 or 2 get lost some time after the incubation starts.

So I guess we'll start with the 3 we have and take care of finding new mentors 
as needed, if needed.


Chris



-Ursprüngliche Nachricht-
Von: Bernd Fondermann  
Gesendet: Montag, 7. Dezember 2020 10:33
An: general@incubator.apache.org
Betreff: Re: [DISCUSS] Wayang Proposal

+1
If three mentors for Wayang are not enough (I'm one of them), how much would a 
incubating project need?

  Bernd

On Sun, Dec 6, 2020 at 12:43 PM Justin Mclean 
wrote:

> Hi,
>
> > Right now, there are 3 people signed up as mentors, however knowing 
> > that
> not always are all mentors available at every given time, it would be 
> cool if we could find 1-2 more to help out.
>
> In no way reflecting on the mentors who have volunteered and I’m sure 
> they will do a good job
>
> In recent times I've notice that incubating projects with a large 
> number of initial mentors seem to have a very slow start. I’m not sure 
> if the issue is that each mentor assumes someone else will do the job 
> or something else but 3 initial mentors seems to be the sweet spot.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

AW: [DISCUSS] Wayang Proposal

[Christofer Dutz]

Hi and welcome on this new communication channel.

I'd like to add, that I really liked how the project approached me and how they 
reacted when I told them the old project name Rheem would probably not go down 
well and that I would suggest changing the name. 

I gave them some tips what things are important for Apache and what we lay 
emphasis on and the team started brainstorming and doing all the trademark 
checks, taking options off the list where problems could be expected.

So, upon acceptance here, the project would do the renaming together with the 
groupId and package changing, which would be required anyway. 

Right now, there are 3 people signed up as mentors, however knowing that not 
always are all mentors available at every given time, it would be cool if we 
could find 1-2 more to help out.


Chris



-Ursprüngliche Nachricht-
Von: Bertty Contreras  
Gesendet: Freitag, 4. Dezember 2020 17:16
An: general@incubator.apache.org
Cc: Alexander Alten-Lorenz ; Rodrigo Pardo Meza 

Betreff: [DISCUSS] Wayang Proposal

Dear all,

Rodrigo and Bertty, Senior Software Engineers at Scalytics, are two of the main 
developers of the Wayang system. We write to you because we would like to bring 
your attention to our Proposal for Incubation in the Apache foundation at 
https://cwiki.apache.org/confluence/display/INCUBATOR/WayangProposal

Please note that Wayang was named Rheem before, but we had to rename the 
project because of trademark issues.
You can find the original project web page at:
https://rheem-ecosystem.github.io/

Best,
Bertty

Re: [VOTE] Release Apache Daffodil (incubating) 3.0.0-rc1

[Christofer Dutz]

+1 (binding) 

Tested on my Mac using java 13 using SBT 1.3.4

[OK] Download all staged artifacts under the url specified in the release vote 
email into a directory we’ll now call download-dir.
[OK] Verify the signature is correct: Additional Apache tutorial on how to 
verify downloads can be found here.
[MINOR] Check if the signature references an Apache email address.
[OK] Verify the SHA512 hashes
[OK] Unzip the archive
[MINOR] Verify the existence of DISCLAIMER, LICENSE, NOTICE, README, 
RELEASE_NOTES files in the extracted source bundle.
[OK] Verify the content of DISCLAIMER, LICENSE, NOTICE, README, RELEASE_NOTES 
files in the extracted source bundle.
[OK] Run RAT externally to ensure there are no surprises.
[OK] Search for SNAPSHOT references:
[OK] Search for Copyright references, and if they are in headers, make sure 
these files containing them are mentioned in the LICENSE file.
[MINOR] Build the project according to the information in the README.md file.

Generally as the "compile" and "test" builds worked, I consider this a 
slightly-severe-MINOR ... however you should address that ASAP.

Notes:

- GPG signature has no trust chain
- No RELEASE_NOTES
- running "sbt it:test" fails
- running "sbt daffodil-cli/stage" fails
- running "sbt ratCheck" fails
- running "sbt clean coverage test it:test" fails (giving up now)
- It would be cool, if you could remove all of the ".keep" files (most are no 
longer needed and they do extend the list of rat findings quite a bit)
- The sources contains license file in: 
apache-daffodil-3.0.0-incubating-src/daffodil-lib/src/main/scala/passera/BSD-LICENSE.txt
 this should be moved to a more prominent location (I like to put these license 
texts in a "licenses" directory in the root of the project and inside I add to 
the end which files in the repo it applies to)
- It appears you manually added LICENSE and NOTICE files to every artifact in 
the repo (this means editing the NOTICE files for every first release of a 
year. Maven has a plugin to automatically add these to artifacts, perhaps 
there's an SBT way to do that too?


Am 10.11.20, 13:51 schrieb "Steve Lawrence" :

Remdiner to please take a look at this vote if you get a chance. We only 
have two mentors so we will need at least one vote from another IPMC member.

Thanks!

On 2020/11/04 16:30:28, Steve Lawrence  wrote: 
> 
> The Apache Daffodil community has voted and approved the proposed
> release of Apache Daffodil (incubating) 3.0.0-rc1.
> 
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
> 
> Daffodil is an open source implementation of the DFDL specification that
> uses DFDL schemas to parse fixed format data into an infoset, which is
> most commonly represented as either XML or JSON. This allows the use of
> well-established XML or JSON technologies and libraries to consume,
> inspect, and manipulate fixed format data in existing solutions.
> Daffodil is also capable of the reverse by serializing or "unparsing" an
> XML or JSON infoset back to the original data format.
> 
> Vote thread:
> 
https://lists.apache.org/thread.html/r4352b6907245d31b556d1fb977c7c7261487174f99e723c0cf77fad8%40%3Cdev.daffodil.apache.org%3E
> 
> Result thread:
> 
https://lists.apache.org/thread.html/rb08b144b848350c6f29af0bad64570a1cc77d37d296129d26aedbe0a%40%3Cdev.daffodil.apache.org%3E
> 
> All distribution packages, including signatures, digests, etc. can be
> found at:
> 
> https://dist.apache.org/repos/dist/dev/incubator/daffodil/3.0.0-rc1/
> 
> Staging artifacts can be found at:
> 
> https://repository.apache.org/content/repositories/orgapachedaffodil-1019/
> 
> This release has been signed with PGP key 36F3494B033AE661, corresponding
> to slawre...@apache.org, which is included in the KEYS file here:
> 
> https://downloads.apache.org/incubator/daffodil/KEYS
> 
> The release candidate has been tagged in git with v3.0.0-rc1.
> 
> For reference, here is a list of all closed JIRAs tagged with 3.0.0:
> 
> https://s.apache.org/daffodil-issues-3.0.0
> 
> For a summary of the changes in this release, see:
> 
> https://daffodil.apache.org/releases/3.0.0/
> 
> Please review and vote. The vote will be open for at least 72 hours
> (Saturday, 07 November 2019, 12 Noon EST).
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> -
> 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: 

Apache Training (incubating) granted all Apache committers commit rights

[Christofer Dutz]

Hi,

We, the Apache Training PPMC, would like to tell you about an important
update by which you can promote & train people on your Apache project:
We're opening up commit access to all Apache committers.

We at Apache build all sorts of great software. Some people even create
training projects for Apache projects.
With the enormous pace of most of the projects, it's almost impossible to
keep training material up-to-date.
And even if you might know a given project, preparing training material
might be too much.
Also, even if you are a great coder, whipping up cool presentations might
not be your favourite thing to do.

Apache Training was created especially to help with all of this.

We created a framework for creating presentations in a coder friendly way
with features like versioning, tagging etc.
It is a RevealJS based presentation-framework using Asciidoctor; A
Markdown-like format but with a lot more control over the output and
additional features.
The primary supported build system is Maven. However, if you prefer, you
can also build your presentation with Ruby and Node.JS (The latter two are
still experimental).

The output is a Browser-based presentation with a dedicated speaker view,
which also allows exporting your presentation into PDF format for
distribution.

We would like to make Apache Training the place you look first if you are
in need of Apache related training or presentation material.

As you probably know your projects best, who would be better suited to help
with creating this material, if not you?

*Important Update*
That's why the Apache Training PPMC has turned on the commit permissions
for all Apache committers.

We trust that you will use these rights wisely. However, we do have one
restriction:
If you want to contribute to the fundamental presentation framework and the
tooling, please use PRs.
But when it comes to content, feel free to add and/or edit content for your
projects inside the 'content' directory as you see fit.
Please however exercise common sense about whether or not a PR is
appropriate, when changing content that other people created.

Note:
It seems that we can only grant all committers commit access on gitbox
and not on Github, so be sure to set our gitbox repo as "upstream" when
trying to commit:
https://gitbox.apache.org/repos/asf?p=incubator-training.git


*Please see this link for samples*
https://github.com/apache/incubator-training/tree/develop/content <
https://github.com/apache/incubator-training/tree/develop/content>


*Easy Steps to Create a Presentation*
To get you started in no-time, we provide Maven archetypes for generating
your presentation skeleton. In order to use this please just run:

mvn archetype:generate -DarchetypeGroupId=org.apache.training
-DarchetypeArtifactId=content-archetype -DarchetypeVersion=1.0.0

This will ask you for a group-id, artifact-id, version and a package-name
and as soon as you have provided them, will generate your new presentation.

To now build the presentation, change into the freshly created directory
and run:

mvn package

You can then run your presentation by opening the following file in your
browser:

target/generated-slides/index.html

We hope Apache Training will help you and your projects.

*The Apache Training (incubating) PPMC*

[NOTICE] The Apache Training (incubating) pooling has just finished a vote to turn on the commit bit for all apache committers ...

[Christofer Dutz]

Hi all,

the Apache Training podling has just passed a vote to turn on the commit bit 
for it’s code repos to allow all Apache Committers to commit.
We hope this will revive the podling as we see potential for great benefit for 
all Apache projects.

Filing an Infra-Issue for actually flicking the switch right now …

Chris

[RESULT] [VOTE] Apache Training (Incubating) Tools 1.0.0 RC2

[Christofer Dutz]

Hi all,

the vote passes with 

5 binding +1 votes 
2 non-binding +1 votes

No other votes.

Thanks for taking the time to review.

Chris



Am 16.09.20, 22:25 schrieb "Kevin Ratnasekera" :

+1 ( binding )

On Thu, Sep 17, 2020 at 1:50 AM Furkan KAMACI 
wrote:

> Hi,
>
> +1!
>
> Kind Regards,
> Furkan KAMACI
>
> On Wed, Sep 16, 2020 at 7:49 PM Brahma Reddy Battula 
> wrote:
>
> > My late +1 (non-binding)
    > >
    > > On Mon, Sep 14, 2020 at 8:01 PM Christofer Dutz <
> christofer.d...@c-ware.de
> > >
> > wrote:
> >
> > > Hi,
> > >
> > > The vote to release Apache Training (incubating) Tools 1.0.0 has 
passed
> > > with 3 +1 (all from mentors) and one non-binding +1 vote.
> > >
> > > Binding votes (all were IPMC members):
> > > - Christofer Dutz (
> > >
> >
> 
https://lists.apache.org/thread.html/rd2cbadaf3b8c050e927f7ec5078d9b783eeaa234026542131e01477e%40%3Cdev.training.apache.org%3E
> > > )
> > > - Justin McLean (
> > >
> >
> 
https://lists.apache.org/thread.html/r34fe140758417103ba6a53e5d3a15dba7ca9924368f52bdf8bceb67e%40%3Cdev.training.apache.org%3E
> > > )
> > > - Lars Francke (
> > >
> >
> 
https://lists.apache.org/thread.html/r857decb97e97b2d3a86fbf05a919e7990be79f57a61d8c861e6dfa60%40%3Cdev.training.apache.org%3E
> > > )
> > >
> > > Non-Binding vote:
> > > - Gautam Gupta
> > >
> > > The vote thread for some reason was fragmented, so I added links to 
the
> > > vote emails to each person voting.
> > >
> > >
> > > Chris
> > >
> >
> >
> > --
> >
> >
> >
> > --Brahma Reddy Battula
> >
>


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

[VOTE] Apache Training (Incubating) Tools 1.0.0 RC2

[Christofer Dutz]

Hi,

The vote to release Apache Training (incubating) Tools 1.0.0 has passed with 3 
+1 (all from mentors) and one non-binding +1 vote.

Binding votes (all were IPMC members):
- Christofer Dutz 
(https://lists.apache.org/thread.html/rd2cbadaf3b8c050e927f7ec5078d9b783eeaa234026542131e01477e%40%3Cdev.training.apache.org%3E)
- Justin McLean 
(https://lists.apache.org/thread.html/r34fe140758417103ba6a53e5d3a15dba7ca9924368f52bdf8bceb67e%40%3Cdev.training.apache.org%3E)
- Lars Francke 
(https://lists.apache.org/thread.html/r857decb97e97b2d3a86fbf05a919e7990be79f57a61d8c861e6dfa60%40%3Cdev.training.apache.org%3E)

Non-Binding vote:
- Gautam Gupta

The vote thread for some reason was fragmented, so I added links to the vote 
emails to each person voting.


Chris

[jira] [Closed] (INCUBATOR-254) Permissions to edit subscriptions

[Christofer Dutz (Jira)]

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

Christofer Dutz closed INCUBATOR-254.
-
Resolution: Fixed

Wrong project to report this for ... opened a new INFRA ticket

> Permissions to edit subscriptions
> -
>
> Key: INCUBATOR-254
> URL: https://issues.apache.org/jira/browse/INCUBATOR-254
> Project: Incubator
>  Issue Type: Task
>    Reporter: Christofer Dutz
>Priority: Major
>
> Hi,
> I would like to be able to edit the subscriptions sent to the Apache Training 
> (Incubating) mailing-list. The "patches available" and the "triage needed" 
> subscriptions need some fine-tuning.
> Thanks,
>      Chris



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Re: [VOTE] Graduate Apache IoTDB as TLP

[Christofer Dutz]

+1 (binding)

Chris

Am 10.09.20, 10:35 schrieb "atoi...@163.com im Auftrag von Dawei Liu" 
:

+1 (non-binding)



Best,
Dawei Liu
On 09/10/2020 16:02，Dominik Riemer wrote：
+1 (non-binding)

Great project!

Dominik

-Original Message-
From: Xiangdong Huang 
Sent: Thursday, September 10, 2020 9:42 AM
To: general@incubator.apache.org
Subject: [VOTE] Graduate Apache IoTDB as TLP

Dear all IPMCs:

Following discussions with great support from our mentors, committers and 
community members.
I would like to call for a formal VOTE for graduating Apache IoTDB 
(Incubating), as a Top Level Project.

This is a formal voting thread about Apache IoTDB's graduation, please Vote:
[ ] +1 - Recommend graduation of Apache IoTDB as a TLP [ ]  0 [ ] -1 - Do 
not recommend the graduation of Apache IoTDB because...

The VOTE will open for at least 72 hours.

Apache IoTDB (Incubating) entered the incubator in Nov 2018, the community 
has grown vibrantly since, with all the design, development happening on the 
Apache infrastructure, the "Apache Way".

To list a few of the community's achievements,

- Apache IoTDB name search has been approved
- Accepted > 1300 PRs from 75 contributors
- Migrated developer conversations to the list at d...@iotdb.apache.org
(more than 3000 mails, without JIRA notifications, and gitbox, are sent by 
more than 160 persons)
- There are 9 versions (3 major versions) released successfully conformant 
to Apache release policy by 5 release managers;
- Invited 12 new committers (all of them accepted)
- invited 4 of those new committers to join the PMC (all of them accepted)
- Our proposed PMC is diverse and consists of members from more than 10 
organizations

Preparations and discussions history about the graduation:

- The maturity assessment is done [2],
- The community agreed on starting the graduation process in a formal vote 
[3] (result see [4]).
And, I'd like to note that all our mentors also participated in the vote 
with a positive vote!
- The community also decided about a suggestion for the initial VP, a 
charter [5, 6] and the initial PMC list [7].
- We also received positive feedback from the incubator general mailing 
list [8].


The draft of the resolution:

Establish the Apache IoTDB 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 an IoT native database with high performance
for data management and analysis, on the edge and the cloud.

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

RESOLVED, that the Apache IoTDB Project be and hereby is
responsible for the creation and maintenance of software
related to an IoT native database with high performance
for data management and analysis, on the edge and the cloud.
and be it further

RESOLVED, that the office of "Vice President, Apache IoTDB 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 IoTDB Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache IoTDB 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 IoTDB Project:

    * Chen Wang  
* Christofer Dutz 
* Dawei Liu 
* Gaofei Cao 
* Haonan Hou 
* Jialin Qiao 
* Jianmin Wang 
* Jincheng Sun 
* Jinrui Zhang 
* Julian Feinauer 
* Jun Yuan 
* Justin Mclean 
* Kevin A. McGrail 
* Kun Liu 
* Lei Rui 
* Rong Kang 
* Rui Liu 
* Shuo Zhang 
* Stefanie Zhao 
* Tian Jiang 
* Tianan Li 
* Willem Ning Jiang 
* Xiangdong Huang 

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Xiangdong Huang
be appointed to the office of Vice President, Apache IoTDB, 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 IoTDB 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 IoTDB Project; and be it further

RESOLVED, that the Apache IoT

[jira] [Created] (INCUBATOR-254) Permissions to edit subscriptions

[Christofer Dutz (Jira)]

Christofer Dutz created INCUBATOR-254:
-

 Summary: Permissions to edit subscriptions
 Key: INCUBATOR-254
 URL: https://issues.apache.org/jira/browse/INCUBATOR-254
 Project: Incubator
  Issue Type: Task
Reporter: Christofer Dutz


Hi,

I would like to be able to edit the subscriptions sent to the Apache Training 
(Incubating) mailing-list. The "patches available" and the "triage needed" 
subscriptions need some fine-tuning.

Thanks,

     Chris



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[DISCUSS] [VOTE] Release Apache IoTDB 0.10.1

[Christofer Dutz]

I wouldn't say they have to be there ... 

but I personally do like projects that have them there: A README as well as a 
RELEASE_NOTES.

Chris



Am 19.08.20, 16:17 schrieb "Xiangdong Huang" :

Hi,

> I just have a quick question about the README files. Why do we put them
into the release directory?

Thanks, Willem. Yes, you are right, we do not need to put the README files
to the SVN
(But they still need to be included in our source-release files)...

We will fix our release process to remove the README files out of the SVN.

Now we get two votes from IPMCs. Look forward to at least one more votes
from IPMCs for this release. :D

Best,
---
Xiangdong Huang
School of Software, Tsinghua University

 黄向东
清华大学 软件学院


Willem Jiang  于2020年8月19日周三 上午7:56写道：

> +1 （binding）
>
> I just have a quick question about the README files. Why do we put
> them into the release directory?
>
> I checked：
> Verified the signed the key and hash code.
>  Incubating in the release kit name.
> License and Notice files  are good to me.
> The maven staging repo looks good.
> Git repo release tag.
> There is no binary in the source kit.
> I can build the kit from source.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Aug 14, 2020 at 9:59 AM Xiangdong Huang 
> wrote:
> >
> > Hello all,
> >
> > This is a call for vote to release Apache IoTDB (Incubating) version
> > 0.10.1, which is a bug-fix version of 0.10.0.
> >
> > The Apache IoTDB community has voted on and approved a proposal to
> > release Apache
> > IoTDB (Incubating) version 0.10.1 (with 12 +1 votes).
> >
> > We now kindly request the Incubator PMC members review and vote on
> > this incubator
> > release.
> >
> > Apache IoTDB (incubating) (Database for Internet of Things) is an
> > integrated data management engine designed for timeseries data.
> >
> > IoTDB community vote and result thread:
> >
> > Result:
> >
> >
> 
https://lists.apache.org/thread.html/r3d2081bac4aed5217820a4587383150dc7b6471828675d9b6eeacf5e%40%3Cdev.iotdb.apache.org%3E
> >
> >
> > Vote:
> >
> >
> 
https://lists.apache.org/thread.html/r94e5dcac19d5f2ba9990a95cc1fb5232074702de9f1c326d27eebfe3%40%3Cdev.iotdb.apache.org%3E
> >
> >
> > The release candidates (RC3):
> > https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.10.1/rc3/
> >
> > Git tag for the release (RC3):
> > https://github.com/apache/incubator-iotdb/releases/tag/release%2F0.10.1
> >
> > Hash for the release tag:
> > 023fb84e0b76c0ac64b7a9ac098c640f26795a25
> >
> >
> > Release Notes:
> >
> 
https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.10.1/rc3/RELEASE_NOTES.md
> >
> >
> > The artifacts have been signed with Key: 2206EF8F64C35889, which can be
> found
> > in the keys file:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/iotdb/KEYS
> >
> > Look at here for how to verify this release candidate:
> >
> 
https://cwiki.apache.org/confluence/display/IOTDB/Validating+a+staged+Release
> >
> > The vote will be open for at least 72 hours.
> >
> >
> > The vote will be passed if there are at least 3 IPMC +1 votes and there
> is
> > no -1 vote.
> >
> > Please vote accordingly:
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > Xiangdong Huang
> > Apache IoTDB (incubating)
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


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

Re: [VOTE] Release Apache IoTDB 0.10.1

[Christofer Dutz]

Hi all,

TL/DR:
+1 binding

Longer version:
I started evaluating. As usual the IoTDB release candidate is in very good 
shape. 

Here some super minor things I noticed:

- It seems the ".plan" templates in 
server/src/assembly/resources/tools/logVisualize/plans support comments, then 
they should contain the Apache headers.
- The karaf feature is referencing a SNAPSHOT version and not even the version 
in this release 0.10.0.SNAPSHOT
- The Dockerfile is also referencing an older SNAPSHOT version 0.10.0-SNAPSHOT
- The mvnw.sh file doesn't seem to be executable
- In the README perhaps point out that you can a) download the source bundle 
from one of the mirrors or you can clone from gitbox or github ... what you're 
describing in the README is actually not downloading, but cloning the repo. I 
would probably base the documentation on downloading a release archive and put 
the cloning in the developer part of the documentation. Reason is: Only for the 
source-bundles can we really ensure this is what was voted on ... tags in 
Github can be changed.

[OK] Download all staged artifacts under the url specified in the release vote 
email into a directory we’ll now call download-dir. 
[OK] Verify the signature is correct: Additional Apache tutorial on how to 
verify downloads can be found here. 
[OK] Check if the signature references an Apache email address.
[OK] Verify the SHA512 hashes:
[OK] Unzip the archive:
[OK] Verify the existence of DISCLAIMER, LICENSE, NOTICE, README, RELEASE_NOTES 
files in the extracted source bundle.
[OK] Verify the content of LICENSE, NOTICE, README, RELEASE_NOTES files in the 
extracted source bundle.
[OK] Verify the staged source README, RELEASE_NOTE files correspond to those in 
the extracted source bundle.
[MINOR] Run RAT externally to ensure there are no surprises.
[MINOR] Search for SNAPSHOT references:
[OK] Search for Copyright references, and if they are in headers, make sure 
these files containing them are mentioned in the LICENSE file.
[MINOR] Build the project according to the information in the README.md file.

Great job folks,

Chris



Am 18.08.20, 05:42 schrieb "Xiangdong Huang" :

Hi IPMCs,

We are still looking forward to getting votes from you...

Many thanks!

Best,
---
Xiangdong Huang
School of Software, Tsinghua University

 黄向东
清华大学 软件学院


Xiangdong Huang  于2020年8月14日周五 上午9:59写道：

> Hello all,
>
> This is a call for vote to release Apache IoTDB (Incubating) version
> 0.10.1, which is a bug-fix version of 0.10.0.
>
> The Apache IoTDB community has voted on and approved a proposal to 
release Apache
> IoTDB (Incubating) version 0.10.1 (with 12 +1 votes).
>
> We now kindly request the Incubator PMC members review and vote on this 
incubator
> release.
>
> Apache IoTDB (incubating) (Database for Internet of Things) is an
> integrated data management engine designed for timeseries data.
>
> IoTDB community vote and result thread:
>
> Result:
>
>
> 
https://lists.apache.org/thread.html/r3d2081bac4aed5217820a4587383150dc7b6471828675d9b6eeacf5e%40%3Cdev.iotdb.apache.org%3E
>
>
> Vote:
>
>
> 
https://lists.apache.org/thread.html/r94e5dcac19d5f2ba9990a95cc1fb5232074702de9f1c326d27eebfe3%40%3Cdev.iotdb.apache.org%3E
>
>
> The release candidates (RC3):
> https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.10.1/rc3/
>
> Git tag for the release (RC3):
> https://github.com/apache/incubator-iotdb/releases/tag/release%2F0.10.1
>
> Hash for the release tag:
> 023fb84e0b76c0ac64b7a9ac098c640f26795a25
>
>
> Release Notes:
>
> 
https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.10.1/rc3/RELEASE_NOTES.md
>
>
> The artifacts have been signed with Key: 2206EF8F64C35889, which can be 
found
> in the keys file:
>
> https://dist.apache.org/repos/dist/dev/incubator/iotdb/KEYS
>
> Look at here for how to verify this release candidate:
>
> 
https://cwiki.apache.org/confluence/display/IOTDB/Validating+a+staged+Release
>
> The vote will be open for at least 72 hours.
>
>
> The vote will be passed if there are at least 3 IPMC +1 votes and there is
> no -1 vote.
>
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> Xiangdong Huang
> Apache IoTDB (incubating)
>
>
>


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

Re: [RELEASENOTES?] Re: [VOTE] Release Apache Daffodil (incubating) 2.7.0-rc2

[Christofer Dutz]

Hi Dave, 

they are not a requirement ... it's just that every project I'm on sort of has 
them and I think it's a good thing to have them.
I didn't vote -1 or so ... I just added a comment as a minor issue (in my 
opinion)

Chris


Am 13.07.20, 16:53 schrieb "Dave Fisher" :



> On Jul 10, 2020, at 12:43 AM, Christofer Dutz  
wrote:
> 
> +1 (binding)
> 
> I did find some minor issues though, please see below.
> I would really suggest to start maintaining a RELEASE_NOTES file. I 
usually have a look at this in order to see what to expect of the new release.
> 
> Chris
> 
> 
> [OK] Download all staged artifacts under the url specified in the release 
vote email into a directory we’ll now call download-dir.
> [MINOR] Verify the signature is correct: Additional Apache tutorial on 
how to verify downloads can be found here.
>   - No trusted Key-chain (might think about going to a key-signing party) 
> [OK] Check if the signature references an Apache email address.
> [OK] Verify the SHA512 hashes:
> [OK] Unzip the archive:
> [MINOR] Verify the existence of DISCLAIMER, LICENSE, NOTICE, README, 
RELEASE_NOTES files in the extracted source bundle.
>   - No RELEASE_NOTES

When and where did Release Notes become a requirement?

They may be a good idea, but I want a reference to where this requirement 
came about and who made that change.

Regards,
Dave


> [OK] Verify the content of LICENSE, NOTICE, README, RELEASE_NOTES files 
in the extracted source bundle.
> [OK] Run RAT externally (without any exclusions) to ensure there are no 
surprises.
> [OK] Search for SNAPSHOT references:
> [MINOR] Search for Copyright references, and if they are in headers, make 
sure these files containing them are mentioned in the LICENSE file.
>   - Some files listed in LICENSE moved from 
daffodil-test/src/test/resources/org/apache/daffodil/ibm-tests/ to 
daffodil-test-ibm1/src/test/resources/test-suite/ibm-contributed/ without being 
updated in the LICENSE file
>   - dpaspc7131.dfdl.xsd
>   - dpaspc7132.dfdl.xsd
>   - dpaspc7132_2.dfdl.xsd
> [OK] Build the project according to the information in the README.md file.
> 
> 
> 
> 
> Am 10.07.20, 03:38 schrieb "Beckerle, Mike" :
> 
> 
>Hoping to get some attention to this.
> 
>We have a user community that requested that we do this point-release 
with a specific fix.
>This is gating their release of a system that uses Daffodil.
> 
>Please review this latest incubator release of Daffodil.
> 
>Thank you
> 
>
>From: Mike Beckerle 
>Sent: Monday, July 6, 2020 11:45 AM
>To: general@incubator.apache.org 
>Subject: [VOTE] Release Apache Daffodil (incubating) 2.7.0-rc2
> 
>The Apache Daffodil community has voted and approved the proposed
>release of Apache Daffodil (incubating) 2.7.0-rc2.
> 
>We now kindly request the Incubator PMC members review and vote on this
>incubator release.
> 
>Daffodil is an open source implementation of the DFDL specification 
that
>uses DFDL schemas to parse fixed format data into an infoset, which is 
most
>commonly represented as either XML or JSON. This allows the use of
>well-established XML or JSON technologies and libraries to consume,
>inspect, and manipulate fixed format data in existing solutions. 
Daffodil
>is also capable of the reverse by serializing or "unparsing" an XML or 
JSON
>infoset back to the original data format.
> 
>Vote thread:
> 
>
https://mail-archives.apache.org/mod_mbox/daffodil-dev/202007.mbox/%3CEEA6E9860DFB8449AA9F0E561E1B75AAA9709778%40ALPMBAPA07.e2k.ad.ge.com%3E
> 
>Result thread:
> 
>
https://mail-archives.apache.org/mod_mbox/daffodil-dev/202007.mbox/%3CCAM5OWnjr88hP-DVqFh2hKFBMMXepKu39YEt-_E-8Agx2%3DHBOcA%40mail.gmail.com%3E
> 
>All distribution packages, including signatures, digests, etc. can be
>found at:
> 
>https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.7.0-rc2/
> 
>Staging artifacts can be found at:
> 
>
https://repository.apache.org/content/repositories/orgapachedaffodil-1018/
> 
>This release has been signed with PGP key 13A680AF, corresponding
>to mbecke...@apache.org, which is included in the KEYS file here:
> 
>https://downloads.apache.org/incubator/daffodil/KEYS
> 
>The re

Re: [VOTE] Release Apache Daffodil (incubating) 2.7.0-rc2

[Christofer Dutz]

+1 (binding)

I did find some minor issues though, please see below.
I would really suggest to start maintaining a RELEASE_NOTES file. I usually 
have a look at this in order to see what to expect of the new release.

Chris


[OK] Download all staged artifacts under the url specified in the release vote 
email into a directory we’ll now call download-dir.
[MINOR] Verify the signature is correct: Additional Apache tutorial on how to 
verify downloads can be found here.
- No trusted Key-chain (might think about going to a key-signing party) 
[OK] Check if the signature references an Apache email address.
[OK] Verify the SHA512 hashes:
[OK] Unzip the archive:
[MINOR] Verify the existence of DISCLAIMER, LICENSE, NOTICE, README, 
RELEASE_NOTES files in the extracted source bundle.
- No RELEASE_NOTES
[OK] Verify the content of LICENSE, NOTICE, README, RELEASE_NOTES files in the 
extracted source bundle.
[OK] Run RAT externally (without any exclusions) to ensure there are no 
surprises.
[OK] Search for SNAPSHOT references:
[MINOR] Search for Copyright references, and if they are in headers, make sure 
these files containing them are mentioned in the LICENSE file.
- Some files listed in LICENSE moved from 
daffodil-test/src/test/resources/org/apache/daffodil/ibm-tests/ to 
daffodil-test-ibm1/src/test/resources/test-suite/ibm-contributed/ without being 
updated in the LICENSE file
- dpaspc7131.dfdl.xsd
- dpaspc7132.dfdl.xsd
- dpaspc7132_2.dfdl.xsd
[OK] Build the project according to the information in the README.md file.




Am 10.07.20, 03:38 schrieb "Beckerle, Mike" :


Hoping to get some attention to this.

We have a user community that requested that we do this point-release with 
a specific fix.
This is gating their release of a system that uses Daffodil.

Please review this latest incubator release of Daffodil.

Thank you


From: Mike Beckerle 
Sent: Monday, July 6, 2020 11:45 AM
To: general@incubator.apache.org 
Subject: [VOTE] Release Apache Daffodil (incubating) 2.7.0-rc2

The Apache Daffodil community has voted and approved the proposed
release of Apache Daffodil (incubating) 2.7.0-rc2.

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

Daffodil is an open source implementation of the DFDL specification that
uses DFDL schemas to parse fixed format data into an infoset, which is most
commonly represented as either XML or JSON. This allows the use of
well-established XML or JSON technologies and libraries to consume,
inspect, and manipulate fixed format data in existing solutions. Daffodil
is also capable of the reverse by serializing or "unparsing" an XML or JSON
infoset back to the original data format.

Vote thread:


https://mail-archives.apache.org/mod_mbox/daffodil-dev/202007.mbox/%3CEEA6E9860DFB8449AA9F0E561E1B75AAA9709778%40ALPMBAPA07.e2k.ad.ge.com%3E

Result thread:


https://mail-archives.apache.org/mod_mbox/daffodil-dev/202007.mbox/%3CCAM5OWnjr88hP-DVqFh2hKFBMMXepKu39YEt-_E-8Agx2%3DHBOcA%40mail.gmail.com%3E

All distribution packages, including signatures, digests, etc. can be
found at:

https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.7.0-rc2/

Staging artifacts can be found at:

https://repository.apache.org/content/repositories/orgapachedaffodil-1018/

This release has been signed with PGP key 13A680AF, corresponding
to mbecke...@apache.org, which is included in the KEYS file here:

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

The release candidate has been tagged in git with v2.7.0-rc2.

For reference, here is a list of all closed JIRAs tagged with 2.7.0:

https://s.apache.org/daffodil-issues-2.7.0

For a summary of the changes in this release, see:

https://daffodil.apache.org/releases/2.7.0/

Please review and vote. The vote will be open for at least 72 hours
(ends on Thursday July 9 at 12 noon US.EDT = UTC-4)

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Re: [VOTE] Release Apache Daffodil (incubating) 2.6.0-rc2

[Christofer Dutz]

+1 (binding)

Chris

Source Bundle:
[OK] Signatures match
[OK] Signatures by apache email address
[OK] Hashes match
[OK] Source bundle unpacks correctly
[OK] Unpacked sources contain NOTICE, LICENSE, README.md and DISCLAIMER
[OK] Year on NOTICE file correct, LICENSE file correctly lists up the included 
passera and UniquenessCache.scala code
[OK] Rat doesn't report any surprizes
[OK] Running the build and the tests according to documentation in the README 
(No test failures this time)

Also the DISCLAIMERS are now in place in the jars

Great job :-)


Am 22.04.20, 19:32 schrieb "Christofer Dutz" :

Sorry for not being that responsive,

I'm currently trying to finish something that's consuming a lot of time for 
me ... hopefully I'll be finished soon and can do the review.

Chris

Am 22.04.20, 15:59 schrieb "Olabusayo Kilo" :

Thank you to the IPMC members who voted, we're still in need of 1 more 
vote to pass and would appreciate if someone could review this when 
they 
get a chance.

On 4/20/20 8:31 AM, Furkan KAMACI wrote:
> Hi,
> 
> +1 (binding).
> 
> I checked:
> 
> - Incubating in name
> - DISCLAIMER exists
> - LICENSE and NOTICE are fine
> - No unexpected binary files
> - Checked PGP signatures
> - Checked Checksums
> - Code compiles and tests successfully run
> 
> Kind Regards,
> Furkan KAMACI
> 
> On Mon, Apr 20, 2020 at 3:17 PM Steve Lawrence  
wrote:
> 
>> Thanks for the vote! One mentor voted a +0 for rc1. We chose to fix
>> those issues which led to the rc2 vote. Neither mentor has voted for 
the
>> rc2 release yet.
>>
>> - Steve
>>
>> On 4/17/20 8:12 PM, Justin Mclean wrote:
>>> Hi,
>>>
>>> +1 (binding)
>>>
>>> Did any of your mentor votes on this release?
>>>
>>> I checked:
>>> - incubating in name
>>> - signatures and hashes are fine
>>> - DISCLAIMER exists
>>> - LICENSE and NOTICE are good
>>> - No unexpected binary files
>>> - All ASF files have ASF headers
>>> - Can compile from source
>>>
>>> Thanks,
>>> Justin
>>>
>>> 
-
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 

-- 
Best Regards
Lola K.

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

Re: [VOTE] Release Apache Daffodil (incubating) 2.6.0-rc2

[Christofer Dutz]

Sorry for not being that responsive,

I'm currently trying to finish something that's consuming a lot of time for me 
... hopefully I'll be finished soon and can do the review.

Chris

Am 22.04.20, 15:59 schrieb "Olabusayo Kilo" :

Thank you to the IPMC members who voted, we're still in need of 1 more 
vote to pass and would appreciate if someone could review this when they 
get a chance.

On 4/20/20 8:31 AM, Furkan KAMACI wrote:
> Hi,
> 
> +1 (binding).
> 
> I checked:
> 
> - Incubating in name
> - DISCLAIMER exists
> - LICENSE and NOTICE are fine
> - No unexpected binary files
> - Checked PGP signatures
> - Checked Checksums
> - Code compiles and tests successfully run
> 
> Kind Regards,
> Furkan KAMACI
> 
> On Mon, Apr 20, 2020 at 3:17 PM Steve Lawrence  
wrote:
> 
>> Thanks for the vote! One mentor voted a +0 for rc1. We chose to fix
>> those issues which led to the rc2 vote. Neither mentor has voted for the
>> rc2 release yet.
>>
>> - Steve
>>
>> On 4/17/20 8:12 PM, Justin Mclean wrote:
>>> Hi,
>>>
>>> +1 (binding)
>>>
>>> Did any of your mentor votes on this release?
>>>
>>> I checked:
>>> - incubating in name
>>> - signatures and hashes are fine
>>> - DISCLAIMER exists
>>> - LICENSE and NOTICE are good
>>> - No unexpected binary files
>>> - All ASF files have ASF headers
>>> - Can compile from source
>>>
>>> Thanks,
>>> Justin
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 

-- 
Best Regards
Lola K.

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

Re: Do Pooling jars have to contain the DISCLAIMER too?

[Christofer Dutz]

They are not debating,

They canceled the vote and fixed the problem. But I couldn't send a link to the 
rules to confirm my reclamation. That's why I'm asking.

Chris

Von: Dave Fisher 
Gesendet: Donnerstag, 9. April 2020 20:28
An: general 
Betreff: Re: Do Pooling jars have to contain the DISCLAIMER too?



> On Apr 9, 2020, at 11:25 AM, Christofer Dutz  
> wrote:
>
> Yhhh ... buuut.
>
> We're talking about convenience binaries here ... as we keep on insisting 
> that only source bundles are releases.
> So technically they are doing it correctly, as the source distribution, we 
> are doing the voting on actually does have the DISCLAIMER in it.
>
> Perhaps we should update that document to also mention releases AND any form 
> of convenience binaries.

Sure - please do make a change.

If they are debating this about conveniences are these binaries going through 
proper VOTE procedures?

Regards,
Dave

>
> Chris
>
>
>
> Am 09.04.20, 20:12 schrieb "Dave Fisher" :
>
>The DISCLAIMER is an Incubator requirement.
>
>https://incubator.apache.org/policy/incubation.html#disclaimers
>
>Regards,
>Dave
>
>> On Apr 9, 2020, at 11:07 AM, Christofer Dutz  
>> wrote:
>>
>> Hi Dave,
>>
>> unfortunately I can't see the requirement to have a DISCLAIMER in there ... 
>> nor could I find it ... I totally agree with you, that it should be that 
>> way, but I couldn't find a written baking of that position so I could vote 
>> -1 and send a pointer to some documentation.
>>
>> Chris
>>
>>
>> Am 09.04.20, 20:01 schrieb "Dave Fisher" :
>>
>>   Hi Chris,
>>
>>   There should not be a question. If these are official Apache packages from 
>> the project published on Maven Central with org.apache co-ordinates then 
>> they must meet all of release policy and include NOTICE, LICENSE, and, if 
>> incubating, DISCLAIMER. They must also be released on the official dist 
>> server and available at downloads.apache.org even if no one would normally 
>> get packages that way. The same should go for NPM and other distribution 
>> channels.
>>
>>   https://infra.apache.org/release-distribution.html
>>
>>   Clear?
>>
>>   Regards,
>>   Dave
>>
>>> On Apr 8, 2020, at 6:05 AM, Christofer Dutz  
>>> wrote:
>>>
>>> Hi Justin,
>>>
>>> I agree that they should ... especially if you don't build from source or 
>>> use the pre-compiled binaries you otherwise wouldn't have any reference to 
>>> the software undergoing incubation at the ASF.
>>>
>>> Was sort of just asking if it's a "should" (still a +1 with a notice to fix 
>>> for next time), a "must" (-1) or a "I don’t care" (+1 and not even a notice)
>>>
>>> I would clearly like to argue for a "must".
>>>
>>> Chris
>>>
>>>
>>>
>>> Am 08.04.20, 14:58 schrieb "Justin Mclean" :
>>>
>>>  Hi,
>>>
>>>> currently validating a podlings release and I stumbled over the following 
>>>> fact:
>>>>
>>>> *   The src and bin bundles contain a DISCLAIMER
>>>> *   All of their project-jars in any of the bin bundles and the jars in 
>>>> Apache’s Nexus don’t have one
>>>>
>>>> Is this considered OK or should they all have a DISCLAIMER?
>>>
>>>  IMO The jars should contain LICENSE, NOTICE and DISCLAIMER.
>>>
>>>  Thanks,
>>>  Justin
>>>
>>>
>>>  -
>>>  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>>  For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>>   -
>>   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>   For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org


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

Re: Do Pooling jars have to contain the DISCLAIMER too?

[Christofer Dutz]

Yhhh ... buuut.

We're talking about convenience binaries here ... as we keep on insisting that 
only source bundles are releases. 
So technically they are doing it correctly, as the source distribution, we are 
doing the voting on actually does have the DISCLAIMER in it.

Perhaps we should update that document to also mention releases AND any form of 
convenience binaries.

Chris



Am 09.04.20, 20:12 schrieb "Dave Fisher" :

The DISCLAIMER is an Incubator requirement.

https://incubator.apache.org/policy/incubation.html#disclaimers

Regards,
Dave

> On Apr 9, 2020, at 11:07 AM, Christofer Dutz  
wrote:
> 
> Hi Dave,
> 
> unfortunately I can't see the requirement to have a DISCLAIMER in there 
... nor could I find it ... I totally agree with you, that it should be that 
way, but I couldn't find a written baking of that position so I could vote -1 
and send a pointer to some documentation.
> 
> Chris
> 
> 
> Am 09.04.20, 20:01 schrieb "Dave Fisher" :
> 
>Hi Chris,
> 
>There should not be a question. If these are official Apache packages 
from the project published on Maven Central with org.apache co-ordinates then 
they must meet all of release policy and include NOTICE, LICENSE, and, if 
incubating, DISCLAIMER. They must also be released on the official dist server 
and available at downloads.apache.org even if no one would normally get 
packages that way. The same should go for NPM and other distribution channels.
> 
>https://infra.apache.org/release-distribution.html
> 
>Clear?
> 
>Regards,
>Dave
> 
>> On Apr 8, 2020, at 6:05 AM, Christofer Dutz  
wrote:
>> 
>> Hi Justin,
>> 
>> I agree that they should ... especially if you don't build from source 
or use the pre-compiled binaries you otherwise wouldn't have any reference to 
the software undergoing incubation at the ASF.
>> 
>> Was sort of just asking if it's a "should" (still a +1 with a notice to 
fix for next time), a "must" (-1) or a "I don’t care" (+1 and not even a notice)
>> 
>> I would clearly like to argue for a "must".
>> 
>> Chris
>> 
>> 
>> 
>> Am 08.04.20, 14:58 schrieb "Justin Mclean" :
>> 
>>   Hi,
>> 
>>> currently validating a podlings release and I stumbled over the 
following fact:
>>> 
>>> *   The src and bin bundles contain a DISCLAIMER
>>> *   All of their project-jars in any of the bin bundles and the jars in 
Apache’s Nexus don’t have one
>>> 
>>> Is this considered OK or should they all have a DISCLAIMER?
>> 
>>   IMO The jars should contain LICENSE, NOTICE and DISCLAIMER.
>> 
>>   Thanks,
>>   Justin
>> 
>> 
>>   -
>>   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>   For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 
> 
> 
> -
> 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: Do Pooling jars have to contain the DISCLAIMER too?

[Christofer Dutz]

Hi Dave,

unfortunately I can't see the requirement to have a DISCLAIMER in there ... nor 
could I find it ... I totally agree with you, that it should be that way, but I 
couldn't find a written baking of that position so I could vote -1 and send a 
pointer to some documentation.

Chris


Am 09.04.20, 20:01 schrieb "Dave Fisher" :

Hi Chris,

There should not be a question. If these are official Apache packages from 
the project published on Maven Central with org.apache co-ordinates then they 
must meet all of release policy and include NOTICE, LICENSE, and, if 
incubating, DISCLAIMER. They must also be released on the official dist server 
and available at downloads.apache.org even if no one would normally get 
packages that way. The same should go for NPM and other distribution channels.

https://infra.apache.org/release-distribution.html

Clear?

Regards,
Dave

> On Apr 8, 2020, at 6:05 AM, Christofer Dutz  
wrote:
> 
> Hi Justin,
> 
> I agree that they should ... especially if you don't build from source or 
use the pre-compiled binaries you otherwise wouldn't have any reference to the 
software undergoing incubation at the ASF.
> 
> Was sort of just asking if it's a "should" (still a +1 with a notice to 
fix for next time), a "must" (-1) or a "I don’t care" (+1 and not even a notice)
> 
> I would clearly like to argue for a "must".
> 
> Chris
> 
> 
> 
> Am 08.04.20, 14:58 schrieb "Justin Mclean" :
> 
>Hi,
> 
>> currently validating a podlings release and I stumbled over the 
following fact:
>> 
>> *   The src and bin bundles contain a DISCLAIMER
>> *   All of their project-jars in any of the bin bundles and the jars in 
Apache’s Nexus don’t have one
>> 
>> Is this considered OK or should they all have a DISCLAIMER?
> 
>IMO The jars should contain LICENSE, NOTICE and DISCLAIMER.
> 
>Thanks,
>Justin
> 
> 
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org


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

Re: Do Pooling jars have to contain the DISCLAIMER too?

[Christofer Dutz]

Hi Justin,

I agree that they should ... especially if you don't build from source or use 
the pre-compiled binaries you otherwise wouldn't have any reference to the 
software undergoing incubation at the ASF.

Was sort of just asking if it's a "should" (still a +1 with a notice to fix for 
next time), a "must" (-1) or a "I don’t care" (+1 and not even a notice)

I would clearly like to argue for a "must".

Chris



Am 08.04.20, 14:58 schrieb "Justin Mclean" :

Hi,

> currently validating a podlings release and I stumbled over the following 
fact:
> 
>  *   The src and bin bundles contain a DISCLAIMER
>  *   All of their project-jars in any of the bin bundles and the jars in 
Apache’s Nexus don’t have one
> 
> Is this considered OK or should they all have a DISCLAIMER?

IMO The jars should contain LICENSE, NOTICE and DISCLAIMER.

Thanks,
Justin


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




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

Do Pooling jars have to contain the DISCLAIMER too?

[Christofer Dutz]

Hi all,

currently validating a podlings release and I stumbled over the following fact:

  *   The src and bin bundles contain a DISCLAIMER
  *   All of their project-jars in any of the bin bundles and the jars in 
Apache’s Nexus don’t have one

Is this considered OK or should they all have a DISCLAIMER?

I would opt for all artifacts should have one as if you’re using maven you will 
probably otherwise not notice having jars from incubating projects in your 
build.

What do you others think?

Chris

Re: [RESULT] [IP CLEARANCE] Maven Wrapper

[Christofer Dutz]

Great ... :-)

really looking forward to finally having this resolved AND the maven-wrapper 
itself as part of the Maven project.
Guess after releasing that as apache once and updating the maven-wrapper 
scripts accordingly we can finally get rid of some of the controversial bits in 
our releases.

Chris

Am 09.02.20, 13:12 schrieb "Robert Scholte" :

I've updated incubator page[1].

Do we still need a vote to complete the process? 

There was already an agreement on maven-wrapper, there was only discussion 
about the maven-wrapper-plugin, which has been removed from the page.

thanks,
Robert

[1] http://incubator.apache.org/ip-clearance/maven-wrapper.html

On 7-2-2020 20:06:19, Robert Scholte  wrote:
After sharing the information with the Maven PMC, we want to do the 
following:

- accept Maven wrapper. 
- don't wait for Walmart to hand over a SGA for the wrapper-plugin. Instead 
we will start to write our own maven-wrapper-plugin. This is actually a very 
small plugin, won't require a lot of effort to get it running.

thanks,
Robert
On 4-2-2020 19:28:03, Robert Scholte  wrote:
Thanks John, I'll share this with the PMC and we'll let you now what we'll 
decide.

Robert
On 4-2-2020 17:07:31, John D. Ament  wrote:
To be very explicit here:

- The code for the maven wrapper is fine, it's already apache licensed and
has no NOTICE file declared with it, so would be perfectly fine to import.
ICLA's would be nice, but not required, and adding a NOTICE indicating the
origination of parts of it would also be nice but not required.
- The code for the Takari Maven Plugin is EPLv1 and requires an SGA to
change the license to apache license.

I'd recommend the Maven PMC take this back and decide if importing just the
wrapper is enough.

John

On Mon, Feb 3, 2020 at 5:20 PM Brian Fox wrote:

> I do not have answers to those questions, which seems like good ones.
> I just wanted to break the loop, which I think I might have ;-)
>
> On Mon, Feb 3, 2020 at 5:13 PM David Nalley wrote:
> >
> > My sense from reading this thread is that it was a 'work-for-hire' and
> > that the contributors are not owners. Otherwise, why have they been
> > bothering to talk to Walmart Labs? Why is a company (as opposed to
> > project or indivudal(s)) listed as the copyright holder in source
> > code?
> >
> > The copyright headers identify Takari Inc as the copyright
> > holder/owner, which from this thread seems to have been acquired by
> > Walmart Labs?
> >
> > --David
> >
> > On Mon, Feb 3, 2020 at 11:01 PM Brian Fox wrote:
> > >
> > > I think what Robert is highlighting was that collectively, the
> > > contributors are still owners and have granted permission to use
> > > another license.
> > >
> > > On Mon, Feb 3, 2020 at 4:59 PM David Nalley wrote:
> > > >
> > > > On Mon, Feb 3, 2020 at 9:27 PM Justin Mclean <>
> jus...@classsoftware.com> wrote:
> > > > >
> > > > > HI,
> > > > >
> > > > > I agree with what John wrote, part of the code is EPL which is not
> compatible with the ALv2, you need the owner permission to change the
> license on that..
> > > > >
> > > > > My understanding of "Let me try to get in contact with Walmart
> Labs to get an SGA for the Takari Maven Wrapper.” was that the next step
> would be an SGA.
> > > > >
> > > >
> > > > I agree with Justin.
> > > >
> > > > The lack of an SGA makes this ineligible for the normal lazy
> consensus route.
> > > > The fact that 1 of the chunks of code you're looking at is licensed
> > > > under the EPL is a further blocker. You can't relicense it without
> > > > explicit permission from the owner, preferably memorialized as a 
SGA.
> > > >
> > > > While I don't think that the IP Clearance process is perfectly 
rigid,
> > > > it is a process and this one is missing some significant parts of
> that
> > > > process.
> > > >
> > > > --David
> > > >
> > > > 
-
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> 

Re: [RESULT] [IP CLEARANCE] Maven Wrapper

[Christofer Dutz]

Hi all,

how about just adding the maven-wrapper itself ... the maven plugin isn't even 
needed.
I have been using the maven-wrapper in almost every project, however the plugin 
I have never.

It's just a little tool to add the cmd, sh files as well as some properties. 
I think we could even just whip up a small archive containing this information 
and make that available.

And if we want to I think I'd whip up a maven plugin that automates this in 
just an hour or so.

So I would suggest to add the maven wrapper and just skip the maven plugin.


Chris



Am 04.02.20, 17:07 schrieb "John D. Ament" :

To be very explicit here:

- The code for the maven wrapper is fine, it's already apache licensed and
has no NOTICE file declared with it, so would be perfectly fine to import.
ICLA's would be nice, but not required, and adding a NOTICE indicating the
origination of parts of it would also be nice but not required.
- The code for the Takari Maven Plugin is EPLv1 and requires an SGA to
change the license to apache license.

I'd recommend the Maven PMC take this back and decide if importing just the
wrapper is enough.

John

On Mon, Feb 3, 2020 at 5:20 PM Brian Fox  wrote:

> I do not have answers to those questions, which seems like good ones.
> I just wanted to break the loop, which I think I might have ;-)
>
> On Mon, Feb 3, 2020 at 5:13 PM David Nalley  wrote:
> >
> > My sense from reading this thread is that it was a 'work-for-hire' and
> > that the contributors are not owners. Otherwise, why have they been
> > bothering to talk to Walmart Labs? Why is a company  (as opposed to
> > project or indivudal(s)) listed as the copyright holder in source
> > code?
> >
> > The copyright headers identify Takari Inc as the copyright
> > holder/owner, which from this thread seems to have been acquired by
> > Walmart Labs?
> >
> > --David
> >
> > On Mon, Feb 3, 2020 at 11:01 PM Brian Fox  wrote:
> > >
> > > I think what Robert is highlighting was that collectively, the
> > > contributors are still owners and have granted permission to use
> > > another license.
> > >
> > > On Mon, Feb 3, 2020 at 4:59 PM David Nalley  wrote:
> > > >
> > > > On Mon, Feb 3, 2020 at 9:27 PM Justin Mclean <
> jus...@classsoftware.com> wrote:
> > > > >
> > > > > HI,
> > > > >
> > > > > I agree with what John wrote, part of the code is EPL which is not
> compatible with the ALv2, you need the owner permission to change the
> license on that..
> > > > >
> > > > > My understanding of "Let me try to get in contact with Walmart
> Labs to get an SGA for the Takari Maven Wrapper.” was that the next step
> would be an SGA.
> > > > >
> > > >
> > > > I agree with Justin.
> > > >
> > > > The lack of an SGA makes this ineligible for the normal lazy
> consensus route.
> > > > The fact that 1 of the chunks of code you're looking at is licensed
> > > > under the EPL is a further blocker. You can't relicense it without
> > > > explicit permission from the owner, preferably memorialized as a 
SGA.
> > > >
> > > > While I don't think that the IP Clearance process is perfectly 
rigid,
> > > > it is a process and this one is missing some significant parts of
> that
> > > > process.
> > > >
> > > > --David
> > > >
> > > > 
-
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>



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

[RESULT] [VOTE] Accept StreamPipes into the Apache Incubator

[Christofer Dutz]

). All major 
contributors are still active in the project.

=== External Dependencies ===
We did an initial review of all dependencies used in the various 
projects. No critical libraries that depend on category X licenses were found, 
some minor issues have already been resolved (e.g., removing dependencies to 
org.json libraries). Most external dependencies used by the Java-based 
(backend, pipeline-elements and connect) modules are licensed under the Apache 
License 2.0, whereas some licenses are Cat B (e.g., CDDL). Most external 
dependencies the UI requires on are licensed under the MIT license. 
Once we are moving to the Incubator, we would do a complete check of 
all transitive dependencies. We don't expect any surprises here.

=== Cryptography ===
(not applicable)

=== Required Resources ===

** Mailing Lists **
We plan to use the following mailing lists:
* us...@streampipes.incubator.apache.org
* d...@streampipes.incubator.apache.org
* priv...@streampipes.incubator.apache.org
* comm...@streampipes.incubator.apache.org
As StreamPipes is targeted to a non-technical audience, we see a 
dedicated user mailing list as an important requirement to help users.

** Subversion directory **
(not applicable)

** Git repositories **
We would like to use Git for source code management and enable Github 
mirroring functionality.

As we plan to merge some of the repos described above to simplify the 
release process we ask to create the following source repositories:
* streampipes (containing backend + UI)
* streampipes-extensions (containing modules that can be dynamically 
installed at runtime: pipeline elements and connect adapters)
* streampipes-website (containing docs + website)

** Issue tracking **
JIRA ID: StreamPipes

=== Initial Committers ===
List of initial committers in alphabetical order:
* Christofer Dutz (christofer.dutz at c-ware dot de)
* Dominik Riemer (dominik dot riemer at gmail dot com)
* Johannes Tex (tex at fzi dot de)
* Patrick Wiener (wiener at fzi dot de)
* Philipp Zehnder (zehnder at fzi dot de)

=== Sponsors ===

** Champion **
* Christofer Dutz (christofer.dutz at c-ware dot de)

** Mentors **
* Christofer Dutz (christofer.dutz at c-ware dot de)
* Julian Feinauer (Jfeinauer at apache dot org)
* Kenneth Knowles (kenn at apache dot org)
* Justin Mclean (justin at classsoftware dot com)
* Jean-Baptiste Onofré (jb at nanthrax dot net)

** Sponsoring Entity **
The Apache Incubator


-
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

AW: [VOTE] Accept StreamPipes into the Apache Incubator

[Christofer Dutz]

 do a complete check of all 
transitive dependencies. We don't expect any surprises here.

=== Cryptography ===
(not applicable)

=== Required Resources ===

** Mailing Lists **
We plan to use the following mailing lists:
* us...@streampipes.incubator.apache.org
* d...@streampipes.incubator.apache.org
* priv...@streampipes.incubator.apache.org
* comm...@streampipes.incubator.apache.org
As StreamPipes is targeted to a non-technical audience, we see a dedicated 
user mailing list as an important requirement to help users.

** Subversion directory **
(not applicable)

** Git repositories **
We would like to use Git for source code management and enable Github 
mirroring functionality.

As we plan to merge some of the repos described above to simplify the 
release process we ask to create the following source repositories:
* streampipes (containing backend + UI)
* streampipes-extensions (containing modules that can be dynamically 
installed at runtime: pipeline elements and connect adapters)
* streampipes-website (containing docs + website)

** Issue tracking **
JIRA ID: StreamPipes

=== Initial Committers ===
List of initial committers in alphabetical order:
    * Christofer Dutz (christofer.dutz at c-ware dot de)
* Dominik Riemer (dominik dot riemer at gmail dot com)
* Johannes Tex (tex at fzi dot de)
* Patrick Wiener (wiener at fzi dot de)
* Philipp Zehnder (zehnder at fzi dot de)

=== Sponsors ===

** Champion **
    * Christofer Dutz (christofer.dutz at c-ware dot de)

** Mentors **
    * Christofer Dutz (christofer.dutz at c-ware dot de)
* Julian Feinauer (Jfeinauer at apache dot org)
* Kenneth Knowles (kenn at apache dot org)
* Justin Mclean (justin at classsoftware dot com)
* Jean-Baptiste Onofré (jb at nanthrax dot net)

** Sponsoring Entity **
The Apache Incubator


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




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

Re: [DISCUSS] StreamPipes proposal

[Christofer Dutz]

Hi all,

So are there any more comments, or should we start the vote?

Chris

Am 03.11.19, 11:17 schrieb "Julian Feinauer" :

Hi,

it would of course be awesome to have JB on board.
And indeed what JB suggests was the way I was also thinking of Streampipes 
and had a several discussions with Dominik already.

Currently, Streampipes is some kind of mediator between several "external" 
engines running in different processes or even different nodes.
But I would especially for edge applications highly welcome something which 
is more "edge" centered and designed to run in one process (which then brings 
us back to OSGi or Karaf or something in the long run).

My idea would be to have this as some sort of subproject which shares 
things like a data model and other abstractions, so ideally we could peel out 
into a "shared" core (although Dominik already assumed it to be tons of work... 
__ ).

Julian

Am 02.11.19, 18:14 schrieb "Jean-Baptiste Onofré" :

Thanks guys !

I'm cloning the existing codebase to dig into a little ;)

Regards
JB
    
On 02/11/2019 17:39, Christofer Dutz wrote:
> Hi all,
> 
> I added him to the list.
> 
> Chris
> 
> Am 02.11.19, 11:53 schrieb "Dominik Riemer" :
> 
> Yes, it would be super cool to have you as a mentor, thanks!
> We'll update the list in the wiki.
> 
> Dominik
> 
> -Original Message-
> From: Jean-Baptiste Onofré  
> Sent: Friday, November 1, 2019 6:49 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] StreamPipes proposal
> 
> Hi Dominik,
> 
> it's an interesting proposal !
> 
> It sounds kind of integration platform for IoT protocols (a 
specialized platform compared to frameworks like Apache Camel or NiFi).
> 
> I would be happy to be mentor on the podling if you want !
> 
> Regards
> JB
> 
> On 01/11/2019 16:51, Dominik Riemer wrote:
> > Hi all,
> > 
> > following up my previous mail, we would now like to start an 
open discussion on bringing StreamPipes to the Apache Incubator. StreamPipes is 
an open source self-service toolbox for analyzing (Industrial) IoT data 
streams. We are aware that one of our main challenges will be to diversify the 
developer base and we are willing (and look forward!) to work on that. 
> > 
> > The proposal can be found below and is also listed in the 
Incubator wiki: 
https://cwiki.apache.org/confluence/display/INCUBATOR/StreamPipesProposal, 
thanks @Chris Dutz for creating the page!
> > 
> > We appreciate anyone who would be willing to support us a an 
additional mentor!
> > 
> > 
> > Dominik
> > 
> > 
> > 
> > StreamPipes Proposal
> > 
> > == Abstract ==
> > StreamPipes is a self-service (Industrial) IoT toolbox to 
enable non-technical users to connect, analyze and explore (Industrial) IoT 
data streams.
> > 
> > = Proposal =
> > 
> > The goal of StreamPipes (www.streampipes.org) is to provide an 
easy-to-use toolbox for non-technical users, e.g., domain experts, to exploit 
data streams coming from (Industrial) IoT devices. Such users are provided with 
an intuitive graphical user interface with the Pipeline Editor at its core. 
Users are able to graphically model processing pipelines based on data sources 
(streams), data processors and data sinks. Data processors and sinks are 
self-contained microservices, which implement either stateful or stateless 
processing logic (e.g., a trend detection or image classifier). Their 
processing logic is implemented using one of several provided wrappers (we 
currently have wrappers for standalone/Edge-based processing, Apache Flink, 
Siddhi and working wrapper prototypes for Apache Kafka Streams and Spark, in 
the future we also plan to integrate with Apache Beam). An SDK allows to easily 
create new pipeline elements. Pipeline elements can be installed at runtime. To 
support users in creating pipelines, an underlying semantics-based data model 
enables pipeline elements to express requirements on incoming data streams that 
need to be fulfilled, thus reducing modeling errors.
> > D

Re: [DISCUSS] StreamPipes proposal

[Christofer Dutz]

tioned documentation)
> 
> === Source and intellectual property submission plan === All initial 
committers will sign a ICLA with the ASF. FZI, as the organizational body that 
has employed the main contributors of StreamPipes, will sign a CCLA and donate 
the codebase to the ASF (both subject to formal approval). All major 
contributors are still active in the project.
> 
> === External Dependencies ===
> We did an initial review of all dependencies used in the various 
projects. No critical libraries that depend on category X licenses were found, 
some minor issues have already been resolved (e.g., removing dependencies to 
org.json libraries). Most external dependencies used by the Java-based 
(backend, pipeline-elements and connect) modules are licensed under the Apache 
License 2.0, whereas some licenses are Cat B (e.g., CDDL). Most external 
dependencies the UI requires on are licensed under the MIT license. 
> Once we are moving to the Incubator, we would do a complete check of all 
transitive dependencies. We don't expect any surprises here.
> 
> === Cryptography ===
> (not applicable)
> 
> === Required Resources ===
> 
> ** Mailing Lists **
> We plan to use the following mailing lists:
> * us...@streampipes.incubator.apache.org
> * d...@streampipes.incubator.apache.org
> * priv...@streampipes.incubator.apache.org
> * comm...@streampipes.incubator.apache.org
> As StreamPipes is targeted to a non-technical audience, we see a 
dedicated user mailing list as an important requirement to help users.
> 
> ** Subversion directory **
> (not applicable)
> 
> ** Git repositories **
> We would like to use Git for source code management and enable Github 
mirroring functionality.
> 
> As we plan to merge some of the repos described above to simplify the 
release process we ask to create the following source repositories:
> * streampipes (containing backend + UI)
> * streampipes-extensions (containing modules that can be dynamically 
> installed at runtime: pipeline elements and connect adapters)
> * streampipes-website (containing docs + website)
> 
> ** Issue tracking **
> JIRA ID: StreamPipes
> 
    > === Initial Committers ===
> List of initial committers in alphabetical order:
> * Christofer Dutz (christofer.dutz at c-ware dot de)
> * Dominik Riemer (dominik dot riemer at gmail dot com)
> * Johannes Tex (tex at fzi dot de)
> * Patrick Wiener (wiener at fzi dot de)
> * Philipp Zehnder (zehnder at fzi dot de)
> 
> === Sponsors ===
> 
> ** Champion **
> * Christofer Dutz (christofer.dutz at c-ware dot de)
> 
> ** Mentors **
> * Christofer Dutz (christofer.dutz at c-ware dot de)
> * Julian Feinauer (Jfeinauer at apache dot org)
> * Kenneth Knowles (kenn at apache dot org)
> * Justin Mclean (justin at classsoftware dot com)
> 
> ** Sponsoring Entity **
> The Apache Incubator
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
?B CB ? 
?[  X  ܚX K??K[XZ[
 ? [ \ [
][  X  ܚX P?[  X ]?܋ \?X ?K ܙ B  ܈?Y??]?[ۘ[??  [X[ ? ??K[XZ[
 ? [ \ [
Z?[???[  X ]?܋ \?X ?K ܙ B

?Т�ХF�?V�7V'67&��?R��?�â?vV�W&?��V�7V'67&�?��7V&?F�"�???6�R��Фf�"??FF�F���?�?6���?�G2�?R��?�â?vV�W&?�ֆV�??��7V&?F�"�???6�R��

AW: Write Access to Incubator Wiki

[Christofer Dutz]

enefit for the industrial IoT
>>>> domain, we would also continue development without being an Apache
>> project.
>>>>
>>>>
>>>>
>>>> === Documentation ===
>>>>
>>>> Currently, we host a website at https://www.streampipes.org More
>>>> technical info (user + developer guide) can be found in the
>> documentation:
>>>> https://docs.streampipes.org, where users can find tutorials and
>>>> manuals on how to extend StreamPipes using the SDK.
>>>>
>>>>
>>>>
>>>> === Initial Source ===
>>>>
>>>> Currently, the following Github repositories exist, all licensed under
>>>> the Apache Software License 2.0:
>>>>
>>>> * streampipes (https://www.github.com /streampipes/streampipes, the
>>>> backend & pipeline management module)
>>>>
>>>> * streampipes-ui (https://www.github.com/streampipes/streampipes-ui,
>>>> the UI module)
>>>>
>>>> * streampipes-pipeline-elements (
>>>> https://www.github.com/streampipes/streampipes-pipeline-elements,
>>>> library of data processors and sinks)
>>>>
>>>> * streampipes-connect-adapters (
>>>> https://www.github.com/streampipes/streampipes-connect-adapters,
>>>> StreamPipes connect adapters)
>>>>
>>>> * streampipes-docs
>>>> (https://www.github.com/streampipes/streampipes-docs,
>>>> the abovementioned documentation)
>>>>
>>>>
>>>>
>>>> === Source and intellectual property submission plan === All initial
>>>> committers will sign a ICLA with the ASF. FZI, as the organizational
>>>> body that has employed the main contributors of StreamPipes, will sign
>>>> a CCLA and donate the codebase to the ASF (both subject to formal
>>>> approval). All major contributors are still active in the project.
>>>>
>>>>
>>>>
>>>> === External Dependencies ===
>>>>
>>>> We did an initial review of all dependencies used in the various
>> projects.
>>>> No critical libraries that depend on category X licenses were found,
>>>> some minor issues have already been resolved (e.g., removing
>>>> dependencies to org.json libraries). Most external dependencies used
>>>> by the Java-based (backend, pipeline-elements and connect) modules are
>>>> licensed under the Apache License 2.0, whereas some licenses are Cat B
>>>> (e.g., CDDL). Most external dependencies the UI requires on are
>> licensed under the MIT license.
>>>>
>>>> Once we are moving to the Incubator, we would do a complete check of
>>>> all transitive dependencies. We don't expect any surprises here.
>>>>
>>>>
>>>>
>>>> === Cryptography ===
>>>>
>>>> (not applicable)
>>>>
>>>>
>>>>
>>>> === Required Resources ===
>>>>
>>>> ** Mailing Lists **
>>>>
>>>> We plan to use the following mailing lists:
>>>>
>>>> * us...@streampipes.incubator.apache.org>>> us...@streampipes.incubator.apache.org>
>>>>
>>>> * d...@streampipes.incubator.apache.org>>> d...@streampipes.incubator.apache.org>
>>>>
>>>> * priv...@streampipes.incubator.apache.org>>> priv...@streampipes.incubator.apache.org>
>>>>
>>>> * comm...@streampipes.incubator.apache.org>>> comm...@streampipes.incubator.apache.org>
>>>>
>>>> As StreamPipes is targeted to a non-technical audience, we see a
>>>> dedicated user mailing list as an important requirement to help users.
>>>>
>>>>
>>>>
>>>> ** Subversion directory **
>>>>
>>>> (not applicable)
>>>>
>>>>
>>>>
>>>> ** Git repositories **
>>>>
>>>> We would like to use Git for source code management and enable Github
>>>> mirroring functionality.
>>>>
>>>>
>>>>
>>>> As we plan to merge some of the repos described above to simplify the
>>>> release process we ask to create the following source repositories:
>>>>
>>>> * streampipes (containing backend + UI)
>>>>
>>>> * streampipes-extensions (containing modules that can be dynamically
>>>> installed at runtime: pipeline elements and connect adapters)
>>>>
>>>> * streampipes-website (containing docs + website)
>>>>
>>>>
>>>>
>>>> ** Issue tracking **
>>>>
>>>> JIRA ID: StreamPipes
>>>>
>>>>
>>>>
>>>> === Initial Committers ===
>>>>
>>>> List of initial committers in alphabetical order:
>>>>
>>>> Christofer Dutz (christofer.dutz at c-ware dot de) Dominik Riemer
>>>> (dominik dot riemer at gmail dot com) Johannes Tex (tex at fzi dot de)
>>>> Patrick Wiener (wiener at fzi dot de) Philipp Zehnder (zehnder at fzi
>>>> dot de)
>>>>
>>>>
>>>>
>>>> === Sponsors ===
>>>>
>>>> ** Champion **
>>>>
>>>> * Christofer Dutz (christofer.dutz at c-ware dot de)
>>>>
>>>>
>>>>
>>>> ** Mentors **
>>>>
>>>> * Christofer Dutz (christofer.dutz at c-ware dot de)
>>>>
>>>> * Julian Feinauer (Jfeinauer at apache dot org)
>>>>
>>>> * Justin Mclean (justin at classsoftware dot com)
>>>>
>>>>
>>>>
>>>> ** Sponsoring Entity **
>>>>
>>>> The Apache Incubator
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>


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

Re: Write Access to Incubator Wiki

[Christofer Dutz]

cts.
> No critical libraries that depend on category X licenses were found, 
some
> minor issues have already been resolved (e.g., removing dependencies 
to
> org.json libraries). Most external dependencies used by the Java-based
> (backend, pipeline-elements and connect) modules are licensed under 
the
> Apache License 2.0, whereas some licenses are Cat B (e.g., CDDL). Most
> external dependencies the UI requires on are licensed under the MIT 
license.
>
> Once we are moving to the Incubator, we would do a complete check of 
all
> transitive dependencies. We don't expect any surprises here.
>
>
>
> === Cryptography ===
>
> (not applicable)
>
>
>
> === Required Resources ===
>
> ** Mailing Lists **
>
> We plan to use the following mailing lists:
>
> * us...@streampipes.incubator.apache.org us...@streampipes.incubator.apache.org>
>
> * d...@streampipes.incubator.apache.org d...@streampipes.incubator.apache.org>
>
> * priv...@streampipes.incubator.apache.org priv...@streampipes.incubator.apache.org>
>
> * comm...@streampipes.incubator.apache.org comm...@streampipes.incubator.apache.org>
>
> As StreamPipes is targeted to a non-technical audience, we see a 
dedicated
> user mailing list as an important requirement to help users.
>
>
>
> ** Subversion directory **
>
> (not applicable)
>
>
>
> ** Git repositories **
>
> We would like to use Git for source code management and enable Github
> mirroring functionality.
>
>
    >
> As we plan to merge some of the repos described above to simplify the
> release process we ask to create the following source repositories:
>
> * streampipes (containing backend + UI)
>
> * streampipes-extensions (containing modules that can be dynamically
> installed at runtime: pipeline elements and connect adapters)
>
> * streampipes-website (containing docs + website)
>
>
>
> ** Issue tracking **
>
> JIRA ID: StreamPipes
>
>
>
> === Initial Committers ===
>
> List of initial committers in alphabetical order:
>
> Christofer Dutz (christofer.dutz at c-ware dot de) Dominik Riemer 
(dominik
> dot riemer at gmail dot com) Johannes Tex (tex at fzi dot de) Patrick
> Wiener (wiener at fzi dot de) Philipp Zehnder (zehnder at fzi dot de)
>
>
>
> === Sponsors ===
>
> ** Champion **
>
> * Christofer Dutz (christofer.dutz at c-ware dot de)
>
>
>
> ** Mentors **
>
> * Christofer Dutz (christofer.dutz at c-ware dot de)
>
> * Julian Feinauer (Jfeinauer at apache dot org)
>
> * Justin Mclean (justin at classsoftware dot com)
>
>
>
> ** Sponsoring Entity **
>
> The Apache Incubator
>
>



-
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: Donation of subproject for PLC4X

[Christofer Dutz]

Hi all,

We have that on our radar and that's why we're discussion naming options.
We're not planning or ever had planned naming it "Crunch".

Chris


Am 07.10.19, 10:57 schrieb "Bertrand Delacretaz" :

On Mon, Oct 7, 2019 at 10:52 AM Lars Francke  wrote:
> ...while a name search is not necessary I'm sure you're aware that there's
> already an Apache Crunch project which _might_ confuse people...

Good point, thanks!

While a formal podling name search is not needed, it's of course a
good idea to choose a somewhat unique name. My favorite metric for
that is if Google doesn't find the suggested name...

-Bertrand

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

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Christofer Dutz]

I agree,

I think that the "requirement" (Never really knew there was such a requirement) 
of being a Member sort of gives you the easy entry path as if you are a member 
people expect you to understand the Apache Way.

However that doesn't mean that people not being a member don't get the Apache 
Way and hereby should be excluded. 

Chris

PS: Sorry for being silent for quite some time ... was 100% swamped with 
TAC and ACEU preparations ...



Am 13.08.19, 08:29 schrieb "Julian Feinauer" :

Hi,

I'm a new IPMC Member (no foundation member) and come from a PLC4X which 
has graduated months ago.
I already started to help other Podlings a bit.

And I agree with Dave in the sense that we should seek our way not in 
locking-out people but in finding ways to draw in more people.
It was already said multiple times that people from "mature" podlings or 
freshly graduated projects would be a good call as mentors this should be ONE 
way to go.

Julian

Am 13.08.19, 01:42 schrieb "Dave Fisher" :



> On Aug 12, 2019, at 4:29 PM, Greg Stein  wrote:
> 
> On Mon, Aug 12, 2019 at 5:26 PM Justin Mclean 

> wrote:
> 
>> Hi,
>> 
>>> I will also note that if the IPMC switches to *voting* Members into 
the
>>> IPMC, that the Apache Member will be observing that vote take place 
on
>>> private@ through a subscription (they can reply!) or via the 
archives. …
>> 
>> Which is also the same for any project who votes in a ASF member as a
>> committer or PMC member.
>> 
> 
> I would counter that any project which creates such a bar for ASF 
Members
> may be doing it Wrong :)
> 
> (this goes into my general feeling that projects generally need to 
lower
> their bars, and become more inclusive)

I really think that we have long precedent to do most of what we need 
to do already in place.

I’m -1 on this proposal. I think it is a bad idea. It is so bad that I 
would seriously think about volunteering here less.

Just think about how many VOTEs we would need to do when a Podling 
comes in. Think about all the pro forma votes and discussions about people. 
BORING!

Frankly, I’m quite surprised that this is even being proposed.

Regards,
Dave

> 
> Cheers,
> -g


-
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

New IoT related exchange mailinglist

[Christofer Dutz]

Hi all,

as I know there’s a lot of IoT stuff going on in the incubator, I would like to 
advertise a new mailing list we recently created.

i...@apache.org

It’s a mailing list intended to help increase the communication between the 
projects in the IoT area.

It would be great if as many as possible people involved in IoT related 
projects would sign up
and start exchanging ideas and communicating what your projects are currently 
up to.

Thanks,
  Chris

Re: Move the Zipkin repos back, as the community has voted to leave.

[Christofer Dutz]

But if you are releasing Maven artifacts, I would assume that you change the 
group-ids to not start with "org.apache" 
and the packages should probably be changed too. But not 100% sure if this is 
just a nice-to-have or a hard requirement.
And also I didn't check the coordinates or package structure of the repo ... so 
just ignore me, if this all doesn't apply ;-)

Chris



Am 17.06.19, 11:52 schrieb "Sheng Wu" :

Hi Incubator.

As a Zipkin incubator mentor, I am asking to make Zipkin all repositories 
back to original OpenZipkin org as soon as possible.

They have done a public ml vote, result is here[1].
Also, with no transfer happened about Zipkin trademark, logo, domain, so, 
there is no such thing about return the trademark or permission of using Zipkin 
name.

Zipkin is a big community and a lots of dependency out there are waiting 
for release.

I think there is nothing hold this transfer, right?
If so, please give a clear reply. The INFRA team is waiting at this JIRA 
ticket[2].


[1] 
https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
 

[2] https://issues.apache.org/jira/browse/INFRA-18604 



Sheng Wu
Apache Skywalking, ShardingSphere, Zipkin






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

Re: Incubation Pain Points

[Christofer Dutz]

I can see how this can be annoying, 

But I also have to see the IPMC workload ... we're raising quite a number of 
podlings. 
Having the votes start in parallel on the podling dev and the general incubator 
list 
would probably not decrease the number of cancelled votes. I would be fine with 
allowing parallel votes, if the podlings mentors have voted in favor of the 
release. 

So you start a vote in the podlings dev list and as soon as the mentors have 
voted +1
You could start the vote in the general incubator list, but not before that. 

I mean It's one of the most important jobs of the mentors to thoroughly check 
the RCs.
If there are realy valid issues for which the vote in the general list is -1ed, 
that's actually 
not really the fault of the Incubator, but could considered the fault of your 
mentors.
And if these RCs are waived through with serious issues over and over again, I 
would
Instead start thinking of getting mentors on board, that do the checks before 
you carry 
over. 

For exactly that reason I asked Justin to mentor PLC4X when it entered 
incubation.
He did raise quite a lot of issues, but on the project list and prior to 
carrying over the
Vote to the general incubator list. And I can't remember a single RC cancelled 
because 
Of IPMC votes on the incubator list.

Chris





Am 17.06.19, 11:15 schrieb "Geertjan Wielenga" :

I agree and that’s how I see it too — coming to Apache means the assumption
that you’re wanting to adopt its culture. However, there are definitely
very frustrating aspects to that culture. The biggest fix I’d suggest for
the incubator is parallel voting — i.e., start the PPMC vote and IPMC vote
at the same time.

I cannot tell you how many times I’ve wanted to stab myself with a blunt
instrument in the eye after having to restart the PPMC vote yet again (with
less and less enthusiasm from the community and thus less voting and more
time wasting) after an IPMC vote failed yet again on some aspect that the
community is not interested in at all (but should be, but still isn’t).

Gj


On Mon, 17 Jun 2019 at 10:24, Christofer Dutz 
wrote:

> Hi Geertjan,
>
> not quite sure how to read this ... what are you referring to as "new
> culture".
> The existing project coming to the ASF? And this project should adopt the
> tradition of the ASF.
> Or that the ASF should adopt the culture and tradition of the project
> joining?
> (Probably then meant more as: Allowing them to continue than the ASF to
> change)
>
> I think projects coming to the ASF have to be educated prior to entering
> incubation that
> there will almost always be things we are expecting them to change when
> they come to Apache
> and that there's no discussion on if they have to follow them.
>
> We have to make them understand that the ASF is more than a GIT repo, CI
> Server and Mailing lists.
> That the ASF has great things to provide (Legal Shield, Marketing, Infra,
> ...) but that this only works
> If you play along with some rules we have. Also should we explain WHY
> these rules are there.
>
> I would say it's sort of like emigrating to another country: You probably
> move for some reasons.
> But also probably the rules are a little different at the country you are
> moving. There will be things
> You will be allowed to do the same way you always did it, but there will
> be things expected of you
> to simply follow and not ignore, because you think otherwise.
>
> We have to find a way to state the rules and what we expect before
> podlings enter incubation.
>
> Still we will have podlings that sort of remind me of small children
> simply not willing to do something simple,
> Just cause a parent told them to: "No, I will not say thank you".
>
> Or converted to our world: "No, I will not add anything to any Notice", or
> "No, I will not credit stuff I
> obviously borrowed somewhere" ... but this way we can always refer to the
> rules being clearly
> communicated prior to entering incubation and not have to listen to
> complaints all the time.
>
> And for my point of view: If there are projects, that join the ASF, but
> don't want to play according to the
> Rules - we're off way better without them. At least I don't want to invest
> my time (which is already
> Spread out pretty thin with all the things I do for the ASF) to deal with
> rebellious podlings.
>
> Chris
>
>
>
>
> Perhaps creating a training session as part of the training podling
>
> Am

Re: Incubation Pain Points

[Christofer Dutz]

Hi Geertjan,

not quite sure how to read this ... what are you referring to as "new culture".
The existing project coming to the ASF? And this project should adopt the 
tradition of the ASF.
Or that the ASF should adopt the culture and tradition of the project joining?
(Probably then meant more as: Allowing them to continue than the ASF to change)

I think projects coming to the ASF have to be educated prior to entering 
incubation that 
there will almost always be things we are expecting them to change when they 
come to Apache
and that there's no discussion on if they have to follow them.

We have to make them understand that the ASF is more than a GIT repo, CI Server 
and Mailing lists.
That the ASF has great things to provide (Legal Shield, Marketing, Infra, ...) 
but that this only works
If you play along with some rules we have. Also should we explain WHY these 
rules are there.

I would say it's sort of like emigrating to another country: You probably move 
for some reasons.
But also probably the rules are a little different at the country you are 
moving. There will be things
You will be allowed to do the same way you always did it, but there will be 
things expected of you
to simply follow and not ignore, because you think otherwise.

We have to find a way to state the rules and what we expect before podlings 
enter incubation.

Still we will have podlings that sort of remind me of small children simply not 
willing to do something simple, 
Just cause a parent told them to: "No, I will not say thank you".

Or converted to our world: "No, I will not add anything to any Notice", or "No, 
I will not credit stuff I 
obviously borrowed somewhere" ... but this way we can always refer to the rules 
being clearly 
communicated prior to entering incubation and not have to listen to complaints 
all the time.

And for my point of view: If there are projects, that join the ASF, but don't 
want to play according to the
Rules - we're off way better without them. At least I don't want to invest my 
time (which is already
Spread out pretty thin with all the things I do for the ASF) to deal with 
rebellious podlings.

Chris




Perhaps creating a training session as part of the training podling

Am 13.06.19, 22:29 schrieb "Geertjan Wielenga" :

Speaking on behalf of myself only, though note I am PMC chair of NetBeans,
which went through a protracted (nice way of saying ‘complex’) incubation
because of its size (‘very large’) and history (20+ years) — the key to any
new culture is to adopt its traditions and to fight them as little as
possible. And one can’t really understand the culture until one is in it.
It’s hard to really prepare — other than to admire projects like Maven or
TomEE and to want and aim to be like them, regardless of the contortions
required to get there.

Gj


On Thu, 13 Jun 2019 at 21:10, Dave Fisher  wrote:

> Hi -
>
> Here are some thoughts I have to improving Incubation. These are not
> really new, but I think we should discuss where and how best to apply 
these.
>
> (1) Champions need to very clear that the ASF expects Community decisions
> not BDFLs. Burnout is one factor to highlight why community is important.
> Vendor independence is important and part of why BDFLs don’t fly. In the
> last few years we have deemphasized the role of Champion and I think we
> need to list out some of the duties a Champion has to both the prospective
> podling community and the Incubator.
>
> (2) We should help existing communities plan their entry into Incubation
> with their proposals. Currently TVM is moving their community over before
> repositories. That might be a better approach for many communities as it
> will assure that (a) the existing community keeps its current velocity and
> (b) they are making community decisions on list before actual development
> is moved over.
>
> (3) Having a lower impedance to release and code changes would really
> help. We are already having this discussion. A very radical idea might be
> to move a lot of the License, Notice and Dependency work away from the
> Release Vote and instead do periodic and potentially automated audits of
> repositories. This would follow the REVIEW suggestion, but make it more
> automated and based on tooling.
>
> (4) Relinquishing control of admin rights on GitHub repos is an impedance.
> I understand why this is done from an Apache Infrastructure perspective,
> but it is a surprise to podling communities. Making sure that a new 
podling
> knows fully what to expect before transferring repos would really help
> manage expectations.
>
> (5) Failure to incubate is not failure. Currently 63 podlings have retired
> and there are two or three additional retirements soon. 4 or 5 podlings
> moved on or back to where they were. The why of retirement 

Re: late learnings, which could be helpful for all mentors to know

[Christofer Dutz]

How about this as compromise?

If the mentors on the project list have voted +1, then the vote can be 
continued in parallel? Shouldn't this help reduce both the time votes take but 
not waste the limited IPMC bandwidth?

Regarding releasing of all repos ... how about this: 
Instead of having to actually DO releases, at least Release Candidates should 
be created ... this would prove the general ability to do a release, but not 
actually DO it. Of course if these RCs contain bad things, they should not pass.

Having some automated tooling would have the benefit of finding more than 
currently and it would at least help with the projects being able to run those 
checks themselves and therefore being able to react first. If a RC fails and 
things are found by the tooling it's not the person reporting this who is 
considered the bad guy cause we could all say: It's the standard tooling that 
found this and you could have addressed that yourself before releasing. I know 
it doesn't find all issues, but if it finds more than currently, then that's a 
good thing. The only danger I see is that we (IPMC) might grow comfortable and 
simply trust on the tool. 

Chris



Am 05.06.19, 09:50 schrieb "Justin Mclean" :

Hi,

Please take this as friendly advice with with a bit of experience and 
personal opinion thrown in. (if that intent is not obvious).

> * "parallel votes" is a technique to reduce the lag between dev@ and
> general@ by starting the IPMC vote slightly after, but before
> conclusion of the PPMC one. This may have only been tried once (in
> Zipkin) and met resistance.

Please start a new thread where this can be discussed as an option. I think 
the main issue will be that it takes up too much of a limited resource (i.e. 
IPMC volunteer time) and it's better to have the podling checks first, 
especially for technical issues. I've seen some releases go though a dozen 
release candidates before being put up to the IPMC, I don’t think the IPMC 
would like to see those dozen release candidates and to have them withdrawn 
each time. I understand that it feels inconvenient to podlings who may be used 
to making technical releases without voting on them and not checking for 
licensing and other issues previously. It could possibly be an option, if 
approved by the IPMC, for podlings who have previously made 100% compliant 
releases.

> * "bundled votes" is a technique where multiple repos are sent in a
> single vote. This is much more efficient for coupled repos than
> pipelining. OpenWhisk uses this and don't appear to have met
> resistance.

That is fine but the IPMC will likely complain if it contains too many 
release artefacts or it may not attract enough votes due to time commitment 
required to review. There's also a risk that if one artefact is broken you need 
to make another release candidate of everything, meaning more work for a 
podling.

> * not all repos need to actually release prior to graduation. Both
> Dubbo and OpenWhisk had unreleased repos when they called for
> graduation.

The point here is not that all repos need to have releases or be moved over 
before graduation but that the podling needs to show that it can make releases 
on it own that conform to all legal, release, distribution and other ASF 
policies. Actually deeper than just that, that the PPMC can recognise issues 
when they occur, and most importantly self-correct on their own. They need to 
embody the ASF values (usually referred as the Apache Way) in the way they act, 
their structure, how they recognises merit and how they makes decisions. 
Learning to making releases is a part of that.

> * You are allowed to automate release process

Take care with this, most automation is not going to check or find 
everything. It not going to know if some code was copied from somewhere it 
shouldn’t be or that something is labeled as license A but actually contains 
something that is Category X or you don’t have the rights to distribute that 
cat photo. It will catch obvious errors and is really good at that. A PPMC 
needs to learn why we have these policies and the values under them not just 
apply "the rules”, using automation in this way  IMO is a little problematic 
during incubation as it can hide what the podling needs to show they understand 
before graduating. I would guess 1/3 to 1/4 of the serious issues the IPMC 
catches in releases, wouldn’t be found by automation or a script.

> * ASF tools like RAT and the release plugin are barely maintained in
> comparison with Incubator policy.

There's nothing in Rat that deals with incubator policy. Incubator policy 
is that releases need have a DISCLAIMER, have incubating in their name and be 
voted on by the IPMC. I think you mean to say ASF’s release, distribution, 
branding  or other policies? Rat highlights possible issues, it reports require 

[RESULT] [VOTE] Recommend 'Apache PLC4X graduation to Top Level Project' resolution to board

[Christofer Dutz]

Hi all,

The vote passes with:

6 +1 Votes
0 -1 Votes

I'll add the resolution to the board meeting agenda for the meeting on 
17.04.2019.

Thanks for your support,
   Chris



Am 10.04.19, 04:47 schrieb "Christofer Dutz" :

Justin just pointed out that the section:

“RESOLVED, that the initial Apache PLC4X 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 PLC4X Project; and be it
further”

should be omitted and not taken over into the final resolution.

Chris

On 2019/04/09 08:08:45, Christofer Dutz  wrote: 
> Hello,
> 
> The Apache PLC4X podling community has successfully[0] voted[1] to
> graduate to a top-level project (Even seem to have mis-counted the +1 
votes). 
> Accordingly, I'm bringing the resolution up for an IPMC VOTE.
> 
> The podling vote result was:
> Overall: 9 x +1 votes, 0 x -1 votes
> 
> 8 binding +1 votes: Christofer Dutz, Tim Mitsch, Julian Feinauer, Greg 
Trasuk, Sebastian Rühl, Justin Mclean, Markus Sommer, Stefan Bodewig
> 1 non-binding +1 vote: Andreas Oswald
> 
> No 0 or -1.
> 
> Since entering the Incubator in 2017, the Apache PLC4X community has:
>* sent 1.908 emails by 57 participants in the mailing lists [2]
>* successfully produced 4 project releases
>* setup a complete website including project documentation
>* added 4 new committers/PPMC members
>* built a diverse group of committers from multiple different employers
>* had more than 108 JIRA tickets opened with 59 closed (Open ones are 
mostly marker issues)
>* completed the project maturity model with positive responses [3] 
(except where it contradicts the incubator rules)
> 
> Here's my binding +1.  The VOTE will run for at least 72 hours.
> 
> Thanks & best regards,
>   Christofer Dutz
> 
> [0] 
https://lists.apache.org/thread.html/d53c159c6e8973a6e763635c90bc0f52e0c4fa576da80f553bc4aa40@%3Cdev.plc4x.apache.org%3E
> [1] 
https://lists.apache.org/thread.html/9a4cf5b1ad7b59e79ae33f3d09032e7942a7191a319335303e16d286@%3Cdev.plc4x.apache.org%3E
> [2] https://lists.apache.org/trends.html?d...@plc4x.apache.org:lte=5y:
> [3] http://plc4x.apache.org/developers/maturity.html
> 
> ---
> 
> Establish the Apache PLC4X 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 set of libraries for communicating with industrial
> programmable logic controllers (PLCs) using a variety of protocols but
> with a shared API.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache PLC4X Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
> 
> RESOLVED, that the Apache PLC4X Project be and hereby is responsible for
> the creation and maintenance of software related to a set of libraries
> for communicating with industrial programmable logic controllers (PLCs)
> using a variety of protocols but with a shared API; and be it further
> 
> RESOLVED, that the office of "Vice President, Apache PLC4X" 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 PLC4X
> Project, and to have primary responsibility for management of the
> projects within the scope of responsibility of the Apache PLC4X 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 PLC4X Project:
> 
> * Christofer Dutzmailto:cd...@apache.org>>
> * Julian Feinauermailto:jfeina...@apache.org>>
> * Justin Mclean  mailto:jmcl...@apache.org>>
> * Markus Sommer  mailto:msom...@apache.org>>
> * Sebastian Rühl mailto:sru...@apache.org>>
> * Tim Mitsch mailto:tmit...@apache.org>>
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Christofer Dutz be
> appointed to the office of Vice President, Apache PLC4X, to serve in
> accordance with and subject to the direction of the Board of Directors
> and the Bylaws of the Foundation until death, resign

Re: [VOTE] Recommend 'Apache PLC4X graduation to Top Level Project' resolution to board

[Christofer Dutz]

Justin just pointed out that the section:

“RESOLVED, that the initial Apache PLC4X 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 PLC4X Project; and be it
further”

should be omitted and not taken over into the final resolution.

Chris

On 2019/04/09 08:08:45, Christofer Dutz  wrote: 
> Hello,
> 
> The Apache PLC4X podling community has successfully[0] voted[1] to
> graduate to a top-level project (Even seem to have mis-counted the +1 votes). 
> Accordingly, I'm bringing the resolution up for an IPMC VOTE.
> 
> The podling vote result was:
> Overall: 9 x +1 votes, 0 x -1 votes
> 
> 8 binding +1 votes: Christofer Dutz, Tim Mitsch, Julian Feinauer, Greg 
> Trasuk, Sebastian Rühl, Justin Mclean, Markus Sommer, Stefan Bodewig
> 1 non-binding +1 vote: Andreas Oswald
> 
> No 0 or -1.
> 
> Since entering the Incubator in 2017, the Apache PLC4X community has:
>* sent 1.908 emails by 57 participants in the mailing lists [2]
>* successfully produced 4 project releases
>* setup a complete website including project documentation
>* added 4 new committers/PPMC members
>* built a diverse group of committers from multiple different employers
>* had more than 108 JIRA tickets opened with 59 closed (Open ones are 
> mostly marker issues)
>* completed the project maturity model with positive responses [3] (except 
> where it contradicts the incubator rules)
> 
> Here's my binding +1.  The VOTE will run for at least 72 hours.
> 
> Thanks & best regards,
>   Christofer Dutz
> 
> [0] 
> https://lists.apache.org/thread.html/d53c159c6e8973a6e763635c90bc0f52e0c4fa576da80f553bc4aa40@%3Cdev.plc4x.apache.org%3E
> [1] 
> https://lists.apache.org/thread.html/9a4cf5b1ad7b59e79ae33f3d09032e7942a7191a319335303e16d286@%3Cdev.plc4x.apache.org%3E
> [2] https://lists.apache.org/trends.html?d...@plc4x.apache.org:lte=5y:
> [3] http://plc4x.apache.org/developers/maturity.html
> 
> ---
> 
> Establish the Apache PLC4X 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 set of libraries for communicating with industrial
> programmable logic controllers (PLCs) using a variety of protocols but
> with a shared API.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache PLC4X Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
> 
> RESOLVED, that the Apache PLC4X Project be and hereby is responsible for
> the creation and maintenance of software related to a set of libraries
> for communicating with industrial programmable logic controllers (PLCs)
> using a variety of protocols but with a shared API; and be it further
> 
> RESOLVED, that the office of "Vice President, Apache PLC4X" 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 PLC4X
> Project, and to have primary responsibility for management of the
> projects within the scope of responsibility of the Apache PLC4X 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 PLC4X Project:
> 
> * Christofer Dutzmailto:cd...@apache.org>>
> * Julian Feinauermailto:jfeina...@apache.org>>
> * Justin Mclean  mailto:jmcl...@apache.org>>
> * Markus Sommer  mailto:msom...@apache.org>>
> * Sebastian Rühl mailto:sru...@apache.org>>
> * Tim Mitsch mailto:tmit...@apache.org>>
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Christofer Dutz be
> appointed to the office of Vice President, Apache PLC4X, 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 PLC4X 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 PLC4X Project; and be it
> further
> 
> RESOLVED, that the Apache PLC4X Project be and hereby is tasked with the
> migration and rationalization of the Apache Incubator PLC4X podling; and
> be it further
> 
> RESOLVED,

[VOTE] Recommend 'Apache PLC4X graduation to Top Level Project' resolution to board

[Christofer Dutz]

Hello,

The Apache PLC4X podling community has successfully[0] voted[1] to
graduate to a top-level project (Even seem to have mis-counted the +1 votes). 
Accordingly, I'm bringing the resolution up for an IPMC VOTE.

The podling vote result was:
Overall: 9 x +1 votes, 0 x -1 votes

8 binding +1 votes: Christofer Dutz, Tim Mitsch, Julian Feinauer, Greg Trasuk, 
Sebastian Rühl, Justin Mclean, Markus Sommer, Stefan Bodewig
1 non-binding +1 vote: Andreas Oswald

No 0 or -1.

Since entering the Incubator in 2017, the Apache PLC4X community has:
   * sent 1.908 emails by 57 participants in the mailing lists [2]
   * successfully produced 4 project releases
   * setup a complete website including project documentation
   * added 4 new committers/PPMC members
   * built a diverse group of committers from multiple different employers
   * had more than 108 JIRA tickets opened with 59 closed (Open ones are mostly 
marker issues)
   * completed the project maturity model with positive responses [3] (except 
where it contradicts the incubator rules)

Here's my binding +1.  The VOTE will run for at least 72 hours.

Thanks & best regards,
  Christofer Dutz

[0] 
https://lists.apache.org/thread.html/d53c159c6e8973a6e763635c90bc0f52e0c4fa576da80f553bc4aa40@%3Cdev.plc4x.apache.org%3E
[1] 
https://lists.apache.org/thread.html/9a4cf5b1ad7b59e79ae33f3d09032e7942a7191a319335303e16d286@%3Cdev.plc4x.apache.org%3E
[2] https://lists.apache.org/trends.html?d...@plc4x.apache.org:lte=5y:
[3] http://plc4x.apache.org/developers/maturity.html

---

Establish the Apache PLC4X 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 set of libraries for communicating with industrial
programmable logic controllers (PLCs) using a variety of protocols but
with a shared API.

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

RESOLVED, that the Apache PLC4X Project be and hereby is responsible for
the creation and maintenance of software related to a set of libraries
for communicating with industrial programmable logic controllers (PLCs)
using a variety of protocols but with a shared API; and be it further

RESOLVED, that the office of "Vice President, Apache PLC4X" 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 PLC4X
Project, and to have primary responsibility for management of the
projects within the scope of responsibility of the Apache PLC4X 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 PLC4X Project:

* Christofer Dutzmailto:cd...@apache.org>>
* Julian Feinauermailto:jfeina...@apache.org>>
* Justin Mclean  mailto:jmcl...@apache.org>>
* Markus Sommer  mailto:msom...@apache.org>>
* Sebastian Rühl mailto:sru...@apache.org>>
* Tim Mitsch mailto:tmit...@apache.org>>

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Christofer Dutz be
appointed to the office of Vice President, Apache PLC4X, 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 PLC4X 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 PLC4X Project; and be it
further

RESOLVED, that the Apache PLC4X Project be and hereby is tasked with the
migration and rationalization of the Apache Incubator PLC4X podling; and
be it further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
PLC4X 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

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

[Christofer Dutz]

Hi all,

as there seem to be no objections, I'll start the VOTE.

Thanks,
Chris

On 2019/04/04 13:59:15, Christofer Dutz  wrote: 
> Hi all,
> 
> Since Apache PLC4X (incubating) entered the incubator in December 2017 we 
> have attracted quite a number of new PPMCs,
> committers and contributors that didn’t have any experience with Apache and 
> the Apache Way.
> 
> However have we managed to educate these new individuals and have grown to a 
> community that operates nicely following
> the Apache Way. All issues reported have been addressed and our last releases 
> usually passed without any objections.
> 
> We recently had a discussion on graduation [5] and just finished a community 
> vote [2] on the matter which resulted in 7 (binding) +1, 1 (non-binding) +1 
> and no 0 or -1 votes [1].
> In another discussion prior to the vote we decided to reduce the number of 
> PMCs/Committers to those existing who explicitly expressed the wish to be 
> included [3].
> This was due to the fact that when setting up the project outside of Apache, 
> a lot of my colleagues initially expressed the wish to participate and we 
> included them in the initial contributor list.
> However most of these never did anything and some didn’t even sign up for our 
> mailing lists.
> Some have expressed the wish to go emeritus and we used a vote [4] to define 
> the initial PMC for the TLP.
> 
> We would like to continue the graduation process and hereby ask you all for 
> your opinion on this.
> 
> Chris
> 
> [1] 
> https://lists.apache.org/thread.html/d53c159c6e8973a6e763635c90bc0f52e0c4fa576da80f553bc4aa40@%3Cdev.plc4x.apache.org%3E
> [2] 
> https://lists.apache.org/thread.html/9a4cf5b1ad7b59e79ae33f3d09032e7942a7191a319335303e16d286@%3Cdev.plc4x.apache.org%3E
> [3] 
> https://lists.apache.org/thread.html/d14e972889dad4ca9cb72f2447edb422df2742f8d71bf140618ba021@%3Cdev.plc4x.apache.org%3E
> [4] 
> https://lists.apache.org/thread.html/7a979438fa050bc873a4df0da9b628edaa61d350a17364b837a059d3@%3Cdev.plc4x.apache.org%3E
> [5] 
> https://lists.apache.org/thread.html/0a590c8aabced1b46e1200aeface51e9fe34cdf01ed7753a6779ce55@%3Cdev.plc4x.apache.org%3E
> 
> 
> ---
> 
> Establish the Apache PLC4X 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 set of libraries for communicating with industrial
> programmable logic controllers (PLCs) using a variety of protocols but
> with a shared API.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache PLC4X Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
> 
> RESOLVED, that the Apache PLC4X Project be and hereby is responsible for
> the creation and maintenance of software related to a set of libraries
> for communicating with industrial programmable logic controllers (PLCs)
> using a variety of protocols but with a shared API; and be it further
> 
> RESOLVED, that the office of "Vice President, Apache PLC4X" 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 PLC4X
> Project, and to have primary responsibility for management of the
> projects within the scope of responsibility of the Apache PLC4X 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 PLC4X Project:
> 
> * Christofer Dutzmailto:cd...@apache.org>>
> * Julian Feinauermailto:jfeina...@apache.org>>
> * Justin Mclean  mailto:jmcl...@apache.org>>
> * Markus Sommer  mailto:msom...@apache.org>>
> * Sebastian Rühl mailto:sru...@apache.org>>
> * Tim Mitsch mailto:tmit...@apache.org>>
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Christofer Dutz be
> appointed to the office of Vice President, Apache PLC4X, 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 PLC4X 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 PLC4X Project; and be it
> furt

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

[Christofer Dutz]

Hi Dave,

The one addition you mention explicitly said, that due to changes at work he 
will not be able to participate and is not willing to invest his private time 
:-( ... But we are more than willing to re-invite past contributors later, if 
they decided not to be carried over now.

And yes, there are potential candidates that we are keeping an eye on, which we 
will probably invite soon.

We know there are way larger communities in the incubator but as far as I 
understand incubation, it's all about the projects learning to become good 
Apache communities and that they demonstrate their fitness to do correct 
releases. I guess we have proven that and continuing to grow community is and 
will remain the goal of every Apache project throughout it's existence.

Chris


Outlook für Android<https://aka.ms/ghei36> herunterladen


From: Dave Fisher 
Sent: Thursday, April 4, 2019 8:14:00 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Graduate Apache PLC4X (incubating) as a TLP

Hi -

I am for graduation. I appreciate the need to narrow the PMC to those who are 
active. I’ll note that one of your recent additions (noted on the Oct 2018 
report) did not continue while the other did.

Graduating with only 6 PMC is pretty narrow. Are there other developers active 
who look like you will want to add to the committer / PMC soon after graduation?

Best Regards,
Dave

> On Apr 4, 2019, at 6:59 AM, Christofer Dutz  wrote:
>
> Hi all,
>
> Since Apache PLC4X (incubating) entered the incubator in December 2017 we 
> have attracted quite a number of new PPMCs,
> committers and contributors that didn’t have any experience with Apache and 
> the Apache Way.
>
> However have we managed to educate these new individuals and have grown to a 
> community that operates nicely following
> the Apache Way. All issues reported have been addressed and our last releases 
> usually passed without any objections.
>
> We recently had a discussion on graduation [5] and just finished a community 
> vote [2] on the matter which resulted in 7 (binding) +1, 1 (non-binding) +1 
> and no 0 or -1 votes [1].
> In another discussion prior to the vote we decided to reduce the number of 
> PMCs/Committers to those existing who explicitly expressed the wish to be 
> included [3].
> This was due to the fact that when setting up the project outside of Apache, 
> a lot of my colleagues initially expressed the wish to participate and we 
> included them in the initial contributor list.
> However most of these never did anything and some didn’t even sign up for our 
> mailing lists.
> Some have expressed the wish to go emeritus and we used a vote [4] to define 
> the initial PMC for the TLP.
>
> We would like to continue the graduation process and hereby ask you all for 
> your opinion on this.
>
> Chris
>
> [1] 
> https://lists.apache.org/thread.html/d53c159c6e8973a6e763635c90bc0f52e0c4fa576da80f553bc4aa40@%3Cdev.plc4x.apache.org%3E
> [2] 
> https://lists.apache.org/thread.html/9a4cf5b1ad7b59e79ae33f3d09032e7942a7191a319335303e16d286@%3Cdev.plc4x.apache.org%3E
> [3] 
> https://lists.apache.org/thread.html/d14e972889dad4ca9cb72f2447edb422df2742f8d71bf140618ba021@%3Cdev.plc4x.apache.org%3E
> [4] 
> https://lists.apache.org/thread.html/7a979438fa050bc873a4df0da9b628edaa61d350a17364b837a059d3@%3Cdev.plc4x.apache.org%3E
> [5] 
> https://lists.apache.org/thread.html/0a590c8aabced1b46e1200aeface51e9fe34cdf01ed7753a6779ce55@%3Cdev.plc4x.apache.org%3E
>
>
> ---
>
> Establish the Apache PLC4X 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 set of libraries for communicating with industrial
> programmable logic controllers (PLCs) using a variety of protocols but
> with a shared API.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache PLC4X Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache PLC4X Project be and hereby is responsible for
> the creation and maintenance of software related to a set of libraries
> for communicating with industrial programmable logic controllers (PLCs)
> using a variety of protocols but with a shared API; and be it further
>
> RESOLVED, that the office of "Vice President, Apache PLC4X" 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 PLC4X
> Project, a

[DISCUSS] Graduate Apache PLC4X (incubating) as a TLP

[Christofer Dutz]

Hi all,

Since Apache PLC4X (incubating) entered the incubator in December 2017 we have 
attracted quite a number of new PPMCs,
committers and contributors that didn’t have any experience with Apache and the 
Apache Way.

However have we managed to educate these new individuals and have grown to a 
community that operates nicely following
the Apache Way. All issues reported have been addressed and our last releases 
usually passed without any objections.

We recently had a discussion on graduation [5] and just finished a community 
vote [2] on the matter which resulted in 7 (binding) +1, 1 (non-binding) +1 and 
no 0 or -1 votes [1].
In another discussion prior to the vote we decided to reduce the number of 
PMCs/Committers to those existing who explicitly expressed the wish to be 
included [3].
This was due to the fact that when setting up the project outside of Apache, a 
lot of my colleagues initially expressed the wish to participate and we 
included them in the initial contributor list.
However most of these never did anything and some didn’t even sign up for our 
mailing lists.
Some have expressed the wish to go emeritus and we used a vote [4] to define 
the initial PMC for the TLP.

We would like to continue the graduation process and hereby ask you all for 
your opinion on this.

Chris

[1] 
https://lists.apache.org/thread.html/d53c159c6e8973a6e763635c90bc0f52e0c4fa576da80f553bc4aa40@%3Cdev.plc4x.apache.org%3E
[2] 
https://lists.apache.org/thread.html/9a4cf5b1ad7b59e79ae33f3d09032e7942a7191a319335303e16d286@%3Cdev.plc4x.apache.org%3E
[3] 
https://lists.apache.org/thread.html/d14e972889dad4ca9cb72f2447edb422df2742f8d71bf140618ba021@%3Cdev.plc4x.apache.org%3E
[4] 
https://lists.apache.org/thread.html/7a979438fa050bc873a4df0da9b628edaa61d350a17364b837a059d3@%3Cdev.plc4x.apache.org%3E
[5] 
https://lists.apache.org/thread.html/0a590c8aabced1b46e1200aeface51e9fe34cdf01ed7753a6779ce55@%3Cdev.plc4x.apache.org%3E


---

Establish the Apache PLC4X 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 set of libraries for communicating with industrial
programmable logic controllers (PLCs) using a variety of protocols but
with a shared API.

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

RESOLVED, that the Apache PLC4X Project be and hereby is responsible for
the creation and maintenance of software related to a set of libraries
for communicating with industrial programmable logic controllers (PLCs)
using a variety of protocols but with a shared API; and be it further

RESOLVED, that the office of "Vice President, Apache PLC4X" 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 PLC4X
Project, and to have primary responsibility for management of the
projects within the scope of responsibility of the Apache PLC4X 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 PLC4X Project:

* Christofer Dutzmailto:cd...@apache.org>>
* Julian Feinauermailto:jfeina...@apache.org>>
* Justin Mclean  mailto:jmcl...@apache.org>>
* Markus Sommer  mailto:msom...@apache.org>>
* Sebastian Rühl mailto:sru...@apache.org>>
* Tim Mitsch mailto:tmit...@apache.org>>

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Christofer Dutz be
appointed to the office of Vice President, Apache PLC4X, 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 PLC4X 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 PLC4X Project; and be it
further

RESOLVED, that the Apache PLC4X Project be and hereby is tasked with the
migration and rationalization of the Apache Incubator PLC4X podling; and
be it further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
PLC4X podling encumbered upon the Apache Incubator PMC are hereafter
discharged.

Vote started on graduation of Apache PLC4X (incubating) pooling to TLP on d...@plc4x.apache.org

[Christofer Dutz]

Hi all,

I just wanted to inform you all, that on our dev-list we have just started a 
VOTE thread for proposing Apache PLC4X (incubating) for graduation to TLP.

Here’s a link to the vote thread:
https://lists.apache.org/thread.html/9a4cf5b1ad7b59e79ae33f3d09032e7942a7191a319335303e16d286@%3Cdev.plc4x.apache.org%3E

Thanks,
Chris

Re: [VOTE] Release Apache PLC4X (Incubating) 0.3.1 [RC1]

[Christofer Dutz]

Hi all,

carrying over my vote from the plc4x dev list.

+1

Chris




Am 08.03.19, 13:02 schrieb "Julian Feinauer" :

Hello all,

This is a call for vote to release Apache PLC4X (Incubating) version 0.3.1.

The Apache PLC4X community has voted on and approved a proposal to release
Apache PLC4X (Incubating) version 0.3.1.

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

Apache PLC4X (incubating) is a set of libraries for communicating with
industrial programmable logic controllers (PLCs) using a variety of
protocols but with a shared API.

PLC4X community vote and result thread:
Result: 
https://lists.apache.org/thread.html/44904efe6d2ded6442605e627d501dba097e79622308d91eb00799e7@%3Cdev.plc4x.apache.org%3E
Vote: 
https://lists.apache.org/thread.html/7e9c475d07c0e12f813226aa123f54969ebb21a2277b32e9bd366d96@%3Cdev.plc4x.apache.org%3E

The release candidates (RC1):
https://dist.apache.org/repos/dist/dev/incubator/plc4x/0.3.1-incubating/

Git tag for the release (RC1):
https://github.com/apache/incubator-plc4x/releases/tag/release%2F0.3.1

Hash for the release tag:
7852b6d78a2b4c36ecf0f7c902816131e339adff

Release Notes:

https://github.com/apache/incubator-plc4x/blob/7852b6d78a2b4c36ecf0f7c902816131e339adff/RELEASE_NOTES


The artifacts have been signed with Key : C336E0143A553B89, which can be
found in the keys file:
https://dist.apache.org/repos/dist/dev/incubator/plc4x/KEYS

Look at here for how to verify this release candidate:

https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

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

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

Julian
Apache PLC4X




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

Differences in voting rules between Apache Maturity Model and Incubator Default Project Guidelines

[Christofer Dutz]

Hi all,

we’re currently working on some pre-graduation work and stumbled over something:
In the Apache Maturity Model [1] is says that:

CS40 - In Apache projects, vetoes are only valid for code commits and are 
justified by a technical explanation, as per the Apache voting rules defined in 
CS30.


However the Incubator Default Project Guidelines [2] suggest code changes are 
“lazy consensus” and stuff like Comitter, PMC, Chai changes are “Consensus 
approval” which is described as:

Consensus approval requires 3 
binding +1 votes 
and no -1 votes (vetoes).

So these two seem to be contradicting each other.

Not quite sure which rules should be applied.

Chris


[1] https://community.apache.org/apache-way/apache-project-maturity-model.html
[2] https://wiki.apache.org/incubator/DefaultProjectGuidelines

Re: Starting at the incubator and releases

[Christofer Dutz]

Or/and the existing mentors could concentrate more on helping the podling they 
handle to become a TLP and not stay in the incubator for too long.

Even if that sometimes requires becoming more a PITA to the podlings that are 
sort of living in the incubator forever ...

And in the end we should also think about releasing (in the sense of kicking 
them out) podlings that are obviously not actively adopting the Apache way. (Of 
course after a quite large grace-period)

After all we mentors are investing our time and therefore we could also expect 
them to work on their end. 
If they don't, we could then invest the time we are wasting on them on other 
projects that might be more in need of active mentoring.

Chris


Am 28.02.19, 13:55 schrieb "Mark Thomas" :

On 25/02/2019 19:22, Dave Fisher wrote:



> To me the main Incubator problem is most podlings do not have three fully 
engaged mentors.

+1

> 52 or 53 Incubating podlings may be too many.

+1

> The Incubator may be too lenient in (a) allowing podlings in with minimal 
mentors

+1

The tricky part in all of this is that it isn't the podlings fault if 
the mentors don't engage.

We need more engaged mentors per podling. The obvious solutions to that 
are recruit more mentors (where from?) or accept fewer podlings (seems 
unfair to prospective podlings).

I think the IMPC has some tough decisions ahead.

Mark

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

Re: Incubator release votes

[Christofer Dutz]

Hmmm ... this is really odd ...

On the one side we have lengthy discussions about non-mentors from resisting to 
interfere, but on the other hand podlings are begging for such "interference".
Guess there are always two sides of the discussion.

And I have to admit that for a short time I was hesitating, if I should check 
the Daffodil release as doing it would have been exactly what others were 
complaining about.
I decided to do it nevertheless ... 

I could imagine that the heat and discussions recently could definitely make 
others hesitate to do so in the future and the problem of not being able to 
release could increase as a result of this.

Chris



Am 26.02.19, 14:43 schrieb "David P Grove" :




Craig Russell  wrote on 02/25/2019 09:15:56 PM:

>
> To me, the biggest issue with incubating releases has been lack of
> engagement by mentors for release voting. Many examples from history
> have podlings begging for someone, anyone, to review a release that
> has already received review in the podling dev list but has failed
> to attract three +1 votes from Incubator PMC members.
>
> This is really sad, because in most of these cases the mentors have
> not voted. And so it fell to the rest of the IPMC members to pay
> attention enough to take time to vote.
>


Or in the case of the current OpenWhisk podling voting thread [1], our only
mentor has already voted +1, but after a week we still need two more IPMC
votes to be able to proceed.

Please help


--dave

[1]

https://lists.apache.org/thread.html/be62f7d373bef9a6729f62faf672ae39951159a0ed2ecc9e196cfb96@%3Cgeneral.incubator.apache.org%3E