Alex, TOshiya, from my POV the idea of "experimental folder" introduce a logical and practical inconsistence, with downfall issues: 1. from logical POV, it would mean that there would be "stable" (mean - production ready) modules and code mixed with "unstable" (mean experimental) code experimental 2. there would be no way to avoid the latter impacting the former, whatever problem may arise (dependency clashes, CVE, bugs) 3. at ci level, the only way to differentiate a "stable" build with the experimental one would be to create/duplicate CI scripts so that, e.g. there would be a PR build that excludes the experimental module and another one that include them (or, some similar "hack") that, again, would be much more cumbersome to maintain
There is no "easy" solution, IMO, but the constant look for "easy solution" always leads to "workarounds" that, soon after being implemented, proved to be problematic to maintain. Complex problems require complex solutions to be properly addressed and, sorry, but the idea of an "experimental folder" mixed in the very same "production-ready" code seems very naive to me. Cheers Gabriele On Wed, Mar 4, 2026 at 3:13 AM Alex Porcelli <[email protected]> wrote: > The problem of your suggestion Gabriele is the CI complexity it introduces, > being experimental or whatever.. I'd argue once accepted it should be > released.. and this also require being part of release automation. > > We are already struggling with current complexity in place - see the email > I sent early today about 10.2.0 release that I'm sure Kennedy is fighting > hard. > > +1 for the experimental folder, I think Toshyia provided a very good > initial framework we can start with.. and probably in a point in time we > may want to refine it. > > Subhanshu, in the meantime while we discuss these topics in parallel, I > submitted a PR review… so please continue refining it.. don't get this > helpful and healthy discussion distract you from your contribution. Thank > you again! > > - > Alex > > > > On Mon, Mar 02, 2026 at 3:32 AM, Gabriele Cardosi < > [email protected]> wrote: > > > Hi all, > > one of the critical aspects with introducing new features, IMO, it is to > > avoid that "main" branches ends up containing unused code (we already > have > > a certain amount of that) that, anyway, we have to maintain, in terms of > > security, library compatibility, etc.; basically, it will also impact the > > CI build, with all consequent issues (see: clashing libraries versions, > > framework upgrade hassle, etc). > > Creating a specific directory inside the main branch does not solve any > of > > such problems (the name of a directory is just a human convention). In > the > > past I also remember the usage of "experimental" flags but, again, this > > won't solve the above. > > So, I would like to propose two different approaches, to both simplify > the > > introduction of new features from any contributor, on one side, and keep > > integrity of our build, on the other side: > > 1. a specific branch > > 2. a specific repo > > > > I've not a strong opinion about any of the two. Anyway, with either of > > those in place, maybe we would already have, in community, some code > that, > > in the past, has been pushed back due to lack of clear understanding and > > other uncertainty. > > And, again with that in place, that Opentelemetry feature would be easily > > included in our domain. > > (side-note: this is exactly the approach that has been followed by me, in > > the past, after internal discussion with the so-called "drools" team). > > > > M2C > > > > Cheers > > > > On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi <toshiyakobayashi@gmail. > > com> wrote: > > > > Also, having a `contrib/experimental` area can help reduce maintenance > > costs. For example, it could include disclaimers such as: > > > > - Experimental APIs may change in future releases. > > - Experimental features may be removed in future releases. > > - Experimental features must not block a release. For example, if an > issue > > is found in an experimental feature during the release process, we may > > choose to disable that feature for the current release. > > > > This is just a proposal. I’d be happy to hear your thoughts. > > > > Toshiya > > > > On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi > > <[email protected]> wrote: > > > > Thank you for moving this topic forward, Alex. > > > > I agree that criteria are required. > > > > What do you think would be reasonable criteria to establish? > > > > Here is a quick draft. Opinions are welcome: > > > > (Creation) > > - A new feature module should default to contrib/experimental (not > limited > > to new contributors). > > - If a developer wants to place the module elsewhere from the beginning, > > they should start a thread on the dev mailing list (dev ML). If there are > > no objections, it is accepted. If there are objections, a vote will be > held > > (Simple Majority vote: https://www.apache.org/foundation/glossary. > > html#SimpleMajority). > > > > (Promotion) > > - If anyone wants to promote the module to a different location, they > > should start a thread on the dev ML. If there are no objections, it is > > accepted. If there are objections, a vote will be held (Simple Majority > > vote). > > > > * These criteria do not apply to the creation of modules that are not new > > features (e.g., refactoring modules). > > > > Regards, > > Toshiya > > > > On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <[email protected]> wrote: > > > > Subhanshu, > > > > Thank you for the contribution, it's great idea. I'll take some time to > > review soon. > > > > Now I'm sorry to hijack the thread…. > > > > Toshiya-san, > > > > The idea to have contrib/experimental makes total sense, but it misses > > criteria. Lots of features have been added by new contributors without > > > > such > > > > experimental or contrib labels. > > > > I'm absolutely in favor of exploring this idea, but we need to define a > > fair criteria for when a thing is flagged as contrib/experimental and > > what's the criteria to promote it out of that status. > > > > Otherwise we risk creating inconsistency in how we treat contributions, > > especially since we've accepted feature additions at the top level in > > > > the > > > > recent past. > > > > What do you think would be reasonable criteria to establish? > > > > - > > Alex > > > > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi < toshiyakobayashi@ > > gmail.com> wrote: > > > > Hi Subhanshu, > > > > Thank you for the contribution! > > > > The module looks good and will add value to the use cases you > > > > mentioned. > > > > My concern is that `drools-opentelemetry` looks like a feature built > > > > on > > > > top of the Drools engine, so it may not be appropriate to place it > > > > at the > > > > top level of the `drools` repository. Maybe we could have an umbrella > > directory like `drools-contrib` or `drools-experimental`. Does > > > > anyone have > > > > thoughts? > > > > Toshiya > > > > On Wed, Feb 25, 2026 at 8:42 PM Francisco Javier Tirado Sarti > > <[email protected]> wrote: > > > > Hi, > > Nice addition. > > Although not completely related, I think it is worth mentioning that > > > > there > > > > is already some OpenTelemetry usage in the kogito-runtimes > > > > repository. Here > > > > <https://github.com/apache/incubator-kie-kogito-runtimes/tree/main/ > > quarkus/addons/opentelemetry> node > > listeners are used to trace the progress of the Workflow. I do not > > > > think > > > > it will conflict with what you are planning to do (If I understood > > correctly, you are adding OpenTelemetry only to the rule engine) > > > > Also, > > > > since Quarkus's POM handles OpenTelemetry dependencies, we are good > > > > on that > > > > too. > > > > On Wed, Feb 25, 2026 at 12:37 AM Subhanshu Bansal < > > > > subhanshu.bansal5566@ > > > > gmail.com> wrote: > > > > Hi Everyone, > > > > I have opened a PR to implement support for OpenTelemetry for Drools. > > > > PR: https://github.com/apache/incubator-kie-drools/pull/6595 > > > > This is a separate module and why I used Open Telemetry specifically > > > > is > > > > because it gives you production visibility into how your Drools > > > > rules are > > > > actually behaving in a running system. Here’s what that means > > > > concretely > > > > for this project:Distributed TracingWhen rules execute inside a > > microservice, the TracingAgendaEventListener creates spans that > > > > connect to > > > > your existing traces. If a REST request hits your service, triggers > > > > rule > > > > evaluation, and then calls a downstream service, you get one unified > > > > trace > > > > showing exactly which rules fired, how long each took, and what > > > > facts were > > > > involved. Without this, Drools is a black box inside your trace — > > > > you see > > > > the request enter and leave, but nothing about the decision logic in > > between.Metrics for Production MonitoringThe > > > > MetricsAgendaEventListener > > > > exposes counters and histograms that flow into whatever backend you > > > > already > > > > use (Prometheus, Datadog, Grafana, etc.). This lets you: > > > > - Alert when a rule suddenly fires 10x more than usual (possible data > > issue or regression) > > - Dashboard rule firing latency to catch performance degradations > > > > before > > > > users notice > > - Compare rule firing patterns across deployments (did the new rule > > version change behavior?) > > > > Why OpenTelemetry specifically (vs. the existing Micrometer in > > drools-metric)The existing drools-metric module focuses on internal > > node-level constraint evaluation metrics via Micrometer. > > > > OpenTelemetry adds > > > > a different dimension with metrics and tracing. > > > > The key differentiator is correlation. When a customer complaint > > > > comes in, > > > > an SRE can search traces by the request ID, see exactly which rules > > > > fired > > > > during that request, how long each took, and what facts were > > > > inserted — all > > > > without adding any logging or redeploying. That’s the operational > > > > benefit > > > > that the existing drools-metric module doesn’t address. > > > > I am open to all the suggestions. Feel free to reach out. > > > > Thanks! > > > > --------------------------------------------------------------------- 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] > > > > >
