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 <
[email protected]> 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 <
> [email protected]> 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 <[email protected]>
> 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: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
> >>
>

Reply via email to