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