Hello World / CRUNCH Framework

[Julian Feinauer]

Hi all,

I just joined the incubator ML and wanted to present myself and possibly also 
start a discussion about a software project we developed in the past.
But first things first. My name is Julian Feinauer and I come from Germany 
where I run two “start-up” companies where we work a lot on the “industrial 
IoT” topics, data science and processing of “larger amounts of data”. We love 
open source and so we love the ASF. Most notably, I closely follow the Apache 
Calcite project and hopefully find some time soon to contribute a bit more than 
in the last monts. Futhermore, I am engaged in the (incubating) PLC4X project 
as (P)PMC and in the  (incubating) Edgent project where I try to “revive” the 
community as new (P)PMC together with Christopher Dutz.

Now to the real topic. Over the last 3 years I started to develop a 
“Framework/Library” (currently a set of jars) to facilitate processing of 
timeseries data. The focus is mostly on processing of data from test stands, 
e.g., automotive tests, driving profiles and so on. Furthermore, in the recent 
year we added a lot of functionality for processing of “industrial data”. This 
means that we want to make it easy to analyze things like “how long did the 
machine spend in this state”, “when are the following set of bits set” or 
“nofity when the following conditions is true for the first time”.
It is a bit technical and I don’t want to go too deep into it, but generally 
speaking we try to introduce the “right” semantics to answer the typical 
questions when analyzing machine or test data. This project is called “CRUNCH” 
and we are in the process of making it open source (will be moved to a public 
github repo in this year) under the Apache 2.0 License.

As there can be seen a close relationship to other (incubating or TLP) projects 
we are thinking about if this project could fit into the incubator. Some 
examples for Apache projects that we see as “related” are Apache Flink (which 
we can use as the Streaming Engine to process the stream), (incubating) Edgent 
which we also can support as Streaming Engine and where we try to find a 
suitable project goal and community currently as some of the (P)PMC members 
retired or went inactive. Finally, CRUNCH has a very natural fit with PLC4X 
because it can directly process the data gathered form PLCs (and in fact we are 
already using it in some of our projects that way). I had several discussions 
with some of the (P)PMCs of PLC4X, namely Sebastian Rühl and Christpher Dutz wo 
encouraged me to introduce the project to the incubator because they also see 
some potential for the project to enrich the OSS ecosystem with regards to edge 
/ stream processing of (I)IoT data.

So please feel free to ask questions or discuss your view on this topic as I 
would like to find out if this project could fit in the Apache Ecosystem and 
the Incubator or not.

Thank you already!
Julian

Re: Hello World / CRUNCH Framework

[Julian Feinauer]

Hi Chris,

yes, you got it right.
We do not care about "how does this message get from this processing node to 
that".
We "transpile" the higher level input into a DAG which can then run on 
basically every streaming engine (I agree, we do NOT need yet another one), in 
that sense it is a bit like Apache Beam.
Thus, I do not see it as a contender to Edgent but more as a complementary, 
because edgents focus is more the engine and Cloud Communication and CRUNCHs 
focus is more of "what exactly does the pipeline do".

Julian

Am 14.12.18, 11:54 schrieb "Christofer Dutz" :

Hi Julian,

For me it always felt like crunch can't directly be compared to the other 
"streaming engines" as I see it as a bundle of a streaming engine and a higher 
level framework for doing typical industry operations on top of that.

I think the higher level library should actually be able to run on top of 
any of the other streaming engines we have. Does such a split make sense, or 
did I get something wrong? Perhaps it would make sense to evaluate Edgents 
stream processing and eventually merge in improvements. I don't see a need 
multiple edge stream frameworks especially if we have to revive the existing 
one.

I think an engine for higher level functions on top of a streaming engine 
of choice would be a great addition, because adding such logic to only one of 
the existing seems to be a waste.

Chris

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

From: Julian Feinauer 
Sent: Friday, December 14, 2018 11:11:40 AM
To: general@incubator.apache.org
Subject: Hello World / CRUNCH Framework

Hi all,

I just joined the incubator ML and wanted to present myself and possibly 
also start a discussion about a software project we developed in the past.
But first things first. My name is Julian Feinauer and I come from Germany 
where I run two “start-up” companies where we work a lot on the “industrial 
IoT” topics, data science and processing of “larger amounts of data”. We love 
open source and so we love the ASF. Most notably, I closely follow the Apache 
Calcite project and hopefully find some time soon to contribute a bit more than 
in the last monts. Futhermore, I am engaged in the (incubating) PLC4X project 
as (P)PMC and in the  (incubating) Edgent project where I try to “revive” the 
community as new (P)PMC together with Christopher Dutz.

Now to the real topic. Over the last 3 years I started to develop a 
“Framework/Library” (currently a set of jars) to facilitate processing of 
timeseries data. The focus is mostly on processing of data from test stands, 
e.g., automotive tests, driving profiles and so on. Furthermore, in the recent 
year we added a lot of functionality for processing of “industrial data”. This 
means that we want to make it easy to analyze things like “how long did the 
machine spend in this state”, “when are the following set of bits set” or 
“nofity when the following conditions is true for the first time”.
It is a bit technical and I don’t want to go too deep into it, but 
generally speaking we try to introduce the “right” semantics to answer the 
typical questions when analyzing machine or test data. This project is called 
“CRUNCH” and we are in the process of making it open source (will be moved to a 
public github repo in this year) under the Apache 2.0 License.

As there can be seen a close relationship to other (incubating or TLP) 
projects we are thinking about if this project could fit into the incubator. 
Some examples for Apache projects that we see as “related” are Apache Flink 
(which we can use as the Streaming Engine to process the stream), (incubating) 
Edgent which we also can support as Streaming Engine and where we try to find a 
suitable project goal and community currently as some of the (P)PMC members 
retired or went inactive. Finally, CRUNCH has a very natural fit with PLC4X 
because it can directly process the data gathered form PLCs (and in fact we are 
already using it in some of our projects that way). I had several discussions 
with some of the (P)PMCs of PLC4X, namely Sebastian Rühl and Christpher Dutz wo 
encouraged me to introduce the project to the incubator because they also see 
some potential for the project to enrich the OSS ecosystem with regards to edge 
/ stream processing of (I)IoT data.

So please feel free to ask questions or discuss your view on this topic as 
I would like to find out if this project could fit in the Apache Ecosystem and 
the Incubator or not.

Thank you already!
Julian

Re: Hello World / CRUNCH Framework

[Julian Feinauer]

Hi Brian,

thanks for your email.
Regarding your hint, we know about the "real" CRUNCH project and are willing to 
change the projects name if we would enter the incubator (sadly we are 
massively lacking creativity...).
 
Regarding Zipkin, I could imagine that some of the things we are doing fits 
well with use cases but I have to admit that I never went too deep into Zipkin 
because it looks to crazy what you are doing there.
And in fact, this is what we are mostly looking for, 

Regarding IoTDB... I was very excited when I heard of the project (and also 
looked through the Codebase in the "old" github repo) and I really like it. We 
use parquet in some situations but IotDB is definetly better suited for the 
specific workloads we have in mind. Thus, I am really looking forward to the 
project really starting, from a PLC4X, Edgent and CRUNCH dev perspective.

Julian

PS.: Do you have some sample questions or analytics that you have in mind for 
Zipkin, to get a feeling?

Am 14.12.18, 16:30 schrieb "Brian Devins-Suresh" :

Hi Julian,

This seems like a cool project. I'd like to point out one thing with your
name, there is already an Apache Crunch project: https://crunch.apache.org

On a couple collaborative notes, as a (incubating) Zipkin developer I could
see some use for your project in our community. We've had trouble building
reusable analytics components so if your framework would help facilitate
that then we might be able to get community buy-in for adopting.

My other collaboration point is it would be cool if it could be used with
the newly incubating IoTDB once that has all of its source available.

- Brian
    
    On Fri, Dec 14, 2018 at 5:59 AM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi Chris,
>
> yes, you got it right.
> We do not care about "how does this message get from this processing node
> to that".
> We "transpile" the higher level input into a DAG which can then run on
> basically every streaming engine (I agree, we do NOT need yet another 
one),
> in that sense it is a bit like Apache Beam.
> Thus, I do not see it as a contender to Edgent but more as a
> complementary, because edgents focus is more the engine and Cloud
> Communication and CRUNCHs focus is more of "what exactly does the pipeline
> do".
>
> Julian
>
> Am 14.12.18, 11:54 schrieb "Christofer Dutz" :
>
> Hi Julian,
>
> For me it always felt like crunch can't directly be compared to the
> other "streaming engines" as I see it as a bundle of a streaming engine 
and
> a higher level framework for doing typical industry operations on top of
> that.
>
> I think the higher level library should actually be able to run on top
> of any of the other streaming engines we have. Does such a split make
> sense, or did I get something wrong? Perhaps it would make sense to
> evaluate Edgents stream processing and eventually merge in improvements. I
> don't see a need multiple edge stream frameworks especially if we have to
> revive the existing one.
>
> I think an engine for higher level functions on top of a streaming
> engine of choice would be a great addition, because adding such logic to
> only one of the existing seems to be a waste.
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
> 
> From: Julian Feinauer 
> Sent: Friday, December 14, 2018 11:11:40 AM
> To: general@incubator.apache.org
> Subject: Hello World / CRUNCH Framework
    >
> Hi all,
>
> I just joined the incubator ML and wanted to present myself and
> possibly also start a discussion about a software project we developed in
> the past.
> But first things first. My name is Julian Feinauer and I come from
> Germany where I run two “start-up” companies where we work a lot on the
> “industrial IoT” topics, data science and processing of “larger amounts of
> data”. We love open source and so we love the ASF. Most notably, I closely
> follow the Apache Calcite project and hopefully find some time soon to
> contribute a bit more than in the last monts. Futhermore, I am engaged in
> the (incubating) PLC4X project as (P)PMC and in the  (incubating) Edgent
> project where I try to “revive” the community as new (P)PMC together with
> Christopher Dutz.
>
> Now to the real topic. Over the last 3 years I started to develop a
> “Framework/Library” (current

Re: Hello World / CRUNCH Framework

[Julian Feinauer]

Hi Brian,

thanks for your email!
Regarding your hint, we know about the "real" CRUNCH project and are willing to 
change the projects name if we would enter the incubator (sadly we are 
massively lacking creativity...).

Regarding Zipkin, I could imagine that some of the things we are doing fits 
well with use cases but I have to admit that I never went too deep into Zipkin 
because it looks to crazy what you are doing there.
And in fact, this is what we are mostly looking for, combatants and people that 
bring in different perspectives. We already learned so much while discussing it 
with some PLC4X folks.

Regarding IoTDB... I was very excited when I heard of the project (and also 
looked through the Codebase in the "old" github repo) and I really like it. We 
use parquet in some situations but IotDB is definetly better suited for the 
specific workloads we have in mind. Thus, I am really looking forward to the 
project really starting, from a PLC4X, Edgent and CRUNCH dev perspective.

Julian

Am 14.12.18, 16:30 schrieb "Brian Devins-Suresh" :

Hi Julian,

This seems like a cool project. I'd like to point out one thing with your
name, there is already an Apache Crunch project: https://crunch.apache.org

On a couple collaborative notes, as a (incubating) Zipkin developer I could
see some use for your project in our community. We've had trouble building
reusable analytics components so if your framework would help facilitate
that then we might be able to get community buy-in for adopting.

My other collaboration point is it would be cool if it could be used with
the newly incubating IoTDB once that has all of its source available.

- Brian
    
    On Fri, Dec 14, 2018 at 5:59 AM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi Chris,
>
> yes, you got it right.
> We do not care about "how does this message get from this processing node
> to that".
> We "transpile" the higher level input into a DAG which can then run on
> basically every streaming engine (I agree, we do NOT need yet another 
one),
> in that sense it is a bit like Apache Beam.
> Thus, I do not see it as a contender to Edgent but more as a
> complementary, because edgents focus is more the engine and Cloud
> Communication and CRUNCHs focus is more of "what exactly does the pipeline
> do".
>
> Julian
>
> Am 14.12.18, 11:54 schrieb "Christofer Dutz" :
>
> Hi Julian,
>
> For me it always felt like crunch can't directly be compared to the
> other "streaming engines" as I see it as a bundle of a streaming engine 
and
> a higher level framework for doing typical industry operations on top of
> that.
>
> I think the higher level library should actually be able to run on top
> of any of the other streaming engines we have. Does such a split make
> sense, or did I get something wrong? Perhaps it would make sense to
> evaluate Edgents stream processing and eventually merge in improvements. I
> don't see a need multiple edge stream frameworks especially if we have to
> revive the existing one.
>
> I think an engine for higher level functions on top of a streaming
> engine of choice would be a great addition, because adding such logic to
> only one of the existing seems to be a waste.
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
> 
> From: Julian Feinauer 
> Sent: Friday, December 14, 2018 11:11:40 AM
> To: general@incubator.apache.org
> Subject: Hello World / CRUNCH Framework
    >
> Hi all,
>
> I just joined the incubator ML and wanted to present myself and
> possibly also start a discussion about a software project we developed in
> the past.
> But first things first. My name is Julian Feinauer and I come from
> Germany where I run two “start-up” companies where we work a lot on the
> “industrial IoT” topics, data science and processing of “larger amounts of
> data”. We love open source and so we love the ASF. Most notably, I closely
> follow the Apache Calcite project and hopefully find some time soon to
> contribute a bit more than in the last monts. Futhermore, I am engaged in
> the (incubating) PLC4X project as (P)PMC and in the  (incubating) Edgent
> project where I try to “revive” the community as new (P)PMC together with
> Christopher Dutz.
>
> Now to the real topic. Over the last 3 years I started to develop a
> “F

Re: Hello World / CRUNCH Framework

[Julian Feinauer]

Hi Julian,

thanks for your answer and your insights.
I agree with you on many points (especially our last discussion on the Calcite 
ML made me think a lot).
So I agree with your "layered" approach, and in fact this is what we currently 
do (without stating it explicit enough, I think).

Basically, we do two thinks, I guess.. first, we provide a (Java-)DSL to make 
it easy to write specific operations (and do some very limited optimization, 
not at all comparable to what Calcite does).
Second, we also provide some functions which are useful or necessary for signal 
processing (smoothing, filtering, ...) and we plan to extend them soon with 
things like short or long term predictions, anomaly detection, ... .
By providing suitable wrappers for all that stuff we are able to translate this 
to "real" streaming engines (currently Flink and Akka Streams) and run it there.

And indeed MATCH_RECOGNIZE could be a good implementation for many situations 
(definitely not all) and I hope that I can contribute soon to your recent work 
(I will continue the discussion on the Calcite list). But overall I'm really 
unsure if our problem can be seen as a problem of relational algebra. I know 
and like the overall framework very much (it's one of the most elegant 
applications of math I've seen so far I would even say). But it feels like it 
doesn’t fit that well. As soon as you have a problem where relations are 
related, even for simple things like LAG or LEAD as window functions it gets 
pretty complicated and unnatural with regards to the definition of the algebra. 
But, as I'm lacking a lot of expertise there I would love to discuss the matter 
further with you (but again, I think we should do it on the calcite list).

The following small ASCII Image depicts my thinking of these "layers", and from 
our perspective MATCH_RECOGNIZE is one way to solve the problem and we can also 
provide "native" blocks to run directly on a streaming engine and there are 
surely pros and cons for both sides:

O CRUNCH Evaluation
|
--
|   |
STREAM   Rel. Expression with MATCH_RECOGNIZE
|   |   
   Streaming Engines|
|
SQL based Engines

So, I'm not exactly sure what approach you would prefer from your mail, but my 
suggestion for the next steps with CRUNCH would be to enrich the DSL, add more 
domain specific functions, find more use-cases and get more users on-board. So 
to say, work on the semantics side of things. But in parallel we should follow 
a path to get a better separation of "business logic" and execution with 
support for multiple frameworks and especially the relational algebra side. 
Perhaps, we can conclude at one point that we can cover everything by Calcite 
(I'm skeptical right now) but I think whats needed for this discussion is a 
valid basis to also show you calcite devs what exactly we are doing in-depth.

Julian


Am 16.12.18, 08:20 schrieb "Julian Hyde" :

Hi Julian,

Regarding whether to do this as a streaming engine (with its own query 
language) or as a framework above a streaming engine, I’d say that’s a false 
choice. If there is relational algebra inside your system, you can provide a 
high-level query language that can be translated to a lower-level query 
language in a streaming engine.

This approach of “layered” databases has worked well for me for several 
projects, and is ever more applicable these days as data is becoming federated.

You and I have discussed SQL’s MATCH_RECOGNIZE clause as a way to build 
complex time-based logic. You have probably noticed that is now in Flink, I am 
working on it in Calcite, and Beam will probably get it at some point. Even if 
MATCH_RECOGNIZE doesn’t solve your problem, let’s follow the same approach - 
convert your problem to a DSL that maps to or extends relational algebra, and 
then figure out how to translate that to SQL in an underlying engine. Calcite 
is a very good platform for building new “data languages”, so let’s carry on 
talking.

Julian


> On Dec 14, 2018, at 2:11 AM, Julian Feinauer 
 wrote:
> 
> Hi all,
> 
> I just joined the incubator ML and wanted to present myself and possibly 
also start a discussion about a software project we developed in the past.
> But first things first. My name is Julian Feinauer and I come from 
Germany where I run two “start-up” companies where we work a lot on the 
“industrial IoT” topics, data science and processing of “larger amounts of 
data”. We love open source and so we love the ASF. Most notably, I closely 
follow the Apache Calcite project and hopefully find some time soon to 
contribute a bit more than in the last monts. Futhermore, I am engaged in the 
(incubating) PLC4X pr

Re: Establishing an ASF project for training

[Julian Feinauer]

Hey Lars,
hi Rich,

I really like the idea!
We, from time to time, also do trainings and workshops with Apache projects and 
it would really help to have a better basis.
And I agree for you that you don’t get payed for *having* slides but for the 
show as well as for the insights you get from a good instructor or a person 
with background knowledge, so I also see no big concerns in sharing.

One thing that came to my mind was to use some kind of "code based" generation 
for the slides, notebooks, brochures like Latex, Markdown, Asciidoc or else...
I would not like to force users to use proprietary tools (PPT) to use the 
material.
And furthermore, this would allow us to have some kind of style files which 
could be personalized for corps and which they could keep for each release.
Another aspect is that it makes the whole versioning way easier as it is code 
and one can see all changes and stuff which is impossible for "binary" formats.
I also think we have enough people here that would be able to easily do an 
automated resources documentation, so that we could always offer "compiled" 
material in pdf in default style or the possibility to do a custom build with 
custom styles.

And I think that the incubator would be a good place to start to see if here, 
as in all ASF projects, a community can be established and continuous effort is 
spend on the project. This would reduce the risk of a "zombie" project which is 
probably only really powered by one organization and lives and dies on their 
will.

Julian

Am 17.12.18, 14:37 schrieb "Rich Bowen" :

It's worth mentioning that there's a conversation going right now over on
the members@ list about creating a "central services" kind of entity. That
discussion is primarily focused on design/graphic kind of stuff, but
training/documentation/presentations are similar in concept, if not in
content, and I'm definitely in favor of such an entity existing.

Your anticipated question "Isn't the ASF all about code, now you want to do
PPT!" is very insightful. The ASF exists to provide services to projects,
and this is an unfilled need that many/most of our projects have. There is
precedent - we have an infrastructure organization, a conferences entity, a
marketing group, legal, brand, and so on, that provide non-code services to
projects. Recognizing contributors for non-code contributions is *critical*
for the survival of our projects, and of the Foundation as a whole, and we
tend to be very poor at it.

So, suffice it to say, a huge +1 to this concept, although I'm not sure
where it should live - whether under ComDev (as you suggest) or as a
top-level entity. I think the latter makes a little more sense. While this
is indeed a function of community development/growth/education, it's also
sufficiently different that it may need to be independent.

What are next steps? I don't *think* this is something that should go
through the Incubator. It's not a Thing Like That. Perhaps a proposal to
the Board to create a top-level thing? I'll put a pointer to this thread
into that other thread (referenced above), and apologies to those of you
who are not ASF Members and cannot see that thread.


On Mon, Dec 17, 2018 at 8:23 AM Lars Francke  wrote:

> Hi,
>
> I'd like to start a discussion around establishing a project (or Central
> Service) at the ASF to host and develop training and related materials for
> ASF (and possibly others, where it makes sense) projects.
>
> I'm a committer and contributor to a few projects and make money doing
> consulting work. Naturally people do contact us for training, and we have
> developed our own slideware etc. but we find it incredibly hard work to
> keep those up-to-date.
>
> We also work with lots of other companies and they all face the same
> challenges. At the same time, we do not believe that a slide-deck is worth
> that much on its own (others disagree, as we used to). We believe the
> instructor is the real selling-point and especially when that person is
> deeply embedded in the projects itself as a committer or PMC.
>
> So, we as a company[0] would like to donate our slide decks and other
> resources we have and establish an ASF wide training project in the hopes
> that we as a community can collaborate on those resources. We are 
currently
> talking to partners to assess whether they are interested in joining us in
> open sourcing their material.
>
> I'm not sure if this is a "Central Services" kind of thing or if it should
> be an Incubator project to begin with. I'm posting this here because I
> think there are good arguments for it being a project (e.g. it appears as 
a
> “project” in all lists that others can contribute to, it follows a 
familiar
> structure etc.). It might be a bit different than o

Write Access to incubator Wiki

[Julian Feinauer]

Hi,

could I get write access to the incubator Wiki to update the Podling reports 
for the next time?
Username is jfeinauer

Thanks!
Julian

Re: Write Access to incubator Wiki

[Julian Feinauer]

Thank you Justin!

Am 03.01.19, 10:54 schrieb "Justin Mclean" :

Hi,

> could I get write access to the incubator Wiki to update the Podling 
reports for the next time?

Done and enjoy!

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

[VOTE] Release Apache PLC4X (Incubating) 0.3.0 [RC2]

[Julian Feinauer]

Hello all,


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


The Apache PLC4X community has voted on and approved a proposal to release

Apache PLC4X (Incubating) version 0.3.0.


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/5ee3372ca4c2fd83952ec0e36e93a8bbcf5a8ecde72f75b324b60a5b@%3Cdev.plc4x.apache.org%3E

Vote: 
https://lists.apache.org/thread.html/eacbccd9b7f540a3bacff2eaf7420751252067977bcfab1679f8fb35@%3Cdev.plc4x.apache.org%3E


The release candidates (RC2):

https://dist.apache.org/repos/dist/dev/incubator/plc4x/0.3.0


Git tag for the release (RC2):

https://github.com/apache/incubator-plc4x/tree/release/0.3.0


Hash for the release tag:

ed21ab16d54601c01f7d97805aa1dd8d87a148e0


Release Notes:

https://github.com/apache/incubator-plc4x/blob/release/0.3.0/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

Re: [VOTE] Release Apache PLC4X (Incubating) 0.3.0 [RC2]

[Julian Feinauer]

Hi Justin,

thanks for your remark.
I had some issues initially but the key got found by cdutz and others.

I'll try to publish the key again to the server.

Julian

Am 03.02.19, 10:26 schrieb "Justin Mclean" :

Hi,

While you key is in the KEY file it looks like you KEY is not published:
gpg: assuming signed data in 
'apache-plc4x-incubating-0.3.0-source-release.zip'
gpg: Signature made Mon 28 Jan 08:57:37 2019 AEDT
gpg:using RSA key ADBD428CB5BF6C9FFC77B907C336E0143A553B89
gpg: requesting key C336E0143A553B89 from hkps server 
hkps.pool.sks-keyservers.net
gpg: Can't check signature: No public key

(not an issue but though I’d mention it)

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

Request for write access for wiki

[Julian Feinauer]

Hi all,

I request write access tot he incubator wiki to submit the Report for Edgent.
My username is “jfeinauer”.

Thanks!
Julian

Re: Request for write access for wiki

[Julian Feinauer]

Indeed, strange, but nonetheless, thank you Justin!

Am 03.02.19, 12:02 schrieb "Justin Mclean" :

Hi,

> I request write access tot he incubator wiki to submit the Report for 
Edgent.
> My username is “jfeinauer”.

Looks like you already have permission.

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

[RESULT][VOTE] Release Apache PLC4X (Incubating) 0.3.0 [RC2]

[Julian Feinauer]

Hello all,

The vote for releasing Apache PLC4X 0.3.0-RC2 (incubating) is closed, now.

Vote result:
3 (+1 binding) (Stefan Bodewig, Justin McLean, Christofer Dutz)
0 ( 0 binding)
0 (-1 binding)

No non-binding votes.

Thank you everyone for taking the time to review the release and help us.

I will process to publish the release and send ANNOUNCE.

Julian
Apache PLC4X

Re: [VOTE] Accept Training into the Apache Incubator

[Julian Feinauer]

+1 (non-binding)
I really liked the idea from the start and probably will find some time to 
contribute!

Julian

Am 13.02.19, 15:18 schrieb "Kevin A. McGrail" :

+1 Binding.  I'll also try again to get  Udacity, Udemy, Coursera,
Pluralsight involved now that this is going to a formal incubator podling.
I am hoping once a domino falls, more will help.

Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Wed, Feb 13, 2019 at 7:00 AM Vinayakumar B 
wrote:

> +1 (binding)
>
> -Vinay
>
>
> On Wed, Feb 13, 2019 at 4:58 PM Hans-Peter Zorn  wrote:
>
> > +1 (non-binding)
> >
> > Looking forward to work on this!
> > Thanks,
> > Hans-Peter
> >
> > > Am 13.02.2019 um 08:57 schrieb Lars Francke :
> > >
> > > Hi everyone,
> > >
> > > we've discussed the proposal for the Training project in [1] and [2].
> The
> > > proposal itself can be found on the wiki[3].
> > >
> > > According to the Incubator rules[4] I'd like to call a vote to accept
> the
> > > new "Training" project as a podling in the Apache Incubator.
> > >
> > > A vote for accepting a new Apache Incubator podling is a majority 
vote.
> > > Everyone is welcome to vote, only Incubator PMC member votes are
> binding.
> > > It would be helpful (but not required) if you could add a comment
> stating
> > > whether your vote is binding or non-binding.
> > >
> > > This vote will run for at least 72 hours (but I expect to keep it open
> > for
> > > longer). Please VOTE as follows:
> > >
> > > [ ] +1 Accept Training into the Apache Incubator
> > > [ ] +0 Abstain
> > > [ ] -1 Do not accept Training into the Apache Incubator because ...
> > >
> > > Thank you for everyone who decided to join in in the past discussions!
> > > Lars
> > >
> > > [1] <
> > >
> >
> 
https://lists.apache.org/thread.html/5c00016b769135cc302bb2ce4e5f6bbfeeda933a07e9c38b5017d651@%3Cgeneral.incubator.apache.org%3E
> > >>
> > >
> > > [2] <
> > >
> >
> 
https://lists.apache.org/thread.html/9cb4d7eef73e0d526e0124944c3d37325aa892675351a1eed0a25de3@%3Cgeneral.incubator.apache.org%3E
> > >>
> > >
> > > [3] 
> > >
> > > [4] <
> > >
> >
> 
https://incubator.apache.org/policy/incubation.html#approval_of_proposal_by_sponsor
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

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

[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

[RESULT][VOTE] Release Apache PLC4X (Incubating) 0.3.1 [RC1]

[Julian Feinauer]

Hello all,

The vote for releasing Apache PLC4X 0.3.1-RC1 (incubating) is closed, now.

Vote result:
5 (+1 binding) (cdutz, gtrasuk, jmclean, bodewig, lresende)
0 (0 binding)
0 (-1 binding)

And no non-binding votes.

Thank you everyone for taking the time to review the release and help us.

I will process to publish the release and send ANNOUNCE.

Julian
Apache PLC4X

Mentors and Voting on Podling Releases

[Julian Feinauer]

Hi all,

I just wanted to bring back a short summary of a discussion we had with Craig 
Russel on a private list regarding the role of podling mentors in the release 
approval process.
And as there are currently many thoughts and discussions going on about these 
topics, I thought it would be good to have the essence of the discussion public.

Basically the point was when mentors should vote. In the IPMC Vote only or 
already in the Podlings Vote.

Currently, the rules state that the approval of a podling release can only be 
given by IPMC Vote, see [1] and [2].
Both these documents do not mention the “mentor” explicitly but only speak of 
the podling and the IPMC.
Also, the role of the mentor does say nothing about releases [3] and describes 
the mentor (as I read it) more as a lawyer of the podling with regards to the 
IPMC (and not vice versa).
On the other hand, with the current dimension of the incubator, there is a huge 
“load” of approvals put on the IPMC.

So I thought if it wouldn’t be possible to discuss and perhaps redefine the 
mentor role a bit with regards to release approval or voting.
My observation is, that often times the IPMC vote consists mostly of votes from 
mentors (or PPMCs who happen to be also IPMC members) and from very few other 
IPMC members.
I also think that this makes sense, as mentors follow the projects closely and 
can have an eye on the specifics of the project and have a strong relation to 
the project which makes them decide to vote for the project.

On the other hand it would be a too big of a change (I guess) to simply skip 
the IPMC Vote and change it to a “Mentor-only” vote (and also Craig raised a 
lot of reasonable concerns and “technical” difficulties about what changes this 
would impose).

But perhaps one could find a sensible compromise to e.g. motivate mentors to 
vote in the PPMC Vote and also state this in the IPMC Vote thread (how many 
mentors / IPMC members already voted).
This would make it easier for the other IPMC members to scan through these 
mails and see if they have the feeling that they should also check the release 
or if they feel confident enough about the podling.
And if 3 IPMC members already voted in the PPMC Vote one could simply close the 
Vote 72h later if no one else went active without big overhead.

As I understood Craig this goes in the same direction as he (and also others) 
think we should go.

Best
Julian

[1] https://incubator.apache.org/policy/incubation.html#releases
[2] https://incubator.apache.org/guides/releasemanagement.html
[3] https://incubator.apache.org/policy/roles_and_responsibilities.html#mentor

Re: Mentors and Voting on Podling Releases

[Julian Feinauer]

Hi Dave,

thanks for your feedback.
I totally agree with what you say and from all the discussions I read, I have 
the impression that there is a good direction where many IPMC members think 
this should be going and the "right" points are addressed.

Regarding the release process: We just had a discussion in a podling to do 
regular releases but agreed that to discuss the topic futher AFTER graduation 
to keep the workload for the IPMC low.
So I fully agree that we should find a way to make the release process smooth 
for both sides, especially the IPMC to allow Podlings to keep their (official) 
releases frequent (which is especially important for young projects) without 
too much work for the IPMC members.

I am mostly involved in incubating projects, thus I have a bit of a different 
perspective and will happily share my impressions in the discussion and also 
help to update docs or so to make things smoother.
So please come back to me whenever you need help on these matters.

Best
Julian

Am 12.03.19, 18:04 schrieb "Dave Fisher" :

Hi Julian -

Thanks for bringing this discussion to general@.

I think that there are two calls to action here:

(1) How can Mentors service the Podlings they have volunteered to help by 
VOTING on releases? For me the issues can be any of:
- The Release was not discussed on the dev@ list until the VOTE is called.
- 72 hours may not be enough time to find the cycles.
- I know the podling is going to call the next step on general@ and if I 
don’t have time then I can defer and VOTE later (or not.)
- I sometimes resent feeling like the only active mentor.
These are my human reasons. I am a volunteer and no one is paying me to do 
this.

(2) Documentation and guidance can be improved.
- The incubator site is mostly in Github at 
https://github.com/apache/incubator/tree/master/pages 
<https://github.com/apache/incubator/tree/master/pages>
- PRs after discussions are welcome.

My current distraction/obsession is INCUBATOR-231 which will improve the 
site. I am looking to make a Podling’s status and issues easier to see and act 
upon.

More inline.

> On Mar 12, 2019, at 2:19 AM, Julian Feinauer 
 wrote:
> 
> Hi all,
> 
> I just wanted to bring back a short summary of a discussion we had with 
Craig Russel on a private list regarding the role of podling mentors in the 
release approval process.
> And as there are currently many thoughts and discussions going on about 
these topics, I thought it would be good to have the essence of the discussion 
public.
> 
> Basically the point was when mentors should vote. In the IPMC Vote only 
or already in the Podlings Vote.
> 
> Currently, the rules state that the approval of a podling release can 
only be given by IPMC Vote, see [1] and [2].
> Both these documents do not mention the “mentor” explicitly but only 
speak of the podling and the IPMC.
> Also, the role of the mentor does say nothing about releases [3] and 
describes the mentor (as I read it) more as a lawyer of the podling with 
regards to the IPMC (and not vice versa).
> On the other hand, with the current dimension of the incubator, there is 
a huge “load” of approvals put on the IPMC.

To me the responsibility of the Mentor is to the Podling to provide 
guidance to the podling community in how to interact with the Apache Software 
Foundation. Mentors should be able to direct the podling to the following 
committees and resources:

- Infrastructure for Resources and Release Distribution Policy
- Legal-Discuss for License interpretation and Release Policy
- Brand/Trademarks for Name Search, Logos, and Website organization. Also, 
large event approval.
- Press for announcements within the rules for podlings.
- ComDev for community information like the maturity model and help with 
events.
- Conference committee.

We should not duplicate documentation, but should point to the Foundation 
docs.

To me the Incubator is about.
- Entry of a project community - proposal
- Bootstrap by Champion and Mentors
- Watching that Podlings are making progress and helping mentors help the 
community.
- Making sure that Release and Release Distribution Policies are followed.

> 
> So I thought if it wouldn’t be possible to discuss and perhaps redefine 
the mentor role a bit with regards to release approval or voting.
> My observation is, that often times the IPMC vote consists mostly of 
votes from mentors (or PPMCs who happen to be also IPMC members) and from very 
few other IPMC members.
> I also think that this makes sense, as mentors follow the projects 
closely and can have an eye on the specifics of the project and have a strong 
relation to the project which makes them decide to vote for the

Re: [VOTE] Accept DataSketches into the Apache Incubator

[Julian Feinauer]

+1 (non-binding)

Am 15.03.19, 10:50 schrieb "Byung-Gon Chun" :

+1 (binding)

On Fri, Mar 15, 2019 at 6:34 PM Furkan KAMACI 
wrote:

> +1 (binding)
>
> 15 Mar 2019 Cum, saat 07:08 tarihinde Kevin A. McGrail <
> kmcgr...@apache.org>
> şunu yazdı:
>
> > I'd like to vote -1 since you made me look up the word "stochastic" and
> > that feels like homework but I will vote +1 (binding).  Please don't
> > make me do any math.
> >
> > On 3/14/2019 5:23 PM, Kenneth Knowles wrote:
> > > Hi all,
> > >
> > > We've discussed the proposal for the DataSketches project in [1] and
> [2].
> > > The
> > > proposal itself has been put on the wiki [3].
> > >
> > > Per incubator rules [4] I'd like to call a vote to accept the new
> > > "DataSketches" project as a podling in the Apache Incubator.
> > >
> > > A vote for accepting a new Apache Incubator podling is a majority 
vote.
> > > Everyone is welcome to vote, only Incubator PMC member votes are
> binding.
> > > It would be helpful (but not required) if you could add a comment
> stating
> > > whether your vote is binding or non-binding.
> > >
> > > This vote will run for at least 72 hours (but I expect to keep it open
> > for
> > > longer). Please VOTE as follows:
> > >
> > > [ ] +1 Accept DataSketches into the Apache Incubator
> > > [ ] +0 Abstain
> > > [ ] -1 Do not accept DataSketches into the Apache Incubator because 
...
> > >
> > > Thanks to everyone who contributed to the proposal and discussions.
> > >
> > > Kenn
> > >
> > > [1]
> > >
> >
> 
https://lists.apache.org/thread.html/329354bd6a463dab56c2539972cfa2d6c6da7c75900216d785db4e3b@%3Cgeneral.incubator.apache.org%3E
> > > [2]
> > >
> >
> 
https://lists.apache.org/thread.html/c9873cd4fcdc6367bcf530d8fa1ef09f3035f38e7c435e1a79a93885@%3Cgeneral.incubator.apache.org%3E
> > > [3] https://wiki.apache.org/incubator/DataSketchesProposal
> > > [4] https://incubator.apache.org/guides/proposal.html#the_vote
> > >
> >
> > --
> > Kevin A. McGrail
> > Member, Apache Software Foundation
> > Chair Emeritus Apache SpamAssassin Project
> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>


-- 
Byung-Gon Chun

Re: Request for Mentor

[Julian Feinauer]

Hi Lewis,

although, I cannot fulfill your requirement as a formal mentor (as I'm no IPMC 
member) I will join your list and will try to help you with performing the 
release as I've done several releases as RM in the past.

Julian

Am 28.03.19, 21:02 schrieb "Trevor Grant" :

Looks like an awesome project, I'd be happy to help.

On Thu, Mar 28, 2019 at 1:50 PM lewis john mcgibbney 
wrote:

> Hi general@,
>
> The Apache Science Data Analytics Platform (SDAP) (Incubating) project is
> in need of an active mentor!
>
> What is SDAP?
> http://sdap.apache.org/
> SDAP is a technology software solution currently geared to better enable
> scientists involved in advancing the study of the Earth's physical
> oceanography.
> The platform is an orchestration of several previously funded NASA big
> ocean data solutions using cloud technology, which include:
>
>- data analysis (NEXUS)
>- anomaly detection (OceanXtremes)
>- matchup (DOMS)
>- subsetting
>- discovery (MUDROD)
>- visualization (VQSS)
>
> What state is the podling in?
> SDAP is working towards it's first formal release having encountered some
> issues with the initial release candidate. The Podling requires a mentor
> who can come on board and drive through the generation of Apache-compliant
> release candidates so that the project can continue to grow community
> through usage.
>
> Interested?
> Let us know by responding to this thread ensuring that you CC 
dev@sdap.a.o.
>
> Thank you
> Lewis
>
> --
> http://home.apache.org/~lewismc/
> http://people.apache.org/keys/committer/lewismc
>

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Julian Feinauer]

Hi,

I like Craigs suggestion and I'm aware of the problem with the ASF Policy if we 
would skip the formal IPMC Vote.
On the other hand in PLC4X we had a discussion about a regular release cycle to 
bring new features to the users as fast as possible and decided to skip that 
for now, to keep the burden on the IPMC low (and we usually have 3 IPMC / 
Mentor Votes as we have very active Mentors).
I agree with this decision of the PPMC but I see a problem with that, as the 
IPMC Vote should be something to help podlings (aside from the necessity by 
Policy) but not "negatively" impact them.

Perhaps it helps to see the IPMC Votes more as a "take notice" in case that 
there are already 3 +1 Votes. This means that the vote is open for 72hrs 
formally, but IPMC members do not feel to have to go to action (usually as PMC 
member one "should" participate in votes... although this is practiced 
differently in the IPMC for good reasons) but CAN if they feel like.
This would especially mean that podlings should be encouraged to formulate 
their votes more explicit about whether there are already enough IPMC Votes or 
not.

Julian


Am 01.04.19, 23:51 schrieb "Justin Mclean" :

Hi,

I'd also like to see those mentors / IPMC members vote with more than just 
a +1 and provide a list of what they checked. If they could use something like 
this all the better [1].

I wouldn’t be for removing the second step of letting the IPMC look at it, 
reasonably often serious issues are found in that step. By skilling that we 
risk some podlings going all the way to propose graduation while having 
releases that don’t follow ASF policy. This is a situation I’d like to avoid.

Thanks,
Justin

1. https://wiki.apache.org/incubator/IncubatorReleaseChecklist
-
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] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Julian Feinauer]

I agree with the point from Myrle and Ross, I dislike the idea of parallel 
votes.
Especially in the early stages we had multiple RCs which failed in the PPMC 
Vote process.
I would not like to have them on the general@ list, as that adds a lot of noise.

Julian

Am 02.04.19, 16:41 schrieb "Ross Gardler" :

Myrle makes a good point. As a mentor (is been a long time though) I tried 
to cast my vote after there were at least 3 views from the community. Once I 
saw the ppmc catching issues I was missing, or I was simply ratifying their 
view, it was time to graduate.

The IPMC should have nothing to do with it, other than as a backstop for 
absent mentors.

Interested IPMC members can join the community like everyone else. They are 
not some privileged group that gets special treatment.

Get Outlook for Android


From: Myrle Krantz 
Sent: Tuesday, April 2, 2019 7:31:41 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to 
asking IPMC to vote

On Tue, Apr 2, 2019 at 2:09 PM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Hi,
>
> On Tue, Apr 2, 2019 at 11:30 AM Geertjan Wielenga
>  wrote:
> > ...Maybe the PPMC and IPMC vote could run in parallel...
>
> I think the reason for having two votes is to give an opportunity for
> mentors to catch issues in the first one without bothering the IPMC.
>

The vote on the podling list is more (in my opinion) about giving the
members of the PPMC hands-on practice in catching issues before the safety
net of mentors/IPMC comes into play.  This is one reason why some mentors
sometimes chose to wait a bit before voting on releases.

Best Regards,
Myrle



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

Re: Draft incubator report

[Julian Feinauer]

Hi Justin,

thanks for the report. I agree with all thats listed there, but theres one 
passage which I dont understand or which makes me think... it is:

Having a smaller IPMC was discussed, it was suggested that anyone not
signed up to the private list be removed from the IPMC. This was looked 
into and people who make infrequent contributors are still helpful and make 
useful contributions. What seems less helpful in some cases is involvement
of non-IPMC members on this list.

The last sentence indicates that non-IPMC members should not involve on this 
list? Is this the case?
For me it reads like we as non-IPMC members should calm down on this list. Is 
this so?

Julian

On 2019/04/07 02:11:37, Justin Mclean  wrote: 
> Hi,
> 
> Draft report is up here [1] and it will be submitted on Wednesday  April 10th.
> 
> A lot happened in March so I may of missing something and it may need a 
> little more detail in places, if you think thins is the case please go ahead 
> and make changes. As always any if you have any feedback please provide it. 
> Dave if you want to add more info to the new clutch report, and Bertand if 
> you want to any more info on the cookbook page please go ahead.
> 
> Please note that the report doesn’t include anything mentioned on list in 
> April as that is for the next report.
> 
> Thanks,
> Justin
> 
> 1. https://wiki.apache.org/incubator/April2019
> -
> 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: Draft incubator report

[Julian Feinauer]

Hi,

thanks for your clarification. I can only speak for myself and I try to involve 
in discussions where I think I can be helpful or where I have a strong opinion 
(usually from the podling perspective).
But, of course, I do not want to disturb things or annoy people on these lists, 
so I was a bit confused by the sentence, as it is, indeed, a public list.

If its these "drive-by comments" that arre annoying then I would name that so, 
e.g. "What seems less helpful in some cases is involvement of non-IPMC members 
which drop comments and leave the discussion then."

But, I can also live with your clarification.

Julian

On 2019/04/09 08:31:03, Justin Mclean  wrote: 
> Hi,
> 
> > The last sentence indicates that non-IPMC members should not involve on 
> > this list? Is this the case?
> 
> Well we can’t stop them from being involved, and nor IMO should we,  it is a 
> public list after all. And most of the time they can be useful and helpful, 
> it's just in some cases they are not. it was more a summary of the several 
> “drive-by comments” threads/conversations we had.
> 
> > For me it reads like we as non-IPMC members should calm down on this list. 
> > Is this so?
> 
> Why would you re-word it? Any suggestions?
> 
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 

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

Re: Draft incubator report

[Julian Feinauer]

+1, I like that formulation.

On 2019/04/09 09:26:00, Bertrand Delacretaz  wrote: 
> Hi,
> 
> On Tue, Apr 9, 2019 at 10:43 AM Julian Feinauer  wrote:
> > ...If its these "drive-by comments" that are annoying then I would name 
> > that so, e.g. "What
> > seems less helpful in some cases is involvement of non-IPMC members which 
> > drop
> > comments and leave the discussion then
> 
> I agree that drive-by comments are sometimes a problem here but I
> don't think they necessarily correlate with people being on the IPMC
> or not.
> 
> IMO the problem is people commenting on topics that they are not
> involved in, without checking prior comments or the prior history of a
> given discussion.
> 
> So maybe
> 
> ***
> What seems less helpful in some cases is 'drive-by' comments, where
> people comment without necessarily checking prior facts or history,
> and also sometimes leave discussions hanging. We should all be careful
> in the relatively vast "Incubator space" to inform ourselves about the
> actual context of the things we are commenting on, and we count on
> mentors, who are closer to their podlings, to set things straight when
> such comments are made.
> ***
> 
> -Bertrand
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 

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

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

[Julian Feinauer]

+1 (binding)

I checked
* Signatures and Hashes
* Builds Backend and Frontend
* All Tests pass
* Rats reports no error
* No Snapshot Artifacts
* Disclaimer exists
* Incubating is in artefacts name

Best
Julian

On 2021/07/21 05:19:52, Jean-Baptiste Onofre  wrote: 
> +1 (binding)
> 
> I quickly checked:
> - signatures are ok
> - NOTICE and LICENSE files look good to me
> - DISCLAIMER file is there
> - incubating is in the artifacts name
> 
> Thanks,
> Regards
> JB
> 
> > Le 14 juil. 2021 à 22:00, Dominik Riemer  a écrit :
> > 
> > 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
> > [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
> 
> 

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

AW: [PROPOSAL] MetaObjects for Apache Incubator

[Julian Feinauer]

Hi Carl,

The project sounds interesting and as I understand it the aim is code 
generation from models.
Is this right?

It would be interesting to see the current version of the code base to get a 
better feeling on that.

We use and want to use code generation heavily in the apache plc4x project and 
I would love to have another project where such efforts are driven aside from 
doing it all by ourselves.

Best
Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: [PROPOSAL] MetaObjects for Apache Incubator
Von: Justin Mclean
An: general@incubator.apache.org
Cc:

Hi,

> Currently most development is happening within Cengage.  The core library 
> hasn't changed much, aside from some bug fixes.  Most of the recent 
> innovation has occurred in other libraries built upon the draagon-metaobjects 
> foundations.  That code is part of what is proposed to be donated to the 
> apache-metaobjects project.

Thanks for that, I still a little unclear what code base is being donated. I’m 
just asking as that may make the IP transfers process easier or harder, you 
might have to get ICLA from people who have worked on it in the past for 
instance.

> Regarding the mentor list, I saw the Apache committer list included Heath, 
> but misunderstood that being a committer did not imply ASF membership, which 
> was my mistake.  However, Johan Edstrom and James Carman are members of the 
> IPMC, and Jamie mentioned to me that he has requested IPMC membership as 
> well.  In addition, James has mentored a few projects in the past.  We would 
> welcome another mentor if anyone is interested in helping build a community 
> around the project.

I think it would be best for a project if you had an mentor with some more 
experience. It can be difficult if you mentors go missing or if they may not be 
familiar with recent changes in infrastructure or the incubator.

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

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

[Julian Feinauer]

Hi Justin,

This is such a great progress from the podlings perspective. Thank your work!

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: [MENTORS] IPMC Policy change work in progress disclaimer
Von: Davor Bonaci
An: general@incubator.apache.org
Cc:

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

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

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

Re: [DISCUSS] IPMC votes on releases

[Julian Feinauer]

Hi,

thanks Justin for bringing that up.
I have perhaps a different perspective than many others because I was / am 
mostly active in several podlings and just very recently became IPMC member (no 
apache member).

But, assuming that each podling has three active mentors, each podling should 
have 3 +1 IPMC vote before the RC goes to general@ and then is, as Sebb says 
below basically a "lazy" consensus vote as 3 +1 are present and if no one 
throws in a -1 it will pass regularly and is a regular release.

This brings me to the point. The assumption "three active mentors" is pretty 
strong.
In the podlings I have been active with I observed three categories of Mentors:

- generally present (best!)
- usually not present but active in VOTE threads or report signoff (so-so)
- not active at all

So from my perspective we should really work on the Mentor activity then the 
"voting" problem becomes minor.
I have no opinion of whether ASF Members should be allowed to simply step into 
IPMC or not (Members should be expected to bring everything which is needed for 
a valuable decision making, I guess).
But, I think its to "easy" to become mentor of a project.
So I would rather argue that not each IPMC member should automatically become a 
possible Mentor.
To become Mentor should be based on the experience / track record in "the 
apache way" as already stated by others like Sheng.

Also I think our current practice of just saying "Interesting project, count me 
in as Mentor" is not good as this leads exactly to the situation I described 
above.
So I would suggest to make the Mentor assignment somewhat binding, e.g. by IPMC 
Vote or some other process and to force in the "activity" of mentors.
I have no detailed idea how this should be done but if Mentors regularily do 
not vote on Podling releases and do not signoff podling reports this is a sign 
that perhaps another mentor has to step in.
If we ensure that each podling always has 3 ACTIVE mentors, than most IPMC 
Release Votes become LAZY votes.

This should, from my perspective, be the main goal to focus on.

Julian

Am 10.08.19, 13:55 schrieb "sebb" :

On Sat, 10 Aug 2019 at 12:45, Paul King  wrote:
>
> Another variation/option for those using the WIP disclaimer might be that
> since the WIP disclaimer kind of says this release doesn't have "full
> official" status from an ASF point of view then one way of thinking about
> it is that perhaps full official IPMC endorsement is less of a requirement
> so IPMC voting could be 3 days but lazy. If you don't get more -1 votes
> than +1 votes after 3 days, you can go ahead and publish. Outside WIP
> disclaimer projects, if there are projects which are repeatedly not 
getting
> enough IPMC votes, then IPMC membership by an experienced PPMC member 
could
> be considered as an option, so +1 for your (D) I believe.
>
> I have no problem giving +1 to (E) at all but in reality, it is almost no
> effort for the 3 mentioned IPMC members on the dev list to just +1 the 
IPMC
> vote, so are we picking up the real problem podlings?

If the IPMC members have +1ed the vote on the dev list, won't these
votes count if the vote is continued on the general@ list?
Do they really have to re-affirm their votes?

I agree that the issue seems to be more about podlings with
insufficient/inactive IPMC reviewers.

> On Fri, Aug 9, 2019 at 3:04 PM Justin Mclean 
> wrote:
>
> > Hi,
> >
> > One of the incubator pain points is the double voting on releases first 
by
> > the podling and then by the IPMC.
> >
> > Historically there been a lot of discussion about this and a couple of
> > proposals to try and change it, but none have been accepted. There have
> > been proposals on alternative ways to vote and to ask for guidances 
which
> > have been accepted, but podlings don’t seem to take these options up. 
I’m
> > hoping the recent DISCLAIMER-WIP is one that is used more by podlings, 
and
> > go some way to helping podling get releases out, but time will tell.
> >
> > When consider what to do about this, please keep this in mind:
> > 1. Only PMC members can have binding votes on releases (it’s in our
> > bylaws) so a minimum of 3 IPMC votes are require to make a release.
> > 2. Podlings are not TLP and don’t have a PMC and PPMC members votes are
> > not binding on releases.
> > 3. The IPMC picks up some serious issues in (about 1 in 5) releases by
> > checking this way. This is mostly, but not always, on the early 
releases.
> >
> > So option (A) would be to get the Bylaws changed and treat podlings as
> > TLPs.
> >
> > Another option (B) is to get all mentors to vote on every release. We’ve
> > tried this via various means and it seems only a couple of podlings can
> > manage this.
> >
> > One (perhaps not carefully considered) option

Re: [DISCUSS] IPMC votes on releases

[Julian Feinauer]

Hi,

I'm answering to this (old) thread as the new one branched up with a different 
topic.
Personally, during my time in the first podling I learned a lot by doing Apache 
Releases.
First, as contributor, then as PPMC and finally as RM.
And this is something valuable and if a project wants to become a TLP something 
people have to learn.
And not only one or two but better every PPMC member (and some even able to RM).

So I suggest to encourage Podlings as much as possible to to ASF releases.
I would suggest to solve all the current issues by setting the rules up in a 
way which lets podlings have (at least) 3 +1 IPMC votes in their PPMC Vote 
which are then carried over and make the IPMC Vote basically "lazy consensus".

To do this I would suggest to set up / change the "Mentor Guideline" that a 
Mentor "should" vote on PPMC releases.
Furthermore, in addition to 3 (active?!) Mentors we could add 2-3 "assessors" 
or "observers" (from the IPMC) who do not help actively but are on the list and 
whos dutie is to support Releases.
That would make a pool of 5-6 IPMC members for each podling which should be 
encouraged to VOTE on releases.

Then, we could, step by step, tackle podlings to bring their Vote to the IPMC 
only if they have 3 +1 votes.

This would allow us to keep all global rules of the ASF as is and only change 
Incubator "internals".
I think we should really start to see Mentoring as something which needs time 
and work and which people should only call in if they feel like they can do.
For everything else we could have this "observer" role where people that find 
the project interesting could simply take to watch and monitor it but with 
their Votes also help the incubator a lot.

Julian

Am 12.08.19, 02:46 schrieb "Greg Stein" :

On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean 
wrote:

> Hi,
>
> > I see no problem with using our infrastructure to distribute F/OSS
> > materials. Why would the Foundation want to be against that? If it is
> > labeled properly, then ... roll with it.
>
> It often isn’t labelled properly.  There’s a reasonable risk that some of
> what would be placed there and distributed isn’t actually F/OSS.


And what would be the blowback of something on our server with incorrect
information? Very little. Mostly, we'd just move on. Maybe we delete it.


> I can point you to several example of this. I’m not sure how the incubator
> (or the board) would feel about that risk, so that would be something we
> would be need to consider further. Also


Welp. Then I will pose that question, rather than this endless
pontificating about "risk".


> while Jane and John may be fine with that, a lot of companies that use
> Apache releases may not be.
>

I already acknowledged that. Many people could use software regardless of
its licensing. The license typically only matters in *redistribution*
scenarios. Things like the AGPL affect *usage*, but that is very, very
atypical. I'd think 99% of downstream could use our software, even with
gummed-up licensing.


> > You're conflating *learning* with *releases*. These can be handled
> separately.
>
> How exactly?


You're saying that releases are the control point to learning. I say just
let the releases go.

You want to teach? Then you can use the releases like "that wasn't good.
next time: do A and B". Over time, releases will get fixed. But the IPMC
should not have to manage the releases.

Cheers,
-g



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

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

[Julian Feinauer]

Hi Ted,

but instead of questioning the Bylaws or introducing two classes of artifacts I 
would rather try to improve mentor votes as this is something we can do 
incubator internal.
And its always better to cure the cause then the symptoms : )

Julian

Am 12.08.19, 16:44 schrieb "Ted Dunning" :

On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski  wrote:

> ...
> This does NOT mean that the IPMC should be gatekeepers though... Just as
> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
> ears of the IPMC". The IPMC "vote" should be little more than a formality.
> IMO, if mentors are IPMC members, and there are at least 3 binding votes 
on
> the podling list, and the mentors are acting as IPMC members when they
> vote, then any other additional vote in the IPMC is not required... in
> essence, consider it like extending the vote for a lazy consensus, so to
> speak:
>
>
>"The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> pointers here). We have 3 (or more) binding votes from mentors. We are
> giving the IPMC and additional 72 hours to vote on said release."
>


This is good in theory, but as Justin has pointed out, 90% of podling
releases don't have enough mentor votes to follow this path.

The 10% that do have enough votes can easily follow this process.

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

[Julian Feinauer]

Hi Ted,

dont get me wrong, I'm rather new to the ASF, the incubator and especially the 
IPMC. So my perspective might be different. But, I understand the frustration 
that some may have and I leant that there have been many trials to change 
things which didn’t go the way we wanted.
The "fear" or concerns I have is that loosening some requirements feels a bit 
like resigning which would be a horrible thing as the incubator is one of the 
(if not the) most important projects in the ASF.

And I don’t object that much with having different classes of releases (its not 
elegant but acceptable IMHO) but the thing I'm really concerned about is the 
lack of possibilities to learn for podlings.
If we come at the end to the modus operandi of "Yeah, simply release as is but 
use this disclaimer or that NOTICE and later in the project we will do it 
'right'" that would be pretty bad.
But perhaps I'm too spoiled as I had the luck to be in several podlings with 
Justin and Chris Dutz who both took lots of time and did an excellent job in 
helping me and all other freshmen to really learn what this Apache Release 
policy is about and how to do it right.
And this is something so important that I want every other podling / newcomers 
to the ASF to experience.

I know that this might sound provocative and perhaps some people might disagree 
but perhaps, if we know that we have not enough "mentor-power" we should be 
more careful about picking up new projects in the incubator if we are not sure 
how to bring them to TLP successful?

Julian

Am 12.08.19, 17:34 schrieb "Ted Dunning" :

Julian,

I love the sentiment, but increasing the probability of mentor-only
approval by 10x is going to take a lot of something that we haven't had the
last five times we have tried to do this. The current system is a bit
frustrating, but having what amounts to mentors-at-large like Justin and a
few others is the only way we have right now to solve the problem of
inspecting releases (and helping to improve them).

And regarding two level of artifacts, we already have two kinds of podling
release artifacts. Those are releasable and defective (and thus not
releasable). That can't change since it is inherent in the release ground
rules and the fact that incoming podlings don't know the ground rules. The
only change is to make the defective artifacts provisionally releasable.



On Mon, Aug 12, 2019 at 7:56 AM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi Ted,
>
> but instead of questioning the Bylaws or introducing two classes of
> artifacts I would rather try to improve mentor votes as this is something
> we can do incubator internal.
> And its always better to cure the cause then the symptoms : )
>
> Julian
>
> Am 12.08.19, 16:44 schrieb "Ted Dunning" :
>
> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski  
wrote:
>
> > ...
> > This does NOT mean that the IPMC should be gatekeepers though...
> Just as
> > PMC chairs are the "eyes and ears of the board", mentors are the
> "eyes and
> > ears of the IPMC". The IPMC "vote" should be little more than a
> formality.
> > IMO, if mentors are IPMC members, and there are at least 3 binding
> votes on
> > the podling list, and the mentors are acting as IPMC members when
> they
> > vote, then any other additional vote in the IPMC is not required...
> in
> > essence, consider it like extending the vote for a lazy consensus,
> so to
> > speak:
> >
> >
> >"The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> > pointers here). We have 3 (or more) binding votes from mentors. We
> are
> > giving the IPMC and additional 72 hours to vote on said release."
> >
>
>
> This is good in theory, but as Justin has pointed out, 90% of podling
> releases don't have enough mentor votes to follow this path.
>
> The 10% that do have enough votes can easily follow this process.
>
>
>

[OFFER] Offer to Mentor one or two podlings

[Julian Feinauer]

Hi,

this goes to the IPMC as well as to podlings watching this list.
I just recently became IPMC member and am currently pretty active in the IoTDB 
Project as “informal mentor” (started there before becoming IPMC member) 
together with 3 other pretty active mentors.
As I received a lot of help from mentors and learned a lot about the Apache Way 
since I joined incubating projects, I think its time now to give something 
back. I could join one or two other podlings as Mentor if I am needed.

I gained a reasonable amount of “podling” experience hands-on during the last 2 
years after joining the PLC4X project and moving from release 0.1 to TLP and am 
active in other Podlings.
My main interest is in the IoT, Big Data and analytics area (I’m active in 
PLC4X, Edgent, IoTDB and sometimes in Calcite) and mostly on the JVM. So this 
is the area where I could help most, I guess.

So if someone has an idea where I can help, feel free to contact me!

Julian

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

[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

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

[Julian Feinauer]

Hi,

I fully agree with Julian here. But we should beware not to start a witch hunt 
about 'bad mentors' but develop an environment where one can step back as 
mentor if priorities change or for other reasons are no longer able to mentor. 
Everybody is a volunteer here so we should thank everybody for their effort and 
not be 'mad' if they 'do not enough'.

But on the other hand this should encourage mentors who can for whatever reason 
not support their podlings enough to speak freely or look for others to fill in 
their spots.

JulianF


 Ursprüngliche Nachricht 
Betreff: Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just 
asking
Von: Julian Hyde
An: general@incubator.apache.org
Cc:

I agree with a lot of Dave Fisher's points.

Some mentors will fail. Let's not waste effort trying to 'vet' them
beforehand; it's time-consuming and counter-productive. Let's instead
make it easier to detect when mentors fail (I think the "Have your
mentors been helpful?" question on podling reports helps with that,
but we need to do more), and let's try to increase the supply of
potential good mentors. That way, we'll end up with good mentors, and
we'll bring active new members into the Foundation.

Julian

On Tue, Aug 13, 2019 at 10:40 AM Hao Chen  wrote:
>
> I founded some apache project and graduated to TLP, and also keep
> contributing to some other apache projects but almost in code, wonder to
> know how to volunteer as IPMC to help some incubator projects graduate in
> Apache way.
>
> Hao Chen
>
> On Tue, Aug 13, 2019 at 7:43 AM Dave Fisher  wrote:
>
> >
> >
> > Sent from my iPhone
> >
> > > On Aug 13, 2019, at 2:39 AM, Justin Mclean 
> > wrote:
> > >
> > > HI,
> > >
> > > I think there's a couple of misconceptions in this thread. First off
> > currently you can join the IPMC two ways by being an ASF member and asking
> > to join, the other by being voted in. On average the people being voted in
> > tend to not go missing, review releases and sign off board reports more
> > frequently.
> > >
> > > This has come up on list the list before and some (ex)board members have
> > suggested that the IPMC shouldn’t;t allow people to be added this way.
> > >
> > > The suggestion here isn’t to be exclusionary, in fact we now allow
> > people who have experience in incubator to ask if they can join, as it
> > often hard for the IPMC to recognise merit, but they still need to be voted
> > in. [1] When a project graduates I go though the PMC list and see if there
> > are any likely IPMC candidates and contact them to see if they are
> > interested, you’ll notice that more people have been voted in in recent
> > times. In another thread I’ve gone one step further and suggested that
> > mentors look out for people on their projects list who are release managers
> > and vote on releases and suggest they be voted in as IPMC members. [2]
> > (Option D). I agree the bar should be low.
> > >
> > > I do find it strange that we would allow people from a privileged group
> > to auto join, when they possibly may not have shown merit and/or have not
> > being involved in the incubator or an incubating project before. Obviously
> > this doesn’t apply to all ASF members that ask join the incubator, but I
> > can point to examples where this has given rise to serious issues. We’ve
> > even had the occasional mentor who has never sent an email to their
> > podlings list, never voted on a release and never signed off a board report.
> >
> > This is a different problem. I’ve seen nonmember mentors who were voted in
> > who never really do anything. Let’s face it life intrudes in one way or
> > another. One hopes that such mentors will resign, but they usually fade
> > away.
> >
> > Let’s focus on service to podlings and try to replace mentors who for
> > whatever reason cannot help.
> >
> > Following through with your proposal creates an IPMC that is not fully
> > trusting the Membership. The membership of The ASF is the Foundation. These
> > people have attained merit.
> >
> > >
> > > I don’t mind if their's not consensus on this and letting this stay.
> > There may be better ways to make sure mentors who sign up do their job and
> > make mentors are more engaged. Please post your suggestions to this list
> > for discussion.
> >
> > I reject the use of the verb “make” for this problem. We should “help”
> > mentors and podling communities “be” more engaged. We should “help”
> > podlings and mentors when Incubation is not working.
> >
> > Mentoring is voluntary. So is Membership.
> >
> > We need to have strong Champions who know how to bring willing and able
> > podlings and mentors into the Incubator.
> >
> > Regards,
> > Dave
> >
> > >
> > > Thanks,
> > > Justin
> > >
> > > 1.
> > https://lists.apache.org/thread.html/9ee3860bc9066ba682484542d34976ab21d9b62106f26a96f19d997f@%3Cgeneral.incubator.apache.org%3E
> > > 2.
> > https://lists.apache.org/thread.html/8c6e12bb040856dddb5d9b7b4821739e441455f3c61c6e469eb98f81@%

AW: [VOTE] Recommend 'Apache Druid graduation to Top Level Project' resolution to the board

[Julian Feinauer]

+1 (binding)

Congratulations!

Julian


 Ursprüngliche Nachricht 
Betreff: Re: [VOTE] Recommend 'Apache Druid graduation to Top Level Project' 
resolution to the board
Von: Julian Hyde
An: general@incubator.apache.org
Cc:

+1

Good luck! It has been great mentoring you guys.

On Tue, Aug 13, 2019 at 10:40 AM Andrei Savu  wrote:
>
> +1 (binding)
>
> Congrats! Great to see such an active community.
>
> -- Andrei Savu
>
> On Tue, Aug 13, 2019 at 12:03 AM Gian Merlino  wrote:
>
> > The Apache Druid community has recently discussed our readiness for
> > graduation [1] and voted on it affirmatively [2, 3]. We've also assessed
> > ourselves against the maturity model [4] and collaborated on a resolution
> > for graduation including PMC membership and PMC chair.
> >
> > The community's achievements since entering the Incubator in early 2018
> > include the following:
> >
> > - Accepted 1240 patches from 142 contributors
> > - Performed 5 releases with 4 different release managers
> > - Invited 10 new committers
> > - Some time later on, invited all 10 of those new committers to join the
> > PMC (those that have accepted are named in the resolution below)
> > - Migrated development to Apache's GitHub org:
> > https://github.com/apache/incubator-druid
> > - Migrated our web site to https://druid.apache.org/
> > - Migrated developer conversations to the list at d...@druid.apache.org
> >
> > Now the Druid community is bringing the attached resolution up for a formal
> > IPMC VOTE.
> >
> > Please take a minute to vote on whether or not Apache Druid should graduate
> > to a Top Level Project by responding with one of the following:
> >
> > [ ] +1 Apache Druid should graduate
> > [ ]  0 No opinion
> > [ ] -1 Apache Druid should not graduate because...
> >
> > The VOTE is open for a minimum of 72 hours.
> >
> > [1]
> >
> > https://lists.apache.org/thread.html/68fcc3d2fc66c7f559e2c9dd02478d17f195565fecdb07ed53bc965e@%3Cdev.druid.apache.org%3E
> > [2]
> >
> > https://lists.apache.org/thread.html/10c615a7648db14a268759be91f4b1eff448960f5338e0d416c7373a@%3Cdev.druid.apache.org%3E
> > [3]
> >
> > https://lists.apache.org/thread.html/7517dd38fbeb28978b1188bed1d69e91445927d13d520a4c71ae9fcf@%3Cdev.druid.apache.org%3E
> > [4] https://gist.github.com/gianm/33ae4d61ebaa8b8714d9e2f51a11e7f7
> >
> > --
> >
> > Establish Apache Druid 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 analytical database
> > software, for distribution at no charge to the public.
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > Committee (PMC), to be known as the "The Apache Druid Project",
> > be and hereby is established pursuant to Bylaws of the
> > Foundation; and be it further
> >
> > RESOLVED, that The Apache Druid Project be and hereby is
> > responsible for the creation and maintenance of an analytical
> > database software project; and be it further
> >
> > RESOLVED, that the office of "Vice President, Druid" 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
> > Druid Project, and to have primary responsibility for
> > management of the projects within the scope of responsibility of
> > The Apache Druid 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 Druid Project:
> >
> >   * Benedict Jin (asdf2...@apache.org)
> >   * Charles Allen(cral...@apache.org)
> >   * Clint Wylie  (cwy...@apache.org)
> >   * David Lim(david...@apache.org)
> >   * Dylan Wylie  (dylanwy...@apache.org)
> >   * Eric Tschetter   (ched...@apache.org)
> >   * Fangjin Yang (f...@apache.org)
> >   * Gian Merlino (g...@apache.org)
> >   * Himanshu Gupta   (himans...@apache.org)
> >   * Jihoon Son   (jihoon...@apache.org)
> >   * Jonathan Wei (jon...@apache.org)
> >   * Julian Hyde  (jh...@apache.org)
> >   * Kurt Young   (k...@apache.org)
> >   * Lijin Bin(binli...@apache.org)
> >   * Maxime Beauchemin(maximebeauche...@apache.org)
> >   * Niketh Sabbineni (nik...@apache.org)
> >   * Nishant Bangarwa (nish...@apache.org)
> >   * P. Taylor Goetz  (ptgo...@apache.org)
> >   * Parag Jain   (pja...@apache.org)
> >   * Roman Leventov   (leven...@apache.org)
> >   * Slim Bouguerra   (bs...@apache.org)
> >   * Surekha Saharan  (sure...@apache.org)
> >   * Xavier Léauté(x...@apache.org)
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Gian Merlino
> > be and hereby is appointed to the office of Vice President,
> > Druid, to serve in accordance with and subject to the d

[LAZY][VOTE] Release Apache IoTDB (Incubating) 0.8.0 RC3

[Julian Feinauer]

Hello all,

This is a call for vote to release Apache IoTDB (Incubating) version 0.8.0, 
which is the first Apache Release for the IoTDB Project.

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

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. It provides users with 
services for data collection, storage and analysis.

IoTDB community vote and result thread:
Result: 
https://lists.apache.org/thread.html/19c913987145a2dc0afced626131e084fc3b1ab7e1ca1dde07a5b977@%3Cdev.iotdb.apache.org%3E
Vote: 
https://lists.apache.org/thread.html/d1272646baf81a0d2d62308cfb7a6e4fc754e377a043068409b0b9ed@%3Cdev.iotdb.apache.org%3E

The release candidates (RC3):
https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.8.0/rc3

Git tag for the release (RC3):
https://github.com/apache/incubator-iotdb/releases/tag/release%2F0.8.0

Hash for the release tag:
2f4da03b05d1c063eaaca622c68de86abe35de22

Release Notes:
https://github.com/apache/incubator-iotdb/blob/2f4da03b05d1c063eaaca622c68de86abe35de22/RELEASE_NOTES.md

The artifacts have been signed with Key : C336E0143A553B89, 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.

From the PPMC Vote we cary over 4 binding IPMC Votes:

+1 from Justin McLean,
+1 from Christofer Dutz,
+1 from Kevin A. McGrail,
+1 from Julian Feinauer

Thus, I took the freedom to declare the Vote as Lazy as no futher positive 
votes are necessary and only a -1 Vote could cancel the vote.

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

Julian
Apache IoTDB

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

[Julian Feinauer]

Hi Greg,

I think Justins Answer refers to the WIP-Disclaimer which was recently added to 
the incubator Policy Page:
https://incubator.apache.org/policy/incubation.html#disclaimers

A Podlings releasing with the WIP Disclaimer is no ASF release, so I consider 
Justins response is no misdirection and I would also agree on that.

Julian

PS.: Allow me to add a very personal side note. But it seems to me that the 
tone in this discussion is from time to time rather harsh. I know that many 
people here have a long history in the ASF and with each other but it just 
doesn’t seem right that two very seasoned and well established ASF mentors 
consider that one of them straight lies on purpose on a ML, which makes me a 
bit sad : /

Am 14.08.19, 12:51 schrieb "Greg Stein" :

On Wed, Aug 14, 2019, 00:33 Justin Mclean  wrote:

> Hi,
>
> > Q: Does the IPMC want to produce non-ASF releases?
>
> A: We already are


Not true, as you well know. Whether we call the above a lie, or
misdirection is left to the reader.

The IPMC currently attempts to ensure all podling releases conform to
policy, and then/thus calls them ASF releases.

This thread is to ask about stopping that approach. That we can/should make
a business decision to accept the moot risk of placing podling releases on
our distribution servers.

-g

Re: Showcase your project at ApacheCON at a Podling's Shark Tank

[Julian Feinauer]

IoTDB Podling is Interested!

Julian

Am 15.08.19, 15:04 schrieb "Dmytro Liaskovskyi" 
:

DLab podling is interested

DMYTRO LIASKOVSKYI
Software Engineering Manager
 
Office: +380 322 424 642 x 57729
Cell: +380 97 341 1315Email: 
dmytro_liaskovs...@epam.com
Lviv, Ukraine   epam.com 
 
CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s) or 
entity(ies) to which it is addressed and contains information that is legally 
privileged and confidential. If you are not the intended recipient, or the 
person responsible for delivering the message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. All unintended recipients are obliged to 
delete this message and destroy any printed copies.

On 8/14/19, 23:45, "Roman Shaposhnik"  wrote:

Hi Podlings!

in less than a month we're going to have our first
ApacheCON this year -- the one in Las Vegas. In
about two month there will be one more in Berlin.

These are not your regular ApacheCONs -- these are
20th Anniversary of ASF ApacehCONs! In other words,
these are not to be missed!

And even if your talk didn't get accepted -- you still
get an opportunity to highlight your project to, what's
likely going to be the biggest audience attending.

Here's how: if you (or any community member who's
passionate about your project) are going to be at either
of those ApacheCONs consider signing up for
Podling's Shark Tank
events:
https://www.apachecon.com/acna19/s/#/scheduledEvent/1038
https://aceu19.apachecon.com/session/podlings-shark-tank

Each project presenting will get ~10 min for the pitch and ~5 min
of panel grilling them on all sorts of things. Kind of like this ;-)
 https://www.youtube.com/watch?v=wmenN7NEdBc

You've got nothing to lose (in fact, the opposite: you're likely to get
a prize!) and you will get a chance to receive feedback that might
actually help you grow your community and ultimately graduate to the
TLP status. And! Given our awesome panel of judges:
 * Myrle Krantz
 * Justin Mclean
 * Craig Russel
 * Shane Curcuru
We guarantee this to be a fun and useful event for your community!

We will be tracking signups over here:
 https://wiki.apache.org/apachecon/ACNA19PodlingSharkTank
 https://wiki.apache.org/apachecon/ACEU19PodlingSharkTank
but for now:

SIMPLY REPLY TO THIS EMAIL if you're interested.

It is first come, first serve -- so don't delay -- sign up today!

Thanks,
Roman.

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




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

[RESULT][VOTE] Release Apache IoTDB (Incubating) 0.8.0 RC3

[Julian Feinauer]

Hello all,

the vote to release Apache IoTDB (incubating) 0.8.0 RC3 has passed with 4 +1 
Votes.
Binding Votes:

Justin McLean
Christofer Dutz
Kevin A. McGrail
Julian Feinauer

No further Votes were cast.

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

As this is the first Apache Release of IoTDB a big ‘thank you’ to everybody who 
supported us in doing the release, this is a big milestone for a young podling!

We will proceed with publishing the approved artefacts and send out the 
ANNOUNCE when everythink is ready and synced.

On behalf of the Apache IoTDB Community,
Julian

Re: [VOTE] Release Apache Superset (incubating) 0.34.0 [RC1]

[Julian Feinauer]

Hi,

as it seems like the PPMC vote is already closed I'll repost my vote here...

+1 (binding)

I checked:
- Checked out release
- Verified hashes
- Verified incubating in names
- No binaries in release
- Checked NOTICE and LICENSE.txt, README
- Started superset from sources using ` docker-compose run --rm superset 
./docker-init.sh` -> Works

Some (minor) issues found: 
- No KEYS file found in 'dev' repository only in RELEASE
- The Key used to sign is not very "thrustworhy" (short chain of thrust)
- LICENSE.txt contains infomrations which I think should belong to NOTICE (but 
I'm not 100% sure)
- README is not very human readable. Perhaps one should split it in one for 
humas and one which is sued to generate the Homepage?
- Start / Installation instructions should be directly in the README (IMHO)
- Following warning while building docker Container:
```
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin:
```
- The docker start script asks me for input (admin name, ...). This is not 
listed in the installation instructions
- Another Hint: Generally its good to start a [DISCUSS] Thread parallel to the 
[VOTE] Thread. Then it becomes easier to follow the VOTE thread as it stays 
"cleaner".

Good Job!

Best
Julian

Am 19.08.19, 15:11 schrieb "Jim Jagielski" :

+1 (binding)

> On Aug 19, 2019, at 12:41 AM, Maxime Beauchemin 
 wrote:
> 
> Hi IPMC,
> 
> The Apache Superset community has voted on and approved a proposal to
> release
> Apache Superset (incubating) 0.34.0 (rc1). *This would be the first Apache
> release of Superset.*
> 
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
> 
> Apache Superset (incubating) is a business intelligence web application
> 
> The community voting thread can be found here:
> 
https://lists.apache.org/thread.html/c9ad3ce592a695ceeabfa92969c00c0d7be8e3420b6a221c7e806f40@%3Cdev.superset.apache.org%3E
> 
> The release candidate has been tagged in GitHub as tag 0.34.0rc1
> ,
> available here:
> https://github.com/apache/incubator-superset/releases/tag/0.34.0rc1
> 
> The artifacts to be voted on are located here:
> https://dist.apache.org/repos/dist/dev/incubator/superset/
> 
> Release artifacts are signed with the key located here:
> https://dist.apache.org/repos/dist/release/incubator/superset/KEYS
> 
> This vote will be open for at least 72 hours. The vote will pass if a
> majority of at least three +1 IPMC votes are cast.
> 
> [ ] +1 Release this package as Apache Superset (incubating) 0.15.1
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
> 
> Thank you IPMC! We appreciate your efforts in helping the Apache Superset
> community to validate this release.
> 
> On behalf of the Apache Superset Community,
> 
> Max
> 
> 
> 
> Apache Superset (incubating) is an effort undergoing incubation at The
> Apache
> Software Foundation (ASF), sponsored by the Apache Incubator. Incubation 
is
> required of all newly accepted projects until a further review indicates
> that the infrastructure, communications, and decision making process have
> stabilized in a manner consistent with other successful ASF projects. 
While
> incubation status is not necessarily a reflection of the completeness or
> stability of the code, it does indicate that the project has yet to be
> fully endorsed by the ASF.


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

Re: [OFFER] Offer to Mentor one or two podlings

[Julian Feinauer]

Hi Javi,
hi John,

I will have a look and register to the mailing lists.
I was also pointet to Milagro, so I'll also check that out : )

Julian

Am 20.08.19, 20:11 schrieb "Javi Roman" :

At Apache Myriad we need some help, our more active mentor is really
busy right now.

Myriad => Hadoop YARN (Big Data) and the awesome Mesos, what else! ;-)
--
Javi Roman

Twitter: @javiromanrh
GitHub: github.com/javiroman
Linkedin: es.linkedin.com/in/javiroman
Big Data Blog: dataintensive.info
Apache Id: javiroman

On Tue, Aug 20, 2019 at 5:42 PM John D. Ament  wrote:
>
> Julian,
>
> Apache Tamaya could use help.  My activity has been reduced pretty 
heavily as of late.
>
> John
>
> On 2019/08/13 06:21:54, Julian Feinauer  
wrote:
> > Hi,
> >
> > this goes to the IPMC as well as to podlings watching this list.
> > I just recently became IPMC member and am currently pretty active in 
the IoTDB Project as “informal mentor” (started there before becoming IPMC 
member) together with 3 other pretty active mentors.
> > As I received a lot of help from mentors and learned a lot about the 
Apache Way since I joined incubating projects, I think its time now to give 
something back. I could join one or two other podlings as Mentor if I am needed.
> >
> > I gained a reasonable amount of “podling” experience hands-on during 
the last 2 years after joining the PLC4X project and moving from release 0.1 to 
TLP and am active in other Podlings.
> > My main interest is in the IoT, Big Data and analytics area (I’m active 
in PLC4X, Edgent, IoTDB and sometimes in Calcite) and mostly on the JVM. So 
this is the area where I could help most, I guess.
> >
> > So if someone has an idea where I can help, feel free to contact me!
> >
> > Julian
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: [VOTE] Release Apache Milagro (incubating) Crypto Libraries v1.0.0

[Julian Feinauer]

Hi all,

+1 (binding)

I checked
- Download links are valid
- Checksums and PGP signatures are valid for C 
- Checksums and PGP signatures are valid for JS
-  DISCLAIMER, LICENCE & NOTICE files are included
- Artefacts have incubating in name
- No compiled binaries are included
- C Libraries build correctly and all tests pass (make)on macOS Mojave 10.14.4
- JS Libraries build correctly and all tests pass (npm install and npm test) on 
macOS Mojave 10.14.4

Minor issues found:
- Your KEY File is in an unusual location and has an unusual name. Its more 
convenient (IMHO) to have in in the root folder of the project and named KEYS
- DISCLAIMER is formatted not optimally and hard to read (for C and JS)
- I found no RELEASE NOTES for C and JS

The release overall looks pretty good for me and the documentation is done 
really well!

Julian

Am 21.08.19, 16:10 schrieb "John McCane-Whitney" :

Hi,

This is a call to vote to release the Apache Milagro (incubating) Crypto 
Libraries v1.0.0.

The Apache Milagro (incubating) community has voted to approve this release 
with 5 x +1 votes.  The vote thread can be found here:


https://lists.apache.org/thread.html/7d788b5f3b293bb5545612d9f8af59a005f6407d57d826a1d2a2a563@%3Cdev.milagro.apache.org%3E

(Note that my original [VOTE] email doesn't render for some reason, but its 
contents can be seen further down in the thread)

And a summary of the result:


https://lists.apache.org/thread.html/6b320894a91d5ac298f71b1fab168127de6e75ba4763ab0b1b896a0f@%3Cdev.milagro.apache.org%3E

This release includes both C and JavaScript libraries tagged as v1.0.0 in 
the following repositories:

Crypto C Library:
https://github.com/apache/incubator-milagro-crypto-c/tags

milagro-crypto-c is a modern cryptographic C library that focuses on 
Elliptic Curve Cryptography but has support for legacy systems that require 
RSA. There is support for three different security levels; 128, 192 and 256 
bit. It has been written only in C and has no external dependencies other than 
an entropy source. Measures have been taken in the code base to prevent side 
channel attacks.  Pairing based cryptography (PBC) is a maturing field that has 
recently gained widespread acceptance. The library supports schemes that make 
use of PBC such as BLS for short signatures and MPIN for multi-factor 
authentication (MFA).

Crypto JavaScript Library:
https://github.com/apache/incubator-milagro-crypto-js/tags

milagro-crypto-js is the JavaScript equivalent of milagro-crypto-c. It has 
all the same functionality, API and even the intermediate calculated values in 
the functions are the same. This library allows you to run MFA using MPIN in 
the browser which, to the best of our knowledge, is the only such 
implementation of MFA in this context.

Both libraries have been under active development for many years and the 
APIs haven't changed in several months. There are extensive tests using third 
party test vectors and the tooling required to deploy this software into a 
modern software project. We believe that the code base has reached the point 
that we can perform general availability (GA) releases.

The compressed archives from these release along with a SHA512 checksum, 
PGP signature and PGP key file are being staged here:

https://dist.apache.org/repos/dist/dev/incubator/milagro

Specifically, for the C library:

Source code archive: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/apache-milagro-crypto-c-1.0.0-incubating-src.tar.gz
SHA512 checksum: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/apache-milagro-crypto-c-1.0.0-incubating-src.tar.gz.sha512
PGP Signature: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/apache-milagro-crypto-c-1.0.0-incubating-src.tar.gz.asc
Keys: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/team.keys

And for the JavaScript library:

Source code archive: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/apache-milagro-crypto-js-1.0.0-incubating-src.tar.gz
SHA512 checksum: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/apache-milagro-crypto-js-1.0.0-incubating-src.tar.gz.sha512
PGP Signature: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/apache-milagro-crypto-js-1.0.0-incubating-src.tar.gz.asc
Keys: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/team.keys

Please note that the project's website (https://milagro.apache.org) has 
been updated to include the standard Apache incubator disclaimer

Re: [VOTE] Release Apache Superset (incubating) 0.34.0 [RC1]

[Julian Feinauer]

Hi,

I agree with Alan that its really minor but as the signatures will change I 
would prefer another Vote to have this checked.
If you (as Justin suggests) state your changes clearly in the thread I think 
everybody will easily carry over the vote from the previous thread so its just 
about waiting 72hrs but ensure that everything is alright.

Julian

Am 22.08.19, 19:21 schrieb "Alan Gates" :

I would call a revote over that, it's not like you're changing anything of
import.  I'd just regen the package with the change, create the new hash,
and let everyone know.  I don't see any reason to drag back through the
voting process on two lists over this.

Alan.

On Wed, Aug 21, 2019 at 10:43 PM Justin Mclean 
wrote:

> Hi,
>
> > Oh here's something. Somewhere inside the source release I have a 
version
> > string that says "0.34.0rc1" and that now I'm realizing should really 
say
> > "0.34.0" as it becomes an official release. Now changing that string 
will
> > make for a different SHA.
>
> That's a bit awkward. It would be best to call a vote again if it needs to
> be changed, given the changes shod be minor it shod be easy to review.
>
> Other IPMC members might have another view. Anyone?
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Myriad 0.4.0 (incubating) [rc1]

[Julian Feinauer]

Hi,

+1 (binding)

I checked:
- incubating in name
- signatures and hashes match
- checked DISCLAIMER, LICENSE and NOTICE
- No unexpected binary
- Can compile from source on macOS Mojave

Julian

Am 21.08.19, 05:15 schrieb "Justin Mclean" :

Hi,

+1 (binding)

I checked:
- incubating in name
- signatures and hashes fine
- DISCLAIMER exists
- LICENSE and NOTICE fine (but see below)
- All source files have ASF header
- No unexpected binary files
- Can compile from source

I think you may have the wrong license in LICENSE for bootstrap as the css 
file [1] refers to the Apache licensed version copyright twitter not the MIT 
licensed version?

Thanks,
Justin

1.  ./myriad-scheduler/src/main/resources/webapp/css/bootstrap-myriad.css


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

Re: [VOTE] Accept DolphinScheduler(was EasyScheduler) into Apache Incubator

[Julian Feinauer]

Hi,

Your proposal looks good and the initiual PPMC already looks 'diverse'.
Furthermore, it seems like you have a good mentoring team on board.

One 'minor' concern is that I think it is best to use Apaches Infra for CI and 
Issue tracking.
Which I would greatly prefer over using Github issues.

But overall, a clear +1 (binding) from my side.

Julian

Am 23.08.19, 11:14 schrieb "Kevin Ratnasekera" :

+1

On Fri, Aug 23, 2019 at 7:09 AM Sheng Wu  wrote:

> Hi all,
>
> After the discussion of DolphinScheduler(was EasyScheduler) proposal
> (discussion thread:
>
> 
https://lists.apache.org/thread.html/d3ac53bddf91391e54f63d042a0b3d60f2aecfbb99780bcc00b4db6e@%3Cgeneral.incubator.apache.org%3E
> ),
> I would like to call a VOTE to accept it into the Apache Incubator.
>
> Please cast your vote:
>
>   [ ] +1, bring DolphinScheduler into Incubator
>   [ ] +0, I don't care either way
>   [ ] -1, do not bring DolphinScheduler into Incubator, because...
>
> The vote will open at least for 72 hours and only votes from the Incubator
> PMC are binding.
>
> ==
> Abstract
>
> DolphinScheduler is a distributed ETL scheduling engine with powerful DAG
> visualization interface. DolphinScheduler focuses on solving the problem 
of
> 'complex task dependencies & triggers' in data processing. Just like its
> name, we dedicated to making the scheduling system out of the box.
>
> *Current project name of DolphinScheduler is EasyScheduler, will change it
> after it is accepted by Incubator.*
> Proposal
>
> DolphinScheduler provides many easy-to-use features to accelerate
> the engineering efficiency on data ETL workflow job. We propose a new
> concept of 'instance of process' and 'instance of task' to let developers
> to tuning their jobs on the running state of workflow instead of changing
> the task's template. Its main objectives are as follows:
>
>- Define the complex tasks' dependencies & triggers in a DAG graph by
>dragging and dropping.
>- Support cluster HA.
>- Support multi-tenant and parallel or serial backfilling data.
>- Support automatical failure job retry and recovery.
>- Support many data task types and process priority, task priority and
>relative task timeout alarm.
>
> For now, DolphinScheduler has a fairly huge community in China. It is also
> widely adopted by many companies and organizations
>  as its ETL
> scheduling
> tool.
>
> We believe that bringing DolphinScheduler into ASF could advance
> development of a much more stronger and more diverse open source 
community.
>
> Analysys submits this proposal to donate DolphinScheduler's source codes
> and all related documentations to Apache Software Foundation. The codes 
are
> already under Apache License Version 2.0.
>
>- Code base: https://www.github.com/analysys/easyscheduler
>- English Documentations: https://analysys.github.io/easyscheduler_docs
>- Chinese Documentations:
>https://analysys.github.io/easyscheduler_docs_cn
>
> Background
>
> We want to find a data processing tool with the following features:
>
>- Easy to use，developers can build a ETL process with a very simple 
drag
>and drop operation. not only for ETL developers，people who can't write
> code
>also can use this tool for ETL operation such as system adminitrator.
>- Solving the problem of "complex task dependencies" , and it can
>monitor the ETL running status.
>- Support multi-tenant.
>- Support many task types: Shell, MR, Spark, SQL (mysql, postgresql,
>hive, sparksql), Python, Sub_Process, Procedure, etc.
>- Support HA and linear scalability.
>
> For the above reasons, we realized that no existing product met our
> requirements, so we decided to develop this tool ourselves. We designed
> DolphinScheduler at the end of 2017. The first internal use version was
> completed in May 2018. We then iterated several internal versions and the
> system gradually became stabilized.
>
> Then we open the source code of DolphinScheduler on March 2019. It soon
> gained lot's of ETL developers interest and stars on github.
> Rationale
>
> Many organizations (>30) (refer to Who is using DolphinScheduler
>  ) already benefit
> from running DolphinScheduler to make data process pipelines more easier.
> More than 100 feature ideas
>  come from
> DolphinScheduler community. Some 3rd-party projects also plan to integrate
> with DolphinScheduler through task plugin, such as Scriptis
   

Re: [ANNOUNCE] Release Apache Superset (incubating) version 0.34.0

[Julian Feinauer]

Congratulations! : )

Am 28.08.19, 10:15 schrieb "Justin Mclean" :

Hi,

It’s great to see superset finally get an offical release out.

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

When is tamaya supposed to report next time?

[Julian Feinauer]

Hi,

as I’m pretty new in the tamaya project… when is tamaya scheduled for the next 
incubator report?
From the records it seems like they missed the last time but I don’t see them 
on the current wiki page?

Thanks!
Julian

Re: Incubator podling reports due today

[Julian Feinauer]

Hi Justin,

I know that Tamaya is late (we discussed that already today off-list) and I 
sent multiple mails to the list the last 2 days but got no response yet.
They are currently in the process of doing a release we had some issues in 
first rc but things should be fixed soon, so I really hope that there will be a 
response soon.

Julian

Am 06.09.19, 09:54 schrieb "Justin Mclean" :

Hi,

Still missing sand now past due:
Amaterasu
Hivemall
Marvin-AI
Superset
Tamaya
Tephra

However several reports also don’t IMO have enough detail and I’m 
considering rejected them and asking them to report again next month, they 
include:
Iceberg
Myriad
Omid
ShardingSphere

Also Warble but given it's circumstances we make an exception there I 
think. I’ve asked teh above podling to provide more details.

What do other IPMC members per think?

A few other like Singa I’d like to see more details and less meaningless 
stats.

I’m also concerned that Iceberg thinks it's nearing graduation in the state 
it’s in. What do the mentors think?

Tavera's report is a little confusing are you trying to graduate or retire? 

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




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

Re: [VOTE] Release Apache Milagro (incubating) Decentralized Trust Authority v0.1.0 (alpha release)

[Julian Feinauer]

Hi,

let me initially say, that the release locks pretty good and well prepared. 
But, unfortunately I found two issues I would consider major, thus I vote

-1 (binding)

Remember, this is no VETO so this does not necessarily stop the release. But 
from my experience its easier to fix things while you still are in release mode 
than after one. The two major issues I see are the Headers and the failing 
build of dta.

I checked:
- Keys present in KEYS file
- Signatures and Hash match for all 3 artifacts
- DISCLAIMER is present, see findings below
- LICENSE and NOTICE
- Building of sources 
- works for crypto C (`make`)
- works for crypt js (`npm install`) but `npm test` fails, see below
- fails for dta, see below

(Minor) Findings:
- Why is the DISCLAIMER different(ly formatted) for dta than for crypto c/js ?

(Less Minor) Findings:
- Several Files do not have apache headers.  But at least "code" files like 
Dockerfile's and bash scripts should for sure have some (also CMake).

In dta these are, e.g.
/.dockerignore
  25   ./.gitignore
  26   ./.travis.yml
  27   ./Dockerfile
  28   ./Dockerfile-alpine
  29   ./build-static.sh
  30   ./build.sh
  31   ./go.mod
  32   ./go.sum
  33   ./lint.sh
  34   ./report
  35   ./test.sh
  36   ./cmd/servicetester/e2e_test.sh
  37   ./cmd/servicetester/fulltest.sh
  38   ./cmd/servicetester/id_test.sh
  39   ./libs/crypto/libpqnist/CMakeLists.txt
  40   ./libs/crypto/libpqnist/CPackConfig.cmake
  41   ./libs/crypto/libpqnist/VERSION
  42   ./libs/crypto/libpqnist/cmake_uninstall.cmake.in
  43   ./libs/crypto/libpqnist/examples/CMakeLists.txt
  44   ./libs/crypto/libpqnist/include/CMakeLists.txt
  45   ./libs/crypto/libpqnist/src/CMakeLists.txt
  46   ./libs/crypto/libpqnist/test/smoke/CMakeLists.txt
  47   ./libs/crypto/libpqnist/testVectors/aes/CBCMMT256.rsp
  48   ./libs/documents/docs.pb.go
  49   ./libs/documents/docs.proto
  50   ./libs/documents/docs.validator.pb.go
  51   ./pkg/safeguardsecret/README.md
  52   ./pkg/safeguardsecret/open-api.yaml

- When trying to build dta on MacOs via Docker I Get

Digest: sha256:b88f8848e9a1a4e4558ba7cfc4acc5879e1d0e7ac06401409062ad2627e6fb58
Status: Downloaded newer image for ubuntu:latest
 ---> 2ca708c1c9cc
Step 2/29 : RUN apt-get update &&  apt-get install -y --no-install-recommends   
  ca-certificates cmake g++ gcc git make libtool 
automake libssl-dev
 ---> Running in f8a17dc7ab42
Err:1 http://archive.ubuntu.com/ubuntu bionic InRelease
  403  Forbidden [IP: 91.189.88.31 80]
Err:2 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
  403  Forbidden [IP: 91.189.88.31 80]
Err:3 http://security.ubuntu.com/ubuntu bionic-security InRelease
  403  Forbidden [IP: 91.189.88.31 80]
Err:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
  403  Forbidden [IP: 91.189.88.31 80]
Reading package lists...
E: The repository 'http://archive.ubuntu.com/ubuntu bionic InRelease' is not 
signed.
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/bionic/InRelease  403 
 Forbidden [IP: 91.189.88.31 80]
E: The repository 'http://archive.ubuntu.com/ubuntu bionic-updates InRelease' 
is not signed.
E: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/bionic-updates/InRelease  403  Forbidden 
[IP: 91.189.88.31 80]
E: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease  403  
Forbidden [IP: 91.189.88.31 80]
E: The repository 'http://security.ubuntu.com/ubuntu bionic-security InRelease' 
is not signed.
E: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/bionic-backports/InRelease  403  
Forbidden [IP: 91.189.88.31 80]
E: The repository 'http://archive.ubuntu.com/ubuntu bionic-backports InRelease' 
is not signed.
The command '/bin/sh -c apt-get update &&  apt-get install -y 
--no-install-recommends ca-certificates cmake g++ gcc git   
  make libtool automake libssl-dev' returned a non-zero code: 100

`npm test` fails for me with the following:
1 failing

  1)
   TEST MPIN BLS461
 test MPin Kangaroo:
 AssertionError: expected 0 to equal 
  at Context. (test/test_MPIN.js:310:31)
  at processImmediate (internal/timers.js:443:21)



npm ERR! Test failed.  See above for more details.

Best and feel free to ask if something is unclear or needs discussion!
Julian

Am 19.09.19, 13:58 schrieb "Dave Fisher" :

Hi -

+1 (binding)

Keys present
DISCLAIMER checked - See (3)
LICENSE and NOTICE checked
Signature and Hash checked
Rat Check run - See (2) below.
Did NOT build, I’m on a macOS - See (1) below.

(1) In subsequent releases please make sure that the instructions are to 
build from the source releases and NOT the GitHub tags as these are not 
immutable. Also the Docker files and build shell scripts refer to GitHub and 
not the source release. I understand that these distinctions may be difficult 
considering CI/CD vs. Release Policy.

Re: [VOTE] Release Apache MXNet (incubating) 1.5.1.rc0

[Julian Feinauer]

Hi Tao,

Gratulations to the passed vote but a minor comment. The vote results should 
have the subject prefixed with [RESULT] [VOTE]...

Best
Julian

From: Tao Lv 
Sent: Saturday, September 28, 2019 12:39:49 PM
To: general@incubator.apache.org 
Subject: Re: [VOTE] Release Apache MXNet (incubating) 1.5.1.rc0

  Hi all,

The vote to release Apache MXNet (incubating) 1.5.1.rc0 has passed with 3
+1 binding votes:

- Michael Wall
- Justin Mclean
- Jason Dai

Vote thread can be found at:
https://lists.apache.org/thread.html/282f7911768dab61ddf8f70adcce34ef0afb285046093b3ff0bafb7e@%3Cgeneral.incubator.apache.org%3E


Thank you to the above IPMC members for taking the time to review
and provide guidance on our release!
We will proceed with publishing the approved artifacts and sending out
the appropriate announcements in the coming days.

On behalf of the Apache MXNet community,
-tao

On Fri, Sep 27, 2019 at 10:37 PM Jason Dai  wrote:

> +1 (binding)
>
>
>
> I checked:
>
> - Signatures and hashes OK
>
> - Incubating in name
>
> - Disclaimer and NOTICE exists
>
> - LICENSE OK
>
>
>
> Thanks,
>
> -Jason
>
> On Thu, Sep 26, 2019 at 11:17 PM Tao Lv  wrote:
>
> > Hi Justin,
> >
> > Thank you for sharing the link. We will follow the WIP disclaimer next
> time
> > or if we have another release candidate.
> >
> > Thanks,
> > -tao
> >
> > On Thu, Sep 26, 2019 at 6:03 AM Justin Mclean 
> > wrote:
> >
> > > HI,
> > >
> > > > I'm trying to add below disclaimer into the release notes.
> > >
> > > That wold help but it not how the WIP disclaimer works - see  [1].
> > >
> > > Thanks,
> > > Justin
> > >
> > > 1. https://incubator.apache.org/policy/incubation.html#disclaimers
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
>

Re: [VOTE] Release Apache Milagro (incubating) Decentralized Trust Authority v0.1.0 (alpha release)

[Julian Feinauer]

Hi all,

I change my vote to 

+1 (binding)

It seems like I had some issues on my machine and on another PC the builds work.
So my "major" concerns are no longer true and I change my vote.
So, from below my checks:
- Keys present in KEYS file
- Signatures and Hash match for all 3 artifacts
- DISCLAIMER is present, see findings below
- LICENSE and NOTICE
- Building of sources 
- works for crypto C (`make`)
- works for crypt js (`npm install` and `npm test`)
- works for dta

The other "minor" findings should be corrected for the next release (see below).
Thanks to John for his support and work helping me with the release.

Best
Julian


Am 19.09.19, 23:01 schrieb "Julian Feinauer" :

Hi,

let me initially say, that the release locks pretty good and well prepared. 
But, unfortunately I found two issues I would consider major, thus I vote

-1 (binding)

Remember, this is no VETO so this does not necessarily stop the release. 
But from my experience its easier to fix things while you still are in release 
mode than after one. The two major issues I see are the Headers and the failing 
build of dta.

I checked:
- Keys present in KEYS file
- Signatures and Hash match for all 3 artifacts
- DISCLAIMER is present, see findings below
- LICENSE and NOTICE
- Building of sources 
- works for crypto C (`make`)
- works for crypt js (`npm install`) but `npm test` fails, see below
- fails for dta, see below

(Minor) Findings:
- Why is the DISCLAIMER different(ly formatted) for dta than for crypto 
c/js ?

(Less Minor) Findings:
- Several Files do not have apache headers.  But at least "code" files like 
Dockerfile's and bash scripts should for sure have some (also CMake).

In dta these are, e.g.
/.dockerignore
  25   ./.gitignore
  26   ./.travis.yml
  27   ./Dockerfile
  28   ./Dockerfile-alpine
  29   ./build-static.sh
  30   ./build.sh
  31   ./go.mod
  32   ./go.sum
  33   ./lint.sh
  34   ./report
  35   ./test.sh
  36   ./cmd/servicetester/e2e_test.sh
  37   ./cmd/servicetester/fulltest.sh
  38   ./cmd/servicetester/id_test.sh
  39   ./libs/crypto/libpqnist/CMakeLists.txt
  40   ./libs/crypto/libpqnist/CPackConfig.cmake
  41   ./libs/crypto/libpqnist/VERSION
  42   ./libs/crypto/libpqnist/cmake_uninstall.cmake.in
  43   ./libs/crypto/libpqnist/examples/CMakeLists.txt
  44   ./libs/crypto/libpqnist/include/CMakeLists.txt
  45   ./libs/crypto/libpqnist/src/CMakeLists.txt
  46   ./libs/crypto/libpqnist/test/smoke/CMakeLists.txt
  47   ./libs/crypto/libpqnist/testVectors/aes/CBCMMT256.rsp
  48   ./libs/documents/docs.pb.go
  49   ./libs/documents/docs.proto
  50   ./libs/documents/docs.validator.pb.go
  51   ./pkg/safeguardsecret/README.md
  52   ./pkg/safeguardsecret/open-api.yaml

- When trying to build dta on MacOs via Docker I Get

Digest: 
sha256:b88f8848e9a1a4e4558ba7cfc4acc5879e1d0e7ac06401409062ad2627e6fb58
Status: Downloaded newer image for ubuntu:latest
 ---> 2ca708c1c9cc
Step 2/29 : RUN apt-get update &&  apt-get install -y 
--no-install-recommends ca-certificates cmake g++ gcc git   
  make libtool automake libssl-dev
 ---> Running in f8a17dc7ab42
Err:1 http://archive.ubuntu.com/ubuntu bionic InRelease
  403  Forbidden [IP: 91.189.88.31 80]
Err:2 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
  403  Forbidden [IP: 91.189.88.31 80]
Err:3 http://security.ubuntu.com/ubuntu bionic-security InRelease
  403  Forbidden [IP: 91.189.88.31 80]
Err:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
  403  Forbidden [IP: 91.189.88.31 80]
Reading package lists...
E: The repository 'http://archive.ubuntu.com/ubuntu bionic InRelease' is 
not signed.
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/bionic/InRelease  
403  Forbidden [IP: 91.189.88.31 80]
E: The repository 'http://archive.ubuntu.com/ubuntu bionic-updates 
InRelease' is not signed.
E: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/bionic-updates/InRelease  403  Forbidden 
[IP: 91.189.88.31 80]
E: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease  403  
Forbidden [IP: 91.189.88.31 80]
E: The repository 'http://security.ubuntu.com/ubuntu bionic-security 
InRelease' is not signed.
E: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/bionic-backports/InRelease  403  
Forbidden [IP: 91.189.88.31 80]
E: The repository 'http://archive.ubuntu.com/ubuntu bionic-backports 
InRelease' is not signed.
The command '/bin/sh -c apt-get update &&  apt-get install -y 
--no-install-re

Donation of subproject for PLC4X

[Julian Feinauer]

Hi all,

my company decided to donate our project CRUNCH [1] that has been developed 
internally to the ASF.
The idea is to integrate it as subproject into the PLC4X Project [2].
The PMC has already performed a VOTE on that task [3,4] and we also filed a 
Software Grant as well as CCLA and ICLAs for all committers of the project.

What are the next steps to take?
We need to find a name and go through namesearch, or?
And also we need to do IP Clearance, or?

I’m happy for all pointers in the right direction : )

Julian


[1] https://github.com/pragmaticminds/crunch
[2] plc4x.apache.org
[3] 
https://lists.apache.org/thread.html/9a8078209e005215232f6c02c2433ce0ef67473fe01414a1ac717c23@%3Cdev.plc4x.apache.org%3E
[4] 
https://lists.apache.org/thread.html/3ef7b144ae60a3bd3bf2f592b6ecb6ed540967a45be252a072d3eead@%3Cdev.plc4x.apache.org%3E

Re: Donation of subproject for PLC4X

[Julian Feinauer]

Thanks Bertrand,

I will start editing the IP Clearance Form then!

Julian

Am 02.10.19, 14:36 schrieb "Bertrand Delacretaz" :

Hi,

On Wed, Oct 2, 2019 at 1:59 PM Julian Feinauer
 wrote:
> my company decided to donate our project CRUNCH [1] that has been 
developed internally to the ASF

> ...We need to find a name and go through namesearch, or?...

No, that's only for Apache PMCs which need to have a suitable name.

IOW if your module is called "Apache PLC4X Foo" you don't need to do a
name search on "Foo".

> And also we need to do IP Clearance, or?

Yes, see https://incubator.apache.org/ip-clearance/

-Bertrand

Re: Donation of subproject for PLC4X

[Julian Feinauer]

Thanks for jumping in Chris, yes.
We never liked the name anyway but never had a better one : )

But currently we are discussing that with the community to hiopefully come up 
with a  better one.

Julian

Am 07.10.19, 11:28 schrieb "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] TubeMQ Proposal

[Julian Feinauer]

Hi David,

thanks for the nice proposal.
I think it was already introduced a bit at the ApacheCon NA so it may already 
be known a bit to some folks.
The proposal reads quite nice and TubeMQ seems to be a really nice project and 
has some impressive capabilities and USPs.

Although, those who know me know that I tend to be concerned a lot. The two 
main concerns I see here are not really related to the project in detail but 
rather to two general questions.

The first one is if we are able to mentor the project well enough (old 
discussion). As the project comes from Tencent I assume that the community is 
mostly Chinese and due to the language barrier (and probably a different 
culture) we have seen that these projects tend to be "more challenging" (this 
does not describe it accurate enough but I hope that readers understand what I 
mean).

Aside from that I have the impressions that Messaging and Pub/Sub is the new 
"JS Frontend" thing and we get new Projects each week. I am not too deep into 
the topic (only used Kafka and MQTT) but especially at the last ACNA I got the 
impression that Pulsar is doing a lot to catch up with Kafka and in our 
industrial environment MQTT is pretty set.
But overall we have many Messaging solutions in the ASF all with different 
aspects and USPs yes but overall also with tons of overlap. Which is bad then 
when it comes to "too much" competition and brain-split.

So maybe for someone deeply involved in the field my concerns sound 
unreasonable but this is the impression I have. And I don’t know if we already 
had such a situation but as the foundation is kind of the "bracket" which keeps 
all projects and PMCs together we should also keep this in mind a bit.

I am interested to hear what others think.

Julian

Am 21.10.19, 11:54 schrieb "David Nalley" :

Greetings folks:

Please consider the following proposal, which is also on the wiki[1].
I look forward to hearing feedback.

TubeMQ

=Abstract=

TubeMQ is a distributed messaging queue (MQ) system developed by
Tencent Big Data since 2013. It focuses on high-performance storage
and transmission of massive data in big data scenarios.After nearly
seven years of massive data precipitation, TubeMQ has certain
advantages in production practice (stability + performance) and low
cost compared to many open source MQ projects.

=Proposal=

TubeMQ is suitable for high concurrency, massive data and tolerates a
small amount of data loss scenarios under abnormal conditions, such as
massive log collection, indicator statistics and monitoring, etc.
TubeMQ does not support highly reliable data transmission services
yet. It could be on a future project roadmap, as many other MQs. but
not today.

=Rationale=

Just like other message queue systems, TubeMQ is built on the
publish-subscribe pattern, aka pub-sub.
In this pattern, producers publish messages to topics while consumers
subscribe to those topics. After incoming messages get proceeded,
consumers send an acknowledgement back to producer. Once a
subscription has been created, all messages will be tracked and
retained by TubeMQ, even if the consumer go offline for some reasons.
Retained messages will be discarded only when a consumer acknowledges
that they've been successfully processed.

Portal is responsible for interact with user and admin system which
include two parts: API and web portal.

Master is controller of the cluster, which include one or multiple
master node(s) which is responsible for managing state of cluster,
resource scheduling, authentication check and maintaining of metadata.
As a reliable system, TubeMQ provides HA solution for master node.

Broker is responsible for data store which include a cluster of broker
nodes. Every broker node is managing a set of topics, include: append,
delete, update, query of topic information. In TubeMQ, these brokers
can be horizontal scaled and can be very large size for massive data
case.

Client is responsible for producing and consuming messages. When a
pub-sub topic get setup, we can support two ways (push and pull) for
delivering message from producers to consumers.

Zookeeper is for storing offset of messages which is used to recover
topic during some components get failed.


=Initial Goals=

The initial goal will be to move the current codebase in github’s
repository under Tencent account to Apache and integrate with the
Apache development process and infrastructure.
A primary goal of incubation will be to grow and diversify the TubeMQ
community. We are well aware that the project community is largely
comprised of individuals from a single company. We aim to change that
during incubation.

=Current Status=

As previously mentioned, TubeMQ is u

Leaving the incubator

[Julian Feinauer]

Hi all,

as already discussed before the Podling Edgent is “too dead” to be revived.
The PPMC has thus voted to leave the incubator [1,2] and we will move the 
project to GitHub, perhaps some interest will stay.

What are the next (formal) steps. Do we hold a Vote for the IPMC?

Thanks!
Julian

[1] 
https://lists.apache.org/thread.html/034c26b8c54a1467e2e2f5903c8b984b7037364e27aa36cd2c34794b@%3Cdev.edgent.apache.org%3E
[2] 
https://lists.apache.org/thread.html/c1e4834fbee2634ed3dac8626739c00357ed427f261e3c4f678637c8@%3Cdev.edgent.apache.org%3E

Re: Write Access to Incubator Wiki

[Julian Feinauer]

ode-Red, the wrapper architecture and the underlying
> semantics-based model), we believe the target audience differs. We aim to
> collaborate with the Apache Nifi community in terms of exchanging best
> practices and also integrating both projects (e.g., by building 
connectors).
>
> As mentioned above, quite a few adapters and data sinks are already
> available that link to existing Apache projects.
>
>
>
> ** An excessive fascination with the Apache Brand ** Although we recognize
> the Apache brand as the most visible brand in the open source domain, the
> primary goal of this proposal is not to create publicity, but to widen the
> developer base. We believe that successful projects have broad and diverse
> communities. We expect that an Apache project, with a clear and proven way
> to develop open source software, helps in finding new committers. As the
> core development team has already worked on StreamPipes for the past few
> years and is fully committed to the software and its benefit 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

Re: [DISCUSS] StreamPipes proposal

[Julian Feinauer]

(e.g., by building connectors).
> > As mentioned above, quite a few adapters and data sinks are already 
available that link to existing Apache projects.
> > 
> > ** An excessive fascination with the Apache Brand ** Although we 
> > recognize the Apache brand as the most visible brand in the open 
source domain, the primary goal of this proposal is not to create publicity, 
but to widen the developer base. We believe that successful projects have broad 
and diverse communities. We expect that an Apache project, with a clear and 
proven way to develop open source software, helps in finding new committers. As 
the core development team has already worked on StreamPipes for the past few 
years and is fully committed to the software and its benefit 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
> > * 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 commi

Re: [VOTE] Release of Apache Tamaya 0.4-incubating

[Julian Feinauer]

Hi everybody,

we would be really happy and grateful if we find two more people to vote on the 
tamaya release. 
@Justin Mclean as you already assisted in one RC (by the mandatory -1 Vote) you 
probably find some time to jump in again (a +1 would be welcome this time :P ).

Thanks!
Julian

Am 23.10.19, 09:09 schrieb "Anatole Tresch" :

Hi,

The Tamaya team was running the needed tasks to get the 0.4-incubating
release of Tamaya out.
The artifacts available via the Apache distribution repository [1] and
also via Apache's Nexus [2].

The tag for this release candidate is available at [3] and [4]. It will be
renamed
once the vote passed.

The mail thread of the vote can be found at [5].

Please take a look at the artifacts and vote!

Please note:
This vote is a "majority approval" with a minimum of three +1 votes (see
[6]).
Hereby we already have one binding +1 vote carrying over from our PPMC vote
by our mentor Julian Feinauer [7]


[ ] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be released, and
why ...


Thanks,
Anatole Tresch

[1] https://dist.apache.org/repos/dist/dev/incubator/tamaya/0.4-incubating/

[2] https://repository.apache.org/content/repositories/orgapachetamaya-1040
[3]

https://gitbox.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=0ad439201f16ba1ddcc6b5c9ffb65e0a8a067301
[4]

https://gitbox.apache.org/repos/asf?p=incubator-tamaya-extensions.git;a=commit;h=a397bf7cf08ec57830aabe7b66099e70390a5006

[5]

https://lists.apache.org/thread.html/7f52e8bcac7f8d60205179b632416ff24cadd64b5f45c38f42f87e38@%3Cdev.tamaya.apache.org%3E

[6] http://www.apache.org/foundation/voting.html#ReleaseVotes
[7]

https://lists.apache.org/thread.html/c56ada758367709f0b9a86712ebc3cea62b799e4c44a057ee87d7761@%3Cdev.tamaya.apache.org%3E

-- 
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter:  @atsticks, @tamayaconf*

Re: [VOTE] Release of Apache Tamaya 0.4-incubating

[Julian Feinauer]

Hi Justin,

yes, this is a minor issue (overcompensation of the to few hashes in the last 
RC) but thanks for the vote!

Julian

Am 05.11.19, 22:56 schrieb "Justin Mclean" :

Hi,

+1 (binding)

I checked:
- incubating in name
- signatures and hashes good
- DISCLAIMER exits
- LICENSE and NOTICE fine
- All files have ASF headers
- No unexpected binary files
- can compile from source

You seem to have gone a little overboard on the hashes, just sha512 and asc 
are needed and you don’t need hashes of the asc file.

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




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

Re: [RESULT][VOTE] Release of Apache Tamaya 0.4-incubating

[Julian Feinauer]

Hi Anatole,

first, congratulations, nicely done (took some stamina to over several RCs...)!
Second, little commnt, the binding votes where from IPMC not PPMC : )

Julian

Am 07.11.19, 12:04 schrieb "Anatole Tresch" :

Thank you all vor voting. I will close this vote with a YES result:

Thank you for voting!

5 binding +1 votes (PPMC):
    Julian Feinauer
Justin Mclean
Jean-Baptiste Onofré
Mohammad Asif Siddiqui
Furkan KAMACI

no non-binding +1 votes
no -1 votes

Have a nice day, Anatole



-- 
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter:  @atsticks, @tamayaconf*

Re: [DISUCSS] Is there any neccessary to do an Apache Release if we publish an App to Apple Store?

[Julian Feinauer]

Hi,

I think this cannot be done as PMC or PPMC as it would be a "binary release" 
which we cannot do with the ASF policy.
So I think another entity than the ASF / the PMC would need to put the App in 
the store, and then you are also free with regards to releases.

Julian

Am 07.11.19, 14:34 schrieb "申远" :

I am OK with the normal release procedure if we have to.

But I'd like to know the boundary line here, why we don't need go though
the release procedure for Apache Project Website and why we need it for an
App built from Apache code. What's the difference here?

Best Regards,
YorkShen

申远


Jamie G.  于2019年11月7日周四 下午9:07写道：

> The App should follow a release process - vetting, vote, signatures,
> tag on source repository, etc.
>
> The community should approve its release.
>
> On Thu, Nov 7, 2019 at 9:29 AM 申远  wrote:
> >
> > Hi, there
> >
> > I'd like to know whether it's necessary to do an Apache Release if we
> > publish an App to Apple Store using the code of Apache Weex [1]. I
> > understand there is no need to do an Apache Release if we publish
> projects
> > website, but what if we publish an App to iOS Apple Store?
> >
> > [1] https://github.com/apache/incubator-weex-playground/tree/master/ios
> >
> > Best Regards,
> > YorkShen
> >
> > 申远
>
> -
> 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: [DISUCSS] Is there any neccessary to do an Apache Release if we publish an App to Apple Store?

[Julian Feinauer]

Thanks Greg, I didn't know that!

Julian

Am 07.11.19, 19:24 schrieb "Greg Stein" :


https://cwiki.apache.org/confluence/display/INFRA/Distribution+via+the+Apple+App+Store

On Thu, Nov 7, 2019 at 12:14 PM Greg Stein  wrote:

> An app signed by the Foundation is most definitely associated with the
> ASF. The Foundation has an Apple Developer Account for exactly this 
reason.
>
>
> On Thu, Nov 7, 2019 at 9:17 AM Justin Mclean 
> wrote:
>
>> Hi,
>>
>> A binary convenance release needs to be created from released voted on
>> code. [1]
>>
>> However if some 3rd party (not the PPMC) wants to use unreleased code and
>> make a “release” from it and put that somewhere but it needs to be clear
>> that this is not in anyway associated with the ASF and it needs to 
respects
>> ASF branding and trademarks.Doing [1] is probably easier so I suggest you
>> go down that path.
>>
>> Thanks,
>> Justin
>>
>> 1. http://www.apache.org/legal/release-policy.html#compiled-packages
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: [VOTE] Accept StreamPipes into the Apache Incubator

[Julian Feinauer]

 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: [RESULT] [VOTE] Accept StreamPipes into the Apache Incubator

[Julian Feinauer]

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



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

Re: [VOTE] Release Apache IoTDB 0.9.2

[Julian Feinauer]

Hi,

my vote is +1 (binding).

I Checked:
- Downloaded files and checked sig and hash
- checked LIC, RELEASE_NOTES, README, NOTICE
- DISCLAIMER is included
- No unexpected binary files
- Built according to instructions in README (some tests fail due to locale 
being not US)
- did NOT check binaries

Julian


Am 21.04.20, 16:23 schrieb "Willem Jiang" :

+1.（Binding）
Download links are valid.
Checksums and PGP signatures are valid.
DISCLAIMER is included.
Checked the git tag.
No binary file in the source file.


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem


On Mon, Apr 20, 2020 at 10:37 PM Dawei Liu  wrote:
>
> Hello all,
>
>
> This is a call for vote to release Apache IoTDB (Incubating) version 
0.9.2, which is the first Apache Release for the IoTDB Project.
>
>
> The Apache IoTDB community has voted on and approved a proposal to release
> Apache IoTDB (Incubating) version 0.9.2.
>
>
> 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. It provides 
users with services for data collection, storage and analysis.
>
>
> IoTDB community vote and result thread:
> Result: 
https://lists.apache.org/thread.html/ra9efae1ec1ee6c89d58f86b16bb195b3e19f925183b4838379896e83%40%3Cdev.iotdb.apache.org%3E
> Vote: 
https://lists.apache.org/thread.html/r9789da87ec813bcb8d0cb6e93451275f2d276685f7f059c457898fe3%40%3Cdev.iotdb.apache.org%3E
>
>
> The release candidates (RC2):
> https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.9.2/rc2
>
>
> Git tag for the release (RC2):
> https://github.com/apache/incubator-iotdb/releases/tag/release%2F0.9.2
>
>
> Hash for the release tag:
> cf1bfb329bb6ac7c2dff0fe3de28404bacfac4aa
>
>
> Release Notes:
> 
https://github.com/apache/incubator-iotdb/blob/cf1bfb329bb6ac7c2dff0fe3de28404bacfac4aa/RELEASE_NOTES.md
>
>
> The artifacts have been signed with Key : EC80A08B232C50B2, 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.
>
>
> From the PPMC Vote we carry over 3 binding IPMC Votes:
>
>
> +1 from Justin Mclean,
> +1 from Jialin Qiao,
> +1 from Xiangdong Huang
>
>
> The vote will be passed if there is no -1 vote ( as there are 3 IPMC +1 
votes already), but we still hope all other IPMCs vote for it.
>
>
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Dawei Liu
> Apache IoTDB

-
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.9.3

[Julian Feinauer]

Hi,

my vote is +1 (binding).

I checked:
- Downloaded Sources
- Checked Signatures and Hashes are ok
- LICENSE, RELEASE_NOTES, NOTICE and README are fine
  - Hive and Commons Notice seems outdated (2018, 2019)
- Unzipped Archive
- No unexpected Binaries
- No Snapshot dependencies
- Run build ("mvn clean install")
  - Comment: Fails with non-english locale. But "mvn clean install 
-Dmaven.test.skip=true" passes, so its "minor"

Best and gratulations to this good RC!
Julian

Am 10.05.20, 09:21 schrieb "孙泽嵩" :

Hello all,


This is a call for vote to release Apache IoTDB (Incubating) version 0.9.3.

Apache IoTDB (incubating) (Database for Internet of Things) is an 
integrated data management engine designed for timeseries data. It provides 
users with services for data collection, storage and analysis.
The Apache IoTDB community has voted on and approved a proposal to release
Apache IoTDB (incubating) version 0.9.3.

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

IoTDB community vote and result thread:
Result: 
https://lists.apache.org/thread.html/r1b1c8058fe2dcf7602b3d987b613cd0807abb53f86ad24f358f991a5%40%3Cdev.iotdb.apache.org%3E
Vote: 
https://lists.apache.org/thread.html/rfef4652594af3e3ba0561ebdd9e6fa8eaa549abbb2c7bf1d0c584da9%40%3Cdev.iotdb.apache.org%3E

The release candidates (RC1):
https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.9.3/rc1/

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

Hash for the release tag:
a704aa2cd6a61db57c5495f8b43849be876a1980

Release Notes:

https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.9.3/rc1/RELEASE_NOTES.md

The artifacts have been signed with Key : C336E0143A553B89, 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.

From the PPMC Vote we carry over 1 binding IPMC Votes:

+1 from Christofer Dutz


The vote will be passed if there are at least 2 more IPMC +1 votes and no 
-1 vote.

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


Best,
---
Zesong Sun
Apache IoTDB

Re: [VOTE] Release Apache IoTDB 0.10.1

[Julian Feinauer]

Hi,

my vote is +1 (binding).

I checked:
- Downloaded staged artefacts and checked signature and hash
- Incubating in name
- License and Notice file are fine
- README and RELEASE_NOTES are fine
- No unexpected binaries in source release
- Builds sucessfull on macOS 10.15.5

Great Job Team!

Julian

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

[DISCUSS] Apache IoTDB considers graduation

[Julian Feinauer]

Hi folks,

on the IoTDB mailing list we already had a discussion about our maturity for 
graduation, see [1] and recently started a vote if the community wants to start 
the graduation process [2].

We also filled all materials necessary, see e.g. the maturity evaluation [3] 
and got positive feedback from our mentors.

So I just wanted to inform this list and also start a discussion about others 
thoughts about IoTDBs graduation.

Best!
Julian


[1] 
https://lists.apache.org/thread.html/r7607cbf6ff2020dc7e7cc27eb698ce265b768ed2a63d3e353c2dc572%40%3Cdev.iotdb.apache.org%3E
[2] 
https://lists.apache.org/thread.html/r5fe46923c8625601a25e51340f1df6a2b6472e52dfa2648df116f618%40%3Cdev.iotdb.apache.org%3E

[3] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=148645763

[DISCUSS] Apache IoTDB Graduation

[Julian Feinauer]

Hi all,

as already stated some time ago [1], the Apacher IoTDB community decided that 
it feels ready to graduate.
The maturity assesment is done [2], and the community agreed on starting the 
graduation process in a formal vote [3] (result see [4]).
Ist important to note that all our mentors also participated in the vote with a 
positive vote!

The community also decided about a suggestion fort he initial VP and a charta 
[5, 6] as follows:

The PPMC will suggest the board Xiangdong Huang as first VP for Apache IoTDB

The suggested Charta of IoTDB is „An IoT native database with high performance 
for data management and analysis, on the edge and the cloud“.

We also did an internal discussion which PPMC members want to join the PMC as 
it is estalished, all details can be found here [7].

So, I wanted to bring up the discussion about the incubators and the IPMCs 
thoughts about IoTDBs matureness and ist readiness to graduate.

What do you think?

Finally, big thanks to our Mentors Chris, Justin and Kevin who were really 
helpful in the whole process (as they were all the time) and to all members of 
the awesome IoTDB Community!

Julian (on behalf of the IoTDB Community)

[1] 
https://lists.apache.org/thread.html/r83af02254859c88f2555778e59a5a6fc72a1d9bb4c30c52a82065353%40%3Cgeneral.incubator.apache.org%3E

[2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=148645763

[3] 
https://lists.apache.org/thread.html/r5fe46923c8625601a25e51340f1df6a2b6472e52dfa2648df116f618%40%3Cdev.iotdb.apache.org%3E
[4] 
https://lists.apache.org/thread.html/rd99752552f6ecacaebd4ae4b27b4223c7899aabfa3ea22540a8f0924%40%3Cdev.iotdb.apache.org%3E
[5] 
https://lists.apache.org/thread.html/ra072c0f047c25a439088d12a3fca9e38f67870e71a430772b242343c%40%3Cdev.iotdb.apache.org%3E
[6] 
https://lists.apache.org/thread.html/r884906a2fb1f7e1b6538f9c444d763f2ea6964bbbc707b2a832f8c7c%40%3Cdev.iotdb.apache.org%3E
[7] 
https://lists.apache.org/thread.html/r768dace1874ac9e1eed6ed138ae1a686b381a9775ba648d0fa5cef22%40%3Cdev.iotdb.apache.org%3E

Re: [VOTE] Graduate Apache IoTDB as TLP

[Julian Feinauer]

+1 (binding)

Its an awesome community and so much fun to see the project grow!

Julian

Am 10.09.20, 10:54 schrieb "Patrick Wiener" :

+1 (non-binding)

keep up the great work!

Patrick

> Am 10.09.2020 um 10:02 schrieb Dominik Riemer :
> 
> +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 
>  

Re: [DISCUSS] Hop proposal

[Julian Feinauer]

Hey,

thanks for your statement Max and thats already a great start as we coannot 
expect fresh podlings to know the apache way (at all?) as then there would be 
no point for the incubator.
But knowing you and your motivation and reading your statement about the team 
makes me very confident that this could be a very smooth ride : )

So, best from my side!

Julian

Am 10.09.20, 12:40 schrieb "Maximilian Michels" :

I've met Matt and other folks from the Hop project more than a year ago 
through Beam Summit Europe. I can say that they are genuinely passionate 
about open-source. Initially, they were not familiar with the Apache 
Way, but throughout the past year, everyone has ramped up their 
knowledge about the ASF. You will also see that reflected in the proposal.

Hop is a great project in the sense that it adds GUI-based integration 
to many data processing projects at Apache. This is appealing to me 
because we are leveraging many of the existing projects such as Spark, 
Flink, Hadoop, Cassandra, Kafka, etc. The project would be a great 
addition to the Apache project portfolio.

This is going to be my first project as a Champion and I'm very much 
looking forward to guiding the project throughout the incubation process.

Please post your questions or let us know if you want to help with 
mentoring the project.

-Max

On 08.09.20 12:30, Matt Casters wrote:
> Thank you very much Kevin!
> 
> On Tue, Sep 8, 2020 at 12:07 PM Kevin Ratnasekera 

> wrote:
> 
>> +1 ( binding ) Interesting project. Please add me as a mentor to the
>> project.
>>
>> On Tue, Sep 8, 2020 at 3:26 PM Matt Casters
>>  wrote:
>>
>>> Hello Apache,
>>>
>>> Our community is eager to propose for Hop to join the Apache Incubator.
>>> The Hop Orchestration Platform aims to help people with complex data and
>>> metadata orchestration problems.
>>>
>>> Below is the complete text of the proposal but you can also find it 
here:
>>> https://cwiki.apache.org/confluence/display/INCUBATOR/HopProposal
>>>
>>> Any help with respect to the incubation is appreciated including help
>> from
>>> a few more mentors to set us on the right track.  On behalf of my
>> community
>>> I'd be happy to answer any questions you might have regarding Hop.  Our
>>> thanks go out to Max, Julian and Tom for helping us set up this 
proposal.
>>>
>>> Thanks in advance for your time!
>>>
>>> Best regards,
>>>
>>> Matt - Hop co-founder
>>> www.project-hop.org
>>> ---
>>>
>>> Abstract
>>> =
>>> Hop is short for the Hop Orchestration Platform. Written completely in
>> Java
>>> it aims to provide a wide range of data orchestration tools, including a
>>> visual development environment, servers, metadata analysis, auditing
>>> services and so on. As a platform Hop also wants to be a re-usable
>> library
>>> so that it can be easily re-used by other software.
>>>
>>> Proposal
>>> =
>>> Hop provides all the tools to build, maintain and deploy data
>>> orchestration, ETL and data integration solutions. For example, Hop
>> allows
>>> you to diagram a data flow that propagates changes from a database via
>>> Apache Kafka to a data warehouse and deploy it as an Apache Beam
>> pipeline.
>>> The core concepts of Hop are Pipelines and Workflows.
>>> * Pipelines do the core data manipulation work (read, manipulate, write
>>> data). The main items of work in pipelines are transforms. A pipeline
>>> consists of two or more (usually many) transforms that each perform a
>>> granular piece of work. The transforms in a pipeline run in parallel, 
and
>>> together create a powerful data processing tool.
>>> * Workflows take care of the orchestration of actions: execute 
pipelines,
>>> run child workflows, environment checks, preparation, problem alerting
>> and
>>> so on.
>>> If these terms sound familiar it’s because they are taken from the 
Apache
>>> Beam and Apache Airflow projects.
>>>
>>>
>>> The main components of the Hop platform are:
>>> * hop-gui, a visual data orchestration IDE
>>> * hop-run: a CLI tool to run workflows or pipelines
>>> * hop-config: a CLI tool to configure Hop and its components
>>> * hop-server: a light-weight web server to run and monitor workflows and
>>> pipelines
>>> * hop-translator: a tool for translating the various parts of the Hop
>> tools
>>> (i18n).
>>> * hop-web: a thin client version of hop-gui for web browsers and mobile
>>> devices
>>>
>>>
>>> The cornerstone of the Hop platform is extensibility: all major
>> components
>>> of the platform are designed to be pluggable. This allows any possible
>>> missing functionality to be created in a short