Hi Mario, some thoughts inline El mar, 19 dic 2023 a las 10:25, Mario Fusco (<[email protected]>) escribió: > > > drools has `drools-reliability` component which persistence is pluggable. > > We have infinispan persistence and h2 persistence at the moment. If we want > > to make the version 10 release "minimal", shall we keep only the h2 > > persistence and then move the infinispan persistence to another repo > > (kiegroup)? WDYT, Mario? > > As Toshiya wrote we're using Infinispan as one implementation of the > persistence layer for the drools-reliability module. This Infinispan-based > persistence is quite well isolated in its own submodule, so in theory it > would be relatively easy to move it somewhere else, but where? back in the > kiegroup? and how we will manage its release then? > In essence I don't see much value in getting rid of that dependency there and > more importantly (and this is a more general note) I'm afraid that having to > release other optional modules from different repositories or even > organizations will bring us many more and bigger problems than the ones > solved by not using those dependencies anymore.
I think we need to establish a baseline to discuss the main problems at hand and what are the agreements we have so far because I believe we are not at the same page at the moment as I can see in some answers in the thread. 1. So far, the only agreement we have is what is going to be shipped in the next release (including persistence in the workflow area), so from my point of view that should be the baseline about what it is in the codebase and what is not. I don't think we have any other agreement (correct me if I am wrong). Just to clarify more so nobody missunderstands; there might be areas that might be gray, but there should not be any discussion that the minimal set of agreement is what we are going to be shippped as part of the product as this mean the codebase is going to be shipped and therefore the only thing necessary to provide the required functionality agreed. 2. Nobody is enforcing to remove or delete any code. As it was said before if there is a mantainer / sustainer of that piece of code, then is fine as long as that work is not impacting any commitment in the current/future work/release or other people task (this already happened and this is the reason this concerns me a lot) The problem I see with both is that let's say we have share code and you add something on top of it that is not going to be part of the delivery. Any change in the codebase will mean that all committers will be enforced to fix/mantain/sustain that, as any change in that shared code can impact potentially that code and therefore transferring that sustaining effort to the whole team of commiters responsible for that area. The reason I did propose to move those "extra from the delivery" somewhere else (TBD) is that you remove that burden from the commiters and let the mantainers move that somewhere else. It would be possible to include checks for that repo or repos so it raises awareness if something is broken in there. I guess the main problem is the lifecycle as those parts will be only community driven and I don't see the problem to set any lifecycle you consider fit till that piece of code is promoted to the apache kie project. I think this works like always for us. If any of those extra gains enough traction I won't complain to take responsability of the code. (hope the problem is understood) > Mario > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Saludos, Enrique González Martínez :) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
