sounds fair; Let’s wait for others input to better understand the impact.
On Sat, May 3, 2025 at 11:10 AM Enrique Gonzalez Martinez < elguard...@gmail.com> wrote: > Yeah. First i need to know what the impact is. > Job service is used by the workflow engine and so far there is no impact in > the workflow engine from any use case as serveless workflow is just another > parser in it (more or less) > Security has not been touched, functionality and performance is already > answered. So i want the people rising concerns to state clearly what are > the problems they see so i can address them publicly either here or in the > PR. > > El sáb, 3 may 2025, 17:01, Alex Porcelli <a...@porcelli.me> escribió: > > > 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 > > > > >
