Enrique, I hear you and - regarding the specific piece of code impacted - I can't agree more that the current state seems to have quite unnecessary complexity.
However, it's not because a change has been discussed, that it has to be executed without taking into account impact on use cases. If there's a concern that current proposed solution has an impact on a use case, it has to be properly addressed. I might be wrong, but the original proposal that has been agreed to progress, didn't clearly stated or evaluated that a use case would not be supported anymore, or would cause significant impact on it (significant impact includes security and performance issues). So.. I'd love to use this thread, or the original, so you can address how the use case referenced is not impact or what type of adjustments you can make to current PR can be made to address the concerns. On Sat, May 3, 2025 at 10:04 AM Enrique Gonzalez Martinez <elguard...@gmail.com> wrote: > > Hi Alex and Tiago > > Regarding calls, as it was mentioned before, it is not the right way > as the formal procedure is to go through is the ML like it is > mentioned by Alex, pushing in any other communication channels steals > the conversation from the community and that is not something we want > in a sensitive component like the workflow engine and its satellites > applications like audit, jobs, index, events and wih, etc... > > The removal of the reactive code was discussed during the spring boot > support discussion. You can check that thread for more details as > Francisco asked for some clarifications about what it means about > removing code that was not shared among runtimes. I did mention > explicitly the reactive code in the job service and there was no push > back in the discussion or any other direction so I presumed by > procedure that everybody was aware. As nobody else raised any concerns > and there was not any push back and everybody agreed on the topic > being discussed (by voting +1 or by being absent) I started to work on > this. > I also asked for volunteers and I should remind people that the > default responsible for moving forward the code is the committer > responsible for making the proposal. Francisco asked for the data > index support and nobody else asked for the job service so I did take > it. > > I want to state clearly that this bullet point on the topic was > mentioned explicitly and nobody pushed back during the active period > of the discussion and vote. > > In any case and just reaching this point I would like to know the > committers concerns because so far they were answered in the PR. > > El sáb, 3 may 2025 a las 15:35, Alex Porcelli (<porce...@apache.org>) > escribió: > > > > Tiago, > > > > I understand the issue concern, as I wrote before. > > > > However I didn’t see any attempt in ML nor in PR to discuss anything. > > > > I’d much rather to see initial discussion happening here, and if party > > involved consider that a call would be helpful, I consider it completely > > fine. > > > > So, please let’s try to have initial conversation here first… unfortunately > > I can’t make the proposed call time, and I’d love to hear the discussion…. > > At least proposals on how to solve the situation, so I’d be aware of > > possible outcomes. > > > > Alex > > > > > > On Sat, May 3, 2025 at 9:03 AM Tiago Bento <tiagobe...@apache.org> wrote: > > > > > Hi Alex, > > > > > > Thanks for raising it here, given it’s been a topic of debate recently. I > > > guess they didn’t default to a call in this case and tried to move it > > > forward in the ML then on the PR directly… but even so people seem to > > > think > > > written communication is lacking something for them to find a common > > > ground > > > for this particular case. > > > > > > If they feel like getting together on a call will help, I guess that’s > > > okay, provided there’s a summary captured here for those who can’t attend, > > > and their proposed resolution is sent in the ML too so everyone can voice > > > their view as well. > > > > > > As long as we’re not under the impression big decisions can be made in > > > calls within a small group, and we eventually come back to the ML with > > > something more polished for everyone to understand and participate in, I > > > guess I don’t see a problem in having these discussion calls. > > > > > > In summary I think we can do both: some times discuss in calls then use > > > the > > > Mailing List for continue discussing and eventually reaching consensus. > > > > > > Regards, > > > > > > Tiago Bento > > > > > > > > > On Fri, May 2, 2025 at 21:14 Alex Porcelli <a...@porcelli.me> wrote: > > > > > > > Hi all, > > > > > > > > I’d like to propose that we bring the current conversation around > > > > SpringBoot support in job-service to the mailing list. > > > > > > > > While I understand the intention behind organizing a call to move the > > > > discussion forward, it’s important to remember that calls are not the > > > > primary medium for resolving decisions in Apache projects. We’ve used > > > > calls in the past, but there’s broad consensus now that the ML should > > > > be the main channel — for transparency, inclusiveness, and alignment > > > > with the Apache Way. In fact, we recently agreed to discontinue the > > > > Friday sync meetings for the same reason [1]. > > > > > > > > I’m not here to dive into the merits of the technical arguments just > > > > yet — though I see valid concerns from both perspectives. On one hand, > > > > the current implementation may seem overly complex and tightly coupled > > > > with Quarkus, which limits portability. On the other, any significant > > > > architectural change needs careful consideration, especially when it > > > > may affect alternative use cases like the SonataFlow deployment > > > > strategy. > > > > > > > > So rather than defaulting to a call, I suggest we use this thread to: > > > > > > > > - Surface and clarify the concerns > > > > - Explore how we can evolve the codebase to support SpringBoot at the > > > > highest quality standard > > > > - Ensure we do so without compromising other existing deployment > > > strategies > > > > > > > > Let’s take full advantage of the mechanisms the community has in > > > > place: [DISCUSS], [PROPOSAL], and [VOTE]. If a call ends up being > > > > necessary to clarify something specific, it should still be initiated > > > > through the ML and the outcomes reflected on the ML. > > > > > > > > Looking forward to your thoughts. > > > > > > > > [1] https://lists.apache.org/thread/xpdvw24ytqojkx7kkbv8l9kp6scznlo3 > > > > > > > > - > > > > Alex > > > > > > > > --------------------------------------------------------------------- > > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
