Hi Francisco: Answer inline:
El mié, 31 ene 2024 a las 11:38, Francisco Javier Tirado Sarti (<[email protected]>) escribió: > > Hi Brian > If the code was not functional, I would agree. But the code is fully > functional and we are planning to remove it because of a controversial > potential legal issue that, even with the more restricted view on that, > only affects a dependency and its associated test. It is not "potential", it is a compulsory requirement. We need to comply. This is a ruling above our project and for every apache project. > That's why my PR is removing the driver and disable the test that fails > when the driver is removed, but the code, which is essentially using jdbc, > not specific oracle stuff, is still being compiled and can be used by > projects that include our code plus the driver. I don't want to get to much into detail but if we have a test for jdbc and needs to be disabled because it requires oracle driver it means it is not generic enough therefore it can be enabled probably unless it is really tied to the vendor implementation (no good). While my first reaction was proposing to disable as well, after the Alex PR try, IMO there was not much sense to keep them because it is not abstract enough. This problem is signaling that our implementation is not good enough and requires some tweaks or the tests are not properly done (from the generic point of view). So either we change the tests or we remove the tweaks in the implementation. > Also, I do not understand how you conclude that adding community Oracle > support was a mistake? >From my perspective, it is a mistake because: 1. we need to comply with legal requirements. 2. the design is flawed because bad test or persistence tier is leaking abstractions Honestly at this point of the conversation I don't see sensible to disable the test as this won't be part of the CI and therefore can be broken at anytime and the alternative solution (better IMO) is to improve the test and create a certification matrix where the driver can be added. Keeping in mind that we are using jdbc it should not be difficult. My 2c. > > On Tue, Jan 30, 2024 at 10:40 PM Brian Proffitt <[email protected]> wrote: > > > Yeah, so, catching up on this, and I have to say, I don't understand any > > arguments to leave non-functional code that may not be in compliance > > behind. Any code that jeopardizes compliance needs to be removed, and > > workarounds created. > > > > If there is a genuine concern that somehow, some way, this code might be > > used later, than that's what version control is for: go back to an older > > version and pick up the code from there. > > > > The other mentors may have different solutions, but if you can scrape out > > the driver (binaries and code) and the functionality won't break, then just > > do it. > > > > On 2024/01/29 16:14:10 ricardo zanini fernandes wrote: > > > I'd -1 to remove functional code added by a community member. This would > > > pass the wrong message. > > > > Sorry, it does suck, but sometimes people make honest mistakes and they > > might need correction. It's not a personal slight, especially when legal > > compliance pretty much overrules this situation. > > > > [snip] > > > > Brian Proffitt > > KIE mentor > > > > --------------------------------------------------------------------- > > 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]
