My 2 cents: I think we should keep MongoDB implementation. As far as I remember from Zulip, there are quite some people using it. Others are less important.
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 > > > > >> > >> > > > > >> > >> > > > > >> > > > > > >> > > > > > > > > > > > > > > >
