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