Hi Dominik El lun, 5 may 2025 a las 16:33, Dominik Hanak (<domin.ha...@gmail.com>) escribió: > > Enrique, > > I agree more involvement is needed. That is why I am highlighting the > template, as from my experience > having detailed base focused on technical details, helps and facilities > better collaboration on any code base.
There are two different problems at play. 1. awareness / involved 2. better understanding of that will be done. The current problem is not about better understanding (template) it is about awareness They are two different things/concepts My concern about getting into a call is about this will lead people to try to fix things *after* following the procedure which is the formal way to organise the community. This is the wrong approach and lessons learnt. I can agree to certain extent that more detailed would help to see the impact clearly, but given such a complex problem of supporting 2 different runtimes and several storage plus different sets of configurations turn this into a little hell to organise things and the only real way to do this is offering certain amount of information and try to implement this in scoped PR to a simple concept (in this case remove the reactive code from the common parts). I am not against being inclusive at this point but rejecting right away something that was coming along the way is completely a misunderstanding how the community is organised IMO. If the feedback were like this is missing or this need to be addressed that would be ok, but rejecting the core concept of the PR (removing reactive code) that was the core concept is a no-go. Quarkus' implementation was not working properly either (and it was because of the reactive code). * The basic interface is not reactive so it was forced to be called from non reactive code. * This also was a problem with transactions in collocated mode and IIRC collocated mode is one of the supported use cases everybody agreed upon. * This required a bit of a hack with I/O threads and worker threads in that scenario. * This was also a problem with the unit of work as it stores information in the Thread Local variable (so the solution was incompatible) > My understanding is that some technical details of the implementation & > their impact were misunderstood, hence my suggestion to mitigate this. > It will never be perfect, however in open source community we must strive > to provide accurate information about why a change is or > was made. Technical details won't fix awareness. It is just simple. The first thing to become a community is to get involved in the decision making. > > On Mon, 5 May 2025 at 14:07, Toni Rikkola <rikk...@apache.org> wrote: > > > The one delivering it always leads it. > > > > As long as the intentions were brought up on this list in advance, the > > ones surprised then need to use the search function for the list. I doubt > > there is a way for everyone to know everything all the time, but this is > > the closest we can get. > > > > This gives a lot of power for the person delivering and for a good reason, > > none of us wants to waste time on something that gets rejected later. > > > > Toni > > > > On 2025/05/05 09:59:35 Enrique Gonzalez Martinez wrote: > > > Hi Dominik, > > > What you said does not matter if people do not get involved in the > > proposals. > > > You can be as much as specific you want, vote and approve and then, > > > one month later, somebody would be surprised by the job being done. > > > > > > El lun, 5 may 2025 a las 11:33, Dominik Hanak > > > (<domin.ha...@gmail.com>) escribió: > > > > > > > > Hello everyone, > > > > > > > > imho the clarity of what is going to happen and how, can be partially > > > > solved by initially proposing the change as per the > > > > agreed proposal template[1]. The more detailed and specific it is, the > > > > better. > > > > There will always be surprises, the template helps minimizing them. > > > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=340037098#Guidelinefordiscussion,proposalandvote-ProposalTemplate > > > > > > > > Best regards, > > > > > > > > Dominik > > > > > > --------------------------------------------------------------------- > > > 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
