+1 On Tue, Dec 19, 2023 at 11:38 AM Tibor Zimányi <[email protected]> wrote:
> 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] > > > > > > > > > > > > > > > > > > > >
