Playing advocate devil now, from a community point of view, I do not see which extra merits deserves postgresql data index storage implementation over MongoDB one (again, from a community point of view) Following with data index case, I would remove Infinispan and keep just one generic JDBC implementation for all relationals (which can be used on Postgres, Oracle and Mysql, among others) On runtimes, I think we need to keep at least one community key-value store, to illustrate that Kogito does not preclude a relational DB (actually, it can be argued, that for runtimes, where query capabilities are minimal or non existent, a key-value should be the preferred option from a theoretical point of view. In practise, if you want to save DBs, you can, as we are going to do, bundle runtimes and data index accessing just one relational DB)
On Mon, Dec 18, 2023 at 12:38 PM Tibor Zimányi <tzima...@apache.org> wrote: > Hi everyone, > > I was about to write something similar as Enrique. There are two aspects > now: > - What should we release as part of 10? > - What should be part of the release in the future? > > I agree, it might be better to start with a minimal set in 10 to reduce the > maintenance costs and then we could build on top of that. Part of kiegroup > in the past was the experimental nature, where we had multiple smaller > projects, that ended in the community, however later they just become a > maintenance burden (even if used for a very small set of use cases) - > remember e.g. droolsjbpm-integration repository, Fuse integration etc. > > Best regards, > Tibor > > Dňa po 18. 12. 2023, 12:23 Enrique Gonzalez Martinez <egonza...@apache.org > > > napísal(a): > > > I do agree in removing or at least setting aside those componentes that > are > > not our primary focus. > > > > As Alex suggested this increases the overhead and we don' t really have > > many hands for now. > > > > I would say that if we don't agree in remove them, at least move those to > > another repo outside the apache kie. That will make > > 1. Its influence won't be a burden to any calls that needs to be made > > regarding codebase. > > 2. It is better start with a minimal set of funcional things working and > > let it grow by need than try to do too much. > > 3. Reduce the effort / expertise require to sustain the codebase. > > 4. Shift the effort to general use cases that are more likely to be used > by > > users. > > > > > > > > > > > > El lun, 18 dic 2023, 12:05, Alex Porcelli <a...@porcelli.me> escribió: > > > > > There’s no proposal yet, this is just a discussion… it’s expected that > a > > > proposal will emerge from here. > > > > > > The discussion is an invite to revisit the complex matrix of > > dependencies + > > > any codebase that hasn’t been much maintained that could be cleaned up. > > > > > > Now to be more specific to persistence, it’s clear that all investments > > has > > > been focused mostly on Postgres. If Oracle has been properly and > actively > > > maintained it’s also a good candidate to be kept. > > > > > > On Mon, Dec 18, 2023 at 5:59 AM Francisco Javier Tirado Sarti < > > > ftira...@redhat.com> wrote: > > > > > > > But in order to be more precise about what we are discussing, I guess > > the > > > > proposal (at least part of it) is to keep only one implementation of > > > > persistence for data index, the postgresql one. Is my understanding > > > > correct? > > > > Or keep Oracle and Postgresql and remove Infinipan and MongoDB? > > > > > > > > > > > > On Mon, Dec 18, 2023 at 11:54 AM Francisco Javier Tirado Sarti < > > > > ftira...@redhat.com> wrote: > > > > > > > > > I think my point is that value is not that marginal > > > > > > > > > > On Mon, Dec 18, 2023 at 11:53 AM Alex Porcelli < > porce...@apache.org> > > > > > wrote: > > > > > > > > > >> Francisco, > > > > >> > > > > >> The question is not about the potential value those components > > > provide… > > > > >> it’s about the cost associated to maintain those for the marginal > > > value > > > > >> they provide. > > > > >> > > > > >> There’s a ripple effect for every component we carry over, adding > a > > > > >> complex > > > > >> matrix of additional resources to be managed like container > images, > > > CVEs > > > > >> associated with them (and their transient dependencies) + all the > > > extra > > > > CI > > > > >> time to build the matrix. > > > > >> > > > > >> > > > > >> On Mon, Dec 18, 2023 at 5:05 AM Francisco Javier Tirado Sarti < > > > > >> ftira...@redhat.com> wrote: > > > > >> > > > > >> > Anyway, I'm currently refactoring data index persistence, > > including > > > > >> changes > > > > >> > in Storage interface (shared with trusty), so maybe we should > > table > > > > the > > > > >> > discussion after that PR is done. Although removing infinispan > and > > > > >> MongoDB > > > > >> > will save me substantial work, I truly believe keeping them adds > > > value > > > > >> to > > > > >> > our platform, so I still vote for keeping. > > > > >> > > > > > >> > On Mon, Dec 18, 2023 at 11:02 AM Francisco Javier Tirado Sarti < > > > > >> > ftira...@redhat.com> wrote: > > > > >> > > > > > >> > > I think having "secondary" addons that illustrate platform > > > extension > > > > >> > > capabilities beyond the one we are prioritizing: postgresql > is a > > > > great > > > > >> > > value. > > > > >> > > Therefore I vote for keeping them, except maybe Infinispan. > > > > >> > > > > > > >> > > On Sun, Dec 17, 2023 at 6:49 PM Alex Porcelli < > > > porce...@apache.org> > > > > >> > wrote: > > > > >> > > > > > > >> > >> As we gear up for the much-anticipated 10.0.0 release, I > invite > > > > >> > >> everyone to a crucial discussion about refining our codebase. > > > This > > > > is > > > > >> > >> not just about what we're adding but also about what we might > > > > >> consider > > > > >> > >> removing or changing for the better. > > > > >> > >> > > > > >> > >> The following are initial suggestions for components we might > > > > >> deprecate: > > > > >> > >> > > > > >> > >> - Infinispan > > > > >> > >> - MongoDB > > > > >> > >> - Redis > > > > >> > >> - Elastic > > > > >> > >> > > > > >> > >> However, this list is just a starting point. I encourage each > > of > > > > you > > > > >> > >> to contribute your thoughts. If there are other components > you > > > > >> believe > > > > >> > >> should be on this list, please bring them forward. Likewise, > if > > > any > > > > >> of > > > > >> > >> the listed components should remain, your input is equally > > > > valuable. > > > > >> > >> Explain your reasons so we can all understand the benefits of > > > > keeping > > > > >> > >> them. > > > > >> > >> > > > > >> > >> The TrustyAI codebase is also up for discussion. It hasn't > > been a > > > > >> > >> primary focus for a while, and while I see some potential in > > it, > > > > >> > >> setting it aside might be more practical for now. But > remember, > > > no > > > > >> > >> decision here is permanent. We can always revisit any > > component, > > > > >> > >> especially if there's a collective interest in its > maintenance > > > and > > > > >> > >> development. > > > > >> > >> > > > > >> > >> Your opinions and expertise are vital in this process. Let's > > work > > > > >> > >> together to make these decisions unanimously, ensuring our > > > > project's > > > > >> > >> long-term success and manageability. > > > > >> > >> > > > > >> > >> - > > > > >> > >> Alex > > > > >> > >> > > > > >> > >> > > > > --------------------------------------------------------------------- > > > > >> > >> To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > >> > >> For additional commands, e-mail: dev-h...@kie.apache.org > > > > >> > >> > > > > >> > >> > > > > >> > > > > > >> > > > > > > > > > > > > > > >
