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