Re: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling
tison, We've talked with the Hibernate team, and Alex has been a Hibernate contributor. They've sent out emails to the list of contributors asking about switching. We don't have a firm date yet, as you know these things take time, but they are actively working on it. On 2024/03/05 17:35:50 tison wrote: > Thanks for reaching out Alex :D > > I agree with PJ and emphasize that we should highlight the license > issue on release. > > Also, for others in this thread, the thorough solution described above is: > > > The Hibernate team is in the process of relicensing from LGPL to Apache > > License 2.0. > > To Alex: > > How much confidence do you have in this direction? Are you involved in > this effort? > > What if the relicensing doesn't happen? Do you have an alternative plan? > > Best, > tison. > > Alex Porcelli 于2024年3月6日周三 01:25写道： > > > > Thank you PJ! This is very helpful! > > > > On Tue, Mar 5, 2024 at 12:23 PM PJ Fanning wrote: > > > > > > https://incubator.apache.org/policy/incubation.html#disclaimers > > > > > > Have a look at the Disclaimers doc. If you use the WIP Disclaimer then you > > > can do releases that are not fully ASF compliant. It would be good to > > > document clearly about this dependency license issue. > > > > > > > > > > > > On Tue 5 Mar 2024, 17:53 Alex Porcelli, wrote: > > > > > > > Dear Members of the Apache Incubator, > > > > > > > > I hope this email finds you well. My name is Alex Porcelli, and I am > > > > part of the Apache KIE podling community [1]. I am reaching out to > > > > discuss a matter regarding a dependency we have under LGPL, which > > > > falls under Category X according to Apache guidelines. > > > > > > > > The dependency is Hibernate ORM [2], the only supported JPA provider > > > > for Quarkus [3] - the primary runtime provider for Apache KIE podling. > > > > > > > > However, I'd like to emphasize the urgency of our situation. Our > > > > community has dedicated substantial effort over the past six months to > > > > prepare for our initial Apache release. Unfortunately, this delay in > > > > releasing Apache KIE is unprecedented for this community, and it is > > > > critical for us to deliver new releases promptly. Not only does our > > > > large user base eagerly anticipate a new release, but older versions > > > > may also pose security vulnerabilities (CVEs). Additionally, with our > > > > previous release process through Red Hat decommissioned, Apache now > > > > stands as our sole means of distribution. > > > > > > > > Given these circumstances, I kindly ask the Apache Incubator to > > > > consider granting us a temporary exception to maintain the LGPL > > > > dependency for our initial releases. We understand the importance of > > > > adhering to Apache licensing requirements and are willing to make > > > > necessary adjustments while ensuring compliance. However, we believe > > > > that allowing us to proceed with proper disclaimers in place would > > > > enable us to maintain momentum and meet the expectations of our user > > > > community. > > > > > > > > Furthermore, I would like to inform you that the Hibernate team is in > > > > the process of relicensing from LGPL to ASLv3, as indicated in their > > > > recent blog post [4]. This transition aligns with our long-term goals > > > > and demonstrates our commitment to compliance with Apache guidelines. > > > > > > > > We are open to any guidance or suggestions from the Incubator PMC on > > > > how best to proceed. > > > > > > > > Thank you for considering our request. > > > > > > > > Best regards, > > > > Alex Porcelli > > > > Apache KIE Podling Community Member > > > > > > > > [1] - Apache KIE: https://kie.apache.org/ > > > > [2] - Hibernate ORM: https://hibernate.org/orm/ > > > > [3] - Quarkus: https://quarkus.io/ > > > > [4] - Blog post on relicensing: > > > > https://in.relation.to/2023/11/18/license/ > > > > > > > > - > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: podling reports for January 2024
Thanks, PJ. I was just looking at this myself. On 2024/01/09 13:16:03 PJ Fanning wrote: > Hi, > > There doesn't appear to be a setup to provide podling reports for January > 2024. > > I'm going to be away for a few days so I have put together a report > for Apache Pekko. > > https://cwiki.apache.org/confluence/display/PEKKO/Pekko+Podling+Report+-+January+2024 > > Feel free to modify this or to replace it with a completely different report. > > Regards, > PJ > > - > 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
Podling report slipped
Looks like I missed the deadline for KIE, I'm sorry. I'll get one for next month. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
When can an IP clearance start?
We’re currently working through some issues with a software grant, but there is a light at the end of the tunnel. Do we need to wait for the software grant to finalize before starting an IP clearance? If not, that’s available self-serve somewhere, correct? -- Jason Porter Software Engineer He/Him/His IBM
Re: [QUESTION] How do Java-based projects handle Hibernate?
Thanks, Romain. Jason Porter Software Engineer He/Him/His IBM On Jan 30, 2023, at 12:10, Romain Manni-Bucau wrote: Hi Jason, AFAIK it is ok to use it in tests while you don't reference it explicitly in your code (which means delivering it or implementing its SPI/classes and you don't let it be transitive in any assembly somehow) so would mean ok to use in test while you stay under JPA API. So it would be more JPA for the code, OpenJPA/Hibernate in tests and OpenJPA for the runtime until you download it at runtime (like Karaf features can do for ex). Regards, Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau > | Blog <https://rmannibucau.metawerx.net/ > | Old Blog <http://rmannibucau.wordpress.com > | Github <https://github.com/rmannibucau > | LinkedIn <https://www.linkedin.com/in/rmannibucau > | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance > Le lun. 30 janv. 2023 à 20:01, Jason Porter a écrit : Question for the group, since I have seen things that seem contradictory. How do projects handle Hibernate since it's LGPL and as such, a Category X dependency? It seems like simply using the library is fine. However, then you see things about "linking" to the library, does simply using the classes and the imports mean it's included in the source? Is that allowed if we're using JPA and OpenJPA for the classes and Hibernate for the implementation? Along the same lines, what about test libraries? Jason Porter Software Engineer He/Him/His IBM
Re: Does ASF have any agreement with docker?
Any news on this? It would be good to get a license for Apache projects. Jason Porter Software Engineer He/Him/His IBM On Feb 5, 2023, at 20:50, Willem Jiang wrote: ASF has the targeted sponsorship with Jetbrain[1], which supports applying for the license with an apache email. I just found docker is listed as a gold-targeted sponsor[2], maybe we try to apply for the free license with apache org email. [1]https://www.apache.org/foundation/thanks#targeted-platinum-sponsors [2]https://www.apache.org/foundation/thanks#targeted-gold-sponsors Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, Jan 31, 2023 at 10:14 AM Jeff Zhang wrote: Docker desktop is not free any more, I am wondering whether ASF has any agreement with docker. Or does each apache project need to apply for this docker open source program separately? https://www.docker.com/community/open-source/application/ -- Best Regards Jeff Zhang - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[QUESTION] How do Java-based projects handle Hibernate?
Question for the group, since I have seen things that seem contradictory. How do projects handle Hibernate since it's LGPL and as such, a Category X dependency? It seems like simply using the library is fine. However, then you see things about "linking" to the library, does simply using the classes and the imports mean it's included in the source? Is that allowed if we're using JPA and OpenJPA for the classes and Hibernate for the implementation? Along the same lines, what about test libraries? Jason Porter Software Engineer He/Him/His IBM
Re: [QUESTION] Code grant or IP clearance?
Thanks Justin. That very well could take some time :) Drools has 215 contributors, jBPM 128, and Kogito 230. Granted there is a large amount of overlap, but that's a lot of contributors. Jason Porter Software Engineer He/Him/His IBM On Jan 23, 2023, at 19:41, Justin Mclean wrote: HI, For KIE, all of the software that will be part of the podling is already licensed as ASL 2.0. Do we need to have a code grant, or simply pass an IP clearance? While it is under ASL 2.0 a grant would be preferred but not required. All incubating projects still need to pass IP clearance. What most projects do itis identify all contributors to the code base and have them, if possible, sign ICLAs. Kind Regards, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[QUESTION] Code grant or IP clearance?
For KIE, all of the software that will be part of the podling is already licensed as ASL 2.0. Do we need to have a code grant, or simply pass an IP clearance? I realsize that trademarks are a different question and will require a grant. Jason Porter Software Engineer He/Him/His IBM
Re: [VOTE] KIE proposal acceptance
Looks like I messed up sections. Happy to change, but I don't have edit access to the Wiki. We have the Apache Camel project and Brian Proffit as sponsors for the incubator project. Jason Porter Software Engineer He/Him/His IBM On Jan 9, 2023, at 08:02, Sheng Wu wrote: I noticed the sponsor part of the proposal Sponsors IBM and Red Hat are the sponsors for the project. I think this sponsor part referring an ASF TLP, which usually be the incubator in here or other TLPs. These two companies may provide support to the developers, but this is not the meaning of the proposal. Sheng Wu 吴晟 Twitter, wusheng1108 Antoine Toulme 于2023年1月9日周一 22:58写道： Here is my +1 (binding). I worked with Drools long time ago and am excited to see KIE take it to the next level! Cheers, Antoine On Jan 9, 2023, at 06:51, Jason Porter wrote: I'd like to call a vote for the acceptance of KIE as an Apache Incubator project as the conversation around the proposal has ended. The proposal is available at [1]. [1] https://cwiki.apache.org/confluence/display/INCUBATOR/KIE+Proposal Jason Porter Software Engineer He/Him/His IBM - 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: Looking for a Champion: FuzzyLite
Oh, you are correct. I am so sorry. Jason Porter Software Engineer He/Him/His IBM On Jan 5, 2023, at 08:54, Eric Covener wrote: On Thu, Jan 5, 2023 at 10:52 AM Jason Porter wrote: We do have a list of initial committers willing to work on the project. I’m not sure what you’re suggesting we’re missing. Jason Porter This thread is about a different proposal. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Looking for a Champion: FuzzyLite
We do have a list of initial committers willing to work on the project. I’m not sure what you’re suggesting we’re missing. Jason Porter Software Engineer He/Him/His IBM On Jan 5, 2023, at 08:44, PJ Fanning wrote: Hi Juan, I'm willing to assist with putting together a proposal for admission to the Incubator. You might notice in this Pekko example [1] and other proposals include a team of initial contributors. The rules within which Incubator podlings operate require that you have at least 3 individuals willing to vote on releases and such like. I still think it might make sense to try to attract some volunteers before proceeding with creating the proposal. The Pekko team publicised the project in Github and on Social Media and was able to get a number of volunteers in this way. [1] https://cwiki.apache.org/confluence/display/INCUBATOR/PekkoProposal [2] https://github.com/mdedetrich/akka-apache-project/discussions/3 Do you think this is an ok way to proceed? Regards, PJ On 2022/12/20 22:23:31 Juan Rada-Vilela wrote: Hi PJ, Thanks for your email. Only a few people have contributed, and not constantly. I have been the main driver of the engineering efforts. I am thinking of Apache as a way to start a community and keep the development on the projects more active. Juan. On Wed, 21 Dec 2022 at 01:06, PJ Fanning wrote: Resending and including OP, just in case. -- Forwarded message - From: PJ Fanning Date: Tue, 20 Dec 2022 at 13:02 Subject: Re: Looking for a Champion: FuzzyLite To: Thanks Juan for your interest in contributing this work to the ASF. I have a question about whether there are any other people who have contributed to FuzzyLite and if they would be interested in continuing to contribute as part of a FuzzyLite PMC? One of the most important aspects of an ASF project is building a community. On Tue, 20 Dec 2022 at 08:29, Juan Rada-Vilela wrote: Hi, I have created over the past years three projects: fuzzylite (C++), jfuzzylite (Java), and pyfuzzylite (Python), which are well designed and engineered libraries for fuzzy logic controllers, a field within Artificial Intelligence. Their repositories are in github.com/fuzzylite, and the home page is fuzzylite.com I am considering having them for incubation at Apache, so I am looking for a Champion to first find if there is interest in the ASF, and maybe start with one? Kind regards, Juan. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] KIE Proposal
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: [DISCUSS] KIE Proposal
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> 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> 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 Ap
Re: [DISCUSS] KIE Proposal
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> 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> 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-proj
Re: [DISCUSS] KIE Proposal
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: [DISCUSS] KIE Proposal
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 technol
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 technologies. > > > We would like to initially keep the PPMC small, ideally 5-7 people. We have > around 50 people identified as initial committers, but having a PMC that > large during incubation is not ideal for the issues that have been mentioned. > > Jason Porter > Software Engineer > He/Him/His > > IBM > > On Dec 9, 2022, at 08:17, Niall Pemberton wrote: > > On Tue, 6 Dec 2022 at 16:27, Jason Porter
Re: [DISCUSS] KIE Proposal
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. 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 technologies. We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned. Jason Porter Software Engineer He/Him/His IBM On Dec 9, 2022, at 08:17, Niall Pemberton wrote: On Tue, 6 Dec 2022 at 16:27, Jason Porter mailto:jpor...@ibm.com.invalid>> wrote: On Dec 6, 2022, at 01:43, Christofer Dutz wrote: Hi Jason, Well, those numbers are a bit better than the initial ones. Thing is: Mentors will not only have to help onboard people to Apache and teach them how to do things, if they are doing their job correctly, they should also really audit the releases being done and help get the codebase into shape first. Even with 12 sub-projects, work-wise that would put a load on the mentors, as if they signed up for mentoring 12 projects. So how about bringing in projects separately (where it makes sense)? There each project could have their initial PPMC and committer lists and it would spread out the load a bit. However I would expect staffing 12 projects with enough work-w
Re: [DISCUSS] KIE Proposal
> On Dec 6, 2022, at 01:43, Christofer Dutz wrote: > > Hi Jason, > > Well, those numbers are a bit better than the initial ones. > Thing is: Mentors will not only have to help onboard people to Apache and > teach them how to do things, if they are doing their job correctly, they > should also really audit the releases being done and help get the codebase > into shape first. > > Even with 12 sub-projects, work-wise that would put a load on the mentors, as > if they signed up for mentoring 12 projects. > > So how about bringing in projects separately (where it makes sense)? There > each project could have their initial PPMC and committer lists and it would > spread out the load a bit. However I would expect staffing 12 projects with > enough work-willing mentors will still be challenging and I would assume not > all of them to find enough of them, but it could be one first step. > > Or is there an advantage of considering all projects as one unity? > > Chris > > [snip] That is part of a broader question. Some of those repos are things like examples for kogito, the website, etc. Things that are part of the projects themselves, but don’t have a life outside of the project to which they belong. I understand we’ll probably have to collapse the structures within Apache and have a single repo per project. What we’re really looking at as far as projects being donated: Kogito Drools jBPM Then there are the supporting repos for things like examples, docs, website, tooling, etc. Many of the people working on these projects work on all of them, so it would probably be the same group of people with very little deviation in the list of committers. Could they be different PPMCs, but they’d basically be the same group, just more work with the reports, setup, infra, etc. Jason Porter Software Engineer He/Him/His IBM
Re: [DISCUSS] KIE Proposal
On Dec 5, 2022, at 01:23, Christofer Dutz wrote: Hi all, as you already mentioned PLC4X, I think in general supporting something to do logic-decisions based on industrial data-streams would be a nice addition. I do also agree that adding 80 projects might be quite a big gulp for us to ingest. How many people are we talking about being on the IPMC/committers? Mentoring a project with hundreds of people would probably require a fleet of mentors. Hey Chris, The size of the PPMC is a good question. Per the Incubator site [https://incubator.apache.org/guides/ppmc.html] it is typically made up of the initial committers and mentors. We have 51 people currently tagged for being initial committers and three people as mentors. Most have not done anything with Apache. That feels like a lot of people for an initial PPMC. We were initially thinking of something small around 7 people initially. Not sure how that plays in with the list of initial committers though, unless we par that down as well and bring people in during the incubation. WRT the number of projects, we’re not looking at donating all of those. We’re still in discussion on the final list, but that list is considerably smaller. Discussions are leaning toward 12 or so. Jason Porter Software Engineer He/Him/His IBM Chris From: Willem Jiang mailto:willem.ji...@gmail.com>> Date: Monday, 5. December 2022 at 04:15 To: general@incubator.apache.org<mailto:general@incubator.apache.org> mailto:general@incubator.apache.org>> Subject: Re: [DISCUSS] KIE Proposal We need to go through the IP clearance and help the project to do the release that follows the Apache police. It could be a nightmare for the incubator if we donate an "Umbrella Project." Can we consider donating sub-projects such as kogito one by one? Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Fri, Dec 2, 2022 at 9:21 AM Niall Pemberton wrote: Wow, 137 GitHub repositories! OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you have a rough idea of how many of those would be part of the incubation? Historically, Apache has been against "Umbrella Projects" - encouraging them to break up and become individual Top Level Projects (TLP) in their own right - the biggest example of that was Jakarta which used to be anything java related - but there have been others where sub-projects which have a life of their own have moved out to become TLPs. To me this looks like it should be 4 or 5 projects - its not clear whether kie is a product in its own right (with releasable artifcats) or just the umbrella that the others are grouped under? * drools * jbpm * kogito * optaplanner * kie ??? Niall On Thu, 1 Dec 2022 at 21:36, Jason Porter wrote: Abstract KIE (Knowledge is Everything) is a community of solutions and supporting tooling for knowledge engineering and process automation, focusing on events, rules, and workflows. Proposal< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal KIE is a community dedicated to supporting knowledge engineering and process automation, using standards from groups like OMG (BPMN, CMMN, DMN), CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is comprised of leading open-source projects (like Drools and jBPM), which provide modeling and code authoring tools in this space. The work has a strong emphasis on being a first-class citizen for Kubernetes but will continue to support embedded and other environments such as edge computing. Drools and jBPM are well-known projects in their areas of rules and workflow and they will be joined by another project, building on a shared core with jBPM, for CNCF’s Serverless Workflow - this project is going through a naming process at the time of this application. Kogito is the foundation project for workflow which jBPM and CNCF’s Serverless Workflow build on. Services and frameworks are provided to enable those projects in a cloud-native environment and tooling is made available through KIE Tools. Background< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background Experience has shown that a holistic approach is a practical requirement for any knowledge engineering and process automation. This requires a breadth of capabilities able to model and execute an application’s data models, rules, workflows, and events. These projects aim to provide a holistic approach with a strong emphasis on congruency across them. Rationale< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale Knowledge engineering and process automation have been and continue to play a large part in today’s software lifecycle. To date, there have been few truly open-source implementations of any of the specifications (DMN, PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement these standards and fill that gap of having an open-source impl
[DISCUSS] KIE Proposal
that Apache would be a better place for the code base. Red Hat, and IBM, have worked with both foundations and continue to do so. While the Apache brand is indeed well known and has great recognition, we’re looking more toward the neutral nature of being at Apache and keeping the project alive in an environment that is not solely controlled by a single entity. Documentation<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#documentation> Kogito Documentation: https://docs.kogito.kie.org/latest/html_single/#con-kogito-automation_kogito-docs Drools Documentation: https://www.drools.org/learn/documentation.html jBPM Documentation: https://docs.jbpm.org/7.73.0.Final/jbpm-docs/html_single/ Drools DMN Engine landing page: https://www.drools.org/learn/dmn.html DMN Specification: https://www.omg.org/spec/DMN BPMN Specification: https://www.omg.org/spec/BPMN/2.0/ Cloud Events Specification: https://github.com/cloudevents/spec Initial Source<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-source> All the code will be coming from the KIE Community GitHub repo at https://github.com/kiegroup. There will be multiple repositories including examples and code bases for Drools, jBPM, and Kogito. Source and Intellectual Property Submission Plan<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#source-and-intellectual-property-submission-plan> * Source code within GitHub * Domains: kie.org, kogito.org, kogito.kie.org, blog.kie.org, jbpm.org, drools.org, bpmn.new, dmn.new, pmml.new, and sandbox.kie.org are all currently owned by Red Hat External Dependencies:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#external-dependencies> There are some LGPL, and Eclipse dependencies for some of the projects in the test or provided scopes of the Maven poms. For example jdt dependencies for the Eclipse plugins, logback, junit, and similar. Hibernate jars are LGPL as well, those are in jBPM. Cryptography:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#cryptography> There are some calls to the JVM vault, for process migration. Required Resources<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#required-resources> Mailing lists:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#mailing-lists> * priv...@kie.incubator.apache.org * d...@kie.incubator.apache.org * comm...@kie.incubator.apache.org Subversion Directory:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#subversion-directory> None Git Repositories:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#git-repositories> Assuming we can continue to use GitHub, though it may need to migrate to be beneath the Apache Organization. Issue Tracking:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#issue-tracking> If possible, we would like to use GitHub issues. Other Resources:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#other-resources> None. Initial Committers<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-committers> List of GitHub names: Name GitHub Username Apache CLA Apache Email Mario Fusco mariofusco FALSE Toshiya Kobayashi tkobayas TRUE Matteo Mortari tarilabs TRUE Tristan Radisson radtriste FALSE Gabriele Cardosi gitgabrio FALSE Edoardo Vacchi evacchi FALSE Paolo Bizzarri pibizza FALSE Cristiano Nicolai cristianonicolai FALSE Michael Biarnés Kiefer mbiarnes FALSE Enrique González Martínez elguardian FALSE Vani Haripriya Mudadla vaniharipriya FALSE Jason Porter lightguard TRUE lightguar...@apache.org Gonzalo Muñoz gmunozfe FALSE Francisco Javier Tirado Sarti fjtirado FALSE Helber Belmiro hbelmiro TRUE Antonio Fernandez Alhambra afalhambra FALSE Abhijit Humbe abhijithumbe FALSE Martin Weiler martinweiler FALSE Enrique Mingorance Cano ginxo FALSE Tiago Dolphine tiagodolphine FALSE Alex Porcelli porcelli FALSE Kris Verlaenen krisv TRUE (requested kr...@apache.org) Pere Fernández pefernan FALSE Jan Stastny jstastny-cz FALSE Jozef Marko jomarko FALSE Walter Medvedeo wmedvede FALSE Kennedy Bowers kbowers-redhat FALSE Roberto Oliveira rgdoliveira FALSE Andrea Lamparelli lampajr FALSE Bai Xiaofeng bxf12315 FALSE Ruben Romero Montes ruromero FALSE Filippe Spolti spolti FALSE Massimiliano Dessì desmax74 TRUE Tiago Bento tiagobento FALSE Yeser Amer yesamer FALSE Guilherme Caponetto caponetto FALSE Paulo Martins paulovmr FALSE Thiago Lugli thiagoelg FALSE William Antônio Siqueira jesuino FALSE Fabrizio Antonangeli fantonangeli FALSE Valentino Pellegrino vpe
[jira] [Commented] (PODLINGNAMESEARCH-31) Establish whether Apache DeltaSpike is a suitable name
[ https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615470#comment-13615470 ] Jason Porter commented on PODLINGNAMESEARCH-31: --- IIRC, Dan was the one to suggest DeltaSpike, being something (the spike) that filled all the deltas between what we have in Java EE 6 and what we'd like it to be. Establish whether Apache DeltaSpike is a suitable name Key: PODLINGNAMESEARCH-31 URL: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31 Project: Podling Suitable Names Search Issue Type: Suitable Name Search Reporter: John D. Ament Attachments: deltaspike.com Bildschirmfoto 2013-03-27 um 12.58.58.png DeltaSpike is a portmanteau of Delta (for change) and Spike (for 'an abrupt sharp increase'). From the ASF perspective, it is a library of reusable CDI extensions and components. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
