Alex, we know the team one of the most active community contributors on Zulip ( Debabrata Patnaik) is using MongoDB for their product. So removing that without a previous warning will not be welcomed.
On Mon, Dec 18, 2023 at 2:31 PM Alex Porcelli <porce...@apache.org> wrote: > The question is not about usage, but the effort to keep components > that haven't been actively maintained. > > The components suggested (including MongoDB) haven’t been actively > developed and keeping those for the 10 release might send the wrong message > regarding continued investment and focus. > > Maybe not releasing then creates an opportunity to hear community feedback, > that might end up helping us prioritize areas of investments. > > > On Mon, Dec 18, 2023 at 7:59 AM Tristan Radisson <radtri...@apache.org> > wrote: > > > 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 > > > > > > >> > >> > > > > > > >> > >> > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
