Answering in line: El lun, 18 dic 2023 a las 16:04, Francisco Javier Tirado Sarti (<ftira...@redhat.com>) escribió: > > As mentioned before, currently I'm working at DataIndex persistence to > increase performance (avoiding a lot of updates when using Postgresql). > This requires changes in the interface used between indexing and storage, > and it affects MongoDB, Infinispan and Oracle implementations, not only > Postgres. So, in a way, I'm committed to ensuring all of them are still > working (I'm currently changing them to achieve that), although I'm putting > more emphasis on optimizing the postgres one.
You are committed because you are enforced by the fact that those bits are in apache kie repositories and CI. As we did mention before as we (all parties) are focused on delivering pgsql (agreed) you are making a pretty huge effort that requires more time spent on those, burdening your own task and making it more complex than it should be. That is exactly what we are discussing here. IMO, Alex's discussion is a bit more deeper that focusing on one task from an individual committer, so we should try to keep the discussion in that scope and not go into the details of a task. I think Tibor questions are the ones that should be answered in this topic and they are very good as a starting point to center the debate again. > I think we agree that, overall, we should remove those bits which we are > not interested in, based on technical merits, not on circunstancial > availability of resources or changing company priorities. I think we should try to see all sides of a problem. In the end, this effort should be very well balanced. For instance * Time vs resources * User needs vs fancy tech * technical complexity vs return * incubation effort vs primary goals All those are sides of a project and balancing them are key to build something that users want. We need to keep in mind that either an open source project or proprietary code, we will be judged not by the technical merits of a solution but if we solve a users problem in a good way and timely manner. > For example, I'm for removing Infinispan because I do not think it is a > good technology to implement GraphQL capabilities, but keeping relational > and Mongo, because both suit the scenario. Obviously, if keeping MongoDB > was an unaffordable burden, we should reevaluate, but currently, as far as > I know, it is not. As I did mention before, if we use mongo but our users don't (speaking as a mental experiment) we might dedicate resources to a solution that has tech merit but does not solve user problems, meaning wasted resources and sustaining effort. > I'm always talking from a community perspective, from our product, which is > based on Postgres, we should just not include that addon on the image. > > > On Mon, Dec 18, 2023 at 3:15 PM Alex Porcelli <a...@porcelli.me> wrote: > > > Francisco, > > > > This discussion should provide enough heads-up, and community members > > should be able to engage in this ML to express their concerns. > > > > But as I wrote before, this is not about the user's perspective, it's > > about active development and focus. > > > > So far in this thread there's some push back to remove components, but > > no commitment from anyone to keep investing in their development. If > > you, Debabrata and any other are committed to maintain any specific > > component proposed to be removed, the discussion might have a better > > chance to be preserved. > > > > So far, I saw and heard more concerns from active committers about the > > shared burden to carry over those components and the overall impact of > > keeping those. > > > > > > On Mon, Dec 18, 2023 at 9:05 AM Francisco Javier Tirado Sarti > > <ftira...@redhat.com> wrote: > > > > > > 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 > > > > > > > > > >> > >> > > > > > > > > > >> > >> > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > -- Saludos, Enrique González Martínez :) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
