Re: [DISCUSS] KIE Proposal

[Jason Porter]

Hmm… I don’t seem to have edit access :(

Jason Porter
Software Engineer
He/Him/His

IBM

On Jan 3, 2023, at 11:55, PJ Fanning  wrote:

https://cwiki.apache.org/confluence/display/INCUBATOR/KIE+Proposal  is
the work in progress page.

On Tue, 3 Jan 2023 at 19:53, PJ Fanning  wrote:

I did some of the wikification of the email but it's pretty time
consuming and I want to finish up for the evening.

The main item remaining is to put all the initial committers into the table.

On Tue, 3 Jan 2023 at 19:26, Jason Porter  wrote:

I was just going to do this but looks like you beat me to it, PJ, thank you.

Jason Porter
Software Engineer
He/Him/His

IBM

On Jan 3, 2023, at 09:42, PJ Fanning  wrote:

This Message Is From an External Sender
This message came from outside your organization.
Could we get the proposal doc up on the ASF wiki?

On Tue 3 Jan 2023, 17:25 Jason Porter,  wrote:

Sounds like there aren’t any further questions, but I can appreciate people 
just getting back to work from the end of the year. I’ll give it another day 
before we move on to the next stage, which I believe is a call for a vote, 
correct?

Jason Porter
Software Engineer
He/Him/His

IBM

On Dec 23, 2022, at 09:20, Jason Porter  wrote:

Are there any further questions anyone has about KIE? I know we're nearing the 
end of the year and people may not be watching as closely, but wanted to make 
sure since the discussion has died down.

If there are no further questions, are we able to go to a vote?

From: Jason Porter 
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org 
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal




From: Calvin Kirs 
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal

On Fri, Dec 9, 2022 at 11:45 PM Jason Porter  wrote:

We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- 
Knowledge Is Everything), and the other is a suffix. Both projects are very 
different as well. Servicecomb-kie is a configuration center for microservices 
written in Go, whereas KIE is a knowledge engineering and process automation 
solution written in Java. For example, how was this handled in the context of 
Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? 
Is there precedence within the ASF for similarly named projects? The two 
communities have also co-existed for roughly the same time, using the same 
names without clashes.

That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.

Perfect! Thank you, Calvin.



As was stated previously, the number of projects is much smaller than the 
number of GitHub repos. This is because KIE did not use a singular repository 
model within the GitHub organization. The projects we’re currently considering 
in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for 
the CNCF Serverless Workflow implementation that is going through a naming 
process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own 
well. The existing code base contains a lot of modules and code, which could be 
considered legacy, which we do not plan to move over. There will be a cleaning 
and pruning process to ensure a more relevant, sustainable, and forward-looking 
set of modules as code is moved over. This should further reduce the amount of 
code that is moved over. We understand we may need to collapse the repositories 
moving over to the ASF. Let us know if you want to see how everything rolls 
into a more flat structure.


Regarding umbrella versus standalone projects, we believe that the unified and 
cohesive experience provides more value than just the sum of its parts. This is 
also not just about where we are now, but where we hope to evolve as a 
knowledge engineering platform. On the surface, those projects can be seen as 
independent in their business rules, decisions, and workflow domains. However, 
real-world use cases are more complex. Usually, they require a lot of 
interdependencies, for example, business rules orchestration is accomplished by 
using a workflow file definition (i.e., BPMN), and complex workflow decisions 
are better modeled in DMN models. The aim is to try and drive consistency and 
ease of use across those technologies, in an integrated and holistic manner.


If those projects end up as individual TLPs, it'll be up to users to write a 
lot of boiler-plate code - or create additional new projects to handle and 
abstract the unified experience.


Of course, as a consequence of the unified vision, the current codebase is 
taking advantage of this unification, which means there's a lot of shared code 
among the projects. Moving away from this will also result in more top-level 
supporting projects to provide additional code, needed as foundational code or 
integration code, which may actually create 

Re: [VOTE] Release Apache SDAP (incubating) 1.0.0-rc2

[Justin Mclean]

Hi,

> If using DISCLAIMER-WIP, would we need to switch to that for all our release 
> artifacts? As far as I can see, the issues found in this thread that would 
> necessitate using the WIP disclaimer are present in 2 of the 3 artifacts. 
> Should the other artifact keep the standard DISCLAIMER?

As per [1] - "If the standard DISCLAIMER is used then the release needs to 
comply with all ASF policies”. While some of the issues are minor, I believe 
each binary has a problem that merits a -1 vote. So your option is to fix those 
issues or use a DISCLAIMER-WIP. It is expected that an incubating project will 
use the plain DISCLAIMER before graduation.

Kind Regards,
Justin

1. https://issues.apache.org/jira/browse/LEGAL-469
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache SDAP (incubating) 1.0.0-rc2

[Riley Kuttruff]

If using DISCLAIMER-WIP, would we need to switch to that for all our release 
artifacts? As far as I can see, the issues found in this thread that would 
necessitate using the WIP disclaimer are present in 2 of the 3 artifacts. 
Should the other artifact keep the standard DISCLAIMER?

On 2023/01/03 05:16:09 Justin Mclean wrote:
> Hi,
> 
> You may want to consider using a DISCLAIMER-WIP [1] until these issues are 
> sorted.
> 
> Thanks,
> Justin
> 
> 1. https://issues.apache.org/jira/browse/LEGAL-469

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

Re: [VOTE] Release Apache SDAP (incubating) 1.0.0-rc2

[Julian Hyde]

Thank you to Calvin, John, Justin, Larry for reviewing/voting. You raised some 
good points. SDAP is discussing on its dev@ list and I will argue there that 
they should address most or all in a new RC.

A couple of responses to specific remarks.

> On 2023/01/03 04:48:23 Justin Mclean wrote:
> 
> First off you need to vote on a release artefact not a GitHub tag.

The vote email contained this URL for staged artifacts:

  https://dist.apache.org/repos/dist/dev/incubator/sdap/apache-sdap-1.0.0-rc2/

The GitHub tags mentioned elsewhere in the vote email were just intended to 
provide context.

I would be grateful if everyone can focus discussion on those artifacts, not 
the various branches and tags in GitHub.

> Riley Kuttruff wrote:
>
> Furthermore, with the new year, the copyright statements in the NOTICE
> files are now out of date as you observed. I'm assuming this will require
> a new release candidate?

I am not a lawyer, but I think that it's OK to make a release in 2023 with a 
copyright notice of 2022 that as long as the release doesn't contain any work 
done in 2023.

This is all moot, because it looks like this won't be final RC.

> Frank Greguska wrote:
>
> What does ASL refer to in this context?

I think that Larry meant 'Apache Software License'. Strictly, the license is 
these days called 'Apache License' and abbreviated 'AL'.

Julian

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

Re: [DISCUSS] KIE Proposal

[PJ Fanning]

https://cwiki.apache.org/confluence/display/INCUBATOR/KIE+Proposal is
the work in progress page.

On Tue, 3 Jan 2023 at 19:53, PJ Fanning  wrote:
>
> I did some of the wikification of the email but it's pretty time
> consuming and I want to finish up for the evening.
>
> The main item remaining is to put all the initial committers into the table.
>
> On Tue, 3 Jan 2023 at 19:26, Jason Porter  wrote:
> >
> > I was just going to do this but looks like you beat me to it, PJ, thank you.
> >
> > Jason Porter
> > Software Engineer
> > He/Him/His
> >
> > IBM
> >
> > On Jan 3, 2023, at 09:42, PJ Fanning  wrote:
> >
> > This Message Is From an External Sender
> > This message came from outside your organization.
> > Could we get the proposal doc up on the ASF wiki?
> >
> > On Tue 3 Jan 2023, 17:25 Jason Porter,  wrote:
> >>
> >> Sounds like there aren’t any further questions, but I can appreciate 
> >> people just getting back to work from the end of the year. I’ll give it 
> >> another day before we move on to the next stage, which I believe is a call 
> >> for a vote, correct?
> >>
> >> Jason Porter
> >> Software Engineer
> >> He/Him/His
> >>
> >> IBM
> >>
> >> On Dec 23, 2022, at 09:20, Jason Porter  wrote:
> >>
> >> Are there any further questions anyone has about KIE? I know we're nearing 
> >> the end of the year and people may not be watching as closely, but wanted 
> >> to make sure since the discussion has died down.
> >>
> >> If there are no further questions, are we able to go to a vote?
> >> 
> >> From: Jason Porter 
> >> Sent: Tuesday, December 13, 2022 08:37
> >> To: general@incubator.apache.org 
> >> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
> >>
> >>
> >>
> >> 
> >> From: Calvin Kirs 
> >> Sent: Monday, December 12, 2022 23:31
> >> To: general@incubator.apache.org 
> >> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
> >>
> >> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter  
> >> wrote:
> >>
> >> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- 
> >> Knowledge Is Everything), and the other is a suffix. Both projects are 
> >> very different as well. Servicecomb-kie is a configuration center for 
> >> microservices written in Go, whereas KIE is a knowledge engineering and 
> >> process automation solution written in Java. For example, how was this 
> >> handled in the context of Apache DeltaCloud and Apache DeltaSpike; or 
> >> Apache DataFu and Apache DataLab? Is there precedence within the ASF for 
> >> similarly named projects? The two communities have also co-existed for 
> >> roughly the same time, using the same names without clashes.
> >>
> >> That's not a problem If two projects are in different fields.
> >> we'd just need to be careful with the project description.
> >>
> >> Perfect! Thank you, Calvin.
> >>
> >>
> >>
> >> As was stated previously, the number of projects is much smaller than the 
> >> number of GitHub repos. This is because KIE did not use a singular 
> >> repository model within the GitHub organization. The projects we’re 
> >> currently considering in this proposal are Kogito, jBPM, Drools, 
> >> KIE-Tools, and another project for the CNCF Serverless Workflow 
> >> implementation that is going through a naming process now. KIE-Tools is a 
> >> little odd, though, as it doesn’t stand on its own well. The existing code 
> >> base contains a lot of modules and code, which could be considered legacy, 
> >> which we do not plan to move over. There will be a cleaning and pruning 
> >> process to ensure a more relevant, sustainable, and forward-looking set of 
> >> modules as code is moved over. This should further reduce the amount of 
> >> code that is moved over. We understand we may need to collapse the 
> >> repositories moving over to the ASF. Let us know if you want to see how 
> >> everything rolls into a more flat structure.
> >>
> >>
> >> Regarding umbrella versus standalone projects, we believe that the unified 
> >> and cohesive experience provides more value than just the sum of its 
> >> parts. This is also not just about where we are now, but where we hope to 
> >> evolve as a knowledge engineering platform. On the surface, those projects 
> >> can be seen as independent in their business rules, decisions, and 
> >> workflow domains. However, real-world use cases are more complex. Usually, 
> >> they require a lot of interdependencies, for example, business rules 
> >> orchestration is accomplished by using a workflow file definition (i.e., 
> >> BPMN), and complex workflow decisions are better modeled in DMN models. 
> >> The aim is to try and drive consistency and ease of use across those 
> >> technologies, in an integrated and holistic manner.
> >>
> >>
> >> If those projects end up as individual TLPs, it'll be up to users to write 
> >> a lot of boiler-plate code - or create additional new projects to handle 
> >> and abstract the unified experience.
> >>
> >>
> >> Of 

Re: [DISCUSS] KIE Proposal

[PJ Fanning]

I did some of the wikification of the email but it's pretty time
consuming and I want to finish up for the evening.

The main item remaining is to put all the initial committers into the table.

On Tue, 3 Jan 2023 at 19:26, Jason Porter  wrote:
>
> I was just going to do this but looks like you beat me to it, PJ, thank you.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
> On Jan 3, 2023, at 09:42, PJ Fanning  wrote:
>
> This Message Is From an External Sender
> This message came from outside your organization.
> Could we get the proposal doc up on the ASF wiki?
>
> On Tue 3 Jan 2023, 17:25 Jason Porter,  wrote:
>>
>> Sounds like there aren’t any further questions, but I can appreciate people 
>> just getting back to work from the end of the year. I’ll give it another day 
>> before we move on to the next stage, which I believe is a call for a vote, 
>> correct?
>>
>> Jason Porter
>> Software Engineer
>> He/Him/His
>>
>> IBM
>>
>> On Dec 23, 2022, at 09:20, Jason Porter  wrote:
>>
>> Are there any further questions anyone has about KIE? I know we're nearing 
>> the end of the year and people may not be watching as closely, but wanted to 
>> make sure since the discussion has died down.
>>
>> If there are no further questions, are we able to go to a vote?
>> 
>> From: Jason Porter 
>> Sent: Tuesday, December 13, 2022 08:37
>> To: general@incubator.apache.org 
>> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
>>
>>
>>
>> 
>> From: Calvin Kirs 
>> Sent: Monday, December 12, 2022 23:31
>> To: general@incubator.apache.org 
>> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
>>
>> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter  wrote:
>>
>> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- 
>> Knowledge Is Everything), and the other is a suffix. Both projects are very 
>> different as well. Servicecomb-kie is a configuration center for 
>> microservices written in Go, whereas KIE is a knowledge engineering and 
>> process automation solution written in Java. For example, how was this 
>> handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache 
>> DataFu and Apache DataLab? Is there precedence within the ASF for similarly 
>> named projects? The two communities have also co-existed for roughly the 
>> same time, using the same names without clashes.
>>
>> That's not a problem If two projects are in different fields.
>> we'd just need to be careful with the project description.
>>
>> Perfect! Thank you, Calvin.
>>
>>
>>
>> As was stated previously, the number of projects is much smaller than the 
>> number of GitHub repos. This is because KIE did not use a singular 
>> repository model within the GitHub organization. The projects we’re 
>> currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, 
>> and another project for the CNCF Serverless Workflow implementation that is 
>> going through a naming process now. KIE-Tools is a little odd, though, as it 
>> doesn’t stand on its own well. The existing code base contains a lot of 
>> modules and code, which could be considered legacy, which we do not plan to 
>> move over. There will be a cleaning and pruning process to ensure a more 
>> relevant, sustainable, and forward-looking set of modules as code is moved 
>> over. This should further reduce the amount of code that is moved over. We 
>> understand we may need to collapse the repositories moving over to the ASF. 
>> Let us know if you want to see how everything rolls into a more flat 
>> structure.
>>
>>
>> Regarding umbrella versus standalone projects, we believe that the unified 
>> and cohesive experience provides more value than just the sum of its parts. 
>> This is also not just about where we are now, but where we hope to evolve as 
>> a knowledge engineering platform. On the surface, those projects can be seen 
>> as independent in their business rules, decisions, and workflow domains. 
>> However, real-world use cases are more complex. Usually, they require a lot 
>> of interdependencies, for example, business rules orchestration is 
>> accomplished by using a workflow file definition (i.e., BPMN), and complex 
>> workflow decisions are better modeled in DMN models. The aim is to try and 
>> drive consistency and ease of use across those technologies, in an 
>> integrated and holistic manner.
>>
>>
>> If those projects end up as individual TLPs, it'll be up to users to write a 
>> lot of boiler-plate code - or create additional new projects to handle and 
>> abstract the unified experience.
>>
>>
>> Of course, as a consequence of the unified vision, the current codebase is 
>> taking advantage of this unification, which means there's a lot of shared 
>> code among the projects. Moving away from this will also result in more 
>> top-level supporting projects to provide additional code, needed as 
>> foundational code or integration code, which may actually create more 

Re: [VOTE] Release Apache SDAP (incubating) 1.0.0-rc2

[Frank Greguska]

What does ASL refer to in this context?

With respect to the branch differences: In general we use 'develop' as our 
active development branch; release branches are created from 'develop' and our 
release candidates are built from the release branches. Issues with a release 
are addressed in the release branch itself (as new development MAY have already 
started on 'develop'). Once approved release branches are merged to main/master 
branch and then deleted. Then main/master is merged into 'develop'. 

Thanks,
- Frank
On 2023/01/03 17:56:23 Riley Kuttruff wrote:
> "In general, I would expect your main
> branch to have a superset of the changes in your release branch."
> 
> I checked, and the only differences between the release/1.0.0 branches and 
> the main branches are things like the NOTICE/DISCLAIMER files and adding in 
> missing ASF headers. In short I don't see any "functional" (ie code) changes 
> between the two.
> 
> As to your question, I'm checking with the SDAP community to see what the 
> consensus is.
> 
> Thanks,
> Riley
> 
> On 2023/01/03 17:35:09 larry mccay wrote:
> > "I would like to point out in regards to the missing ASF headers that the
> > links you provide are on a different branch than the one we built the
> > release from."
> > 
> > Apologies, I was jumping around between github repos and got confused.
> > 
> > That said, it seems to me that your release branch having the headers and
> > dev and/or master branches not having them may point to a dev/release flow
> > that may result in regressions. Perhaps you have a different Trunk or
> > whatever your main branch is though. In general, I would expect your main
> > branch to have a superset of the changes in your release branch.
> > 
> > Just to be sure, you don't intend to only license the release
> > branch's source as ASL, right?
> > 
> > On Mon, Jan 2, 2023 at 9:28 PM Riley Kuttruff  wrote:
> > 
> > > Thank you for the notes.
> > >
> > > I would like to point out in regards to the missing ASF headers that the
> > > links you provide are on a different branch than the one we built the
> > > release from. The release artifacts were built from the 'release/1.0.0'
> > > branch in their respective repositories. That said, the 'requirements.txt'
> > > file you linked present in the release does not contain such a header.
> > >
> > > Furthermore, with the new year, the copyright statements in the NOTICE
> > > files are now out of date as you observed. I'm assuming this will require 
> > > a
> > > new release candidate?
> > >
> > > Thanks,
> > > Riley
> > >
> > > On 2022/12/30 23:39:13 larry mccay wrote:
> > > > I wanted to lend a hand with the sdap 1.0.0 release review and wanted to
> > > > let you know that it seems a bit cumbersome to review.
> > > > Perhaps my experience with other projects is limited to similar
> > > > conventions, though.
> > > >
> > > > The fact that the src artifacts aren't under a project specific root
> > > ended
> > > > up polluting my releases directory (where I review releases). This was 
> > > > my
> > > > fault for not noticing the missing root but clearly outside my
> > > > expectations.
> > > >
> > > > I also notice that each of what I would expect to just be separate
> > > modules
> > > > have their own tar balls and even github mirrors which is also awkward
> > > for
> > > > how I expect to review things - though not technically related to 
> > > > typical
> > > > review requirements.
> > > >
> > > > These may be seen as less relevant to the specific release at hand and
> > > more
> > > > for the overall project structure and conventions but they would
> > > certainly
> > > > help in reviewing.
> > > >
> > > > I note that there are numerous files [1][2][3] and many more that may
> > > > require Apache License headers.
> > > >
> > > > You can use something like the following in python files:
> > > > #
> > > > # Licensed to the Apache Software Foundation (ASF) under one or more
> > > > # contributor license agreements.  See the NOTICE file distributed with
> > > > # this work for additional information regarding copyright ownership.
> > > > # The ASF licenses this file to You under the Apache License, Version 
> > > > 2.0
> > > > # (the "License"); you may not use this file except in compliance with
> > > > # the License.  You may obtain a copy of the License at
> > > > #
> > > > #http://www.apache.org/licenses/LICENSE-2.0
> > > > #
> > > > # Unless required by applicable law or agreed to in writing, software
> > > > # distributed under the License is distributed on an "AS IS" BASIS,
> > > > # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > > implied.
> > > > # See the License for the specific language governing permissions and
> > > > # limitations under the License.
> > > > #
> > > >
> > > > The NOTICE file has a copyright of 2017-2022 still and unless this goes
> > > out
> > > > in the next couple days that will be out of date.
> > > > Duplicate and separate files like 

Re: [DISCUSS] KIE Proposal

[Jason Porter]

I was just going to do this but looks like you beat me to it, PJ, thank you.

Jason Porter
Software Engineer
He/Him/His

IBM

On Jan 3, 2023, at 09:42, PJ Fanning  wrote:

This Message Is From an External Sender
This message came from outside your organization.
Could we get the proposal doc up on the ASF wiki?

On Tue 3 Jan 2023, 17:25 Jason Porter, 
mailto:jpor...@ibm.com.invalid>> wrote:
Sounds like there aren’t any further questions, but I can appreciate people 
just getting back to work from the end of the year. I’ll give it another day 
before we move on to the next stage, which I believe is a call for a vote, 
correct?

Jason Porter
Software Engineer
He/Him/His

IBM

On Dec 23, 2022, at 09:20, Jason Porter 
mailto:jpor...@ibm.com.INVALID>> wrote:

Are there any further questions anyone has about KIE? I know we're nearing the 
end of the year and people may not be watching as closely, but wanted to make 
sure since the discussion has died down.

If there are no further questions, are we able to go to a vote?

From: Jason Porter mailto:jpor...@ibm.com.INVALID>>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org 
mailto:general@incubator.apache.org>>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal




From: Calvin Kirs mailto:k...@apache.org>>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org 
mailto:general@incubator.apache.org>>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal

On Fri, Dec 9, 2022 at 11:45 PM Jason Porter 
mailto:jpor...@ibm.com.invalid>> wrote:

We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- 
Knowledge Is Everything), and the other is a suffix. Both projects are very 
different as well. Servicecomb-kie is a configuration center for microservices 
written in Go, whereas KIE is a knowledge engineering and process automation 
solution written in Java. For example, how was this handled in the context of 
Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? 
Is there precedence within the ASF for similarly named projects? The two 
communities have also co-existed for roughly the same time, using the same 
names without clashes.

That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.

Perfect! Thank you, Calvin.



As was stated previously, the number of projects is much smaller than the 
number of GitHub repos. This is because KIE did not use a singular repository 
model within the GitHub organization. The projects we’re currently considering 
in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for 
the CNCF Serverless Workflow implementation that is going through a naming 
process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own 
well. The existing code base contains a lot of modules and code, which could be 
considered legacy, which we do not plan to move over. There will be a cleaning 
and pruning process to ensure a more relevant, sustainable, and forward-looking 
set of modules as code is moved over. This should further reduce the amount of 
code that is moved over. We understand we may need to collapse the repositories 
moving over to the ASF. Let us know if you want to see how everything rolls 
into a more flat structure.


Regarding umbrella versus standalone projects, we believe that the unified and 
cohesive experience provides more value than just the sum of its parts. This is 
also not just about where we are now, but where we hope to evolve as a 
knowledge engineering platform. On the surface, those projects can be seen as 
independent in their business rules, decisions, and workflow domains. However, 
real-world use cases are more complex. Usually, they require a lot of 
interdependencies, for example, business rules orchestration is accomplished by 
using a workflow file definition (i.e., BPMN), and complex workflow decisions 
are better modeled in DMN models. The aim is to try and drive consistency and 
ease of use across those technologies, in an integrated and holistic manner.


If those projects end up as individual TLPs, it'll be up to users to write a 
lot of boiler-plate code - or create additional new projects to handle and 
abstract the unified experience.


Of course, as a consequence of the unified vision, the current codebase is 
taking advantage of this unification, which means there's a lot of shared code 
among the projects. Moving away from this will also result in more top-level 
supporting projects to provide additional code, needed as foundational code or 
integration code, which may actually create more complexity and end-user 
confusion.



Although it might not be the most popular example within Apache, KIE aims to 
provide a similar umbrella cohesiveness that Apache OpenOffice has for their 
sub-projects like Write 

Re: [VOTE] Release Apache SDAP (incubating) 1.0.0-rc2

[Riley Kuttruff]

"In general, I would expect your main
branch to have a superset of the changes in your release branch."

I checked, and the only differences between the release/1.0.0 branches and the 
main branches are things like the NOTICE/DISCLAIMER files and adding in missing 
ASF headers. In short I don't see any "functional" (ie code) changes between 
the two.

As to your question, I'm checking with the SDAP community to see what the 
consensus is.

Thanks,
Riley

On 2023/01/03 17:35:09 larry mccay wrote:
> "I would like to point out in regards to the missing ASF headers that the
> links you provide are on a different branch than the one we built the
> release from."
> 
> Apologies, I was jumping around between github repos and got confused.
> 
> That said, it seems to me that your release branch having the headers and
> dev and/or master branches not having them may point to a dev/release flow
> that may result in regressions. Perhaps you have a different Trunk or
> whatever your main branch is though. In general, I would expect your main
> branch to have a superset of the changes in your release branch.
> 
> Just to be sure, you don't intend to only license the release
> branch's source as ASL, right?
> 
> On Mon, Jan 2, 2023 at 9:28 PM Riley Kuttruff  wrote:
> 
> > Thank you for the notes.
> >
> > I would like to point out in regards to the missing ASF headers that the
> > links you provide are on a different branch than the one we built the
> > release from. The release artifacts were built from the 'release/1.0.0'
> > branch in their respective repositories. That said, the 'requirements.txt'
> > file you linked present in the release does not contain such a header.
> >
> > Furthermore, with the new year, the copyright statements in the NOTICE
> > files are now out of date as you observed. I'm assuming this will require a
> > new release candidate?
> >
> > Thanks,
> > Riley
> >
> > On 2022/12/30 23:39:13 larry mccay wrote:
> > > I wanted to lend a hand with the sdap 1.0.0 release review and wanted to
> > > let you know that it seems a bit cumbersome to review.
> > > Perhaps my experience with other projects is limited to similar
> > > conventions, though.
> > >
> > > The fact that the src artifacts aren't under a project specific root
> > ended
> > > up polluting my releases directory (where I review releases). This was my
> > > fault for not noticing the missing root but clearly outside my
> > > expectations.
> > >
> > > I also notice that each of what I would expect to just be separate
> > modules
> > > have their own tar balls and even github mirrors which is also awkward
> > for
> > > how I expect to review things - though not technically related to typical
> > > review requirements.
> > >
> > > These may be seen as less relevant to the specific release at hand and
> > more
> > > for the overall project structure and conventions but they would
> > certainly
> > > help in reviewing.
> > >
> > > I note that there are numerous files [1][2][3] and many more that may
> > > require Apache License headers.
> > >
> > > You can use something like the following in python files:
> > > #
> > > # Licensed to the Apache Software Foundation (ASF) under one or more
> > > # contributor license agreements.  See the NOTICE file distributed with
> > > # this work for additional information regarding copyright ownership.
> > > # The ASF licenses this file to You under the Apache License, Version 2.0
> > > # (the "License"); you may not use this file except in compliance with
> > > # the License.  You may obtain a copy of the License at
> > > #
> > > #http://www.apache.org/licenses/LICENSE-2.0
> > > #
> > > # Unless required by applicable law or agreed to in writing, software
> > > # distributed under the License is distributed on an "AS IS" BASIS,
> > > # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > implied.
> > > # See the License for the specific language governing permissions and
> > > # limitations under the License.
> > > #
> > >
> > > The NOTICE file has a copyright of 2017-2022 still and unless this goes
> > out
> > > in the next couple days that will be out of date.
> > > Duplicate and separate files like NOTICE, LICENSE, DISCLAIMER access
> > > ingester, nexus and nexusproto as well as CONTRIBUTING.md which is in 2
> > but
> > > not the other point to some organization issues. There should be some
> > > effort put in to possibly make these modules under a common project
> > rather
> > > than what seem like separate projects.
> > >
> > > Some of the above make it pretty cumbersome to review even if not
> > > technically blockers.
> > > Addressing these sorts of things early will help contributors feel more
> > > easily able to help out and can help build your community.
> > > It will also help you get releases out easier.
> > >
> > > Hope the above is useful for you.
> > > Happy to see a release coming together for the SDAP community and
> > > congratulate you on tackling this milestone!
> > >

Re: [VOTE] Release Apache SDAP (incubating) 1.0.0-rc2

[larry mccay]

"I would like to point out in regards to the missing ASF headers that the
links you provide are on a different branch than the one we built the
release from."

Apologies, I was jumping around between github repos and got confused.

That said, it seems to me that your release branch having the headers and
dev and/or master branches not having them may point to a dev/release flow
that may result in regressions. Perhaps you have a different Trunk or
whatever your main branch is though. In general, I would expect your main
branch to have a superset of the changes in your release branch.

Just to be sure, you don't intend to only license the release
branch's source as ASL, right?

On Mon, Jan 2, 2023 at 9:28 PM Riley Kuttruff  wrote:

> Thank you for the notes.
>
> I would like to point out in regards to the missing ASF headers that the
> links you provide are on a different branch than the one we built the
> release from. The release artifacts were built from the 'release/1.0.0'
> branch in their respective repositories. That said, the 'requirements.txt'
> file you linked present in the release does not contain such a header.
>
> Furthermore, with the new year, the copyright statements in the NOTICE
> files are now out of date as you observed. I'm assuming this will require a
> new release candidate?
>
> Thanks,
> Riley
>
> On 2022/12/30 23:39:13 larry mccay wrote:
> > I wanted to lend a hand with the sdap 1.0.0 release review and wanted to
> > let you know that it seems a bit cumbersome to review.
> > Perhaps my experience with other projects is limited to similar
> > conventions, though.
> >
> > The fact that the src artifacts aren't under a project specific root
> ended
> > up polluting my releases directory (where I review releases). This was my
> > fault for not noticing the missing root but clearly outside my
> > expectations.
> >
> > I also notice that each of what I would expect to just be separate
> modules
> > have their own tar balls and even github mirrors which is also awkward
> for
> > how I expect to review things - though not technically related to typical
> > review requirements.
> >
> > These may be seen as less relevant to the specific release at hand and
> more
> > for the overall project structure and conventions but they would
> certainly
> > help in reviewing.
> >
> > I note that there are numerous files [1][2][3] and many more that may
> > require Apache License headers.
> >
> > You can use something like the following in python files:
> > #
> > # Licensed to the Apache Software Foundation (ASF) under one or more
> > # contributor license agreements.  See the NOTICE file distributed with
> > # this work for additional information regarding copyright ownership.
> > # The ASF licenses this file to You under the Apache License, Version 2.0
> > # (the "License"); you may not use this file except in compliance with
> > # the License.  You may obtain a copy of the License at
> > #
> > #http://www.apache.org/licenses/LICENSE-2.0
> > #
> > # Unless required by applicable law or agreed to in writing, software
> > # distributed under the License is distributed on an "AS IS" BASIS,
> > # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> > # See the License for the specific language governing permissions and
> > # limitations under the License.
> > #
> >
> > The NOTICE file has a copyright of 2017-2022 still and unless this goes
> out
> > in the next couple days that will be out of date.
> > Duplicate and separate files like NOTICE, LICENSE, DISCLAIMER access
> > ingester, nexus and nexusproto as well as CONTRIBUTING.md which is in 2
> but
> > not the other point to some organization issues. There should be some
> > effort put in to possibly make these modules under a common project
> rather
> > than what seem like separate projects.
> >
> > Some of the above make it pretty cumbersome to review even if not
> > technically blockers.
> > Addressing these sorts of things early will help contributors feel more
> > easily able to help out and can help build your community.
> > It will also help you get releases out easier.
> >
> > Hope the above is useful for you.
> > Happy to see a release coming together for the SDAP community and
> > congratulate you on tackling this milestone!
> >
> > It isn't clear to me that these should block your initial release - my
> vote
> > would be as follows:
> > -0 for my vote at this time.
> >
> > 1.
> >
> https://github.com/apache/incubator-sdap-ingester/blob/dev/collection_manager/requirements.txt
> > 2.
> >
> https://github.com/apache/incubator-sdap-ingester/blob/dev/collection_manager/setup.py
> > 3.
> >
> https://github.com/apache/incubator-sdap-ingester/blob/dev/collection_manager/collection_manager/main.py
> >
> >
> > On Fri, Dec 30, 2022 at 4:30 PM Julian Hyde  wrote:
> >
> > > Good catch. But could you (and others) continue the process of
> > > reviewing and voting on the release.
> > >
> > > It is established that an official ASF 

Re: [DISCUSS] KIE Proposal

[Jason Porter]

Sure, how do I go about doing that?

Jason Porter
Software Engineer
He/Him/His

IBM

On Jan 3, 2023, at 09:42, PJ Fanning  wrote:

This Message Is From an External Sender
This message came from outside your organization.
Could we get the proposal doc up on the ASF wiki?

On Tue 3 Jan 2023, 17:25 Jason Porter, 
mailto:jpor...@ibm.com.invalid>> wrote:
Sounds like there aren’t any further questions, but I can appreciate people 
just getting back to work from the end of the year. I’ll give it another day 
before we move on to the next stage, which I believe is a call for a vote, 
correct?

Jason Porter
Software Engineer
He/Him/His

IBM

On Dec 23, 2022, at 09:20, Jason Porter 
mailto:jpor...@ibm.com.INVALID>> wrote:

Are there any further questions anyone has about KIE? I know we're nearing the 
end of the year and people may not be watching as closely, but wanted to make 
sure since the discussion has died down.

If there are no further questions, are we able to go to a vote?

From: Jason Porter mailto:jpor...@ibm.com.INVALID>>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org 
mailto:general@incubator.apache.org>>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal




From: Calvin Kirs mailto:k...@apache.org>>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org 
mailto:general@incubator.apache.org>>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal

On Fri, Dec 9, 2022 at 11:45 PM Jason Porter 
mailto:jpor...@ibm.com.invalid>> wrote:

We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- 
Knowledge Is Everything), and the other is a suffix. Both projects are very 
different as well. Servicecomb-kie is a configuration center for microservices 
written in Go, whereas KIE is a knowledge engineering and process automation 
solution written in Java. For example, how was this handled in the context of 
Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? 
Is there precedence within the ASF for similarly named projects? The two 
communities have also co-existed for roughly the same time, using the same 
names without clashes.

That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.

Perfect! Thank you, Calvin.



As was stated previously, the number of projects is much smaller than the 
number of GitHub repos. This is because KIE did not use a singular repository 
model within the GitHub organization. The projects we’re currently considering 
in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for 
the CNCF Serverless Workflow implementation that is going through a naming 
process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own 
well. The existing code base contains a lot of modules and code, which could be 
considered legacy, which we do not plan to move over. There will be a cleaning 
and pruning process to ensure a more relevant, sustainable, and forward-looking 
set of modules as code is moved over. This should further reduce the amount of 
code that is moved over. We understand we may need to collapse the repositories 
moving over to the ASF. Let us know if you want to see how everything rolls 
into a more flat structure.


Regarding umbrella versus standalone projects, we believe that the unified and 
cohesive experience provides more value than just the sum of its parts. This is 
also not just about where we are now, but where we hope to evolve as a 
knowledge engineering platform. On the surface, those projects can be seen as 
independent in their business rules, decisions, and workflow domains. However, 
real-world use cases are more complex. Usually, they require a lot of 
interdependencies, for example, business rules orchestration is accomplished by 
using a workflow file definition (i.e., BPMN), and complex workflow decisions 
are better modeled in DMN models. The aim is to try and drive consistency and 
ease of use across those technologies, in an integrated and holistic manner.


If those projects end up as individual TLPs, it'll be up to users to write a 
lot of boiler-plate code - or create additional new projects to handle and 
abstract the unified experience.


Of course, as a consequence of the unified vision, the current codebase is 
taking advantage of this unification, which means there's a lot of shared code 
among the projects. Moving away from this will also result in more top-level 
supporting projects to provide additional code, needed as foundational code or 
integration code, which may actually create more complexity and end-user 
confusion.



Although it might not be the most popular example within Apache, KIE aims to 
provide a similar umbrella cohesiveness that Apache OpenOffice has for their 
sub-projects like Write and Calc. We really want the community to 

Re: [DISCUSS] KIE Proposal

[PJ Fanning]

Could we get the proposal doc up on the ASF wiki?

On Tue 3 Jan 2023, 17:25 Jason Porter,  wrote:

> Sounds like there aren’t any further questions, but I can appreciate
> people just getting back to work from the end of the year. I’ll give it
> another day before we move on to the next stage, which I believe is a call
> for a vote, correct?
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
> On Dec 23, 2022, at 09:20, Jason Porter  wrote:
>
> Are there any further questions anyone has about KIE? I know we're nearing
> the end of the year and people may not be watching as closely, but wanted
> to make sure since the discussion has died down.
>
> If there are no further questions, are we able to go to a vote?
> 
> From: Jason Porter 
> Sent: Tuesday, December 13, 2022 08:37
> To: general@incubator.apache.org 
> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
>
>
>
> 
> From: Calvin Kirs 
> Sent: Monday, December 12, 2022 23:31
> To: general@incubator.apache.org 
> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
>
> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter 
> wrote:
>
> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE-
> Knowledge Is Everything), and the other is a suffix. Both projects are very
> different as well. Servicecomb-kie is a configuration center for
> microservices written in Go, whereas KIE is a knowledge engineering and
> process automation solution written in Java. For example, how was this
> handled in the context of Apache DeltaCloud and Apache DeltaSpike; or
> Apache DataFu and Apache DataLab? Is there precedence within the ASF for
> similarly named projects? The two communities have also co-existed for
> roughly the same time, using the same names without clashes.
>
> That's not a problem If two projects are in different fields.
> we'd just need to be careful with the project description.
>
> Perfect! Thank you, Calvin.
>
>
>
> As was stated previously, the number of projects is much smaller than the
> number of GitHub repos. This is because KIE did not use a singular
> repository model within the GitHub organization. The projects we’re
> currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools,
> and another project for the CNCF Serverless Workflow implementation that is
> going through a naming process now. KIE-Tools is a little odd, though, as
> it doesn’t stand on its own well. The existing code base contains a lot of
> modules and code, which could be considered legacy, which we do not plan to
> move over. There will be a cleaning and pruning process to ensure a more
> relevant, sustainable, and forward-looking set of modules as code is moved
> over. This should further reduce the amount of code that is moved over. We
> understand we may need to collapse the repositories moving over to the ASF.
> Let us know if you want to see how everything rolls into a more flat
> structure.
>
>
> Regarding umbrella versus standalone projects, we believe that the unified
> and cohesive experience provides more value than just the sum of its parts.
> This is also not just about where we are now, but where we hope to evolve
> as a knowledge engineering platform. On the surface, those projects can be
> seen as independent in their business rules, decisions, and workflow
> domains. However, real-world use cases are more complex. Usually, they
> require a lot of interdependencies, for example, business rules
> orchestration is accomplished by using a workflow file definition (i.e.,
> BPMN), and complex workflow decisions are better modeled in DMN models. The
> aim is to try and drive consistency and ease of use across those
> technologies, in an integrated and holistic manner.
>
>
> If those projects end up as individual TLPs, it'll be up to users to write
> a lot of boiler-plate code - or create additional new projects to handle
> and abstract the unified experience.
>
>
> Of course, as a consequence of the unified vision, the current codebase is
> taking advantage of this unification, which means there's a lot of shared
> code among the projects. Moving away from this will also result in more
> top-level supporting projects to provide additional code, needed as
> foundational code or integration code, which may actually create more
> complexity and end-user confusion.
>
>
>
> Although it might not be the most popular example within Apache, KIE aims
> to provide a similar umbrella cohesiveness that Apache OpenOffice has for
> their sub-projects like Write and Calc. We really want the community to
> think of knowledge engineering as a whole domain of technologies for
> problem-solving, and not on individual silo technologies.
>
>
> Lastly, fracturing the community we have already created around the KIE
> brand and concept is certainly not ideal and will weaken the overall
> project brands and success. We believe we'll be able to leverage further
> what we currently have in the community 

Re: [DISCUSS] KIE Proposal

[Jason Porter]

Sounds like there aren’t any further questions, but I can appreciate people 
just getting back to work from the end of the year. I’ll give it another day 
before we move on to the next stage, which I believe is a call for a vote, 
correct?

Jason Porter
Software Engineer
He/Him/His

IBM

On Dec 23, 2022, at 09:20, Jason Porter  wrote:

Are there any further questions anyone has about KIE? I know we're nearing the 
end of the year and people may not be watching as closely, but wanted to make 
sure since the discussion has died down.

If there are no further questions, are we able to go to a vote?

From: Jason Porter 
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org 
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal




From: Calvin Kirs 
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal

On Fri, Dec 9, 2022 at 11:45 PM Jason Porter  wrote:

We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- 
Knowledge Is Everything), and the other is a suffix. Both projects are very 
different as well. Servicecomb-kie is a configuration center for microservices 
written in Go, whereas KIE is a knowledge engineering and process automation 
solution written in Java. For example, how was this handled in the context of 
Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? 
Is there precedence within the ASF for similarly named projects? The two 
communities have also co-existed for roughly the same time, using the same 
names without clashes.

That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.

Perfect! Thank you, Calvin.



As was stated previously, the number of projects is much smaller than the 
number of GitHub repos. This is because KIE did not use a singular repository 
model within the GitHub organization. The projects we’re currently considering 
in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for 
the CNCF Serverless Workflow implementation that is going through a naming 
process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own 
well. The existing code base contains a lot of modules and code, which could be 
considered legacy, which we do not plan to move over. There will be a cleaning 
and pruning process to ensure a more relevant, sustainable, and forward-looking 
set of modules as code is moved over. This should further reduce the amount of 
code that is moved over. We understand we may need to collapse the repositories 
moving over to the ASF. Let us know if you want to see how everything rolls 
into a more flat structure.


Regarding umbrella versus standalone projects, we believe that the unified and 
cohesive experience provides more value than just the sum of its parts. This is 
also not just about where we are now, but where we hope to evolve as a 
knowledge engineering platform. On the surface, those projects can be seen as 
independent in their business rules, decisions, and workflow domains. However, 
real-world use cases are more complex. Usually, they require a lot of 
interdependencies, for example, business rules orchestration is accomplished by 
using a workflow file definition (i.e., BPMN), and complex workflow decisions 
are better modeled in DMN models. The aim is to try and drive consistency and 
ease of use across those technologies, in an integrated and holistic manner.


If those projects end up as individual TLPs, it'll be up to users to write a 
lot of boiler-plate code - or create additional new projects to handle and 
abstract the unified experience.


Of course, as a consequence of the unified vision, the current codebase is 
taking advantage of this unification, which means there's a lot of shared code 
among the projects. Moving away from this will also result in more top-level 
supporting projects to provide additional code, needed as foundational code or 
integration code, which may actually create more complexity and end-user 
confusion.



Although it might not be the most popular example within Apache, KIE aims to 
provide a similar umbrella cohesiveness that Apache OpenOffice has for their 
sub-projects like Write and Calc. We really want the community to think of 
knowledge engineering as a whole domain of technologies for problem-solving, 
and not on individual silo technologies.


Lastly, fracturing the community we have already created around the KIE brand 
and concept is certainly not ideal and will weaken the overall project brands 
and success. We believe we'll be able to leverage further what we currently 
have in the community and build upon it to create a more cohesive 
knowledge-processing solution if everything stays together and people remain 
invested in the success of the knowledge engineering platform as a whole, 
rather than their individual 

Re: [VOTE] Release Apache SeaTunnel(Incubating) 2.3.0

[Calvin Kirs]

On Tue, Jan 3, 2023 at 4:41 PM Justin Mclean  wrote:
>
> Hi,
>
> With the 3 people you list who voted, it hard to tell who David is and there 
> is no David on your PPMC.
Hi Justin,

David is Lidong Dai, he is IPMC, his voting email is
davidzollo...@gmail.com, we can find the email he is bound to in
whimsy including this[1].

But in any case, the inconsistent name will bring confusion to IPMC, I
will send an additional email to ask the mentor to check whether the
public name is consistent with what the whimsy presented.

[1]https://whimsy.apache.org/roster/committer/lidongdai
>
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>


-- 
Best wishes！
CalvinKirs

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

Re: [VOTE] Release Apache SeaTunnel(Incubating) 2.3.0

[Justin Mclean]

Hi,

With the 3 people you list who voted, it hard to tell who David is and there is 
no David on your PPMC.

Justin


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