Hi, I think it is hard to compare with Spring Boot, because Spring is the most used framework with much bigger market share than Quarkus. The focus on Quarkus from the past (before KIE in Apache) was driven by internal company decisions, not market share. But this is getting a bit off topic, sorry for that.
I think the most important thing is to take into account, if we have a maintainer for a piece of code. For the case of Mongo, if there is someone willing to maintain it, then it is fine. Same should apply for other parts of the codebase. Leaving something part of the release because there are users for it may be a good reason, however without maintainers of that code, it will get obsolete quickly and be a security nightmare too. I think that is not a good message for those users. So I would say, to move this discussion forward, we may need a list of things proposed to be removed from the release, and if there is an objection, there should be some volunteer, who openly declares, that they want to maintain that part of the codebase. What do you think about this please? Best regards, Tibor Dňa ut 19. 12. 2023, 11:18 Francisco Javier Tirado Sarti < [email protected]> napísal(a): > Ricardo, for images I fully agree we should only include postgresql stuff. > I think we need to separate the image content from the repo content. > We can even select what we want to test in our CI, through maven profiles. > What I want to avoid, given the changing priorities, is to remove some > stuff that will be useful later. In the case of Mongo, since there are > active users, I'm pretty sure it will come up again. In the case of > Infinispan, I'm pretty sure it won't come up again, so we can move to a > legacy repo. > That's the same rationale we used for not removing springboot stuff when we > decided to focus only on quarkus. > > On Mon, Dec 18, 2023 at 4:33 PM ricardo zanini fernandes < > [email protected]> wrote: > > > I think keeping a few addons in a "sandbox" shows the right message to > the > > community and we can even have a governance model that updates the state > of > > such components. We can even keep them in the same repository, in a > > "sandbox" profile so we won't add too much maintenance effort. From the > > image's perspective, it's hard to maintain too many flavors since it > > demands infra resources to build and keep the bits in the image registry. > > If it's not being used based on metrics (pulls from outside, for > instance), > > we should ditch them. > > > > In a nutshell what I propose: > > > > - List the addons/libs we want to support (ex postgres) > > - List the addons/libs that can be in a sandbox model (ex MongoDB) > > - List the addons/libs we want to ditch (ex infinispan) > > > > Then, we add support for images that are only in the first list. > > > > If a sandbox component gains enough traction, we can promote it to a > > "supported" addon. > > > > Cheers! > > > > On Mon, Dec 18, 2023 at 12:04 PM Francisco Javier Tirado Sarti < > > [email protected]> wrote: > > > > > 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. > > > 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. > > > 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. > > > 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 <[email protected]> > 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 > > > > <[email protected]> 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 <[email protected] > > > > > > 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 < > > > [email protected] > > > > > > > > > > > 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 < > > > [email protected]> > > > > > > > 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 < > > > > > > > [email protected] > > > > > > > > > > > > > > > > > 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 < > [email protected]> > > > > > > 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 < > > > > > > > > > > [email protected]> 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 < > > > > > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > I think my point is that value is not that marginal > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 18, 2023 at 11:53 AM Alex Porcelli < > > > > > > > > [email protected]> > > > > > > > > > > > > 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 > > > > > > < > > > > > > > > > > > >> [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] > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > >
