Here's my take on removing images we might not support anymore: https://github.com/apache/incubator-kie-kogito-images/pull/1726
I've stripped 10 images, we have "only" 14 running in the CI: https://ci-builds.apache.org/blue/organizations/jenkins/KIE%2Fkogito%2Fmain%2Fpullrequest%2Fkogito-images.build-and-test/detail/kogito-images.build-and-test/28/pipeline/ We might be able to cut even more, depending on what we want to do moving forward. Happy new Year! On Thu, Dec 21, 2023 at 4:22 PM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Infinispan and filesystem persistence on runtimes, I think we all agree > these should be goners. > > On Thu, Dec 21, 2023 at 5:56 PM Alex Porcelli <a...@porcelli.me> wrote: > > > Looks like we have a diverse perspective on the possible deprecation > list. > > > > Wondering if we could try to find common sense on components that we > > all would easily agree to start with. A good candidates list are the > > images and maybe the Infinispan as persistence for workflow. Thoughts? > > > > Another input that I can provide is that Gabriele, Tibor and I will > > take a more in-depth look at TrustyAI, proposing items to be removed, > > but I can anticipate that we are looking for keep some parts of it. > > > > On Tue, Dec 19, 2023 at 10:25 AM Mario Fusco <mariofu...@apache.org> > > wrote: > > > > > > > drools has `drools-reliability` component which persistence is > > pluggable. > > > > We have infinispan persistence and h2 persistence at the moment. If > we > > want > > > > to make the version 10 release "minimal", shall we keep only the h2 > > > > persistence and then move the infinispan persistence to another repo > > > > (kiegroup)? WDYT, Mario? > > > > > > As Toshiya wrote we're using Infinispan as one implementation of the > > persistence layer for the drools-reliability module. This > Infinispan-based > > persistence is quite well isolated in its own submodule, so in theory it > > would be relatively easy to move it somewhere else, but where? back in > the > > kiegroup? and how we will manage its release then? > > > > > > In essence I don't see much value in getting rid of that dependency > > there and more importantly (and this is a more general note) I'm afraid > > that having to release other optional modules from different repositories > > or even organizations will bring us many more and bigger problems than > the > > ones solved by not using those dependencies anymore. > > > > > > Mario > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > >
