Thanks Alex, Tony, Now I better understand, make sense.
Thanks for the explanation. Best Gabriele Il giorno ven 4 lug 2025 alle ore 16:08 Alex Porcelli <[email protected]> ha scritto: > The code in question, specifically the YARD runtime, has a development > history dating back to June 2022, which predates the migration of the > codebase to the Apache Software Foundation. During that migration, > other parts of the same effort, such as the YARD tooling, were brought > into the KIE Tools repository, which is already under the ASF. This > suggests the YARD runtime was part of the broader initiative and was > overlooked during the move. > > By recognizing and incorporating it now, we establish consistency in > the codebase and eliminate ambiguity regarding ownership. Treating > this code as ASF property aligns it with related components that are > already within the foundation, helping us reduce risk, not increase > it. > > Leaving it outside ASF, despite its connection to existing ASF-hosted > code, could raise concerns about unclear ownership, especially as > development continues and the code gains visibility. This is where > potential legal concerns could arise, particularly regarding > trademarks or misperceptions about what is or is not part of ASF. > > For context, the PMC plays a crucial role in monitoring and > safeguarding the use of trademarks and ensuring the integrity of ASF > projects. These responsibilities are outlined in more detail here: > - https://www.apache.org/foundation/marks/responsibility.html > - https://www.apache.org/foundation/marks/ > > I think my suggestion aligns with that spirit: to ensure proper > attribution by treating the code as a missing piece of the original > migration. > > - > Alex > > On Fri, Jul 4, 2025 at 9:57 AM Gabriele Cardosi > <[email protected]> wrote: > > > > HI Alex, thanks for your explanation. > > Could you please help me understand better what you mean with: > > "This helps prevent potential legal concerns related to > > ownership, trademarks, and similar issues." > > > > The reason I'm asking is because, reading your explanation, my conclusion > > would be exactly the other way around, so the above is the actual > > discrimination. > > > > Thanks > > > > Best regards > > > > Gabriele > > > > > > Il giorno ven 4 lug 2025 alle ore 15:42 Alex Porcelli <[email protected]> > ha > > scritto: > > > > > Thank you, Gabriele, for engaging and helping to evaluate the overall > > > situation. > > > > > > Based on the repository history, with commits dating back to June > > > 2022, this piece of code was likely overlooked during the migration to > > > Apache. This seems plausible, given that other components, such as the > > > YARD tooling, have already been moved into the KIE Tools repository. > > > The available evidence suggests this code is effectively part of what > > > should now be considered Apache Software Foundation property. > > > > > > Regarding the future of this component, we can reassess its value and > > > determine whether to evolve it or remove it. However, for now, I > > > recommend we treat it as an overlooked part of the original codebase > > > migration. This helps prevent potential legal concerns related to > > > ownership, trademarks, and similar issues. > > > > > > - > > > Alex > > > > > > On Fri, Jul 4, 2025 at 9:28 AM Gabriele Cardosi > > > <[email protected]> wrote: > > > > > > > > Hi Tony, many thanks for your answers, make sense! > > > > > > > > The only thing probably I've not been very clear about is the > "driver" or > > > > business value, or whatever. > > > > > > > > I understand that currently the implementation is targeting > scorecard, > > > but > > > > my question was about the "need" of this other implementation, since, > > > IINW, > > > > we already have a couple of them, or more, around (I may be wrong on > > > that, > > > > of course). > > > > > > > > Am I clear ? Does this make sense ? > > > > > > > > And, my personal POV, I would prefer to not include something that, > > > > eventually, would need to be removed, since, as we all know, removing > > > stuff > > > > is much harder than introducing them, for different reasons.... > > > > > > > > > > > > > > > > Il giorno ven 4 lug 2025 alle ore 15:19 Toni Rikkola < > [email protected] > > > > > > > > ha scritto: > > > > > > > > > Thank you for interest. Like I said this is a separate module that > is > > > easy > > > > > to pick out if needed later. > > > > > > > > > > 1. > > > > > Yes this is another way for defining and grouping rules. > > > > > > > > > > 2. > > > > > org.kie.j2cl is actually something I need to remove. It comes from > our > > > > > j2cl dependencies that are mainly used by tooling. It will be > replaced > > > with > > > > > pure Java approach. This is was used so that the > model-to-YAML-to-model > > > > > functionality could be the same and reused in the J2CL client side. > > > > > > > > > > 3. > > > > > Right now the driver is scorecards, but this can also be used for > data > > > > > aggregation. In the simple cases it could be merging one or more > > > YAML/JSON > > > > > files to a new file using rule logic. > > > > > > > > > > This is right now on alpha stage and for that reason experimental. > This > > > > > does mean that in case it is not useful in future use the bar to > > > remove it > > > > > should be low. > > > > > > > > > > Toni > > > > > > > > > > On 2025/07/04 12:47:47 Gabriele Cardosi wrote: > > > > > > Hi Tony, > > > > > > this seems an interesting feature, indeed. > > > > > > Anyway, as I mentioned in the past for other similar > improvements, I > > > > > think > > > > > > the main concern should be the evaluation of pros/cons, since we > are > > > > > > already struggling to maintain the codebase as it is and this new > > > > > > implementation, inevitably, would increase the surface. > > > > > > First of all I'm looking at the code here [1], and I take for > granted > > > > > that > > > > > > all that code would be incorporated inside the drools repository: > > > please > > > > > > correct me if I'm wrong. > > > > > > 1. IIUC, this is first of all another way to define rules to be > > > invoked > > > > > by > > > > > > the rule engine: is that true, or the execution is delegated to a > > > > > > completely different engine ? > > > > > > 2. I see dependencies like -> org.kie.j2cl.tools; I have no idea > > > what's > > > > > > inside, but the name suggest something on the tool/ui side (j2cl, > > > tools) > > > > > > and, if that is true, such kind of dependencies should not get > in the > > > > > > "backend" side > > > > > > 3. What is the concrete driver for this initiative? I mean, what > use > > > > > > case/issue currently exists that would be solved by that > > > implementation ? > > > > > > > > > > > > Beside minor technical issues or doubts, the main problem from my > > > POV is > > > > > in > > > > > > the overall approach we have to our codebase after the Apache > > > migration. > > > > > > For different reasons, we have to be extremely careful about the > > > > > stability > > > > > > and maintenance of our projects, and indeed we should start > removing > > > > > > dead/unused/unmaintained code for our sake. > > > > > > So, I think we should have a sort of "experimental" or similar > branch > > > > > > (unfortunately, "incubator" name has already been taken), so > that on > > > one > > > > > > side we may promote innovation, as this proposal seems to point > to, > > > but > > > > > on > > > > > > the other side without increasing the burden of maintain the code > > > with > > > > > > something that is not necessary. > > > > > > > > > > > > > > > > > > I want to enforce the point that I have nothing against the idea > by > > > > > itself, > > > > > > but I'm only concerned about our overall context. > > > > > > > > > > > > Many thanks > > > > > > > > > > > > Best > > > > > > > > > > > > Gabriele > > > > > > > > > > > > ---- > > > > > > 1 https://github.com/kubesmarts/yard > > > > > > > > > > > > Il giorno ven 4 lug 2025 alle ore 14:19 Toni Rikkola < > > > [email protected] > > > > > > > > > > > > ha scritto: > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > Summary: > > > > > > > > > > > > > > When we moved to KIE, YARD was still in experimental mode. We > did > > > move > > > > > > > the editors and validation tooling (in kie-tools ATM), but > runtime > > > was > > > > > > > left behind. I previously proposed adding YARD in, but it was > seen > > > as a > > > > > > > risk for the up coming releases. > > > > > > > > > > > > > > Assignee: Me, Toni Rikkola > > > > > > > > > > > > > > Target Release: ASAP > > > > > > > > > > > > > > Scope: > > > > > > > > > > > > > > This will go into the incubator-kie-drools repository as a > > > separated > > > > > > > unit. No dependencies to any other part of KIE will be added. > > > > > > > > > > > > > > Description: > > > > > > > > > > > > > > YARD. Yet Another Rule Definition is best explained in the > > > README.MD > > > > > > > with pictures. It is a work in progress project where the > current > > > main > > > > > > > driver is the decision table feature. > > > > > > > > > > > > > > https://github.com/kubesmarts/yard > > > > > > > > > > > > > > Testing: Unit tests. Human validation is not relevant at this > point > > > > > > > since the project is in Alpha stage. > > > > > > > > > > > > > > Dependencies: Drools > > > > > > > > > > > > > > > > > > > > > Thank you > > > > > > > > > > > > > > Toni Rikkola > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
