Hi Toshiya, my idea would be that 1. the "drools-experimental" repo would be built as the other "downstream" repos 2. PRs on "main" should not be considered "broken" if only the drools-experimental repo fails to build (maybe just a warning ?) 3. merging PRs in such "drools-experimental" should be very "easy" - just check that there is not bad or malicious code, and then let the community "decide" if the feature is used/useful or not (*) 4. until the experimental feature is in the drools-experimental repo, the proposer of such feature should also be responsible for maintaining it (*) 5. artifacts built from the drools-experimental should be released to maven repo to be publicly available, maybe with some conventional name to indicate they are experimental (and, as such, absolutely no guarantee in any long term support)
(*) I'm aware that behind those very simple statements there could be a lot of nuances and disagreement. //// To recap, what I'm driving at is: 1. simplify and encourage contributors to propose features we may not even think about 2. avoid our own "bias" to influence the publication of such new features 3. enforce a sense of "belonging" to the community from the proposers, making them responsible of what they propose until the feature finally is promoted to main 4. avoid to increase the burden of maintenance of code that, in the short to long term, may prove to be unused or "dead" I hope to have answered your questions and that all of that makes sense. Cheers Gabriele On Thu, Mar 5, 2026 at 8:44 AM Toshiya Kobayashi <[email protected]> wrote: > Hi Gabriele, > > Assuming "drools-experimental" repo is created, I think your point is > its maintenance policy and CD/CI policy. Could you share your thoughts > on this? (e.g., Should the artifacts be released to maven repo? Should > "drools-experimental" repo CI be executed as downstream CI of "drools" > PR?) > > Thanks! > Toshiya > > On Wed, Mar 4, 2026 at 5:23 PM Gabriele Cardosi > <[email protected]> wrote: > > > > 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] > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
