You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kie.apache.org by Tiago Bento <ti...@apache.org> on 2024/03/12 19:45:09 UTC
[PROPOSAL] Unblocking and releasing Apache KIE 10
Hi everyone,
Unfortunately, I can't do a tl;dr this time, as this matter requires a
lot of context.
This email will take you < 20 minutes to read, according to
https://thereadtime.com/.
As you may have followed on a separate thread
(https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
many of us were working towards removing a circular dependency
currently present between `kogito-apps` and `kie-tools`. As we
progressed towards a solution, we kept finding the circular dependency
pop up somewhere else. I'll do a breakdown of the things we did, and
the results we had.
Right now, even though we started the effort to move the Quarkus Dev
UI modules to `kie-tools`, we haven't been able to do it yet, as we've
been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
effort was concluded this Monday, with
https://github.com/apache/incubator-kie-tools/pull/2136.
The current scenario we have is:
01. incubator-kie-kogito-runtimes
|==> 02. incubator-kie-kogito-apps
C | 03. incubator-kie-kogito-examples
Y | 04. incubator-kie-kogito-images
C | 05. incubator-kie-kogito-serverless-operator
L | ==========================
E | 06. incubator-kie-sandbox-quarkus-accelerator
|==> 07. incubator-kie-tools
* As `kie-tools`/extended-services depends on `kogito-apps`/jitexecutor;
* and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
`kie-tools`/{many packages}
After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
01. incubator-kie-kogito-runtimes
02. incubator-kie-kogito-apps
03. incubator-kie-kogito-examples
C |==> 04. incubator-kie-kogito-images
Y | 05. incubator-kie-kogito-serverless-operator
C | =====================
L | 06. incubator-kie-sandbox-quarkus-accelerator
E |==> 07. incubator-kie-tools
* As `kie-tools`/kn-plugin-workflow depends on
`kogito-images`/kogito-swf-devmode;
* and `kogito-images`/kogito-swf-devmode depends on
`kie-tools`/sonataflow-quarkus-devui
After moving the `kogito-swf-devmode` image to `kie-tools`, we would've had:
01. incubator-kie-kogito-runtimes
02. incubator-kie-kogito-apps
03. incubator-kie-kogito-examples
04. incubator-kie-kogito-images
C |==> 05. incubator-kie-kogito-serverless-operator
Y | =====================
C | 06. incubator-kie-sandbox-quarkus-accelerator
L |==> 07. incubator-kie-tools
E
* As `kie-tools`/kn-plugin-workflow depends on
`kogito-serverless-operator`;
* and `kogito-serverless-operator` depends on
`kie-tools`/kogito-swf-devmode
Clearly, we have a much bigger problem than a simple circular dependency.
After multiple conversations with a lot of people, it's been really
hard coming up with a simple solution that makes it possible to build
Apache KIE in one shot, while preserving the way everyone is used to
contributing to the multiple repositories we have. More than that,
while making this assessment, I found more problems that, in my
perspective, block Apache KIE 10.
In light of that difficulty, I'm coming forward with my proposal for
the Apache KIE release process, so we can use Apache's mechanisms to
have a slower-paced, in-depth debate about this really complicated
matter.
I'll lay out my entire perspective about the current situation of our
codebase, as well as problems I can currently see. I'll start with an
analysis of the repositories and their purposes, point out some
problems that I believe are blocking our 10 release, explain my
proposal and discuss some consequences to what I'm proposing.
Let's begin.
# THE APACHE KIE REPOS
A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
- incubator-kie-kogito-pipelines @ `main`
- incubator-kie-drools @ `main`
- incubator-kie-optaplanner @ `main`
- incubator-kie-optaplanner-quickstarts @ `main`
- incubator-kie-kogito-runtimes @ `main`
- incubator-kie-kogito-apps @ `main`
- incubator-kie-kogito-examples @ `main`
- incubator-kie-kogito-images @ `main`
- incubator-kie-kogito-serverless-operator @ `main`
- incubator-kie-kogito-docs @ `main`
- incubator-kie-docs @ `main-kogito`
B. TOOLS (count: 2)
- incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
- incubator-kie-tools @ `main`
C. BENCHMARKS (count: 2)
- incubator-kie-kogito-benchmarks @ `main`
- incubator-kie-benchmarks @ `main`
D. ARCHIVED (count: 1)
- incubator-kie-kogito-operator
E. "NON-CODE" (count: 5)
- incubator-kie-issues @ `main`
(Issues only, README should be updated @ `main`. Same for GitHub
Actions workflows.)
- incubator-kie-kogito-website @ `main`
(The Kogito website. Develop & deploy at the `main` branch.)
- incubator-kie-website @ `main`
(The KIE website. Develop @ `main`. Push @ `deploy` to update the website.)
- incubator-kie-kogito-online @ `gh-pages`
(GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
Extension assets.)
- incubator-kie-kogito-online-staging @ `main`
(Same as above, but for manual sanity checks during the staging
phase of a release.)
TOTAL (count: 21)
I grouped the repositories by category, and listed them in a
topological order. Keep in mind that when flattening out a tree, there
are multiple possibilities. For example, OptaPlanner could've been
placed in any position after Drools.
Category A repos are what I've been referring to as `drools` and
`kogito-*` stream. Of course OptaPlanner is inside that stream, as the
way these repositories reference each other are through Maven
SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This mechanism
is well-known to the team, and although flawed for intra-day builds
and disruptive for people in many different time zones, it is already
very comfortable for everyone to work with, I assume.
Contributions made to Category A have some dedicated pipelines, which
are, at least to some extent, able to build cross-repo PRs together
and verify that the codebase will continue working as expected after
they're all merged. From what I could gather, there are some
"sub-streams" currently configured for cross-repo PRs.
- kogito-pipelines
- drools, kogito-runtimes, kogito-apps, and kogito-examples
- optaplanner, and optaplanner-quickstarts
- kogito-images, and kogito-serverless-operator
- kogito-docs
- kie-docs
This means that sending cross-repo PRs to any combination of repos
that are not part of the same "sub-stream" cannot be verified before
merging, making our contribution model dependent on individual
contributors building stuff on their machines to verify that it works.
I based this analysis on
https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml,
https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml,
and https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml.
Note that I'm not that familiar with these pipelines, so please
someone correct me if I'm wrong.
Category B repos are what I've been referring to as `kie-tools`
stream. The first repo there is a template repository that is used by
people starting projects from scratch on KIE Sandbox, similar to a
Maven archetype, if you will. The other one is the KIE Tools monorepo,
a polyglot monorepo with `pnpm` as its build system. Currently, KIE
Tools hosts Java libraries and apps, TypeScript libraries and apps, Go
apps, Docker images, and Helm charts. The `kie-tools` monorepo is
configured to work with sparse checkouts and can do partial builds.
Category B repos refer to Category A repos through timestamped
SNAPSHOTs. This is a new mechanism we recently introduced that will
build and publish immutable, persistent artifacts under a version
following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
releases, as we're now targeting one release for all of Apache KIE, so
we can't have Kogito releases anymore.
An important note here is that Category B repositories have been
historically kept out of any automations we used to have, way back
when Kogito started and we had the Business Central (a.k.a. v7) stream
still going on. For this reason, Category B projects have developed
their own automations, based on GitHub Actions. Category B repos have
always depended on Category A repos using fixed versions. If Category
B repos have had adopted mutable SNAPSHOTs, breaking changes on
Category A repositories would've had the potential to break Category B
silently, leaving Category B with a broken development stream, and
introducing unpleasant surprises for maintainers of Category B repos,
as historically Category A contributors were not familiar with
Category B repos.
Contributions made to Category B repos go through a GitHub Actions
workflow that builds the relevant part of the `kie-tools` monorepo for
the changes introduced. Changes made to the pipeline itself are also
picked up as part of PRs, allowing us to do things like atomically
bumping the Node.js version, for example. More importantly, it allows
us to upgrade the repository to a new timestamped SNAPSHOT together
with the changes necessary to make it stay green.
This setup, however, makes it impossible to have cross-repo PRs
involving Category A and Category B simultaneously, with the current
automations we have.
Category C repos are kind of floating around, and I'm not sure if
there's much activity going on there. Regardless, as they're part of
Apache KIE, they will be part of our release, so I listed them for us
to take them into consideration too.
Category D is self explanatory. There's only one repo that has already
been marked for being archived.
Category E are repos that do not host code directly, and are either
organizational entities, or host websites, that currently are not part
of any pipelines we have.
This lack of unification between Category A and Category B is, IMHO,
what allowed us to introduce the infamous circular dependency between
`kie-tools` and `kogito-apps`, which we now can describe as a circular
dependency between Category A and Category B. The way I see it, if we
had a single pipeline, building everything from `drools` to
`kie-tools`, such flaws would've never been introduced, and we
wouldn't be having this huge problem in our hands right now.
My proposal for the Apache KIE release process sees this lack of
unification as a central problem, not only for this release in
particular, but for the community as a whole. It is my belief that we
are all under the same roof, and that no contribution should be
allowed to break any part of our codebase. With the increasing volume
of code, and hopefully number of contributors too, we cannot keep
counting on "common sense" to avoid breaking things. We're all humans
after all, and it is our job to have mechanisms in place to prevent us
from unwillingly making mistakes. Especially when these mistakes
impact on parts of the codebase that we, individually, probably can't
fix.
# THE PROBLEMS WE HAVE RIGHT NOW
P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools `0.32.0`.
See:
- https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
P2. PR open for Kogito SWF images @ `kogito-images` depending on
kiegroup's KIE Tools `0.32.0`.
See:
- https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
`kie-soup` artifacts at version `7.59.0.Final`.
See:
- https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
- https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
P4. Multiple packages @ `kogito-apps` depending on kiegroup's
Explainability `1.22.1.Final`.
* This module was removed from the KIE codebase here:
https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
and now lives on
https://github.com/trustyai-explainability/trustyai-explainability,
under a different GAV.
* This new repo depends on Kogito and OptaPlanner, pointing to older versions.
See:
- https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
- https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
`1.32.0.Final` and Quarkus `2.15.3.Final`.
See:
- https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
P6. Category C repos are out of date and not part of the Category A
CI/Release pipelines.
* incubator-kie-kogito-benchmarks: (Current version is `2.0-SNAPSHOT`,
depending on Kogito without a specific version, only by using
`http://localhost:8080`)
* incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled after
upgrading to 999-20240218-SNAPSHOT.
In my perspective, P1 and P2 have the same solution, as they both
suffer from the circular dependency between Category A and Category B.
As Category A and Category B are both streams that have been really
active, I see this as a blocker, as there are contributions that
cannot be done, given that Category A depends on Category B with a
dephasing of 1 release.
P3 and P4, although not ideal, can be understood as technical debt.
Depending on unmaintained projects is something we'll always be
susceptible to, given time.
P5 and P6 are easily fixable, as it's just a matter of making them
part of the play.
P7 is an isolated problem that won't impact the structure or anything
that we're talking about here, but it is a regression we introduced
recently.
Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
and P7 have easy fixes, the only problems left to discuss are P1 and
P2, which can't be done without a proper proposal.
# THE PROPOSAL
I'll try to be very meticulous here, since from my experience, any
little miscalculation can lead to our release not working out in the
end. To try and avoid that as much as possible, and make everything we
can to have a successful Apache KIE 10 release, bear with me. I'll lay
out a timeline of events that need to happen in order for our release
to be published, with all artifacts ending up in the right places, but
first, we need to solve problems P1 and P2.
As you saw at the beginning of this email, all the attempts we made
left us with the circular dependency showing up at a different place,
but something all these places have in common is that they're all
after kogito-apps, and before to Category B.
The first part of my proposal is the following:
S1. We keep the original plan of moving the Quarkus Dev UIs from
`kogito-apps` to `kie-tools`, together with Management and Task
consoles from `kogito-images` to `kie-tools`.
S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
from `kogito-images` to `kie-tools` too.
S3. We move the entire `kogito-serverless-operator` repo inside a new
package on `kie-tools`, keeping Git history.
Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
the rest of https://github.com/apache/incubator-kie-issues/issues/967
would still be done too.
This doesn't come without consequences, of course, as the
`kogito-swf-devmode` and `kogito-swf-builder` images, and the
`kogito-serverless-operator` would be moving from Category A to
Category B. This move would make them have to reference Category A
repos through timestamped SNAPSHOTs. Since `kogito-images` and
`kogito-serverless-operator` are already their own "sub-stream" inside
Category A, though, contributions made in a cross-repo fashion to this
"sub-stream" will continue being possible, now via a single PR to
`kie-tools`. Cross-repo PRs between Category A and Category B will
continue not being possible, and a 1-week delay between merging
something on Category A and using it on Category B will still happen.
It's worth mentioning that `kie-tools`, however, does allow for sparse
checkouts and partial builds, so working with a subset of the monorepo
is possible and encouraged. Making changes only to
`packages/kn-plugin-workflow`, for example, will have the PR checks
run in < 10 minutes, as you can see here:
https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136.
We're not compromising when running partial builds too. We know that
the entire repo will continue working even after only building a small
subset of the changes. Doing partial or full builds is automatically
determined by the changes of a PR.
Keep in mind that, even though I'm proposing we move a bunch of
additional stuff into `kie-tools`, I see this as a TEMPORARY solution
for our codebase. `kie-tools` would host some additional stuff
TEMPORARILY so that we can release and continue moving forward.
As I mentioned on other places, `kie-tools` became a polyglot monorepo
out of necessity, and although I'm really proud of what we achieved
there so far, I don't think `kie-tools` has a setup that is suitable
for all the different nuances that compose our community. I'm well
aware that a polyglot monorepo that does not follow widespread
conventions will scare some people away, and as much as we've tried to
make build instructions clear, we can't always get past the prejudice
some people have towards the "front-end" ecosystem.
With all that said, I keep thinking this is the best course of action
for us right now. We keep most of our stuff unchanged, we unblock the
release, and we have a working setup that will suit us well while we
discuss and reach a conclusion regarding the future of our codebase
structure.
Let me paint a quick picture here of what our code base would look
like, repository-wise, if my proposal is accepted:
CATEGORY REPO
=====================
A incubator-kie-kogito-pipelines
A incubator-kie-drools
A incubator-kie-optaplanner
A incubator-kie-optaplanner-quickstarts
A incubator-kie-kogito-runtimes
A incubator-kie-kogito-apps
A incubator-kie-kogito-examples
A incubator-kie-kogito-images
A incubator-kie-kogito-docs
A incubator-kie-kogito-benchmarks
A incubator-kie-docs
A incubator-kie-benchmarks
=====================
B incubator-kie-sandbox-quarkus-accelerator
B incubator-kie-tools
=====================
D incubator-kie-kogito-operator
=====================
E incubator-kie-issues
E incubator-kie-kogito-website
E incubator-kie-website
E incubator-kie-kogito-online
E incubator-kie-kogito-online-staging
=====================
* Category C becomes part of Category A, and
`kogito-serverless-operator` moves entirely inside `kie-tools`.
* With `kogito-swf-{builder,devmode}` images and
`kogito-serverless-operator` inside `kie-tools`, there are no cycles
anymore, as inside `kie-tools`, we can granularly build:
1. packages/sonataflow-deployment-webapp
2. packages/sonataflow-quarkus-devui
3. packages/sonataflow-images (containing `kogito-swf-builder` and
`kogito-swf-devmode`)
4. packages/sonataflow-operator (contents from `kogito-serverless-operator`)
5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
but renamed)
The second part of the proposal is the release process itself,
assuming the structure above is what we have.
Here it is:
1. Define a timestamped SNAPSHOT to be used as cutting point for
Category A repos.
2. Update Category B repos to point to this timestamped SNAPSHOT, and
verify that everything is working.
3. At this point, with everything working, we can branch out to
`10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
from `main`.
4. All Category A and Category B repos update their versions to
10.0.0, in their `10.0.x` branches.
5. Update Category B repos to point to Category A repos using the
10.0.0 version.
6. At this point, we can vote on the release based on the `10.0.x`
branches, given we don't expect any code changes anymore.
7. After voting passes, we're good to start the release process.
8. Category A repos follow their manual/automated release process,
pointing to the `10.0.x` branch. Tags pushed to Git, and built
artifacts pushed to their registries.
9. We wait a little bit for Category A artifacts to be propagated on
registries. ~1 day.
10. Category B repos follow their manual/automated release process,
pointing to the `10.0.x` branch. Tags pushed to Git, and built
artifacts pushed to their registries.
11. Category D repos are ignored.
12. Category E repos can be manually tagged with 10.0.0 from their
default branches.
More needs to be discussed if we're planning to maintain multiple
release streams in parallel, but I guess it can wait for after Apache
KIE 10.
Thank you for reading, and I'm looking forward to hearing back from everyone.
Of course, alternative solutions are possible. This email, however,
summarizes my view of how we should attack the problem, considering
disruption, required effort, the release process itself, and history.
Feel free to propose alternatives. This is not a voting thread.
Regards,
Tiago Bento
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Jason Porter <li...@apache.org>.
+1. We need to get this unblocked for release. People are going to want to build this themselves and having a convoluted build will be a surefire way for us to get -1s on a release vote.
On 2024/03/12 19:45:09 Tiago Bento wrote:
> Hi everyone,
>
> Unfortunately, I can't do a tl;dr this time, as this matter requires a
> lot of context.
>
> This email will take you < 20 minutes to read, according to
> https://thereadtime.com/.
>
> As you may have followed on a separate thread
> (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> many of us were working towards removing a circular dependency
> currently present between `kogito-apps` and `kie-tools`. As we
> progressed towards a solution, we kept finding the circular dependency
> pop up somewhere else. I'll do a breakdown of the things we did, and
> the results we had.
>
> Right now, even though we started the effort to move the Quarkus Dev
> UI modules to `kie-tools`, we haven't been able to do it yet, as we've
> been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> effort was concluded this Monday, with
> https://github.com/apache/incubator-kie-tools/pull/2136.
>
> The current scenario we have is:
>
> 01. incubator-kie-kogito-runtimes
> |==> 02. incubator-kie-kogito-apps
> C | 03. incubator-kie-kogito-examples
> Y | 04. incubator-kie-kogito-images
> C | 05. incubator-kie-kogito-serverless-operator
> L | ==========================
> E | 06. incubator-kie-sandbox-quarkus-accelerator
> |==> 07. incubator-kie-tools
>
>
> * As `kie-tools`/extended-services depends on `kogito-apps`/jitexecutor;
> * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> `kie-tools`/{many packages}
>
>
> After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
>
> 01. incubator-kie-kogito-runtimes
> 02. incubator-kie-kogito-apps
> 03. incubator-kie-kogito-examples
> C |==> 04. incubator-kie-kogito-images
> Y | 05. incubator-kie-kogito-serverless-operator
> C | =====================
> L | 06. incubator-kie-sandbox-quarkus-accelerator
> E |==> 07. incubator-kie-tools
>
> * As `kie-tools`/kn-plugin-workflow depends on
> `kogito-images`/kogito-swf-devmode;
> * and `kogito-images`/kogito-swf-devmode depends on
> `kie-tools`/sonataflow-quarkus-devui
>
>
> After moving the `kogito-swf-devmode` image to `kie-tools`, we would've had:
>
> 01. incubator-kie-kogito-runtimes
> 02. incubator-kie-kogito-apps
> 03. incubator-kie-kogito-examples
> 04. incubator-kie-kogito-images
> C |==> 05. incubator-kie-kogito-serverless-operator
> Y | =====================
> C | 06. incubator-kie-sandbox-quarkus-accelerator
> L |==> 07. incubator-kie-tools
> E
>
> * As `kie-tools`/kn-plugin-workflow depends on
> `kogito-serverless-operator`;
> * and `kogito-serverless-operator` depends on
> `kie-tools`/kogito-swf-devmode
>
>
> Clearly, we have a much bigger problem than a simple circular dependency.
>
> After multiple conversations with a lot of people, it's been really
> hard coming up with a simple solution that makes it possible to build
> Apache KIE in one shot, while preserving the way everyone is used to
> contributing to the multiple repositories we have. More than that,
> while making this assessment, I found more problems that, in my
> perspective, block Apache KIE 10.
>
> In light of that difficulty, I'm coming forward with my proposal for
> the Apache KIE release process, so we can use Apache's mechanisms to
> have a slower-paced, in-depth debate about this really complicated
> matter.
>
> I'll lay out my entire perspective about the current situation of our
> codebase, as well as problems I can currently see. I'll start with an
> analysis of the repositories and their purposes, point out some
> problems that I believe are blocking our 10 release, explain my
> proposal and discuss some consequences to what I'm proposing.
>
> Let's begin.
>
>
> # THE APACHE KIE REPOS
>
> A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> - incubator-kie-kogito-pipelines @ `main`
> - incubator-kie-drools @ `main`
> - incubator-kie-optaplanner @ `main`
> - incubator-kie-optaplanner-quickstarts @ `main`
> - incubator-kie-kogito-runtimes @ `main`
> - incubator-kie-kogito-apps @ `main`
> - incubator-kie-kogito-examples @ `main`
> - incubator-kie-kogito-images @ `main`
> - incubator-kie-kogito-serverless-operator @ `main`
> - incubator-kie-kogito-docs @ `main`
> - incubator-kie-docs @ `main-kogito`
>
> B. TOOLS (count: 2)
> - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> - incubator-kie-tools @ `main`
>
> C. BENCHMARKS (count: 2)
> - incubator-kie-kogito-benchmarks @ `main`
> - incubator-kie-benchmarks @ `main`
>
> D. ARCHIVED (count: 1)
> - incubator-kie-kogito-operator
>
> E. "NON-CODE" (count: 5)
> - incubator-kie-issues @ `main`
> (Issues only, README should be updated @ `main`. Same for GitHub
> Actions workflows.)
> - incubator-kie-kogito-website @ `main`
> (The Kogito website. Develop & deploy at the `main` branch.)
> - incubator-kie-website @ `main`
> (The KIE website. Develop @ `main`. Push @ `deploy` to update the website.)
> - incubator-kie-kogito-online @ `gh-pages`
> (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> Extension assets.)
> - incubator-kie-kogito-online-staging @ `main`
> (Same as above, but for manual sanity checks during the staging
> phase of a release.)
>
> TOTAL (count: 21)
>
> I grouped the repositories by category, and listed them in a
> topological order. Keep in mind that when flattening out a tree, there
> are multiple possibilities. For example, OptaPlanner could've been
> placed in any position after Drools.
>
> Category A repos are what I've been referring to as `drools` and
> `kogito-*` stream. Of course OptaPlanner is inside that stream, as the
> way these repositories reference each other are through Maven
> SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This mechanism
> is well-known to the team, and although flawed for intra-day builds
> and disruptive for people in many different time zones, it is already
> very comfortable for everyone to work with, I assume.
>
> Contributions made to Category A have some dedicated pipelines, which
> are, at least to some extent, able to build cross-repo PRs together
> and verify that the codebase will continue working as expected after
> they're all merged. From what I could gather, there are some
> "sub-streams" currently configured for cross-repo PRs.
>
> - kogito-pipelines
> - drools, kogito-runtimes, kogito-apps, and kogito-examples
> - optaplanner, and optaplanner-quickstarts
> - kogito-images, and kogito-serverless-operator
> - kogito-docs
> - kie-docs
>
> This means that sending cross-repo PRs to any combination of repos
> that are not part of the same "sub-stream" cannot be verified before
> merging, making our contribution model dependent on individual
> contributors building stuff on their machines to verify that it works.
>
> I based this analysis on
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml,
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml,
> and https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml.
> Note that I'm not that familiar with these pipelines, so please
> someone correct me if I'm wrong.
>
> Category B repos are what I've been referring to as `kie-tools`
> stream. The first repo there is a template repository that is used by
> people starting projects from scratch on KIE Sandbox, similar to a
> Maven archetype, if you will. The other one is the KIE Tools monorepo,
> a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> Tools hosts Java libraries and apps, TypeScript libraries and apps, Go
> apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> configured to work with sparse checkouts and can do partial builds.
> Category B repos refer to Category A repos through timestamped
> SNAPSHOTs. This is a new mechanism we recently introduced that will
> build and publish immutable, persistent artifacts under a version
> following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> releases, as we're now targeting one release for all of Apache KIE, so
> we can't have Kogito releases anymore.
>
> An important note here is that Category B repositories have been
> historically kept out of any automations we used to have, way back
> when Kogito started and we had the Business Central (a.k.a. v7) stream
> still going on. For this reason, Category B projects have developed
> their own automations, based on GitHub Actions. Category B repos have
> always depended on Category A repos using fixed versions. If Category
> B repos have had adopted mutable SNAPSHOTs, breaking changes on
> Category A repositories would've had the potential to break Category B
> silently, leaving Category B with a broken development stream, and
> introducing unpleasant surprises for maintainers of Category B repos,
> as historically Category A contributors were not familiar with
> Category B repos.
>
> Contributions made to Category B repos go through a GitHub Actions
> workflow that builds the relevant part of the `kie-tools` monorepo for
> the changes introduced. Changes made to the pipeline itself are also
> picked up as part of PRs, allowing us to do things like atomically
> bumping the Node.js version, for example. More importantly, it allows
> us to upgrade the repository to a new timestamped SNAPSHOT together
> with the changes necessary to make it stay green.
>
> This setup, however, makes it impossible to have cross-repo PRs
> involving Category A and Category B simultaneously, with the current
> automations we have.
>
> Category C repos are kind of floating around, and I'm not sure if
> there's much activity going on there. Regardless, as they're part of
> Apache KIE, they will be part of our release, so I listed them for us
> to take them into consideration too.
>
> Category D is self explanatory. There's only one repo that has already
> been marked for being archived.
>
> Category E are repos that do not host code directly, and are either
> organizational entities, or host websites, that currently are not part
> of any pipelines we have.
>
> This lack of unification between Category A and Category B is, IMHO,
> what allowed us to introduce the infamous circular dependency between
> `kie-tools` and `kogito-apps`, which we now can describe as a circular
> dependency between Category A and Category B. The way I see it, if we
> had a single pipeline, building everything from `drools` to
> `kie-tools`, such flaws would've never been introduced, and we
> wouldn't be having this huge problem in our hands right now.
>
> My proposal for the Apache KIE release process sees this lack of
> unification as a central problem, not only for this release in
> particular, but for the community as a whole. It is my belief that we
> are all under the same roof, and that no contribution should be
> allowed to break any part of our codebase. With the increasing volume
> of code, and hopefully number of contributors too, we cannot keep
> counting on "common sense" to avoid breaking things. We're all humans
> after all, and it is our job to have mechanisms in place to prevent us
> from unwillingly making mistakes. Especially when these mistakes
> impact on parts of the codebase that we, individually, probably can't
> fix.
>
>
> # THE PROBLEMS WE HAVE RIGHT NOW
>
> P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools `0.32.0`.
> See:
> - https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
>
>
> P2. PR open for Kogito SWF images @ `kogito-images` depending on
> kiegroup's KIE Tools `0.32.0`.
> See:
> - https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
>
>
> P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> `kie-soup` artifacts at version `7.59.0.Final`.
> See:
> - https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> - https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
>
>
> P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> Explainability `1.22.1.Final`.
> * This module was removed from the KIE codebase here:
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> and now lives on
> https://github.com/trustyai-explainability/trustyai-explainability,
> under a different GAV.
> * This new repo depends on Kogito and OptaPlanner, pointing to older versions.
> See:
> - https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> - https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
>
>
> P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> `1.32.0.Final` and Quarkus `2.15.3.Final`.
> See:
> - https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
>
>
> P6. Category C repos are out of date and not part of the Category A
> CI/Release pipelines.
> * incubator-kie-kogito-benchmarks: (Current version is `2.0-SNAPSHOT`,
> depending on Kogito without a specific version, only by using
> `http://localhost:8080`)
> * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
>
>
> P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled after
> upgrading to 999-20240218-SNAPSHOT.
>
>
> In my perspective, P1 and P2 have the same solution, as they both
> suffer from the circular dependency between Category A and Category B.
> As Category A and Category B are both streams that have been really
> active, I see this as a blocker, as there are contributions that
> cannot be done, given that Category A depends on Category B with a
> dephasing of 1 release.
>
> P3 and P4, although not ideal, can be understood as technical debt.
> Depending on unmaintained projects is something we'll always be
> susceptible to, given time.
>
> P5 and P6 are easily fixable, as it's just a matter of making them
> part of the play.
>
> P7 is an isolated problem that won't impact the structure or anything
> that we're talking about here, but it is a regression we introduced
> recently.
>
> Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> and P7 have easy fixes, the only problems left to discuss are P1 and
> P2, which can't be done without a proper proposal.
>
>
> # THE PROPOSAL
>
> I'll try to be very meticulous here, since from my experience, any
> little miscalculation can lead to our release not working out in the
> end. To try and avoid that as much as possible, and make everything we
> can to have a successful Apache KIE 10 release, bear with me. I'll lay
> out a timeline of events that need to happen in order for our release
> to be published, with all artifacts ending up in the right places, but
> first, we need to solve problems P1 and P2.
>
> As you saw at the beginning of this email, all the attempts we made
> left us with the circular dependency showing up at a different place,
> but something all these places have in common is that they're all
> after kogito-apps, and before to Category B.
>
> The first part of my proposal is the following:
>
> S1. We keep the original plan of moving the Quarkus Dev UIs from
> `kogito-apps` to `kie-tools`, together with Management and Task
> consoles from `kogito-images` to `kie-tools`.
> S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> from `kogito-images` to `kie-tools` too.
> S3. We move the entire `kogito-serverless-operator` repo inside a new
> package on `kie-tools`, keeping Git history.
>
> Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> the rest of https://github.com/apache/incubator-kie-issues/issues/967
> would still be done too.
>
> This doesn't come without consequences, of course, as the
> `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> `kogito-serverless-operator` would be moving from Category A to
> Category B. This move would make them have to reference Category A
> repos through timestamped SNAPSHOTs. Since `kogito-images` and
> `kogito-serverless-operator` are already their own "sub-stream" inside
> Category A, though, contributions made in a cross-repo fashion to this
> "sub-stream" will continue being possible, now via a single PR to
> `kie-tools`. Cross-repo PRs between Category A and Category B will
> continue not being possible, and a 1-week delay between merging
> something on Category A and using it on Category B will still happen.
>
> It's worth mentioning that `kie-tools`, however, does allow for sparse
> checkouts and partial builds, so working with a subset of the monorepo
> is possible and encouraged. Making changes only to
> `packages/kn-plugin-workflow`, for example, will have the PR checks
> run in < 10 minutes, as you can see here:
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136.
> We're not compromising when running partial builds too. We know that
> the entire repo will continue working even after only building a small
> subset of the changes. Doing partial or full builds is automatically
> determined by the changes of a PR.
>
> Keep in mind that, even though I'm proposing we move a bunch of
> additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> for our codebase. `kie-tools` would host some additional stuff
> TEMPORARILY so that we can release and continue moving forward.
>
> As I mentioned on other places, `kie-tools` became a polyglot monorepo
> out of necessity, and although I'm really proud of what we achieved
> there so far, I don't think `kie-tools` has a setup that is suitable
> for all the different nuances that compose our community. I'm well
> aware that a polyglot monorepo that does not follow widespread
> conventions will scare some people away, and as much as we've tried to
> make build instructions clear, we can't always get past the prejudice
> some people have towards the "front-end" ecosystem.
>
> With all that said, I keep thinking this is the best course of action
> for us right now. We keep most of our stuff unchanged, we unblock the
> release, and we have a working setup that will suit us well while we
> discuss and reach a conclusion regarding the future of our codebase
> structure.
>
> Let me paint a quick picture here of what our code base would look
> like, repository-wise, if my proposal is accepted:
>
> CATEGORY REPO
> =====================
> A incubator-kie-kogito-pipelines
> A incubator-kie-drools
> A incubator-kie-optaplanner
> A incubator-kie-optaplanner-quickstarts
> A incubator-kie-kogito-runtimes
> A incubator-kie-kogito-apps
> A incubator-kie-kogito-examples
> A incubator-kie-kogito-images
> A incubator-kie-kogito-docs
> A incubator-kie-kogito-benchmarks
> A incubator-kie-docs
> A incubator-kie-benchmarks
> =====================
> B incubator-kie-sandbox-quarkus-accelerator
> B incubator-kie-tools
> =====================
> D incubator-kie-kogito-operator
> =====================
> E incubator-kie-issues
> E incubator-kie-kogito-website
> E incubator-kie-website
> E incubator-kie-kogito-online
> E incubator-kie-kogito-online-staging
> =====================
>
> * Category C becomes part of Category A, and
> `kogito-serverless-operator` moves entirely inside `kie-tools`.
> * With `kogito-swf-{builder,devmode}` images and
> `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> anymore, as inside `kie-tools`, we can granularly build:
> 1. packages/sonataflow-deployment-webapp
> 2. packages/sonataflow-quarkus-devui
> 3. packages/sonataflow-images (containing `kogito-swf-builder` and
> `kogito-swf-devmode`)
> 4. packages/sonataflow-operator (contents from `kogito-serverless-operator`)
> 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> but renamed)
>
> The second part of the proposal is the release process itself,
> assuming the structure above is what we have.
>
> Here it is:
>
> 1. Define a timestamped SNAPSHOT to be used as cutting point for
> Category A repos.
> 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> verify that everything is working.
> 3. At this point, with everything working, we can branch out to
> `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
> from `main`.
> 4. All Category A and Category B repos update their versions to
> 10.0.0, in their `10.0.x` branches.
> 5. Update Category B repos to point to Category A repos using the
> 10.0.0 version.
> 6. At this point, we can vote on the release based on the `10.0.x`
> branches, given we don't expect any code changes anymore.
> 7. After voting passes, we're good to start the release process.
> 8. Category A repos follow their manual/automated release process,
> pointing to the `10.0.x` branch. Tags pushed to Git, and built
> artifacts pushed to their registries.
> 9. We wait a little bit for Category A artifacts to be propagated on
> registries. ~1 day.
> 10. Category B repos follow their manual/automated release process,
> pointing to the `10.0.x` branch. Tags pushed to Git, and built
> artifacts pushed to their registries.
> 11. Category D repos are ignored.
> 12. Category E repos can be manually tagged with 10.0.0 from their
> default branches.
>
> More needs to be discussed if we're planning to maintain multiple
> release streams in parallel, but I guess it can wait for after Apache
> KIE 10.
>
> Thank you for reading, and I'm looking forward to hearing back from everyone.
>
> Of course, alternative solutions are possible. This email, however,
> summarizes my view of how we should attack the problem, considering
> disruption, required effort, the release process itself, and history.
> Feel free to propose alternatives. This is not a voting thread.
>
> Regards,
>
> Tiago Bento
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Tibor Zimányi <tz...@apache.org>.
Hi,
+1, to unblock the release.
Best regards,
Tibor
Dňa ut 12. 3. 2024, 21:44 Alex Porcelli <al...@porcelli.me> napísal(a):
> +1
>
> I spent the last day or so working closely with Tiago, exploring different
> options and getting deeper on the impact and evaluating the overall release
> procedure steps required. I agree with the proposal as the most
> viable option for unblocking the 10 release in the reasonable time frame.
>
>
> On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <ti...@apache.org> wrote:
>
> > Hi everyone,
> >
> > Unfortunately, I can't do a tl;dr this time, as this matter requires a
> > lot of context.
> >
> > This email will take you < 20 minutes to read, according to
> > https://thereadtime.com/.
> >
> > As you may have followed on a separate thread
> > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> > many of us were working towards removing a circular dependency
> > currently present between `kogito-apps` and `kie-tools`. As we
> > progressed towards a solution, we kept finding the circular dependency
> > pop up somewhere else. I'll do a breakdown of the things we did, and
> > the results we had.
> >
> > Right now, even though we started the effort to move the Quarkus Dev
> > UI modules to `kie-tools`, we haven't been able to do it yet, as we've
> > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> > effort was concluded this Monday, with
> > https://github.com/apache/incubator-kie-tools/pull/2136.
> >
> > The current scenario we have is:
> >
> > 01. incubator-kie-kogito-runtimes
> > |==> 02. incubator-kie-kogito-apps
> > C | 03. incubator-kie-kogito-examples
> > Y | 04. incubator-kie-kogito-images
> > C | 05. incubator-kie-kogito-serverless-operator
> > L | ==========================
> > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > |==> 07. incubator-kie-tools
> >
> >
> > * As `kie-tools`/extended-services depends on
> > `kogito-apps`/jitexecutor;
> > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> > `kie-tools`/{many packages}
> >
> >
> > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> >
> > 01. incubator-kie-kogito-runtimes
> > 02. incubator-kie-kogito-apps
> > 03. incubator-kie-kogito-examples
> > C |==> 04. incubator-kie-kogito-images
> > Y | 05. incubator-kie-kogito-serverless-operator
> > C | =====================
> > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > E |==> 07. incubator-kie-tools
> >
> > * As `kie-tools`/kn-plugin-workflow depends on
> > `kogito-images`/kogito-swf-devmode;
> > * and `kogito-images`/kogito-swf-devmode depends on
> > `kie-tools`/sonataflow-quarkus-devui
> >
> >
> > After moving the `kogito-swf-devmode` image to `kie-tools`, we would've
> > had:
> >
> > 01. incubator-kie-kogito-runtimes
> > 02. incubator-kie-kogito-apps
> > 03. incubator-kie-kogito-examples
> > 04. incubator-kie-kogito-images
> > C |==> 05. incubator-kie-kogito-serverless-operator
> > Y | =====================
> > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > L |==> 07. incubator-kie-tools
> > E
> >
> > * As `kie-tools`/kn-plugin-workflow depends on
> > `kogito-serverless-operator`;
> > * and `kogito-serverless-operator` depends on
> > `kie-tools`/kogito-swf-devmode
> >
> >
> > Clearly, we have a much bigger problem than a simple circular dependency.
> >
> > After multiple conversations with a lot of people, it's been really
> > hard coming up with a simple solution that makes it possible to build
> > Apache KIE in one shot, while preserving the way everyone is used to
> > contributing to the multiple repositories we have. More than that,
> > while making this assessment, I found more problems that, in my
> > perspective, block Apache KIE 10.
> >
> > In light of that difficulty, I'm coming forward with my proposal for
> > the Apache KIE release process, so we can use Apache's mechanisms to
> > have a slower-paced, in-depth debate about this really complicated
> > matter.
> >
> > I'll lay out my entire perspective about the current situation of our
> > codebase, as well as problems I can currently see. I'll start with an
> > analysis of the repositories and their purposes, point out some
> > problems that I believe are blocking our 10 release, explain my
> > proposal and discuss some consequences to what I'm proposing.
> >
> > Let's begin.
> >
> >
> > # THE APACHE KIE REPOS
> >
> > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > - incubator-kie-kogito-pipelines @ `main`
> > - incubator-kie-drools @ `main`
> > - incubator-kie-optaplanner @ `main`
> > - incubator-kie-optaplanner-quickstarts @ `main`
> > - incubator-kie-kogito-runtimes @ `main`
> > - incubator-kie-kogito-apps @ `main`
> > - incubator-kie-kogito-examples @ `main`
> > - incubator-kie-kogito-images @ `main`
> > - incubator-kie-kogito-serverless-operator @ `main`
> > - incubator-kie-kogito-docs @ `main`
> > - incubator-kie-docs @ `main-kogito`
> >
> > B. TOOLS (count: 2)
> > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > - incubator-kie-tools @ `main`
> >
> > C. BENCHMARKS (count: 2)
> > - incubator-kie-kogito-benchmarks @ `main`
> > - incubator-kie-benchmarks @ `main`
> >
> > D. ARCHIVED (count: 1)
> > - incubator-kie-kogito-operator
> >
> > E. "NON-CODE" (count: 5)
> > - incubator-kie-issues @ `main`
> > (Issues only, README should be updated @ `main`. Same for GitHub
> > Actions workflows.)
> > - incubator-kie-kogito-website @ `main`
> > (The Kogito website. Develop & deploy at the `main` branch.)
> > - incubator-kie-website @ `main`
> > (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> > website.)
> > - incubator-kie-kogito-online @ `gh-pages`
> > (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> > Extension assets.)
> > - incubator-kie-kogito-online-staging @ `main`
> > (Same as above, but for manual sanity checks during the staging
> > phase of a release.)
> >
> > TOTAL (count: 21)
> >
> > I grouped the repositories by category, and listed them in a
> > topological order. Keep in mind that when flattening out a tree, there
> > are multiple possibilities. For example, OptaPlanner could've been
> > placed in any position after Drools.
> >
> > Category A repos are what I've been referring to as `drools` and
> > `kogito-*` stream. Of course OptaPlanner is inside that stream, as the
> > way these repositories reference each other are through Maven
> > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This mechanism
> > is well-known to the team, and although flawed for intra-day builds
> > and disruptive for people in many different time zones, it is already
> > very comfortable for everyone to work with, I assume.
> >
> > Contributions made to Category A have some dedicated pipelines, which
> > are, at least to some extent, able to build cross-repo PRs together
> > and verify that the codebase will continue working as expected after
> > they're all merged. From what I could gather, there are some
> > "sub-streams" currently configured for cross-repo PRs.
> >
> > - kogito-pipelines
> > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > - optaplanner, and optaplanner-quickstarts
> > - kogito-images, and kogito-serverless-operator
> > - kogito-docs
> > - kie-docs
> >
> > This means that sending cross-repo PRs to any combination of repos
> > that are not part of the same "sub-stream" cannot be verified before
> > merging, making our contribution model dependent on individual
> > contributors building stuff on their machines to verify that it works.
> >
> > I based this analysis on
> >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > ,
> >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > ,
> > and
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > .
> > Note that I'm not that familiar with these pipelines, so please
> > someone correct me if I'm wrong.
> >
> > Category B repos are what I've been referring to as `kie-tools`
> > stream. The first repo there is a template repository that is used by
> > people starting projects from scratch on KIE Sandbox, similar to a
> > Maven archetype, if you will. The other one is the KIE Tools monorepo,
> > a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> > Tools hosts Java libraries and apps, TypeScript libraries and apps, Go
> > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> > configured to work with sparse checkouts and can do partial builds.
> > Category B repos refer to Category A repos through timestamped
> > SNAPSHOTs. This is a new mechanism we recently introduced that will
> > build and publish immutable, persistent artifacts under a version
> > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> > releases, as we're now targeting one release for all of Apache KIE, so
> > we can't have Kogito releases anymore.
> >
> > An important note here is that Category B repositories have been
> > historically kept out of any automations we used to have, way back
> > when Kogito started and we had the Business Central (a.k.a. v7) stream
> > still going on. For this reason, Category B projects have developed
> > their own automations, based on GitHub Actions. Category B repos have
> > always depended on Category A repos using fixed versions. If Category
> > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > Category A repositories would've had the potential to break Category B
> > silently, leaving Category B with a broken development stream, and
> > introducing unpleasant surprises for maintainers of Category B repos,
> > as historically Category A contributors were not familiar with
> > Category B repos.
> >
> > Contributions made to Category B repos go through a GitHub Actions
> > workflow that builds the relevant part of the `kie-tools` monorepo for
> > the changes introduced. Changes made to the pipeline itself are also
> > picked up as part of PRs, allowing us to do things like atomically
> > bumping the Node.js version, for example. More importantly, it allows
> > us to upgrade the repository to a new timestamped SNAPSHOT together
> > with the changes necessary to make it stay green.
> >
> > This setup, however, makes it impossible to have cross-repo PRs
> > involving Category A and Category B simultaneously, with the current
> > automations we have.
> >
> > Category C repos are kind of floating around, and I'm not sure if
> > there's much activity going on there. Regardless, as they're part of
> > Apache KIE, they will be part of our release, so I listed them for us
> > to take them into consideration too.
> >
> > Category D is self explanatory. There's only one repo that has already
> > been marked for being archived.
> >
> > Category E are repos that do not host code directly, and are either
> > organizational entities, or host websites, that currently are not part
> > of any pipelines we have.
> >
> > This lack of unification between Category A and Category B is, IMHO,
> > what allowed us to introduce the infamous circular dependency between
> > `kie-tools` and `kogito-apps`, which we now can describe as a circular
> > dependency between Category A and Category B. The way I see it, if we
> > had a single pipeline, building everything from `drools` to
> > `kie-tools`, such flaws would've never been introduced, and we
> > wouldn't be having this huge problem in our hands right now.
> >
> > My proposal for the Apache KIE release process sees this lack of
> > unification as a central problem, not only for this release in
> > particular, but for the community as a whole. It is my belief that we
> > are all under the same roof, and that no contribution should be
> > allowed to break any part of our codebase. With the increasing volume
> > of code, and hopefully number of contributors too, we cannot keep
> > counting on "common sense" to avoid breaking things. We're all humans
> > after all, and it is our job to have mechanisms in place to prevent us
> > from unwillingly making mistakes. Especially when these mistakes
> > impact on parts of the codebase that we, individually, probably can't
> > fix.
> >
> >
> > # THE PROBLEMS WE HAVE RIGHT NOW
> >
> > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> > `0.32.0`.
> > See:
> > -
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> >
> >
> > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > kiegroup's KIE Tools `0.32.0`.
> > See:
> > -
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> >
> >
> > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> > `kie-soup` artifacts at version `7.59.0.Final`.
> > See:
> > -
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > -
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> >
> >
> > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > Explainability `1.22.1.Final`.
> > * This module was removed from the KIE codebase here:
> >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > and now lives on
> > https://github.com/trustyai-explainability/trustyai-explainability,
> > under a different GAV.
> > * This new repo depends on Kogito and OptaPlanner, pointing to older
> > versions.
> > See:
> > -
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > -
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> >
> >
> > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > See:
> > -
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> >
> >
> > P6. Category C repos are out of date and not part of the Category A
> > CI/Release pipelines.
> > * incubator-kie-kogito-benchmarks: (Current version is `2.0-SNAPSHOT`,
> > depending on Kogito without a specific version, only by using
> > `http://localhost:8080`)
> > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
> >
> >
> > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled after
> > upgrading to 999-20240218-SNAPSHOT.
> >
> >
> > In my perspective, P1 and P2 have the same solution, as they both
> > suffer from the circular dependency between Category A and Category B.
> > As Category A and Category B are both streams that have been really
> > active, I see this as a blocker, as there are contributions that
> > cannot be done, given that Category A depends on Category B with a
> > dephasing of 1 release.
> >
> > P3 and P4, although not ideal, can be understood as technical debt.
> > Depending on unmaintained projects is something we'll always be
> > susceptible to, given time.
> >
> > P5 and P6 are easily fixable, as it's just a matter of making them
> > part of the play.
> >
> > P7 is an isolated problem that won't impact the structure or anything
> > that we're talking about here, but it is a regression we introduced
> > recently.
> >
> > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> > and P7 have easy fixes, the only problems left to discuss are P1 and
> > P2, which can't be done without a proper proposal.
> >
> >
> > # THE PROPOSAL
> >
> > I'll try to be very meticulous here, since from my experience, any
> > little miscalculation can lead to our release not working out in the
> > end. To try and avoid that as much as possible, and make everything we
> > can to have a successful Apache KIE 10 release, bear with me. I'll lay
> > out a timeline of events that need to happen in order for our release
> > to be published, with all artifacts ending up in the right places, but
> > first, we need to solve problems P1 and P2.
> >
> > As you saw at the beginning of this email, all the attempts we made
> > left us with the circular dependency showing up at a different place,
> > but something all these places have in common is that they're all
> > after kogito-apps, and before to Category B.
> >
> > The first part of my proposal is the following:
> >
> > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > `kogito-apps` to `kie-tools`, together with Management and Task
> > consoles from `kogito-images` to `kie-tools`.
> > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> > from `kogito-images` to `kie-tools` too.
> > S3. We move the entire `kogito-serverless-operator` repo inside a new
> > package on `kie-tools`, keeping Git history.
> >
> > Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> > the rest of https://github.com/apache/incubator-kie-issues/issues/967
> > would still be done too.
> >
> > This doesn't come without consequences, of course, as the
> > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > `kogito-serverless-operator` would be moving from Category A to
> > Category B. This move would make them have to reference Category A
> > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > `kogito-serverless-operator` are already their own "sub-stream" inside
> > Category A, though, contributions made in a cross-repo fashion to this
> > "sub-stream" will continue being possible, now via a single PR to
> > `kie-tools`. Cross-repo PRs between Category A and Category B will
> > continue not being possible, and a 1-week delay between merging
> > something on Category A and using it on Category B will still happen.
> >
> > It's worth mentioning that `kie-tools`, however, does allow for sparse
> > checkouts and partial builds, so working with a subset of the monorepo
> > is possible and encouraged. Making changes only to
> > `packages/kn-plugin-workflow`, for example, will have the PR checks
> > run in < 10 minutes, as you can see here:
> >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > .
> > We're not compromising when running partial builds too. We know that
> > the entire repo will continue working even after only building a small
> > subset of the changes. Doing partial or full builds is automatically
> > determined by the changes of a PR.
> >
> > Keep in mind that, even though I'm proposing we move a bunch of
> > additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> > for our codebase. `kie-tools` would host some additional stuff
> > TEMPORARILY so that we can release and continue moving forward.
> >
> > As I mentioned on other places, `kie-tools` became a polyglot monorepo
> > out of necessity, and although I'm really proud of what we achieved
> > there so far, I don't think `kie-tools` has a setup that is suitable
> > for all the different nuances that compose our community. I'm well
> > aware that a polyglot monorepo that does not follow widespread
> > conventions will scare some people away, and as much as we've tried to
> > make build instructions clear, we can't always get past the prejudice
> > some people have towards the "front-end" ecosystem.
> >
> > With all that said, I keep thinking this is the best course of action
> > for us right now. We keep most of our stuff unchanged, we unblock the
> > release, and we have a working setup that will suit us well while we
> > discuss and reach a conclusion regarding the future of our codebase
> > structure.
> >
> > Let me paint a quick picture here of what our code base would look
> > like, repository-wise, if my proposal is accepted:
> >
> > CATEGORY REPO
> > =====================
> > A incubator-kie-kogito-pipelines
> > A incubator-kie-drools
> > A incubator-kie-optaplanner
> > A incubator-kie-optaplanner-quickstarts
> > A incubator-kie-kogito-runtimes
> > A incubator-kie-kogito-apps
> > A incubator-kie-kogito-examples
> > A incubator-kie-kogito-images
> > A incubator-kie-kogito-docs
> > A incubator-kie-kogito-benchmarks
> > A incubator-kie-docs
> > A incubator-kie-benchmarks
> > =====================
> > B incubator-kie-sandbox-quarkus-accelerator
> > B incubator-kie-tools
> > =====================
> > D incubator-kie-kogito-operator
> > =====================
> > E incubator-kie-issues
> > E incubator-kie-kogito-website
> > E incubator-kie-website
> > E incubator-kie-kogito-online
> > E incubator-kie-kogito-online-staging
> > =====================
> >
> > * Category C becomes part of Category A, and
> > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > * With `kogito-swf-{builder,devmode}` images and
> > `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> > anymore, as inside `kie-tools`, we can granularly build:
> > 1. packages/sonataflow-deployment-webapp
> > 2. packages/sonataflow-quarkus-devui
> > 3. packages/sonataflow-images (containing `kogito-swf-builder` and
> > `kogito-swf-devmode`)
> > 4. packages/sonataflow-operator (contents from
> > `kogito-serverless-operator`)
> > 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> > but renamed)
> >
> > The second part of the proposal is the release process itself,
> > assuming the structure above is what we have.
> >
> > Here it is:
> >
> > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > Category A repos.
> > 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> > verify that everything is working.
> > 3. At this point, with everything working, we can branch out to
> > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
> > from `main`.
> > 4. All Category A and Category B repos update their versions to
> > 10.0.0, in their `10.0.x` branches.
> > 5. Update Category B repos to point to Category A repos using the
> > 10.0.0 version.
> > 6. At this point, we can vote on the release based on the `10.0.x`
> > branches, given we don't expect any code changes anymore.
> > 7. After voting passes, we're good to start the release process.
> > 8. Category A repos follow their manual/automated release process,
> > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > artifacts pushed to their registries.
> > 9. We wait a little bit for Category A artifacts to be propagated on
> > registries. ~1 day.
> > 10. Category B repos follow their manual/automated release process,
> > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > artifacts pushed to their registries.
> > 11. Category D repos are ignored.
> > 12. Category E repos can be manually tagged with 10.0.0 from their
> > default branches.
> >
> > More needs to be discussed if we're planning to maintain multiple
> > release streams in parallel, but I guess it can wait for after Apache
> > KIE 10.
> >
> > Thank you for reading, and I'm looking forward to hearing back from
> > everyone.
> >
> > Of course, alternative solutions are possible. This email, however,
> > summarizes my view of how we should attack the problem, considering
> > disruption, required effort, the release process itself, and history.
> > Feel free to propose alternatives. This is not a voting thread.
> >
> > Regards,
> >
> > Tiago Bento
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <al...@porcelli.me>.
Ricardo,
Images are not broken because of the circular dependency exists between
apps and tools. Once the ui from apps repo is moved to KIE tools, there is
no more snapshots being published. Thus the reason I’m concerned about
broken CI.
Regards,
_____________
Alex Porcelli
http://porcelli.me
On Wed, Mar 13, 2024 at 9:57 AM ricardo zanini fernandes <
ricardozanini@gmail.com> wrote:
> Nothing will be broken. The operator doesn't need anything from tooling to
> work, as the images. We always used snapshots/last released versions in
> Cloud.
>
> On Wed, Mar 13, 2024 at 10:55 AM Alex Porcelli <al...@porcelli.me> wrote:
>
> > Ricardo,
> >
> > In this case, as soon as we merge the UI move to KIE tools, the images
> and
> > operators build will be permanently broken until post release. Or Am I
> > missing something?
> >
> >
> > On Wed, Mar 13, 2024 at 9:52 AM ricardo zanini fernandes <
> > ricardozanini@gmail.com> wrote:
> >
> > > Alex, we simply copy the code to tools and do the release. I propose to
> > not
> > > start adding contributions from operator/images to tools.
> > >
> > > On Wed, Mar 13, 2024 at 10:41 AM Alex Porcelli <al...@porcelli.me>
> wrote:
> > >
> > > > Ricardo,
> > > >
> > > > I think it's more than fair to ask to preserve the original repos, as
> > > > this solution is proposed as TEMPORARY.
> > > >
> > > > However, the devil is in the details.... could you expand a bit in
> > > > steps how you see the COPYING and the contributions still flow to the
> > > > right repos work?
> > > >
> > > > btw; I don't think we should account for fear or feelings about
> > > > things.. We should focus on plans and facts.
> > > >
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 9:14 AM ricardo zanini fernandes
> > > > <ri...@gmail.com> wrote:
> > > > >
> > > > > Hi!
> > > > >
> > > > > Clearly, you all understand that moving images and the operator to
> > > > > kie-tools is a workaround and wrong in all possible scenarios,
> right?
> > > We
> > > > > won't undo once we merge. I'm pretty positive that once we have a
> > > release
> > > > > train going people will add all the obstacles they can add saying
> > "It's
> > > > > working, let's not change it".
> > > > >
> > > > > Also, I understand that we need to unblock the release. We can
> > > compromise
> > > > > in COPYING the code, do the release, and then make the necessary
> > > changes.
> > > > > Images and cloud code are *integration platforms*. Should be the
> last
> > > in
> > > > a
> > > > > stream. Tooling SHOULD NOT, in any case, depend on the images to
> > build.
> > > > >
> > > > > So we can:
> > > > >
> > > > > 1. Accept Tiago's proposal (very well detailed, thanks!) but
> COPYING
> > > the
> > > > > code base, not MERGING. The contributions still flow to the right
> > > repos.
> > > > > 2. After release we:
> > > > > 1. Move the CLI to the operator repo, removing this dependency
> > from
> > > > > tools to image
> > > > > 2. Adjust the CI
> > > > > 3. Remove the copied code
> > > > >
> > > > > Moving forward, I'd like to see a clear boundary between the
> projects
> > > (as
> > > > > stated in the temporary website). At the moment, we do not have.
> And
> > > it's
> > > > > hard for anyone from outside to understand what we are doing.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > >
> > > > > > Francisco and Gabriele,
> > > > > >
> > > > > > I understand and acknowledge your desire to find the “right”
> > solution
> > > > > > instead to work on a temporary “patch” - however without a
> detailed
> > > > > > proposal I don’t think we can properly evaluate the impact of
> your
> > > > > > suggestion.
> > > > > >
> > > > > > When I spoke with different SMEs that included tools and CI, the
> > > > > > guesstimate for making the necessary changes on CI and codebase
> to
> > > > > > basically have images and operators in the end of the build chain
> > is
> > > > > > something like 2 months of effort. Another impact that needs to
> be
> > > > > > discussed is that KIE Tools repo had to be injected in the middle
> > of
> > > > all
> > > > > > pipelines - forcing all PR checks and nightlies to build all
> repos
> > > (PR
> > > > > > checks will likely take 12+ hours… I even heard that it could be
> > even
> > > > 24
> > > > > > hours).
> > > > > >
> > > > > > Based on the input above, I think it’s quite risk to move in such
> > > > direction
> > > > > > without a more detailed plan… because 2 months could be turned
> > easily
> > > > in 6!
> > > > > > And this is exactly what happened when we guessed that moving to
> > > Apache
> > > > > > would take no more than 3 months. But here we are.
> > > > > >
> > > > > > I really strongly suggest that we focus on a release that could
> be
> > > > > > achievable in less than a month from now, and we - after release
> -
> > > > have a
> > > > > > in depth discussion about the overall codebase and ci
> organization.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > > gabriele.cardosi@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Alex,
> > > > > > > my suggestion is to move the building of all docker images,
> from
> > > > whatever
> > > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo,
> to
> > > be
> > > > > > > invoked after all the others.
> > > > > > > I'm not sure if this would solve all the issues, and since I
> > could
> > > > not
> > > > > > > enter in the details of all the involved code, my suggestion
> may
> > be
> > > > too
> > > > > > > naive.
> > > > > > > Having spent almost all of the last year in CI, I may say
> that,
> > at
> > > > least
> > > > > > > for the kie-tools repo, removing the image build step from it
> > > should
> > > > not
> > > > > > be
> > > > > > > too difficult (since it is an issue we already faced and
> solved).
> > > > > > > If, with "detailed proposal", you mean a complete list of all
> > > > modules to
> > > > > > be
> > > > > > > moved and dependency refactoring, of course I can not provide
> it
> > > > right
> > > > > > now.
> > > > > > >
> > > > > > > Anyway, I share the concern from Francisco: undoing something
> is
> > > > almost
> > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier
> Tirado
> > > > Sarti <
> > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > >
> > > > > > > > I do not think estimations should be the only driver to make
> a
> > > > > > decision,
> > > > > > > > especially when the current proposal is conceptually
> > incompatible
> > > > with
> > > > > > > the
> > > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > > Given my knowledge of the CI it is nearly impossible for me
> to
> > > > give a
> > > > > > > fair
> > > > > > > > estimate of how much it might take to achieve step 2) of my
> > > > previous
> > > > > > > e-mail
> > > > > > > > . It might take a while or it might be pretty easy after
> all, I
> > > > don't
> > > > > > > > really know, but I think it will be a good idea if some of
> the
> > > > experts
> > > > > > > on
> > > > > > > > CI in the team (the ones that set up the pipeline, which was
> a
> > > huge
> > > > > > > > achievement) give an estimate, not me. Estimating how much
> it
> > > > takes to
> > > > > > > > merge two existing repos (without altering CI) is easier, but
> > it
> > > > does
> > > > > > not
> > > > > > > > mean we are doing the right thing.
> > > > > > > > My main concern is that it will be very difficult for me to
> > > > explain to
> > > > > > > > someone that arrives new to the team, that having experts on
> CI
> > > on
> > > > the
> > > > > > > > team, we decided to merge two repos (once merged, it would be
> > > > rather
> > > > > > > > difficult to unmerge) rather than fix the CI, because of
> > > > expediency.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > > porcelli@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco,
> > > > > > > > >
> > > > > > > > > Please take the time to make the more in depth analysis
> > needed
> > > > and
> > > > > > > > provide
> > > > > > > > > a more detailed plan… so we - as community- can evaluate
> the
> > > > size of
> > > > > > > the
> > > > > > > > > effort. In the conceptual level you shared it’s near
> > impossible
> > > > to
> > > > > > > > estimate
> > > > > > > > > the size of the effort and compare with the current
> proposal.
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado
> > Sarti <
> > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > 1) Remove all dependencies from tooling to images, so
> > images
> > > > > > depend
> > > > > > > on
> > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > 2) Then change CI to deal with tooling repo before
> dealing
> > > with
> > > > > > > images
> > > > > > > > > > repo.
> > > > > > > > > > I understand that CI details are tricky and since I'm not
> > > > familiar
> > > > > > > with
> > > > > > > > > CI
> > > > > > > > > > in any way, I barely can make a low level design, but we
> do
> > > not
> > > > > > need
> > > > > > > to
> > > > > > > > > fix
> > > > > > > > > > everything, just achieve 2), a change of compilation
> order.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > > > alex@porcelli.me>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > >
> > > > > > > > > > > You may not like or understand why the current state of
> > the
> > > > CI is
> > > > > > > > like
> > > > > > > > > > > that… actually has been in Red Hat and has been
> > replicated
> > > in
> > > > > > > Apache
> > > > > > > > as
> > > > > > > > > > > used to be….
> > > > > > > > > > >
> > > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > > >
> > > > > > > > > > > If you disagree with the current plan, please provide a
> > > > detailed
> > > > > > > > > > > alternative so we, as community, can better evaluate
> the
> > > > pros and
> > > > > > > > cons
> > > > > > > > > of
> > > > > > > > > > > each proposal.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I think it’s also fair to say that, post 10 release we
> > need
> > > > to
> > > > > > > have a
> > > > > > > > > > much
> > > > > > > > > > > in depth discussion about how our codebase is
> organized,
> > > it’s
> > > > > > clear
> > > > > > > > > that
> > > > > > > > > > > it’s not working.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > I also have the impression that the "images" (if we
> are
> > > > talking
> > > > > > > of
> > > > > > > > > > docker
> > > > > > > > > > > > images) should be the very last one to be built, in a
> > > > > > standalone
> > > > > > > > > repo.
> > > > > > > > > > > > That way, they may "combine" artifacts that are built
> > in
> > > > > > > different
> > > > > > > > > > repos,
> > > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > > Moving them out of all the repos
> > (kogito-apps/kie-tools)
> > > > maybe
> > > > > > > > could
> > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > (I also think there are some statements of
> undisputable
> > > > needs
> > > > > > > while
> > > > > > > > > > they
> > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > > > discussion.)
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco
> > Javier
> > > > > > Tirado
> > > > > > > > > Sarti
> > > > > > > > > > <
> > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > >
> > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > There are two assumptions that deserve further
> > > > discussion:
> > > > > > > > > > > > > 1) That tool has to be the last to build. why? it
> > does
> > > > not
> > > > > > have
> > > > > > > > > more
> > > > > > > > > > > > sense
> > > > > > > > > > > > > to build final images after everything else has
> been
> > > > built?-
> > > > > > > > > > > > > 2) That the impact (in terms of effort now) on
> fixing
> > > CI
> > > > is
> > > > > > > > bigger
> > > > > > > > > > than
> > > > > > > > > > > > the
> > > > > > > > > > > > > impact (long term consequences) of consolidating
> two
> > > > > > unrelated
> > > > > > > > > piece
> > > > > > > > > > of
> > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > > alex@porcelli.me
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This was discussed as an alternative solution,
> > > however
> > > > it
> > > > > > has
> > > > > > > > > major
> > > > > > > > > > > > > impact
> > > > > > > > > > > > > > on CI and there’s also the fact Tool has been
> > always
> > > > the
> > > > > > last
> > > > > > > > to
> > > > > > > > > > > build
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> > > world
> > > > > > there
> > > > > > > > is
> > > > > > > > > no
> > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So, based on our evaluation… the proposal here is
> > the
> > > > least
> > > > > > > > > > > disruptive
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> > > Tirado
> > > > > > > Sarti <
> > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > > embracing
> > > > the
> > > > > > > fact
> > > > > > > > > > that
> > > > > > > > > > > > > > > kogito-images depend on kie-tools, because we
> > want
> > > > those
> > > > > > > > images
> > > > > > > > > > to
> > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco
> Javier
> > > > Tirado
> > > > > > > > Sarti
> > > > > > > > > <
> > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > > kn-plugin-workflow
> > > > > > > > > to
> > > > > > > > > > > > > > > > kogito-images (so there is not longer
> > dependency
> > > > from
> > > > > > > tools
> > > > > > > > > to
> > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique
> > Gonzalez
> > > > > > > Martinez
> > > > > > > > <
> > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > > > (apache) <
> > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> > I say +1 in order to move forward with the
> > 10.
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex
> Porcelli
> > <
> > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > I spent the last day or so working
> closely
> > > > with
> > > > > > > Tiago,
> > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > >> > > options and getting deeper on the impact
> > and
> > > > > > > > evaluating
> > > > > > > > > > the
> > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > >> > > procedure steps required. I agree with
> the
> > > > > > proposal
> > > > > > > as
> > > > > > > > > the
> > > > > > > > > > > > most
> > > > > > > > > > > > > > > >> > > viable option for unblocking the 10
> > release
> > > > in the
> > > > > > > > > > > reasonable
> > > > > > > > > > > > > time
> > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago
> > Bento
> > > <
> > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> > > > time, as
> > > > > > > this
> > > > > > > > > > > matter
> > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes
> to
> > > > read,
> > > > > > > > > according
> > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > > > thread
> > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > >
> > > > > > > >
> > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > >> > > > many of us were working towards
> > removing a
> > > > > > > circular
> > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > >> > > > currently present between
> `kogito-apps`
> > > and
> > > > > > > > > `kie-tools`.
> > > > > > > > > > > As
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > > > finding
> > > > > > the
> > > > > > > > > > > circular
> > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > breakdown
> > > > of
> > > > > > the
> > > > > > > > > things
> > > > > > > > > > > we
> > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Right now, even though we started the
> > > > effort to
> > > > > > > move
> > > > > > > > > the
> > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't
> > been
> > > > able
> > > > > > to
> > > > > > > > do
> > > > > > > > > it
> > > > > > > > > > > > yet,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java
> > 17,
> > > > Maven
> > > > > > > > 3.9.6,
> > > > > > > > > > and
> > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > .
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > |==> 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > C | 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > L |
> > ==========================
> > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/extended-services
> > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > > `kie-tools`,
> > > > > > > we
> > > > > > > > > > > would've
> > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > 02.
> > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > 03.
> > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > > `kie-tools`/kn-plugin-workflow
> > > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > >> > > > * and
> > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > depends
> > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> > > image
> > > > to
> > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > 02.
> > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > 03.
> > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > > `kie-tools`/kn-plugin-workflow
> > > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > >> > > > * and
> > `kogito-serverless-operator`
> > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> > > than
> > > > a
> > > > > > > simple
> > > > > > > > > > > > circular
> > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After multiple conversations with a
> lot
> > of
> > > > > > people,
> > > > > > > > > it's
> > > > > > > > > > > been
> > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > >> > > > hard coming up with a simple solution
> > that
> > > > makes
> > > > > > > it
> > > > > > > > > > > possible
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while
> preserving
> > > > the way
> > > > > > > > > > everyone
> > > > > > > > > > > is
> > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > contributing to the multiple
> > repositories
> > > we
> > > > > > have.
> > > > > > > > > More
> > > > > > > > > > > than
> > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > >> > > > while making this assessment, I found
> > more
> > > > > > > problems
> > > > > > > > > > that,
> > > > > > > > > > > in
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm
> coming
> > > > forward
> > > > > > > with
> > > > > > > > > my
> > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we
> > can
> > > > use
> > > > > > > > Apache's
> > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate
> > about
> > > > this
> > > > > > > > really
> > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective
> about
> > > the
> > > > > > > current
> > > > > > > > > > > > situation
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > > > currently
> > > > > > see.
> > > > > > > > > I'll
> > > > > > > > > > > > start
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > > purposes,
> > > > > > > > point
> > > > > > > > > > out
> > > > > > > > > > > > > some
> > > > > > > > > > > > > > > >> > > > problems that I believe are blocking
> our
> > > 10
> > > > > > > release,
> > > > > > > > > > > explain
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > >> > > > proposal and discuss some consequences
> > to
> > > > what
> > > > > > I'm
> > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO
> (count:
> > > 11)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @
> > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > > >> > > > -
> incubator-kie-optaplanner-quickstarts
> > @
> > > > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-serverless-operator @
> > > > > > > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-sandbox-quarkus-accelerator
> > > > @
> > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @
> > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > > updated @
> > > > > > > `main`.
> > > > > > > > > > Same
> > > > > > > > > > > > for
> > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @
> `main`
> > > > > > > > > > > > > > > >> > > > (The Kogito website. Develop &
> > deploy
> > > > at the
> > > > > > > > > `main`
> > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > > >> > > > (The KIE website. Develop @
> `main`.
> > > > Push @
> > > > > > > > > `deploy`
> > > > > > > > > > to
> > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> > `gh-pages`
> > > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > sandbox.kie.org
> > > > > > > and
> > > > > > > > > KIE
> > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging
> @
> > > > `main`
> > > > > > > > > > > > > > > >> > > > (Same as above, but for manual
> > sanity
> > > > checks
> > > > > > > > > during
> > > > > > > > > > > the
> > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I grouped the repositories by
> category,
> > > and
> > > > > > listed
> > > > > > > > > them
> > > > > > > > > > > in a
> > > > > > > > > > > > > > > >> > > > topological order. Keep in mind that
> > when
> > > > > > > flattening
> > > > > > > > > > out a
> > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > >> > > > are multiple possibilities. For
> example,
> > > > > > > OptaPlanner
> > > > > > > > > > > > could've
> > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > > > referring to
> > > > > > > as
> > > > > > > > > > > `drools`
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> OptaPlanner
> > > is
> > > > > > inside
> > > > > > > > > that
> > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > way these repositories reference each
> > > other
> > > > are
> > > > > > > > > through
> > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > > > 999-SNAPSHOT
> > > > > > > > > version.
> > > > > > > > > > > This
> > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > >> > > > is well-known to the team, and
> although
> > > > flawed
> > > > > > for
> > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > > different
> > > > time
> > > > > > > > > zones,
> > > > > > > > > > it
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> > > with,
> > > > I
> > > > > > > > assume.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Contributions made to Category A have
> > some
> > > > > > > dedicated
> > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> > > build
> > > > > > > > cross-repo
> > > > > > > > > > PRs
> > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > >> > > > and verify that the codebase will
> > continue
> > > > > > working
> > > > > > > > as
> > > > > > > > > > > > expected
> > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > > > gather,
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > > some
> > > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > > > cross-repo
> > > > > > > > PRs.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> kogito-apps,
> > > and
> > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > >> > > > - optaplanner, and
> > optaplanner-quickstarts
> > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs
> > to
> > > > any
> > > > > > > > > > combination
> > > > > > > > > > > of
> > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > >> > > > that are not part of the same
> > "sub-stream"
> > > > > > cannot
> > > > > > > be
> > > > > > > > > > > > verified
> > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > > dependent
> > > > > > > on
> > > > > > > > > > > > individual
> > > > > > > > > > > > > > > >> > > > contributors building stuff on their
> > > > machines to
> > > > > > > > > verify
> > > > > > > > > > > that
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with
> > these
> > > > > > > > pipelines,
> > > > > > > > > so
> > > > > > > > > > > > > please
> > > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > > > referring to
> > > > > > > as
> > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > >> > > > stream. The first repo there is a
> > template
> > > > > > > > repository
> > > > > > > > > > that
> > > > > > > > > > > > is
> > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > >> > > > people starting projects from scratch
> on
> > > KIE
> > > > > > > > Sandbox,
> > > > > > > > > > > > similar
> > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The
> other
> > > one
> > > > is
> > > > > > the
> > > > > > > > KIE
> > > > > > > > > > > Tools
> > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> > > build
> > > > > > > system.
> > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > > TypeScript
> > > > > > > > > > libraries
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts.
> > The
> > > > > > > > `kie-tools`
> > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > >> > > > configured to work with sparse
> checkouts
> > > > and can
> > > > > > > do
> > > > > > > > > > > partial
> > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > >> > > > Category B repos refer to Category A
> > repos
> > > > > > through
> > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > > > recently
> > > > > > > > > > introduced
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > >> > > > build and publish immutable,
> persistent
> > > > > > artifacts
> > > > > > > > > under
> > > > > > > > > > a
> > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> > > format,
> > > > > > > > published
> > > > > > > > > > > weekly
> > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs
> are
> > an
> > > > > > > evolution
> > > > > > > > > to
> > > > > > > > > > > the
> > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > > > release for
> > > > > > > all
> > > > > > > > > of
> > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > An important note here is that
> Category
> > B
> > > > > > > > repositories
> > > > > > > > > > > have
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > > >> > > > historically kept out of any
> automations
> > > we
> > > > used
> > > > > > > to
> > > > > > > > > > have,
> > > > > > > > > > > > way
> > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > > Business
> > > > > > > Central
> > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > >> > > > still going on. For this reason,
> > Category
> > > B
> > > > > > > projects
> > > > > > > > > > have
> > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > > Actions.
> > > > > > > > > > Category B
> > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > >> > > > always depended on Category A repos
> > using
> > > > fixed
> > > > > > > > > > versions.
> > > > > > > > > > > If
> > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > > SNAPSHOTs,
> > > > > > > breaking
> > > > > > > > > > > changes
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > Category A repositories would've had
> the
> > > > > > potential
> > > > > > > > to
> > > > > > > > > > > break
> > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > >> > > > silently, leaving Category B with a
> > broken
> > > > > > > > development
> > > > > > > > > > > > stream,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > > maintainers
> > > > > > > of
> > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > >> > > > as historically Category A
> contributors
> > > > were not
> > > > > > > > > > familiar
> > > > > > > > > > > > with
> > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Contributions made to Category B repos
> > go
> > > > > > through
> > > > > > > a
> > > > > > > > > > GitHub
> > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > >> > > > workflow that builds the relevant part
> > of
> > > > the
> > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > >> > > > the changes introduced. Changes made
> to
> > > the
> > > > > > > pipeline
> > > > > > > > > > > itself
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us
> to
> > > do
> > > > > > things
> > > > > > > > > like
> > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> > example.
> > > > More
> > > > > > > > > > > importantly,
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > > > timestamped
> > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > >> > > > with the changes necessary to make it
> > stay
> > > > > > green.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This setup, however, makes it
> impossible
> > > to
> > > > have
> > > > > > > > > > > cross-repo
> > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > > simultaneously,
> > > > > > > > > with
> > > > > > > > > > > the
> > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > > > around,
> > > > > > and
> > > > > > > > I'm
> > > > > > > > > > not
> > > > > > > > > > > > sure
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > > > Regardless,
> > > > > > > as
> > > > > > > > > > > they're
> > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > > > release,
> > > > > > so I
> > > > > > > > > > listed
> > > > > > > > > > > > them
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category D is self explanatory.
> There's
> > > > only one
> > > > > > > > repo
> > > > > > > > > > that
> > > > > > > > > > > > has
> > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category E are repos that do not host
> > code
> > > > > > > directly,
> > > > > > > > > and
> > > > > > > > > > > are
> > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > >> > > > organizational entities, or host
> > websites,
> > > > that
> > > > > > > > > > currently
> > > > > > > > > > > > are
> > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This lack of unification between
> > Category
> > > A
> > > > and
> > > > > > > > > > Category B
> > > > > > > > > > > > is,
> > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> > infamous
> > > > > > circular
> > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which
> we
> > > now
> > > > can
> > > > > > > > > describe
> > > > > > > > > > > as
> > > > > > > > > > > > a
> > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > >> > > > dependency between Category A and
> > Category
> > > > B.
> > > > > > The
> > > > > > > > way
> > > > > > > > > I
> > > > > > > > > > > see
> > > > > > > > > > > > > it,
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > had a single pipeline, building
> > everything
> > > > from
> > > > > > > > > `drools`
> > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> > > been
> > > > > > > > > introduced,
> > > > > > > > > > > and
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem
> in
> > > our
> > > > > > hands
> > > > > > > > > right
> > > > > > > > > > > now.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > > > process
> > > > > > > sees
> > > > > > > > > this
> > > > > > > > > > > > lack
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > unification as a central problem, not
> > only
> > > > for
> > > > > > > this
> > > > > > > > > > > release
> > > > > > > > > > > > in
> > > > > > > > > > > > > > > >> > > > particular, but for the community as a
> > > > whole. It
> > > > > > > is
> > > > > > > > my
> > > > > > > > > > > > belief
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > are all under the same roof, and that
> no
> > > > > > > > contribution
> > > > > > > > > > > should
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > >> > > > allowed to break any part of our
> > codebase.
> > > > With
> > > > > > > the
> > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > > > contributors
> > > > > > too,
> > > > > > > > we
> > > > > > > > > > > cannot
> > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> > > breaking
> > > > > > > things.
> > > > > > > > > > We're
> > > > > > > > > > > > all
> > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > > mechanisms
> > > > > > in
> > > > > > > > > place
> > > > > > > > > > > to
> > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> > > Especially
> > > > > > when
> > > > > > > > > these
> > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > >> > > > impact on parts of the codebase that
> we,
> > > > > > > > individually,
> > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > > > depending on
> > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > > > `kogito-images`
> > > > > > > > > > > > depending
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools`
> depending
> > on
> > > > > > > > kiegroup's
> > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by ricardo zanini fernandes <ri...@gmail.com>.
Nothing will be broken. The operator doesn't need anything from tooling to
work, as the images. We always used snapshots/last released versions in
Cloud.
On Wed, Mar 13, 2024 at 10:55 AM Alex Porcelli <al...@porcelli.me> wrote:
> Ricardo,
>
> In this case, as soon as we merge the UI move to KIE tools, the images and
> operators build will be permanently broken until post release. Or Am I
> missing something?
>
>
> On Wed, Mar 13, 2024 at 9:52 AM ricardo zanini fernandes <
> ricardozanini@gmail.com> wrote:
>
> > Alex, we simply copy the code to tools and do the release. I propose to
> not
> > start adding contributions from operator/images to tools.
> >
> > On Wed, Mar 13, 2024 at 10:41 AM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > Ricardo,
> > >
> > > I think it's more than fair to ask to preserve the original repos, as
> > > this solution is proposed as TEMPORARY.
> > >
> > > However, the devil is in the details.... could you expand a bit in
> > > steps how you see the COPYING and the contributions still flow to the
> > > right repos work?
> > >
> > > btw; I don't think we should account for fear or feelings about
> > > things.. We should focus on plans and facts.
> > >
> > >
> > >
> > > On Wed, Mar 13, 2024 at 9:14 AM ricardo zanini fernandes
> > > <ri...@gmail.com> wrote:
> > > >
> > > > Hi!
> > > >
> > > > Clearly, you all understand that moving images and the operator to
> > > > kie-tools is a workaround and wrong in all possible scenarios, right?
> > We
> > > > won't undo once we merge. I'm pretty positive that once we have a
> > release
> > > > train going people will add all the obstacles they can add saying
> "It's
> > > > working, let's not change it".
> > > >
> > > > Also, I understand that we need to unblock the release. We can
> > compromise
> > > > in COPYING the code, do the release, and then make the necessary
> > changes.
> > > > Images and cloud code are *integration platforms*. Should be the last
> > in
> > > a
> > > > stream. Tooling SHOULD NOT, in any case, depend on the images to
> build.
> > > >
> > > > So we can:
> > > >
> > > > 1. Accept Tiago's proposal (very well detailed, thanks!) but COPYING
> > the
> > > > code base, not MERGING. The contributions still flow to the right
> > repos.
> > > > 2. After release we:
> > > > 1. Move the CLI to the operator repo, removing this dependency
> from
> > > > tools to image
> > > > 2. Adjust the CI
> > > > 3. Remove the copied code
> > > >
> > > > Moving forward, I'd like to see a clear boundary between the projects
> > (as
> > > > stated in the temporary website). At the moment, we do not have. And
> > it's
> > > > hard for anyone from outside to understand what we are doing.
> > > >
> > > > On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me>
> > wrote:
> > > >
> > > > > Francisco and Gabriele,
> > > > >
> > > > > I understand and acknowledge your desire to find the “right”
> solution
> > > > > instead to work on a temporary “patch” - however without a detailed
> > > > > proposal I don’t think we can properly evaluate the impact of your
> > > > > suggestion.
> > > > >
> > > > > When I spoke with different SMEs that included tools and CI, the
> > > > > guesstimate for making the necessary changes on CI and codebase to
> > > > > basically have images and operators in the end of the build chain
> is
> > > > > something like 2 months of effort. Another impact that needs to be
> > > > > discussed is that KIE Tools repo had to be injected in the middle
> of
> > > all
> > > > > pipelines - forcing all PR checks and nightlies to build all repos
> > (PR
> > > > > checks will likely take 12+ hours… I even heard that it could be
> even
> > > 24
> > > > > hours).
> > > > >
> > > > > Based on the input above, I think it’s quite risk to move in such
> > > direction
> > > > > without a more detailed plan… because 2 months could be turned
> easily
> > > in 6!
> > > > > And this is exactly what happened when we guessed that moving to
> > Apache
> > > > > would take no more than 3 months. But here we are.
> > > > >
> > > > > I really strongly suggest that we focus on a release that could be
> > > > > achievable in less than a month from now, and we - after release -
> > > have a
> > > > > in depth discussion about the overall codebase and ci organization.
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > gabriele.cardosi@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Alex,
> > > > > > my suggestion is to move the building of all docker images, from
> > > whatever
> > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to
> > be
> > > > > > invoked after all the others.
> > > > > > I'm not sure if this would solve all the issues, and since I
> could
> > > not
> > > > > > enter in the details of all the involved code, my suggestion may
> be
> > > too
> > > > > > naive.
> > > > > > Having spent almost all of the last year in CI, I may say that,
> at
> > > least
> > > > > > for the kie-tools repo, removing the image build step from it
> > should
> > > not
> > > > > be
> > > > > > too difficult (since it is an issue we already faced and solved).
> > > > > > If, with "detailed proposal", you mean a complete list of all
> > > modules to
> > > > > be
> > > > > > moved and dependency refactoring, of course I can not provide it
> > > right
> > > > > now.
> > > > > >
> > > > > > Anyway, I share the concern from Francisco: undoing something is
> > > almost
> > > > > > always harder than doing it "rightly" from scratch...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado
> > > Sarti <
> > > > > > ftirados@redhat.com> ha scritto:
> > > > > >
> > > > > > > I do not think estimations should be the only driver to make a
> > > > > decision,
> > > > > > > especially when the current proposal is conceptually
> incompatible
> > > with
> > > > > > the
> > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > Given my knowledge of the CI it is nearly impossible for me to
> > > give a
> > > > > > fair
> > > > > > > estimate of how much it might take to achieve step 2) of my
> > > previous
> > > > > > e-mail
> > > > > > > . It might take a while or it might be pretty easy after all, I
> > > don't
> > > > > > > really know, but I think it will be a good idea if some of the
> > > experts
> > > > > > on
> > > > > > > CI in the team (the ones that set up the pipeline, which was a
> > huge
> > > > > > > achievement) give an estimate, not me. Estimating how much it
> > > takes to
> > > > > > > merge two existing repos (without altering CI) is easier, but
> it
> > > does
> > > > > not
> > > > > > > mean we are doing the right thing.
> > > > > > > My main concern is that it will be very difficult for me to
> > > explain to
> > > > > > > someone that arrives new to the team, that having experts on CI
> > on
> > > the
> > > > > > > team, we decided to merge two repos (once merged, it would be
> > > rather
> > > > > > > difficult to unmerge) rather than fix the CI, because of
> > > expediency.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > porcelli@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Francisco,
> > > > > > > >
> > > > > > > > Please take the time to make the more in depth analysis
> needed
> > > and
> > > > > > > provide
> > > > > > > > a more detailed plan… so we - as community- can evaluate the
> > > size of
> > > > > > the
> > > > > > > > effort. In the conceptual level you shared it’s near
> impossible
> > > to
> > > > > > > estimate
> > > > > > > > the size of the effort and compare with the current proposal.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado
> Sarti <
> > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > >
> > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > 1) Remove all dependencies from tooling to images, so
> images
> > > > > depend
> > > > > > on
> > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > 2) Then change CI to deal with tooling repo before dealing
> > with
> > > > > > images
> > > > > > > > > repo.
> > > > > > > > > I understand that CI details are tricky and since I'm not
> > > familiar
> > > > > > with
> > > > > > > > CI
> > > > > > > > > in any way, I barely can make a low level design, but we do
> > not
> > > > > need
> > > > > > to
> > > > > > > > fix
> > > > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > > alex@porcelli.me>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > >
> > > > > > > > > > You may not like or understand why the current state of
> the
> > > CI is
> > > > > > > like
> > > > > > > > > > that… actually has been in Red Hat and has been
> replicated
> > in
> > > > > > Apache
> > > > > > > as
> > > > > > > > > > used to be….
> > > > > > > > > >
> > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > >
> > > > > > > > > > If you disagree with the current plan, please provide a
> > > detailed
> > > > > > > > > > alternative so we, as community, can better evaluate the
> > > pros and
> > > > > > > cons
> > > > > > > > of
> > > > > > > > > > each proposal.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I think it’s also fair to say that, post 10 release we
> need
> > > to
> > > > > > have a
> > > > > > > > > much
> > > > > > > > > > in depth discussion about how our codebase is organized,
> > it’s
> > > > > clear
> > > > > > > > that
> > > > > > > > > > it’s not working.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > As Francisco said,
> > > > > > > > > > > I also have the impression that the "images" (if we are
> > > talking
> > > > > > of
> > > > > > > > > docker
> > > > > > > > > > > images) should be the very last one to be built, in a
> > > > > standalone
> > > > > > > > repo.
> > > > > > > > > > > That way, they may "combine" artifacts that are built
> in
> > > > > > different
> > > > > > > > > repos,
> > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > Moving them out of all the repos
> (kogito-apps/kie-tools)
> > > maybe
> > > > > > > could
> > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > (I also think there are some statements of undisputable
> > > needs
> > > > > > while
> > > > > > > > > they
> > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > > discussion.)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco
> Javier
> > > > > Tirado
> > > > > > > > Sarti
> > > > > > > > > <
> > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > >
> > > > > > > > > > > > Alex,
> > > > > > > > > > > > There are two assumptions that deserve further
> > > discussion:
> > > > > > > > > > > > 1) That tool has to be the last to build. why? it
> does
> > > not
> > > > > have
> > > > > > > > more
> > > > > > > > > > > sense
> > > > > > > > > > > > to build final images after everything else has been
> > > built?-
> > > > > > > > > > > > 2) That the impact (in terms of effort now) on fixing
> > CI
> > > is
> > > > > > > bigger
> > > > > > > > > than
> > > > > > > > > > > the
> > > > > > > > > > > > impact (long term consequences) of consolidating two
> > > > > unrelated
> > > > > > > > piece
> > > > > > > > > of
> > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > alex@porcelli.me
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > >
> > > > > > > > > > > > > This was discussed as an alternative solution,
> > however
> > > it
> > > > > has
> > > > > > > > major
> > > > > > > > > > > > impact
> > > > > > > > > > > > > on CI and there’s also the fact Tool has been
> always
> > > the
> > > > > last
> > > > > > > to
> > > > > > > > > > build
> > > > > > > > > > > > and
> > > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> > world
> > > > > there
> > > > > > > is
> > > > > > > > no
> > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > >
> > > > > > > > > > > > > So, based on our evaluation… the proposal here is
> the
> > > least
> > > > > > > > > > disruptive
> > > > > > > > > > > > and
> > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > _____________
> > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> > Tirado
> > > > > > Sarti <
> > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > embracing
> > > the
> > > > > > fact
> > > > > > > > > that
> > > > > > > > > > > > > > kogito-images depend on kie-tools, because we
> want
> > > those
> > > > > > > images
> > > > > > > > > to
> > > > > > > > > > > > > include
> > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > > Tirado
> > > > > > > Sarti
> > > > > > > > <
> > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > kn-plugin-workflow
> > > > > > > > to
> > > > > > > > > > > > > > > kogito-images (so there is not longer
> dependency
> > > from
> > > > > > tools
> > > > > > > > to
> > > > > > > > > > > > images)
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique
> Gonzalez
> > > > > > Martinez
> > > > > > > <
> > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > > (apache) <
> > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> > I say +1 in order to move forward with the
> 10.
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli
> <
> > > > > > > > > alex@porcelli.me
> > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > I spent the last day or so working closely
> > > with
> > > > > > Tiago,
> > > > > > > > > > > exploring
> > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > >> > > options and getting deeper on the impact
> and
> > > > > > > evaluating
> > > > > > > > > the
> > > > > > > > > > > > > overall
> > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > > > proposal
> > > > > > as
> > > > > > > > the
> > > > > > > > > > > most
> > > > > > > > > > > > > > >> > > viable option for unblocking the 10
> release
> > > in the
> > > > > > > > > > reasonable
> > > > > > > > > > > > time
> > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago
> Bento
> > <
> > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> > > time, as
> > > > > > this
> > > > > > > > > > matter
> > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes to
> > > read,
> > > > > > > > according
> > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > > thread
> > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > >
> > > > > > >
> https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > >> > > > many of us were working towards
> removing a
> > > > > > circular
> > > > > > > > > > > dependency
> > > > > > > > > > > > > > >> > > > currently present between `kogito-apps`
> > and
> > > > > > > > `kie-tools`.
> > > > > > > > > > As
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > > finding
> > > > > the
> > > > > > > > > > circular
> > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> breakdown
> > > of
> > > > > the
> > > > > > > > things
> > > > > > > > > > we
> > > > > > > > > > > > did,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Right now, even though we started the
> > > effort to
> > > > > > move
> > > > > > > > the
> > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't
> been
> > > able
> > > > > to
> > > > > > > do
> > > > > > > > it
> > > > > > > > > > > yet,
> > > > > > > > > > > > as
> > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java
> 17,
> > > Maven
> > > > > > > 3.9.6,
> > > > > > > > > and
> > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > This
> > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > > >> > > >
> > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > .
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > |==> 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > C | 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > Y | 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > L |
> ==========================
> > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> `kie-tools`/extended-services
> > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > depend
> > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > `kie-tools`,
> > > > > > we
> > > > > > > > > > would've
> > > > > > > > > > > > > had:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > 02.
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > C |==> 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/kn-plugin-workflow
> > > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > >> > > > * and
> > > `kogito-images`/kogito-swf-devmode
> > > > > > > > depends
> > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> > image
> > > to
> > > > > > > > > > `kie-tools`,
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > 02.
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/kn-plugin-workflow
> > > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > >> > > > * and
> `kogito-serverless-operator`
> > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> > than
> > > a
> > > > > > simple
> > > > > > > > > > > circular
> > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After multiple conversations with a lot
> of
> > > > > people,
> > > > > > > > it's
> > > > > > > > > > been
> > > > > > > > > > > > > > really
> > > > > > > > > > > > > > >> > > > hard coming up with a simple solution
> that
> > > makes
> > > > > > it
> > > > > > > > > > possible
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving
> > > the way
> > > > > > > > > everyone
> > > > > > > > > > is
> > > > > > > > > > > > > used
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > contributing to the multiple
> repositories
> > we
> > > > > have.
> > > > > > > > More
> > > > > > > > > > than
> > > > > > > > > > > > > that,
> > > > > > > > > > > > > > >> > > > while making this assessment, I found
> more
> > > > > > problems
> > > > > > > > > that,
> > > > > > > > > > in
> > > > > > > > > > > > my
> > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > > forward
> > > > > > with
> > > > > > > > my
> > > > > > > > > > > > proposal
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we
> can
> > > use
> > > > > > > Apache's
> > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate
> about
> > > this
> > > > > > > really
> > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective about
> > the
> > > > > > current
> > > > > > > > > > > situation
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > > currently
> > > > > see.
> > > > > > > > I'll
> > > > > > > > > > > start
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > purposes,
> > > > > > > point
> > > > > > > > > out
> > > > > > > > > > > > some
> > > > > > > > > > > > > > >> > > > problems that I believe are blocking our
> > 10
> > > > > > release,
> > > > > > > > > > explain
> > > > > > > > > > > > my
> > > > > > > > > > > > > > >> > > > proposal and discuss some consequences
> to
> > > what
> > > > > I'm
> > > > > > > > > > > proposing.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count:
> > 11)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @
> `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts
> @
> > > `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-serverless-operator @
> > > > > > `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > >> > > > -
> > incubator-kie-sandbox-quarkus-accelerator
> > > @
> > > > > > > `0.0.0`
> > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @
> `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > updated @
> > > > > > `main`.
> > > > > > > > > Same
> > > > > > > > > > > for
> > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > > > >> > > > (The Kogito website. Develop &
> deploy
> > > at the
> > > > > > > > `main`
> > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`.
> > > Push @
> > > > > > > > `deploy`
> > > > > > > > > to
> > > > > > > > > > > > > update
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> `gh-pages`
> > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > sandbox.kie.org
> > > > > > and
> > > > > > > > KIE
> > > > > > > > > > > Tools'
> > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @
> > > `main`
> > > > > > > > > > > > > > >> > > > (Same as above, but for manual
> sanity
> > > checks
> > > > > > > > during
> > > > > > > > > > the
> > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I grouped the repositories by category,
> > and
> > > > > listed
> > > > > > > > them
> > > > > > > > > > in a
> > > > > > > > > > > > > > >> > > > topological order. Keep in mind that
> when
> > > > > > flattening
> > > > > > > > > out a
> > > > > > > > > > > > tree,
> > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > > > OptaPlanner
> > > > > > > > > > > could've
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > > referring to
> > > > > > as
> > > > > > > > > > `drools`
> > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner
> > is
> > > > > inside
> > > > > > > > that
> > > > > > > > > > > > stream,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > way these repositories reference each
> > other
> > > are
> > > > > > > > through
> > > > > > > > > > > Maven
> > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > > 999-SNAPSHOT
> > > > > > > > version.
> > > > > > > > > > This
> > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > >> > > > is well-known to the team, and although
> > > flawed
> > > > > for
> > > > > > > > > > intra-day
> > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > different
> > > time
> > > > > > > > zones,
> > > > > > > > > it
> > > > > > > > > > > is
> > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> > with,
> > > I
> > > > > > > assume.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Contributions made to Category A have
> some
> > > > > > dedicated
> > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> > build
> > > > > > > cross-repo
> > > > > > > > > PRs
> > > > > > > > > > > > > > together
> > > > > > > > > > > > > > >> > > > and verify that the codebase will
> continue
> > > > > working
> > > > > > > as
> > > > > > > > > > > expected
> > > > > > > > > > > > > > after
> > > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > > gather,
> > > > > > there
> > > > > > > > are
> > > > > > > > > > some
> > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > > cross-repo
> > > > > > > PRs.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps,
> > and
> > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > >> > > > - optaplanner, and
> optaplanner-quickstarts
> > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs
> to
> > > any
> > > > > > > > > combination
> > > > > > > > > > of
> > > > > > > > > > > > > repos
> > > > > > > > > > > > > > >> > > > that are not part of the same
> "sub-stream"
> > > > > cannot
> > > > > > be
> > > > > > > > > > > verified
> > > > > > > > > > > > > > before
> > > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > dependent
> > > > > > on
> > > > > > > > > > > individual
> > > > > > > > > > > > > > >> > > > contributors building stuff on their
> > > machines to
> > > > > > > > verify
> > > > > > > > > > that
> > > > > > > > > > > > it
> > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with
> these
> > > > > > > pipelines,
> > > > > > > > so
> > > > > > > > > > > > please
> > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > > referring to
> > > > > > as
> > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > >> > > > stream. The first repo there is a
> template
> > > > > > > repository
> > > > > > > > > that
> > > > > > > > > > > is
> > > > > > > > > > > > > used
> > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > >> > > > people starting projects from scratch on
> > KIE
> > > > > > > Sandbox,
> > > > > > > > > > > similar
> > > > > > > > > > > > > to a
> > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The other
> > one
> > > is
> > > > > the
> > > > > > > KIE
> > > > > > > > > > Tools
> > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> > build
> > > > > > system.
> > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > TypeScript
> > > > > > > > > libraries
> > > > > > > > > > > and
> > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts.
> The
> > > > > > > `kie-tools`
> > > > > > > > > > > monorepo
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > >> > > > configured to work with sparse checkouts
> > > and can
> > > > > > do
> > > > > > > > > > partial
> > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > >> > > > Category B repos refer to Category A
> repos
> > > > > through
> > > > > > > > > > > timestamped
> > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > > recently
> > > > > > > > > introduced
> > > > > > > > > > > that
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > > > artifacts
> > > > > > > > under
> > > > > > > > > a
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> > format,
> > > > > > > published
> > > > > > > > > > weekly
> > > > > > > > > > > > > every
> > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are
> an
> > > > > > evolution
> > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > > release for
> > > > > > all
> > > > > > > > of
> > > > > > > > > > > Apache
> > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > An important note here is that Category
> B
> > > > > > > repositories
> > > > > > > > > > have
> > > > > > > > > > > > been
> > > > > > > > > > > > > > >> > > > historically kept out of any automations
> > we
> > > used
> > > > > > to
> > > > > > > > > have,
> > > > > > > > > > > way
> > > > > > > > > > > > > back
> > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > Business
> > > > > > Central
> > > > > > > > > > (a.k.a.
> > > > > > > > > > > > v7)
> > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > >> > > > still going on. For this reason,
> Category
> > B
> > > > > > projects
> > > > > > > > > have
> > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > Actions.
> > > > > > > > > Category B
> > > > > > > > > > > > repos
> > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > >> > > > always depended on Category A repos
> using
> > > fixed
> > > > > > > > > versions.
> > > > > > > > > > If
> > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > SNAPSHOTs,
> > > > > > breaking
> > > > > > > > > > changes
> > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > > > potential
> > > > > > > to
> > > > > > > > > > break
> > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > >> > > > silently, leaving Category B with a
> broken
> > > > > > > development
> > > > > > > > > > > stream,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > maintainers
> > > > > > of
> > > > > > > > > > > Category B
> > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > >> > > > as historically Category A contributors
> > > were not
> > > > > > > > > familiar
> > > > > > > > > > > with
> > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Contributions made to Category B repos
> go
> > > > > through
> > > > > > a
> > > > > > > > > GitHub
> > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > >> > > > workflow that builds the relevant part
> of
> > > the
> > > > > > > > > `kie-tools`
> > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > >> > > > the changes introduced. Changes made to
> > the
> > > > > > pipeline
> > > > > > > > > > itself
> > > > > > > > > > > > are
> > > > > > > > > > > > > > also
> > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to
> > do
> > > > > things
> > > > > > > > like
> > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> example.
> > > More
> > > > > > > > > > importantly,
> > > > > > > > > > > it
> > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > > timestamped
> > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > together
> > > > > > > > > > > > > > >> > > > with the changes necessary to make it
> stay
> > > > > green.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This setup, however, makes it impossible
> > to
> > > have
> > > > > > > > > > cross-repo
> > > > > > > > > > > > PRs
> > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > simultaneously,
> > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > > > > > current
> > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > > around,
> > > > > and
> > > > > > > I'm
> > > > > > > > > not
> > > > > > > > > > > sure
> > > > > > > > > > > > > if
> > > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > > Regardless,
> > > > > > as
> > > > > > > > > > they're
> > > > > > > > > > > > > part
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > > release,
> > > > > so I
> > > > > > > > > listed
> > > > > > > > > > > them
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category D is self explanatory. There's
> > > only one
> > > > > > > repo
> > > > > > > > > that
> > > > > > > > > > > has
> > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category E are repos that do not host
> code
> > > > > > directly,
> > > > > > > > and
> > > > > > > > > > are
> > > > > > > > > > > > > > either
> > > > > > > > > > > > > > >> > > > organizational entities, or host
> websites,
> > > that
> > > > > > > > > currently
> > > > > > > > > > > are
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This lack of unification between
> Category
> > A
> > > and
> > > > > > > > > Category B
> > > > > > > > > > > is,
> > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> infamous
> > > > > circular
> > > > > > > > > > > dependency
> > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we
> > now
> > > can
> > > > > > > > describe
> > > > > > > > > > as
> > > > > > > > > > > a
> > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > >> > > > dependency between Category A and
> Category
> > > B.
> > > > > The
> > > > > > > way
> > > > > > > > I
> > > > > > > > > > see
> > > > > > > > > > > > it,
> > > > > > > > > > > > > if
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > had a single pipeline, building
> everything
> > > from
> > > > > > > > `drools`
> > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> > been
> > > > > > > > introduced,
> > > > > > > > > > and
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem in
> > our
> > > > > hands
> > > > > > > > right
> > > > > > > > > > now.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > > process
> > > > > > sees
> > > > > > > > this
> > > > > > > > > > > lack
> > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > unification as a central problem, not
> only
> > > for
> > > > > > this
> > > > > > > > > > release
> > > > > > > > > > > in
> > > > > > > > > > > > > > >> > > > particular, but for the community as a
> > > whole. It
> > > > > > is
> > > > > > > my
> > > > > > > > > > > belief
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > > > contribution
> > > > > > > > > > should
> > > > > > > > > > > > be
> > > > > > > > > > > > > > >> > > > allowed to break any part of our
> codebase.
> > > With
> > > > > > the
> > > > > > > > > > > increasing
> > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > > contributors
> > > > > too,
> > > > > > > we
> > > > > > > > > > cannot
> > > > > > > > > > > > > keep
> > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> > breaking
> > > > > > things.
> > > > > > > > > We're
> > > > > > > > > > > all
> > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > mechanisms
> > > > > in
> > > > > > > > place
> > > > > > > > > > to
> > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> > Especially
> > > > > when
> > > > > > > > these
> > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > > > individually,
> > > > > > > > > > > > probably
> > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > > depending on
> > > > > > > > > > kiegroup's
> > > > > > > > > > > > KIE
> > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > > `kogito-images`
> > > > > > > > > > > depending
> > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending
> on
> > > > > > > kiegroup's
> > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > `7.59.0.Final`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > depending
> > > > > on
> > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > codebase
> > > > > > > here:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >
> > > > > > > > >
> > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > ,
> > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > > OptaPlanner,
> > > > > > > > > > pointing
> > > > > > > > > > > to
> > > > > > > > > > > > > > older
> > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P5.
> > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > depending
> > > > > > > > > > on
> > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> `2.15.3.Final`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P6. Category C repos are out of date and
> > not
> > > > > part
> > > > > > of
> > > > > > > > the
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > > A
> > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> > (Current
> > > > > > version
> > > > > > > is
> > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > version,
> > > > > > only
> > > > > > > > by
> > > > > > > > > > > using
> > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> > > version is
> > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > OptaPlanner
> > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P7.
> > `kie-tools`/packages/kn-plugin-workflow
> > > has
> > > > > > its
> > > > > > > > E2E
> > > > > > > > > > > > disabled
> > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the
> same
> > > > > > solution,
> > > > > > > > as
> > > > > > > > > > they
> > > > > > > > > > > > > both
> > > > > > > > > > > > > > >> > > > suffer from the circular dependency
> > between
> > > > > > > Category A
> > > > > > > > > and
> > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > >> > > > As Category A and Category B are both
> > > streams
> > > > > that
> > > > > > > > have
> > > > > > > > > > been
> > > > > > > > > > > > > > really
> > > > > > > > > > > > > > >> > > > active, I see this as a blocker, as
> there
> > > are
> > > > > > > > > > contributions
> > > > > > > > > > > > that
> > > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> > > depends on
> > > > > > > > > Category
> > > > > > > > > > B
> > > > > > > > > > > > > with a
> > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > understood
> > > > > > as
> > > > > > > > > > > technical
> > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > something
> > > > > > > we'll
> > > > > > > > > > always
> > > > > > > > > > > > be
> > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> > just a
> > > > > > matter
> > > > > > > of
> > > > > > > > > > > making
> > > > > > > > > > > > > them
> > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> > impact
> > > the
> > > > > > > > > structure
> > > > > > > > > >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <al...@porcelli.me>.
Ricardo,
In this case, as soon as we merge the UI move to KIE tools, the images and
operators build will be permanently broken until post release. Or Am I
missing something?
On Wed, Mar 13, 2024 at 9:52 AM ricardo zanini fernandes <
ricardozanini@gmail.com> wrote:
> Alex, we simply copy the code to tools and do the release. I propose to not
> start adding contributions from operator/images to tools.
>
> On Wed, Mar 13, 2024 at 10:41 AM Alex Porcelli <al...@porcelli.me> wrote:
>
> > Ricardo,
> >
> > I think it's more than fair to ask to preserve the original repos, as
> > this solution is proposed as TEMPORARY.
> >
> > However, the devil is in the details.... could you expand a bit in
> > steps how you see the COPYING and the contributions still flow to the
> > right repos work?
> >
> > btw; I don't think we should account for fear or feelings about
> > things.. We should focus on plans and facts.
> >
> >
> >
> > On Wed, Mar 13, 2024 at 9:14 AM ricardo zanini fernandes
> > <ri...@gmail.com> wrote:
> > >
> > > Hi!
> > >
> > > Clearly, you all understand that moving images and the operator to
> > > kie-tools is a workaround and wrong in all possible scenarios, right?
> We
> > > won't undo once we merge. I'm pretty positive that once we have a
> release
> > > train going people will add all the obstacles they can add saying "It's
> > > working, let's not change it".
> > >
> > > Also, I understand that we need to unblock the release. We can
> compromise
> > > in COPYING the code, do the release, and then make the necessary
> changes.
> > > Images and cloud code are *integration platforms*. Should be the last
> in
> > a
> > > stream. Tooling SHOULD NOT, in any case, depend on the images to build.
> > >
> > > So we can:
> > >
> > > 1. Accept Tiago's proposal (very well detailed, thanks!) but COPYING
> the
> > > code base, not MERGING. The contributions still flow to the right
> repos.
> > > 2. After release we:
> > > 1. Move the CLI to the operator repo, removing this dependency from
> > > tools to image
> > > 2. Adjust the CI
> > > 3. Remove the copied code
> > >
> > > Moving forward, I'd like to see a clear boundary between the projects
> (as
> > > stated in the temporary website). At the moment, we do not have. And
> it's
> > > hard for anyone from outside to understand what we are doing.
> > >
> > > On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me>
> wrote:
> > >
> > > > Francisco and Gabriele,
> > > >
> > > > I understand and acknowledge your desire to find the “right” solution
> > > > instead to work on a temporary “patch” - however without a detailed
> > > > proposal I don’t think we can properly evaluate the impact of your
> > > > suggestion.
> > > >
> > > > When I spoke with different SMEs that included tools and CI, the
> > > > guesstimate for making the necessary changes on CI and codebase to
> > > > basically have images and operators in the end of the build chain is
> > > > something like 2 months of effort. Another impact that needs to be
> > > > discussed is that KIE Tools repo had to be injected in the middle of
> > all
> > > > pipelines - forcing all PR checks and nightlies to build all repos
> (PR
> > > > checks will likely take 12+ hours… I even heard that it could be even
> > 24
> > > > hours).
> > > >
> > > > Based on the input above, I think it’s quite risk to move in such
> > direction
> > > > without a more detailed plan… because 2 months could be turned easily
> > in 6!
> > > > And this is exactly what happened when we guessed that moving to
> Apache
> > > > would take no more than 3 months. But here we are.
> > > >
> > > > I really strongly suggest that we focus on a release that could be
> > > > achievable in less than a month from now, and we - after release -
> > have a
> > > > in depth discussion about the overall codebase and ci organization.
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > gabriele.cardosi@gmail.com>
> > > > wrote:
> > > >
> > > > > Alex,
> > > > > my suggestion is to move the building of all docker images, from
> > whatever
> > > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to
> be
> > > > > invoked after all the others.
> > > > > I'm not sure if this would solve all the issues, and since I could
> > not
> > > > > enter in the details of all the involved code, my suggestion may be
> > too
> > > > > naive.
> > > > > Having spent almost all of the last year in CI, I may say that, at
> > least
> > > > > for the kie-tools repo, removing the image build step from it
> should
> > not
> > > > be
> > > > > too difficult (since it is an issue we already faced and solved).
> > > > > If, with "detailed proposal", you mean a complete list of all
> > modules to
> > > > be
> > > > > moved and dependency refactoring, of course I can not provide it
> > right
> > > > now.
> > > > >
> > > > > Anyway, I share the concern from Francisco: undoing something is
> > almost
> > > > > always harder than doing it "rightly" from scratch...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado
> > Sarti <
> > > > > ftirados@redhat.com> ha scritto:
> > > > >
> > > > > > I do not think estimations should be the only driver to make a
> > > > decision,
> > > > > > especially when the current proposal is conceptually incompatible
> > with
> > > > > the
> > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > Given my knowledge of the CI it is nearly impossible for me to
> > give a
> > > > > fair
> > > > > > estimate of how much it might take to achieve step 2) of my
> > previous
> > > > > e-mail
> > > > > > . It might take a while or it might be pretty easy after all, I
> > don't
> > > > > > really know, but I think it will be a good idea if some of the
> > experts
> > > > > on
> > > > > > CI in the team (the ones that set up the pipeline, which was a
> huge
> > > > > > achievement) give an estimate, not me. Estimating how much it
> > takes to
> > > > > > merge two existing repos (without altering CI) is easier, but it
> > does
> > > > not
> > > > > > mean we are doing the right thing.
> > > > > > My main concern is that it will be very difficult for me to
> > explain to
> > > > > > someone that arrives new to the team, that having experts on CI
> on
> > the
> > > > > > team, we decided to merge two repos (once merged, it would be
> > rather
> > > > > > difficult to unmerge) rather than fix the CI, because of
> > expediency.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > porcelli@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Francisco,
> > > > > > >
> > > > > > > Please take the time to make the more in depth analysis needed
> > and
> > > > > > provide
> > > > > > > a more detailed plan… so we - as community- can evaluate the
> > size of
> > > > > the
> > > > > > > effort. In the conceptual level you shared it’s near impossible
> > to
> > > > > > estimate
> > > > > > > the size of the effort and compare with the current proposal.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > > > ftirados@redhat.com> wrote:
> > > > > > >
> > > > > > > > I think I already did a high level proposal.
> > > > > > > > 1) Remove all dependencies from tooling to images, so images
> > > > depend
> > > > > on
> > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > 2) Then change CI to deal with tooling repo before dealing
> with
> > > > > images
> > > > > > > > repo.
> > > > > > > > I understand that CI details are tricky and since I'm not
> > familiar
> > > > > with
> > > > > > > CI
> > > > > > > > in any way, I barely can make a low level design, but we do
> not
> > > > need
> > > > > to
> > > > > > > fix
> > > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > alex@porcelli.me>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco and Grabriele,
> > > > > > > > >
> > > > > > > > > You may not like or understand why the current state of the
> > CI is
> > > > > > like
> > > > > > > > > that… actually has been in Red Hat and has been replicated
> in
> > > > > Apache
> > > > > > as
> > > > > > > > > used to be….
> > > > > > > > >
> > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > >
> > > > > > > > > If you disagree with the current plan, please provide a
> > detailed
> > > > > > > > > alternative so we, as community, can better evaluate the
> > pros and
> > > > > > cons
> > > > > > > of
> > > > > > > > > each proposal.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think it’s also fair to say that, post 10 release we need
> > to
> > > > > have a
> > > > > > > > much
> > > > > > > > > in depth discussion about how our codebase is organized,
> it’s
> > > > clear
> > > > > > > that
> > > > > > > > > it’s not working.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > As Francisco said,
> > > > > > > > > > I also have the impression that the "images" (if we are
> > talking
> > > > > of
> > > > > > > > docker
> > > > > > > > > > images) should be the very last one to be built, in a
> > > > standalone
> > > > > > > repo.
> > > > > > > > > > That way, they may "combine" artifacts that are built in
> > > > > different
> > > > > > > > repos,
> > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> > maybe
> > > > > > could
> > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > (I also think there are some statements of undisputable
> > needs
> > > > > while
> > > > > > > > they
> > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > discussion.)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > > > Tirado
> > > > > > > Sarti
> > > > > > > > <
> > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > >
> > > > > > > > > > > Alex,
> > > > > > > > > > > There are two assumptions that deserve further
> > discussion:
> > > > > > > > > > > 1) That tool has to be the last to build. why? it does
> > not
> > > > have
> > > > > > > more
> > > > > > > > > > sense
> > > > > > > > > > > to build final images after everything else has been
> > built?-
> > > > > > > > > > > 2) That the impact (in terms of effort now) on fixing
> CI
> > is
> > > > > > bigger
> > > > > > > > than
> > > > > > > > > > the
> > > > > > > > > > > impact (long term consequences) of consolidating two
> > > > unrelated
> > > > > > > piece
> > > > > > > > of
> > > > > > > > > > > software within the same repository.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > alex@porcelli.me
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Francisco,
> > > > > > > > > > > >
> > > > > > > > > > > > This was discussed as an alternative solution,
> however
> > it
> > > > has
> > > > > > > major
> > > > > > > > > > > impact
> > > > > > > > > > > > on CI and there’s also the fact Tool has been always
> > the
> > > > last
> > > > > > to
> > > > > > > > > build
> > > > > > > > > > > and
> > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> world
> > > > there
> > > > > > is
> > > > > > > no
> > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > >
> > > > > > > > > > > > So, based on our evaluation… the proposal here is the
> > least
> > > > > > > > > disruptive
> > > > > > > > > > > and
> > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > _____________
> > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> Tirado
> > > > > Sarti <
> > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> embracing
> > the
> > > > > fact
> > > > > > > > that
> > > > > > > > > > > > > kogito-images depend on kie-tools, because we want
> > those
> > > > > > images
> > > > > > > > to
> > > > > > > > > > > > include
> > > > > > > > > > > > > tools.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > Tirado
> > > > > > Sarti
> > > > > > > <
> > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > kn-plugin-workflow
> > > > > > > to
> > > > > > > > > > > > > > kogito-images (so there is not longer dependency
> > from
> > > > > tools
> > > > > > > to
> > > > > > > > > > > images)
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > > > Martinez
> > > > > > <
> > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > (apache) <
> > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > > > alex@porcelli.me
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > I spent the last day or so working closely
> > with
> > > > > Tiago,
> > > > > > > > > > exploring
> > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > > > evaluating
> > > > > > > > the
> > > > > > > > > > > > overall
> > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > > proposal
> > > > > as
> > > > > > > the
> > > > > > > > > > most
> > > > > > > > > > > > > >> > > viable option for unblocking the 10 release
> > in the
> > > > > > > > > reasonable
> > > > > > > > > > > time
> > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento
> <
> > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> > time, as
> > > > > this
> > > > > > > > > matter
> > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This email will take you < 20 minutes to
> > read,
> > > > > > > according
> > > > > > > > > to
> > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > thread
> > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > >
> > > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > ),
> > > > > > > > > > > > > >> > > > many of us were working towards removing a
> > > > > circular
> > > > > > > > > > dependency
> > > > > > > > > > > > > >> > > > currently present between `kogito-apps`
> and
> > > > > > > `kie-tools`.
> > > > > > > > > As
> > > > > > > > > > we
> > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > finding
> > > > the
> > > > > > > > > circular
> > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown
> > of
> > > > the
> > > > > > > things
> > > > > > > > > we
> > > > > > > > > > > did,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Right now, even though we started the
> > effort to
> > > > > move
> > > > > > > the
> > > > > > > > > > > Quarkus
> > > > > > > > > > > > > Dev
> > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> > able
> > > > to
> > > > > > do
> > > > > > > it
> > > > > > > > > > yet,
> > > > > > > > > > > as
> > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> > Maven
> > > > > > 3.9.6,
> > > > > > > > and
> > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > This
> > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > >> > > >
> > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > .
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > C | 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > Y | 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > >> > > > * and
> > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > depend
> > > > > > > > > > > > > >> on
> > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > `kie-tools`,
> > > > > we
> > > > > > > > > would've
> > > > > > > > > > > > had:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > C |==> 04.
> incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As
> `kie-tools`/kn-plugin-workflow
> > > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > >> > > > * and
> > `kogito-images`/kogito-swf-devmode
> > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> image
> > to
> > > > > > > > > `kie-tools`,
> > > > > > > > > > we
> > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As
> `kie-tools`/kn-plugin-workflow
> > > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> than
> > a
> > > > > simple
> > > > > > > > > > circular
> > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > > > people,
> > > > > > > it's
> > > > > > > > > been
> > > > > > > > > > > > > really
> > > > > > > > > > > > > >> > > > hard coming up with a simple solution that
> > makes
> > > > > it
> > > > > > > > > possible
> > > > > > > > > > > to
> > > > > > > > > > > > > >> build
> > > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving
> > the way
> > > > > > > > everyone
> > > > > > > > > is
> > > > > > > > > > > > used
> > > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > contributing to the multiple repositories
> we
> > > > have.
> > > > > > > More
> > > > > > > > > than
> > > > > > > > > > > > that,
> > > > > > > > > > > > > >> > > > while making this assessment, I found more
> > > > > problems
> > > > > > > > that,
> > > > > > > > > in
> > > > > > > > > > > my
> > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > forward
> > > > > with
> > > > > > > my
> > > > > > > > > > > proposal
> > > > > > > > > > > > > for
> > > > > > > > > > > > > >> > > > the Apache KIE release process, so we can
> > use
> > > > > > Apache's
> > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> > this
> > > > > > really
> > > > > > > > > > > > complicated
> > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I'll lay out my entire perspective about
> the
> > > > > current
> > > > > > > > > > situation
> > > > > > > > > > > > of
> > > > > > > > > > > > > >> our
> > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > currently
> > > > see.
> > > > > > > I'll
> > > > > > > > > > start
> > > > > > > > > > > > with
> > > > > > > > > > > > > >> an
> > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > purposes,
> > > > > > point
> > > > > > > > out
> > > > > > > > > > > some
> > > > > > > > > > > > > >> > > > problems that I believe are blocking our
> 10
> > > > > release,
> > > > > > > > > explain
> > > > > > > > > > > my
> > > > > > > > > > > > > >> > > > proposal and discuss some consequences to
> > what
> > > > I'm
> > > > > > > > > > proposing.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count:
> 11)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> > `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-serverless-operator @
> > > > > `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > >> > > > -
> incubator-kie-sandbox-quarkus-accelerator
> > @
> > > > > > `0.0.0`
> > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > >> > > > (Issues only, README should be
> updated @
> > > > > `main`.
> > > > > > > > Same
> > > > > > > > > > for
> > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy
> > at the
> > > > > > > `main`
> > > > > > > > > > > branch.)
> > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`.
> > Push @
> > > > > > > `deploy`
> > > > > > > > to
> > > > > > > > > > > > update
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > sandbox.kie.org
> > > > > and
> > > > > > > KIE
> > > > > > > > > > Tools'
> > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @
> > `main`
> > > > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> > checks
> > > > > > > during
> > > > > > > > > the
> > > > > > > > > > > > > staging
> > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I grouped the repositories by category,
> and
> > > > listed
> > > > > > > them
> > > > > > > > > in a
> > > > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > > > flattening
> > > > > > > > out a
> > > > > > > > > > > tree,
> > > > > > > > > > > > > >> there
> > > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > > OptaPlanner
> > > > > > > > > > could've
> > > > > > > > > > > > been
> > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > referring to
> > > > > as
> > > > > > > > > `drools`
> > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner
> is
> > > > inside
> > > > > > > that
> > > > > > > > > > > stream,
> > > > > > > > > > > > as
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > way these repositories reference each
> other
> > are
> > > > > > > through
> > > > > > > > > > Maven
> > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > 999-SNAPSHOT
> > > > > > > version.
> > > > > > > > > This
> > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > >> > > > is well-known to the team, and although
> > flawed
> > > > for
> > > > > > > > > intra-day
> > > > > > > > > > > > > builds
> > > > > > > > > > > > > >> > > > and disruptive for people in many
> different
> > time
> > > > > > > zones,
> > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > > > > >> already
> > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> with,
> > I
> > > > > > assume.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > > > dedicated
> > > > > > > > > > > pipelines,
> > > > > > > > > > > > > >> which
> > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> build
> > > > > > cross-repo
> > > > > > > > PRs
> > > > > > > > > > > > > together
> > > > > > > > > > > > > >> > > > and verify that the codebase will continue
> > > > working
> > > > > > as
> > > > > > > > > > expected
> > > > > > > > > > > > > after
> > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > gather,
> > > > > there
> > > > > > > are
> > > > > > > > > some
> > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > cross-repo
> > > > > > PRs.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps,
> and
> > > > > > > > > kogito-examples
> > > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > > > >> > > > - kogito-images, and
> > kogito-serverless-operator
> > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to
> > any
> > > > > > > > combination
> > > > > > > > > of
> > > > > > > > > > > > repos
> > > > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > > > cannot
> > > > > be
> > > > > > > > > > verified
> > > > > > > > > > > > > before
> > > > > > > > > > > > > >> > > > merging, making our contribution model
> > dependent
> > > > > on
> > > > > > > > > > individual
> > > > > > > > > > > > > >> > > > contributors building stuff on their
> > machines to
> > > > > > > verify
> > > > > > > > > that
> > > > > > > > > > > it
> > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > > > pipelines,
> > > > > > > so
> > > > > > > > > > > please
> > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > referring to
> > > > > as
> > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > > > repository
> > > > > > > > that
> > > > > > > > > > is
> > > > > > > > > > > > used
> > > > > > > > > > > > > >> by
> > > > > > > > > > > > > >> > > > people starting projects from scratch on
> KIE
> > > > > > Sandbox,
> > > > > > > > > > similar
> > > > > > > > > > > > to a
> > > > > > > > > > > > > >> > > > Maven archetype, if you will. The other
> one
> > is
> > > > the
> > > > > > KIE
> > > > > > > > > Tools
> > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> build
> > > > > system.
> > > > > > > > > > > Currently,
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > TypeScript
> > > > > > > > libraries
> > > > > > > > > > and
> > > > > > > > > > > > > apps,
> > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > > > `kie-tools`
> > > > > > > > > > monorepo
> > > > > > > > > > > > is
> > > > > > > > > > > > > >> > > > configured to work with sparse checkouts
> > and can
> > > > > do
> > > > > > > > > partial
> > > > > > > > > > > > > builds.
> > > > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > > > through
> > > > > > > > > > timestamped
> > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > recently
> > > > > > > > introduced
> > > > > > > > > > that
> > > > > > > > > > > > > will
> > > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > > artifacts
> > > > > > > under
> > > > > > > > a
> > > > > > > > > > > > version
> > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> format,
> > > > > > published
> > > > > > > > > weekly
> > > > > > > > > > > > every
> > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > > > evolution
> > > > > > > to
> > > > > > > > > the
> > > > > > > > > > > > Kogito
> > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > release for
> > > > > all
> > > > > > > of
> > > > > > > > > > Apache
> > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > >> so
> > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > An important note here is that Category B
> > > > > > repositories
> > > > > > > > > have
> > > > > > > > > > > been
> > > > > > > > > > > > > >> > > > historically kept out of any automations
> we
> > used
> > > > > to
> > > > > > > > have,
> > > > > > > > > > way
> > > > > > > > > > > > back
> > > > > > > > > > > > > >> > > > when Kogito started and we had the
> Business
> > > > > Central
> > > > > > > > > (a.k.a.
> > > > > > > > > > > v7)
> > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > >> > > > still going on. For this reason, Category
> B
> > > > > projects
> > > > > > > > have
> > > > > > > > > > > > > developed
> > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > Actions.
> > > > > > > > Category B
> > > > > > > > > > > repos
> > > > > > > > > > > > > >> have
> > > > > > > > > > > > > >> > > > always depended on Category A repos using
> > fixed
> > > > > > > > versions.
> > > > > > > > > If
> > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> SNAPSHOTs,
> > > > > breaking
> > > > > > > > > changes
> > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > > potential
> > > > > > to
> > > > > > > > > break
> > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > > > development
> > > > > > > > > > stream,
> > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > maintainers
> > > > > of
> > > > > > > > > > Category B
> > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > >> > > > as historically Category A contributors
> > were not
> > > > > > > > familiar
> > > > > > > > > > with
> > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > > > through
> > > > > a
> > > > > > > > GitHub
> > > > > > > > > > > > Actions
> > > > > > > > > > > > > >> > > > workflow that builds the relevant part of
> > the
> > > > > > > > `kie-tools`
> > > > > > > > > > > > monorepo
> > > > > > > > > > > > > >> for
> > > > > > > > > > > > > >> > > > the changes introduced. Changes made to
> the
> > > > > pipeline
> > > > > > > > > itself
> > > > > > > > > > > are
> > > > > > > > > > > > > also
> > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to
> do
> > > > things
> > > > > > > like
> > > > > > > > > > > > atomically
> > > > > > > > > > > > > >> > > > bumping the Node.js version, for example.
> > More
> > > > > > > > > importantly,
> > > > > > > > > > it
> > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > timestamped
> > > > > > > > SNAPSHOT
> > > > > > > > > > > > > together
> > > > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > > > green.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This setup, however, makes it impossible
> to
> > have
> > > > > > > > > cross-repo
> > > > > > > > > > > PRs
> > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > simultaneously,
> > > > > > > with
> > > > > > > > > the
> > > > > > > > > > > > > current
> > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > around,
> > > > and
> > > > > > I'm
> > > > > > > > not
> > > > > > > > > > sure
> > > > > > > > > > > > if
> > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > Regardless,
> > > > > as
> > > > > > > > > they're
> > > > > > > > > > > > part
> > > > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > release,
> > > > so I
> > > > > > > > listed
> > > > > > > > > > them
> > > > > > > > > > > > for
> > > > > > > > > > > > > >> us
> > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category D is self explanatory. There's
> > only one
> > > > > > repo
> > > > > > > > that
> > > > > > > > > > has
> > > > > > > > > > > > > >> already
> > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > > > directly,
> > > > > > > and
> > > > > > > > > are
> > > > > > > > > > > > > either
> > > > > > > > > > > > > >> > > > organizational entities, or host websites,
> > that
> > > > > > > > currently
> > > > > > > > > > are
> > > > > > > > > > > > not
> > > > > > > > > > > > > >> part
> > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This lack of unification between Category
> A
> > and
> > > > > > > > Category B
> > > > > > > > > > is,
> > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > > > circular
> > > > > > > > > > dependency
> > > > > > > > > > > > > >> between
> > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we
> now
> > can
> > > > > > > describe
> > > > > > > > > as
> > > > > > > > > > a
> > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > >> > > > dependency between Category A and Category
> > B.
> > > > The
> > > > > > way
> > > > > > > I
> > > > > > > > > see
> > > > > > > > > > > it,
> > > > > > > > > > > > if
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > had a single pipeline, building everything
> > from
> > > > > > > `drools`
> > > > > > > > > to
> > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> been
> > > > > > > introduced,
> > > > > > > > > and
> > > > > > > > > > we
> > > > > > > > > > > > > >> > > > wouldn't be having this huge problem in
> our
> > > > hands
> > > > > > > right
> > > > > > > > > now.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > process
> > > > > sees
> > > > > > > this
> > > > > > > > > > lack
> > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > unification as a central problem, not only
> > for
> > > > > this
> > > > > > > > > release
> > > > > > > > > > in
> > > > > > > > > > > > > >> > > > particular, but for the community as a
> > whole. It
> > > > > is
> > > > > > my
> > > > > > > > > > belief
> > > > > > > > > > > > that
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > > contribution
> > > > > > > > > should
> > > > > > > > > > > be
> > > > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> > With
> > > > > the
> > > > > > > > > > increasing
> > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > contributors
> > > > too,
> > > > > > we
> > > > > > > > > cannot
> > > > > > > > > > > > keep
> > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> breaking
> > > > > things.
> > > > > > > > We're
> > > > > > > > > > all
> > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > mechanisms
> > > > in
> > > > > > > place
> > > > > > > > > to
> > > > > > > > > > > > > prevent
> > > > > > > > > > > > > >> us
> > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> Especially
> > > > when
> > > > > > > these
> > > > > > > > > > > mistakes
> > > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > > individually,
> > > > > > > > > > > probably
> > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > depending on
> > > > > > > > > kiegroup's
> > > > > > > > > > > KIE
> > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > `kogito-images`
> > > > > > > > > > depending
> > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > > > kiegroup's
> > > > > > > > > > `lienzo`
> > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > `7.59.0.Final`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > depending
> > > > on
> > > > > > > > > > kiegroup's
> > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > codebase
> > > > > > here:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >
> > > > > > > >
> > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > ,
> > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > OptaPlanner,
> > > > > > > > > pointing
> > > > > > > > > > to
> > > > > > > > > > > > > older
> > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P5.
> > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > depending
> > > > > > > > > on
> > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P6. Category C repos are out of date and
> not
> > > > part
> > > > > of
> > > > > > > the
> > > > > > > > > > > > Category
> > > > > > > > > > > > > A
> > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> (Current
> > > > > version
> > > > > > is
> > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > version,
> > > > > only
> > > > > > > by
> > > > > > > > > > using
> > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> > version is
> > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > OptaPlanner
> > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P7.
> `kie-tools`/packages/kn-plugin-workflow
> > has
> > > > > its
> > > > > > > E2E
> > > > > > > > > > > disabled
> > > > > > > > > > > > > >> after
> > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > > > solution,
> > > > > > > as
> > > > > > > > > they
> > > > > > > > > > > > both
> > > > > > > > > > > > > >> > > > suffer from the circular dependency
> between
> > > > > > Category A
> > > > > > > > and
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > >> > > > As Category A and Category B are both
> > streams
> > > > that
> > > > > > > have
> > > > > > > > > been
> > > > > > > > > > > > > really
> > > > > > > > > > > > > >> > > > active, I see this as a blocker, as there
> > are
> > > > > > > > > contributions
> > > > > > > > > > > that
> > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> > depends on
> > > > > > > > Category
> > > > > > > > > B
> > > > > > > > > > > > with a
> > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > understood
> > > > > as
> > > > > > > > > > technical
> > > > > > > > > > > > > debt.
> > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > something
> > > > > > we'll
> > > > > > > > > always
> > > > > > > > > > > be
> > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> just a
> > > > > matter
> > > > > > of
> > > > > > > > > > making
> > > > > > > > > > > > them
> > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> impact
> > the
> > > > > > > > structure
> > > > > > > > >
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by ricardo zanini fernandes <ri...@gmail.com>.
Alex, we simply copy the code to tools and do the release. I propose to not
start adding contributions from operator/images to tools.
On Wed, Mar 13, 2024 at 10:41 AM Alex Porcelli <al...@porcelli.me> wrote:
> Ricardo,
>
> I think it's more than fair to ask to preserve the original repos, as
> this solution is proposed as TEMPORARY.
>
> However, the devil is in the details.... could you expand a bit in
> steps how you see the COPYING and the contributions still flow to the
> right repos work?
>
> btw; I don't think we should account for fear or feelings about
> things.. We should focus on plans and facts.
>
>
>
> On Wed, Mar 13, 2024 at 9:14 AM ricardo zanini fernandes
> <ri...@gmail.com> wrote:
> >
> > Hi!
> >
> > Clearly, you all understand that moving images and the operator to
> > kie-tools is a workaround and wrong in all possible scenarios, right? We
> > won't undo once we merge. I'm pretty positive that once we have a release
> > train going people will add all the obstacles they can add saying "It's
> > working, let's not change it".
> >
> > Also, I understand that we need to unblock the release. We can compromise
> > in COPYING the code, do the release, and then make the necessary changes.
> > Images and cloud code are *integration platforms*. Should be the last in
> a
> > stream. Tooling SHOULD NOT, in any case, depend on the images to build.
> >
> > So we can:
> >
> > 1. Accept Tiago's proposal (very well detailed, thanks!) but COPYING the
> > code base, not MERGING. The contributions still flow to the right repos.
> > 2. After release we:
> > 1. Move the CLI to the operator repo, removing this dependency from
> > tools to image
> > 2. Adjust the CI
> > 3. Remove the copied code
> >
> > Moving forward, I'd like to see a clear boundary between the projects (as
> > stated in the temporary website). At the moment, we do not have. And it's
> > hard for anyone from outside to understand what we are doing.
> >
> > On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > Francisco and Gabriele,
> > >
> > > I understand and acknowledge your desire to find the “right” solution
> > > instead to work on a temporary “patch” - however without a detailed
> > > proposal I don’t think we can properly evaluate the impact of your
> > > suggestion.
> > >
> > > When I spoke with different SMEs that included tools and CI, the
> > > guesstimate for making the necessary changes on CI and codebase to
> > > basically have images and operators in the end of the build chain is
> > > something like 2 months of effort. Another impact that needs to be
> > > discussed is that KIE Tools repo had to be injected in the middle of
> all
> > > pipelines - forcing all PR checks and nightlies to build all repos (PR
> > > checks will likely take 12+ hours… I even heard that it could be even
> 24
> > > hours).
> > >
> > > Based on the input above, I think it’s quite risk to move in such
> direction
> > > without a more detailed plan… because 2 months could be turned easily
> in 6!
> > > And this is exactly what happened when we guessed that moving to Apache
> > > would take no more than 3 months. But here we are.
> > >
> > > I really strongly suggest that we focus on a release that could be
> > > achievable in less than a month from now, and we - after release -
> have a
> > > in depth discussion about the overall codebase and ci organization.
> > >
> > >
> > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > gabriele.cardosi@gmail.com>
> > > wrote:
> > >
> > > > Alex,
> > > > my suggestion is to move the building of all docker images, from
> whatever
> > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > > > invoked after all the others.
> > > > I'm not sure if this would solve all the issues, and since I could
> not
> > > > enter in the details of all the involved code, my suggestion may be
> too
> > > > naive.
> > > > Having spent almost all of the last year in CI, I may say that, at
> least
> > > > for the kie-tools repo, removing the image build step from it should
> not
> > > be
> > > > too difficult (since it is an issue we already faced and solved).
> > > > If, with "detailed proposal", you mean a complete list of all
> modules to
> > > be
> > > > moved and dependency refactoring, of course I can not provide it
> right
> > > now.
> > > >
> > > > Anyway, I share the concern from Francisco: undoing something is
> almost
> > > > always harder than doing it "rightly" from scratch...
> > > >
> > > >
> > > >
> > > >
> > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado
> Sarti <
> > > > ftirados@redhat.com> ha scritto:
> > > >
> > > > > I do not think estimations should be the only driver to make a
> > > decision,
> > > > > especially when the current proposal is conceptually incompatible
> with
> > > > the
> > > > > multi repo approach that is taken elsewhere in the project.
> > > > > Given my knowledge of the CI it is nearly impossible for me to
> give a
> > > > fair
> > > > > estimate of how much it might take to achieve step 2) of my
> previous
> > > > e-mail
> > > > > . It might take a while or it might be pretty easy after all, I
> don't
> > > > > really know, but I think it will be a good idea if some of the
> experts
> > > > on
> > > > > CI in the team (the ones that set up the pipeline, which was a huge
> > > > > achievement) give an estimate, not me. Estimating how much it
> takes to
> > > > > merge two existing repos (without altering CI) is easier, but it
> does
> > > not
> > > > > mean we are doing the right thing.
> > > > > My main concern is that it will be very difficult for me to
> explain to
> > > > > someone that arrives new to the team, that having experts on CI on
> the
> > > > > team, we decided to merge two repos (once merged, it would be
> rather
> > > > > difficult to unmerge) rather than fix the CI, because of
> expediency.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> porcelli@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Francisco,
> > > > > >
> > > > > > Please take the time to make the more in depth analysis needed
> and
> > > > > provide
> > > > > > a more detailed plan… so we - as community- can evaluate the
> size of
> > > > the
> > > > > > effort. In the conceptual level you shared it’s near impossible
> to
> > > > > estimate
> > > > > > the size of the effort and compare with the current proposal.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > > ftirados@redhat.com> wrote:
> > > > > >
> > > > > > > I think I already did a high level proposal.
> > > > > > > 1) Remove all dependencies from tooling to images, so images
> > > depend
> > > > on
> > > > > > > tooling but tooling does not depend on images.
> > > > > > > 2) Then change CI to deal with tooling repo before dealing with
> > > > images
> > > > > > > repo.
> > > > > > > I understand that CI details are tricky and since I'm not
> familiar
> > > > with
> > > > > > CI
> > > > > > > in any way, I barely can make a low level design, but we do not
> > > need
> > > > to
> > > > > > fix
> > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> alex@porcelli.me>
> > > > > wrote:
> > > > > > >
> > > > > > > > Francisco and Grabriele,
> > > > > > > >
> > > > > > > > You may not like or understand why the current state of the
> CI is
> > > > > like
> > > > > > > > that… actually has been in Red Hat and has been replicated in
> > > > Apache
> > > > > as
> > > > > > > > used to be….
> > > > > > > >
> > > > > > > > But the fact is that this is the current reality.
> > > > > > > >
> > > > > > > > If you disagree with the current plan, please provide a
> detailed
> > > > > > > > alternative so we, as community, can better evaluate the
> pros and
> > > > > cons
> > > > > > of
> > > > > > > > each proposal.
> > > > > > > >
> > > > > > > >
> > > > > > > > I think it’s also fair to say that, post 10 release we need
> to
> > > > have a
> > > > > > > much
> > > > > > > > in depth discussion about how our codebase is organized, it’s
> > > clear
> > > > > > that
> > > > > > > > it’s not working.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > As Francisco said,
> > > > > > > > > I also have the impression that the "images" (if we are
> talking
> > > > of
> > > > > > > docker
> > > > > > > > > images) should be the very last one to be built, in a
> > > standalone
> > > > > > repo.
> > > > > > > > > That way, they may "combine" artifacts that are built in
> > > > different
> > > > > > > repos,
> > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> maybe
> > > > > could
> > > > > > > > > simplify the situation a bit.
> > > > > > > > > (I also think there are some statements of undisputable
> needs
> > > > while
> > > > > > > they
> > > > > > > > > are, actually, just technical choices.
> > > > > > > > > Anyway, this latter point is for longer, following,
> > > discussion.)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > > Tirado
> > > > > > Sarti
> > > > > > > <
> > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > >
> > > > > > > > > > Alex,
> > > > > > > > > > There are two assumptions that deserve further
> discussion:
> > > > > > > > > > 1) That tool has to be the last to build. why? it does
> not
> > > have
> > > > > > more
> > > > > > > > > sense
> > > > > > > > > > to build final images after everything else has been
> built?-
> > > > > > > > > > 2) That the impact (in terms of effort now) on fixing CI
> is
> > > > > bigger
> > > > > > > than
> > > > > > > > > the
> > > > > > > > > > impact (long term consequences) of consolidating two
> > > unrelated
> > > > > > piece
> > > > > > > of
> > > > > > > > > > software within the same repository.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > alex@porcelli.me
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Francisco,
> > > > > > > > > > >
> > > > > > > > > > > This was discussed as an alternative solution, however
> it
> > > has
> > > > > > major
> > > > > > > > > > impact
> > > > > > > > > > > on CI and there’s also the fact Tool has been always
> the
> > > last
> > > > > to
> > > > > > > > build
> > > > > > > > > > and
> > > > > > > > > > > has no Snapshot published (actually in JavaScript world
> > > there
> > > > > is
> > > > > > no
> > > > > > > > > > > snapshot concept).
> > > > > > > > > > >
> > > > > > > > > > > So, based on our evaluation… the proposal here is the
> least
> > > > > > > > disruptive
> > > > > > > > > > and
> > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > _____________
> > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > http://porcelli.me
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > > > Sarti <
> > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > After kie-tools, sorry. I think we are not embracing
> the
> > > > fact
> > > > > > > that
> > > > > > > > > > > > kogito-images depend on kie-tools, because we want
> those
> > > > > images
> > > > > > > to
> > > > > > > > > > > include
> > > > > > > > > > > > tools.
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> Tirado
> > > > > Sarti
> > > > > > <
> > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > It can be an alternative solution to move
> > > > > kn-plugin-workflow
> > > > > > to
> > > > > > > > > > > > > kogito-images (so there is not longer dependency
> from
> > > > tools
> > > > > > to
> > > > > > > > > > images)
> > > > > > > > > > > > and
> > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > > Martinez
> > > > > <
> > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> (apache) <
> > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > > alex@porcelli.me
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > I spent the last day or so working closely
> with
> > > > Tiago,
> > > > > > > > > exploring
> > > > > > > > > > > > >> > different
> > > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > > evaluating
> > > > > > > the
> > > > > > > > > > > overall
> > > > > > > > > > > > >> > release
> > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > proposal
> > > > as
> > > > > > the
> > > > > > > > > most
> > > > > > > > > > > > >> > > viable option for unblocking the 10 release
> in the
> > > > > > > > reasonable
> > > > > > > > > > time
> > > > > > > > > > > > >> frame.
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> time, as
> > > > this
> > > > > > > > matter
> > > > > > > > > > > > >> requires a
> > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This email will take you < 20 minutes to
> read,
> > > > > > according
> > > > > > > > to
> > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > As you may have followed on a separate
> thread
> > > > > > > > > > > > >> > > > (
> > > > > > > > > > >
> > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > ),
> > > > > > > > > > > > >> > > > many of us were working towards removing a
> > > > circular
> > > > > > > > > dependency
> > > > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > > > `kie-tools`.
> > > > > > > > As
> > > > > > > > > we
> > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> finding
> > > the
> > > > > > > > circular
> > > > > > > > > > > > >> dependency
> > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown
> of
> > > the
> > > > > > things
> > > > > > > > we
> > > > > > > > > > did,
> > > > > > > > > > > > and
> > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Right now, even though we started the
> effort to
> > > > move
> > > > > > the
> > > > > > > > > > Quarkus
> > > > > > > > > > > > Dev
> > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> able
> > > to
> > > > > do
> > > > > > it
> > > > > > > > > yet,
> > > > > > > > > > as
> > > > > > > > > > > > >> we've
> > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> Maven
> > > > > 3.9.6,
> > > > > > > and
> > > > > > > > > > > Quarkus
> > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > This
> > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > >> > > >
> > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > .
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > C | 03.
> incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > Y | 04.
> incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > >> > > > * and
> > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > depend
> > > > > > > > > > > > >> on
> > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> `kie-tools`,
> > > > we
> > > > > > > > would've
> > > > > > > > > > > had:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > >> > > > * and
> `kogito-images`/kogito-swf-devmode
> > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image
> to
> > > > > > > > `kie-tools`,
> > > > > > > > > we
> > > > > > > > > > > > >> would've
> > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > 04.
> incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem than
> a
> > > > simple
> > > > > > > > > circular
> > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > > people,
> > > > > > it's
> > > > > > > > been
> > > > > > > > > > > > really
> > > > > > > > > > > > >> > > > hard coming up with a simple solution that
> makes
> > > > it
> > > > > > > > possible
> > > > > > > > > > to
> > > > > > > > > > > > >> build
> > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving
> the way
> > > > > > > everyone
> > > > > > > > is
> > > > > > > > > > > used
> > > > > > > > > > > > to
> > > > > > > > > > > > >> > > > contributing to the multiple repositories we
> > > have.
> > > > > > More
> > > > > > > > than
> > > > > > > > > > > that,
> > > > > > > > > > > > >> > > > while making this assessment, I found more
> > > > problems
> > > > > > > that,
> > > > > > > > in
> > > > > > > > > > my
> > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> forward
> > > > with
> > > > > > my
> > > > > > > > > > proposal
> > > > > > > > > > > > for
> > > > > > > > > > > > >> > > > the Apache KIE release process, so we can
> use
> > > > > Apache's
> > > > > > > > > > > mechanisms
> > > > > > > > > > > > to
> > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> this
> > > > > really
> > > > > > > > > > > complicated
> > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > > > current
> > > > > > > > > situation
> > > > > > > > > > > of
> > > > > > > > > > > > >> our
> > > > > > > > > > > > >> > > > codebase, as well as problems I can
> currently
> > > see.
> > > > > > I'll
> > > > > > > > > start
> > > > > > > > > > > with
> > > > > > > > > > > > >> an
> > > > > > > > > > > > >> > > > analysis of the repositories and their
> purposes,
> > > > > point
> > > > > > > out
> > > > > > > > > > some
> > > > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > > > release,
> > > > > > > > explain
> > > > > > > > > > my
> > > > > > > > > > > > >> > > > proposal and discuss some consequences to
> what
> > > I'm
> > > > > > > > > proposing.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > > > `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator
> @
> > > > > `0.0.0`
> > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > >> > > > (Issues only, README should be updated @
> > > > `main`.
> > > > > > > Same
> > > > > > > > > for
> > > > > > > > > > > > GitHub
> > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy
> at the
> > > > > > `main`
> > > > > > > > > > branch.)
> > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`.
> Push @
> > > > > > `deploy`
> > > > > > > to
> > > > > > > > > > > update
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > > >> > > > (GitHub pages used to host
> sandbox.kie.org
> > > > and
> > > > > > KIE
> > > > > > > > > Tools'
> > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @
> `main`
> > > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> checks
> > > > > > during
> > > > > > > > the
> > > > > > > > > > > > staging
> > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I grouped the repositories by category, and
> > > listed
> > > > > > them
> > > > > > > > in a
> > > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > > flattening
> > > > > > > out a
> > > > > > > > > > tree,
> > > > > > > > > > > > >> there
> > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > OptaPlanner
> > > > > > > > > could've
> > > > > > > > > > > been
> > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category A repos are what I've been
> referring to
> > > > as
> > > > > > > > `drools`
> > > > > > > > > > and
> > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is
> > > inside
> > > > > > that
> > > > > > > > > > stream,
> > > > > > > > > > > as
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> > > > way these repositories reference each other
> are
> > > > > > through
> > > > > > > > > Maven
> > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> 999-SNAPSHOT
> > > > > > version.
> > > > > > > > This
> > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > >> > > > is well-known to the team, and although
> flawed
> > > for
> > > > > > > > intra-day
> > > > > > > > > > > > builds
> > > > > > > > > > > > >> > > > and disruptive for people in many different
> time
> > > > > > zones,
> > > > > > > it
> > > > > > > > > is
> > > > > > > > > > > > >> already
> > > > > > > > > > > > >> > > > very comfortable for everyone to work with,
> I
> > > > > assume.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > > dedicated
> > > > > > > > > > pipelines,
> > > > > > > > > > > > >> which
> > > > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > > > cross-repo
> > > > > > > PRs
> > > > > > > > > > > > together
> > > > > > > > > > > > >> > > > and verify that the codebase will continue
> > > working
> > > > > as
> > > > > > > > > expected
> > > > > > > > > > > > after
> > > > > > > > > > > > >> > > > they're all merged. From what I could
> gather,
> > > > there
> > > > > > are
> > > > > > > > some
> > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > cross-repo
> > > > > PRs.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > > > kogito-examples
> > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > > >> > > > - kogito-images, and
> kogito-serverless-operator
> > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to
> any
> > > > > > > combination
> > > > > > > > of
> > > > > > > > > > > repos
> > > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > > cannot
> > > > be
> > > > > > > > > verified
> > > > > > > > > > > > before
> > > > > > > > > > > > >> > > > merging, making our contribution model
> dependent
> > > > on
> > > > > > > > > individual
> > > > > > > > > > > > >> > > > contributors building stuff on their
> machines to
> > > > > > verify
> > > > > > > > that
> > > > > > > > > > it
> > > > > > > > > > > > >> works.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > > pipelines,
> > > > > > so
> > > > > > > > > > please
> > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category B repos are what I've been
> referring to
> > > > as
> > > > > > > > > > `kie-tools`
> > > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > > repository
> > > > > > > that
> > > > > > > > > is
> > > > > > > > > > > used
> > > > > > > > > > > > >> by
> > > > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > > > Sandbox,
> > > > > > > > > similar
> > > > > > > > > > > to a
> > > > > > > > > > > > >> > > > Maven archetype, if you will. The other one
> is
> > > the
> > > > > KIE
> > > > > > > > Tools
> > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > > > system.
> > > > > > > > > > Currently,
> > > > > > > > > > > > KIE
> > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> TypeScript
> > > > > > > libraries
> > > > > > > > > and
> > > > > > > > > > > > apps,
> > > > > > > > > > > > >> Go
> > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > > `kie-tools`
> > > > > > > > > monorepo
> > > > > > > > > > > is
> > > > > > > > > > > > >> > > > configured to work with sparse checkouts
> and can
> > > > do
> > > > > > > > partial
> > > > > > > > > > > > builds.
> > > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > > through
> > > > > > > > > timestamped
> > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> recently
> > > > > > > introduced
> > > > > > > > > that
> > > > > > > > > > > > will
> > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > artifacts
> > > > > > under
> > > > > > > a
> > > > > > > > > > > version
> > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > > > published
> > > > > > > > weekly
> > > > > > > > > > > every
> > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > > evolution
> > > > > > to
> > > > > > > > the
> > > > > > > > > > > Kogito
> > > > > > > > > > > > >> > > > releases, as we're now targeting one
> release for
> > > > all
> > > > > > of
> > > > > > > > > Apache
> > > > > > > > > > > > KIE,
> > > > > > > > > > > > >> so
> > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > An important note here is that Category B
> > > > > repositories
> > > > > > > > have
> > > > > > > > > > been
> > > > > > > > > > > > >> > > > historically kept out of any automations we
> used
> > > > to
> > > > > > > have,
> > > > > > > > > way
> > > > > > > > > > > back
> > > > > > > > > > > > >> > > > when Kogito started and we had the Business
> > > > Central
> > > > > > > > (a.k.a.
> > > > > > > > > > v7)
> > > > > > > > > > > > >> stream
> > > > > > > > > > > > >> > > > still going on. For this reason, Category B
> > > > projects
> > > > > > > have
> > > > > > > > > > > > developed
> > > > > > > > > > > > >> > > > their own automations, based on GitHub
> Actions.
> > > > > > > Category B
> > > > > > > > > > repos
> > > > > > > > > > > > >> have
> > > > > > > > > > > > >> > > > always depended on Category A repos using
> fixed
> > > > > > > versions.
> > > > > > > > If
> > > > > > > > > > > > >> Category
> > > > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > > > breaking
> > > > > > > > changes
> > > > > > > > > > on
> > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > potential
> > > > > to
> > > > > > > > break
> > > > > > > > > > > > >> Category B
> > > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > > development
> > > > > > > > > stream,
> > > > > > > > > > > and
> > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> maintainers
> > > > of
> > > > > > > > > Category B
> > > > > > > > > > > > >> repos,
> > > > > > > > > > > > >> > > > as historically Category A contributors
> were not
> > > > > > > familiar
> > > > > > > > > with
> > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > > through
> > > > a
> > > > > > > GitHub
> > > > > > > > > > > Actions
> > > > > > > > > > > > >> > > > workflow that builds the relevant part of
> the
> > > > > > > `kie-tools`
> > > > > > > > > > > monorepo
> > > > > > > > > > > > >> for
> > > > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > > > pipeline
> > > > > > > > itself
> > > > > > > > > > are
> > > > > > > > > > > > also
> > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do
> > > things
> > > > > > like
> > > > > > > > > > > atomically
> > > > > > > > > > > > >> > > > bumping the Node.js version, for example.
> More
> > > > > > > > importantly,
> > > > > > > > > it
> > > > > > > > > > > > >> allows
> > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > timestamped
> > > > > > > SNAPSHOT
> > > > > > > > > > > > together
> > > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > > green.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This setup, however, makes it impossible to
> have
> > > > > > > > cross-repo
> > > > > > > > > > PRs
> > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > simultaneously,
> > > > > > with
> > > > > > > > the
> > > > > > > > > > > > current
> > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category C repos are kind of floating
> around,
> > > and
> > > > > I'm
> > > > > > > not
> > > > > > > > > sure
> > > > > > > > > > > if
> > > > > > > > > > > > >> > > > there's much activity going on there.
> > > Regardless,
> > > > as
> > > > > > > > they're
> > > > > > > > > > > part
> > > > > > > > > > > > of
> > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> release,
> > > so I
> > > > > > > listed
> > > > > > > > > them
> > > > > > > > > > > for
> > > > > > > > > > > > >> us
> > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category D is self explanatory. There's
> only one
> > > > > repo
> > > > > > > that
> > > > > > > > > has
> > > > > > > > > > > > >> already
> > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > > directly,
> > > > > > and
> > > > > > > > are
> > > > > > > > > > > > either
> > > > > > > > > > > > >> > > > organizational entities, or host websites,
> that
> > > > > > > currently
> > > > > > > > > are
> > > > > > > > > > > not
> > > > > > > > > > > > >> part
> > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This lack of unification between Category A
> and
> > > > > > > Category B
> > > > > > > > > is,
> > > > > > > > > > > > IMHO,
> > > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > > circular
> > > > > > > > > dependency
> > > > > > > > > > > > >> between
> > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now
> can
> > > > > > describe
> > > > > > > > as
> > > > > > > > > a
> > > > > > > > > > > > >> circular
> > > > > > > > > > > > >> > > > dependency between Category A and Category
> B.
> > > The
> > > > > way
> > > > > > I
> > > > > > > > see
> > > > > > > > > > it,
> > > > > > > > > > > if
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > had a single pipeline, building everything
> from
> > > > > > `drools`
> > > > > > > > to
> > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > > > introduced,
> > > > > > > > and
> > > > > > > > > we
> > > > > > > > > > > > >> > > > wouldn't be having this huge problem in our
> > > hands
> > > > > > right
> > > > > > > > now.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> process
> > > > sees
> > > > > > this
> > > > > > > > > lack
> > > > > > > > > > of
> > > > > > > > > > > > >> > > > unification as a central problem, not only
> for
> > > > this
> > > > > > > > release
> > > > > > > > > in
> > > > > > > > > > > > >> > > > particular, but for the community as a
> whole. It
> > > > is
> > > > > my
> > > > > > > > > belief
> > > > > > > > > > > that
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > contribution
> > > > > > > > should
> > > > > > > > > > be
> > > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> With
> > > > the
> > > > > > > > > increasing
> > > > > > > > > > > > >> volume
> > > > > > > > > > > > >> > > > of code, and hopefully number of
> contributors
> > > too,
> > > > > we
> > > > > > > > cannot
> > > > > > > > > > > keep
> > > > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > > > things.
> > > > > > > We're
> > > > > > > > > all
> > > > > > > > > > > > >> humans
> > > > > > > > > > > > >> > > > after all, and it is our job to have
> mechanisms
> > > in
> > > > > > place
> > > > > > > > to
> > > > > > > > > > > > prevent
> > > > > > > > > > > > >> us
> > > > > > > > > > > > >> > > > from unwillingly making mistakes. Especially
> > > when
> > > > > > these
> > > > > > > > > > mistakes
> > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > individually,
> > > > > > > > > > probably
> > > > > > > > > > > > >> can't
> > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> depending on
> > > > > > > > kiegroup's
> > > > > > > > > > KIE
> > > > > > > > > > > > >> Tools
> > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > `kogito-images`
> > > > > > > > > depending
> > > > > > > > > > on
> > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > > kiegroup's
> > > > > > > > > `lienzo`
> > > > > > > > > > > and
> > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> `7.59.0.Final`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> depending
> > > on
> > > > > > > > > kiegroup's
> > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > >> > > > * This module was removed from the KIE
> codebase
> > > > > here:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > >
> > > > > > >
> https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > ,
> > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > OptaPlanner,
> > > > > > > > pointing
> > > > > > > > > to
> > > > > > > > > > > > older
> > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P5.
> `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > depending
> > > > > > > > on
> > > > > > > > > > > > Kogito
> > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P6. Category C repos are out of date and not
> > > part
> > > > of
> > > > > > the
> > > > > > > > > > > Category
> > > > > > > > > > > > A
> > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > > > version
> > > > > is
> > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > >> > > > depending on Kogito without a specific
> version,
> > > > only
> > > > > > by
> > > > > > > > > using
> > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> version is
> > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> OptaPlanner
> > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow
> has
> > > > its
> > > > > > E2E
> > > > > > > > > > disabled
> > > > > > > > > > > > >> after
> > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > > solution,
> > > > > > as
> > > > > > > > they
> > > > > > > > > > > both
> > > > > > > > > > > > >> > > > suffer from the circular dependency between
> > > > > Category A
> > > > > > > and
> > > > > > > > > > > > Category
> > > > > > > > > > > > >> B.
> > > > > > > > > > > > >> > > > As Category A and Category B are both
> streams
> > > that
> > > > > > have
> > > > > > > > been
> > > > > > > > > > > > really
> > > > > > > > > > > > >> > > > active, I see this as a blocker, as there
> are
> > > > > > > > contributions
> > > > > > > > > > that
> > > > > > > > > > > > >> > > > cannot be done, given that Category A
> depends on
> > > > > > > Category
> > > > > > > > B
> > > > > > > > > > > with a
> > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> understood
> > > > as
> > > > > > > > > technical
> > > > > > > > > > > > debt.
> > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> something
> > > > > we'll
> > > > > > > > always
> > > > > > > > > > be
> > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > > > matter
> > > > > of
> > > > > > > > > making
> > > > > > > > > > > them
> > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P7 is an isolated problem that won't impact
> the
> > > > > > > structure
> > > > > > > > or
> > > > > > > > > > > > >> anything
> > > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > > regression
> > > > > > we
> > > > > > > > > > > > introduced
> > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> Apache KIE
> > > > 10,
> > > > > > and
> > > > > > > > > that
> > > > > > > > > > > P5,
> > > > > > > > > > > > >> P6,
> > > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems
> left
> > > to
> > > > > > > discuss
> > > > > > > > > are
> > > > > > > > > > P1
> > > > > > > > > > > > and
> > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > > proposal.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> from
> > > my
> > > > > > > > > experience,
> > > > > > > > > > > any
> > > > > > > > > > > > >> > > > little miscalculation can lead to our
> release
> > > not
> > > > > > > working
> > > > > > > > > out
> > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> possible,
> > > > and
> > > > > > make
> > > > > > > > > > > > everything
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> release,
> > > > bear
> > > > > > > with
> > > > > > > > > me.
> > > > > > > > > > > I'll
> > > > > > > > > > > > >> lay
> > > > > > > > > > > > >> > > > out a timeline of events that need to
> happen in
> > > > > order
> > > > > > > for
> > > > > > > > > our
> > > > > > > > > > > > >> release
> > > > > > > > > > > > >> > > > to be published, with all artifacts ending
> up in
> > > > the
> > > > > > > right
> > > > > > > > > > > places,
> > > > > > > > > > > > >> but
> > > > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > As you saw at the beginning of this email,
> all
> > > the
> > > > > > > > attempts
> > > > > > > > > we
> > > > > > > > > > > > made
> > > > > > > > > > > > >> > > > left us with the circular dependency
> showing up
> > > > at a
> > > > > > > > > different
> > > > > > > > > > > > >> place,
> > > > > > > > > > > > >> > > > but something all these places have in
> common is
> > > > > that
> > > > > > > > > they're
> > > > > > > > > > > all
> > > > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > The first part of my proposal is the
> following:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > > > Quarkus
> > > > > > Dev
> > > > > > > > UIs
> > > > > > > > > > from
> > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > > > Management
> > > > > > > and
> > > > > > > > > > Task
> > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> `kie-tools`.
> > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > images
> > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > >> > > > S3. We move the entire
> > > > `kogito-serverless-operator`
> > > > > > repo
> > > > > > > > > > inside
> > > > > > > > > > > a
> > > > > > > > > > > > >> new
> > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> problems
> > > > P1
> > > > > > and
> > > > > > > > P2.
> > > > > > > > > Of
> > > > > > > > > > > > >> course
> > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > >>
> > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This doesn't come without consequences, of
> > > course,
> > > > > as
> > > > > > > the
> > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> `kogito-swf-builder`
> > > > > images,
> > > > > > > and
> > > > > > > > > the
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be moving
> > > from
> > > > > > > > Category A
> > > > > > > > > > to
> > > > > > > > > > > > >> > > > Category B. This move would make them have
> to
> > > > > > reference
> > > > > > > > > > > Category A
> > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > > `kogito-images`
> > > > > > > > > and
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` are already
> their
> > > own
> > > > > > > > > > "sub-stream"
> > > > > > > > > > > > >> inside
> > > > > > > > > > > > >> > > > Category A, though, contributions made in a
> > > > > cross-repo
> > > > > > > > > fashion
> > > > > > > > > > > to
> > > > > > > > > > > > >> this
> > > > > > > > > > > > >> > > > "sub-stream" will continue being possible,
> now
> > > > via a
> > > > > > > > single
> > > > > > > > > PR
> > > > > > > > > > > to
> > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> Category A
> > > and
> > > > > > > > Category
> > > > > > > > > B
> > > > > > > > > > > will
> > > > > > > > > > > > >> > > > continue not being possible, and a 1-week
> delay
> > > > > > between
> > > > > > > > > > merging
> > > > > > > > > > > > >> > > > something on Category A and using it on
> > > Category B
> > > > > > will
> > > > > > > > > still
> > > > > > > > > > > > >> happen.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> however,
> > > > > does
> > > > > > > > allow
> > > > > > > > > > for
> > > > > > > > > > > > >> sparse
> > > > > > > > > > > > >> > > > checkouts and partial builds, so working
> with a
> > > > > subset
> > > > > > > of
> > > > > > > > > the
> > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > >> > > > is possible and encouraged. Making changes
> only
> > > to
> > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example,
> will
> > > > > have
> > > > > > > the
> > > > > > > > PR
> > > > > > > > > > > > checks
> > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > >> > > > We're not compromising when running partial
> > > builds
> > > > > > too.
> > > > > > > We
> > > > > > > > > > know
> > > > > > > > > > > > that
> > > > > > > > > > > > >> > > > the entire repo will continue working even
> after
> > > > > only
> > > > > > > > > > building a
> > > > > > > > > > > > >> small
> > > > > > > > > > > > >> > > > subset of the changes. Doing partial or full
> > > > builds
> > > > > is
> > > > > > > > > > > > automatically
> > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> proposing we
> > > > > move a
> > > > > > > > bunch
> > > > > > > > > > of
> > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see
> this
> > > as a
> > > > > > > > TEMPORARY
> > > > > > > > > > > > >> solution
> > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host
> some
> > > > > > additional
> > > > > > > > > stuff
> > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> continue
> > > > > moving
> > > > > > > > > > forward.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> > > > became a
> > > > > > > > > polyglot
> > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > >> > > > out of necessity, and although I'm really
> proud
> > > of
> > > > > > what
> > > > > > > we
> > > > > > > > > > > > achieved
> > > > > > > > > > > > >> > > > there so far, I don't think `kie-tools` has
> a
> > > > setup
> > > > > > that
> > > > > > > > is
> > > > > > > > > > > > suitable
> > > > > > > > > > > > >> > > > for all the different nuances that compose
> our
> > > > > > > community.
> > > > > > > > > I'm
> > > > > > > > > > > well
> > > > > > > > > > > > >> > > > aware that a polyglot monorepo that does not
> > > > follow
> > > > > > > > > widespread
> > > > > > > > > > > > >> > > > conventions will scare some people away,
> and as
> > > > much
> > > > > > as
> > > > > > > > > we've
> > > > > > > > > > > > tried
> > > > > > > > > > > > >> to
> > > > > > > > > > > > >> > > > make build instructions clear, we can't
> always
> > > get
> > > > > > past
> > > > > > > > the
> > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > > ecosystem.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > With all that said, I keep thinking this is
> the
> > > > best
> > > > > > > > course
> > > > > > > > > of
> > > > > > > > > > > > >> action
> > > > > > > > > > > > >> > > > for us right now. We keep most of our stuff
> > > > > unchanged,
> > > > > > > we
> > > > > > > > > > > unblock
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> > > > release, and we have a working setup that
> will
> > > > suit
> > > > > us
> > > > > > > > well
> > > > > > > > > > > while
> > > > > > > > > > > > we
> > > > > > > > > > > > >> > > > discuss and reach a conclusion regarding the
> > > > future
> > > > > of
> > > > > > > our
> > > > > > > > > > > > codebase
> > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Let me paint a quick picture here of what
> our
> > > code
> > > > > > base
> > > > > > > > > would
> > > > > > > > > > > look
> > > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > > accepted:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > >> > > > A
> > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > B
> > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > > >> > > > E
> incubator-kie-kogito-online-staging
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves entirely
> > > inside
> > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> images and
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> `kie-tools`,
> > > > > there
> > > > > > > are
> > > > > > > > > no
> > > > > > > > > > > > cycles
> > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > granularly
> > > > > > build:
> > > > > > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> (containing
> > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > >> and
> > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> (contents
> > > from
> > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > The second part of the proposal is the
> release
> > > > > process
> > > > > > > > > itself,
> > > > > > > > > > > > >> > > > assuming the structure above is what we
> have.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used
> as
> > > > > cutting
> > > > > > > > point
> > > > > > > > > > for
> > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > >> > > > 2. Update Category B repos to point to this
> > > > > > timestamped
> > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > >> and
> > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > >> > > > 3. At this point, with everything working,
> we
> > > can
> > > > > > branch
> > > > > > > > out
> > > > > > > > > > to
> > > > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> > > SNAPSHOT
> > > > > > tag,
> > > > > > > > and
> > > > > > > > > > > > >> Category B
> > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> update
> > > > their
> > > > > > > > versions
> > > > > > > > > > to
> > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> Category
> > > A
> > > > > > repos
> > > > > > > > > using
> > > > > > > > > > > the
> > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > >> > > > 6. At this point, we can vote on the release
> > > based
> > > > > on
> > > > > > > the
> > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > >> > > > branches, given we don't expect any code
> changes
> > > > > > > anymore.
> > > > > > > > > > > > >> > > > 7. After voting passes, we're good to start
> the
> > > > > > release
> > > > > > > > > > process.
> > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > manual/automated
> > > > > > > release
> > > > > > > > > > > process,
> > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> pushed to
> > > > Git,
> > > > > > and
> > > > > > > > > built
> > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> artifacts
> > > > to
> > > > > be
> > > > > > > > > > > propagated
> > > > > > > > > > > > on
> > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > manual/automated
> > > > > > > release
> > > > > > > > > > > > process,
> > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> pushed to
> > > > Git,
> > > > > > and
> > > > > > > > > built
> > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > >> > > > 12. Category E repos can be manually tagged
> with
> > > > > > 10.0.0
> > > > > > > > from
> > > > > > > > > > > their
> > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > More needs to be discussed if we're
> planning to
> > > > > > maintain
> > > > > > > > > > > multiple
> > > > > > > > > > > > >> > > > release streams in parallel, but I guess it
> can
> > > > wait
> > > > > > for
> > > > > > > > > after
> > > > > > > > > > > > >> Apache
> > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> forward
> > > to
> > > > > > > hearing
> > > > > > > > > back
> > > > > > > > > > > > from
> > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Of course, alternative solutions are
> possible.
> > > > This
> > > > > > > email,
> > > > > > > > > > > > however,
> > > > > > > > > > > > >> > > > summarizes my view of how we should attack
> the
> > > > > > problem,
> > > > > > > > > > > > considering
> > > > > > > > > > > > >> > > > disruption, required effort, the release
> process
> > > > > > itself,
> > > > > > > > and
> > > > > > > > > > > > >> history.
> > > > > > > > > > > > >> > > > Feel free to propose alternatives. This is
> not a
> > > > > > voting
> > > > > > > > > > thread.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >>
> > > > > > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <al...@porcelli.me>.
Ricardo,
I think it's more than fair to ask to preserve the original repos, as
this solution is proposed as TEMPORARY.
However, the devil is in the details.... could you expand a bit in
steps how you see the COPYING and the contributions still flow to the
right repos work?
btw; I don't think we should account for fear or feelings about
things.. We should focus on plans and facts.
On Wed, Mar 13, 2024 at 9:14 AM ricardo zanini fernandes
<ri...@gmail.com> wrote:
>
> Hi!
>
> Clearly, you all understand that moving images and the operator to
> kie-tools is a workaround and wrong in all possible scenarios, right? We
> won't undo once we merge. I'm pretty positive that once we have a release
> train going people will add all the obstacles they can add saying "It's
> working, let's not change it".
>
> Also, I understand that we need to unblock the release. We can compromise
> in COPYING the code, do the release, and then make the necessary changes.
> Images and cloud code are *integration platforms*. Should be the last in a
> stream. Tooling SHOULD NOT, in any case, depend on the images to build.
>
> So we can:
>
> 1. Accept Tiago's proposal (very well detailed, thanks!) but COPYING the
> code base, not MERGING. The contributions still flow to the right repos.
> 2. After release we:
> 1. Move the CLI to the operator repo, removing this dependency from
> tools to image
> 2. Adjust the CI
> 3. Remove the copied code
>
> Moving forward, I'd like to see a clear boundary between the projects (as
> stated in the temporary website). At the moment, we do not have. And it's
> hard for anyone from outside to understand what we are doing.
>
> On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me> wrote:
>
> > Francisco and Gabriele,
> >
> > I understand and acknowledge your desire to find the “right” solution
> > instead to work on a temporary “patch” - however without a detailed
> > proposal I don’t think we can properly evaluate the impact of your
> > suggestion.
> >
> > When I spoke with different SMEs that included tools and CI, the
> > guesstimate for making the necessary changes on CI and codebase to
> > basically have images and operators in the end of the build chain is
> > something like 2 months of effort. Another impact that needs to be
> > discussed is that KIE Tools repo had to be injected in the middle of all
> > pipelines - forcing all PR checks and nightlies to build all repos (PR
> > checks will likely take 12+ hours… I even heard that it could be even 24
> > hours).
> >
> > Based on the input above, I think it’s quite risk to move in such direction
> > without a more detailed plan… because 2 months could be turned easily in 6!
> > And this is exactly what happened when we guessed that moving to Apache
> > would take no more than 3 months. But here we are.
> >
> > I really strongly suggest that we focus on a release that could be
> > achievable in less than a month from now, and we - after release - have a
> > in depth discussion about the overall codebase and ci organization.
> >
> >
> > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > gabriele.cardosi@gmail.com>
> > wrote:
> >
> > > Alex,
> > > my suggestion is to move the building of all docker images, from whatever
> > > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > > invoked after all the others.
> > > I'm not sure if this would solve all the issues, and since I could not
> > > enter in the details of all the involved code, my suggestion may be too
> > > naive.
> > > Having spent almost all of the last year in CI, I may say that, at least
> > > for the kie-tools repo, removing the image build step from it should not
> > be
> > > too difficult (since it is an issue we already faced and solved).
> > > If, with "detailed proposal", you mean a complete list of all modules to
> > be
> > > moved and dependency refactoring, of course I can not provide it right
> > now.
> > >
> > > Anyway, I share the concern from Francisco: undoing something is almost
> > > always harder than doing it "rightly" from scratch...
> > >
> > >
> > >
> > >
> > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti <
> > > ftirados@redhat.com> ha scritto:
> > >
> > > > I do not think estimations should be the only driver to make a
> > decision,
> > > > especially when the current proposal is conceptually incompatible with
> > > the
> > > > multi repo approach that is taken elsewhere in the project.
> > > > Given my knowledge of the CI it is nearly impossible for me to give a
> > > fair
> > > > estimate of how much it might take to achieve step 2) of my previous
> > > e-mail
> > > > . It might take a while or it might be pretty easy after all, I don't
> > > > really know, but I think it will be a good idea if some of the experts
> > > on
> > > > CI in the team (the ones that set up the pipeline, which was a huge
> > > > achievement) give an estimate, not me. Estimating how much it takes to
> > > > merge two existing repos (without altering CI) is easier, but it does
> > not
> > > > mean we are doing the right thing.
> > > > My main concern is that it will be very difficult for me to explain to
> > > > someone that arrives new to the team, that having experts on CI on the
> > > > team, we decided to merge two repos (once merged, it would be rather
> > > > difficult to unmerge) rather than fix the CI, because of expediency.
> > > >
> > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> > > > wrote:
> > > >
> > > > > Francisco,
> > > > >
> > > > > Please take the time to make the more in depth analysis needed and
> > > > provide
> > > > > a more detailed plan… so we - as community- can evaluate the size of
> > > the
> > > > > effort. In the conceptual level you shared it’s near impossible to
> > > > estimate
> > > > > the size of the effort and compare with the current proposal.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > ftirados@redhat.com> wrote:
> > > > >
> > > > > > I think I already did a high level proposal.
> > > > > > 1) Remove all dependencies from tooling to images, so images
> > depend
> > > on
> > > > > > tooling but tooling does not depend on images.
> > > > > > 2) Then change CI to deal with tooling repo before dealing with
> > > images
> > > > > > repo.
> > > > > > I understand that CI details are tricky and since I'm not familiar
> > > with
> > > > > CI
> > > > > > in any way, I barely can make a low level design, but we do not
> > need
> > > to
> > > > > fix
> > > > > > everything, just achieve 2), a change of compilation order.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <al...@porcelli.me>
> > > > wrote:
> > > > > >
> > > > > > > Francisco and Grabriele,
> > > > > > >
> > > > > > > You may not like or understand why the current state of the CI is
> > > > like
> > > > > > > that… actually has been in Red Hat and has been replicated in
> > > Apache
> > > > as
> > > > > > > used to be….
> > > > > > >
> > > > > > > But the fact is that this is the current reality.
> > > > > > >
> > > > > > > If you disagree with the current plan, please provide a detailed
> > > > > > > alternative so we, as community, can better evaluate the pros and
> > > > cons
> > > > > of
> > > > > > > each proposal.
> > > > > > >
> > > > > > >
> > > > > > > I think it’s also fair to say that, post 10 release we need to
> > > have a
> > > > > > much
> > > > > > > in depth discussion about how our codebase is organized, it’s
> > clear
> > > > > that
> > > > > > > it’s not working.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > As Francisco said,
> > > > > > > > I also have the impression that the "images" (if we are talking
> > > of
> > > > > > docker
> > > > > > > > images) should be the very last one to be built, in a
> > standalone
> > > > > repo.
> > > > > > > > That way, they may "combine" artifacts that are built in
> > > different
> > > > > > repos,
> > > > > > > > regardless of the order in which those are built.
> > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools) maybe
> > > > could
> > > > > > > > simplify the situation a bit.
> > > > > > > > (I also think there are some statements of undisputable needs
> > > while
> > > > > > they
> > > > > > > > are, actually, just technical choices.
> > > > > > > > Anyway, this latter point is for longer, following,
> > discussion.)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > Tirado
> > > > > Sarti
> > > > > > <
> > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > >
> > > > > > > > > Alex,
> > > > > > > > > There are two assumptions that deserve further discussion:
> > > > > > > > > 1) That tool has to be the last to build. why? it does not
> > have
> > > > > more
> > > > > > > > sense
> > > > > > > > > to build final images after everything else has been built?-
> > > > > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> > > > bigger
> > > > > > than
> > > > > > > > the
> > > > > > > > > impact (long term consequences) of consolidating two
> > unrelated
> > > > > piece
> > > > > > of
> > > > > > > > > software within the same repository.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > alex@porcelli.me
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco,
> > > > > > > > > >
> > > > > > > > > > This was discussed as an alternative solution, however it
> > has
> > > > > major
> > > > > > > > > impact
> > > > > > > > > > on CI and there’s also the fact Tool has been always the
> > last
> > > > to
> > > > > > > build
> > > > > > > > > and
> > > > > > > > > > has no Snapshot published (actually in JavaScript world
> > there
> > > > is
> > > > > no
> > > > > > > > > > snapshot concept).
> > > > > > > > > >
> > > > > > > > > > So, based on our evaluation… the proposal here is the least
> > > > > > > disruptive
> > > > > > > > > and
> > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > _____________
> > > > > > > > > > Alex Porcelli
> > > > > > > > > > http://porcelli.me
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > > Sarti <
> > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > After kie-tools, sorry. I think we are not embracing the
> > > fact
> > > > > > that
> > > > > > > > > > > kogito-images depend on kie-tools, because we want those
> > > > images
> > > > > > to
> > > > > > > > > > include
> > > > > > > > > > > tools.
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado
> > > > Sarti
> > > > > <
> > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > It can be an alternative solution to move
> > > > kn-plugin-workflow
> > > > > to
> > > > > > > > > > > > kogito-images (so there is not longer dependency from
> > > tools
> > > > > to
> > > > > > > > > images)
> > > > > > > > > > > and
> > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > Martinez
> > > > <
> > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > >>
> > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > >> escribió:
> > > > > > > > > > > >>
> > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > alex@porcelli.me
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > > +1
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > I spent the last day or so working closely with
> > > Tiago,
> > > > > > > > exploring
> > > > > > > > > > > >> > different
> > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > evaluating
> > > > > > the
> > > > > > > > > > overall
> > > > > > > > > > > >> > release
> > > > > > > > > > > >> > > procedure steps required. I agree with the
> > proposal
> > > as
> > > > > the
> > > > > > > > most
> > > > > > > > > > > >> > > viable option for unblocking the 10 release in the
> > > > > > > reasonable
> > > > > > > > > time
> > > > > > > > > > > >> frame.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > >> > wrote:
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time, as
> > > this
> > > > > > > matter
> > > > > > > > > > > >> requires a
> > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > > > > according
> > > > > > > to
> > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > > > > >> > > > (
> > > > > > > > > >
> > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > ),
> > > > > > > > > > > >> > > > many of us were working towards removing a
> > > circular
> > > > > > > > dependency
> > > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > > `kie-tools`.
> > > > > > > As
> > > > > > > > we
> > > > > > > > > > > >> > > > progressed towards a solution, we kept finding
> > the
> > > > > > > circular
> > > > > > > > > > > >> dependency
> > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of
> > the
> > > > > things
> > > > > > > we
> > > > > > > > > did,
> > > > > > > > > > > and
> > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Right now, even though we started the effort to
> > > move
> > > > > the
> > > > > > > > > Quarkus
> > > > > > > > > > > Dev
> > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been able
> > to
> > > > do
> > > > > it
> > > > > > > > yet,
> > > > > > > > > as
> > > > > > > > > > > >> we've
> > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17, Maven
> > > > 3.9.6,
> > > > > > and
> > > > > > > > > > Quarkus
> > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > This
> > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > >> > > >
> > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > .
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > C | 03. incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > Y | 04. incubator-kie-kogito-images
> > > > > > > > > > > >> > > > C | 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > >> > > > E | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > >> > > > * and
> > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > depend
> > > > > > > > > > > >> on
> > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`,
> > > we
> > > > > > > would've
> > > > > > > > > > had:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > > >> > > > Y | 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > >> > > > L | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > >> > > > * and `kogito-images`/kogito-swf-devmode
> > > > > depends
> > > > > > > on
> > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > > > > `kie-tools`,
> > > > > > > > we
> > > > > > > > > > > >> would've
> > > > > > > > > > > >> > > > had:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > 04. incubator-kie-kogito-images
> > > > > > > > > > > >> > > > C |==> 05.
> > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > >> > > > C | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > > E
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > depends
> > > > on
> > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Clearly, we have a much bigger problem than a
> > > simple
> > > > > > > > circular
> > > > > > > > > > > >> > dependency.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > people,
> > > > > it's
> > > > > > > been
> > > > > > > > > > > really
> > > > > > > > > > > >> > > > hard coming up with a simple solution that makes
> > > it
> > > > > > > possible
> > > > > > > > > to
> > > > > > > > > > > >> build
> > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving the way
> > > > > > everyone
> > > > > > > is
> > > > > > > > > > used
> > > > > > > > > > > to
> > > > > > > > > > > >> > > > contributing to the multiple repositories we
> > have.
> > > > > More
> > > > > > > than
> > > > > > > > > > that,
> > > > > > > > > > > >> > > > while making this assessment, I found more
> > > problems
> > > > > > that,
> > > > > > > in
> > > > > > > > > my
> > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > In light of that difficulty, I'm coming forward
> > > with
> > > > > my
> > > > > > > > > proposal
> > > > > > > > > > > for
> > > > > > > > > > > >> > > > the Apache KIE release process, so we can use
> > > > Apache's
> > > > > > > > > > mechanisms
> > > > > > > > > > > to
> > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about this
> > > > really
> > > > > > > > > > complicated
> > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > > current
> > > > > > > > situation
> > > > > > > > > > of
> > > > > > > > > > > >> our
> > > > > > > > > > > >> > > > codebase, as well as problems I can currently
> > see.
> > > > > I'll
> > > > > > > > start
> > > > > > > > > > with
> > > > > > > > > > > >> an
> > > > > > > > > > > >> > > > analysis of the repositories and their purposes,
> > > > point
> > > > > > out
> > > > > > > > > some
> > > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > > release,
> > > > > > > explain
> > > > > > > > > my
> > > > > > > > > > > >> > > > proposal and discuss some consequences to what
> > I'm
> > > > > > > > proposing.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > > `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> > > > `0.0.0`
> > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > >> > > > (Issues only, README should be updated @
> > > `main`.
> > > > > > Same
> > > > > > > > for
> > > > > > > > > > > GitHub
> > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy at the
> > > > > `main`
> > > > > > > > > branch.)
> > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > > > > `deploy`
> > > > > > to
> > > > > > > > > > update
> > > > > > > > > > > >> the
> > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > >> > > > (GitHub pages used to host sandbox.kie.org
> > > and
> > > > > KIE
> > > > > > > > Tools'
> > > > > > > > > > > >> Chrome
> > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > > > > >> > > > (Same as above, but for manual sanity checks
> > > > > during
> > > > > > > the
> > > > > > > > > > > staging
> > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I grouped the repositories by category, and
> > listed
> > > > > them
> > > > > > > in a
> > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > flattening
> > > > > > out a
> > > > > > > > > tree,
> > > > > > > > > > > >> there
> > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > OptaPlanner
> > > > > > > > could've
> > > > > > > > > > been
> > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category A repos are what I've been referring to
> > > as
> > > > > > > `drools`
> > > > > > > > > and
> > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is
> > inside
> > > > > that
> > > > > > > > > stream,
> > > > > > > > > > as
> > > > > > > > > > > >> the
> > > > > > > > > > > >> > > > way these repositories reference each other are
> > > > > through
> > > > > > > > Maven
> > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > > > > version.
> > > > > > > This
> > > > > > > > > > > >> mechanism
> > > > > > > > > > > >> > > > is well-known to the team, and although flawed
> > for
> > > > > > > intra-day
> > > > > > > > > > > builds
> > > > > > > > > > > >> > > > and disruptive for people in many different time
> > > > > zones,
> > > > > > it
> > > > > > > > is
> > > > > > > > > > > >> already
> > > > > > > > > > > >> > > > very comfortable for everyone to work with, I
> > > > assume.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > dedicated
> > > > > > > > > pipelines,
> > > > > > > > > > > >> which
> > > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > > cross-repo
> > > > > > PRs
> > > > > > > > > > > together
> > > > > > > > > > > >> > > > and verify that the codebase will continue
> > working
> > > > as
> > > > > > > > expected
> > > > > > > > > > > after
> > > > > > > > > > > >> > > > they're all merged. From what I could gather,
> > > there
> > > > > are
> > > > > > > some
> > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > cross-repo
> > > > PRs.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > > kogito-examples
> > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > >> > > > - kogito-images, and kogito-serverless-operator
> > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > > > > combination
> > > > > > > of
> > > > > > > > > > repos
> > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > cannot
> > > be
> > > > > > > > verified
> > > > > > > > > > > before
> > > > > > > > > > > >> > > > merging, making our contribution model dependent
> > > on
> > > > > > > > individual
> > > > > > > > > > > >> > > > contributors building stuff on their machines to
> > > > > verify
> > > > > > > that
> > > > > > > > > it
> > > > > > > > > > > >> works.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > >> > > > ,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > >> > > > ,
> > > > > > > > > > > >> > > > and
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > >> > > > .
> > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > pipelines,
> > > > > so
> > > > > > > > > please
> > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category B repos are what I've been referring to
> > > as
> > > > > > > > > `kie-tools`
> > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > repository
> > > > > > that
> > > > > > > > is
> > > > > > > > > > used
> > > > > > > > > > > >> by
> > > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > > Sandbox,
> > > > > > > > similar
> > > > > > > > > > to a
> > > > > > > > > > > >> > > > Maven archetype, if you will. The other one is
> > the
> > > > KIE
> > > > > > > Tools
> > > > > > > > > > > >> monorepo,
> > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > > system.
> > > > > > > > > Currently,
> > > > > > > > > > > KIE
> > > > > > > > > > > >> > > > Tools hosts Java libraries and apps, TypeScript
> > > > > > libraries
> > > > > > > > and
> > > > > > > > > > > apps,
> > > > > > > > > > > >> Go
> > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > `kie-tools`
> > > > > > > > monorepo
> > > > > > > > > > is
> > > > > > > > > > > >> > > > configured to work with sparse checkouts and can
> > > do
> > > > > > > partial
> > > > > > > > > > > builds.
> > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > through
> > > > > > > > timestamped
> > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > > > > introduced
> > > > > > > > that
> > > > > > > > > > > will
> > > > > > > > > > > >> > > > build and publish immutable, persistent
> > artifacts
> > > > > under
> > > > > > a
> > > > > > > > > > version
> > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > > published
> > > > > > > weekly
> > > > > > > > > > every
> > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > evolution
> > > > > to
> > > > > > > the
> > > > > > > > > > Kogito
> > > > > > > > > > > >> > > > releases, as we're now targeting one release for
> > > all
> > > > > of
> > > > > > > > Apache
> > > > > > > > > > > KIE,
> > > > > > > > > > > >> so
> > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > An important note here is that Category B
> > > > repositories
> > > > > > > have
> > > > > > > > > been
> > > > > > > > > > > >> > > > historically kept out of any automations we used
> > > to
> > > > > > have,
> > > > > > > > way
> > > > > > > > > > back
> > > > > > > > > > > >> > > > when Kogito started and we had the Business
> > > Central
> > > > > > > (a.k.a.
> > > > > > > > > v7)
> > > > > > > > > > > >> stream
> > > > > > > > > > > >> > > > still going on. For this reason, Category B
> > > projects
> > > > > > have
> > > > > > > > > > > developed
> > > > > > > > > > > >> > > > their own automations, based on GitHub Actions.
> > > > > > Category B
> > > > > > > > > repos
> > > > > > > > > > > >> have
> > > > > > > > > > > >> > > > always depended on Category A repos using fixed
> > > > > > versions.
> > > > > > > If
> > > > > > > > > > > >> Category
> > > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > > breaking
> > > > > > > changes
> > > > > > > > > on
> > > > > > > > > > > >> > > > Category A repositories would've had the
> > potential
> > > > to
> > > > > > > break
> > > > > > > > > > > >> Category B
> > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > development
> > > > > > > > stream,
> > > > > > > > > > and
> > > > > > > > > > > >> > > > introducing unpleasant surprises for maintainers
> > > of
> > > > > > > > Category B
> > > > > > > > > > > >> repos,
> > > > > > > > > > > >> > > > as historically Category A contributors were not
> > > > > > familiar
> > > > > > > > with
> > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > through
> > > a
> > > > > > GitHub
> > > > > > > > > > Actions
> > > > > > > > > > > >> > > > workflow that builds the relevant part of the
> > > > > > `kie-tools`
> > > > > > > > > > monorepo
> > > > > > > > > > > >> for
> > > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > > pipeline
> > > > > > > itself
> > > > > > > > > are
> > > > > > > > > > > also
> > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do
> > things
> > > > > like
> > > > > > > > > > atomically
> > > > > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > > > > importantly,
> > > > > > > > it
> > > > > > > > > > > >> allows
> > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > timestamped
> > > > > > SNAPSHOT
> > > > > > > > > > > together
> > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > green.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This setup, however, makes it impossible to have
> > > > > > > cross-repo
> > > > > > > > > PRs
> > > > > > > > > > > >> > > > involving Category A and Category B
> > > simultaneously,
> > > > > with
> > > > > > > the
> > > > > > > > > > > current
> > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category C repos are kind of floating around,
> > and
> > > > I'm
> > > > > > not
> > > > > > > > sure
> > > > > > > > > > if
> > > > > > > > > > > >> > > > there's much activity going on there.
> > Regardless,
> > > as
> > > > > > > they're
> > > > > > > > > > part
> > > > > > > > > > > of
> > > > > > > > > > > >> > > > Apache KIE, they will be part of our release,
> > so I
> > > > > > listed
> > > > > > > > them
> > > > > > > > > > for
> > > > > > > > > > > >> us
> > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category D is self explanatory. There's only one
> > > > repo
> > > > > > that
> > > > > > > > has
> > > > > > > > > > > >> already
> > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > directly,
> > > > > and
> > > > > > > are
> > > > > > > > > > > either
> > > > > > > > > > > >> > > > organizational entities, or host websites, that
> > > > > > currently
> > > > > > > > are
> > > > > > > > > > not
> > > > > > > > > > > >> part
> > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This lack of unification between Category A and
> > > > > > Category B
> > > > > > > > is,
> > > > > > > > > > > IMHO,
> > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > circular
> > > > > > > > dependency
> > > > > > > > > > > >> between
> > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now can
> > > > > describe
> > > > > > > as
> > > > > > > > a
> > > > > > > > > > > >> circular
> > > > > > > > > > > >> > > > dependency between Category A and Category B.
> > The
> > > > way
> > > > > I
> > > > > > > see
> > > > > > > > > it,
> > > > > > > > > > if
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > had a single pipeline, building everything from
> > > > > `drools`
> > > > > > > to
> > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > > introduced,
> > > > > > > and
> > > > > > > > we
> > > > > > > > > > > >> > > > wouldn't be having this huge problem in our
> > hands
> > > > > right
> > > > > > > now.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > My proposal for the Apache KIE release process
> > > sees
> > > > > this
> > > > > > > > lack
> > > > > > > > > of
> > > > > > > > > > > >> > > > unification as a central problem, not only for
> > > this
> > > > > > > release
> > > > > > > > in
> > > > > > > > > > > >> > > > particular, but for the community as a whole. It
> > > is
> > > > my
> > > > > > > > belief
> > > > > > > > > > that
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > contribution
> > > > > > > should
> > > > > > > > > be
> > > > > > > > > > > >> > > > allowed to break any part of our codebase. With
> > > the
> > > > > > > > increasing
> > > > > > > > > > > >> volume
> > > > > > > > > > > >> > > > of code, and hopefully number of contributors
> > too,
> > > > we
> > > > > > > cannot
> > > > > > > > > > keep
> > > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > > things.
> > > > > > We're
> > > > > > > > all
> > > > > > > > > > > >> humans
> > > > > > > > > > > >> > > > after all, and it is our job to have mechanisms
> > in
> > > > > place
> > > > > > > to
> > > > > > > > > > > prevent
> > > > > > > > > > > >> us
> > > > > > > > > > > >> > > > from unwillingly making mistakes. Especially
> > when
> > > > > these
> > > > > > > > > mistakes
> > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > individually,
> > > > > > > > > probably
> > > > > > > > > > > >> can't
> > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on
> > > > > > > kiegroup's
> > > > > > > > > KIE
> > > > > > > > > > > >> Tools
> > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > `kogito-images`
> > > > > > > > depending
> > > > > > > > > on
> > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > kiegroup's
> > > > > > > > `lienzo`
> > > > > > > > > > and
> > > > > > > > > > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps` depending
> > on
> > > > > > > > kiegroup's
> > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > >> > > > * This module was removed from the KIE codebase
> > > > here:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > >> > > >
> > > > > > > > > > >
> > > > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > ,
> > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > OptaPlanner,
> > > > > > > pointing
> > > > > > > > to
> > > > > > > > > > > older
> > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > depending
> > > > > > > on
> > > > > > > > > > > Kogito
> > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P6. Category C repos are out of date and not
> > part
> > > of
> > > > > the
> > > > > > > > > > Category
> > > > > > > > > > > A
> > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > > version
> > > > is
> > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > >> > > > depending on Kogito without a specific version,
> > > only
> > > > > by
> > > > > > > > using
> > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version is
> > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has
> > > its
> > > > > E2E
> > > > > > > > > disabled
> > > > > > > > > > > >> after
> > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > solution,
> > > > > as
> > > > > > > they
> > > > > > > > > > both
> > > > > > > > > > > >> > > > suffer from the circular dependency between
> > > > Category A
> > > > > > and
> > > > > > > > > > > Category
> > > > > > > > > > > >> B.
> > > > > > > > > > > >> > > > As Category A and Category B are both streams
> > that
> > > > > have
> > > > > > > been
> > > > > > > > > > > really
> > > > > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > > > > contributions
> > > > > > > > > that
> > > > > > > > > > > >> > > > cannot be done, given that Category A depends on
> > > > > > Category
> > > > > > > B
> > > > > > > > > > with a
> > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be understood
> > > as
> > > > > > > > technical
> > > > > > > > > > > debt.
> > > > > > > > > > > >> > > > Depending on unmaintained projects is something
> > > > we'll
> > > > > > > always
> > > > > > > > > be
> > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > > matter
> > > > of
> > > > > > > > making
> > > > > > > > > > them
> > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P7 is an isolated problem that won't impact the
> > > > > > structure
> > > > > > > or
> > > > > > > > > > > >> anything
> > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > regression
> > > > > we
> > > > > > > > > > > introduced
> > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE
> > > 10,
> > > > > and
> > > > > > > > that
> > > > > > > > > > P5,
> > > > > > > > > > > >> P6,
> > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems left
> > to
> > > > > > discuss
> > > > > > > > are
> > > > > > > > > P1
> > > > > > > > > > > and
> > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > proposal.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I'll try to be very meticulous here, since from
> > my
> > > > > > > > experience,
> > > > > > > > > > any
> > > > > > > > > > > >> > > > little miscalculation can lead to our release
> > not
> > > > > > working
> > > > > > > > out
> > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > >> > > > end. To try and avoid that as much as possible,
> > > and
> > > > > make
> > > > > > > > > > > everything
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > can to have a successful Apache KIE 10 release,
> > > bear
> > > > > > with
> > > > > > > > me.
> > > > > > > > > > I'll
> > > > > > > > > > > >> lay
> > > > > > > > > > > >> > > > out a timeline of events that need to happen in
> > > > order
> > > > > > for
> > > > > > > > our
> > > > > > > > > > > >> release
> > > > > > > > > > > >> > > > to be published, with all artifacts ending up in
> > > the
> > > > > > right
> > > > > > > > > > places,
> > > > > > > > > > > >> but
> > > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As you saw at the beginning of this email, all
> > the
> > > > > > > attempts
> > > > > > > > we
> > > > > > > > > > > made
> > > > > > > > > > > >> > > > left us with the circular dependency showing up
> > > at a
> > > > > > > > different
> > > > > > > > > > > >> place,
> > > > > > > > > > > >> > > > but something all these places have in common is
> > > > that
> > > > > > > > they're
> > > > > > > > > > all
> > > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > The first part of my proposal is the following:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > > Quarkus
> > > > > Dev
> > > > > > > UIs
> > > > > > > > > from
> > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > > Management
> > > > > > and
> > > > > > > > > Task
> > > > > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > images
> > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > >> > > > S3. We move the entire
> > > `kogito-serverless-operator`
> > > > > repo
> > > > > > > > > inside
> > > > > > > > > > a
> > > > > > > > > > > >> new
> > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve problems
> > > P1
> > > > > and
> > > > > > > P2.
> > > > > > > > Of
> > > > > > > > > > > >> course
> > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > >>
> > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This doesn't come without consequences, of
> > course,
> > > > as
> > > > > > the
> > > > > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> > > > images,
> > > > > > and
> > > > > > > > the
> > > > > > > > > > > >> > > > `kogito-serverless-operator` would be moving
> > from
> > > > > > > Category A
> > > > > > > > > to
> > > > > > > > > > > >> > > > Category B. This move would make them have to
> > > > > reference
> > > > > > > > > > Category A
> > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > `kogito-images`
> > > > > > > > and
> > > > > > > > > > > >> > > > `kogito-serverless-operator` are already their
> > own
> > > > > > > > > "sub-stream"
> > > > > > > > > > > >> inside
> > > > > > > > > > > >> > > > Category A, though, contributions made in a
> > > > cross-repo
> > > > > > > > fashion
> > > > > > > > > > to
> > > > > > > > > > > >> this
> > > > > > > > > > > >> > > > "sub-stream" will continue being possible, now
> > > via a
> > > > > > > single
> > > > > > > > PR
> > > > > > > > > > to
> > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A
> > and
> > > > > > > Category
> > > > > > > > B
> > > > > > > > > > will
> > > > > > > > > > > >> > > > continue not being possible, and a 1-week delay
> > > > > between
> > > > > > > > > merging
> > > > > > > > > > > >> > > > something on Category A and using it on
> > Category B
> > > > > will
> > > > > > > > still
> > > > > > > > > > > >> happen.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`, however,
> > > > does
> > > > > > > allow
> > > > > > > > > for
> > > > > > > > > > > >> sparse
> > > > > > > > > > > >> > > > checkouts and partial builds, so working with a
> > > > subset
> > > > > > of
> > > > > > > > the
> > > > > > > > > > > >> monorepo
> > > > > > > > > > > >> > > > is possible and encouraged. Making changes only
> > to
> > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example, will
> > > > have
> > > > > > the
> > > > > > > PR
> > > > > > > > > > > checks
> > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > >> > > > .
> > > > > > > > > > > >> > > > We're not compromising when running partial
> > builds
> > > > > too.
> > > > > > We
> > > > > > > > > know
> > > > > > > > > > > that
> > > > > > > > > > > >> > > > the entire repo will continue working even after
> > > > only
> > > > > > > > > building a
> > > > > > > > > > > >> small
> > > > > > > > > > > >> > > > subset of the changes. Doing partial or full
> > > builds
> > > > is
> > > > > > > > > > > automatically
> > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Keep in mind that, even though I'm proposing we
> > > > move a
> > > > > > > bunch
> > > > > > > > > of
> > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see this
> > as a
> > > > > > > TEMPORARY
> > > > > > > > > > > >> solution
> > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > > > > additional
> > > > > > > > stuff
> > > > > > > > > > > >> > > > TEMPORARILY so that we can release and continue
> > > > moving
> > > > > > > > > forward.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> > > became a
> > > > > > > > polyglot
> > > > > > > > > > > >> monorepo
> > > > > > > > > > > >> > > > out of necessity, and although I'm really proud
> > of
> > > > > what
> > > > > > we
> > > > > > > > > > > achieved
> > > > > > > > > > > >> > > > there so far, I don't think `kie-tools` has a
> > > setup
> > > > > that
> > > > > > > is
> > > > > > > > > > > suitable
> > > > > > > > > > > >> > > > for all the different nuances that compose our
> > > > > > community.
> > > > > > > > I'm
> > > > > > > > > > well
> > > > > > > > > > > >> > > > aware that a polyglot monorepo that does not
> > > follow
> > > > > > > > widespread
> > > > > > > > > > > >> > > > conventions will scare some people away, and as
> > > much
> > > > > as
> > > > > > > > we've
> > > > > > > > > > > tried
> > > > > > > > > > > >> to
> > > > > > > > > > > >> > > > make build instructions clear, we can't always
> > get
> > > > > past
> > > > > > > the
> > > > > > > > > > > >> prejudice
> > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > ecosystem.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > With all that said, I keep thinking this is the
> > > best
> > > > > > > course
> > > > > > > > of
> > > > > > > > > > > >> action
> > > > > > > > > > > >> > > > for us right now. We keep most of our stuff
> > > > unchanged,
> > > > > > we
> > > > > > > > > > unblock
> > > > > > > > > > > >> the
> > > > > > > > > > > >> > > > release, and we have a working setup that will
> > > suit
> > > > us
> > > > > > > well
> > > > > > > > > > while
> > > > > > > > > > > we
> > > > > > > > > > > >> > > > discuss and reach a conclusion regarding the
> > > future
> > > > of
> > > > > > our
> > > > > > > > > > > codebase
> > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Let me paint a quick picture here of what our
> > code
> > > > > base
> > > > > > > > would
> > > > > > > > > > look
> > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > accepted:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > >> > > > A
> > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > B
> > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > >> > > > E incubator-kie-kogito-online-staging
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > > > > >> > > > `kogito-serverless-operator` moves entirely
> > inside
> > > > > > > > > `kie-tools`.
> > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > > > > > > > > >> > > > `kogito-serverless-operator` inside `kie-tools`,
> > > > there
> > > > > > are
> > > > > > > > no
> > > > > > > > > > > cycles
> > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > granularly
> > > > > build:
> > > > > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > >> and
> > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > >> > > > 4. packages/sonataflow-operator (contents
> > from
> > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > The second part of the proposal is the release
> > > > process
> > > > > > > > itself,
> > > > > > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as
> > > > cutting
> > > > > > > point
> > > > > > > > > for
> > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > >> > > > 2. Update Category B repos to point to this
> > > > > timestamped
> > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > >> and
> > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > >> > > > 3. At this point, with everything working, we
> > can
> > > > > branch
> > > > > > > out
> > > > > > > > > to
> > > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> > SNAPSHOT
> > > > > tag,
> > > > > > > and
> > > > > > > > > > > >> Category B
> > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > >> > > > 4. All Category A and Category B repos update
> > > their
> > > > > > > versions
> > > > > > > > > to
> > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > >> > > > 5. Update Category B repos to point to Category
> > A
> > > > > repos
> > > > > > > > using
> > > > > > > > > > the
> > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > >> > > > 6. At this point, we can vote on the release
> > based
> > > > on
> > > > > > the
> > > > > > > > > > `10.0.x`
> > > > > > > > > > > >> > > > branches, given we don't expect any code changes
> > > > > > anymore.
> > > > > > > > > > > >> > > > 7. After voting passes, we're good to start the
> > > > > release
> > > > > > > > > process.
> > > > > > > > > > > >> > > > 8. Category A repos follow their
> > manual/automated
> > > > > > release
> > > > > > > > > > process,
> > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to
> > > Git,
> > > > > and
> > > > > > > > built
> > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > >> > > > 9. We wait a little bit for Category A artifacts
> > > to
> > > > be
> > > > > > > > > > propagated
> > > > > > > > > > > on
> > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > >> > > > 10. Category B repos follow their
> > manual/automated
> > > > > > release
> > > > > > > > > > > process,
> > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to
> > > Git,
> > > > > and
> > > > > > > > built
> > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > >> > > > 12. Category E repos can be manually tagged with
> > > > > 10.0.0
> > > > > > > from
> > > > > > > > > > their
> > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > More needs to be discussed if we're planning to
> > > > > maintain
> > > > > > > > > > multiple
> > > > > > > > > > > >> > > > release streams in parallel, but I guess it can
> > > wait
> > > > > for
> > > > > > > > after
> > > > > > > > > > > >> Apache
> > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Thank you for reading, and I'm looking forward
> > to
> > > > > > hearing
> > > > > > > > back
> > > > > > > > > > > from
> > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Of course, alternative solutions are possible.
> > > This
> > > > > > email,
> > > > > > > > > > > however,
> > > > > > > > > > > >> > > > summarizes my view of how we should attack the
> > > > > problem,
> > > > > > > > > > > considering
> > > > > > > > > > > >> > > > disruption, required effort, the release process
> > > > > itself,
> > > > > > > and
> > > > > > > > > > > >> history.
> > > > > > > > > > > >> > > > Feel free to propose alternatives. This is not a
> > > > > voting
> > > > > > > > > thread.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >>
> > > > > > > > >
> > > > > ---------------------------------------------------------------------
> > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > dev-help@kie.apache.org
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by ricardo zanini fernandes <ri...@gmail.com>.
Not only the community. I'm honestly tired as I believe many of you are as
well.
Alex, the devui can move freely, we use the last 0.32.0 version released,
won't break anything. I think the lack of knowledge you have about how the
images and the operator work, might make it harder to identify the
bottlenecks.
On Wed, Mar 13, 2024 at 11:03 AM Yeser Amer <ya...@apache.org> wrote:
> Thank you Tiago for your comprehensive description.
>
> From a purely technical point, I tend to agree with Francisco.
> And yes, it happened in the past that we took accountability for a future
> change and eventually we forgot or we ignored that.
>
> But we can't only consider the technical point of taking this decision.
> Tibor raised, from my point of view, the most important point to consider
> in this case, and I fully agree with him.
>
> Take this conversion as an example
> https://kie.zulipchat.com/#narrow/stream/232676-kogito/topic/Kogito.20and.20SpringBoot.203
>
> Our community users are getting frustrated to wait for a release and a
> precise release date.
>
> My suggestion is then to proceed with Tiago's proposal as a Temporary
> solution to unblock the release, and in parallel start a conversion to
> define a more correct solution from a structural/technical point of view.
>
> Yes, there's the risk that agreeing and applying a solution may require
> more time and it can be forgotten it in our backlog tasks, but on the other
> hand, we have an even bigger risk of losing our user community's trust.
>
> In that sense, I would consider any solution that may force us to have a
> real and quick follow-up to tackle it just before the release (and seems to
> me Ricardo proposed a solution that goes in that direction)
>
> (P.S. Problem 3 can be solved in 1 day, I can do it during my free time :)
> )
>
>
>
>
> On 2024/03/13 13:32:08 Alex Porcelli wrote:
> > Francisco,
> >
> > As I wrote earlier, I had a conversation with Jan - that is our
> > community CI expert - and he said that he guesses that it would take
> > about 2 months to make CI changes implied in your comments.
> >
> > He also mentioned that if Tristan was around and could dedicate his
> > time on this, he believes that Tristan could make the same changes
> > potentially in about 2 weeks.
> >
> >
> > On Wed, Mar 13, 2024 at 9:26 AM Francisco Javier Tirado Sarti
> > <ft...@redhat.com> wrote:
> > >
> > > @Ricardo Zanini <za...@redhat.com> The main issue I have is why we
> > > conclude 1 takes less time than 2?. If I understood 1) completely, it
> also
> > > requires CI adjustments (at tools repo level, not at overall stream
> level),
> > > so I hardly see the estimation different for someone that is familiar
> with
> > > CI.
> > >
> > > On Wed, Mar 13, 2024 at 2:14 PM ricardo zanini fernandes <
> > > ricardozanini@gmail.com> wrote:
> > >
> > > > Hi!
> > > >
> > > > Clearly, you all understand that moving images and the operator to
> > > > kie-tools is a workaround and wrong in all possible scenarios,
> right? We
> > > > won't undo once we merge. I'm pretty positive that once we have a
> release
> > > > train going people will add all the obstacles they can add saying
> "It's
> > > > working, let's not change it".
> > > >
> > > > Also, I understand that we need to unblock the release. We can
> compromise
> > > > in COPYING the code, do the release, and then make the necessary
> changes.
> > > > Images and cloud code are *integration platforms*. Should be the
> last in a
> > > > stream. Tooling SHOULD NOT, in any case, depend on the images to
> build.
> > > >
> > > > So we can:
> > > >
> > > > 1. Accept Tiago's proposal (very well detailed, thanks!) but COPYING
> the
> > > > code base, not MERGING. The contributions still flow to the right
> repos.
> > > > 2. After release we:
> > > > 1. Move the CLI to the operator repo, removing this dependency
> from
> > > > tools to image
> > > > 2. Adjust the CI
> > > > 3. Remove the copied code
> > > >
> > > > Moving forward, I'd like to see a clear boundary between the
> projects (as
> > > > stated in the temporary website). At the moment, we do not have. And
> it's
> > > > hard for anyone from outside to understand what we are doing.
> > > >
> > > > On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me>
> wrote:
> > > >
> > > > > Francisco and Gabriele,
> > > > >
> > > > > I understand and acknowledge your desire to find the “right”
> solution
> > > > > instead to work on a temporary “patch” - however without a detailed
> > > > > proposal I don’t think we can properly evaluate the impact of your
> > > > > suggestion.
> > > > >
> > > > > When I spoke with different SMEs that included tools and CI, the
> > > > > guesstimate for making the necessary changes on CI and codebase to
> > > > > basically have images and operators in the end of the build chain
> is
> > > > > something like 2 months of effort. Another impact that needs to be
> > > > > discussed is that KIE Tools repo had to be injected in the middle
> of all
> > > > > pipelines - forcing all PR checks and nightlies to build all repos
> (PR
> > > > > checks will likely take 12+ hours… I even heard that it could be
> even 24
> > > > > hours).
> > > > >
> > > > > Based on the input above, I think it’s quite risk to move in such
> > > > direction
> > > > > without a more detailed plan… because 2 months could be turned
> easily in
> > > > 6!
> > > > > And this is exactly what happened when we guessed that moving to
> Apache
> > > > > would take no more than 3 months. But here we are.
> > > > >
> > > > > I really strongly suggest that we focus on a release that could be
> > > > > achievable in less than a month from now, and we - after release -
> have a
> > > > > in depth discussion about the overall codebase and ci organization.
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > gabriele.cardosi@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Alex,
> > > > > > my suggestion is to move the building of all docker images, from
> > > > whatever
> > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo,
> to be
> > > > > > invoked after all the others.
> > > > > > I'm not sure if this would solve all the issues, and since I
> could not
> > > > > > enter in the details of all the involved code, my suggestion may
> be too
> > > > > > naive.
> > > > > > Having spent almost all of the last year in CI, I may say that,
> at
> > > > least
> > > > > > for the kie-tools repo, removing the image build step from it
> should
> > > > not
> > > > > be
> > > > > > too difficult (since it is an issue we already faced and solved).
> > > > > > If, with "detailed proposal", you mean a complete list of all
> modules
> > > > to
> > > > > be
> > > > > > moved and dependency refactoring, of course I can not provide it
> right
> > > > > now.
> > > > > >
> > > > > > Anyway, I share the concern from Francisco: undoing something is
> almost
> > > > > > always harder than doing it "rightly" from scratch...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado
> Sarti
> > > > <
> > > > > > ftirados@redhat.com> ha scritto:
> > > > > >
> > > > > > > I do not think estimations should be the only driver to make a
> > > > > decision,
> > > > > > > especially when the current proposal is conceptually
> incompatible
> > > > with
> > > > > > the
> > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > Given my knowledge of the CI it is nearly impossible for me
> to give
> > > > a
> > > > > > fair
> > > > > > > estimate of how much it might take to achieve step 2) of my
> previous
> > > > > > e-mail
> > > > > > > . It might take a while or it might be pretty easy after all,
> I don't
> > > > > > > really know, but I think it will be a good idea if some of the
> > > > experts
> > > > > > on
> > > > > > > CI in the team (the ones that set up the pipeline, which was a
> huge
> > > > > > > achievement) give an estimate, not me. Estimating how much it
> takes
> > > > to
> > > > > > > merge two existing repos (without altering CI) is easier, but
> it does
> > > > > not
> > > > > > > mean we are doing the right thing.
> > > > > > > My main concern is that it will be very difficult for me to
> explain
> > > > to
> > > > > > > someone that arrives new to the team, that having experts on
> CI on
> > > > the
> > > > > > > team, we decided to merge two repos (once merged, it would be
> rather
> > > > > > > difficult to unmerge) rather than fix the CI, because of
> expediency.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> porcelli@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Francisco,
> > > > > > > >
> > > > > > > > Please take the time to make the more in depth analysis
> needed and
> > > > > > > provide
> > > > > > > > a more detailed plan… so we - as community- can evaluate the
> size
> > > > of
> > > > > > the
> > > > > > > > effort. In the conceptual level you shared it’s near
> impossible to
> > > > > > > estimate
> > > > > > > > the size of the effort and compare with the current proposal.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado
> Sarti <
> > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > >
> > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > 1) Remove all dependencies from tooling to images, so
> images
> > > > > depend
> > > > > > on
> > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > 2) Then change CI to deal with tooling repo before dealing
> with
> > > > > > images
> > > > > > > > > repo.
> > > > > > > > > I understand that CI details are tricky and since I'm not
> > > > familiar
> > > > > > with
> > > > > > > > CI
> > > > > > > > > in any way, I barely can make a low level design, but we
> do not
> > > > > need
> > > > > > to
> > > > > > > > fix
> > > > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> alex@porcelli.me
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > >
> > > > > > > > > > You may not like or understand why the current state of
> the CI
> > > > is
> > > > > > > like
> > > > > > > > > > that… actually has been in Red Hat and has been
> replicated in
> > > > > > Apache
> > > > > > > as
> > > > > > > > > > used to be….
> > > > > > > > > >
> > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > >
> > > > > > > > > > If you disagree with the current plan, please provide a
> > > > detailed
> > > > > > > > > > alternative so we, as community, can better evaluate the
> pros
> > > > and
> > > > > > > cons
> > > > > > > > of
> > > > > > > > > > each proposal.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I think it’s also fair to say that, post 10 release we
> need to
> > > > > > have a
> > > > > > > > > much
> > > > > > > > > > in depth discussion about how our codebase is organized,
> it’s
> > > > > clear
> > > > > > > > that
> > > > > > > > > > it’s not working.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > As Francisco said,
> > > > > > > > > > > I also have the impression that the "images" (if we are
> > > > talking
> > > > > > of
> > > > > > > > > docker
> > > > > > > > > > > images) should be the very last one to be built, in a
> > > > > standalone
> > > > > > > > repo.
> > > > > > > > > > > That way, they may "combine" artifacts that are built
> in
> > > > > > different
> > > > > > > > > repos,
> > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > Moving them out of all the repos
> (kogito-apps/kie-tools)
> > > > maybe
> > > > > > > could
> > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > (I also think there are some statements of
> undisputable needs
> > > > > > while
> > > > > > > > > they
> > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > > discussion.)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco
> Javier
> > > > > Tirado
> > > > > > > > Sarti
> > > > > > > > > <
> > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > >
> > > > > > > > > > > > Alex,
> > > > > > > > > > > > There are two assumptions that deserve further
> discussion:
> > > > > > > > > > > > 1) That tool has to be the last to build. why? it
> does not
> > > > > have
> > > > > > > > more
> > > > > > > > > > > sense
> > > > > > > > > > > > to build final images after everything else has been
> > > > built?-
> > > > > > > > > > > > 2) That the impact (in terms of effort now) on
> fixing CI is
> > > > > > > bigger
> > > > > > > > > than
> > > > > > > > > > > the
> > > > > > > > > > > > impact (long term consequences) of consolidating two
> > > > > unrelated
> > > > > > > > piece
> > > > > > > > > of
> > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > alex@porcelli.me
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > >
> > > > > > > > > > > > > This was discussed as an alternative solution,
> however it
> > > > > has
> > > > > > > > major
> > > > > > > > > > > > impact
> > > > > > > > > > > > > on CI and there’s also the fact Tool has been
> always the
> > > > > last
> > > > > > > to
> > > > > > > > > > build
> > > > > > > > > > > > and
> > > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> world
> > > > > there
> > > > > > > is
> > > > > > > > no
> > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > >
> > > > > > > > > > > > > So, based on our evaluation… the proposal here is
> the
> > > > least
> > > > > > > > > > disruptive
> > > > > > > > > > > > and
> > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > _____________
> > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> Tirado
> > > > > > Sarti <
> > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> embracing
> > > > the
> > > > > > fact
> > > > > > > > > that
> > > > > > > > > > > > > > kogito-images depend on kie-tools, because we
> want
> > > > those
> > > > > > > images
> > > > > > > > > to
> > > > > > > > > > > > > include
> > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > > > Tirado
> > > > > > > Sarti
> > > > > > > > <
> > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > kn-plugin-workflow
> > > > > > > > to
> > > > > > > > > > > > > > > kogito-images (so there is not longer
> dependency from
> > > > > > tools
> > > > > > > > to
> > > > > > > > > > > > images)
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique
> Gonzalez
> > > > > > Martinez
> > > > > > > <
> > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> (apache)
> > > > <
> > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> > I say +1 in order to move forward with the
> 10.
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli
> <
> > > > > > > > > alex@porcelli.me
> > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > I spent the last day or so working
> closely with
> > > > > > Tiago,
> > > > > > > > > > > exploring
> > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > >> > > options and getting deeper on the impact
> and
> > > > > > > evaluating
> > > > > > > > > the
> > > > > > > > > > > > > overall
> > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > > > proposal
> > > > > > as
> > > > > > > > the
> > > > > > > > > > > most
> > > > > > > > > > > > > > >> > > viable option for unblocking the 10
> release in
> > > > the
> > > > > > > > > > reasonable
> > > > > > > > > > > > time
> > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago
> Bento <
> > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> time,
> > > > as
> > > > > > this
> > > > > > > > > > matter
> > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes
> to read,
> > > > > > > > according
> > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As you may have followed on a separate
> thread
> > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > >
> > > > > > >
> https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > >> > > > many of us were working towards
> removing a
> > > > > > circular
> > > > > > > > > > > dependency
> > > > > > > > > > > > > > >> > > > currently present between `kogito-apps`
> and
> > > > > > > > `kie-tools`.
> > > > > > > > > > As
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> finding
> > > > > the
> > > > > > > > > > circular
> > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> breakdown of
> > > > > the
> > > > > > > > things
> > > > > > > > > > we
> > > > > > > > > > > > did,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Right now, even though we started the
> effort
> > > > to
> > > > > > move
> > > > > > > > the
> > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't
> been
> > > > able
> > > > > to
> > > > > > > do
> > > > > > > > it
> > > > > > > > > > > yet,
> > > > > > > > > > > > as
> > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java
> 17,
> > > > Maven
> > > > > > > 3.9.6,
> > > > > > > > > and
> > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > This
> > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > > >> > > >
> > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > .
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > |==> 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > C | 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > Y | 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > L |
> ==========================
> > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> `kie-tools`/extended-services
> > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > depend
> > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > > `kie-tools`,
> > > > > > we
> > > > > > > > > > would've
> > > > > > > > > > > > > had:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > C |==> 04.
> incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> `kie-tools`/kn-plugin-workflow
> > > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > >> > > > * and
> > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > depends
> > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> image to
> > > > > > > > > > `kie-tools`,
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> `kie-tools`/kn-plugin-workflow
> > > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > >> > > > * and
> `kogito-serverless-operator`
> > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> than a
> > > > > > simple
> > > > > > > > > > > circular
> > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After multiple conversations with a lot
> of
> > > > > people,
> > > > > > > > it's
> > > > > > > > > > been
> > > > > > > > > > > > > > really
> > > > > > > > > > > > > > >> > > > hard coming up with a simple solution
> that
> > > > makes
> > > > > > it
> > > > > > > > > > possible
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while
> preserving the
> > > > way
> > > > > > > > > everyone
> > > > > > > > > > is
> > > > > > > > > > > > > used
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > contributing to the multiple
> repositories we
> > > > > have.
> > > > > > > > More
> > > > > > > > > > than
> > > > > > > > > > > > > that,
> > > > > > > > > > > > > > >> > > > while making this assessment, I found
> more
> > > > > > problems
> > > > > > > > > that,
> > > > > > > > > > in
> > > > > > > > > > > > my
> > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > > > forward
> > > > > > with
> > > > > > > > my
> > > > > > > > > > > > proposal
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we
> can use
> > > > > > > Apache's
> > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate
> about
> > > > this
> > > > > > > really
> > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective
> about the
> > > > > > current
> > > > > > > > > > > situation
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> currently
> > > > > see.
> > > > > > > > I'll
> > > > > > > > > > > start
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > > purposes,
> > > > > > > point
> > > > > > > > > out
> > > > > > > > > > > > some
> > > > > > > > > > > > > > >> > > > problems that I believe are blocking
> our 10
> > > > > > release,
> > > > > > > > > > explain
> > > > > > > > > > > > my
> > > > > > > > > > > > > > >> > > > proposal and discuss some consequences
> to what
> > > > > I'm
> > > > > > > > > > > proposing.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count:
> 11)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @
> `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts
> @
> > > > `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-serverless-operator @
> > > > > > `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > >> > > > -
> incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > `0.0.0`
> > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @
> `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > >> > > > (Issues only, README should be
> updated @
> > > > > > `main`.
> > > > > > > > > Same
> > > > > > > > > > > for
> > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > > > >> > > > (The Kogito website. Develop &
> deploy at
> > > > the
> > > > > > > > `main`
> > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`.
> Push @
> > > > > > > > `deploy`
> > > > > > > > > to
> > > > > > > > > > > > > update
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> `gh-pages`
> > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > sandbox.kie.org
> > > > > > and
> > > > > > > > KIE
> > > > > > > > > > > Tools'
> > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @
> `main`
> > > > > > > > > > > > > > >> > > > (Same as above, but for manual
> sanity
> > > > checks
> > > > > > > > during
> > > > > > > > > > the
> > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I grouped the repositories by category,
> and
> > > > > listed
> > > > > > > > them
> > > > > > > > > > in a
> > > > > > > > > > > > > > >> > > > topological order. Keep in mind that
> when
> > > > > > flattening
> > > > > > > > > out a
> > > > > > > > > > > > tree,
> > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > > > OptaPlanner
> > > > > > > > > > > could've
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> referring
> > > > to
> > > > > > as
> > > > > > > > > > `drools`
> > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> OptaPlanner is
> > > > > inside
> > > > > > > > that
> > > > > > > > > > > > stream,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > way these repositories reference each
> other
> > > > are
> > > > > > > > through
> > > > > > > > > > > Maven
> > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> 999-SNAPSHOT
> > > > > > > > version.
> > > > > > > > > > This
> > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > >> > > > is well-known to the team, and although
> flawed
> > > > > for
> > > > > > > > > > intra-day
> > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > >> > > > and disruptive for people in many
> different
> > > > time
> > > > > > > > zones,
> > > > > > > > > it
> > > > > > > > > > > is
> > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> with, I
> > > > > > > assume.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Contributions made to Category A have
> some
> > > > > > dedicated
> > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> build
> > > > > > > cross-repo
> > > > > > > > > PRs
> > > > > > > > > > > > > > together
> > > > > > > > > > > > > > >> > > > and verify that the codebase will
> continue
> > > > > working
> > > > > > > as
> > > > > > > > > > > expected
> > > > > > > > > > > > > > after
> > > > > > > > > > > > > > >> > > > they're all merged. From what I could
> gather,
> > > > > > there
> > > > > > > > are
> > > > > > > > > > some
> > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > > cross-repo
> > > > > > > PRs.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps,
> and
> > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > >> > > > - optaplanner, and
> optaplanner-quickstarts
> > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs
> to any
> > > > > > > > > combination
> > > > > > > > > > of
> > > > > > > > > > > > > repos
> > > > > > > > > > > > > > >> > > > that are not part of the same
> "sub-stream"
> > > > > cannot
> > > > > > be
> > > > > > > > > > > verified
> > > > > > > > > > > > > > before
> > > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > > dependent
> > > > > > on
> > > > > > > > > > > individual
> > > > > > > > > > > > > > >> > > > contributors building stuff on their
> machines
> > > > to
> > > > > > > > verify
> > > > > > > > > > that
> > > > > > > > > > > > it
> > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with
> these
> > > > > > > pipelines,
> > > > > > > > so
> > > > > > > > > > > > please
> > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> referring
> > > > to
> > > > > > as
> > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > >> > > > stream. The first repo there is a
> template
> > > > > > > repository
> > > > > > > > > that
> > > > > > > > > > > is
> > > > > > > > > > > > > used
> > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > >> > > > people starting projects from scratch
> on KIE
> > > > > > > Sandbox,
> > > > > > > > > > > similar
> > > > > > > > > > > > > to a
> > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The other
> one is
> > > > > the
> > > > > > > KIE
> > > > > > > > > > Tools
> > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> build
> > > > > > system.
> > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > > TypeScript
> > > > > > > > > libraries
> > > > > > > > > > > and
> > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts.
> The
> > > > > > > `kie-tools`
> > > > > > > > > > > monorepo
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > >> > > > configured to work with sparse
> checkouts and
> > > > can
> > > > > > do
> > > > > > > > > > partial
> > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > >> > > > Category B repos refer to Category A
> repos
> > > > > through
> > > > > > > > > > > timestamped
> > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> recently
> > > > > > > > > introduced
> > > > > > > > > > > that
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > > > artifacts
> > > > > > > > under
> > > > > > > > > a
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> format,
> > > > > > > published
> > > > > > > > > > weekly
> > > > > > > > > > > > > every
> > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are
> an
> > > > > > evolution
> > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> release
> > > > for
> > > > > > all
> > > > > > > > of
> > > > > > > > > > > Apache
> > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > An important note here is that Category
> B
> > > > > > > repositories
> > > > > > > > > > have
> > > > > > > > > > > > been
> > > > > > > > > > > > > > >> > > > historically kept out of any
> automations we
> > > > used
> > > > > > to
> > > > > > > > > have,
> > > > > > > > > > > way
> > > > > > > > > > > > > back
> > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> Business
> > > > > > Central
> > > > > > > > > > (a.k.a.
> > > > > > > > > > > > v7)
> > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > >> > > > still going on. For this reason,
> Category B
> > > > > > projects
> > > > > > > > > have
> > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > > Actions.
> > > > > > > > > Category B
> > > > > > > > > > > > repos
> > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > >> > > > always depended on Category A repos
> using
> > > > fixed
> > > > > > > > > versions.
> > > > > > > > > > If
> > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> SNAPSHOTs,
> > > > > > breaking
> > > > > > > > > > changes
> > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > > > potential
> > > > > > > to
> > > > > > > > > > break
> > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > >> > > > silently, leaving Category B with a
> broken
> > > > > > > development
> > > > > > > > > > > stream,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > > maintainers
> > > > > > of
> > > > > > > > > > > Category B
> > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > >> > > > as historically Category A contributors
> were
> > > > not
> > > > > > > > > familiar
> > > > > > > > > > > with
> > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Contributions made to Category B repos
> go
> > > > > through
> > > > > > a
> > > > > > > > > GitHub
> > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > >> > > > workflow that builds the relevant part
> of the
> > > > > > > > > `kie-tools`
> > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > >> > > > the changes introduced. Changes made to
> the
> > > > > > pipeline
> > > > > > > > > > itself
> > > > > > > > > > > > are
> > > > > > > > > > > > > > also
> > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us
> to do
> > > > > things
> > > > > > > > like
> > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> example. More
> > > > > > > > > > importantly,
> > > > > > > > > > > it
> > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > > timestamped
> > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > together
> > > > > > > > > > > > > > >> > > > with the changes necessary to make it
> stay
> > > > > green.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This setup, however, makes it
> impossible to
> > > > have
> > > > > > > > > > cross-repo
> > > > > > > > > > > > PRs
> > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > simultaneously,
> > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > > > > > current
> > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> around,
> > > > > and
> > > > > > > I'm
> > > > > > > > > not
> > > > > > > > > > > sure
> > > > > > > > > > > > > if
> > > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > > Regardless,
> > > > > > as
> > > > > > > > > > they're
> > > > > > > > > > > > > part
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> release,
> > > > > so I
> > > > > > > > > listed
> > > > > > > > > > > them
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category D is self explanatory. There's
> only
> > > > one
> > > > > > > repo
> > > > > > > > > that
> > > > > > > > > > > has
> > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category E are repos that do not host
> code
> > > > > > directly,
> > > > > > > > and
> > > > > > > > > > are
> > > > > > > > > > > > > > either
> > > > > > > > > > > > > > >> > > > organizational entities, or host
> websites,
> > > > that
> > > > > > > > > currently
> > > > > > > > > > > are
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This lack of unification between
> Category A
> > > > and
> > > > > > > > > Category B
> > > > > > > > > > > is,
> > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> infamous
> > > > > circular
> > > > > > > > > > > dependency
> > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we
> now
> > > > can
> > > > > > > > describe
> > > > > > > > > > as
> > > > > > > > > > > a
> > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > >> > > > dependency between Category A and
> Category B.
> > > > > The
> > > > > > > way
> > > > > > > > I
> > > > > > > > > > see
> > > > > > > > > > > > it,
> > > > > > > > > > > > > if
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > had a single pipeline, building
> everything
> > > > from
> > > > > > > > `drools`
> > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> been
> > > > > > > > introduced,
> > > > > > > > > > and
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem in
> our
> > > > > hands
> > > > > > > > right
> > > > > > > > > > now.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> process
> > > > > > sees
> > > > > > > > this
> > > > > > > > > > > lack
> > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > unification as a central problem, not
> only for
> > > > > > this
> > > > > > > > > > release
> > > > > > > > > > > in
> > > > > > > > > > > > > > >> > > > particular, but for the community as a
> whole.
> > > > It
> > > > > > is
> > > > > > > my
> > > > > > > > > > > belief
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > > > contribution
> > > > > > > > > > should
> > > > > > > > > > > > be
> > > > > > > > > > > > > > >> > > > allowed to break any part of our
> codebase.
> > > > With
> > > > > > the
> > > > > > > > > > > increasing
> > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> contributors
> > > > > too,
> > > > > > > we
> > > > > > > > > > cannot
> > > > > > > > > > > > > keep
> > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> breaking
> > > > > > things.
> > > > > > > > > We're
> > > > > > > > > > > all
> > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > > mechanisms
> > > > > in
> > > > > > > > place
> > > > > > > > > > to
> > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> Especially
> > > > > when
> > > > > > > > these
> > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > > > individually,
> > > > > > > > > > > > probably
> > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> depending
> > > > on
> > > > > > > > > > kiegroup's
> > > > > > > > > > > > KIE
> > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > > `kogito-images`
> > > > > > > > > > > depending
> > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending
> on
> > > > > > > kiegroup's
> > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > `7.59.0.Final`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > > depending
> > > > > on
> > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > > codebase
> > > > > > > here:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >
> > > > > > > > >
> > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > ,
> > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > > OptaPlanner,
> > > > > > > > > > pointing
> > > > > > > > > > > to
> > > > > > > > > > > > > > older
> > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P5.
> > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > depending
> > > > > > > > > > on
> > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> `2.15.3.Final`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P6. Category C repos are out of date
> and not
> > > > > part
> > > > > > of
> > > > > > > > the
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > > A
> > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> (Current
> > > > > > version
> > > > > > > is
> > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > > version,
> > > > > > only
> > > > > > > > by
> > > > > > > > > > > using
> > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> version
> > > > is
> > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > > OptaPlanner
> > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P7.
> `kie-tools`/packages/kn-plugin-workflow
> > > > has
> > > > > > its
> > > > > > > > E2E
> > > > > > > > > > > > disabled
> > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the
> same
> > > > > > solution,
> > > > > > > > as
> > > > > > > > > > they
> > > > > > > > > > > > > both
> > > > > > > > > > > > > > >> > > > suffer from the circular dependency
> between
> > > > > > > Category A
> > > > > > > > > and
> > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > >> > > > As Category A and Category B are both
> streams
> > > > > that
> > > > > > > > have
> > > > > > > > > > been
> > > > > > > > > > > > > > really
> > > > > > > > > > > > > > >> > > > active, I see this as a blocker, as
> there are
> > > > > > > > > > contributions
> > > > > > > > > > > > that
> > > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> depends
> > > > on
> > > > > > > > > Category
> > > > > > > > > > B
> > > > > > > > > > > > > with a
> > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > > understood
> > > > > > as
> > > > > > > > > > > technical
> > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > > something
> > > > > > > we'll
> > > > > > > > > > always
> > > > > > > > > > > > be
> > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> just a
> > > > > > matter
> > > > > > > of
> > > > > > > > > > > making
> > > > > > > > > > > > > them
> > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> impact
> > > > the
> > > > > > > > > structure
> > > > > > > > > > or
> > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > >> > > > that we're talking about here, but it
> is a
> > > > > > > regression
> > > > > > > > we
> > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> Apache
> > > > KIE
> > > > > > 10,
> > > > > > > > and
> > > > > > > > > > > that
> > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only
> problems left
> > > > > to
> > > > > > > > > discuss
> > > > > > > > > > > are
> > > > > > > > > > > > P1
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > > > > proposal.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I'll try to be very meticulous here,
> since
> > > > from
> > > > > my
> > > > > > > > > > > experience,
> > > > > > > > > > > > > any
> > > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> release
> > > > > not
> > > > > > > > > working
> > > > > > > > > > > out
> > > > > > > > > > > > in
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > > possible,
> > > > > > and
> > > > > > > > make
> > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > > release,
> > > > > > bear
> > > > > > > > > with
> > > > > > > > > > > me.
> > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > >> > > > out a timeline of events that need to
> happen
> > > > in
> > > > > > > order
> > > > > > > > > for
> > > > > > > > > > > our
> > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > >> > > > to be published, with all artifacts
> ending up
> > > > in
> > > > > > the
> > > > > > > > > right
> > > > > > > > > > > > > places,
> > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > >> > > > first, we need to solve problems P1 and
> P2.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As you saw at the beginning of this
> email, all
> > > > > the
> > > > > > > > > > attempts
> > > > > > > > > > > we
> > > > > > > > > > > > > > made
> > > > > > > > > > > > > > >> > > > left us with the circular dependency
> showing
> > > > up
> > > > > > at a
> > > > > > > > > > > different
> > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > >> > > > but something all these places have in
> common
> > > > is
> > > > > > > that
> > > > > > > > > > > they're
> > > > > > > > > > > > > all
> > > > > > > > > > > > > > >> > > > after kogito-apps, and before to
> Category B.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > > following:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > S1. We keep the original plan of moving
> the
> > > > > > Quarkus
> > > > > > > > Dev
> > > > > > > > > > UIs
> > > > > > > > > > > > from
> > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> with
> > > > > > > Management
> > > > > > > > > and
> > > > > > > > > > > > Task
> > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> `kie-tools`.
> > > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > images
> > > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > `kogito-serverless-operator`
> > > > > > > > repo
> > > > > > > > > > > > inside
> > > > > > > > > > > > > a
> > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> history.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> > > > problems
> > > > > > P1
> > > > > > > > and
> > > > > > > > > > P2.
> > > > > > > > > > > Of
> > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > >>
> > > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This doesn't come without consequences,
> of
> > > > > course,
> > > > > > > as
> > > > > > > > > the
> > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> `kogito-swf-builder`
> > > > > > > images,
> > > > > > > > > and
> > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be
> moving
> > > > > from
> > > > > > > > > > Category A
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > Category B. This move would make them
> have to
> > > > > > > > reference
> > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs.
> Since
> > > > > > > > > `kogito-images`
> > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are
> already their
> > > > > own
> > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > >> > > > Category A, though, contributions made
> in a
> > > > > > > cross-repo
> > > > > > > > > > > fashion
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> possible, now
> > > > > > via a
> > > > > > > > > > single
> > > > > > > > > > > PR
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> Category A
> > > > > and
> > > > > > > > > > Category
> > > > > > > > > > > B
> > > > > > > > > > > > > will
> > > > > > > > > > > > > > >> > > > continue not being possible, and a
> 1-week
> > > > delay
> > > > > > > > between
> > > > > > > > > > > > merging
> > > > > > > > > > > > > > >> > > > something on Category A and using it on
> > > > > Category B
> > > > > > > > will
> > > > > > > > > > > still
> > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> > > > however,
> > > > > > > does
> > > > > > > > > > allow
> > > > > > > > > > > > for
> > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > >> > > > checkouts and partial builds, so
> working with
> > > > a
> > > > > > > subset
> > > > > > > > > of
> > > > > > > > > > > the
> > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > >> > > > is possible and encouraged. Making
> changes
> > > > only
> > > > > to
> > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> example,
> > > > will
> > > > > > > have
> > > > > > > > > the
> > > > > > > > > > PR
> > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see
> here:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > >> > > > We're not compromising when running
> partial
> > > > > builds
> > > > > > > > too.
> > > > > > > > > We
> > > > > > > > > > > > know
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > >> > > > the entire repo will continue working
> even
> > > > after
> > > > > > > only
> > > > > > > > > > > > building a
> > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > >> > > > subset of the changes. Doing partial or
> full
> > > > > > builds
> > > > > > > is
> > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> proposing
> > > > we
> > > > > > > move a
> > > > > > > > > > bunch
> > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I
> see this
> > > > > as a
> > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would
> host some
> > > > > > > > additional
> > > > > > > > > > > stuff
> > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > > continue
> > > > > > > moving
> > > > > > > > > > > > forward.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As I mentioned on other places,
> `kie-tools`
> > > > > > became a
> > > > > > > > > > > polyglot
> > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > >> > > > out of necessity, and although I'm
> really
> > > > proud
> > > > > of
> > > > > > > > what
> > > > > > > > > we
> > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > >> > > > there so far, I don't think `kie-tools`
> has a
> > > > > > setup
> > > > > > > > that
> > > > > > > > > > is
> > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > >> > > > for all the different nuances that
> compose our
> > > > > > > > > community.
> > > > > > > > > > > I'm
> > > > > > > > > > > > > well
> > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that
> does not
> > > > > > follow
> > > > > > > > > > > widespread
> > > > > > > > > > > > > > >> > > > conventions will scare some people
> away, and
> > > > as
> > > > > > much
> > > > > > > > as
> > > > > > > > > > > we've
> > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > >> > > > make build instructions clear, we can't
> always
> > > > > get
> > > > > > > > past
> > > > > > > > > > the
> > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > > > > ecosystem.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > With all that said, I keep thinking
> this is
> > > > the
> > > > > > best
> > > > > > > > > > course
> > > > > > > > > > > of
> > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > >> > > > for us right now. We keep most of our
> stuff
> > > > > > > unchanged,
> > > > > > > > > we
> > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > release, and we have a working setup
> that will
> > > > > > suit
> > > > > > > us
> > > > > > > > > > well
> > > > > > > > > > > > > while
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > discuss and reach a conclusion
> regarding the
> > > > > > future
> > > > > > > of
> > > > > > > > > our
> > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Let me paint a quick picture here of
> what our
> > > > > code
> > > > > > > > base
> > > > > > > > > > > would
> > > > > > > > > > > > > look
> > > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > > > > accepted:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > B
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > D
> incubator-kie-kogito-operator
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > > > > >> > > > E
> > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * Category C becomes part of Category
> A, and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> entirely
> > > > > inside
> > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> images
> > > > and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > > `kie-tools`,
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > > no
> > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > > > granularly
> > > > > > > > build:
> > > > > > > > > > > > > > >> > > > 1.
> packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> (containing
> > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> (contents
> > > > > from
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The second part of the proposal is the
> release
> > > > > > > process
> > > > > > > > > > > itself,
> > > > > > > > > > > > > > >> > > > assuming the structure above is what we
> have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be
> used as
> > > > > > > cutting
> > > > > > > > > > point
> > > > > > > > > > > > for
> > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to
> this
> > > > > > > > timestamped
> > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > > >> > > > 3. At this point, with everything
> working, we
> > > > > can
> > > > > > > > branch
> > > > > > > > > > out
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the
> timestamped
> > > > > SNAPSHOT
> > > > > > > > tag,
> > > > > > > > > > and
> > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> update
> > > > > > their
> > > > > > > > > > versions
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > > Category
> > > > > A
> > > > > > > > repos
> > > > > > > > > > > using
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the
> release
> > > > > based
> > > > > > > on
> > > > > > > > > the
> > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > >> > > > branches, given we don't expect any code
> > > > changes
> > > > > > > > > anymore.
> > > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to
> start
> > > > the
> > > > > > > > release
> > > > > > > > > > > > process.
> > > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > > manual/automated
> > > > > > > > > release
> > > > > > > > > > > > > process,
> > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> pushed
> > > > to
> > > > > > Git,
> > > > > > > > and
> > > > > > > > > > > built
> > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > > artifacts
> > > > > > to
> > > > > > > be
> > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > > manual/automated
> > > > > > > > > release
> > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> pushed
> > > > to
> > > > > > Git,
> > > > > > > > and
> > > > > > > > > > > built
> > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > > >> > > > 12. Category E repos can be manually
> tagged
> > > > with
> > > > > > > > 10.0.0
> > > > > > > > > > from
> > > > > > > > > > > > > their
> > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > More needs to be discussed if we're
> planning
> > > > to
> > > > > > > > maintain
> > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > >> > > > release streams in parallel, but I
> guess it
> > > > can
> > > > > > wait
> > > > > > > > for
> > > > > > > > > > > after
> > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> forward
> > > > > to
> > > > > > > > > hearing
> > > > > > > > > > > back
> > > > > > > > > > > > > > from
> > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Of course, alternative solutions are
> possible.
> > > > > > This
> > > > > > > > > email,
> > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > >> > > > summarizes my view of how we should
> attack the
> > > > > > > > problem,
> > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > >> > > > disruption, required effort, the release
> > > > process
> > > > > > > > itself,
> > > > > > > > > > and
> > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > >> > > > Feel free to propose alternatives. This
> is
> > > > not a
> > > > > > > > voting
> > > > > > > > > > > > thread.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Yeser Amer <ya...@apache.org>.
Thank you Tiago for your comprehensive description.
From a purely technical point, I tend to agree with Francisco.
And yes, it happened in the past that we took accountability for a future change and eventually we forgot or we ignored that.
But we can't only consider the technical point of taking this decision.
Tibor raised, from my point of view, the most important point to consider in this case, and I fully agree with him.
Take this conversion as an example https://kie.zulipchat.com/#narrow/stream/232676-kogito/topic/Kogito.20and.20SpringBoot.203
Our community users are getting frustrated to wait for a release and a precise release date.
My suggestion is then to proceed with Tiago's proposal as a Temporary solution to unblock the release, and in parallel start a conversion to define a more correct solution from a structural/technical point of view.
Yes, there's the risk that agreeing and applying a solution may require more time and it can be forgotten it in our backlog tasks, but on the other hand, we have an even bigger risk of losing our user community's trust.
In that sense, I would consider any solution that may force us to have a real and quick follow-up to tackle it just before the release (and seems to me Ricardo proposed a solution that goes in that direction)
(P.S. Problem 3 can be solved in 1 day, I can do it during my free time :) )
On 2024/03/13 13:32:08 Alex Porcelli wrote:
> Francisco,
>
> As I wrote earlier, I had a conversation with Jan - that is our
> community CI expert - and he said that he guesses that it would take
> about 2 months to make CI changes implied in your comments.
>
> He also mentioned that if Tristan was around and could dedicate his
> time on this, he believes that Tristan could make the same changes
> potentially in about 2 weeks.
>
>
> On Wed, Mar 13, 2024 at 9:26 AM Francisco Javier Tirado Sarti
> <ft...@redhat.com> wrote:
> >
> > @Ricardo Zanini <za...@redhat.com> The main issue I have is why we
> > conclude 1 takes less time than 2?. If I understood 1) completely, it also
> > requires CI adjustments (at tools repo level, not at overall stream level),
> > so I hardly see the estimation different for someone that is familiar with
> > CI.
> >
> > On Wed, Mar 13, 2024 at 2:14 PM ricardo zanini fernandes <
> > ricardozanini@gmail.com> wrote:
> >
> > > Hi!
> > >
> > > Clearly, you all understand that moving images and the operator to
> > > kie-tools is a workaround and wrong in all possible scenarios, right? We
> > > won't undo once we merge. I'm pretty positive that once we have a release
> > > train going people will add all the obstacles they can add saying "It's
> > > working, let's not change it".
> > >
> > > Also, I understand that we need to unblock the release. We can compromise
> > > in COPYING the code, do the release, and then make the necessary changes.
> > > Images and cloud code are *integration platforms*. Should be the last in a
> > > stream. Tooling SHOULD NOT, in any case, depend on the images to build.
> > >
> > > So we can:
> > >
> > > 1. Accept Tiago's proposal (very well detailed, thanks!) but COPYING the
> > > code base, not MERGING. The contributions still flow to the right repos.
> > > 2. After release we:
> > > 1. Move the CLI to the operator repo, removing this dependency from
> > > tools to image
> > > 2. Adjust the CI
> > > 3. Remove the copied code
> > >
> > > Moving forward, I'd like to see a clear boundary between the projects (as
> > > stated in the temporary website). At the moment, we do not have. And it's
> > > hard for anyone from outside to understand what we are doing.
> > >
> > > On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me> wrote:
> > >
> > > > Francisco and Gabriele,
> > > >
> > > > I understand and acknowledge your desire to find the “right” solution
> > > > instead to work on a temporary “patch” - however without a detailed
> > > > proposal I don’t think we can properly evaluate the impact of your
> > > > suggestion.
> > > >
> > > > When I spoke with different SMEs that included tools and CI, the
> > > > guesstimate for making the necessary changes on CI and codebase to
> > > > basically have images and operators in the end of the build chain is
> > > > something like 2 months of effort. Another impact that needs to be
> > > > discussed is that KIE Tools repo had to be injected in the middle of all
> > > > pipelines - forcing all PR checks and nightlies to build all repos (PR
> > > > checks will likely take 12+ hours… I even heard that it could be even 24
> > > > hours).
> > > >
> > > > Based on the input above, I think it’s quite risk to move in such
> > > direction
> > > > without a more detailed plan… because 2 months could be turned easily in
> > > 6!
> > > > And this is exactly what happened when we guessed that moving to Apache
> > > > would take no more than 3 months. But here we are.
> > > >
> > > > I really strongly suggest that we focus on a release that could be
> > > > achievable in less than a month from now, and we - after release - have a
> > > > in depth discussion about the overall codebase and ci organization.
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > gabriele.cardosi@gmail.com>
> > > > wrote:
> > > >
> > > > > Alex,
> > > > > my suggestion is to move the building of all docker images, from
> > > whatever
> > > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > > > > invoked after all the others.
> > > > > I'm not sure if this would solve all the issues, and since I could not
> > > > > enter in the details of all the involved code, my suggestion may be too
> > > > > naive.
> > > > > Having spent almost all of the last year in CI, I may say that, at
> > > least
> > > > > for the kie-tools repo, removing the image build step from it should
> > > not
> > > > be
> > > > > too difficult (since it is an issue we already faced and solved).
> > > > > If, with "detailed proposal", you mean a complete list of all modules
> > > to
> > > > be
> > > > > moved and dependency refactoring, of course I can not provide it right
> > > > now.
> > > > >
> > > > > Anyway, I share the concern from Francisco: undoing something is almost
> > > > > always harder than doing it "rightly" from scratch...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti
> > > <
> > > > > ftirados@redhat.com> ha scritto:
> > > > >
> > > > > > I do not think estimations should be the only driver to make a
> > > > decision,
> > > > > > especially when the current proposal is conceptually incompatible
> > > with
> > > > > the
> > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > Given my knowledge of the CI it is nearly impossible for me to give
> > > a
> > > > > fair
> > > > > > estimate of how much it might take to achieve step 2) of my previous
> > > > > e-mail
> > > > > > . It might take a while or it might be pretty easy after all, I don't
> > > > > > really know, but I think it will be a good idea if some of the
> > > experts
> > > > > on
> > > > > > CI in the team (the ones that set up the pipeline, which was a huge
> > > > > > achievement) give an estimate, not me. Estimating how much it takes
> > > to
> > > > > > merge two existing repos (without altering CI) is easier, but it does
> > > > not
> > > > > > mean we are doing the right thing.
> > > > > > My main concern is that it will be very difficult for me to explain
> > > to
> > > > > > someone that arrives new to the team, that having experts on CI on
> > > the
> > > > > > team, we decided to merge two repos (once merged, it would be rather
> > > > > > difficult to unmerge) rather than fix the CI, because of expediency.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Francisco,
> > > > > > >
> > > > > > > Please take the time to make the more in depth analysis needed and
> > > > > > provide
> > > > > > > a more detailed plan… so we - as community- can evaluate the size
> > > of
> > > > > the
> > > > > > > effort. In the conceptual level you shared it’s near impossible to
> > > > > > estimate
> > > > > > > the size of the effort and compare with the current proposal.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > > > ftirados@redhat.com> wrote:
> > > > > > >
> > > > > > > > I think I already did a high level proposal.
> > > > > > > > 1) Remove all dependencies from tooling to images, so images
> > > > depend
> > > > > on
> > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > 2) Then change CI to deal with tooling repo before dealing with
> > > > > images
> > > > > > > > repo.
> > > > > > > > I understand that CI details are tricky and since I'm not
> > > familiar
> > > > > with
> > > > > > > CI
> > > > > > > > in any way, I barely can make a low level design, but we do not
> > > > need
> > > > > to
> > > > > > > fix
> > > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <alex@porcelli.me
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco and Grabriele,
> > > > > > > > >
> > > > > > > > > You may not like or understand why the current state of the CI
> > > is
> > > > > > like
> > > > > > > > > that… actually has been in Red Hat and has been replicated in
> > > > > Apache
> > > > > > as
> > > > > > > > > used to be….
> > > > > > > > >
> > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > >
> > > > > > > > > If you disagree with the current plan, please provide a
> > > detailed
> > > > > > > > > alternative so we, as community, can better evaluate the pros
> > > and
> > > > > > cons
> > > > > > > of
> > > > > > > > > each proposal.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think it’s also fair to say that, post 10 release we need to
> > > > > have a
> > > > > > > > much
> > > > > > > > > in depth discussion about how our codebase is organized, it’s
> > > > clear
> > > > > > > that
> > > > > > > > > it’s not working.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > As Francisco said,
> > > > > > > > > > I also have the impression that the "images" (if we are
> > > talking
> > > > > of
> > > > > > > > docker
> > > > > > > > > > images) should be the very last one to be built, in a
> > > > standalone
> > > > > > > repo.
> > > > > > > > > > That way, they may "combine" artifacts that are built in
> > > > > different
> > > > > > > > repos,
> > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> > > maybe
> > > > > > could
> > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > (I also think there are some statements of undisputable needs
> > > > > while
> > > > > > > > they
> > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > discussion.)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > > > Tirado
> > > > > > > Sarti
> > > > > > > > <
> > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > >
> > > > > > > > > > > Alex,
> > > > > > > > > > > There are two assumptions that deserve further discussion:
> > > > > > > > > > > 1) That tool has to be the last to build. why? it does not
> > > > have
> > > > > > > more
> > > > > > > > > > sense
> > > > > > > > > > > to build final images after everything else has been
> > > built?-
> > > > > > > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> > > > > > bigger
> > > > > > > > than
> > > > > > > > > > the
> > > > > > > > > > > impact (long term consequences) of consolidating two
> > > > unrelated
> > > > > > > piece
> > > > > > > > of
> > > > > > > > > > > software within the same repository.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > alex@porcelli.me
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Francisco,
> > > > > > > > > > > >
> > > > > > > > > > > > This was discussed as an alternative solution, however it
> > > > has
> > > > > > > major
> > > > > > > > > > > impact
> > > > > > > > > > > > on CI and there’s also the fact Tool has been always the
> > > > last
> > > > > > to
> > > > > > > > > build
> > > > > > > > > > > and
> > > > > > > > > > > > has no Snapshot published (actually in JavaScript world
> > > > there
> > > > > > is
> > > > > > > no
> > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > >
> > > > > > > > > > > > So, based on our evaluation… the proposal here is the
> > > least
> > > > > > > > > disruptive
> > > > > > > > > > > and
> > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > _____________
> > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > > > > Sarti <
> > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > After kie-tools, sorry. I think we are not embracing
> > > the
> > > > > fact
> > > > > > > > that
> > > > > > > > > > > > > kogito-images depend on kie-tools, because we want
> > > those
> > > > > > images
> > > > > > > > to
> > > > > > > > > > > > include
> > > > > > > > > > > > > tools.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > > Tirado
> > > > > > Sarti
> > > > > > > <
> > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > kn-plugin-workflow
> > > > > > > to
> > > > > > > > > > > > > > kogito-images (so there is not longer dependency from
> > > > > tools
> > > > > > > to
> > > > > > > > > > > images)
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > > > Martinez
> > > > > > <
> > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache)
> > > <
> > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > > > alex@porcelli.me
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > I spent the last day or so working closely with
> > > > > Tiago,
> > > > > > > > > > exploring
> > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > > > evaluating
> > > > > > > > the
> > > > > > > > > > > > overall
> > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > > proposal
> > > > > as
> > > > > > > the
> > > > > > > > > > most
> > > > > > > > > > > > > >> > > viable option for unblocking the 10 release in
> > > the
> > > > > > > > > reasonable
> > > > > > > > > > > time
> > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time,
> > > as
> > > > > this
> > > > > > > > > matter
> > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > > > > > > according
> > > > > > > > > to
> > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > >
> > > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > ),
> > > > > > > > > > > > > >> > > > many of us were working towards removing a
> > > > > circular
> > > > > > > > > > dependency
> > > > > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > > > > `kie-tools`.
> > > > > > > > > As
> > > > > > > > > > we
> > > > > > > > > > > > > >> > > > progressed towards a solution, we kept finding
> > > > the
> > > > > > > > > circular
> > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of
> > > > the
> > > > > > > things
> > > > > > > > > we
> > > > > > > > > > > did,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Right now, even though we started the effort
> > > to
> > > > > move
> > > > > > > the
> > > > > > > > > > > Quarkus
> > > > > > > > > > > > > Dev
> > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> > > able
> > > > to
> > > > > > do
> > > > > > > it
> > > > > > > > > > yet,
> > > > > > > > > > > as
> > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> > > Maven
> > > > > > 3.9.6,
> > > > > > > > and
> > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > This
> > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > >> > > >
> > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > .
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > C | 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > Y | 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > >> > > > * and
> > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > depend
> > > > > > > > > > > > > >> on
> > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > `kie-tools`,
> > > > > we
> > > > > > > > > would've
> > > > > > > > > > > > had:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > >> > > > * and
> > > `kogito-images`/kogito-swf-devmode
> > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > > > > > > `kie-tools`,
> > > > > > > > > > we
> > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem than a
> > > > > simple
> > > > > > > > > > circular
> > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > > > people,
> > > > > > > it's
> > > > > > > > > been
> > > > > > > > > > > > > really
> > > > > > > > > > > > > >> > > > hard coming up with a simple solution that
> > > makes
> > > > > it
> > > > > > > > > possible
> > > > > > > > > > > to
> > > > > > > > > > > > > >> build
> > > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving the
> > > way
> > > > > > > > everyone
> > > > > > > > > is
> > > > > > > > > > > > used
> > > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > contributing to the multiple repositories we
> > > > have.
> > > > > > > More
> > > > > > > > > than
> > > > > > > > > > > > that,
> > > > > > > > > > > > > >> > > > while making this assessment, I found more
> > > > > problems
> > > > > > > > that,
> > > > > > > > > in
> > > > > > > > > > > my
> > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > > forward
> > > > > with
> > > > > > > my
> > > > > > > > > > > proposal
> > > > > > > > > > > > > for
> > > > > > > > > > > > > >> > > > the Apache KIE release process, so we can use
> > > > > > Apache's
> > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> > > this
> > > > > > really
> > > > > > > > > > > > complicated
> > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > > > > current
> > > > > > > > > > situation
> > > > > > > > > > > > of
> > > > > > > > > > > > > >> our
> > > > > > > > > > > > > >> > > > codebase, as well as problems I can currently
> > > > see.
> > > > > > > I'll
> > > > > > > > > > start
> > > > > > > > > > > > with
> > > > > > > > > > > > > >> an
> > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > purposes,
> > > > > > point
> > > > > > > > out
> > > > > > > > > > > some
> > > > > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > > > > release,
> > > > > > > > > explain
> > > > > > > > > > > my
> > > > > > > > > > > > > >> > > > proposal and discuss some consequences to what
> > > > I'm
> > > > > > > > > > proposing.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> > > `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > > > > `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> > > > > > `0.0.0`
> > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > >> > > > (Issues only, README should be updated @
> > > > > `main`.
> > > > > > > > Same
> > > > > > > > > > for
> > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy at
> > > the
> > > > > > > `main`
> > > > > > > > > > > branch.)
> > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > > > > > > `deploy`
> > > > > > > > to
> > > > > > > > > > > > update
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > sandbox.kie.org
> > > > > and
> > > > > > > KIE
> > > > > > > > > > Tools'
> > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> > > checks
> > > > > > > during
> > > > > > > > > the
> > > > > > > > > > > > > staging
> > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I grouped the repositories by category, and
> > > > listed
> > > > > > > them
> > > > > > > > > in a
> > > > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > > > flattening
> > > > > > > > out a
> > > > > > > > > > > tree,
> > > > > > > > > > > > > >> there
> > > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > > OptaPlanner
> > > > > > > > > > could've
> > > > > > > > > > > > been
> > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category A repos are what I've been referring
> > > to
> > > > > as
> > > > > > > > > `drools`
> > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is
> > > > inside
> > > > > > > that
> > > > > > > > > > > stream,
> > > > > > > > > > > > as
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > way these repositories reference each other
> > > are
> > > > > > > through
> > > > > > > > > > Maven
> > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > > > > > > version.
> > > > > > > > > This
> > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > >> > > > is well-known to the team, and although flawed
> > > > for
> > > > > > > > > intra-day
> > > > > > > > > > > > > builds
> > > > > > > > > > > > > >> > > > and disruptive for people in many different
> > > time
> > > > > > > zones,
> > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > > > > >> already
> > > > > > > > > > > > > >> > > > very comfortable for everyone to work with, I
> > > > > > assume.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > > > dedicated
> > > > > > > > > > > pipelines,
> > > > > > > > > > > > > >> which
> > > > > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > > > > cross-repo
> > > > > > > > PRs
> > > > > > > > > > > > > together
> > > > > > > > > > > > > >> > > > and verify that the codebase will continue
> > > > working
> > > > > > as
> > > > > > > > > > expected
> > > > > > > > > > > > > after
> > > > > > > > > > > > > >> > > > they're all merged. From what I could gather,
> > > > > there
> > > > > > > are
> > > > > > > > > some
> > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > cross-repo
> > > > > > PRs.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > > > > kogito-examples
> > > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > > > >> > > > - kogito-images, and
> > > kogito-serverless-operator
> > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > > > > > > combination
> > > > > > > > > of
> > > > > > > > > > > > repos
> > > > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > > > cannot
> > > > > be
> > > > > > > > > > verified
> > > > > > > > > > > > > before
> > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > dependent
> > > > > on
> > > > > > > > > > individual
> > > > > > > > > > > > > >> > > > contributors building stuff on their machines
> > > to
> > > > > > > verify
> > > > > > > > > that
> > > > > > > > > > > it
> > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > > > pipelines,
> > > > > > > so
> > > > > > > > > > > please
> > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category B repos are what I've been referring
> > > to
> > > > > as
> > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > > > repository
> > > > > > > > that
> > > > > > > > > > is
> > > > > > > > > > > > used
> > > > > > > > > > > > > >> by
> > > > > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > > > > Sandbox,
> > > > > > > > > > similar
> > > > > > > > > > > > to a
> > > > > > > > > > > > > >> > > > Maven archetype, if you will. The other one is
> > > > the
> > > > > > KIE
> > > > > > > > > Tools
> > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > > > > system.
> > > > > > > > > > > Currently,
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > TypeScript
> > > > > > > > libraries
> > > > > > > > > > and
> > > > > > > > > > > > > apps,
> > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > > > `kie-tools`
> > > > > > > > > > monorepo
> > > > > > > > > > > > is
> > > > > > > > > > > > > >> > > > configured to work with sparse checkouts and
> > > can
> > > > > do
> > > > > > > > > partial
> > > > > > > > > > > > > builds.
> > > > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > > > through
> > > > > > > > > > timestamped
> > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > > > > > > introduced
> > > > > > > > > > that
> > > > > > > > > > > > > will
> > > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > > artifacts
> > > > > > > under
> > > > > > > > a
> > > > > > > > > > > > version
> > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > > > > published
> > > > > > > > > weekly
> > > > > > > > > > > > every
> > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > > > evolution
> > > > > > > to
> > > > > > > > > the
> > > > > > > > > > > > Kogito
> > > > > > > > > > > > > >> > > > releases, as we're now targeting one release
> > > for
> > > > > all
> > > > > > > of
> > > > > > > > > > Apache
> > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > >> so
> > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > An important note here is that Category B
> > > > > > repositories
> > > > > > > > > have
> > > > > > > > > > > been
> > > > > > > > > > > > > >> > > > historically kept out of any automations we
> > > used
> > > > > to
> > > > > > > > have,
> > > > > > > > > > way
> > > > > > > > > > > > back
> > > > > > > > > > > > > >> > > > when Kogito started and we had the Business
> > > > > Central
> > > > > > > > > (a.k.a.
> > > > > > > > > > > v7)
> > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > >> > > > still going on. For this reason, Category B
> > > > > projects
> > > > > > > > have
> > > > > > > > > > > > > developed
> > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > Actions.
> > > > > > > > Category B
> > > > > > > > > > > repos
> > > > > > > > > > > > > >> have
> > > > > > > > > > > > > >> > > > always depended on Category A repos using
> > > fixed
> > > > > > > > versions.
> > > > > > > > > If
> > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > > > > breaking
> > > > > > > > > changes
> > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > > potential
> > > > > > to
> > > > > > > > > break
> > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > > > development
> > > > > > > > > > stream,
> > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > maintainers
> > > > > of
> > > > > > > > > > Category B
> > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > >> > > > as historically Category A contributors were
> > > not
> > > > > > > > familiar
> > > > > > > > > > with
> > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > > > through
> > > > > a
> > > > > > > > GitHub
> > > > > > > > > > > > Actions
> > > > > > > > > > > > > >> > > > workflow that builds the relevant part of the
> > > > > > > > `kie-tools`
> > > > > > > > > > > > monorepo
> > > > > > > > > > > > > >> for
> > > > > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > > > > pipeline
> > > > > > > > > itself
> > > > > > > > > > > are
> > > > > > > > > > > > > also
> > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do
> > > > things
> > > > > > > like
> > > > > > > > > > > > atomically
> > > > > > > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > > > > > > importantly,
> > > > > > > > > > it
> > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > timestamped
> > > > > > > > SNAPSHOT
> > > > > > > > > > > > > together
> > > > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > > > green.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This setup, however, makes it impossible to
> > > have
> > > > > > > > > cross-repo
> > > > > > > > > > > PRs
> > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > simultaneously,
> > > > > > > with
> > > > > > > > > the
> > > > > > > > > > > > > current
> > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category C repos are kind of floating around,
> > > > and
> > > > > > I'm
> > > > > > > > not
> > > > > > > > > > sure
> > > > > > > > > > > > if
> > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > Regardless,
> > > > > as
> > > > > > > > > they're
> > > > > > > > > > > > part
> > > > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our release,
> > > > so I
> > > > > > > > listed
> > > > > > > > > > them
> > > > > > > > > > > > for
> > > > > > > > > > > > > >> us
> > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category D is self explanatory. There's only
> > > one
> > > > > > repo
> > > > > > > > that
> > > > > > > > > > has
> > > > > > > > > > > > > >> already
> > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > > > directly,
> > > > > > > and
> > > > > > > > > are
> > > > > > > > > > > > > either
> > > > > > > > > > > > > >> > > > organizational entities, or host websites,
> > > that
> > > > > > > > currently
> > > > > > > > > > are
> > > > > > > > > > > > not
> > > > > > > > > > > > > >> part
> > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This lack of unification between Category A
> > > and
> > > > > > > > Category B
> > > > > > > > > > is,
> > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > > > circular
> > > > > > > > > > dependency
> > > > > > > > > > > > > >> between
> > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now
> > > can
> > > > > > > describe
> > > > > > > > > as
> > > > > > > > > > a
> > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > >> > > > dependency between Category A and Category B.
> > > > The
> > > > > > way
> > > > > > > I
> > > > > > > > > see
> > > > > > > > > > > it,
> > > > > > > > > > > > if
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > had a single pipeline, building everything
> > > from
> > > > > > > `drools`
> > > > > > > > > to
> > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > > > > introduced,
> > > > > > > > > and
> > > > > > > > > > we
> > > > > > > > > > > > > >> > > > wouldn't be having this huge problem in our
> > > > hands
> > > > > > > right
> > > > > > > > > now.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release process
> > > > > sees
> > > > > > > this
> > > > > > > > > > lack
> > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > unification as a central problem, not only for
> > > > > this
> > > > > > > > > release
> > > > > > > > > > in
> > > > > > > > > > > > > >> > > > particular, but for the community as a whole.
> > > It
> > > > > is
> > > > > > my
> > > > > > > > > > belief
> > > > > > > > > > > > that
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > > contribution
> > > > > > > > > should
> > > > > > > > > > > be
> > > > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> > > With
> > > > > the
> > > > > > > > > > increasing
> > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > >> > > > of code, and hopefully number of contributors
> > > > too,
> > > > > > we
> > > > > > > > > cannot
> > > > > > > > > > > > keep
> > > > > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > > > > things.
> > > > > > > > We're
> > > > > > > > > > all
> > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > mechanisms
> > > > in
> > > > > > > place
> > > > > > > > > to
> > > > > > > > > > > > > prevent
> > > > > > > > > > > > > >> us
> > > > > > > > > > > > > >> > > > from unwillingly making mistakes. Especially
> > > > when
> > > > > > > these
> > > > > > > > > > > mistakes
> > > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > > individually,
> > > > > > > > > > > probably
> > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending
> > > on
> > > > > > > > > kiegroup's
> > > > > > > > > > > KIE
> > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > `kogito-images`
> > > > > > > > > > depending
> > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > > > kiegroup's
> > > > > > > > > > `lienzo`
> > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > `7.59.0.Final`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > depending
> > > > on
> > > > > > > > > > kiegroup's
> > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > codebase
> > > > > > here:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >
> > > > > > > >
> > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > ,
> > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > OptaPlanner,
> > > > > > > > > pointing
> > > > > > > > > > to
> > > > > > > > > > > > > older
> > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P5.
> > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > depending
> > > > > > > > > on
> > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P6. Category C repos are out of date and not
> > > > part
> > > > > of
> > > > > > > the
> > > > > > > > > > > > Category
> > > > > > > > > > > > > A
> > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > > > > version
> > > > > > is
> > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > version,
> > > > > only
> > > > > > > by
> > > > > > > > > > using
> > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version
> > > is
> > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > OptaPlanner
> > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow
> > > has
> > > > > its
> > > > > > > E2E
> > > > > > > > > > > disabled
> > > > > > > > > > > > > >> after
> > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > > > solution,
> > > > > > > as
> > > > > > > > > they
> > > > > > > > > > > > both
> > > > > > > > > > > > > >> > > > suffer from the circular dependency between
> > > > > > Category A
> > > > > > > > and
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > >> > > > As Category A and Category B are both streams
> > > > that
> > > > > > > have
> > > > > > > > > been
> > > > > > > > > > > > > really
> > > > > > > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > > > > > > contributions
> > > > > > > > > > > that
> > > > > > > > > > > > > >> > > > cannot be done, given that Category A depends
> > > on
> > > > > > > > Category
> > > > > > > > > B
> > > > > > > > > > > > with a
> > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > understood
> > > > > as
> > > > > > > > > > technical
> > > > > > > > > > > > > debt.
> > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > something
> > > > > > we'll
> > > > > > > > > always
> > > > > > > > > > > be
> > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > > > > matter
> > > > > > of
> > > > > > > > > > making
> > > > > > > > > > > > them
> > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't impact
> > > the
> > > > > > > > structure
> > > > > > > > > or
> > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > > > regression
> > > > > > > we
> > > > > > > > > > > > > introduced
> > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache
> > > KIE
> > > > > 10,
> > > > > > > and
> > > > > > > > > > that
> > > > > > > > > > > > P5,
> > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems left
> > > > to
> > > > > > > > discuss
> > > > > > > > > > are
> > > > > > > > > > > P1
> > > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > > > proposal.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> > > from
> > > > my
> > > > > > > > > > experience,
> > > > > > > > > > > > any
> > > > > > > > > > > > > >> > > > little miscalculation can lead to our release
> > > > not
> > > > > > > > working
> > > > > > > > > > out
> > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > possible,
> > > > > and
> > > > > > > make
> > > > > > > > > > > > > everything
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > release,
> > > > > bear
> > > > > > > > with
> > > > > > > > > > me.
> > > > > > > > > > > > I'll
> > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > >> > > > out a timeline of events that need to happen
> > > in
> > > > > > order
> > > > > > > > for
> > > > > > > > > > our
> > > > > > > > > > > > > >> release
> > > > > > > > > > > > > >> > > > to be published, with all artifacts ending up
> > > in
> > > > > the
> > > > > > > > right
> > > > > > > > > > > > places,
> > > > > > > > > > > > > >> but
> > > > > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As you saw at the beginning of this email, all
> > > > the
> > > > > > > > > attempts
> > > > > > > > > > we
> > > > > > > > > > > > > made
> > > > > > > > > > > > > >> > > > left us with the circular dependency showing
> > > up
> > > > > at a
> > > > > > > > > > different
> > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > >> > > > but something all these places have in common
> > > is
> > > > > > that
> > > > > > > > > > they're
> > > > > > > > > > > > all
> > > > > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > following:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > > > > Quarkus
> > > > > > > Dev
> > > > > > > > > UIs
> > > > > > > > > > > from
> > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > > > > Management
> > > > > > > > and
> > > > > > > > > > > Task
> > > > > > > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > images
> > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > `kogito-serverless-operator`
> > > > > > > repo
> > > > > > > > > > > inside
> > > > > > > > > > > > a
> > > > > > > > > > > > > >> new
> > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> > > problems
> > > > > P1
> > > > > > > and
> > > > > > > > > P2.
> > > > > > > > > > Of
> > > > > > > > > > > > > >> course
> > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > >>
> > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This doesn't come without consequences, of
> > > > course,
> > > > > > as
> > > > > > > > the
> > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> > > > > > images,
> > > > > > > > and
> > > > > > > > > > the
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be moving
> > > > from
> > > > > > > > > Category A
> > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > Category B. This move would make them have to
> > > > > > > reference
> > > > > > > > > > > > Category A
> > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > > > `kogito-images`
> > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are already their
> > > > own
> > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > >> > > > Category A, though, contributions made in a
> > > > > > cross-repo
> > > > > > > > > > fashion
> > > > > > > > > > > > to
> > > > > > > > > > > > > >> this
> > > > > > > > > > > > > >> > > > "sub-stream" will continue being possible, now
> > > > > via a
> > > > > > > > > single
> > > > > > > > > > PR
> > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A
> > > > and
> > > > > > > > > Category
> > > > > > > > > > B
> > > > > > > > > > > > will
> > > > > > > > > > > > > >> > > > continue not being possible, and a 1-week
> > > delay
> > > > > > > between
> > > > > > > > > > > merging
> > > > > > > > > > > > > >> > > > something on Category A and using it on
> > > > Category B
> > > > > > > will
> > > > > > > > > > still
> > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> > > however,
> > > > > > does
> > > > > > > > > allow
> > > > > > > > > > > for
> > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > >> > > > checkouts and partial builds, so working with
> > > a
> > > > > > subset
> > > > > > > > of
> > > > > > > > > > the
> > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > >> > > > is possible and encouraged. Making changes
> > > only
> > > > to
> > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example,
> > > will
> > > > > > have
> > > > > > > > the
> > > > > > > > > PR
> > > > > > > > > > > > > checks
> > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > >> > > > We're not compromising when running partial
> > > > builds
> > > > > > > too.
> > > > > > > > We
> > > > > > > > > > > know
> > > > > > > > > > > > > that
> > > > > > > > > > > > > >> > > > the entire repo will continue working even
> > > after
> > > > > > only
> > > > > > > > > > > building a
> > > > > > > > > > > > > >> small
> > > > > > > > > > > > > >> > > > subset of the changes. Doing partial or full
> > > > > builds
> > > > > > is
> > > > > > > > > > > > > automatically
> > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm proposing
> > > we
> > > > > > move a
> > > > > > > > > bunch
> > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see this
> > > > as a
> > > > > > > > > TEMPORARY
> > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > > > > > > additional
> > > > > > > > > > stuff
> > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > continue
> > > > > > moving
> > > > > > > > > > > forward.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> > > > > became a
> > > > > > > > > > polyglot
> > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > >> > > > out of necessity, and although I'm really
> > > proud
> > > > of
> > > > > > > what
> > > > > > > > we
> > > > > > > > > > > > > achieved
> > > > > > > > > > > > > >> > > > there so far, I don't think `kie-tools` has a
> > > > > setup
> > > > > > > that
> > > > > > > > > is
> > > > > > > > > > > > > suitable
> > > > > > > > > > > > > >> > > > for all the different nuances that compose our
> > > > > > > > community.
> > > > > > > > > > I'm
> > > > > > > > > > > > well
> > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that does not
> > > > > follow
> > > > > > > > > > widespread
> > > > > > > > > > > > > >> > > > conventions will scare some people away, and
> > > as
> > > > > much
> > > > > > > as
> > > > > > > > > > we've
> > > > > > > > > > > > > tried
> > > > > > > > > > > > > >> to
> > > > > > > > > > > > > >> > > > make build instructions clear, we can't always
> > > > get
> > > > > > > past
> > > > > > > > > the
> > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > > > ecosystem.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > With all that said, I keep thinking this is
> > > the
> > > > > best
> > > > > > > > > course
> > > > > > > > > > of
> > > > > > > > > > > > > >> action
> > > > > > > > > > > > > >> > > > for us right now. We keep most of our stuff
> > > > > > unchanged,
> > > > > > > > we
> > > > > > > > > > > > unblock
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > release, and we have a working setup that will
> > > > > suit
> > > > > > us
> > > > > > > > > well
> > > > > > > > > > > > while
> > > > > > > > > > > > > we
> > > > > > > > > > > > > >> > > > discuss and reach a conclusion regarding the
> > > > > future
> > > > > > of
> > > > > > > > our
> > > > > > > > > > > > > codebase
> > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Let me paint a quick picture here of what our
> > > > code
> > > > > > > base
> > > > > > > > > > would
> > > > > > > > > > > > look
> > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > > > accepted:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > B
> > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > > > >> > > > E
> > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves entirely
> > > > inside
> > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images
> > > and
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > `kie-tools`,
> > > > > > there
> > > > > > > > are
> > > > > > > > > > no
> > > > > > > > > > > > > cycles
> > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > > granularly
> > > > > > > build:
> > > > > > > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > >> and
> > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator (contents
> > > > from
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The second part of the proposal is the release
> > > > > > process
> > > > > > > > > > itself,
> > > > > > > > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as
> > > > > > cutting
> > > > > > > > > point
> > > > > > > > > > > for
> > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to this
> > > > > > > timestamped
> > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > >> and
> > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > >> > > > 3. At this point, with everything working, we
> > > > can
> > > > > > > branch
> > > > > > > > > out
> > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> > > > SNAPSHOT
> > > > > > > tag,
> > > > > > > > > and
> > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos update
> > > > > their
> > > > > > > > > versions
> > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > Category
> > > > A
> > > > > > > repos
> > > > > > > > > > using
> > > > > > > > > > > > the
> > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the release
> > > > based
> > > > > > on
> > > > > > > > the
> > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > >> > > > branches, given we don't expect any code
> > > changes
> > > > > > > > anymore.
> > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to start
> > > the
> > > > > > > release
> > > > > > > > > > > process.
> > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > manual/automated
> > > > > > > > release
> > > > > > > > > > > > process,
> > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed
> > > to
> > > > > Git,
> > > > > > > and
> > > > > > > > > > built
> > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > artifacts
> > > > > to
> > > > > > be
> > > > > > > > > > > > propagated
> > > > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > manual/automated
> > > > > > > > release
> > > > > > > > > > > > > process,
> > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed
> > > to
> > > > > Git,
> > > > > > > and
> > > > > > > > > > built
> > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > >> > > > 12. Category E repos can be manually tagged
> > > with
> > > > > > > 10.0.0
> > > > > > > > > from
> > > > > > > > > > > > their
> > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > More needs to be discussed if we're planning
> > > to
> > > > > > > maintain
> > > > > > > > > > > > multiple
> > > > > > > > > > > > > >> > > > release streams in parallel, but I guess it
> > > can
> > > > > wait
> > > > > > > for
> > > > > > > > > > after
> > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking forward
> > > > to
> > > > > > > > hearing
> > > > > > > > > > back
> > > > > > > > > > > > > from
> > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Of course, alternative solutions are possible.
> > > > > This
> > > > > > > > email,
> > > > > > > > > > > > > however,
> > > > > > > > > > > > > >> > > > summarizes my view of how we should attack the
> > > > > > > problem,
> > > > > > > > > > > > > considering
> > > > > > > > > > > > > >> > > > disruption, required effort, the release
> > > process
> > > > > > > itself,
> > > > > > > > > and
> > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > >> > > > Feel free to propose alternatives. This is
> > > not a
> > > > > > > voting
> > > > > > > > > > > thread.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <po...@apache.org>.
Francisco,
Unfortunately I don’t think we are ready to have a conversation about how
the future will look like. There’s indeed a need to revisit the whole
codebase organization and even the branding positioning (as also mentioned
by Ricardo).
Such type of discussions will take time, and I don’t think it’s fair to
keep the release hostage because of that.
On Wed, Mar 13, 2024 at 9:58 AM Francisco Javier Tirado Sarti <
ftirados@redhat.com> wrote:
> Ok. I now can see why you are supporting the current proposal ;).
> However, in order to accept it, I would like to link this temporary
> proposal with a future one that accepts that tools repo cannot be the
> final one on the ci stream (and remove the freeze condition on the other
> repos, which is as absurd as runtime imposing a freeze on drools).
> Without that compromise to fix the tools repo overall position in our
> project, I cannot accept this temporary solution, because someone can argue
> that, after all, is conceptually fine, which, in my opinion, is not the
> case.
>
> On Wed, Mar 13, 2024 at 2:50 PM Alex Porcelli <al...@porcelli.me> wrote:
>
> > The guestimate of the plan discussed in this thread is around 2-3 weeks.
> >
> > On Wed, Mar 13, 2024 at 9:47 AM Francisco Javier Tirado Sarti
> > <ft...@redhat.com> wrote:
> > >
> > > Ok, thanks Alex for the clarification.
> > > So two months for changing the order of repos, that sounds realistic,
> > based
> > > on precedent, to me.
> > > Which is the estimation for the changes to be done in tools repo once
> all
> > > operator stuff is there?
> > > What I'm trying to find out now is if the proposed solution really
> takes
> > > less time. At the end both solutions imply moving stuff around between
> > > repos and changing CI, that's why I'm so insistent in pursuing the one
> > that
> > > makes more sense from a SW dependency point of view: one that does not
> > make
> > > "tooling" to be the final repo being processed.
> > >
> > > On Wed, Mar 13, 2024 at 2:33 PM Alex Porcelli <al...@porcelli.me>
> wrote:
> > >
> > > > Francisco,
> > > >
> > > > As I wrote earlier, I had a conversation with Jan - that is our
> > > > community CI expert - and he said that he guesses that it would take
> > > > about 2 months to make CI changes implied in your comments.
> > > >
> > > > He also mentioned that if Tristan was around and could dedicate his
> > > > time on this, he believes that Tristan could make the same changes
> > > > potentially in about 2 weeks.
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 9:26 AM Francisco Javier Tirado Sarti
> > > > <ft...@redhat.com> wrote:
> > > > >
> > > > > @Ricardo Zanini <za...@redhat.com> The main issue I have is why
> we
> > > > > conclude 1 takes less time than 2?. If I understood 1) completely,
> it
> > > > also
> > > > > requires CI adjustments (at tools repo level, not at overall stream
> > > > level),
> > > > > so I hardly see the estimation different for someone that is
> familiar
> > > > with
> > > > > CI.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 2:14 PM ricardo zanini fernandes <
> > > > > ricardozanini@gmail.com> wrote:
> > > > >
> > > > > > Hi!
> > > > > >
> > > > > > Clearly, you all understand that moving images and the operator
> to
> > > > > > kie-tools is a workaround and wrong in all possible scenarios,
> > right?
> > > > We
> > > > > > won't undo once we merge. I'm pretty positive that once we have a
> > > > release
> > > > > > train going people will add all the obstacles they can add saying
> > "It's
> > > > > > working, let's not change it".
> > > > > >
> > > > > > Also, I understand that we need to unblock the release. We can
> > > > compromise
> > > > > > in COPYING the code, do the release, and then make the necessary
> > > > changes.
> > > > > > Images and cloud code are *integration platforms*. Should be the
> > last
> > > > in a
> > > > > > stream. Tooling SHOULD NOT, in any case, depend on the images to
> > build.
> > > > > >
> > > > > > So we can:
> > > > > >
> > > > > > 1. Accept Tiago's proposal (very well detailed, thanks!) but
> > COPYING
> > > > the
> > > > > > code base, not MERGING. The contributions still flow to the right
> > > > repos.
> > > > > > 2. After release we:
> > > > > > 1. Move the CLI to the operator repo, removing this
> dependency
> > from
> > > > > > tools to image
> > > > > > 2. Adjust the CI
> > > > > > 3. Remove the copied code
> > > > > >
> > > > > > Moving forward, I'd like to see a clear boundary between the
> > projects
> > > > (as
> > > > > > stated in the temporary website). At the moment, we do not have.
> > And
> > > > it's
> > > > > > hard for anyone from outside to understand what we are doing.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me>
> > > > wrote:
> > > > > >
> > > > > > > Francisco and Gabriele,
> > > > > > >
> > > > > > > I understand and acknowledge your desire to find the “right”
> > solution
> > > > > > > instead to work on a temporary “patch” - however without a
> > detailed
> > > > > > > proposal I don’t think we can properly evaluate the impact of
> > your
> > > > > > > suggestion.
> > > > > > >
> > > > > > > When I spoke with different SMEs that included tools and CI,
> the
> > > > > > > guesstimate for making the necessary changes on CI and codebase
> > to
> > > > > > > basically have images and operators in the end of the build
> > chain is
> > > > > > > something like 2 months of effort. Another impact that needs to
> > be
> > > > > > > discussed is that KIE Tools repo had to be injected in the
> > middle of
> > > > all
> > > > > > > pipelines - forcing all PR checks and nightlies to build all
> > repos
> > > > (PR
> > > > > > > checks will likely take 12+ hours… I even heard that it could
> be
> > > > even 24
> > > > > > > hours).
> > > > > > >
> > > > > > > Based on the input above, I think it’s quite risk to move in
> such
> > > > > > direction
> > > > > > > without a more detailed plan… because 2 months could be turned
> > > > easily in
> > > > > > 6!
> > > > > > > And this is exactly what happened when we guessed that moving
> to
> > > > Apache
> > > > > > > would take no more than 3 months. But here we are.
> > > > > > >
> > > > > > > I really strongly suggest that we focus on a release that could
> > be
> > > > > > > achievable in less than a month from now, and we - after
> release
> > -
> > > > have a
> > > > > > > in depth discussion about the overall codebase and ci
> > organization.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Alex,
> > > > > > > > my suggestion is to move the building of all docker images,
> > from
> > > > > > whatever
> > > > > > > > repo (kogito-apps, kie-tools) in a different, downstream
> repo,
> > to
> > > > be
> > > > > > > > invoked after all the others.
> > > > > > > > I'm not sure if this would solve all the issues, and since I
> > could
> > > > not
> > > > > > > > enter in the details of all the involved code, my suggestion
> > may
> > > > be too
> > > > > > > > naive.
> > > > > > > > Having spent almost all of the last year in CI, I may say
> > that, at
> > > > > > least
> > > > > > > > for the kie-tools repo, removing the image build step from it
> > > > should
> > > > > > not
> > > > > > > be
> > > > > > > > too difficult (since it is an issue we already faced and
> > solved).
> > > > > > > > If, with "detailed proposal", you mean a complete list of all
> > > > modules
> > > > > > to
> > > > > > > be
> > > > > > > > moved and dependency refactoring, of course I can not provide
> > it
> > > > right
> > > > > > > now.
> > > > > > > >
> > > > > > > > Anyway, I share the concern from Francisco: undoing something
> > is
> > > > almost
> > > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier
> > Tirado
> > > > Sarti
> > > > > > <
> > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > >
> > > > > > > > > I do not think estimations should be the only driver to
> make
> > a
> > > > > > > decision,
> > > > > > > > > especially when the current proposal is conceptually
> > incompatible
> > > > > > with
> > > > > > > > the
> > > > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > > > Given my knowledge of the CI it is nearly impossible for me
> > to
> > > > give
> > > > > > a
> > > > > > > > fair
> > > > > > > > > estimate of how much it might take to achieve step 2) of my
> > > > previous
> > > > > > > > e-mail
> > > > > > > > > . It might take a while or it might be pretty easy after
> > all, I
> > > > don't
> > > > > > > > > really know, but I think it will be a good idea if some of
> > the
> > > > > > experts
> > > > > > > > on
> > > > > > > > > CI in the team (the ones that set up the pipeline, which
> was
> > a
> > > > huge
> > > > > > > > > achievement) give an estimate, not me. Estimating how much
> > it
> > > > takes
> > > > > > to
> > > > > > > > > merge two existing repos (without altering CI) is easier,
> > but it
> > > > does
> > > > > > > not
> > > > > > > > > mean we are doing the right thing.
> > > > > > > > > My main concern is that it will be very difficult for me to
> > > > explain
> > > > > > to
> > > > > > > > > someone that arrives new to the team, that having experts
> on
> > CI
> > > > on
> > > > > > the
> > > > > > > > > team, we decided to merge two repos (once merged, it would
> be
> > > > rather
> > > > > > > > > difficult to unmerge) rather than fix the CI, because of
> > > > expediency.
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > > porcelli@apache.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco,
> > > > > > > > > >
> > > > > > > > > > Please take the time to make the more in depth analysis
> > needed
> > > > and
> > > > > > > > > provide
> > > > > > > > > > a more detailed plan… so we - as community- can evaluate
> > the
> > > > size
> > > > > > of
> > > > > > > > the
> > > > > > > > > > effort. In the conceptual level you shared it’s near
> > > > impossible to
> > > > > > > > > estimate
> > > > > > > > > > the size of the effort and compare with the current
> > proposal.
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado
> > Sarti <
> > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > > 1) Remove all dependencies from tooling to images, so
> > images
> > > > > > > depend
> > > > > > > > on
> > > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > > 2) Then change CI to deal with tooling repo before
> > dealing
> > > > with
> > > > > > > > images
> > > > > > > > > > > repo.
> > > > > > > > > > > I understand that CI details are tricky and since I'm
> not
> > > > > > familiar
> > > > > > > > with
> > > > > > > > > > CI
> > > > > > > > > > > in any way, I barely can make a low level design, but
> we
> > do
> > > > not
> > > > > > > need
> > > > > > > > to
> > > > > > > > > > fix
> > > > > > > > > > > everything, just achieve 2), a change of compilation
> > order.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > > > alex@porcelli.me
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > > >
> > > > > > > > > > > > You may not like or understand why the current state
> of
> > > > the CI
> > > > > > is
> > > > > > > > > like
> > > > > > > > > > > > that… actually has been in Red Hat and has been
> > replicated
> > > > in
> > > > > > > > Apache
> > > > > > > > > as
> > > > > > > > > > > > used to be….
> > > > > > > > > > > >
> > > > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > > > >
> > > > > > > > > > > > If you disagree with the current plan, please
> provide a
> > > > > > detailed
> > > > > > > > > > > > alternative so we, as community, can better evaluate
> > the
> > > > pros
> > > > > > and
> > > > > > > > > cons
> > > > > > > > > > of
> > > > > > > > > > > > each proposal.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I think it’s also fair to say that, post 10 release
> we
> > > > need to
> > > > > > > > have a
> > > > > > > > > > > much
> > > > > > > > > > > > in depth discussion about how our codebase is
> > organized,
> > > > it’s
> > > > > > > clear
> > > > > > > > > > that
> > > > > > > > > > > > it’s not working.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > > I also have the impression that the "images" (if we
> > are
> > > > > > talking
> > > > > > > > of
> > > > > > > > > > > docker
> > > > > > > > > > > > > images) should be the very last one to be built,
> in a
> > > > > > > standalone
> > > > > > > > > > repo.
> > > > > > > > > > > > > That way, they may "combine" artifacts that are
> > built in
> > > > > > > > different
> > > > > > > > > > > repos,
> > > > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > > > Moving them out of all the repos
> > (kogito-apps/kie-tools)
> > > > > > maybe
> > > > > > > > > could
> > > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > > (I also think there are some statements of
> > undisputable
> > > > needs
> > > > > > > > while
> > > > > > > > > > > they
> > > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > > > > discussion.)
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco
> > Javier
> > > > > > > Tirado
> > > > > > > > > > Sarti
> > > > > > > > > > > <
> > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > > There are two assumptions that deserve further
> > > > discussion:
> > > > > > > > > > > > > > 1) That tool has to be the last to build. why? it
> > does
> > > > not
> > > > > > > have
> > > > > > > > > > more
> > > > > > > > > > > > > sense
> > > > > > > > > > > > > > to build final images after everything else has
> > been
> > > > > > built?-
> > > > > > > > > > > > > > 2) That the impact (in terms of effort now) on
> > fixing
> > > > CI is
> > > > > > > > > bigger
> > > > > > > > > > > than
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > impact (long term consequences) of consolidating
> > two
> > > > > > > unrelated
> > > > > > > > > > piece
> > > > > > > > > > > of
> > > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > > > alex@porcelli.me
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This was discussed as an alternative solution,
> > > > however it
> > > > > > > has
> > > > > > > > > > major
> > > > > > > > > > > > > > impact
> > > > > > > > > > > > > > > on CI and there’s also the fact Tool has been
> > always
> > > > the
> > > > > > > last
> > > > > > > > > to
> > > > > > > > > > > > build
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > has no Snapshot published (actually in
> JavaScript
> > > > world
> > > > > > > there
> > > > > > > > > is
> > > > > > > > > > no
> > > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So, based on our evaluation… the proposal here
> > is the
> > > > > > least
> > > > > > > > > > > > disruptive
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco
> Javier
> > > > Tirado
> > > > > > > > Sarti <
> > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > > > embracing
> > > > > > the
> > > > > > > > fact
> > > > > > > > > > > that
> > > > > > > > > > > > > > > > kogito-images depend on kie-tools, because we
> > want
> > > > > > those
> > > > > > > > > images
> > > > > > > > > > > to
> > > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco
> > Javier
> > > > > > Tirado
> > > > > > > > > Sarti
> > > > > > > > > > <
> > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > > > kn-plugin-workflow
> > > > > > > > > > to
> > > > > > > > > > > > > > > > > kogito-images (so there is not longer
> > dependency
> > > > from
> > > > > > > > tools
> > > > > > > > > > to
> > > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > then build kogito-images after
> kogito-tools?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique
> > Gonzalez
> > > > > > > > Martinez
> > > > > > > > > <
> > > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > > > (apache)
> > > > > > <
> > > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >> > I say +1 in order to move forward with
> > the 10.
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex
> > Porcelli <
> > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> > > I spent the last day or so working
> > closely
> > > > with
> > > > > > > > Tiago,
> > > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > > >> > > options and getting deeper on the
> > impact and
> > > > > > > > > evaluating
> > > > > > > > > > > the
> > > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > > >> > > procedure steps required. I agree with
> > the
> > > > > > > proposal
> > > > > > > > as
> > > > > > > > > > the
> > > > > > > > > > > > > most
> > > > > > > > > > > > > > > > >> > > viable option for unblocking the 10
> > release
> > > > in
> > > > > > the
> > > > > > > > > > > > reasonable
> > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago
> > Bento
> > > > <
> > > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr
> this
> > > > time,
> > > > > > as
> > > > > > > > this
> > > > > > > > > > > > matter
> > > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > This email will take you < 20
> minutes
> > to
> > > > read,
> > > > > > > > > > according
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > As you may have followed on a
> separate
> > > > thread
> > > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > > >
> > > > > > > > >
> > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > > >> > > > many of us were working towards
> > removing a
> > > > > > > > circular
> > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > >> > > > currently present between
> > `kogito-apps`
> > > > and
> > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > As
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > >> > > > progressed towards a solution, we
> kept
> > > > finding
> > > > > > > the
> > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > > > breakdown of
> > > > > > > the
> > > > > > > > > > things
> > > > > > > > > > > > we
> > > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Right now, even though we started
> the
> > > > effort
> > > > > > to
> > > > > > > > move
> > > > > > > > > > the
> > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we
> haven't
> > been
> > > > > > able
> > > > > > > to
> > > > > > > > > do
> > > > > > > > > > it
> > > > > > > > > > > > > yet,
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to
> Java
> > 17,
> > > > > > Maven
> > > > > > > > > 3.9.6,
> > > > > > > > > > > and
> > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito
> Runtimes
> > > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > >> > > > effort was concluded this Monday,
> with
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > > .
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > >> > > > |==> 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > >> > > > L |
> > ==========================
> > > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/extended-services
> > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > > > > `kie-tools`,
> > > > > > > > we
> > > > > > > > > > > > would've
> > > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > >> > > > 02.
> > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > >> > > > C |
> =====================
> > > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > * As
> > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > > >> > > > * and
> > > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > > depends
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > After moving the
> `kogito-swf-devmode`
> > > > image to
> > > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > >> > > > 02.
> > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > >> > > > 04.
> > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > >> > > > Y |
> =====================
> > > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > * As
> > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > > >> > > > * and
> > `kogito-serverless-operator`
> > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger
> problem
> > > > than a
> > > > > > > > simple
> > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > After multiple conversations with a
> > lot of
> > > > > > > people,
> > > > > > > > > > it's
> > > > > > > > > > > > been
> > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > >> > > > hard coming up with a simple
> solution
> > that
> > > > > > makes
> > > > > > > > it
> > > > > > > > > > > > possible
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while
> > preserving
> > > > the
> > > > > > way
> > > > > > > > > > > everyone
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > contributing to the multiple
> > repositories
> > > > we
> > > > > > > have.
> > > > > > > > > > More
> > > > > > > > > > > > than
> > > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > > >> > > > while making this assessment, I
> found
> > more
> > > > > > > > problems
> > > > > > > > > > > that,
> > > > > > > > > > > > in
> > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm
> > coming
> > > > > > forward
> > > > > > > > with
> > > > > > > > > > my
> > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > >> > > > the Apache KIE release process, so
> we
> > can
> > > > use
> > > > > > > > > Apache's
> > > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate
> > about
> > > > > > this
> > > > > > > > > really
> > > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective
> > about
> > > > the
> > > > > > > > current
> > > > > > > > > > > > > situation
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > > > currently
> > > > > > > see.
> > > > > > > > > > I'll
> > > > > > > > > > > > > start
> > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > >> > > > analysis of the repositories and
> their
> > > > > > purposes,
> > > > > > > > > point
> > > > > > > > > > > out
> > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > >> > > > problems that I believe are blocking
> > our
> > > > 10
> > > > > > > > release,
> > > > > > > > > > > > explain
> > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > >> > > > proposal and discuss some
> > consequences to
> > > > what
> > > > > > > I'm
> > > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO
> > (count:
> > > > 11)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @
> > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > > > >> > > > -
> > incubator-kie-optaplanner-quickstarts @
> > > > > > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @
> > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @
> > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @
> `main`
> > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-kogito-serverless-operator @
> > > > > > > > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @
> > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > > > updated @
> > > > > > > > `main`.
> > > > > > > > > > > Same
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @
> > `main`
> > > > > > > > > > > > > > > > >> > > > (The Kogito website. Develop &
> > deploy
> > > > at
> > > > > > the
> > > > > > > > > > `main`
> > > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > > > >> > > > (The KIE website. Develop @
> > `main`.
> > > > Push @
> > > > > > > > > > `deploy`
> > > > > > > > > > > to
> > > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> > `gh-pages`
> > > > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > > > sandbox.kie.org
> > > > > > > > and
> > > > > > > > > > KIE
> > > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-online-staging
> > @
> > > > `main`
> > > > > > > > > > > > > > > > >> > > > (Same as above, but for manual
> > sanity
> > > > > > checks
> > > > > > > > > > during
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > I grouped the repositories by
> > category,
> > > > and
> > > > > > > listed
> > > > > > > > > > them
> > > > > > > > > > > > in a
> > > > > > > > > > > > > > > > >> > > > topological order. Keep in mind that
> > when
> > > > > > > > flattening
> > > > > > > > > > > out a
> > > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > > >> > > > are multiple possibilities. For
> > example,
> > > > > > > > OptaPlanner
> > > > > > > > > > > > > could've
> > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > > > referring
> > > > > > to
> > > > > > > > as
> > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> > OptaPlanner
> > > > is
> > > > > > > inside
> > > > > > > > > > that
> > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > >> > > > way these repositories reference
> each
> > > > other
> > > > > > are
> > > > > > > > > > through
> > > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > > > 999-SNAPSHOT
> > > > > > > > > > version.
> > > > > > > > > > > > This
> > > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > > >> > > > is well-known to the team, and
> > although
> > > > flawed
> > > > > > > for
> > > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > > > different
> > > > > > time
> > > > > > > > > > zones,
> > > > > > > > > > > it
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > >> > > > very comfortable for everyone to
> work
> > > > with, I
> > > > > > > > > assume.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Contributions made to Category A
> have
> > some
> > > > > > > > dedicated
> > > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > >> > > > are, at least to some extent, able
> to
> > > > build
> > > > > > > > > cross-repo
> > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > >> > > > and verify that the codebase will
> > continue
> > > > > > > working
> > > > > > > > > as
> > > > > > > > > > > > > expected
> > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > >> > > > they're all merged. From what I
> could
> > > > gather,
> > > > > > > > there
> > > > > > > > > > are
> > > > > > > > > > > > some
> > > > > > > > > > > > > > > > >> > > > "sub-streams" currently configured
> for
> > > > > > > cross-repo
> > > > > > > > > PRs.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> > kogito-apps,
> > > > and
> > > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > > >> > > > - optaplanner, and
> > optaplanner-quickstarts
> > > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > This means that sending cross-repo
> > PRs to
> > > > any
> > > > > > > > > > > combination
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > >> > > > that are not part of the same
> > "sub-stream"
> > > > > > > cannot
> > > > > > > > be
> > > > > > > > > > > > > verified
> > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > >> > > > merging, making our contribution
> model
> > > > > > dependent
> > > > > > > > on
> > > > > > > > > > > > > individual
> > > > > > > > > > > > > > > > >> > > > contributors building stuff on their
> > > > machines
> > > > > > to
> > > > > > > > > > verify
> > > > > > > > > > > > that
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with
> > these
> > > > > > > > > pipelines,
> > > > > > > > > > so
> > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > > > referring
> > > > > > to
> > > > > > > > as
> > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > >> > > > stream. The first repo there is a
> > template
> > > > > > > > > repository
> > > > > > > > > > > that
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > > >> > > > people starting projects from
> scratch
> > on
> > > > KIE
> > > > > > > > > Sandbox,
> > > > > > > > > > > > > similar
> > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The
> > other
> > > > one is
> > > > > > > the
> > > > > > > > > KIE
> > > > > > > > > > > > Tools
> > > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as
> its
> > > > build
> > > > > > > > system.
> > > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > > > > TypeScript
> > > > > > > > > > > libraries
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm
> charts.
> > The
> > > > > > > > > `kie-tools`
> > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > >> > > > configured to work with sparse
> > checkouts
> > > > and
> > > > > > can
> > > > > > > > do
> > > > > > > > > > > > partial
> > > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > > >> > > > Category B repos refer to Category A
> > repos
> > > > > > > through
> > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism
> we
> > > > recently
> > > > > > > > > > > introduced
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > >> > > > build and publish immutable,
> > persistent
> > > > > > > artifacts
> > > > > > > > > > under
> > > > > > > > > > > a
> > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> > > > format,
> > > > > > > > > published
> > > > > > > > > > > > weekly
> > > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs
> > are an
> > > > > > > > evolution
> > > > > > > > > > to
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > > > release
> > > > > > for
> > > > > > > > all
> > > > > > > > > > of
> > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > >> > > > we can't have Kogito releases
> anymore.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > An important note here is that
> > Category B
> > > > > > > > > repositories
> > > > > > > > > > > > have
> > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > >> > > > historically kept out of any
> > automations
> > > > we
> > > > > > used
> > > > > > > > to
> > > > > > > > > > > have,
> > > > > > > > > > > > > way
> > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > > > Business
> > > > > > > > Central
> > > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > > >> > > > still going on. For this reason,
> > Category
> > > > B
> > > > > > > > projects
> > > > > > > > > > > have
> > > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > > >> > > > their own automations, based on
> GitHub
> > > > > > Actions.
> > > > > > > > > > > Category B
> > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > > >> > > > always depended on Category A repos
> > using
> > > > > > fixed
> > > > > > > > > > > versions.
> > > > > > > > > > > > If
> > > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > > > SNAPSHOTs,
> > > > > > > > breaking
> > > > > > > > > > > > changes
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > Category A repositories would've had
> > the
> > > > > > > potential
> > > > > > > > > to
> > > > > > > > > > > > break
> > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > >> > > > silently, leaving Category B with a
> > broken
> > > > > > > > > development
> > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > > > > maintainers
> > > > > > > > of
> > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > > >> > > > as historically Category A
> > contributors
> > > > were
> > > > > > not
> > > > > > > > > > > familiar
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Contributions made to Category B
> > repos go
> > > > > > > through
> > > > > > > > a
> > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > > >> > > > workflow that builds the relevant
> > part of
> > > > the
> > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > >> > > > the changes introduced. Changes made
> > to
> > > > the
> > > > > > > > pipeline
> > > > > > > > > > > > itself
> > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing
> us
> > to
> > > > do
> > > > > > > things
> > > > > > > > > > like
> > > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> > example.
> > > > More
> > > > > > > > > > > > importantly,
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > > >> > > > us to upgrade the repository to a
> new
> > > > > > > timestamped
> > > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > >> > > > with the changes necessary to make
> it
> > stay
> > > > > > > green.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > This setup, however, makes it
> > impossible
> > > > to
> > > > > > have
> > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > > > simultaneously,
> > > > > > > > > > with
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Category C repos are kind of
> floating
> > > > around,
> > > > > > > and
> > > > > > > > > I'm
> > > > > > > > > > > not
> > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > >> > > > there's much activity going on
> there.
> > > > > > > Regardless,
> > > > > > > > as
> > > > > > > > > > > > they're
> > > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > > > release,
> > > > > > > so I
> > > > > > > > > > > listed
> > > > > > > > > > > > > them
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Category D is self explanatory.
> > There's
> > > > only
> > > > > > one
> > > > > > > > > repo
> > > > > > > > > > > that
> > > > > > > > > > > > > has
> > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Category E are repos that do not
> host
> > code
> > > > > > > > directly,
> > > > > > > > > > and
> > > > > > > > > > > > are
> > > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > > >> > > > organizational entities, or host
> > websites,
> > > > > > that
> > > > > > > > > > > currently
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > This lack of unification between
> > Category
> > > > A
> > > > > > and
> > > > > > > > > > > Category B
> > > > > > > > > > > > > is,
> > > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> > infamous
> > > > > > > circular
> > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which
> > we
> > > > now
> > > > > > can
> > > > > > > > > > describe
> > > > > > > > > > > > as
> > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > > >> > > > dependency between Category A and
> > > > Category B.
> > > > > > > The
> > > > > > > > > way
> > > > > > > > > > I
> > > > > > > > > > > > see
> > > > > > > > > > > > > > it,
> > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > >> > > > had a single pipeline, building
> > everything
> > > > > > from
> > > > > > > > > > `drools`
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've
> never
> > > > been
> > > > > > > > > > introduced,
> > > > > > > > > > > > and
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem
> > in
> > > > our
> > > > > > > hands
> > > > > > > > > > right
> > > > > > > > > > > > now.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE
> release
> > > > process
> > > > > > > > sees
> > > > > > > > > > this
> > > > > > > > > > > > > lack
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > >> > > > unification as a central problem,
> not
> > > > only for
> > > > > > > > this
> > > > > > > > > > > > release
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > >> > > > particular, but for the community
> as a
> > > > whole.
> > > > > > It
> > > > > > > > is
> > > > > > > > > my
> > > > > > > > > > > > > belief
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > >> > > > are all under the same roof, and
> that
> > no
> > > > > > > > > contribution
> > > > > > > > > > > > should
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > >> > > > allowed to break any part of our
> > codebase.
> > > > > > With
> > > > > > > > the
> > > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > > > contributors
> > > > > > > too,
> > > > > > > > > we
> > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> > > > breaking
> > > > > > > > things.
> > > > > > > > > > > We're
> > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > > > > mechanisms
> > > > > > > in
> > >
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Ok. I now can see why you are supporting the current proposal ;).
However, in order to accept it, I would like to link this temporary
proposal with a future one that accepts that tools repo cannot be the
final one on the ci stream (and remove the freeze condition on the other
repos, which is as absurd as runtime imposing a freeze on drools).
Without that compromise to fix the tools repo overall position in our
project, I cannot accept this temporary solution, because someone can argue
that, after all, is conceptually fine, which, in my opinion, is not the
case.
On Wed, Mar 13, 2024 at 2:50 PM Alex Porcelli <al...@porcelli.me> wrote:
> The guestimate of the plan discussed in this thread is around 2-3 weeks.
>
> On Wed, Mar 13, 2024 at 9:47 AM Francisco Javier Tirado Sarti
> <ft...@redhat.com> wrote:
> >
> > Ok, thanks Alex for the clarification.
> > So two months for changing the order of repos, that sounds realistic,
> based
> > on precedent, to me.
> > Which is the estimation for the changes to be done in tools repo once all
> > operator stuff is there?
> > What I'm trying to find out now is if the proposed solution really takes
> > less time. At the end both solutions imply moving stuff around between
> > repos and changing CI, that's why I'm so insistent in pursuing the one
> that
> > makes more sense from a SW dependency point of view: one that does not
> make
> > "tooling" to be the final repo being processed.
> >
> > On Wed, Mar 13, 2024 at 2:33 PM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > Francisco,
> > >
> > > As I wrote earlier, I had a conversation with Jan - that is our
> > > community CI expert - and he said that he guesses that it would take
> > > about 2 months to make CI changes implied in your comments.
> > >
> > > He also mentioned that if Tristan was around and could dedicate his
> > > time on this, he believes that Tristan could make the same changes
> > > potentially in about 2 weeks.
> > >
> > >
> > > On Wed, Mar 13, 2024 at 9:26 AM Francisco Javier Tirado Sarti
> > > <ft...@redhat.com> wrote:
> > > >
> > > > @Ricardo Zanini <za...@redhat.com> The main issue I have is why we
> > > > conclude 1 takes less time than 2?. If I understood 1) completely, it
> > > also
> > > > requires CI adjustments (at tools repo level, not at overall stream
> > > level),
> > > > so I hardly see the estimation different for someone that is familiar
> > > with
> > > > CI.
> > > >
> > > > On Wed, Mar 13, 2024 at 2:14 PM ricardo zanini fernandes <
> > > > ricardozanini@gmail.com> wrote:
> > > >
> > > > > Hi!
> > > > >
> > > > > Clearly, you all understand that moving images and the operator to
> > > > > kie-tools is a workaround and wrong in all possible scenarios,
> right?
> > > We
> > > > > won't undo once we merge. I'm pretty positive that once we have a
> > > release
> > > > > train going people will add all the obstacles they can add saying
> "It's
> > > > > working, let's not change it".
> > > > >
> > > > > Also, I understand that we need to unblock the release. We can
> > > compromise
> > > > > in COPYING the code, do the release, and then make the necessary
> > > changes.
> > > > > Images and cloud code are *integration platforms*. Should be the
> last
> > > in a
> > > > > stream. Tooling SHOULD NOT, in any case, depend on the images to
> build.
> > > > >
> > > > > So we can:
> > > > >
> > > > > 1. Accept Tiago's proposal (very well detailed, thanks!) but
> COPYING
> > > the
> > > > > code base, not MERGING. The contributions still flow to the right
> > > repos.
> > > > > 2. After release we:
> > > > > 1. Move the CLI to the operator repo, removing this dependency
> from
> > > > > tools to image
> > > > > 2. Adjust the CI
> > > > > 3. Remove the copied code
> > > > >
> > > > > Moving forward, I'd like to see a clear boundary between the
> projects
> > > (as
> > > > > stated in the temporary website). At the moment, we do not have.
> And
> > > it's
> > > > > hard for anyone from outside to understand what we are doing.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > >
> > > > > > Francisco and Gabriele,
> > > > > >
> > > > > > I understand and acknowledge your desire to find the “right”
> solution
> > > > > > instead to work on a temporary “patch” - however without a
> detailed
> > > > > > proposal I don’t think we can properly evaluate the impact of
> your
> > > > > > suggestion.
> > > > > >
> > > > > > When I spoke with different SMEs that included tools and CI, the
> > > > > > guesstimate for making the necessary changes on CI and codebase
> to
> > > > > > basically have images and operators in the end of the build
> chain is
> > > > > > something like 2 months of effort. Another impact that needs to
> be
> > > > > > discussed is that KIE Tools repo had to be injected in the
> middle of
> > > all
> > > > > > pipelines - forcing all PR checks and nightlies to build all
> repos
> > > (PR
> > > > > > checks will likely take 12+ hours… I even heard that it could be
> > > even 24
> > > > > > hours).
> > > > > >
> > > > > > Based on the input above, I think it’s quite risk to move in such
> > > > > direction
> > > > > > without a more detailed plan… because 2 months could be turned
> > > easily in
> > > > > 6!
> > > > > > And this is exactly what happened when we guessed that moving to
> > > Apache
> > > > > > would take no more than 3 months. But here we are.
> > > > > >
> > > > > > I really strongly suggest that we focus on a release that could
> be
> > > > > > achievable in less than a month from now, and we - after release
> -
> > > have a
> > > > > > in depth discussion about the overall codebase and ci
> organization.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > > gabriele.cardosi@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Alex,
> > > > > > > my suggestion is to move the building of all docker images,
> from
> > > > > whatever
> > > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo,
> to
> > > be
> > > > > > > invoked after all the others.
> > > > > > > I'm not sure if this would solve all the issues, and since I
> could
> > > not
> > > > > > > enter in the details of all the involved code, my suggestion
> may
> > > be too
> > > > > > > naive.
> > > > > > > Having spent almost all of the last year in CI, I may say
> that, at
> > > > > least
> > > > > > > for the kie-tools repo, removing the image build step from it
> > > should
> > > > > not
> > > > > > be
> > > > > > > too difficult (since it is an issue we already faced and
> solved).
> > > > > > > If, with "detailed proposal", you mean a complete list of all
> > > modules
> > > > > to
> > > > > > be
> > > > > > > moved and dependency refactoring, of course I can not provide
> it
> > > right
> > > > > > now.
> > > > > > >
> > > > > > > Anyway, I share the concern from Francisco: undoing something
> is
> > > almost
> > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier
> Tirado
> > > Sarti
> > > > > <
> > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > >
> > > > > > > > I do not think estimations should be the only driver to make
> a
> > > > > > decision,
> > > > > > > > especially when the current proposal is conceptually
> incompatible
> > > > > with
> > > > > > > the
> > > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > > Given my knowledge of the CI it is nearly impossible for me
> to
> > > give
> > > > > a
> > > > > > > fair
> > > > > > > > estimate of how much it might take to achieve step 2) of my
> > > previous
> > > > > > > e-mail
> > > > > > > > . It might take a while or it might be pretty easy after
> all, I
> > > don't
> > > > > > > > really know, but I think it will be a good idea if some of
> the
> > > > > experts
> > > > > > > on
> > > > > > > > CI in the team (the ones that set up the pipeline, which was
> a
> > > huge
> > > > > > > > achievement) give an estimate, not me. Estimating how much
> it
> > > takes
> > > > > to
> > > > > > > > merge two existing repos (without altering CI) is easier,
> but it
> > > does
> > > > > > not
> > > > > > > > mean we are doing the right thing.
> > > > > > > > My main concern is that it will be very difficult for me to
> > > explain
> > > > > to
> > > > > > > > someone that arrives new to the team, that having experts on
> CI
> > > on
> > > > > the
> > > > > > > > team, we decided to merge two repos (once merged, it would be
> > > rather
> > > > > > > > difficult to unmerge) rather than fix the CI, because of
> > > expediency.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > porcelli@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco,
> > > > > > > > >
> > > > > > > > > Please take the time to make the more in depth analysis
> needed
> > > and
> > > > > > > > provide
> > > > > > > > > a more detailed plan… so we - as community- can evaluate
> the
> > > size
> > > > > of
> > > > > > > the
> > > > > > > > > effort. In the conceptual level you shared it’s near
> > > impossible to
> > > > > > > > estimate
> > > > > > > > > the size of the effort and compare with the current
> proposal.
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado
> Sarti <
> > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > 1) Remove all dependencies from tooling to images, so
> images
> > > > > > depend
> > > > > > > on
> > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > 2) Then change CI to deal with tooling repo before
> dealing
> > > with
> > > > > > > images
> > > > > > > > > > repo.
> > > > > > > > > > I understand that CI details are tricky and since I'm not
> > > > > familiar
> > > > > > > with
> > > > > > > > > CI
> > > > > > > > > > in any way, I barely can make a low level design, but we
> do
> > > not
> > > > > > need
> > > > > > > to
> > > > > > > > > fix
> > > > > > > > > > everything, just achieve 2), a change of compilation
> order.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > > alex@porcelli.me
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > >
> > > > > > > > > > > You may not like or understand why the current state of
> > > the CI
> > > > > is
> > > > > > > > like
> > > > > > > > > > > that… actually has been in Red Hat and has been
> replicated
> > > in
> > > > > > > Apache
> > > > > > > > as
> > > > > > > > > > > used to be….
> > > > > > > > > > >
> > > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > > >
> > > > > > > > > > > If you disagree with the current plan, please provide a
> > > > > detailed
> > > > > > > > > > > alternative so we, as community, can better evaluate
> the
> > > pros
> > > > > and
> > > > > > > > cons
> > > > > > > > > of
> > > > > > > > > > > each proposal.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I think it’s also fair to say that, post 10 release we
> > > need to
> > > > > > > have a
> > > > > > > > > > much
> > > > > > > > > > > in depth discussion about how our codebase is
> organized,
> > > it’s
> > > > > > clear
> > > > > > > > > that
> > > > > > > > > > > it’s not working.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > I also have the impression that the "images" (if we
> are
> > > > > talking
> > > > > > > of
> > > > > > > > > > docker
> > > > > > > > > > > > images) should be the very last one to be built, in a
> > > > > > standalone
> > > > > > > > > repo.
> > > > > > > > > > > > That way, they may "combine" artifacts that are
> built in
> > > > > > > different
> > > > > > > > > > repos,
> > > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > > Moving them out of all the repos
> (kogito-apps/kie-tools)
> > > > > maybe
> > > > > > > > could
> > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > (I also think there are some statements of
> undisputable
> > > needs
> > > > > > > while
> > > > > > > > > > they
> > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > > > discussion.)
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco
> Javier
> > > > > > Tirado
> > > > > > > > > Sarti
> > > > > > > > > > <
> > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > >
> > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > There are two assumptions that deserve further
> > > discussion:
> > > > > > > > > > > > > 1) That tool has to be the last to build. why? it
> does
> > > not
> > > > > > have
> > > > > > > > > more
> > > > > > > > > > > > sense
> > > > > > > > > > > > > to build final images after everything else has
> been
> > > > > built?-
> > > > > > > > > > > > > 2) That the impact (in terms of effort now) on
> fixing
> > > CI is
> > > > > > > > bigger
> > > > > > > > > > than
> > > > > > > > > > > > the
> > > > > > > > > > > > > impact (long term consequences) of consolidating
> two
> > > > > > unrelated
> > > > > > > > > piece
> > > > > > > > > > of
> > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > > alex@porcelli.me
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This was discussed as an alternative solution,
> > > however it
> > > > > > has
> > > > > > > > > major
> > > > > > > > > > > > > impact
> > > > > > > > > > > > > > on CI and there’s also the fact Tool has been
> always
> > > the
> > > > > > last
> > > > > > > > to
> > > > > > > > > > > build
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> > > world
> > > > > > there
> > > > > > > > is
> > > > > > > > > no
> > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So, based on our evaluation… the proposal here
> is the
> > > > > least
> > > > > > > > > > > disruptive
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> > > Tirado
> > > > > > > Sarti <
> > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > > embracing
> > > > > the
> > > > > > > fact
> > > > > > > > > > that
> > > > > > > > > > > > > > > kogito-images depend on kie-tools, because we
> want
> > > > > those
> > > > > > > > images
> > > > > > > > > > to
> > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco
> Javier
> > > > > Tirado
> > > > > > > > Sarti
> > > > > > > > > <
> > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > > kn-plugin-workflow
> > > > > > > > > to
> > > > > > > > > > > > > > > > kogito-images (so there is not longer
> dependency
> > > from
> > > > > > > tools
> > > > > > > > > to
> > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique
> Gonzalez
> > > > > > > Martinez
> > > > > > > > <
> > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > > (apache)
> > > > > <
> > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> > I say +1 in order to move forward with
> the 10.
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex
> Porcelli <
> > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > I spent the last day or so working
> closely
> > > with
> > > > > > > Tiago,
> > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > >> > > options and getting deeper on the
> impact and
> > > > > > > > evaluating
> > > > > > > > > > the
> > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > >> > > procedure steps required. I agree with
> the
> > > > > > proposal
> > > > > > > as
> > > > > > > > > the
> > > > > > > > > > > > most
> > > > > > > > > > > > > > > >> > > viable option for unblocking the 10
> release
> > > in
> > > > > the
> > > > > > > > > > > reasonable
> > > > > > > > > > > > > time
> > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago
> Bento
> > > <
> > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> > > time,
> > > > > as
> > > > > > > this
> > > > > > > > > > > matter
> > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes
> to
> > > read,
> > > > > > > > > according
> > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > > thread
> > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > >
> > > > > > > >
> https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > >> > > > many of us were working towards
> removing a
> > > > > > > circular
> > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > >> > > > currently present between
> `kogito-apps`
> > > and
> > > > > > > > > `kie-tools`.
> > > > > > > > > > > As
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > > finding
> > > > > > the
> > > > > > > > > > > circular
> > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > > breakdown of
> > > > > > the
> > > > > > > > > things
> > > > > > > > > > > we
> > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Right now, even though we started the
> > > effort
> > > > > to
> > > > > > > move
> > > > > > > > > the
> > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't
> been
> > > > > able
> > > > > > to
> > > > > > > > do
> > > > > > > > > it
> > > > > > > > > > > > yet,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java
> 17,
> > > > > Maven
> > > > > > > > 3.9.6,
> > > > > > > > > > and
> > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > .
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > |==> 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > L |
> ==========================
> > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> `kie-tools`/extended-services
> > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > > > `kie-tools`,
> > > > > > > we
> > > > > > > > > > > would've
> > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > 02.
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > 03.
> > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > > `kie-tools`/kn-plugin-workflow
> > > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > >> > > > * and
> > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > depends
> > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> > > image to
> > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > 02.
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > 03.
> > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > 04.
> > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > > `kie-tools`/kn-plugin-workflow
> > > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > >> > > > * and
> `kogito-serverless-operator`
> > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> > > than a
> > > > > > > simple
> > > > > > > > > > > > circular
> > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After multiple conversations with a
> lot of
> > > > > > people,
> > > > > > > > > it's
> > > > > > > > > > > been
> > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > >> > > > hard coming up with a simple solution
> that
> > > > > makes
> > > > > > > it
> > > > > > > > > > > possible
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while
> preserving
> > > the
> > > > > way
> > > > > > > > > > everyone
> > > > > > > > > > > is
> > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > contributing to the multiple
> repositories
> > > we
> > > > > > have.
> > > > > > > > > More
> > > > > > > > > > > than
> > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > >> > > > while making this assessment, I found
> more
> > > > > > > problems
> > > > > > > > > > that,
> > > > > > > > > > > in
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm
> coming
> > > > > forward
> > > > > > > with
> > > > > > > > > my
> > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we
> can
> > > use
> > > > > > > > Apache's
> > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate
> about
> > > > > this
> > > > > > > > really
> > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective
> about
> > > the
> > > > > > > current
> > > > > > > > > > > > situation
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > > currently
> > > > > > see.
> > > > > > > > > I'll
> > > > > > > > > > > > start
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > > > purposes,
> > > > > > > > point
> > > > > > > > > > out
> > > > > > > > > > > > > some
> > > > > > > > > > > > > > > >> > > > problems that I believe are blocking
> our
> > > 10
> > > > > > > release,
> > > > > > > > > > > explain
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > >> > > > proposal and discuss some
> consequences to
> > > what
> > > > > > I'm
> > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO
> (count:
> > > 11)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > > >> > > > -
> incubator-kie-optaplanner-quickstarts @
> > > > > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-serverless-operator @
> > > > > > > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > > updated @
> > > > > > > `main`.
> > > > > > > > > > Same
> > > > > > > > > > > > for
> > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @
> `main`
> > > > > > > > > > > > > > > >> > > > (The Kogito website. Develop &
> deploy
> > > at
> > > > > the
> > > > > > > > > `main`
> > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > > >> > > > (The KIE website. Develop @
> `main`.
> > > Push @
> > > > > > > > > `deploy`
> > > > > > > > > > to
> > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> `gh-pages`
> > > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > > sandbox.kie.org
> > > > > > > and
> > > > > > > > > KIE
> > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging
> @
> > > `main`
> > > > > > > > > > > > > > > >> > > > (Same as above, but for manual
> sanity
> > > > > checks
> > > > > > > > > during
> > > > > > > > > > > the
> > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I grouped the repositories by
> category,
> > > and
> > > > > > listed
> > > > > > > > > them
> > > > > > > > > > > in a
> > > > > > > > > > > > > > > >> > > > topological order. Keep in mind that
> when
> > > > > > > flattening
> > > > > > > > > > out a
> > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > >> > > > are multiple possibilities. For
> example,
> > > > > > > OptaPlanner
> > > > > > > > > > > > could've
> > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > > referring
> > > > > to
> > > > > > > as
> > > > > > > > > > > `drools`
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> OptaPlanner
> > > is
> > > > > > inside
> > > > > > > > > that
> > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > way these repositories reference each
> > > other
> > > > > are
> > > > > > > > > through
> > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > > 999-SNAPSHOT
> > > > > > > > > version.
> > > > > > > > > > > This
> > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > >> > > > is well-known to the team, and
> although
> > > flawed
> > > > > > for
> > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > > different
> > > > > time
> > > > > > > > > zones,
> > > > > > > > > > it
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> > > with, I
> > > > > > > > assume.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Contributions made to Category A have
> some
> > > > > > > dedicated
> > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> > > build
> > > > > > > > cross-repo
> > > > > > > > > > PRs
> > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > >> > > > and verify that the codebase will
> continue
> > > > > > working
> > > > > > > > as
> > > > > > > > > > > > expected
> > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > > gather,
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > > some
> > > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > > > cross-repo
> > > > > > > > PRs.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> kogito-apps,
> > > and
> > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > >> > > > - optaplanner, and
> optaplanner-quickstarts
> > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This means that sending cross-repo
> PRs to
> > > any
> > > > > > > > > > combination
> > > > > > > > > > > of
> > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > >> > > > that are not part of the same
> "sub-stream"
> > > > > > cannot
> > > > > > > be
> > > > > > > > > > > > verified
> > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > > > dependent
> > > > > > > on
> > > > > > > > > > > > individual
> > > > > > > > > > > > > > > >> > > > contributors building stuff on their
> > > machines
> > > > > to
> > > > > > > > > verify
> > > > > > > > > > > that
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with
> these
> > > > > > > > pipelines,
> > > > > > > > > so
> > > > > > > > > > > > > please
> > > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > > referring
> > > > > to
> > > > > > > as
> > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > >> > > > stream. The first repo there is a
> template
> > > > > > > > repository
> > > > > > > > > > that
> > > > > > > > > > > > is
> > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > >> > > > people starting projects from scratch
> on
> > > KIE
> > > > > > > > Sandbox,
> > > > > > > > > > > > similar
> > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The
> other
> > > one is
> > > > > > the
> > > > > > > > KIE
> > > > > > > > > > > Tools
> > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> > > build
> > > > > > > system.
> > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > > > TypeScript
> > > > > > > > > > libraries
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts.
> The
> > > > > > > > `kie-tools`
> > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > >> > > > configured to work with sparse
> checkouts
> > > and
> > > > > can
> > > > > > > do
> > > > > > > > > > > partial
> > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > >> > > > Category B repos refer to Category A
> repos
> > > > > > through
> > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > > recently
> > > > > > > > > > introduced
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > >> > > > build and publish immutable,
> persistent
> > > > > > artifacts
> > > > > > > > > under
> > > > > > > > > > a
> > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> > > format,
> > > > > > > > published
> > > > > > > > > > > weekly
> > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs
> are an
> > > > > > > evolution
> > > > > > > > > to
> > > > > > > > > > > the
> > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > > release
> > > > > for
> > > > > > > all
> > > > > > > > > of
> > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > An important note here is that
> Category B
> > > > > > > > repositories
> > > > > > > > > > > have
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > > >> > > > historically kept out of any
> automations
> > > we
> > > > > used
> > > > > > > to
> > > > > > > > > > have,
> > > > > > > > > > > > way
> > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > > Business
> > > > > > > Central
> > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > >> > > > still going on. For this reason,
> Category
> > > B
> > > > > > > projects
> > > > > > > > > > have
> > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > > > Actions.
> > > > > > > > > > Category B
> > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > >> > > > always depended on Category A repos
> using
> > > > > fixed
> > > > > > > > > > versions.
> > > > > > > > > > > If
> > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > > SNAPSHOTs,
> > > > > > > breaking
> > > > > > > > > > > changes
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > Category A repositories would've had
> the
> > > > > > potential
> > > > > > > > to
> > > > > > > > > > > break
> > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > >> > > > silently, leaving Category B with a
> broken
> > > > > > > > development
> > > > > > > > > > > > stream,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > > > maintainers
> > > > > > > of
> > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > >> > > > as historically Category A
> contributors
> > > were
> > > > > not
> > > > > > > > > > familiar
> > > > > > > > > > > > with
> > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Contributions made to Category B
> repos go
> > > > > > through
> > > > > > > a
> > > > > > > > > > GitHub
> > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > >> > > > workflow that builds the relevant
> part of
> > > the
> > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > >> > > > the changes introduced. Changes made
> to
> > > the
> > > > > > > pipeline
> > > > > > > > > > > itself
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us
> to
> > > do
> > > > > > things
> > > > > > > > > like
> > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> example.
> > > More
> > > > > > > > > > > importantly,
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > > > timestamped
> > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > >> > > > with the changes necessary to make it
> stay
> > > > > > green.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This setup, however, makes it
> impossible
> > > to
> > > > > have
> > > > > > > > > > > cross-repo
> > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > > simultaneously,
> > > > > > > > > with
> > > > > > > > > > > the
> > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > > around,
> > > > > > and
> > > > > > > > I'm
> > > > > > > > > > not
> > > > > > > > > > > > sure
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > > > Regardless,
> > > > > > > as
> > > > > > > > > > > they're
> > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > > release,
> > > > > > so I
> > > > > > > > > > listed
> > > > > > > > > > > > them
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category D is self explanatory.
> There's
> > > only
> > > > > one
> > > > > > > > repo
> > > > > > > > > > that
> > > > > > > > > > > > has
> > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category E are repos that do not host
> code
> > > > > > > directly,
> > > > > > > > > and
> > > > > > > > > > > are
> > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > >> > > > organizational entities, or host
> websites,
> > > > > that
> > > > > > > > > > currently
> > > > > > > > > > > > are
> > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This lack of unification between
> Category
> > > A
> > > > > and
> > > > > > > > > > Category B
> > > > > > > > > > > > is,
> > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> infamous
> > > > > > circular
> > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which
> we
> > > now
> > > > > can
> > > > > > > > > describe
> > > > > > > > > > > as
> > > > > > > > > > > > a
> > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > >> > > > dependency between Category A and
> > > Category B.
> > > > > > The
> > > > > > > > way
> > > > > > > > > I
> > > > > > > > > > > see
> > > > > > > > > > > > > it,
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > had a single pipeline, building
> everything
> > > > > from
> > > > > > > > > `drools`
> > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> > > been
> > > > > > > > > introduced,
> > > > > > > > > > > and
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem
> in
> > > our
> > > > > > hands
> > > > > > > > > right
> > > > > > > > > > > now.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > > process
> > > > > > > sees
> > > > > > > > > this
> > > > > > > > > > > > lack
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > unification as a central problem, not
> > > only for
> > > > > > > this
> > > > > > > > > > > release
> > > > > > > > > > > > in
> > > > > > > > > > > > > > > >> > > > particular, but for the community as a
> > > whole.
> > > > > It
> > > > > > > is
> > > > > > > > my
> > > > > > > > > > > > belief
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > are all under the same roof, and that
> no
> > > > > > > > contribution
> > > > > > > > > > > should
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > >> > > > allowed to break any part of our
> codebase.
> > > > > With
> > > > > > > the
> > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > > contributors
> > > > > > too,
> > > > > > > > we
> > > > > > > > > > > cannot
> > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> > > breaking
> > > > > > > things.
> > > > > > > > > > We're
> > > > > > > > > > > > all
> > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > > > mechanisms
> > > > > > in
> > > > > > > > > place
> > > > > > > > > > > to
> > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> > > Especially
> > > > > > when
> > > > > > > > > these
> > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > >> > > > impact on parts of the codebase that
> we,
> > > > > > > > individually,
> > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > > depending
> > > > > on
> > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > > > `kogito-images`
> > > > > > > > > > > > depending
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools`
> depending on
> > > > > > > > kiegroup's
> > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > > > depending
> > > > > > on
> > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > > > codebase
> > > > > > > > here:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >
> > > > > > > > > >
> > > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > > ,
> > > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > > > OptaPlanner,
> > > > > > > > > > > pointing
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > older
> > > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P5.
> > > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > > depending
> > > > > > > > > > > on
> > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> `2.15.3.Final`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P6. Category C repos are out of date
> and
> > > not
> > > > > > part
> > > > > > > of
> > > > > > > > > the
> > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> > > (Current
> > > > > > > version
> > > > > > > > is
> > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > > > version,
> > > > > > > only
> > > > > > > > > by
> > > > > > > > > > > > using
> > > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> > > version
> > > > > is
> > > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > > > OptaPlanner
> > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P7.
> > > `kie-tools`/packages/kn-plugin-workflow
> > > > > has
> > > > > > > its
> > > > > > > > > E2E
> > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the
> same
> > > > > > > solution,
> > > > > > > > > as
> > > > > > > > > > > they
> > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > >> > > > suffer from the circular dependency
> > > between
> > > > > > > > Category A
> > > > > > > > > > and
> > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > > >> > > > As Category A and Category B are both
> > > streams
> > > > > > that
> > > > > > > > > have
> > > > > > > > > > > been
> > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > >> > > > active, I see this as a blocker, as
> there
> > > are
> > > > > > > > > > > contributions
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> > > depends
> > > > > on
> > > > > > > > > > Category
> > > > > > > > > > > B
> > > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > > > understood
> > > > > > > as
> > > > > > > > > > > > technical
> > > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > > > something
> > > > > > > > we'll
> > > > > > > > > > > always
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> > > just a
> > > > > > > matter
> > > > > > > > of
> > > > > > > > > > > > making
> > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> > > impact
> > > > > the
> > > > > > > > > > structure
> > > > > > > > > > > or
> > > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > > >> > > > that we're talking about here, but it
> is a
> > > > > > > > regression
> > > > > > > > > we
> > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> > > Apache
> > > > > KIE
> > > > > > > 10,
> > > > > > > > > and
> > > > > > > > > > > > that
> > > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only
> problems
> > > left
> > > > > > to
> > > > > > > > > > discuss
> > > > > > > > > > > > are
> > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > P2, which can't be done without a
> proper
> > > > > > proposal.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I'll try to be very meticulous here,
> since
> > > > > from
> > > > > > my
> > > > > > > > > > > > experience,
> > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> > > release
> > > > > > not
> > > > > > > > > > working
> > > > > > > > > > > > out
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > > > possible,
> > > > > > > and
> > > > > > > > > make
> > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > > > release,
> > > > > > > bear
> > > > > > > > > > with
> > > > > > > > > > > > me.
> > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > > >> > > > out a timeline of events that need to
> > > happen
> > > > > in
> > > > > > > > order
> > > > > > > > > > for
> > > > > > > > > > > > our
> > > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > > >> > > > to be published, with all artifacts
> > > ending up
> > > > > in
> > > > > > > the
> > > > > > > > > > right
> > > > > > > > > > > > > > places,
> > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > >> > > > first, we need to solve problems P1
> and
> > > P2.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As you saw at the beginning of this
> > > email, all
> > > > > > the
> > > > > > > > > > > attempts
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > made
> > > > > > > > > > > > > > > >> > > > left us with the circular dependency
> > > showing
> > > > > up
> > > > > > > at a
> > > > > > > > > > > > different
> > > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > > >> > > > but something all these places have in
> > > common
> > > > > is
> > > > > > > > that
> > > > > > > > > > > > they're
> > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > >> > > > after kogito-apps, and before to
> Category
> > > B.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > > > following:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > S1. We keep the original plan of
> moving
> > > the
> > > > > > > Quarkus
> > > > > > > > > Dev
> > > > > > > > > > > UIs
> > > > > > > > > > > > > from
> > > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> > > with
> > > > > > > > Management
> > > > > > > > > > and
> > > > > > > > > > > > > Task
> > > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> > > `kie-tools`.
> > > > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode`
> and
> > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools`
> too.
> > > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > > `kogito-serverless-operator`
> > > > > > > > > repo
> > > > > > > > > > > > > inside
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> > > history.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together
> solve
> > > > > problems
> > > > > > > P1
> > > > > > > > > and
> > > > > > > > > > > P2.
> > > > > > > > > > > > Of
> > > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > > >>
> > > > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This doesn't come without
> consequences, of
> > > > > > course,
> > > > > > > > as
> > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > > `kogito-swf-builder`
> > > > > > > > images,
> > > > > > > > > > and
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be
> > > moving
> > > > > > from
> > > > > > > > > > > Category A
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > Category B. This move would make them
> > > have to
> > > > > > > > > reference
> > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs.
> Since
> > > > > > > > > > `kogito-images`
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are
> already
> > > their
> > > > > > own
> > > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > > >> > > > Category A, though, contributions
> made in
> > > a
> > > > > > > > cross-repo
> > > > > > > > > > > > fashion
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> > > possible, now
> > > > > > > via a
> > > > > > > > > > > single
> > > > > > > > > > > > PR
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> > > Category A
> > > > > > and
> > > > > > > > > > > Category
> > > > > > > > > > > > B
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > >> > > > continue not being possible, and a
> 1-week
> > > > > delay
> > > > > > > > > between
> > > > > > > > > > > > > merging
> > > > > > > > > > > > > > > >> > > > something on Category A and using it
> on
> > > > > > Category B
> > > > > > > > > will
> > > > > > > > > > > > still
> > > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > It's worth mentioning that
> `kie-tools`,
> > > > > however,
> > > > > > > > does
> > > > > > > > > > > allow
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > > >> > > > checkouts and partial builds, so
> working
> > > with
> > > > > a
> > > > > > > > subset
> > > > > > > > > > of
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > >> > > > is possible and encouraged. Making
> changes
> > > > > only
> > > > > > to
> > > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> > > example,
> > > > > will
> > > > > > > > have
> > > > > > > > > > the
> > > > > > > > > > > PR
> > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see
> here:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > >> > > > We're not compromising when running
> > > partial
> > > > > > builds
> > > > > > > > > too.
> > > > > > > > > > We
> > > > > > > > > > > > > know
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> > > > the entire repo will continue working
> even
> > > > > after
> > > > > > > > only
> > > > > > > > > > > > > building a
> > > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > > >> > > > subset of the changes. Doing partial
> or
> > > full
> > > > > > > builds
> > > > > > > > is
> > > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> > > proposing
> > > > > we
> > > > > > > > move a
> > > > > > > > > > > bunch
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I
> see
> > > this
> > > > > > as a
> > > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would
> host
> > > some
> > > > > > > > > additional
> > > > > > > > > > > > stuff
> > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > > > continue
> > > > > > > > moving
> > > > > > > > > > > > > forward.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As I mentioned on other places,
> > > `kie-tools`
> > > > > > > became a
> > > > > > > > > > > > polyglot
> > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > >> > > > out of necessity, and although I'm
> really
> > > > > proud
> > > > > > of
> > > > > > > > > what
> > > > > > > > > > we
> > > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > > >> > > > there so far, I don't think
> `kie-tools`
> > > has a
> > > > > > > setup
> > > > > > > > > that
> > > > > > > > > > > is
> > > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > > >> > > > for all the different nuances that
> > > compose our
> > > > > > > > > > community.
> > > > > > > > > > > > I'm
> > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that
> does
> > > not
> > > > > > > follow
> > > > > > > > > > > > widespread
> > > > > > > > > > > > > > > >> > > > conventions will scare some people
> away,
> > > and
> > > > > as
> > > > > > > much
> > > > > > > > > as
> > > > > > > > > > > > we've
> > > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > >> > > > make build instructions clear, we
> can't
> > > always
> > > > > > get
> > > > > > > > > past
> > > > > > > > > > > the
> > > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > > >> > > > some people have towards the
> "front-end"
> > > > > > > ecosystem.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > With all that said, I keep thinking
> this
> > > is
> > > > > the
> > > > > > > best
> > > > > > > > > > > course
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > > >> > > > for us right now. We keep most of our
> > > stuff
> > > > > > > > unchanged,
> > > > > > > > > > we
> > > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > release, and we have a working setup
> that
> > > will
> > > > > > > suit
> > > > > > > > us
> > > > > > > > > > > well
> > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > discuss and reach a conclusion
> regarding
> > > the
> > > > > > > future
> > > > > > > > of
> > > > > > > > > > our
> > > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Let me paint a quick picture here of
> what
> > > our
> > > > > > code
> > > > > > > > > base
> > > > > > > > > > > > would
> > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal
> is
> > > > > > accepted:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > > > >> > > > A
> > > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > B
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > D
> incubator-kie-kogito-operator
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > > > >> > > > E
> incubator-kie-kogito-website
> > > > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > > > >> > > > E
> incubator-kie-kogito-online
> > > > > > > > > > > > > > > >> > > > E
> > > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * Category C becomes part of Category
> A,
> > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> > > entirely
> > > > > > inside
> > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> > > images
> > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > > > `kie-tools`,
> > > > > > > > there
> > > > > > > > > > are
> > > > > > > > > > > > no
> > > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > > > > granularly
> > > > > > > > > build:
> > > > > > > > > > > > > > > >> > > > 1.
> > > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > >> > > > 2.
> packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> > > (containing
> > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> > > (contents
> > > > > > from
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The second part of the proposal is the
> > > release
> > > > > > > > process
> > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > >> > > > assuming the structure above is what
> we
> > > have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be
> > > used as
> > > > > > > > cutting
> > > > > > > > > > > point
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to
> > > this
> > > > > > > > > timestamped
> > > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > > > >> > > > 3. At this point, with everything
> > > working, we
> > > > > > can
> > > > > > > > > branch
> > > > > > > > > > > out
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the
> timestamped
> > > > > > SNAPSHOT
> > > > > > > > > tag,
> > > > > > > > > > > and
> > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> > > update
> > > > > > > their
> > > > > > > > > > > versions
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > > > Category
> > > > > > A
> > > > > > > > > repos
> > > > > > > > > > > > using
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the
> > > release
> > > > > > based
> > > > > > > > on
> > > > > > > > > > the
> > > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > > >> > > > branches, given we don't expect any
> code
> > > > > changes
> > > > > > > > > > anymore.
> > > > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to
> > > start
> > > > > the
> > > > > > > > > release
> > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > > > manual/automated
> > > > > > > > > > release
> > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > > pushed
> > > > > to
> > > > > > > Git,
> > > > > > > > > and
> > > > > > > > > > > > built
> > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > > > artifacts
> > > > > > > to
> > > > > > > > be
> > > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > > > manual/automated
> > > > > > > > > > release
> > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > > pushed
> > > > > to
> > > > > > > Git,
> > > > > > > > > and
> > > > > > > > > > > > built
> > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > > > >> > > > 12. Category E repos can be manually
> > > tagged
> > > > > with
> > > > > > > > > 10.0.0
> > > > > > > > > > > from
> > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > More needs to be discussed if we're
> > > planning
> > > > > to
> > > > > > > > > maintain
> > > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > > >> > > > release streams in parallel, but I
> guess
> > > it
> > > > > can
> > > > > > > wait
> > > > > > > > > for
> > > > > > > > > > > > after
> > > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> > > forward
> > > > > > to
> > > > > > > > > > hearing
> > > > > > > > > > > > back
> > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Of course, alternative solutions are
> > > possible.
> > > > > > > This
> > > > > > > > > > email,
> > > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > > >> > > > summarizes my view of how we should
> > > attack the
> > > > > > > > > problem,
> > > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > > >> > > > disruption, required effort, the
> release
> > > > > process
> > > > > > > > > itself,
> > > > > > > > > > > and
> > > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > > >> > > > Feel free to propose alternatives.
> This is
> > > > > not a
> > > > > > > > > voting
> > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <al...@porcelli.me>.
The guestimate of the plan discussed in this thread is around 2-3 weeks.
On Wed, Mar 13, 2024 at 9:47 AM Francisco Javier Tirado Sarti
<ft...@redhat.com> wrote:
>
> Ok, thanks Alex for the clarification.
> So two months for changing the order of repos, that sounds realistic, based
> on precedent, to me.
> Which is the estimation for the changes to be done in tools repo once all
> operator stuff is there?
> What I'm trying to find out now is if the proposed solution really takes
> less time. At the end both solutions imply moving stuff around between
> repos and changing CI, that's why I'm so insistent in pursuing the one that
> makes more sense from a SW dependency point of view: one that does not make
> "tooling" to be the final repo being processed.
>
> On Wed, Mar 13, 2024 at 2:33 PM Alex Porcelli <al...@porcelli.me> wrote:
>
> > Francisco,
> >
> > As I wrote earlier, I had a conversation with Jan - that is our
> > community CI expert - and he said that he guesses that it would take
> > about 2 months to make CI changes implied in your comments.
> >
> > He also mentioned that if Tristan was around and could dedicate his
> > time on this, he believes that Tristan could make the same changes
> > potentially in about 2 weeks.
> >
> >
> > On Wed, Mar 13, 2024 at 9:26 AM Francisco Javier Tirado Sarti
> > <ft...@redhat.com> wrote:
> > >
> > > @Ricardo Zanini <za...@redhat.com> The main issue I have is why we
> > > conclude 1 takes less time than 2?. If I understood 1) completely, it
> > also
> > > requires CI adjustments (at tools repo level, not at overall stream
> > level),
> > > so I hardly see the estimation different for someone that is familiar
> > with
> > > CI.
> > >
> > > On Wed, Mar 13, 2024 at 2:14 PM ricardo zanini fernandes <
> > > ricardozanini@gmail.com> wrote:
> > >
> > > > Hi!
> > > >
> > > > Clearly, you all understand that moving images and the operator to
> > > > kie-tools is a workaround and wrong in all possible scenarios, right?
> > We
> > > > won't undo once we merge. I'm pretty positive that once we have a
> > release
> > > > train going people will add all the obstacles they can add saying "It's
> > > > working, let's not change it".
> > > >
> > > > Also, I understand that we need to unblock the release. We can
> > compromise
> > > > in COPYING the code, do the release, and then make the necessary
> > changes.
> > > > Images and cloud code are *integration platforms*. Should be the last
> > in a
> > > > stream. Tooling SHOULD NOT, in any case, depend on the images to build.
> > > >
> > > > So we can:
> > > >
> > > > 1. Accept Tiago's proposal (very well detailed, thanks!) but COPYING
> > the
> > > > code base, not MERGING. The contributions still flow to the right
> > repos.
> > > > 2. After release we:
> > > > 1. Move the CLI to the operator repo, removing this dependency from
> > > > tools to image
> > > > 2. Adjust the CI
> > > > 3. Remove the copied code
> > > >
> > > > Moving forward, I'd like to see a clear boundary between the projects
> > (as
> > > > stated in the temporary website). At the moment, we do not have. And
> > it's
> > > > hard for anyone from outside to understand what we are doing.
> > > >
> > > > On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me>
> > wrote:
> > > >
> > > > > Francisco and Gabriele,
> > > > >
> > > > > I understand and acknowledge your desire to find the “right” solution
> > > > > instead to work on a temporary “patch” - however without a detailed
> > > > > proposal I don’t think we can properly evaluate the impact of your
> > > > > suggestion.
> > > > >
> > > > > When I spoke with different SMEs that included tools and CI, the
> > > > > guesstimate for making the necessary changes on CI and codebase to
> > > > > basically have images and operators in the end of the build chain is
> > > > > something like 2 months of effort. Another impact that needs to be
> > > > > discussed is that KIE Tools repo had to be injected in the middle of
> > all
> > > > > pipelines - forcing all PR checks and nightlies to build all repos
> > (PR
> > > > > checks will likely take 12+ hours… I even heard that it could be
> > even 24
> > > > > hours).
> > > > >
> > > > > Based on the input above, I think it’s quite risk to move in such
> > > > direction
> > > > > without a more detailed plan… because 2 months could be turned
> > easily in
> > > > 6!
> > > > > And this is exactly what happened when we guessed that moving to
> > Apache
> > > > > would take no more than 3 months. But here we are.
> > > > >
> > > > > I really strongly suggest that we focus on a release that could be
> > > > > achievable in less than a month from now, and we - after release -
> > have a
> > > > > in depth discussion about the overall codebase and ci organization.
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > gabriele.cardosi@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Alex,
> > > > > > my suggestion is to move the building of all docker images, from
> > > > whatever
> > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to
> > be
> > > > > > invoked after all the others.
> > > > > > I'm not sure if this would solve all the issues, and since I could
> > not
> > > > > > enter in the details of all the involved code, my suggestion may
> > be too
> > > > > > naive.
> > > > > > Having spent almost all of the last year in CI, I may say that, at
> > > > least
> > > > > > for the kie-tools repo, removing the image build step from it
> > should
> > > > not
> > > > > be
> > > > > > too difficult (since it is an issue we already faced and solved).
> > > > > > If, with "detailed proposal", you mean a complete list of all
> > modules
> > > > to
> > > > > be
> > > > > > moved and dependency refactoring, of course I can not provide it
> > right
> > > > > now.
> > > > > >
> > > > > > Anyway, I share the concern from Francisco: undoing something is
> > almost
> > > > > > always harder than doing it "rightly" from scratch...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado
> > Sarti
> > > > <
> > > > > > ftirados@redhat.com> ha scritto:
> > > > > >
> > > > > > > I do not think estimations should be the only driver to make a
> > > > > decision,
> > > > > > > especially when the current proposal is conceptually incompatible
> > > > with
> > > > > > the
> > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > Given my knowledge of the CI it is nearly impossible for me to
> > give
> > > > a
> > > > > > fair
> > > > > > > estimate of how much it might take to achieve step 2) of my
> > previous
> > > > > > e-mail
> > > > > > > . It might take a while or it might be pretty easy after all, I
> > don't
> > > > > > > really know, but I think it will be a good idea if some of the
> > > > experts
> > > > > > on
> > > > > > > CI in the team (the ones that set up the pipeline, which was a
> > huge
> > > > > > > achievement) give an estimate, not me. Estimating how much it
> > takes
> > > > to
> > > > > > > merge two existing repos (without altering CI) is easier, but it
> > does
> > > > > not
> > > > > > > mean we are doing the right thing.
> > > > > > > My main concern is that it will be very difficult for me to
> > explain
> > > > to
> > > > > > > someone that arrives new to the team, that having experts on CI
> > on
> > > > the
> > > > > > > team, we decided to merge two repos (once merged, it would be
> > rather
> > > > > > > difficult to unmerge) rather than fix the CI, because of
> > expediency.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > porcelli@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Francisco,
> > > > > > > >
> > > > > > > > Please take the time to make the more in depth analysis needed
> > and
> > > > > > > provide
> > > > > > > > a more detailed plan… so we - as community- can evaluate the
> > size
> > > > of
> > > > > > the
> > > > > > > > effort. In the conceptual level you shared it’s near
> > impossible to
> > > > > > > estimate
> > > > > > > > the size of the effort and compare with the current proposal.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > >
> > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > 1) Remove all dependencies from tooling to images, so images
> > > > > depend
> > > > > > on
> > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > 2) Then change CI to deal with tooling repo before dealing
> > with
> > > > > > images
> > > > > > > > > repo.
> > > > > > > > > I understand that CI details are tricky and since I'm not
> > > > familiar
> > > > > > with
> > > > > > > > CI
> > > > > > > > > in any way, I barely can make a low level design, but we do
> > not
> > > > > need
> > > > > > to
> > > > > > > > fix
> > > > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > alex@porcelli.me
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > >
> > > > > > > > > > You may not like or understand why the current state of
> > the CI
> > > > is
> > > > > > > like
> > > > > > > > > > that… actually has been in Red Hat and has been replicated
> > in
> > > > > > Apache
> > > > > > > as
> > > > > > > > > > used to be….
> > > > > > > > > >
> > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > >
> > > > > > > > > > If you disagree with the current plan, please provide a
> > > > detailed
> > > > > > > > > > alternative so we, as community, can better evaluate the
> > pros
> > > > and
> > > > > > > cons
> > > > > > > > of
> > > > > > > > > > each proposal.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I think it’s also fair to say that, post 10 release we
> > need to
> > > > > > have a
> > > > > > > > > much
> > > > > > > > > > in depth discussion about how our codebase is organized,
> > it’s
> > > > > clear
> > > > > > > > that
> > > > > > > > > > it’s not working.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > As Francisco said,
> > > > > > > > > > > I also have the impression that the "images" (if we are
> > > > talking
> > > > > > of
> > > > > > > > > docker
> > > > > > > > > > > images) should be the very last one to be built, in a
> > > > > standalone
> > > > > > > > repo.
> > > > > > > > > > > That way, they may "combine" artifacts that are built in
> > > > > > different
> > > > > > > > > repos,
> > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> > > > maybe
> > > > > > > could
> > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > (I also think there are some statements of undisputable
> > needs
> > > > > > while
> > > > > > > > > they
> > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > > discussion.)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > > > > Tirado
> > > > > > > > Sarti
> > > > > > > > > <
> > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > >
> > > > > > > > > > > > Alex,
> > > > > > > > > > > > There are two assumptions that deserve further
> > discussion:
> > > > > > > > > > > > 1) That tool has to be the last to build. why? it does
> > not
> > > > > have
> > > > > > > > more
> > > > > > > > > > > sense
> > > > > > > > > > > > to build final images after everything else has been
> > > > built?-
> > > > > > > > > > > > 2) That the impact (in terms of effort now) on fixing
> > CI is
> > > > > > > bigger
> > > > > > > > > than
> > > > > > > > > > > the
> > > > > > > > > > > > impact (long term consequences) of consolidating two
> > > > > unrelated
> > > > > > > > piece
> > > > > > > > > of
> > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > alex@porcelli.me
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > >
> > > > > > > > > > > > > This was discussed as an alternative solution,
> > however it
> > > > > has
> > > > > > > > major
> > > > > > > > > > > > impact
> > > > > > > > > > > > > on CI and there’s also the fact Tool has been always
> > the
> > > > > last
> > > > > > > to
> > > > > > > > > > build
> > > > > > > > > > > > and
> > > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> > world
> > > > > there
> > > > > > > is
> > > > > > > > no
> > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > >
> > > > > > > > > > > > > So, based on our evaluation… the proposal here is the
> > > > least
> > > > > > > > > > disruptive
> > > > > > > > > > > > and
> > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > _____________
> > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> > Tirado
> > > > > > Sarti <
> > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > embracing
> > > > the
> > > > > > fact
> > > > > > > > > that
> > > > > > > > > > > > > > kogito-images depend on kie-tools, because we want
> > > > those
> > > > > > > images
> > > > > > > > > to
> > > > > > > > > > > > > include
> > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > > > Tirado
> > > > > > > Sarti
> > > > > > > > <
> > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > kn-plugin-workflow
> > > > > > > > to
> > > > > > > > > > > > > > > kogito-images (so there is not longer dependency
> > from
> > > > > > tools
> > > > > > > > to
> > > > > > > > > > > > images)
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > > > > Martinez
> > > > > > > <
> > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > (apache)
> > > > <
> > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > > > > alex@porcelli.me
> > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > I spent the last day or so working closely
> > with
> > > > > > Tiago,
> > > > > > > > > > > exploring
> > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > > > > evaluating
> > > > > > > > > the
> > > > > > > > > > > > > overall
> > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > > > proposal
> > > > > > as
> > > > > > > > the
> > > > > > > > > > > most
> > > > > > > > > > > > > > >> > > viable option for unblocking the 10 release
> > in
> > > > the
> > > > > > > > > > reasonable
> > > > > > > > > > > > time
> > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento
> > <
> > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> > time,
> > > > as
> > > > > > this
> > > > > > > > > > matter
> > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes to
> > read,
> > > > > > > > according
> > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > thread
> > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > >
> > > > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > >> > > > many of us were working towards removing a
> > > > > > circular
> > > > > > > > > > > dependency
> > > > > > > > > > > > > > >> > > > currently present between `kogito-apps`
> > and
> > > > > > > > `kie-tools`.
> > > > > > > > > > As
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > finding
> > > > > the
> > > > > > > > > > circular
> > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > breakdown of
> > > > > the
> > > > > > > > things
> > > > > > > > > > we
> > > > > > > > > > > > did,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Right now, even though we started the
> > effort
> > > > to
> > > > > > move
> > > > > > > > the
> > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> > > > able
> > > > > to
> > > > > > > do
> > > > > > > > it
> > > > > > > > > > > yet,
> > > > > > > > > > > > as
> > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> > > > Maven
> > > > > > > 3.9.6,
> > > > > > > > > and
> > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > This
> > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > > >> > > >
> > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > .
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > C | 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > Y | 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > depend
> > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > > `kie-tools`,
> > > > > > we
> > > > > > > > > > would've
> > > > > > > > > > > > > had:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > C |==> 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/kn-plugin-workflow
> > > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > >> > > > * and
> > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > depends
> > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> > image to
> > > > > > > > > > `kie-tools`,
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/kn-plugin-workflow
> > > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> > than a
> > > > > > simple
> > > > > > > > > > > circular
> > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > > > > people,
> > > > > > > > it's
> > > > > > > > > > been
> > > > > > > > > > > > > > really
> > > > > > > > > > > > > > >> > > > hard coming up with a simple solution that
> > > > makes
> > > > > > it
> > > > > > > > > > possible
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving
> > the
> > > > way
> > > > > > > > > everyone
> > > > > > > > > > is
> > > > > > > > > > > > > used
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > contributing to the multiple repositories
> > we
> > > > > have.
> > > > > > > > More
> > > > > > > > > > than
> > > > > > > > > > > > > that,
> > > > > > > > > > > > > > >> > > > while making this assessment, I found more
> > > > > > problems
> > > > > > > > > that,
> > > > > > > > > > in
> > > > > > > > > > > > my
> > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > > > forward
> > > > > > with
> > > > > > > > my
> > > > > > > > > > > > proposal
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we can
> > use
> > > > > > > Apache's
> > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> > > > this
> > > > > > > really
> > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective about
> > the
> > > > > > current
> > > > > > > > > > > situation
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > currently
> > > > > see.
> > > > > > > > I'll
> > > > > > > > > > > start
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > > purposes,
> > > > > > > point
> > > > > > > > > out
> > > > > > > > > > > > some
> > > > > > > > > > > > > > >> > > > problems that I believe are blocking our
> > 10
> > > > > > release,
> > > > > > > > > > explain
> > > > > > > > > > > > my
> > > > > > > > > > > > > > >> > > > proposal and discuss some consequences to
> > what
> > > > > I'm
> > > > > > > > > > > proposing.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count:
> > 11)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> > > > `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-serverless-operator @
> > > > > > `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > >> > > > -
> > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > `0.0.0`
> > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > updated @
> > > > > > `main`.
> > > > > > > > > Same
> > > > > > > > > > > for
> > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy
> > at
> > > > the
> > > > > > > > `main`
> > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`.
> > Push @
> > > > > > > > `deploy`
> > > > > > > > > to
> > > > > > > > > > > > > update
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > sandbox.kie.org
> > > > > > and
> > > > > > > > KIE
> > > > > > > > > > > Tools'
> > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @
> > `main`
> > > > > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> > > > checks
> > > > > > > > during
> > > > > > > > > > the
> > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I grouped the repositories by category,
> > and
> > > > > listed
> > > > > > > > them
> > > > > > > > > > in a
> > > > > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > > > > flattening
> > > > > > > > > out a
> > > > > > > > > > > > tree,
> > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > > > OptaPlanner
> > > > > > > > > > > could've
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > referring
> > > > to
> > > > > > as
> > > > > > > > > > `drools`
> > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner
> > is
> > > > > inside
> > > > > > > > that
> > > > > > > > > > > > stream,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > way these repositories reference each
> > other
> > > > are
> > > > > > > > through
> > > > > > > > > > > Maven
> > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > 999-SNAPSHOT
> > > > > > > > version.
> > > > > > > > > > This
> > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > >> > > > is well-known to the team, and although
> > flawed
> > > > > for
> > > > > > > > > > intra-day
> > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > different
> > > > time
> > > > > > > > zones,
> > > > > > > > > it
> > > > > > > > > > > is
> > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> > with, I
> > > > > > > assume.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > > > > dedicated
> > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> > build
> > > > > > > cross-repo
> > > > > > > > > PRs
> > > > > > > > > > > > > > together
> > > > > > > > > > > > > > >> > > > and verify that the codebase will continue
> > > > > working
> > > > > > > as
> > > > > > > > > > > expected
> > > > > > > > > > > > > > after
> > > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > gather,
> > > > > > there
> > > > > > > > are
> > > > > > > > > > some
> > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > > cross-repo
> > > > > > > PRs.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps,
> > and
> > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to
> > any
> > > > > > > > > combination
> > > > > > > > > > of
> > > > > > > > > > > > > repos
> > > > > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > > > > cannot
> > > > > > be
> > > > > > > > > > > verified
> > > > > > > > > > > > > > before
> > > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > > dependent
> > > > > > on
> > > > > > > > > > > individual
> > > > > > > > > > > > > > >> > > > contributors building stuff on their
> > machines
> > > > to
> > > > > > > > verify
> > > > > > > > > > that
> > > > > > > > > > > > it
> > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > > > > pipelines,
> > > > > > > > so
> > > > > > > > > > > > please
> > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > referring
> > > > to
> > > > > > as
> > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > > > > repository
> > > > > > > > > that
> > > > > > > > > > > is
> > > > > > > > > > > > > used
> > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > >> > > > people starting projects from scratch on
> > KIE
> > > > > > > Sandbox,
> > > > > > > > > > > similar
> > > > > > > > > > > > > to a
> > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The other
> > one is
> > > > > the
> > > > > > > KIE
> > > > > > > > > > Tools
> > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> > build
> > > > > > system.
> > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > > TypeScript
> > > > > > > > > libraries
> > > > > > > > > > > and
> > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > > > > `kie-tools`
> > > > > > > > > > > monorepo
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > >> > > > configured to work with sparse checkouts
> > and
> > > > can
> > > > > > do
> > > > > > > > > > partial
> > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > > > > through
> > > > > > > > > > > timestamped
> > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > recently
> > > > > > > > > introduced
> > > > > > > > > > > that
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > > > artifacts
> > > > > > > > under
> > > > > > > > > a
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> > format,
> > > > > > > published
> > > > > > > > > > weekly
> > > > > > > > > > > > > every
> > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > > > > evolution
> > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > release
> > > > for
> > > > > > all
> > > > > > > > of
> > > > > > > > > > > Apache
> > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > An important note here is that Category B
> > > > > > > repositories
> > > > > > > > > > have
> > > > > > > > > > > > been
> > > > > > > > > > > > > > >> > > > historically kept out of any automations
> > we
> > > > used
> > > > > > to
> > > > > > > > > have,
> > > > > > > > > > > way
> > > > > > > > > > > > > back
> > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > Business
> > > > > > Central
> > > > > > > > > > (a.k.a.
> > > > > > > > > > > > v7)
> > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > >> > > > still going on. For this reason, Category
> > B
> > > > > > projects
> > > > > > > > > have
> > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > > Actions.
> > > > > > > > > Category B
> > > > > > > > > > > > repos
> > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > >> > > > always depended on Category A repos using
> > > > fixed
> > > > > > > > > versions.
> > > > > > > > > > If
> > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > SNAPSHOTs,
> > > > > > breaking
> > > > > > > > > > changes
> > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > > > potential
> > > > > > > to
> > > > > > > > > > break
> > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > > > > development
> > > > > > > > > > > stream,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > > maintainers
> > > > > > of
> > > > > > > > > > > Category B
> > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > >> > > > as historically Category A contributors
> > were
> > > > not
> > > > > > > > > familiar
> > > > > > > > > > > with
> > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > > > > through
> > > > > > a
> > > > > > > > > GitHub
> > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > >> > > > workflow that builds the relevant part of
> > the
> > > > > > > > > `kie-tools`
> > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > >> > > > the changes introduced. Changes made to
> > the
> > > > > > pipeline
> > > > > > > > > > itself
> > > > > > > > > > > > are
> > > > > > > > > > > > > > also
> > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to
> > do
> > > > > things
> > > > > > > > like
> > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > >> > > > bumping the Node.js version, for example.
> > More
> > > > > > > > > > importantly,
> > > > > > > > > > > it
> > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > > timestamped
> > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > together
> > > > > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > > > > green.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This setup, however, makes it impossible
> > to
> > > > have
> > > > > > > > > > cross-repo
> > > > > > > > > > > > PRs
> > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > simultaneously,
> > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > > > > > current
> > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > around,
> > > > > and
> > > > > > > I'm
> > > > > > > > > not
> > > > > > > > > > > sure
> > > > > > > > > > > > > if
> > > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > > Regardless,
> > > > > > as
> > > > > > > > > > they're
> > > > > > > > > > > > > part
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > release,
> > > > > so I
> > > > > > > > > listed
> > > > > > > > > > > them
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category D is self explanatory. There's
> > only
> > > > one
> > > > > > > repo
> > > > > > > > > that
> > > > > > > > > > > has
> > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > > > > directly,
> > > > > > > > and
> > > > > > > > > > are
> > > > > > > > > > > > > > either
> > > > > > > > > > > > > > >> > > > organizational entities, or host websites,
> > > > that
> > > > > > > > > currently
> > > > > > > > > > > are
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This lack of unification between Category
> > A
> > > > and
> > > > > > > > > Category B
> > > > > > > > > > > is,
> > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > > > > circular
> > > > > > > > > > > dependency
> > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we
> > now
> > > > can
> > > > > > > > describe
> > > > > > > > > > as
> > > > > > > > > > > a
> > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > >> > > > dependency between Category A and
> > Category B.
> > > > > The
> > > > > > > way
> > > > > > > > I
> > > > > > > > > > see
> > > > > > > > > > > > it,
> > > > > > > > > > > > > if
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > had a single pipeline, building everything
> > > > from
> > > > > > > > `drools`
> > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> > been
> > > > > > > > introduced,
> > > > > > > > > > and
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem in
> > our
> > > > > hands
> > > > > > > > right
> > > > > > > > > > now.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > process
> > > > > > sees
> > > > > > > > this
> > > > > > > > > > > lack
> > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > unification as a central problem, not
> > only for
> > > > > > this
> > > > > > > > > > release
> > > > > > > > > > > in
> > > > > > > > > > > > > > >> > > > particular, but for the community as a
> > whole.
> > > > It
> > > > > > is
> > > > > > > my
> > > > > > > > > > > belief
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > > > contribution
> > > > > > > > > > should
> > > > > > > > > > > > be
> > > > > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> > > > With
> > > > > > the
> > > > > > > > > > > increasing
> > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > contributors
> > > > > too,
> > > > > > > we
> > > > > > > > > > cannot
> > > > > > > > > > > > > keep
> > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> > breaking
> > > > > > things.
> > > > > > > > > We're
> > > > > > > > > > > all
> > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > > mechanisms
> > > > > in
> > > > > > > > place
> > > > > > > > > > to
> > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> > Especially
> > > > > when
> > > > > > > > these
> > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > > > individually,
> > > > > > > > > > > > probably
> > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > depending
> > > > on
> > > > > > > > > > kiegroup's
> > > > > > > > > > > > KIE
> > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > > `kogito-images`
> > > > > > > > > > > depending
> > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > > > > kiegroup's
> > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > `7.59.0.Final`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > > depending
> > > > > on
> > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > > codebase
> > > > > > > here:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >
> > > > > > > > >
> > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > ,
> > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > > OptaPlanner,
> > > > > > > > > > pointing
> > > > > > > > > > > to
> > > > > > > > > > > > > > older
> > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P5.
> > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > depending
> > > > > > > > > > on
> > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P6. Category C repos are out of date and
> > not
> > > > > part
> > > > > > of
> > > > > > > > the
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > > A
> > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> > (Current
> > > > > > version
> > > > > > > is
> > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > > version,
> > > > > > only
> > > > > > > > by
> > > > > > > > > > > using
> > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> > version
> > > > is
> > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > > OptaPlanner
> > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P7.
> > `kie-tools`/packages/kn-plugin-workflow
> > > > has
> > > > > > its
> > > > > > > > E2E
> > > > > > > > > > > > disabled
> > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > > > > solution,
> > > > > > > > as
> > > > > > > > > > they
> > > > > > > > > > > > > both
> > > > > > > > > > > > > > >> > > > suffer from the circular dependency
> > between
> > > > > > > Category A
> > > > > > > > > and
> > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > >> > > > As Category A and Category B are both
> > streams
> > > > > that
> > > > > > > > have
> > > > > > > > > > been
> > > > > > > > > > > > > > really
> > > > > > > > > > > > > > >> > > > active, I see this as a blocker, as there
> > are
> > > > > > > > > > contributions
> > > > > > > > > > > > that
> > > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> > depends
> > > > on
> > > > > > > > > Category
> > > > > > > > > > B
> > > > > > > > > > > > > with a
> > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > > understood
> > > > > > as
> > > > > > > > > > > technical
> > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > > something
> > > > > > > we'll
> > > > > > > > > > always
> > > > > > > > > > > > be
> > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> > just a
> > > > > > matter
> > > > > > > of
> > > > > > > > > > > making
> > > > > > > > > > > > > them
> > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> > impact
> > > > the
> > > > > > > > > structure
> > > > > > > > > > or
> > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > > > > regression
> > > > > > > > we
> > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> > Apache
> > > > KIE
> > > > > > 10,
> > > > > > > > and
> > > > > > > > > > > that
> > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems
> > left
> > > > > to
> > > > > > > > > discuss
> > > > > > > > > > > are
> > > > > > > > > > > > P1
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > > > > proposal.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> > > > from
> > > > > my
> > > > > > > > > > > experience,
> > > > > > > > > > > > > any
> > > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> > release
> > > > > not
> > > > > > > > > working
> > > > > > > > > > > out
> > > > > > > > > > > > in
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > > possible,
> > > > > > and
> > > > > > > > make
> > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > > release,
> > > > > > bear
> > > > > > > > > with
> > > > > > > > > > > me.
> > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > >> > > > out a timeline of events that need to
> > happen
> > > > in
> > > > > > > order
> > > > > > > > > for
> > > > > > > > > > > our
> > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > >> > > > to be published, with all artifacts
> > ending up
> > > > in
> > > > > > the
> > > > > > > > > right
> > > > > > > > > > > > > places,
> > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > >> > > > first, we need to solve problems P1 and
> > P2.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As you saw at the beginning of this
> > email, all
> > > > > the
> > > > > > > > > > attempts
> > > > > > > > > > > we
> > > > > > > > > > > > > > made
> > > > > > > > > > > > > > >> > > > left us with the circular dependency
> > showing
> > > > up
> > > > > > at a
> > > > > > > > > > > different
> > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > >> > > > but something all these places have in
> > common
> > > > is
> > > > > > > that
> > > > > > > > > > > they're
> > > > > > > > > > > > > all
> > > > > > > > > > > > > > >> > > > after kogito-apps, and before to Category
> > B.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > > following:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > S1. We keep the original plan of moving
> > the
> > > > > > Quarkus
> > > > > > > > Dev
> > > > > > > > > > UIs
> > > > > > > > > > > > from
> > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> > with
> > > > > > > Management
> > > > > > > > > and
> > > > > > > > > > > > Task
> > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> > `kie-tools`.
> > > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > images
> > > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > `kogito-serverless-operator`
> > > > > > > > repo
> > > > > > > > > > > > inside
> > > > > > > > > > > > > a
> > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> > history.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> > > > problems
> > > > > > P1
> > > > > > > > and
> > > > > > > > > > P2.
> > > > > > > > > > > Of
> > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > >>
> > > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This doesn't come without consequences, of
> > > > > course,
> > > > > > > as
> > > > > > > > > the
> > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > `kogito-swf-builder`
> > > > > > > images,
> > > > > > > > > and
> > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be
> > moving
> > > > > from
> > > > > > > > > > Category A
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > Category B. This move would make them
> > have to
> > > > > > > > reference
> > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > > > > `kogito-images`
> > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are already
> > their
> > > > > own
> > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > >> > > > Category A, though, contributions made in
> > a
> > > > > > > cross-repo
> > > > > > > > > > > fashion
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> > possible, now
> > > > > > via a
> > > > > > > > > > single
> > > > > > > > > > > PR
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> > Category A
> > > > > and
> > > > > > > > > > Category
> > > > > > > > > > > B
> > > > > > > > > > > > > will
> > > > > > > > > > > > > > >> > > > continue not being possible, and a 1-week
> > > > delay
> > > > > > > > between
> > > > > > > > > > > > merging
> > > > > > > > > > > > > > >> > > > something on Category A and using it on
> > > > > Category B
> > > > > > > > will
> > > > > > > > > > > still
> > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> > > > however,
> > > > > > > does
> > > > > > > > > > allow
> > > > > > > > > > > > for
> > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > >> > > > checkouts and partial builds, so working
> > with
> > > > a
> > > > > > > subset
> > > > > > > > > of
> > > > > > > > > > > the
> > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > >> > > > is possible and encouraged. Making changes
> > > > only
> > > > > to
> > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> > example,
> > > > will
> > > > > > > have
> > > > > > > > > the
> > > > > > > > > > PR
> > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > >> > > > We're not compromising when running
> > partial
> > > > > builds
> > > > > > > > too.
> > > > > > > > > We
> > > > > > > > > > > > know
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > >> > > > the entire repo will continue working even
> > > > after
> > > > > > > only
> > > > > > > > > > > > building a
> > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > >> > > > subset of the changes. Doing partial or
> > full
> > > > > > builds
> > > > > > > is
> > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> > proposing
> > > > we
> > > > > > > move a
> > > > > > > > > > bunch
> > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see
> > this
> > > > > as a
> > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host
> > some
> > > > > > > > additional
> > > > > > > > > > > stuff
> > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > > continue
> > > > > > > moving
> > > > > > > > > > > > forward.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As I mentioned on other places,
> > `kie-tools`
> > > > > > became a
> > > > > > > > > > > polyglot
> > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > >> > > > out of necessity, and although I'm really
> > > > proud
> > > > > of
> > > > > > > > what
> > > > > > > > > we
> > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > >> > > > there so far, I don't think `kie-tools`
> > has a
> > > > > > setup
> > > > > > > > that
> > > > > > > > > > is
> > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > >> > > > for all the different nuances that
> > compose our
> > > > > > > > > community.
> > > > > > > > > > > I'm
> > > > > > > > > > > > > well
> > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that does
> > not
> > > > > > follow
> > > > > > > > > > > widespread
> > > > > > > > > > > > > > >> > > > conventions will scare some people away,
> > and
> > > > as
> > > > > > much
> > > > > > > > as
> > > > > > > > > > > we've
> > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > >> > > > make build instructions clear, we can't
> > always
> > > > > get
> > > > > > > > past
> > > > > > > > > > the
> > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > > > > ecosystem.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > With all that said, I keep thinking this
> > is
> > > > the
> > > > > > best
> > > > > > > > > > course
> > > > > > > > > > > of
> > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > >> > > > for us right now. We keep most of our
> > stuff
> > > > > > > unchanged,
> > > > > > > > > we
> > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > release, and we have a working setup that
> > will
> > > > > > suit
> > > > > > > us
> > > > > > > > > > well
> > > > > > > > > > > > > while
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > discuss and reach a conclusion regarding
> > the
> > > > > > future
> > > > > > > of
> > > > > > > > > our
> > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Let me paint a quick picture here of what
> > our
> > > > > code
> > > > > > > > base
> > > > > > > > > > > would
> > > > > > > > > > > > > look
> > > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > > > > accepted:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > B
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > > > > >> > > > E
> > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * Category C becomes part of Category A,
> > and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> > entirely
> > > > > inside
> > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> > images
> > > > and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > > `kie-tools`,
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > > no
> > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > > > granularly
> > > > > > > > build:
> > > > > > > > > > > > > > >> > > > 1.
> > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> > (containing
> > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> > (contents
> > > > > from
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The second part of the proposal is the
> > release
> > > > > > > process
> > > > > > > > > > > itself,
> > > > > > > > > > > > > > >> > > > assuming the structure above is what we
> > have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be
> > used as
> > > > > > > cutting
> > > > > > > > > > point
> > > > > > > > > > > > for
> > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to
> > this
> > > > > > > > timestamped
> > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > > >> > > > 3. At this point, with everything
> > working, we
> > > > > can
> > > > > > > > branch
> > > > > > > > > > out
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> > > > > SNAPSHOT
> > > > > > > > tag,
> > > > > > > > > > and
> > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> > update
> > > > > > their
> > > > > > > > > > versions
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > > Category
> > > > > A
> > > > > > > > repos
> > > > > > > > > > > using
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the
> > release
> > > > > based
> > > > > > > on
> > > > > > > > > the
> > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > >> > > > branches, given we don't expect any code
> > > > changes
> > > > > > > > > anymore.
> > > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to
> > start
> > > > the
> > > > > > > > release
> > > > > > > > > > > > process.
> > > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > > manual/automated
> > > > > > > > > release
> > > > > > > > > > > > > process,
> > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > pushed
> > > > to
> > > > > > Git,
> > > > > > > > and
> > > > > > > > > > > built
> > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > > artifacts
> > > > > > to
> > > > > > > be
> > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > > manual/automated
> > > > > > > > > release
> > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > pushed
> > > > to
> > > > > > Git,
> > > > > > > > and
> > > > > > > > > > > built
> > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > > >> > > > 12. Category E repos can be manually
> > tagged
> > > > with
> > > > > > > > 10.0.0
> > > > > > > > > > from
> > > > > > > > > > > > > their
> > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > More needs to be discussed if we're
> > planning
> > > > to
> > > > > > > > maintain
> > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > >> > > > release streams in parallel, but I guess
> > it
> > > > can
> > > > > > wait
> > > > > > > > for
> > > > > > > > > > > after
> > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> > forward
> > > > > to
> > > > > > > > > hearing
> > > > > > > > > > > back
> > > > > > > > > > > > > > from
> > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Of course, alternative solutions are
> > possible.
> > > > > > This
> > > > > > > > > email,
> > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > >> > > > summarizes my view of how we should
> > attack the
> > > > > > > > problem,
> > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > >> > > > disruption, required effort, the release
> > > > process
> > > > > > > > itself,
> > > > > > > > > > and
> > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > >> > > > Feel free to propose alternatives. This is
> > > > not a
> > > > > > > > voting
> > > > > > > > > > > > thread.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Ok, thanks Alex for the clarification.
So two months for changing the order of repos, that sounds realistic, based
on precedent, to me.
Which is the estimation for the changes to be done in tools repo once all
operator stuff is there?
What I'm trying to find out now is if the proposed solution really takes
less time. At the end both solutions imply moving stuff around between
repos and changing CI, that's why I'm so insistent in pursuing the one that
makes more sense from a SW dependency point of view: one that does not make
"tooling" to be the final repo being processed.
On Wed, Mar 13, 2024 at 2:33 PM Alex Porcelli <al...@porcelli.me> wrote:
> Francisco,
>
> As I wrote earlier, I had a conversation with Jan - that is our
> community CI expert - and he said that he guesses that it would take
> about 2 months to make CI changes implied in your comments.
>
> He also mentioned that if Tristan was around and could dedicate his
> time on this, he believes that Tristan could make the same changes
> potentially in about 2 weeks.
>
>
> On Wed, Mar 13, 2024 at 9:26 AM Francisco Javier Tirado Sarti
> <ft...@redhat.com> wrote:
> >
> > @Ricardo Zanini <za...@redhat.com> The main issue I have is why we
> > conclude 1 takes less time than 2?. If I understood 1) completely, it
> also
> > requires CI adjustments (at tools repo level, not at overall stream
> level),
> > so I hardly see the estimation different for someone that is familiar
> with
> > CI.
> >
> > On Wed, Mar 13, 2024 at 2:14 PM ricardo zanini fernandes <
> > ricardozanini@gmail.com> wrote:
> >
> > > Hi!
> > >
> > > Clearly, you all understand that moving images and the operator to
> > > kie-tools is a workaround and wrong in all possible scenarios, right?
> We
> > > won't undo once we merge. I'm pretty positive that once we have a
> release
> > > train going people will add all the obstacles they can add saying "It's
> > > working, let's not change it".
> > >
> > > Also, I understand that we need to unblock the release. We can
> compromise
> > > in COPYING the code, do the release, and then make the necessary
> changes.
> > > Images and cloud code are *integration platforms*. Should be the last
> in a
> > > stream. Tooling SHOULD NOT, in any case, depend on the images to build.
> > >
> > > So we can:
> > >
> > > 1. Accept Tiago's proposal (very well detailed, thanks!) but COPYING
> the
> > > code base, not MERGING. The contributions still flow to the right
> repos.
> > > 2. After release we:
> > > 1. Move the CLI to the operator repo, removing this dependency from
> > > tools to image
> > > 2. Adjust the CI
> > > 3. Remove the copied code
> > >
> > > Moving forward, I'd like to see a clear boundary between the projects
> (as
> > > stated in the temporary website). At the moment, we do not have. And
> it's
> > > hard for anyone from outside to understand what we are doing.
> > >
> > > On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me>
> wrote:
> > >
> > > > Francisco and Gabriele,
> > > >
> > > > I understand and acknowledge your desire to find the “right” solution
> > > > instead to work on a temporary “patch” - however without a detailed
> > > > proposal I don’t think we can properly evaluate the impact of your
> > > > suggestion.
> > > >
> > > > When I spoke with different SMEs that included tools and CI, the
> > > > guesstimate for making the necessary changes on CI and codebase to
> > > > basically have images and operators in the end of the build chain is
> > > > something like 2 months of effort. Another impact that needs to be
> > > > discussed is that KIE Tools repo had to be injected in the middle of
> all
> > > > pipelines - forcing all PR checks and nightlies to build all repos
> (PR
> > > > checks will likely take 12+ hours… I even heard that it could be
> even 24
> > > > hours).
> > > >
> > > > Based on the input above, I think it’s quite risk to move in such
> > > direction
> > > > without a more detailed plan… because 2 months could be turned
> easily in
> > > 6!
> > > > And this is exactly what happened when we guessed that moving to
> Apache
> > > > would take no more than 3 months. But here we are.
> > > >
> > > > I really strongly suggest that we focus on a release that could be
> > > > achievable in less than a month from now, and we - after release -
> have a
> > > > in depth discussion about the overall codebase and ci organization.
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > gabriele.cardosi@gmail.com>
> > > > wrote:
> > > >
> > > > > Alex,
> > > > > my suggestion is to move the building of all docker images, from
> > > whatever
> > > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to
> be
> > > > > invoked after all the others.
> > > > > I'm not sure if this would solve all the issues, and since I could
> not
> > > > > enter in the details of all the involved code, my suggestion may
> be too
> > > > > naive.
> > > > > Having spent almost all of the last year in CI, I may say that, at
> > > least
> > > > > for the kie-tools repo, removing the image build step from it
> should
> > > not
> > > > be
> > > > > too difficult (since it is an issue we already faced and solved).
> > > > > If, with "detailed proposal", you mean a complete list of all
> modules
> > > to
> > > > be
> > > > > moved and dependency refactoring, of course I can not provide it
> right
> > > > now.
> > > > >
> > > > > Anyway, I share the concern from Francisco: undoing something is
> almost
> > > > > always harder than doing it "rightly" from scratch...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado
> Sarti
> > > <
> > > > > ftirados@redhat.com> ha scritto:
> > > > >
> > > > > > I do not think estimations should be the only driver to make a
> > > > decision,
> > > > > > especially when the current proposal is conceptually incompatible
> > > with
> > > > > the
> > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > Given my knowledge of the CI it is nearly impossible for me to
> give
> > > a
> > > > > fair
> > > > > > estimate of how much it might take to achieve step 2) of my
> previous
> > > > > e-mail
> > > > > > . It might take a while or it might be pretty easy after all, I
> don't
> > > > > > really know, but I think it will be a good idea if some of the
> > > experts
> > > > > on
> > > > > > CI in the team (the ones that set up the pipeline, which was a
> huge
> > > > > > achievement) give an estimate, not me. Estimating how much it
> takes
> > > to
> > > > > > merge two existing repos (without altering CI) is easier, but it
> does
> > > > not
> > > > > > mean we are doing the right thing.
> > > > > > My main concern is that it will be very difficult for me to
> explain
> > > to
> > > > > > someone that arrives new to the team, that having experts on CI
> on
> > > the
> > > > > > team, we decided to merge two repos (once merged, it would be
> rather
> > > > > > difficult to unmerge) rather than fix the CI, because of
> expediency.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> porcelli@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Francisco,
> > > > > > >
> > > > > > > Please take the time to make the more in depth analysis needed
> and
> > > > > > provide
> > > > > > > a more detailed plan… so we - as community- can evaluate the
> size
> > > of
> > > > > the
> > > > > > > effort. In the conceptual level you shared it’s near
> impossible to
> > > > > > estimate
> > > > > > > the size of the effort and compare with the current proposal.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > > > ftirados@redhat.com> wrote:
> > > > > > >
> > > > > > > > I think I already did a high level proposal.
> > > > > > > > 1) Remove all dependencies from tooling to images, so images
> > > > depend
> > > > > on
> > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > 2) Then change CI to deal with tooling repo before dealing
> with
> > > > > images
> > > > > > > > repo.
> > > > > > > > I understand that CI details are tricky and since I'm not
> > > familiar
> > > > > with
> > > > > > > CI
> > > > > > > > in any way, I barely can make a low level design, but we do
> not
> > > > need
> > > > > to
> > > > > > > fix
> > > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> alex@porcelli.me
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco and Grabriele,
> > > > > > > > >
> > > > > > > > > You may not like or understand why the current state of
> the CI
> > > is
> > > > > > like
> > > > > > > > > that… actually has been in Red Hat and has been replicated
> in
> > > > > Apache
> > > > > > as
> > > > > > > > > used to be….
> > > > > > > > >
> > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > >
> > > > > > > > > If you disagree with the current plan, please provide a
> > > detailed
> > > > > > > > > alternative so we, as community, can better evaluate the
> pros
> > > and
> > > > > > cons
> > > > > > > of
> > > > > > > > > each proposal.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think it’s also fair to say that, post 10 release we
> need to
> > > > > have a
> > > > > > > > much
> > > > > > > > > in depth discussion about how our codebase is organized,
> it’s
> > > > clear
> > > > > > > that
> > > > > > > > > it’s not working.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > As Francisco said,
> > > > > > > > > > I also have the impression that the "images" (if we are
> > > talking
> > > > > of
> > > > > > > > docker
> > > > > > > > > > images) should be the very last one to be built, in a
> > > > standalone
> > > > > > > repo.
> > > > > > > > > > That way, they may "combine" artifacts that are built in
> > > > > different
> > > > > > > > repos,
> > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> > > maybe
> > > > > > could
> > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > (I also think there are some statements of undisputable
> needs
> > > > > while
> > > > > > > > they
> > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > discussion.)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > > > Tirado
> > > > > > > Sarti
> > > > > > > > <
> > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > >
> > > > > > > > > > > Alex,
> > > > > > > > > > > There are two assumptions that deserve further
> discussion:
> > > > > > > > > > > 1) That tool has to be the last to build. why? it does
> not
> > > > have
> > > > > > > more
> > > > > > > > > > sense
> > > > > > > > > > > to build final images after everything else has been
> > > built?-
> > > > > > > > > > > 2) That the impact (in terms of effort now) on fixing
> CI is
> > > > > > bigger
> > > > > > > > than
> > > > > > > > > > the
> > > > > > > > > > > impact (long term consequences) of consolidating two
> > > > unrelated
> > > > > > > piece
> > > > > > > > of
> > > > > > > > > > > software within the same repository.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > alex@porcelli.me
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Francisco,
> > > > > > > > > > > >
> > > > > > > > > > > > This was discussed as an alternative solution,
> however it
> > > > has
> > > > > > > major
> > > > > > > > > > > impact
> > > > > > > > > > > > on CI and there’s also the fact Tool has been always
> the
> > > > last
> > > > > > to
> > > > > > > > > build
> > > > > > > > > > > and
> > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> world
> > > > there
> > > > > > is
> > > > > > > no
> > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > >
> > > > > > > > > > > > So, based on our evaluation… the proposal here is the
> > > least
> > > > > > > > > disruptive
> > > > > > > > > > > and
> > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > _____________
> > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> Tirado
> > > > > Sarti <
> > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> embracing
> > > the
> > > > > fact
> > > > > > > > that
> > > > > > > > > > > > > kogito-images depend on kie-tools, because we want
> > > those
> > > > > > images
> > > > > > > > to
> > > > > > > > > > > > include
> > > > > > > > > > > > > tools.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > > Tirado
> > > > > > Sarti
> > > > > > > <
> > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > kn-plugin-workflow
> > > > > > > to
> > > > > > > > > > > > > > kogito-images (so there is not longer dependency
> from
> > > > > tools
> > > > > > > to
> > > > > > > > > > > images)
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > > > Martinez
> > > > > > <
> > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> (apache)
> > > <
> > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > > > alex@porcelli.me
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > I spent the last day or so working closely
> with
> > > > > Tiago,
> > > > > > > > > > exploring
> > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > > > evaluating
> > > > > > > > the
> > > > > > > > > > > > overall
> > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > > proposal
> > > > > as
> > > > > > > the
> > > > > > > > > > most
> > > > > > > > > > > > > >> > > viable option for unblocking the 10 release
> in
> > > the
> > > > > > > > > reasonable
> > > > > > > > > > > time
> > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento
> <
> > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> time,
> > > as
> > > > > this
> > > > > > > > > matter
> > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This email will take you < 20 minutes to
> read,
> > > > > > > according
> > > > > > > > > to
> > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As you may have followed on a separate
> thread
> > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > >
> > > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > ),
> > > > > > > > > > > > > >> > > > many of us were working towards removing a
> > > > > circular
> > > > > > > > > > dependency
> > > > > > > > > > > > > >> > > > currently present between `kogito-apps`
> and
> > > > > > > `kie-tools`.
> > > > > > > > > As
> > > > > > > > > > we
> > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> finding
> > > > the
> > > > > > > > > circular
> > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> breakdown of
> > > > the
> > > > > > > things
> > > > > > > > > we
> > > > > > > > > > > did,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Right now, even though we started the
> effort
> > > to
> > > > > move
> > > > > > > the
> > > > > > > > > > > Quarkus
> > > > > > > > > > > > > Dev
> > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> > > able
> > > > to
> > > > > > do
> > > > > > > it
> > > > > > > > > > yet,
> > > > > > > > > > > as
> > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> > > Maven
> > > > > > 3.9.6,
> > > > > > > > and
> > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > This
> > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > >> > > >
> > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > .
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > C | 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > Y | 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > >> > > > * and
> > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > depend
> > > > > > > > > > > > > >> on
> > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > `kie-tools`,
> > > > > we
> > > > > > > > > would've
> > > > > > > > > > > > had:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > C |==> 04.
> incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As
> `kie-tools`/kn-plugin-workflow
> > > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > >> > > > * and
> > > `kogito-images`/kogito-swf-devmode
> > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> image to
> > > > > > > > > `kie-tools`,
> > > > > > > > > > we
> > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As
> `kie-tools`/kn-plugin-workflow
> > > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> than a
> > > > > simple
> > > > > > > > > > circular
> > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > > > people,
> > > > > > > it's
> > > > > > > > > been
> > > > > > > > > > > > > really
> > > > > > > > > > > > > >> > > > hard coming up with a simple solution that
> > > makes
> > > > > it
> > > > > > > > > possible
> > > > > > > > > > > to
> > > > > > > > > > > > > >> build
> > > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving
> the
> > > way
> > > > > > > > everyone
> > > > > > > > > is
> > > > > > > > > > > > used
> > > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > contributing to the multiple repositories
> we
> > > > have.
> > > > > > > More
> > > > > > > > > than
> > > > > > > > > > > > that,
> > > > > > > > > > > > > >> > > > while making this assessment, I found more
> > > > > problems
> > > > > > > > that,
> > > > > > > > > in
> > > > > > > > > > > my
> > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > > forward
> > > > > with
> > > > > > > my
> > > > > > > > > > > proposal
> > > > > > > > > > > > > for
> > > > > > > > > > > > > >> > > > the Apache KIE release process, so we can
> use
> > > > > > Apache's
> > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> > > this
> > > > > > really
> > > > > > > > > > > > complicated
> > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I'll lay out my entire perspective about
> the
> > > > > current
> > > > > > > > > > situation
> > > > > > > > > > > > of
> > > > > > > > > > > > > >> our
> > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> currently
> > > > see.
> > > > > > > I'll
> > > > > > > > > > start
> > > > > > > > > > > > with
> > > > > > > > > > > > > >> an
> > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > purposes,
> > > > > > point
> > > > > > > > out
> > > > > > > > > > > some
> > > > > > > > > > > > > >> > > > problems that I believe are blocking our
> 10
> > > > > release,
> > > > > > > > > explain
> > > > > > > > > > > my
> > > > > > > > > > > > > >> > > > proposal and discuss some consequences to
> what
> > > > I'm
> > > > > > > > > > proposing.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count:
> 11)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> > > `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-serverless-operator @
> > > > > `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > >> > > > -
> incubator-kie-sandbox-quarkus-accelerator @
> > > > > > `0.0.0`
> > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > >> > > > (Issues only, README should be
> updated @
> > > > > `main`.
> > > > > > > > Same
> > > > > > > > > > for
> > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy
> at
> > > the
> > > > > > > `main`
> > > > > > > > > > > branch.)
> > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`.
> Push @
> > > > > > > `deploy`
> > > > > > > > to
> > > > > > > > > > > > update
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > sandbox.kie.org
> > > > > and
> > > > > > > KIE
> > > > > > > > > > Tools'
> > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @
> `main`
> > > > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> > > checks
> > > > > > > during
> > > > > > > > > the
> > > > > > > > > > > > > staging
> > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I grouped the repositories by category,
> and
> > > > listed
> > > > > > > them
> > > > > > > > > in a
> > > > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > > > flattening
> > > > > > > > out a
> > > > > > > > > > > tree,
> > > > > > > > > > > > > >> there
> > > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > > OptaPlanner
> > > > > > > > > > could've
> > > > > > > > > > > > been
> > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category A repos are what I've been
> referring
> > > to
> > > > > as
> > > > > > > > > `drools`
> > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner
> is
> > > > inside
> > > > > > > that
> > > > > > > > > > > stream,
> > > > > > > > > > > > as
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > way these repositories reference each
> other
> > > are
> > > > > > > through
> > > > > > > > > > Maven
> > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> 999-SNAPSHOT
> > > > > > > version.
> > > > > > > > > This
> > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > >> > > > is well-known to the team, and although
> flawed
> > > > for
> > > > > > > > > intra-day
> > > > > > > > > > > > > builds
> > > > > > > > > > > > > >> > > > and disruptive for people in many
> different
> > > time
> > > > > > > zones,
> > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > > > > >> already
> > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> with, I
> > > > > > assume.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > > > dedicated
> > > > > > > > > > > pipelines,
> > > > > > > > > > > > > >> which
> > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> build
> > > > > > cross-repo
> > > > > > > > PRs
> > > > > > > > > > > > > together
> > > > > > > > > > > > > >> > > > and verify that the codebase will continue
> > > > working
> > > > > > as
> > > > > > > > > > expected
> > > > > > > > > > > > > after
> > > > > > > > > > > > > >> > > > they're all merged. From what I could
> gather,
> > > > > there
> > > > > > > are
> > > > > > > > > some
> > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > cross-repo
> > > > > > PRs.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps,
> and
> > > > > > > > > kogito-examples
> > > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > > > >> > > > - kogito-images, and
> > > kogito-serverless-operator
> > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to
> any
> > > > > > > > combination
> > > > > > > > > of
> > > > > > > > > > > > repos
> > > > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > > > cannot
> > > > > be
> > > > > > > > > > verified
> > > > > > > > > > > > > before
> > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > dependent
> > > > > on
> > > > > > > > > > individual
> > > > > > > > > > > > > >> > > > contributors building stuff on their
> machines
> > > to
> > > > > > > verify
> > > > > > > > > that
> > > > > > > > > > > it
> > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > > > pipelines,
> > > > > > > so
> > > > > > > > > > > please
> > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category B repos are what I've been
> referring
> > > to
> > > > > as
> > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > > > repository
> > > > > > > > that
> > > > > > > > > > is
> > > > > > > > > > > > used
> > > > > > > > > > > > > >> by
> > > > > > > > > > > > > >> > > > people starting projects from scratch on
> KIE
> > > > > > Sandbox,
> > > > > > > > > > similar
> > > > > > > > > > > > to a
> > > > > > > > > > > > > >> > > > Maven archetype, if you will. The other
> one is
> > > > the
> > > > > > KIE
> > > > > > > > > Tools
> > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> build
> > > > > system.
> > > > > > > > > > > Currently,
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > TypeScript
> > > > > > > > libraries
> > > > > > > > > > and
> > > > > > > > > > > > > apps,
> > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > > > `kie-tools`
> > > > > > > > > > monorepo
> > > > > > > > > > > > is
> > > > > > > > > > > > > >> > > > configured to work with sparse checkouts
> and
> > > can
> > > > > do
> > > > > > > > > partial
> > > > > > > > > > > > > builds.
> > > > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > > > through
> > > > > > > > > > timestamped
> > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> recently
> > > > > > > > introduced
> > > > > > > > > > that
> > > > > > > > > > > > > will
> > > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > > artifacts
> > > > > > > under
> > > > > > > > a
> > > > > > > > > > > > version
> > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> format,
> > > > > > published
> > > > > > > > > weekly
> > > > > > > > > > > > every
> > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > > > evolution
> > > > > > > to
> > > > > > > > > the
> > > > > > > > > > > > Kogito
> > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> release
> > > for
> > > > > all
> > > > > > > of
> > > > > > > > > > Apache
> > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > >> so
> > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > An important note here is that Category B
> > > > > > repositories
> > > > > > > > > have
> > > > > > > > > > > been
> > > > > > > > > > > > > >> > > > historically kept out of any automations
> we
> > > used
> > > > > to
> > > > > > > > have,
> > > > > > > > > > way
> > > > > > > > > > > > back
> > > > > > > > > > > > > >> > > > when Kogito started and we had the
> Business
> > > > > Central
> > > > > > > > > (a.k.a.
> > > > > > > > > > > v7)
> > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > >> > > > still going on. For this reason, Category
> B
> > > > > projects
> > > > > > > > have
> > > > > > > > > > > > > developed
> > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > Actions.
> > > > > > > > Category B
> > > > > > > > > > > repos
> > > > > > > > > > > > > >> have
> > > > > > > > > > > > > >> > > > always depended on Category A repos using
> > > fixed
> > > > > > > > versions.
> > > > > > > > > If
> > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> SNAPSHOTs,
> > > > > breaking
> > > > > > > > > changes
> > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > > potential
> > > > > > to
> > > > > > > > > break
> > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > > > development
> > > > > > > > > > stream,
> > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > maintainers
> > > > > of
> > > > > > > > > > Category B
> > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > >> > > > as historically Category A contributors
> were
> > > not
> > > > > > > > familiar
> > > > > > > > > > with
> > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > > > through
> > > > > a
> > > > > > > > GitHub
> > > > > > > > > > > > Actions
> > > > > > > > > > > > > >> > > > workflow that builds the relevant part of
> the
> > > > > > > > `kie-tools`
> > > > > > > > > > > > monorepo
> > > > > > > > > > > > > >> for
> > > > > > > > > > > > > >> > > > the changes introduced. Changes made to
> the
> > > > > pipeline
> > > > > > > > > itself
> > > > > > > > > > > are
> > > > > > > > > > > > > also
> > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to
> do
> > > > things
> > > > > > > like
> > > > > > > > > > > > atomically
> > > > > > > > > > > > > >> > > > bumping the Node.js version, for example.
> More
> > > > > > > > > importantly,
> > > > > > > > > > it
> > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > timestamped
> > > > > > > > SNAPSHOT
> > > > > > > > > > > > > together
> > > > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > > > green.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This setup, however, makes it impossible
> to
> > > have
> > > > > > > > > cross-repo
> > > > > > > > > > > PRs
> > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > simultaneously,
> > > > > > > with
> > > > > > > > > the
> > > > > > > > > > > > > current
> > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> around,
> > > > and
> > > > > > I'm
> > > > > > > > not
> > > > > > > > > > sure
> > > > > > > > > > > > if
> > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > Regardless,
> > > > > as
> > > > > > > > > they're
> > > > > > > > > > > > part
> > > > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> release,
> > > > so I
> > > > > > > > listed
> > > > > > > > > > them
> > > > > > > > > > > > for
> > > > > > > > > > > > > >> us
> > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category D is self explanatory. There's
> only
> > > one
> > > > > > repo
> > > > > > > > that
> > > > > > > > > > has
> > > > > > > > > > > > > >> already
> > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > > > directly,
> > > > > > > and
> > > > > > > > > are
> > > > > > > > > > > > > either
> > > > > > > > > > > > > >> > > > organizational entities, or host websites,
> > > that
> > > > > > > > currently
> > > > > > > > > > are
> > > > > > > > > > > > not
> > > > > > > > > > > > > >> part
> > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This lack of unification between Category
> A
> > > and
> > > > > > > > Category B
> > > > > > > > > > is,
> > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > > > circular
> > > > > > > > > > dependency
> > > > > > > > > > > > > >> between
> > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we
> now
> > > can
> > > > > > > describe
> > > > > > > > > as
> > > > > > > > > > a
> > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > >> > > > dependency between Category A and
> Category B.
> > > > The
> > > > > > way
> > > > > > > I
> > > > > > > > > see
> > > > > > > > > > > it,
> > > > > > > > > > > > if
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > had a single pipeline, building everything
> > > from
> > > > > > > `drools`
> > > > > > > > > to
> > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> been
> > > > > > > introduced,
> > > > > > > > > and
> > > > > > > > > > we
> > > > > > > > > > > > > >> > > > wouldn't be having this huge problem in
> our
> > > > hands
> > > > > > > right
> > > > > > > > > now.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> process
> > > > > sees
> > > > > > > this
> > > > > > > > > > lack
> > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > unification as a central problem, not
> only for
> > > > > this
> > > > > > > > > release
> > > > > > > > > > in
> > > > > > > > > > > > > >> > > > particular, but for the community as a
> whole.
> > > It
> > > > > is
> > > > > > my
> > > > > > > > > > belief
> > > > > > > > > > > > that
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > > contribution
> > > > > > > > > should
> > > > > > > > > > > be
> > > > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> > > With
> > > > > the
> > > > > > > > > > increasing
> > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > >> > > > of code, and hopefully number of
> contributors
> > > > too,
> > > > > > we
> > > > > > > > > cannot
> > > > > > > > > > > > keep
> > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> breaking
> > > > > things.
> > > > > > > > We're
> > > > > > > > > > all
> > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > mechanisms
> > > > in
> > > > > > > place
> > > > > > > > > to
> > > > > > > > > > > > > prevent
> > > > > > > > > > > > > >> us
> > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> Especially
> > > > when
> > > > > > > these
> > > > > > > > > > > mistakes
> > > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > > individually,
> > > > > > > > > > > probably
> > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> depending
> > > on
> > > > > > > > > kiegroup's
> > > > > > > > > > > KIE
> > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > `kogito-images`
> > > > > > > > > > depending
> > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > > > kiegroup's
> > > > > > > > > > `lienzo`
> > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > `7.59.0.Final`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > depending
> > > > on
> > > > > > > > > > kiegroup's
> > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > codebase
> > > > > > here:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >
> > > > > > > >
> > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > ,
> > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > OptaPlanner,
> > > > > > > > > pointing
> > > > > > > > > > to
> > > > > > > > > > > > > older
> > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P5.
> > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > depending
> > > > > > > > > on
> > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P6. Category C repos are out of date and
> not
> > > > part
> > > > > of
> > > > > > > the
> > > > > > > > > > > > Category
> > > > > > > > > > > > > A
> > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> (Current
> > > > > version
> > > > > > is
> > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > version,
> > > > > only
> > > > > > > by
> > > > > > > > > > using
> > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> version
> > > is
> > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > OptaPlanner
> > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P7.
> `kie-tools`/packages/kn-plugin-workflow
> > > has
> > > > > its
> > > > > > > E2E
> > > > > > > > > > > disabled
> > > > > > > > > > > > > >> after
> > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > > > solution,
> > > > > > > as
> > > > > > > > > they
> > > > > > > > > > > > both
> > > > > > > > > > > > > >> > > > suffer from the circular dependency
> between
> > > > > > Category A
> > > > > > > > and
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > >> > > > As Category A and Category B are both
> streams
> > > > that
> > > > > > > have
> > > > > > > > > been
> > > > > > > > > > > > > really
> > > > > > > > > > > > > >> > > > active, I see this as a blocker, as there
> are
> > > > > > > > > contributions
> > > > > > > > > > > that
> > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> depends
> > > on
> > > > > > > > Category
> > > > > > > > > B
> > > > > > > > > > > > with a
> > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > understood
> > > > > as
> > > > > > > > > > technical
> > > > > > > > > > > > > debt.
> > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > something
> > > > > > we'll
> > > > > > > > > always
> > > > > > > > > > > be
> > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> just a
> > > > > matter
> > > > > > of
> > > > > > > > > > making
> > > > > > > > > > > > them
> > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> impact
> > > the
> > > > > > > > structure
> > > > > > > > > or
> > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > > > regression
> > > > > > > we
> > > > > > > > > > > > > introduced
> > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> Apache
> > > KIE
> > > > > 10,
> > > > > > > and
> > > > > > > > > > that
> > > > > > > > > > > > P5,
> > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems
> left
> > > > to
> > > > > > > > discuss
> > > > > > > > > > are
> > > > > > > > > > > P1
> > > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > > > proposal.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> > > from
> > > > my
> > > > > > > > > > experience,
> > > > > > > > > > > > any
> > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> release
> > > > not
> > > > > > > > working
> > > > > > > > > > out
> > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > possible,
> > > > > and
> > > > > > > make
> > > > > > > > > > > > > everything
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > release,
> > > > > bear
> > > > > > > > with
> > > > > > > > > > me.
> > > > > > > > > > > > I'll
> > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > >> > > > out a timeline of events that need to
> happen
> > > in
> > > > > > order
> > > > > > > > for
> > > > > > > > > > our
> > > > > > > > > > > > > >> release
> > > > > > > > > > > > > >> > > > to be published, with all artifacts
> ending up
> > > in
> > > > > the
> > > > > > > > right
> > > > > > > > > > > > places,
> > > > > > > > > > > > > >> but
> > > > > > > > > > > > > >> > > > first, we need to solve problems P1 and
> P2.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As you saw at the beginning of this
> email, all
> > > > the
> > > > > > > > > attempts
> > > > > > > > > > we
> > > > > > > > > > > > > made
> > > > > > > > > > > > > >> > > > left us with the circular dependency
> showing
> > > up
> > > > > at a
> > > > > > > > > > different
> > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > >> > > > but something all these places have in
> common
> > > is
> > > > > > that
> > > > > > > > > > they're
> > > > > > > > > > > > all
> > > > > > > > > > > > > >> > > > after kogito-apps, and before to Category
> B.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > following:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > S1. We keep the original plan of moving
> the
> > > > > Quarkus
> > > > > > > Dev
> > > > > > > > > UIs
> > > > > > > > > > > from
> > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> with
> > > > > > Management
> > > > > > > > and
> > > > > > > > > > > Task
> > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> `kie-tools`.
> > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > images
> > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > `kogito-serverless-operator`
> > > > > > > repo
> > > > > > > > > > > inside
> > > > > > > > > > > > a
> > > > > > > > > > > > > >> new
> > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> history.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> > > problems
> > > > > P1
> > > > > > > and
> > > > > > > > > P2.
> > > > > > > > > > Of
> > > > > > > > > > > > > >> course
> > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > >>
> > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This doesn't come without consequences, of
> > > > course,
> > > > > > as
> > > > > > > > the
> > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> `kogito-swf-builder`
> > > > > > images,
> > > > > > > > and
> > > > > > > > > > the
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be
> moving
> > > > from
> > > > > > > > > Category A
> > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > Category B. This move would make them
> have to
> > > > > > > reference
> > > > > > > > > > > > Category A
> > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > > > `kogito-images`
> > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are already
> their
> > > > own
> > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > >> > > > Category A, though, contributions made in
> a
> > > > > > cross-repo
> > > > > > > > > > fashion
> > > > > > > > > > > > to
> > > > > > > > > > > > > >> this
> > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> possible, now
> > > > > via a
> > > > > > > > > single
> > > > > > > > > > PR
> > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> Category A
> > > > and
> > > > > > > > > Category
> > > > > > > > > > B
> > > > > > > > > > > > will
> > > > > > > > > > > > > >> > > > continue not being possible, and a 1-week
> > > delay
> > > > > > > between
> > > > > > > > > > > merging
> > > > > > > > > > > > > >> > > > something on Category A and using it on
> > > > Category B
> > > > > > > will
> > > > > > > > > > still
> > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> > > however,
> > > > > > does
> > > > > > > > > allow
> > > > > > > > > > > for
> > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > >> > > > checkouts and partial builds, so working
> with
> > > a
> > > > > > subset
> > > > > > > > of
> > > > > > > > > > the
> > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > >> > > > is possible and encouraged. Making changes
> > > only
> > > > to
> > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> example,
> > > will
> > > > > > have
> > > > > > > > the
> > > > > > > > > PR
> > > > > > > > > > > > > checks
> > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > >> > > > We're not compromising when running
> partial
> > > > builds
> > > > > > > too.
> > > > > > > > We
> > > > > > > > > > > know
> > > > > > > > > > > > > that
> > > > > > > > > > > > > >> > > > the entire repo will continue working even
> > > after
> > > > > > only
> > > > > > > > > > > building a
> > > > > > > > > > > > > >> small
> > > > > > > > > > > > > >> > > > subset of the changes. Doing partial or
> full
> > > > > builds
> > > > > > is
> > > > > > > > > > > > > automatically
> > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> proposing
> > > we
> > > > > > move a
> > > > > > > > > bunch
> > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see
> this
> > > > as a
> > > > > > > > > TEMPORARY
> > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host
> some
> > > > > > > additional
> > > > > > > > > > stuff
> > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > continue
> > > > > > moving
> > > > > > > > > > > forward.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As I mentioned on other places,
> `kie-tools`
> > > > > became a
> > > > > > > > > > polyglot
> > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > >> > > > out of necessity, and although I'm really
> > > proud
> > > > of
> > > > > > > what
> > > > > > > > we
> > > > > > > > > > > > > achieved
> > > > > > > > > > > > > >> > > > there so far, I don't think `kie-tools`
> has a
> > > > > setup
> > > > > > > that
> > > > > > > > > is
> > > > > > > > > > > > > suitable
> > > > > > > > > > > > > >> > > > for all the different nuances that
> compose our
> > > > > > > > community.
> > > > > > > > > > I'm
> > > > > > > > > > > > well
> > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that does
> not
> > > > > follow
> > > > > > > > > > widespread
> > > > > > > > > > > > > >> > > > conventions will scare some people away,
> and
> > > as
> > > > > much
> > > > > > > as
> > > > > > > > > > we've
> > > > > > > > > > > > > tried
> > > > > > > > > > > > > >> to
> > > > > > > > > > > > > >> > > > make build instructions clear, we can't
> always
> > > > get
> > > > > > > past
> > > > > > > > > the
> > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > > > ecosystem.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > With all that said, I keep thinking this
> is
> > > the
> > > > > best
> > > > > > > > > course
> > > > > > > > > > of
> > > > > > > > > > > > > >> action
> > > > > > > > > > > > > >> > > > for us right now. We keep most of our
> stuff
> > > > > > unchanged,
> > > > > > > > we
> > > > > > > > > > > > unblock
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > release, and we have a working setup that
> will
> > > > > suit
> > > > > > us
> > > > > > > > > well
> > > > > > > > > > > > while
> > > > > > > > > > > > > we
> > > > > > > > > > > > > >> > > > discuss and reach a conclusion regarding
> the
> > > > > future
> > > > > > of
> > > > > > > > our
> > > > > > > > > > > > > codebase
> > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Let me paint a quick picture here of what
> our
> > > > code
> > > > > > > base
> > > > > > > > > > would
> > > > > > > > > > > > look
> > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > > > accepted:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > B
> > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > > > >> > > > E
> > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * Category C becomes part of Category A,
> and
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> entirely
> > > > inside
> > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> images
> > > and
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > `kie-tools`,
> > > > > > there
> > > > > > > > are
> > > > > > > > > > no
> > > > > > > > > > > > > cycles
> > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > > granularly
> > > > > > > build:
> > > > > > > > > > > > > >> > > > 1.
> packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> (containing
> > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > >> and
> > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> (contents
> > > > from
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The second part of the proposal is the
> release
> > > > > > process
> > > > > > > > > > itself,
> > > > > > > > > > > > > >> > > > assuming the structure above is what we
> have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be
> used as
> > > > > > cutting
> > > > > > > > > point
> > > > > > > > > > > for
> > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to
> this
> > > > > > > timestamped
> > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > >> and
> > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > >> > > > 3. At this point, with everything
> working, we
> > > > can
> > > > > > > branch
> > > > > > > > > out
> > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> > > > SNAPSHOT
> > > > > > > tag,
> > > > > > > > > and
> > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> update
> > > > > their
> > > > > > > > > versions
> > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > Category
> > > > A
> > > > > > > repos
> > > > > > > > > > using
> > > > > > > > > > > > the
> > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the
> release
> > > > based
> > > > > > on
> > > > > > > > the
> > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > >> > > > branches, given we don't expect any code
> > > changes
> > > > > > > > anymore.
> > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to
> start
> > > the
> > > > > > > release
> > > > > > > > > > > process.
> > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > manual/automated
> > > > > > > > release
> > > > > > > > > > > > process,
> > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> pushed
> > > to
> > > > > Git,
> > > > > > > and
> > > > > > > > > > built
> > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > artifacts
> > > > > to
> > > > > > be
> > > > > > > > > > > > propagated
> > > > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > manual/automated
> > > > > > > > release
> > > > > > > > > > > > > process,
> > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> pushed
> > > to
> > > > > Git,
> > > > > > > and
> > > > > > > > > > built
> > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > >> > > > 12. Category E repos can be manually
> tagged
> > > with
> > > > > > > 10.0.0
> > > > > > > > > from
> > > > > > > > > > > > their
> > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > More needs to be discussed if we're
> planning
> > > to
> > > > > > > maintain
> > > > > > > > > > > > multiple
> > > > > > > > > > > > > >> > > > release streams in parallel, but I guess
> it
> > > can
> > > > > wait
> > > > > > > for
> > > > > > > > > > after
> > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> forward
> > > > to
> > > > > > > > hearing
> > > > > > > > > > back
> > > > > > > > > > > > > from
> > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Of course, alternative solutions are
> possible.
> > > > > This
> > > > > > > > email,
> > > > > > > > > > > > > however,
> > > > > > > > > > > > > >> > > > summarizes my view of how we should
> attack the
> > > > > > > problem,
> > > > > > > > > > > > > considering
> > > > > > > > > > > > > >> > > > disruption, required effort, the release
> > > process
> > > > > > > itself,
> > > > > > > > > and
> > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > >> > > > Feel free to propose alternatives. This is
> > > not a
> > > > > > > voting
> > > > > > > > > > > thread.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <al...@porcelli.me>.
Francisco,
As I wrote earlier, I had a conversation with Jan - that is our
community CI expert - and he said that he guesses that it would take
about 2 months to make CI changes implied in your comments.
He also mentioned that if Tristan was around and could dedicate his
time on this, he believes that Tristan could make the same changes
potentially in about 2 weeks.
On Wed, Mar 13, 2024 at 9:26 AM Francisco Javier Tirado Sarti
<ft...@redhat.com> wrote:
>
> @Ricardo Zanini <za...@redhat.com> The main issue I have is why we
> conclude 1 takes less time than 2?. If I understood 1) completely, it also
> requires CI adjustments (at tools repo level, not at overall stream level),
> so I hardly see the estimation different for someone that is familiar with
> CI.
>
> On Wed, Mar 13, 2024 at 2:14 PM ricardo zanini fernandes <
> ricardozanini@gmail.com> wrote:
>
> > Hi!
> >
> > Clearly, you all understand that moving images and the operator to
> > kie-tools is a workaround and wrong in all possible scenarios, right? We
> > won't undo once we merge. I'm pretty positive that once we have a release
> > train going people will add all the obstacles they can add saying "It's
> > working, let's not change it".
> >
> > Also, I understand that we need to unblock the release. We can compromise
> > in COPYING the code, do the release, and then make the necessary changes.
> > Images and cloud code are *integration platforms*. Should be the last in a
> > stream. Tooling SHOULD NOT, in any case, depend on the images to build.
> >
> > So we can:
> >
> > 1. Accept Tiago's proposal (very well detailed, thanks!) but COPYING the
> > code base, not MERGING. The contributions still flow to the right repos.
> > 2. After release we:
> > 1. Move the CLI to the operator repo, removing this dependency from
> > tools to image
> > 2. Adjust the CI
> > 3. Remove the copied code
> >
> > Moving forward, I'd like to see a clear boundary between the projects (as
> > stated in the temporary website). At the moment, we do not have. And it's
> > hard for anyone from outside to understand what we are doing.
> >
> > On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > Francisco and Gabriele,
> > >
> > > I understand and acknowledge your desire to find the “right” solution
> > > instead to work on a temporary “patch” - however without a detailed
> > > proposal I don’t think we can properly evaluate the impact of your
> > > suggestion.
> > >
> > > When I spoke with different SMEs that included tools and CI, the
> > > guesstimate for making the necessary changes on CI and codebase to
> > > basically have images and operators in the end of the build chain is
> > > something like 2 months of effort. Another impact that needs to be
> > > discussed is that KIE Tools repo had to be injected in the middle of all
> > > pipelines - forcing all PR checks and nightlies to build all repos (PR
> > > checks will likely take 12+ hours… I even heard that it could be even 24
> > > hours).
> > >
> > > Based on the input above, I think it’s quite risk to move in such
> > direction
> > > without a more detailed plan… because 2 months could be turned easily in
> > 6!
> > > And this is exactly what happened when we guessed that moving to Apache
> > > would take no more than 3 months. But here we are.
> > >
> > > I really strongly suggest that we focus on a release that could be
> > > achievable in less than a month from now, and we - after release - have a
> > > in depth discussion about the overall codebase and ci organization.
> > >
> > >
> > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > gabriele.cardosi@gmail.com>
> > > wrote:
> > >
> > > > Alex,
> > > > my suggestion is to move the building of all docker images, from
> > whatever
> > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > > > invoked after all the others.
> > > > I'm not sure if this would solve all the issues, and since I could not
> > > > enter in the details of all the involved code, my suggestion may be too
> > > > naive.
> > > > Having spent almost all of the last year in CI, I may say that, at
> > least
> > > > for the kie-tools repo, removing the image build step from it should
> > not
> > > be
> > > > too difficult (since it is an issue we already faced and solved).
> > > > If, with "detailed proposal", you mean a complete list of all modules
> > to
> > > be
> > > > moved and dependency refactoring, of course I can not provide it right
> > > now.
> > > >
> > > > Anyway, I share the concern from Francisco: undoing something is almost
> > > > always harder than doing it "rightly" from scratch...
> > > >
> > > >
> > > >
> > > >
> > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti
> > <
> > > > ftirados@redhat.com> ha scritto:
> > > >
> > > > > I do not think estimations should be the only driver to make a
> > > decision,
> > > > > especially when the current proposal is conceptually incompatible
> > with
> > > > the
> > > > > multi repo approach that is taken elsewhere in the project.
> > > > > Given my knowledge of the CI it is nearly impossible for me to give
> > a
> > > > fair
> > > > > estimate of how much it might take to achieve step 2) of my previous
> > > > e-mail
> > > > > . It might take a while or it might be pretty easy after all, I don't
> > > > > really know, but I think it will be a good idea if some of the
> > experts
> > > > on
> > > > > CI in the team (the ones that set up the pipeline, which was a huge
> > > > > achievement) give an estimate, not me. Estimating how much it takes
> > to
> > > > > merge two existing repos (without altering CI) is easier, but it does
> > > not
> > > > > mean we are doing the right thing.
> > > > > My main concern is that it will be very difficult for me to explain
> > to
> > > > > someone that arrives new to the team, that having experts on CI on
> > the
> > > > > team, we decided to merge two repos (once merged, it would be rather
> > > > > difficult to unmerge) rather than fix the CI, because of expediency.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Francisco,
> > > > > >
> > > > > > Please take the time to make the more in depth analysis needed and
> > > > > provide
> > > > > > a more detailed plan… so we - as community- can evaluate the size
> > of
> > > > the
> > > > > > effort. In the conceptual level you shared it’s near impossible to
> > > > > estimate
> > > > > > the size of the effort and compare with the current proposal.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > > ftirados@redhat.com> wrote:
> > > > > >
> > > > > > > I think I already did a high level proposal.
> > > > > > > 1) Remove all dependencies from tooling to images, so images
> > > depend
> > > > on
> > > > > > > tooling but tooling does not depend on images.
> > > > > > > 2) Then change CI to deal with tooling repo before dealing with
> > > > images
> > > > > > > repo.
> > > > > > > I understand that CI details are tricky and since I'm not
> > familiar
> > > > with
> > > > > > CI
> > > > > > > in any way, I barely can make a low level design, but we do not
> > > need
> > > > to
> > > > > > fix
> > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <alex@porcelli.me
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Francisco and Grabriele,
> > > > > > > >
> > > > > > > > You may not like or understand why the current state of the CI
> > is
> > > > > like
> > > > > > > > that… actually has been in Red Hat and has been replicated in
> > > > Apache
> > > > > as
> > > > > > > > used to be….
> > > > > > > >
> > > > > > > > But the fact is that this is the current reality.
> > > > > > > >
> > > > > > > > If you disagree with the current plan, please provide a
> > detailed
> > > > > > > > alternative so we, as community, can better evaluate the pros
> > and
> > > > > cons
> > > > > > of
> > > > > > > > each proposal.
> > > > > > > >
> > > > > > > >
> > > > > > > > I think it’s also fair to say that, post 10 release we need to
> > > > have a
> > > > > > > much
> > > > > > > > in depth discussion about how our codebase is organized, it’s
> > > clear
> > > > > > that
> > > > > > > > it’s not working.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > As Francisco said,
> > > > > > > > > I also have the impression that the "images" (if we are
> > talking
> > > > of
> > > > > > > docker
> > > > > > > > > images) should be the very last one to be built, in a
> > > standalone
> > > > > > repo.
> > > > > > > > > That way, they may "combine" artifacts that are built in
> > > > different
> > > > > > > repos,
> > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> > maybe
> > > > > could
> > > > > > > > > simplify the situation a bit.
> > > > > > > > > (I also think there are some statements of undisputable needs
> > > > while
> > > > > > > they
> > > > > > > > > are, actually, just technical choices.
> > > > > > > > > Anyway, this latter point is for longer, following,
> > > discussion.)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > > Tirado
> > > > > > Sarti
> > > > > > > <
> > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > >
> > > > > > > > > > Alex,
> > > > > > > > > > There are two assumptions that deserve further discussion:
> > > > > > > > > > 1) That tool has to be the last to build. why? it does not
> > > have
> > > > > > more
> > > > > > > > > sense
> > > > > > > > > > to build final images after everything else has been
> > built?-
> > > > > > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> > > > > bigger
> > > > > > > than
> > > > > > > > > the
> > > > > > > > > > impact (long term consequences) of consolidating two
> > > unrelated
> > > > > > piece
> > > > > > > of
> > > > > > > > > > software within the same repository.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > alex@porcelli.me
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Francisco,
> > > > > > > > > > >
> > > > > > > > > > > This was discussed as an alternative solution, however it
> > > has
> > > > > > major
> > > > > > > > > > impact
> > > > > > > > > > > on CI and there’s also the fact Tool has been always the
> > > last
> > > > > to
> > > > > > > > build
> > > > > > > > > > and
> > > > > > > > > > > has no Snapshot published (actually in JavaScript world
> > > there
> > > > > is
> > > > > > no
> > > > > > > > > > > snapshot concept).
> > > > > > > > > > >
> > > > > > > > > > > So, based on our evaluation… the proposal here is the
> > least
> > > > > > > > disruptive
> > > > > > > > > > and
> > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > _____________
> > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > http://porcelli.me
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > > > Sarti <
> > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > After kie-tools, sorry. I think we are not embracing
> > the
> > > > fact
> > > > > > > that
> > > > > > > > > > > > kogito-images depend on kie-tools, because we want
> > those
> > > > > images
> > > > > > > to
> > > > > > > > > > > include
> > > > > > > > > > > > tools.
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > Tirado
> > > > > Sarti
> > > > > > <
> > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > It can be an alternative solution to move
> > > > > kn-plugin-workflow
> > > > > > to
> > > > > > > > > > > > > kogito-images (so there is not longer dependency from
> > > > tools
> > > > > > to
> > > > > > > > > > images)
> > > > > > > > > > > > and
> > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > > Martinez
> > > > > <
> > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache)
> > <
> > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > > alex@porcelli.me
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > I spent the last day or so working closely with
> > > > Tiago,
> > > > > > > > > exploring
> > > > > > > > > > > > >> > different
> > > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > > evaluating
> > > > > > > the
> > > > > > > > > > > overall
> > > > > > > > > > > > >> > release
> > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > proposal
> > > > as
> > > > > > the
> > > > > > > > > most
> > > > > > > > > > > > >> > > viable option for unblocking the 10 release in
> > the
> > > > > > > > reasonable
> > > > > > > > > > time
> > > > > > > > > > > > >> frame.
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time,
> > as
> > > > this
> > > > > > > > matter
> > > > > > > > > > > > >> requires a
> > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > > > > > according
> > > > > > > > to
> > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > > > > > >> > > > (
> > > > > > > > > > >
> > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > ),
> > > > > > > > > > > > >> > > > many of us were working towards removing a
> > > > circular
> > > > > > > > > dependency
> > > > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > > > `kie-tools`.
> > > > > > > > As
> > > > > > > > > we
> > > > > > > > > > > > >> > > > progressed towards a solution, we kept finding
> > > the
> > > > > > > > circular
> > > > > > > > > > > > >> dependency
> > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of
> > > the
> > > > > > things
> > > > > > > > we
> > > > > > > > > > did,
> > > > > > > > > > > > and
> > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Right now, even though we started the effort
> > to
> > > > move
> > > > > > the
> > > > > > > > > > Quarkus
> > > > > > > > > > > > Dev
> > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> > able
> > > to
> > > > > do
> > > > > > it
> > > > > > > > > yet,
> > > > > > > > > > as
> > > > > > > > > > > > >> we've
> > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> > Maven
> > > > > 3.9.6,
> > > > > > > and
> > > > > > > > > > > Quarkus
> > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > This
> > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > >> > > >
> > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > .
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > C | 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > Y | 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > >> > > > * and
> > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > depend
> > > > > > > > > > > > >> on
> > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > `kie-tools`,
> > > > we
> > > > > > > > would've
> > > > > > > > > > > had:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > >> > > > * and
> > `kogito-images`/kogito-swf-devmode
> > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > > > > > `kie-tools`,
> > > > > > > > > we
> > > > > > > > > > > > >> would've
> > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem than a
> > > > simple
> > > > > > > > > circular
> > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > > people,
> > > > > > it's
> > > > > > > > been
> > > > > > > > > > > > really
> > > > > > > > > > > > >> > > > hard coming up with a simple solution that
> > makes
> > > > it
> > > > > > > > possible
> > > > > > > > > > to
> > > > > > > > > > > > >> build
> > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving the
> > way
> > > > > > > everyone
> > > > > > > > is
> > > > > > > > > > > used
> > > > > > > > > > > > to
> > > > > > > > > > > > >> > > > contributing to the multiple repositories we
> > > have.
> > > > > > More
> > > > > > > > than
> > > > > > > > > > > that,
> > > > > > > > > > > > >> > > > while making this assessment, I found more
> > > > problems
> > > > > > > that,
> > > > > > > > in
> > > > > > > > > > my
> > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > forward
> > > > with
> > > > > > my
> > > > > > > > > > proposal
> > > > > > > > > > > > for
> > > > > > > > > > > > >> > > > the Apache KIE release process, so we can use
> > > > > Apache's
> > > > > > > > > > > mechanisms
> > > > > > > > > > > > to
> > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> > this
> > > > > really
> > > > > > > > > > > complicated
> > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > > > current
> > > > > > > > > situation
> > > > > > > > > > > of
> > > > > > > > > > > > >> our
> > > > > > > > > > > > >> > > > codebase, as well as problems I can currently
> > > see.
> > > > > > I'll
> > > > > > > > > start
> > > > > > > > > > > with
> > > > > > > > > > > > >> an
> > > > > > > > > > > > >> > > > analysis of the repositories and their
> > purposes,
> > > > > point
> > > > > > > out
> > > > > > > > > > some
> > > > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > > > release,
> > > > > > > > explain
> > > > > > > > > > my
> > > > > > > > > > > > >> > > > proposal and discuss some consequences to what
> > > I'm
> > > > > > > > > proposing.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> > `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > > > `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> > > > > `0.0.0`
> > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > >> > > > (Issues only, README should be updated @
> > > > `main`.
> > > > > > > Same
> > > > > > > > > for
> > > > > > > > > > > > GitHub
> > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy at
> > the
> > > > > > `main`
> > > > > > > > > > branch.)
> > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > > > > > `deploy`
> > > > > > > to
> > > > > > > > > > > update
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > > >> > > > (GitHub pages used to host
> > sandbox.kie.org
> > > > and
> > > > > > KIE
> > > > > > > > > Tools'
> > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> > checks
> > > > > > during
> > > > > > > > the
> > > > > > > > > > > > staging
> > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I grouped the repositories by category, and
> > > listed
> > > > > > them
> > > > > > > > in a
> > > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > > flattening
> > > > > > > out a
> > > > > > > > > > tree,
> > > > > > > > > > > > >> there
> > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > OptaPlanner
> > > > > > > > > could've
> > > > > > > > > > > been
> > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category A repos are what I've been referring
> > to
> > > > as
> > > > > > > > `drools`
> > > > > > > > > > and
> > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is
> > > inside
> > > > > > that
> > > > > > > > > > stream,
> > > > > > > > > > > as
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> > > > way these repositories reference each other
> > are
> > > > > > through
> > > > > > > > > Maven
> > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > > > > > version.
> > > > > > > > This
> > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > >> > > > is well-known to the team, and although flawed
> > > for
> > > > > > > > intra-day
> > > > > > > > > > > > builds
> > > > > > > > > > > > >> > > > and disruptive for people in many different
> > time
> > > > > > zones,
> > > > > > > it
> > > > > > > > > is
> > > > > > > > > > > > >> already
> > > > > > > > > > > > >> > > > very comfortable for everyone to work with, I
> > > > > assume.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > > dedicated
> > > > > > > > > > pipelines,
> > > > > > > > > > > > >> which
> > > > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > > > cross-repo
> > > > > > > PRs
> > > > > > > > > > > > together
> > > > > > > > > > > > >> > > > and verify that the codebase will continue
> > > working
> > > > > as
> > > > > > > > > expected
> > > > > > > > > > > > after
> > > > > > > > > > > > >> > > > they're all merged. From what I could gather,
> > > > there
> > > > > > are
> > > > > > > > some
> > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > cross-repo
> > > > > PRs.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > > > kogito-examples
> > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > > >> > > > - kogito-images, and
> > kogito-serverless-operator
> > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > > > > > combination
> > > > > > > > of
> > > > > > > > > > > repos
> > > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > > cannot
> > > > be
> > > > > > > > > verified
> > > > > > > > > > > > before
> > > > > > > > > > > > >> > > > merging, making our contribution model
> > dependent
> > > > on
> > > > > > > > > individual
> > > > > > > > > > > > >> > > > contributors building stuff on their machines
> > to
> > > > > > verify
> > > > > > > > that
> > > > > > > > > > it
> > > > > > > > > > > > >> works.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > > pipelines,
> > > > > > so
> > > > > > > > > > please
> > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category B repos are what I've been referring
> > to
> > > > as
> > > > > > > > > > `kie-tools`
> > > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > > repository
> > > > > > > that
> > > > > > > > > is
> > > > > > > > > > > used
> > > > > > > > > > > > >> by
> > > > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > > > Sandbox,
> > > > > > > > > similar
> > > > > > > > > > > to a
> > > > > > > > > > > > >> > > > Maven archetype, if you will. The other one is
> > > the
> > > > > KIE
> > > > > > > > Tools
> > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > > > system.
> > > > > > > > > > Currently,
> > > > > > > > > > > > KIE
> > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > TypeScript
> > > > > > > libraries
> > > > > > > > > and
> > > > > > > > > > > > apps,
> > > > > > > > > > > > >> Go
> > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > > `kie-tools`
> > > > > > > > > monorepo
> > > > > > > > > > > is
> > > > > > > > > > > > >> > > > configured to work with sparse checkouts and
> > can
> > > > do
> > > > > > > > partial
> > > > > > > > > > > > builds.
> > > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > > through
> > > > > > > > > timestamped
> > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > > > > > introduced
> > > > > > > > > that
> > > > > > > > > > > > will
> > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > artifacts
> > > > > > under
> > > > > > > a
> > > > > > > > > > > version
> > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > > > published
> > > > > > > > weekly
> > > > > > > > > > > every
> > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > > evolution
> > > > > > to
> > > > > > > > the
> > > > > > > > > > > Kogito
> > > > > > > > > > > > >> > > > releases, as we're now targeting one release
> > for
> > > > all
> > > > > > of
> > > > > > > > > Apache
> > > > > > > > > > > > KIE,
> > > > > > > > > > > > >> so
> > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > An important note here is that Category B
> > > > > repositories
> > > > > > > > have
> > > > > > > > > > been
> > > > > > > > > > > > >> > > > historically kept out of any automations we
> > used
> > > > to
> > > > > > > have,
> > > > > > > > > way
> > > > > > > > > > > back
> > > > > > > > > > > > >> > > > when Kogito started and we had the Business
> > > > Central
> > > > > > > > (a.k.a.
> > > > > > > > > > v7)
> > > > > > > > > > > > >> stream
> > > > > > > > > > > > >> > > > still going on. For this reason, Category B
> > > > projects
> > > > > > > have
> > > > > > > > > > > > developed
> > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > Actions.
> > > > > > > Category B
> > > > > > > > > > repos
> > > > > > > > > > > > >> have
> > > > > > > > > > > > >> > > > always depended on Category A repos using
> > fixed
> > > > > > > versions.
> > > > > > > > If
> > > > > > > > > > > > >> Category
> > > > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > > > breaking
> > > > > > > > changes
> > > > > > > > > > on
> > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > potential
> > > > > to
> > > > > > > > break
> > > > > > > > > > > > >> Category B
> > > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > > development
> > > > > > > > > stream,
> > > > > > > > > > > and
> > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > maintainers
> > > > of
> > > > > > > > > Category B
> > > > > > > > > > > > >> repos,
> > > > > > > > > > > > >> > > > as historically Category A contributors were
> > not
> > > > > > > familiar
> > > > > > > > > with
> > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > > through
> > > > a
> > > > > > > GitHub
> > > > > > > > > > > Actions
> > > > > > > > > > > > >> > > > workflow that builds the relevant part of the
> > > > > > > `kie-tools`
> > > > > > > > > > > monorepo
> > > > > > > > > > > > >> for
> > > > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > > > pipeline
> > > > > > > > itself
> > > > > > > > > > are
> > > > > > > > > > > > also
> > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do
> > > things
> > > > > > like
> > > > > > > > > > > atomically
> > > > > > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > > > > > importantly,
> > > > > > > > > it
> > > > > > > > > > > > >> allows
> > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > timestamped
> > > > > > > SNAPSHOT
> > > > > > > > > > > > together
> > > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > > green.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This setup, however, makes it impossible to
> > have
> > > > > > > > cross-repo
> > > > > > > > > > PRs
> > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > simultaneously,
> > > > > > with
> > > > > > > > the
> > > > > > > > > > > > current
> > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category C repos are kind of floating around,
> > > and
> > > > > I'm
> > > > > > > not
> > > > > > > > > sure
> > > > > > > > > > > if
> > > > > > > > > > > > >> > > > there's much activity going on there.
> > > Regardless,
> > > > as
> > > > > > > > they're
> > > > > > > > > > > part
> > > > > > > > > > > > of
> > > > > > > > > > > > >> > > > Apache KIE, they will be part of our release,
> > > so I
> > > > > > > listed
> > > > > > > > > them
> > > > > > > > > > > for
> > > > > > > > > > > > >> us
> > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category D is self explanatory. There's only
> > one
> > > > > repo
> > > > > > > that
> > > > > > > > > has
> > > > > > > > > > > > >> already
> > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > > directly,
> > > > > > and
> > > > > > > > are
> > > > > > > > > > > > either
> > > > > > > > > > > > >> > > > organizational entities, or host websites,
> > that
> > > > > > > currently
> > > > > > > > > are
> > > > > > > > > > > not
> > > > > > > > > > > > >> part
> > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This lack of unification between Category A
> > and
> > > > > > > Category B
> > > > > > > > > is,
> > > > > > > > > > > > IMHO,
> > > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > > circular
> > > > > > > > > dependency
> > > > > > > > > > > > >> between
> > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now
> > can
> > > > > > describe
> > > > > > > > as
> > > > > > > > > a
> > > > > > > > > > > > >> circular
> > > > > > > > > > > > >> > > > dependency between Category A and Category B.
> > > The
> > > > > way
> > > > > > I
> > > > > > > > see
> > > > > > > > > > it,
> > > > > > > > > > > if
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > had a single pipeline, building everything
> > from
> > > > > > `drools`
> > > > > > > > to
> > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > > > introduced,
> > > > > > > > and
> > > > > > > > > we
> > > > > > > > > > > > >> > > > wouldn't be having this huge problem in our
> > > hands
> > > > > > right
> > > > > > > > now.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > My proposal for the Apache KIE release process
> > > > sees
> > > > > > this
> > > > > > > > > lack
> > > > > > > > > > of
> > > > > > > > > > > > >> > > > unification as a central problem, not only for
> > > > this
> > > > > > > > release
> > > > > > > > > in
> > > > > > > > > > > > >> > > > particular, but for the community as a whole.
> > It
> > > > is
> > > > > my
> > > > > > > > > belief
> > > > > > > > > > > that
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > contribution
> > > > > > > > should
> > > > > > > > > > be
> > > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> > With
> > > > the
> > > > > > > > > increasing
> > > > > > > > > > > > >> volume
> > > > > > > > > > > > >> > > > of code, and hopefully number of contributors
> > > too,
> > > > > we
> > > > > > > > cannot
> > > > > > > > > > > keep
> > > > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > > > things.
> > > > > > > We're
> > > > > > > > > all
> > > > > > > > > > > > >> humans
> > > > > > > > > > > > >> > > > after all, and it is our job to have
> > mechanisms
> > > in
> > > > > > place
> > > > > > > > to
> > > > > > > > > > > > prevent
> > > > > > > > > > > > >> us
> > > > > > > > > > > > >> > > > from unwillingly making mistakes. Especially
> > > when
> > > > > > these
> > > > > > > > > > mistakes
> > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > individually,
> > > > > > > > > > probably
> > > > > > > > > > > > >> can't
> > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending
> > on
> > > > > > > > kiegroup's
> > > > > > > > > > KIE
> > > > > > > > > > > > >> Tools
> > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > `kogito-images`
> > > > > > > > > depending
> > > > > > > > > > on
> > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > > kiegroup's
> > > > > > > > > `lienzo`
> > > > > > > > > > > and
> > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > `7.59.0.Final`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > depending
> > > on
> > > > > > > > > kiegroup's
> > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > codebase
> > > > > here:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > >
> > > > > > >
> > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > ,
> > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > OptaPlanner,
> > > > > > > > pointing
> > > > > > > > > to
> > > > > > > > > > > > older
> > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P5.
> > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > depending
> > > > > > > > on
> > > > > > > > > > > > Kogito
> > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P6. Category C repos are out of date and not
> > > part
> > > > of
> > > > > > the
> > > > > > > > > > > Category
> > > > > > > > > > > > A
> > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > > > version
> > > > > is
> > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > version,
> > > > only
> > > > > > by
> > > > > > > > > using
> > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version
> > is
> > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > OptaPlanner
> > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow
> > has
> > > > its
> > > > > > E2E
> > > > > > > > > > disabled
> > > > > > > > > > > > >> after
> > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > > solution,
> > > > > > as
> > > > > > > > they
> > > > > > > > > > > both
> > > > > > > > > > > > >> > > > suffer from the circular dependency between
> > > > > Category A
> > > > > > > and
> > > > > > > > > > > > Category
> > > > > > > > > > > > >> B.
> > > > > > > > > > > > >> > > > As Category A and Category B are both streams
> > > that
> > > > > > have
> > > > > > > > been
> > > > > > > > > > > > really
> > > > > > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > > > > > contributions
> > > > > > > > > > that
> > > > > > > > > > > > >> > > > cannot be done, given that Category A depends
> > on
> > > > > > > Category
> > > > > > > > B
> > > > > > > > > > > with a
> > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > understood
> > > > as
> > > > > > > > > technical
> > > > > > > > > > > > debt.
> > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > something
> > > > > we'll
> > > > > > > > always
> > > > > > > > > > be
> > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > > > matter
> > > > > of
> > > > > > > > > making
> > > > > > > > > > > them
> > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P7 is an isolated problem that won't impact
> > the
> > > > > > > structure
> > > > > > > > or
> > > > > > > > > > > > >> anything
> > > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > > regression
> > > > > > we
> > > > > > > > > > > > introduced
> > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache
> > KIE
> > > > 10,
> > > > > > and
> > > > > > > > > that
> > > > > > > > > > > P5,
> > > > > > > > > > > > >> P6,
> > > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems left
> > > to
> > > > > > > discuss
> > > > > > > > > are
> > > > > > > > > > P1
> > > > > > > > > > > > and
> > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > > proposal.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> > from
> > > my
> > > > > > > > > experience,
> > > > > > > > > > > any
> > > > > > > > > > > > >> > > > little miscalculation can lead to our release
> > > not
> > > > > > > working
> > > > > > > > > out
> > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > possible,
> > > > and
> > > > > > make
> > > > > > > > > > > > everything
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > release,
> > > > bear
> > > > > > > with
> > > > > > > > > me.
> > > > > > > > > > > I'll
> > > > > > > > > > > > >> lay
> > > > > > > > > > > > >> > > > out a timeline of events that need to happen
> > in
> > > > > order
> > > > > > > for
> > > > > > > > > our
> > > > > > > > > > > > >> release
> > > > > > > > > > > > >> > > > to be published, with all artifacts ending up
> > in
> > > > the
> > > > > > > right
> > > > > > > > > > > places,
> > > > > > > > > > > > >> but
> > > > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > As you saw at the beginning of this email, all
> > > the
> > > > > > > > attempts
> > > > > > > > > we
> > > > > > > > > > > > made
> > > > > > > > > > > > >> > > > left us with the circular dependency showing
> > up
> > > > at a
> > > > > > > > > different
> > > > > > > > > > > > >> place,
> > > > > > > > > > > > >> > > > but something all these places have in common
> > is
> > > > > that
> > > > > > > > > they're
> > > > > > > > > > > all
> > > > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > The first part of my proposal is the
> > following:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > > > Quarkus
> > > > > > Dev
> > > > > > > > UIs
> > > > > > > > > > from
> > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > > > Management
> > > > > > > and
> > > > > > > > > > Task
> > > > > > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > images
> > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > >> > > > S3. We move the entire
> > > > `kogito-serverless-operator`
> > > > > > repo
> > > > > > > > > > inside
> > > > > > > > > > > a
> > > > > > > > > > > > >> new
> > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> > problems
> > > > P1
> > > > > > and
> > > > > > > > P2.
> > > > > > > > > Of
> > > > > > > > > > > > >> course
> > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > >>
> > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This doesn't come without consequences, of
> > > course,
> > > > > as
> > > > > > > the
> > > > > > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> > > > > images,
> > > > > > > and
> > > > > > > > > the
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be moving
> > > from
> > > > > > > > Category A
> > > > > > > > > > to
> > > > > > > > > > > > >> > > > Category B. This move would make them have to
> > > > > > reference
> > > > > > > > > > > Category A
> > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > > `kogito-images`
> > > > > > > > > and
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` are already their
> > > own
> > > > > > > > > > "sub-stream"
> > > > > > > > > > > > >> inside
> > > > > > > > > > > > >> > > > Category A, though, contributions made in a
> > > > > cross-repo
> > > > > > > > > fashion
> > > > > > > > > > > to
> > > > > > > > > > > > >> this
> > > > > > > > > > > > >> > > > "sub-stream" will continue being possible, now
> > > > via a
> > > > > > > > single
> > > > > > > > > PR
> > > > > > > > > > > to
> > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A
> > > and
> > > > > > > > Category
> > > > > > > > > B
> > > > > > > > > > > will
> > > > > > > > > > > > >> > > > continue not being possible, and a 1-week
> > delay
> > > > > > between
> > > > > > > > > > merging
> > > > > > > > > > > > >> > > > something on Category A and using it on
> > > Category B
> > > > > > will
> > > > > > > > > still
> > > > > > > > > > > > >> happen.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> > however,
> > > > > does
> > > > > > > > allow
> > > > > > > > > > for
> > > > > > > > > > > > >> sparse
> > > > > > > > > > > > >> > > > checkouts and partial builds, so working with
> > a
> > > > > subset
> > > > > > > of
> > > > > > > > > the
> > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > >> > > > is possible and encouraged. Making changes
> > only
> > > to
> > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example,
> > will
> > > > > have
> > > > > > > the
> > > > > > > > PR
> > > > > > > > > > > > checks
> > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > >> > > > We're not compromising when running partial
> > > builds
> > > > > > too.
> > > > > > > We
> > > > > > > > > > know
> > > > > > > > > > > > that
> > > > > > > > > > > > >> > > > the entire repo will continue working even
> > after
> > > > > only
> > > > > > > > > > building a
> > > > > > > > > > > > >> small
> > > > > > > > > > > > >> > > > subset of the changes. Doing partial or full
> > > > builds
> > > > > is
> > > > > > > > > > > > automatically
> > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Keep in mind that, even though I'm proposing
> > we
> > > > > move a
> > > > > > > > bunch
> > > > > > > > > > of
> > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see this
> > > as a
> > > > > > > > TEMPORARY
> > > > > > > > > > > > >> solution
> > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > > > > > additional
> > > > > > > > > stuff
> > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > continue
> > > > > moving
> > > > > > > > > > forward.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> > > > became a
> > > > > > > > > polyglot
> > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > >> > > > out of necessity, and although I'm really
> > proud
> > > of
> > > > > > what
> > > > > > > we
> > > > > > > > > > > > achieved
> > > > > > > > > > > > >> > > > there so far, I don't think `kie-tools` has a
> > > > setup
> > > > > > that
> > > > > > > > is
> > > > > > > > > > > > suitable
> > > > > > > > > > > > >> > > > for all the different nuances that compose our
> > > > > > > community.
> > > > > > > > > I'm
> > > > > > > > > > > well
> > > > > > > > > > > > >> > > > aware that a polyglot monorepo that does not
> > > > follow
> > > > > > > > > widespread
> > > > > > > > > > > > >> > > > conventions will scare some people away, and
> > as
> > > > much
> > > > > > as
> > > > > > > > > we've
> > > > > > > > > > > > tried
> > > > > > > > > > > > >> to
> > > > > > > > > > > > >> > > > make build instructions clear, we can't always
> > > get
> > > > > > past
> > > > > > > > the
> > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > > ecosystem.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > With all that said, I keep thinking this is
> > the
> > > > best
> > > > > > > > course
> > > > > > > > > of
> > > > > > > > > > > > >> action
> > > > > > > > > > > > >> > > > for us right now. We keep most of our stuff
> > > > > unchanged,
> > > > > > > we
> > > > > > > > > > > unblock
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> > > > release, and we have a working setup that will
> > > > suit
> > > > > us
> > > > > > > > well
> > > > > > > > > > > while
> > > > > > > > > > > > we
> > > > > > > > > > > > >> > > > discuss and reach a conclusion regarding the
> > > > future
> > > > > of
> > > > > > > our
> > > > > > > > > > > > codebase
> > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Let me paint a quick picture here of what our
> > > code
> > > > > > base
> > > > > > > > > would
> > > > > > > > > > > look
> > > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > > accepted:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > >> > > > A
> > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > B
> > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > > >> > > > E
> > incubator-kie-kogito-online-staging
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves entirely
> > > inside
> > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images
> > and
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > `kie-tools`,
> > > > > there
> > > > > > > are
> > > > > > > > > no
> > > > > > > > > > > > cycles
> > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > granularly
> > > > > > build:
> > > > > > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > >> and
> > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator (contents
> > > from
> > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > The second part of the proposal is the release
> > > > > process
> > > > > > > > > itself,
> > > > > > > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as
> > > > > cutting
> > > > > > > > point
> > > > > > > > > > for
> > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > >> > > > 2. Update Category B repos to point to this
> > > > > > timestamped
> > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > >> and
> > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > >> > > > 3. At this point, with everything working, we
> > > can
> > > > > > branch
> > > > > > > > out
> > > > > > > > > > to
> > > > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> > > SNAPSHOT
> > > > > > tag,
> > > > > > > > and
> > > > > > > > > > > > >> Category B
> > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > >> > > > 4. All Category A and Category B repos update
> > > > their
> > > > > > > > versions
> > > > > > > > > > to
> > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > Category
> > > A
> > > > > > repos
> > > > > > > > > using
> > > > > > > > > > > the
> > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > >> > > > 6. At this point, we can vote on the release
> > > based
> > > > > on
> > > > > > > the
> > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > >> > > > branches, given we don't expect any code
> > changes
> > > > > > > anymore.
> > > > > > > > > > > > >> > > > 7. After voting passes, we're good to start
> > the
> > > > > > release
> > > > > > > > > > process.
> > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > manual/automated
> > > > > > > release
> > > > > > > > > > > process,
> > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed
> > to
> > > > Git,
> > > > > > and
> > > > > > > > > built
> > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > artifacts
> > > > to
> > > > > be
> > > > > > > > > > > propagated
> > > > > > > > > > > > on
> > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > manual/automated
> > > > > > > release
> > > > > > > > > > > > process,
> > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed
> > to
> > > > Git,
> > > > > > and
> > > > > > > > > built
> > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > >> > > > 12. Category E repos can be manually tagged
> > with
> > > > > > 10.0.0
> > > > > > > > from
> > > > > > > > > > > their
> > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > More needs to be discussed if we're planning
> > to
> > > > > > maintain
> > > > > > > > > > > multiple
> > > > > > > > > > > > >> > > > release streams in parallel, but I guess it
> > can
> > > > wait
> > > > > > for
> > > > > > > > > after
> > > > > > > > > > > > >> Apache
> > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking forward
> > > to
> > > > > > > hearing
> > > > > > > > > back
> > > > > > > > > > > > from
> > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Of course, alternative solutions are possible.
> > > > This
> > > > > > > email,
> > > > > > > > > > > > however,
> > > > > > > > > > > > >> > > > summarizes my view of how we should attack the
> > > > > > problem,
> > > > > > > > > > > > considering
> > > > > > > > > > > > >> > > > disruption, required effort, the release
> > process
> > > > > > itself,
> > > > > > > > and
> > > > > > > > > > > > >> history.
> > > > > > > > > > > > >> > > > Feel free to propose alternatives. This is
> > not a
> > > > > > voting
> > > > > > > > > > thread.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >>
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
@Ricardo Zanini <za...@redhat.com> The main issue I have is why we
conclude 1 takes less time than 2?. If I understood 1) completely, it also
requires CI adjustments (at tools repo level, not at overall stream level),
so I hardly see the estimation different for someone that is familiar with
CI.
On Wed, Mar 13, 2024 at 2:14 PM ricardo zanini fernandes <
ricardozanini@gmail.com> wrote:
> Hi!
>
> Clearly, you all understand that moving images and the operator to
> kie-tools is a workaround and wrong in all possible scenarios, right? We
> won't undo once we merge. I'm pretty positive that once we have a release
> train going people will add all the obstacles they can add saying "It's
> working, let's not change it".
>
> Also, I understand that we need to unblock the release. We can compromise
> in COPYING the code, do the release, and then make the necessary changes.
> Images and cloud code are *integration platforms*. Should be the last in a
> stream. Tooling SHOULD NOT, in any case, depend on the images to build.
>
> So we can:
>
> 1. Accept Tiago's proposal (very well detailed, thanks!) but COPYING the
> code base, not MERGING. The contributions still flow to the right repos.
> 2. After release we:
> 1. Move the CLI to the operator repo, removing this dependency from
> tools to image
> 2. Adjust the CI
> 3. Remove the copied code
>
> Moving forward, I'd like to see a clear boundary between the projects (as
> stated in the temporary website). At the moment, we do not have. And it's
> hard for anyone from outside to understand what we are doing.
>
> On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me> wrote:
>
> > Francisco and Gabriele,
> >
> > I understand and acknowledge your desire to find the “right” solution
> > instead to work on a temporary “patch” - however without a detailed
> > proposal I don’t think we can properly evaluate the impact of your
> > suggestion.
> >
> > When I spoke with different SMEs that included tools and CI, the
> > guesstimate for making the necessary changes on CI and codebase to
> > basically have images and operators in the end of the build chain is
> > something like 2 months of effort. Another impact that needs to be
> > discussed is that KIE Tools repo had to be injected in the middle of all
> > pipelines - forcing all PR checks and nightlies to build all repos (PR
> > checks will likely take 12+ hours… I even heard that it could be even 24
> > hours).
> >
> > Based on the input above, I think it’s quite risk to move in such
> direction
> > without a more detailed plan… because 2 months could be turned easily in
> 6!
> > And this is exactly what happened when we guessed that moving to Apache
> > would take no more than 3 months. But here we are.
> >
> > I really strongly suggest that we focus on a release that could be
> > achievable in less than a month from now, and we - after release - have a
> > in depth discussion about the overall codebase and ci organization.
> >
> >
> > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > gabriele.cardosi@gmail.com>
> > wrote:
> >
> > > Alex,
> > > my suggestion is to move the building of all docker images, from
> whatever
> > > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > > invoked after all the others.
> > > I'm not sure if this would solve all the issues, and since I could not
> > > enter in the details of all the involved code, my suggestion may be too
> > > naive.
> > > Having spent almost all of the last year in CI, I may say that, at
> least
> > > for the kie-tools repo, removing the image build step from it should
> not
> > be
> > > too difficult (since it is an issue we already faced and solved).
> > > If, with "detailed proposal", you mean a complete list of all modules
> to
> > be
> > > moved and dependency refactoring, of course I can not provide it right
> > now.
> > >
> > > Anyway, I share the concern from Francisco: undoing something is almost
> > > always harder than doing it "rightly" from scratch...
> > >
> > >
> > >
> > >
> > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti
> <
> > > ftirados@redhat.com> ha scritto:
> > >
> > > > I do not think estimations should be the only driver to make a
> > decision,
> > > > especially when the current proposal is conceptually incompatible
> with
> > > the
> > > > multi repo approach that is taken elsewhere in the project.
> > > > Given my knowledge of the CI it is nearly impossible for me to give
> a
> > > fair
> > > > estimate of how much it might take to achieve step 2) of my previous
> > > e-mail
> > > > . It might take a while or it might be pretty easy after all, I don't
> > > > really know, but I think it will be a good idea if some of the
> experts
> > > on
> > > > CI in the team (the ones that set up the pipeline, which was a huge
> > > > achievement) give an estimate, not me. Estimating how much it takes
> to
> > > > merge two existing repos (without altering CI) is easier, but it does
> > not
> > > > mean we are doing the right thing.
> > > > My main concern is that it will be very difficult for me to explain
> to
> > > > someone that arrives new to the team, that having experts on CI on
> the
> > > > team, we decided to merge two repos (once merged, it would be rather
> > > > difficult to unmerge) rather than fix the CI, because of expediency.
> > > >
> > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> > > > wrote:
> > > >
> > > > > Francisco,
> > > > >
> > > > > Please take the time to make the more in depth analysis needed and
> > > > provide
> > > > > a more detailed plan… so we - as community- can evaluate the size
> of
> > > the
> > > > > effort. In the conceptual level you shared it’s near impossible to
> > > > estimate
> > > > > the size of the effort and compare with the current proposal.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > ftirados@redhat.com> wrote:
> > > > >
> > > > > > I think I already did a high level proposal.
> > > > > > 1) Remove all dependencies from tooling to images, so images
> > depend
> > > on
> > > > > > tooling but tooling does not depend on images.
> > > > > > 2) Then change CI to deal with tooling repo before dealing with
> > > images
> > > > > > repo.
> > > > > > I understand that CI details are tricky and since I'm not
> familiar
> > > with
> > > > > CI
> > > > > > in any way, I barely can make a low level design, but we do not
> > need
> > > to
> > > > > fix
> > > > > > everything, just achieve 2), a change of compilation order.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <alex@porcelli.me
> >
> > > > wrote:
> > > > > >
> > > > > > > Francisco and Grabriele,
> > > > > > >
> > > > > > > You may not like or understand why the current state of the CI
> is
> > > > like
> > > > > > > that… actually has been in Red Hat and has been replicated in
> > > Apache
> > > > as
> > > > > > > used to be….
> > > > > > >
> > > > > > > But the fact is that this is the current reality.
> > > > > > >
> > > > > > > If you disagree with the current plan, please provide a
> detailed
> > > > > > > alternative so we, as community, can better evaluate the pros
> and
> > > > cons
> > > > > of
> > > > > > > each proposal.
> > > > > > >
> > > > > > >
> > > > > > > I think it’s also fair to say that, post 10 release we need to
> > > have a
> > > > > > much
> > > > > > > in depth discussion about how our codebase is organized, it’s
> > clear
> > > > > that
> > > > > > > it’s not working.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > As Francisco said,
> > > > > > > > I also have the impression that the "images" (if we are
> talking
> > > of
> > > > > > docker
> > > > > > > > images) should be the very last one to be built, in a
> > standalone
> > > > > repo.
> > > > > > > > That way, they may "combine" artifacts that are built in
> > > different
> > > > > > repos,
> > > > > > > > regardless of the order in which those are built.
> > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> maybe
> > > > could
> > > > > > > > simplify the situation a bit.
> > > > > > > > (I also think there are some statements of undisputable needs
> > > while
> > > > > > they
> > > > > > > > are, actually, just technical choices.
> > > > > > > > Anyway, this latter point is for longer, following,
> > discussion.)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > Tirado
> > > > > Sarti
> > > > > > <
> > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > >
> > > > > > > > > Alex,
> > > > > > > > > There are two assumptions that deserve further discussion:
> > > > > > > > > 1) That tool has to be the last to build. why? it does not
> > have
> > > > > more
> > > > > > > > sense
> > > > > > > > > to build final images after everything else has been
> built?-
> > > > > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> > > > bigger
> > > > > > than
> > > > > > > > the
> > > > > > > > > impact (long term consequences) of consolidating two
> > unrelated
> > > > > piece
> > > > > > of
> > > > > > > > > software within the same repository.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > alex@porcelli.me
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco,
> > > > > > > > > >
> > > > > > > > > > This was discussed as an alternative solution, however it
> > has
> > > > > major
> > > > > > > > > impact
> > > > > > > > > > on CI and there’s also the fact Tool has been always the
> > last
> > > > to
> > > > > > > build
> > > > > > > > > and
> > > > > > > > > > has no Snapshot published (actually in JavaScript world
> > there
> > > > is
> > > > > no
> > > > > > > > > > snapshot concept).
> > > > > > > > > >
> > > > > > > > > > So, based on our evaluation… the proposal here is the
> least
> > > > > > > disruptive
> > > > > > > > > and
> > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > _____________
> > > > > > > > > > Alex Porcelli
> > > > > > > > > > http://porcelli.me
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > > Sarti <
> > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > After kie-tools, sorry. I think we are not embracing
> the
> > > fact
> > > > > > that
> > > > > > > > > > > kogito-images depend on kie-tools, because we want
> those
> > > > images
> > > > > > to
> > > > > > > > > > include
> > > > > > > > > > > tools.
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> Tirado
> > > > Sarti
> > > > > <
> > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > It can be an alternative solution to move
> > > > kn-plugin-workflow
> > > > > to
> > > > > > > > > > > > kogito-images (so there is not longer dependency from
> > > tools
> > > > > to
> > > > > > > > > images)
> > > > > > > > > > > and
> > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > Martinez
> > > > <
> > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > >>
> > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache)
> <
> > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > >> escribió:
> > > > > > > > > > > >>
> > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > alex@porcelli.me
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > > +1
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > I spent the last day or so working closely with
> > > Tiago,
> > > > > > > > exploring
> > > > > > > > > > > >> > different
> > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > evaluating
> > > > > > the
> > > > > > > > > > overall
> > > > > > > > > > > >> > release
> > > > > > > > > > > >> > > procedure steps required. I agree with the
> > proposal
> > > as
> > > > > the
> > > > > > > > most
> > > > > > > > > > > >> > > viable option for unblocking the 10 release in
> the
> > > > > > > reasonable
> > > > > > > > > time
> > > > > > > > > > > >> frame.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > >> > wrote:
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time,
> as
> > > this
> > > > > > > matter
> > > > > > > > > > > >> requires a
> > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > > > > according
> > > > > > > to
> > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > > > > >> > > > (
> > > > > > > > > >
> > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > ),
> > > > > > > > > > > >> > > > many of us were working towards removing a
> > > circular
> > > > > > > > dependency
> > > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > > `kie-tools`.
> > > > > > > As
> > > > > > > > we
> > > > > > > > > > > >> > > > progressed towards a solution, we kept finding
> > the
> > > > > > > circular
> > > > > > > > > > > >> dependency
> > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of
> > the
> > > > > things
> > > > > > > we
> > > > > > > > > did,
> > > > > > > > > > > and
> > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Right now, even though we started the effort
> to
> > > move
> > > > > the
> > > > > > > > > Quarkus
> > > > > > > > > > > Dev
> > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> able
> > to
> > > > do
> > > > > it
> > > > > > > > yet,
> > > > > > > > > as
> > > > > > > > > > > >> we've
> > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> Maven
> > > > 3.9.6,
> > > > > > and
> > > > > > > > > > Quarkus
> > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > This
> > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > >> > > >
> > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > .
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > C | 03.
> incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > Y | 04.
> incubator-kie-kogito-images
> > > > > > > > > > > >> > > > C | 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > >> > > > E | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > >> > > > * and
> > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > depend
> > > > > > > > > > > >> on
> > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> `kie-tools`,
> > > we
> > > > > > > would've
> > > > > > > > > > had:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > > >> > > > Y | 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > >> > > > L | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > >> > > > * and
> `kogito-images`/kogito-swf-devmode
> > > > > depends
> > > > > > > on
> > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > > > > `kie-tools`,
> > > > > > > > we
> > > > > > > > > > > >> would've
> > > > > > > > > > > >> > > > had:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > 04.
> incubator-kie-kogito-images
> > > > > > > > > > > >> > > > C |==> 05.
> > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > >> > > > C | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > > E
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > depends
> > > > on
> > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Clearly, we have a much bigger problem than a
> > > simple
> > > > > > > > circular
> > > > > > > > > > > >> > dependency.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > people,
> > > > > it's
> > > > > > > been
> > > > > > > > > > > really
> > > > > > > > > > > >> > > > hard coming up with a simple solution that
> makes
> > > it
> > > > > > > possible
> > > > > > > > > to
> > > > > > > > > > > >> build
> > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving the
> way
> > > > > > everyone
> > > > > > > is
> > > > > > > > > > used
> > > > > > > > > > > to
> > > > > > > > > > > >> > > > contributing to the multiple repositories we
> > have.
> > > > > More
> > > > > > > than
> > > > > > > > > > that,
> > > > > > > > > > > >> > > > while making this assessment, I found more
> > > problems
> > > > > > that,
> > > > > > > in
> > > > > > > > > my
> > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> forward
> > > with
> > > > > my
> > > > > > > > > proposal
> > > > > > > > > > > for
> > > > > > > > > > > >> > > > the Apache KIE release process, so we can use
> > > > Apache's
> > > > > > > > > > mechanisms
> > > > > > > > > > > to
> > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> this
> > > > really
> > > > > > > > > > complicated
> > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > > current
> > > > > > > > situation
> > > > > > > > > > of
> > > > > > > > > > > >> our
> > > > > > > > > > > >> > > > codebase, as well as problems I can currently
> > see.
> > > > > I'll
> > > > > > > > start
> > > > > > > > > > with
> > > > > > > > > > > >> an
> > > > > > > > > > > >> > > > analysis of the repositories and their
> purposes,
> > > > point
> > > > > > out
> > > > > > > > > some
> > > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > > release,
> > > > > > > explain
> > > > > > > > > my
> > > > > > > > > > > >> > > > proposal and discuss some consequences to what
> > I'm
> > > > > > > > proposing.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > > `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> > > > `0.0.0`
> > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > >> > > > (Issues only, README should be updated @
> > > `main`.
> > > > > > Same
> > > > > > > > for
> > > > > > > > > > > GitHub
> > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy at
> the
> > > > > `main`
> > > > > > > > > branch.)
> > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > > > > `deploy`
> > > > > > to
> > > > > > > > > > update
> > > > > > > > > > > >> the
> > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > >> > > > (GitHub pages used to host
> sandbox.kie.org
> > > and
> > > > > KIE
> > > > > > > > Tools'
> > > > > > > > > > > >> Chrome
> > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> checks
> > > > > during
> > > > > > > the
> > > > > > > > > > > staging
> > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I grouped the repositories by category, and
> > listed
> > > > > them
> > > > > > > in a
> > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > flattening
> > > > > > out a
> > > > > > > > > tree,
> > > > > > > > > > > >> there
> > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > OptaPlanner
> > > > > > > > could've
> > > > > > > > > > been
> > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category A repos are what I've been referring
> to
> > > as
> > > > > > > `drools`
> > > > > > > > > and
> > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is
> > inside
> > > > > that
> > > > > > > > > stream,
> > > > > > > > > > as
> > > > > > > > > > > >> the
> > > > > > > > > > > >> > > > way these repositories reference each other
> are
> > > > > through
> > > > > > > > Maven
> > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > > > > version.
> > > > > > > This
> > > > > > > > > > > >> mechanism
> > > > > > > > > > > >> > > > is well-known to the team, and although flawed
> > for
> > > > > > > intra-day
> > > > > > > > > > > builds
> > > > > > > > > > > >> > > > and disruptive for people in many different
> time
> > > > > zones,
> > > > > > it
> > > > > > > > is
> > > > > > > > > > > >> already
> > > > > > > > > > > >> > > > very comfortable for everyone to work with, I
> > > > assume.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > dedicated
> > > > > > > > > pipelines,
> > > > > > > > > > > >> which
> > > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > > cross-repo
> > > > > > PRs
> > > > > > > > > > > together
> > > > > > > > > > > >> > > > and verify that the codebase will continue
> > working
> > > > as
> > > > > > > > expected
> > > > > > > > > > > after
> > > > > > > > > > > >> > > > they're all merged. From what I could gather,
> > > there
> > > > > are
> > > > > > > some
> > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > cross-repo
> > > > PRs.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > > kogito-examples
> > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > >> > > > - kogito-images, and
> kogito-serverless-operator
> > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > > > > combination
> > > > > > > of
> > > > > > > > > > repos
> > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > cannot
> > > be
> > > > > > > > verified
> > > > > > > > > > > before
> > > > > > > > > > > >> > > > merging, making our contribution model
> dependent
> > > on
> > > > > > > > individual
> > > > > > > > > > > >> > > > contributors building stuff on their machines
> to
> > > > > verify
> > > > > > > that
> > > > > > > > > it
> > > > > > > > > > > >> works.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > >> > > > ,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > >> > > > ,
> > > > > > > > > > > >> > > > and
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > >> > > > .
> > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > pipelines,
> > > > > so
> > > > > > > > > please
> > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category B repos are what I've been referring
> to
> > > as
> > > > > > > > > `kie-tools`
> > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > repository
> > > > > > that
> > > > > > > > is
> > > > > > > > > > used
> > > > > > > > > > > >> by
> > > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > > Sandbox,
> > > > > > > > similar
> > > > > > > > > > to a
> > > > > > > > > > > >> > > > Maven archetype, if you will. The other one is
> > the
> > > > KIE
> > > > > > > Tools
> > > > > > > > > > > >> monorepo,
> > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > > system.
> > > > > > > > > Currently,
> > > > > > > > > > > KIE
> > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> TypeScript
> > > > > > libraries
> > > > > > > > and
> > > > > > > > > > > apps,
> > > > > > > > > > > >> Go
> > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > `kie-tools`
> > > > > > > > monorepo
> > > > > > > > > > is
> > > > > > > > > > > >> > > > configured to work with sparse checkouts and
> can
> > > do
> > > > > > > partial
> > > > > > > > > > > builds.
> > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > through
> > > > > > > > timestamped
> > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > > > > introduced
> > > > > > > > that
> > > > > > > > > > > will
> > > > > > > > > > > >> > > > build and publish immutable, persistent
> > artifacts
> > > > > under
> > > > > > a
> > > > > > > > > > version
> > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > > published
> > > > > > > weekly
> > > > > > > > > > every
> > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > evolution
> > > > > to
> > > > > > > the
> > > > > > > > > > Kogito
> > > > > > > > > > > >> > > > releases, as we're now targeting one release
> for
> > > all
> > > > > of
> > > > > > > > Apache
> > > > > > > > > > > KIE,
> > > > > > > > > > > >> so
> > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > An important note here is that Category B
> > > > repositories
> > > > > > > have
> > > > > > > > > been
> > > > > > > > > > > >> > > > historically kept out of any automations we
> used
> > > to
> > > > > > have,
> > > > > > > > way
> > > > > > > > > > back
> > > > > > > > > > > >> > > > when Kogito started and we had the Business
> > > Central
> > > > > > > (a.k.a.
> > > > > > > > > v7)
> > > > > > > > > > > >> stream
> > > > > > > > > > > >> > > > still going on. For this reason, Category B
> > > projects
> > > > > > have
> > > > > > > > > > > developed
> > > > > > > > > > > >> > > > their own automations, based on GitHub
> Actions.
> > > > > > Category B
> > > > > > > > > repos
> > > > > > > > > > > >> have
> > > > > > > > > > > >> > > > always depended on Category A repos using
> fixed
> > > > > > versions.
> > > > > > > If
> > > > > > > > > > > >> Category
> > > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > > breaking
> > > > > > > changes
> > > > > > > > > on
> > > > > > > > > > > >> > > > Category A repositories would've had the
> > potential
> > > > to
> > > > > > > break
> > > > > > > > > > > >> Category B
> > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > development
> > > > > > > > stream,
> > > > > > > > > > and
> > > > > > > > > > > >> > > > introducing unpleasant surprises for
> maintainers
> > > of
> > > > > > > > Category B
> > > > > > > > > > > >> repos,
> > > > > > > > > > > >> > > > as historically Category A contributors were
> not
> > > > > > familiar
> > > > > > > > with
> > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > through
> > > a
> > > > > > GitHub
> > > > > > > > > > Actions
> > > > > > > > > > > >> > > > workflow that builds the relevant part of the
> > > > > > `kie-tools`
> > > > > > > > > > monorepo
> > > > > > > > > > > >> for
> > > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > > pipeline
> > > > > > > itself
> > > > > > > > > are
> > > > > > > > > > > also
> > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do
> > things
> > > > > like
> > > > > > > > > > atomically
> > > > > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > > > > importantly,
> > > > > > > > it
> > > > > > > > > > > >> allows
> > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > timestamped
> > > > > > SNAPSHOT
> > > > > > > > > > > together
> > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > green.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This setup, however, makes it impossible to
> have
> > > > > > > cross-repo
> > > > > > > > > PRs
> > > > > > > > > > > >> > > > involving Category A and Category B
> > > simultaneously,
> > > > > with
> > > > > > > the
> > > > > > > > > > > current
> > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category C repos are kind of floating around,
> > and
> > > > I'm
> > > > > > not
> > > > > > > > sure
> > > > > > > > > > if
> > > > > > > > > > > >> > > > there's much activity going on there.
> > Regardless,
> > > as
> > > > > > > they're
> > > > > > > > > > part
> > > > > > > > > > > of
> > > > > > > > > > > >> > > > Apache KIE, they will be part of our release,
> > so I
> > > > > > listed
> > > > > > > > them
> > > > > > > > > > for
> > > > > > > > > > > >> us
> > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category D is self explanatory. There's only
> one
> > > > repo
> > > > > > that
> > > > > > > > has
> > > > > > > > > > > >> already
> > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > directly,
> > > > > and
> > > > > > > are
> > > > > > > > > > > either
> > > > > > > > > > > >> > > > organizational entities, or host websites,
> that
> > > > > > currently
> > > > > > > > are
> > > > > > > > > > not
> > > > > > > > > > > >> part
> > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This lack of unification between Category A
> and
> > > > > > Category B
> > > > > > > > is,
> > > > > > > > > > > IMHO,
> > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > circular
> > > > > > > > dependency
> > > > > > > > > > > >> between
> > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now
> can
> > > > > describe
> > > > > > > as
> > > > > > > > a
> > > > > > > > > > > >> circular
> > > > > > > > > > > >> > > > dependency between Category A and Category B.
> > The
> > > > way
> > > > > I
> > > > > > > see
> > > > > > > > > it,
> > > > > > > > > > if
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > had a single pipeline, building everything
> from
> > > > > `drools`
> > > > > > > to
> > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > > introduced,
> > > > > > > and
> > > > > > > > we
> > > > > > > > > > > >> > > > wouldn't be having this huge problem in our
> > hands
> > > > > right
> > > > > > > now.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > My proposal for the Apache KIE release process
> > > sees
> > > > > this
> > > > > > > > lack
> > > > > > > > > of
> > > > > > > > > > > >> > > > unification as a central problem, not only for
> > > this
> > > > > > > release
> > > > > > > > in
> > > > > > > > > > > >> > > > particular, but for the community as a whole.
> It
> > > is
> > > > my
> > > > > > > > belief
> > > > > > > > > > that
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > contribution
> > > > > > > should
> > > > > > > > > be
> > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> With
> > > the
> > > > > > > > increasing
> > > > > > > > > > > >> volume
> > > > > > > > > > > >> > > > of code, and hopefully number of contributors
> > too,
> > > > we
> > > > > > > cannot
> > > > > > > > > > keep
> > > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > > things.
> > > > > > We're
> > > > > > > > all
> > > > > > > > > > > >> humans
> > > > > > > > > > > >> > > > after all, and it is our job to have
> mechanisms
> > in
> > > > > place
> > > > > > > to
> > > > > > > > > > > prevent
> > > > > > > > > > > >> us
> > > > > > > > > > > >> > > > from unwillingly making mistakes. Especially
> > when
> > > > > these
> > > > > > > > > mistakes
> > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > individually,
> > > > > > > > > probably
> > > > > > > > > > > >> can't
> > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending
> on
> > > > > > > kiegroup's
> > > > > > > > > KIE
> > > > > > > > > > > >> Tools
> > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > `kogito-images`
> > > > > > > > depending
> > > > > > > > > on
> > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > kiegroup's
> > > > > > > > `lienzo`
> > > > > > > > > > and
> > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> `7.59.0.Final`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> depending
> > on
> > > > > > > > kiegroup's
> > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > >> > > > * This module was removed from the KIE
> codebase
> > > > here:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > >> > > >
> > > > > > > > > > >
> > > > > >
> https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > ,
> > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > OptaPlanner,
> > > > > > > pointing
> > > > > > > > to
> > > > > > > > > > > older
> > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P5.
> `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > depending
> > > > > > > on
> > > > > > > > > > > Kogito
> > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P6. Category C repos are out of date and not
> > part
> > > of
> > > > > the
> > > > > > > > > > Category
> > > > > > > > > > > A
> > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > > version
> > > > is
> > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > >> > > > depending on Kogito without a specific
> version,
> > > only
> > > > > by
> > > > > > > > using
> > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version
> is
> > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> OptaPlanner
> > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow
> has
> > > its
> > > > > E2E
> > > > > > > > > disabled
> > > > > > > > > > > >> after
> > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > solution,
> > > > > as
> > > > > > > they
> > > > > > > > > > both
> > > > > > > > > > > >> > > > suffer from the circular dependency between
> > > > Category A
> > > > > > and
> > > > > > > > > > > Category
> > > > > > > > > > > >> B.
> > > > > > > > > > > >> > > > As Category A and Category B are both streams
> > that
> > > > > have
> > > > > > > been
> > > > > > > > > > > really
> > > > > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > > > > contributions
> > > > > > > > > that
> > > > > > > > > > > >> > > > cannot be done, given that Category A depends
> on
> > > > > > Category
> > > > > > > B
> > > > > > > > > > with a
> > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> understood
> > > as
> > > > > > > > technical
> > > > > > > > > > > debt.
> > > > > > > > > > > >> > > > Depending on unmaintained projects is
> something
> > > > we'll
> > > > > > > always
> > > > > > > > > be
> > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > > matter
> > > > of
> > > > > > > > making
> > > > > > > > > > them
> > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P7 is an isolated problem that won't impact
> the
> > > > > > structure
> > > > > > > or
> > > > > > > > > > > >> anything
> > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > regression
> > > > > we
> > > > > > > > > > > introduced
> > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache
> KIE
> > > 10,
> > > > > and
> > > > > > > > that
> > > > > > > > > > P5,
> > > > > > > > > > > >> P6,
> > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems left
> > to
> > > > > > discuss
> > > > > > > > are
> > > > > > > > > P1
> > > > > > > > > > > and
> > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > proposal.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> from
> > my
> > > > > > > > experience,
> > > > > > > > > > any
> > > > > > > > > > > >> > > > little miscalculation can lead to our release
> > not
> > > > > > working
> > > > > > > > out
> > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > >> > > > end. To try and avoid that as much as
> possible,
> > > and
> > > > > make
> > > > > > > > > > > everything
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> release,
> > > bear
> > > > > > with
> > > > > > > > me.
> > > > > > > > > > I'll
> > > > > > > > > > > >> lay
> > > > > > > > > > > >> > > > out a timeline of events that need to happen
> in
> > > > order
> > > > > > for
> > > > > > > > our
> > > > > > > > > > > >> release
> > > > > > > > > > > >> > > > to be published, with all artifacts ending up
> in
> > > the
> > > > > > right
> > > > > > > > > > places,
> > > > > > > > > > > >> but
> > > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As you saw at the beginning of this email, all
> > the
> > > > > > > attempts
> > > > > > > > we
> > > > > > > > > > > made
> > > > > > > > > > > >> > > > left us with the circular dependency showing
> up
> > > at a
> > > > > > > > different
> > > > > > > > > > > >> place,
> > > > > > > > > > > >> > > > but something all these places have in common
> is
> > > > that
> > > > > > > > they're
> > > > > > > > > > all
> > > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > The first part of my proposal is the
> following:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > > Quarkus
> > > > > Dev
> > > > > > > UIs
> > > > > > > > > from
> > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > > Management
> > > > > > and
> > > > > > > > > Task
> > > > > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > images
> > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > >> > > > S3. We move the entire
> > > `kogito-serverless-operator`
> > > > > repo
> > > > > > > > > inside
> > > > > > > > > > a
> > > > > > > > > > > >> new
> > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> problems
> > > P1
> > > > > and
> > > > > > > P2.
> > > > > > > > Of
> > > > > > > > > > > >> course
> > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > >>
> > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This doesn't come without consequences, of
> > course,
> > > > as
> > > > > > the
> > > > > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> > > > images,
> > > > > > and
> > > > > > > > the
> > > > > > > > > > > >> > > > `kogito-serverless-operator` would be moving
> > from
> > > > > > > Category A
> > > > > > > > > to
> > > > > > > > > > > >> > > > Category B. This move would make them have to
> > > > > reference
> > > > > > > > > > Category A
> > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > `kogito-images`
> > > > > > > > and
> > > > > > > > > > > >> > > > `kogito-serverless-operator` are already their
> > own
> > > > > > > > > "sub-stream"
> > > > > > > > > > > >> inside
> > > > > > > > > > > >> > > > Category A, though, contributions made in a
> > > > cross-repo
> > > > > > > > fashion
> > > > > > > > > > to
> > > > > > > > > > > >> this
> > > > > > > > > > > >> > > > "sub-stream" will continue being possible, now
> > > via a
> > > > > > > single
> > > > > > > > PR
> > > > > > > > > > to
> > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A
> > and
> > > > > > > Category
> > > > > > > > B
> > > > > > > > > > will
> > > > > > > > > > > >> > > > continue not being possible, and a 1-week
> delay
> > > > > between
> > > > > > > > > merging
> > > > > > > > > > > >> > > > something on Category A and using it on
> > Category B
> > > > > will
> > > > > > > > still
> > > > > > > > > > > >> happen.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> however,
> > > > does
> > > > > > > allow
> > > > > > > > > for
> > > > > > > > > > > >> sparse
> > > > > > > > > > > >> > > > checkouts and partial builds, so working with
> a
> > > > subset
> > > > > > of
> > > > > > > > the
> > > > > > > > > > > >> monorepo
> > > > > > > > > > > >> > > > is possible and encouraged. Making changes
> only
> > to
> > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example,
> will
> > > > have
> > > > > > the
> > > > > > > PR
> > > > > > > > > > > checks
> > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > >> > > > .
> > > > > > > > > > > >> > > > We're not compromising when running partial
> > builds
> > > > > too.
> > > > > > We
> > > > > > > > > know
> > > > > > > > > > > that
> > > > > > > > > > > >> > > > the entire repo will continue working even
> after
> > > > only
> > > > > > > > > building a
> > > > > > > > > > > >> small
> > > > > > > > > > > >> > > > subset of the changes. Doing partial or full
> > > builds
> > > > is
> > > > > > > > > > > automatically
> > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Keep in mind that, even though I'm proposing
> we
> > > > move a
> > > > > > > bunch
> > > > > > > > > of
> > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see this
> > as a
> > > > > > > TEMPORARY
> > > > > > > > > > > >> solution
> > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > > > > additional
> > > > > > > > stuff
> > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> continue
> > > > moving
> > > > > > > > > forward.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> > > became a
> > > > > > > > polyglot
> > > > > > > > > > > >> monorepo
> > > > > > > > > > > >> > > > out of necessity, and although I'm really
> proud
> > of
> > > > > what
> > > > > > we
> > > > > > > > > > > achieved
> > > > > > > > > > > >> > > > there so far, I don't think `kie-tools` has a
> > > setup
> > > > > that
> > > > > > > is
> > > > > > > > > > > suitable
> > > > > > > > > > > >> > > > for all the different nuances that compose our
> > > > > > community.
> > > > > > > > I'm
> > > > > > > > > > well
> > > > > > > > > > > >> > > > aware that a polyglot monorepo that does not
> > > follow
> > > > > > > > widespread
> > > > > > > > > > > >> > > > conventions will scare some people away, and
> as
> > > much
> > > > > as
> > > > > > > > we've
> > > > > > > > > > > tried
> > > > > > > > > > > >> to
> > > > > > > > > > > >> > > > make build instructions clear, we can't always
> > get
> > > > > past
> > > > > > > the
> > > > > > > > > > > >> prejudice
> > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > ecosystem.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > With all that said, I keep thinking this is
> the
> > > best
> > > > > > > course
> > > > > > > > of
> > > > > > > > > > > >> action
> > > > > > > > > > > >> > > > for us right now. We keep most of our stuff
> > > > unchanged,
> > > > > > we
> > > > > > > > > > unblock
> > > > > > > > > > > >> the
> > > > > > > > > > > >> > > > release, and we have a working setup that will
> > > suit
> > > > us
> > > > > > > well
> > > > > > > > > > while
> > > > > > > > > > > we
> > > > > > > > > > > >> > > > discuss and reach a conclusion regarding the
> > > future
> > > > of
> > > > > > our
> > > > > > > > > > > codebase
> > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Let me paint a quick picture here of what our
> > code
> > > > > base
> > > > > > > > would
> > > > > > > > > > look
> > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > accepted:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > >> > > > A
> > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > B
> > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > >> > > > E
> incubator-kie-kogito-online-staging
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > > > > >> > > > `kogito-serverless-operator` moves entirely
> > inside
> > > > > > > > > `kie-tools`.
> > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images
> and
> > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> `kie-tools`,
> > > > there
> > > > > > are
> > > > > > > > no
> > > > > > > > > > > cycles
> > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > granularly
> > > > > build:
> > > > > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > >> and
> > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > >> > > > 4. packages/sonataflow-operator (contents
> > from
> > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > The second part of the proposal is the release
> > > > process
> > > > > > > > itself,
> > > > > > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as
> > > > cutting
> > > > > > > point
> > > > > > > > > for
> > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > >> > > > 2. Update Category B repos to point to this
> > > > > timestamped
> > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > >> and
> > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > >> > > > 3. At this point, with everything working, we
> > can
> > > > > branch
> > > > > > > out
> > > > > > > > > to
> > > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> > SNAPSHOT
> > > > > tag,
> > > > > > > and
> > > > > > > > > > > >> Category B
> > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > >> > > > 4. All Category A and Category B repos update
> > > their
> > > > > > > versions
> > > > > > > > > to
> > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> Category
> > A
> > > > > repos
> > > > > > > > using
> > > > > > > > > > the
> > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > >> > > > 6. At this point, we can vote on the release
> > based
> > > > on
> > > > > > the
> > > > > > > > > > `10.0.x`
> > > > > > > > > > > >> > > > branches, given we don't expect any code
> changes
> > > > > > anymore.
> > > > > > > > > > > >> > > > 7. After voting passes, we're good to start
> the
> > > > > release
> > > > > > > > > process.
> > > > > > > > > > > >> > > > 8. Category A repos follow their
> > manual/automated
> > > > > > release
> > > > > > > > > > process,
> > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed
> to
> > > Git,
> > > > > and
> > > > > > > > built
> > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> artifacts
> > > to
> > > > be
> > > > > > > > > > propagated
> > > > > > > > > > > on
> > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > >> > > > 10. Category B repos follow their
> > manual/automated
> > > > > > release
> > > > > > > > > > > process,
> > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed
> to
> > > Git,
> > > > > and
> > > > > > > > built
> > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > >> > > > 12. Category E repos can be manually tagged
> with
> > > > > 10.0.0
> > > > > > > from
> > > > > > > > > > their
> > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > More needs to be discussed if we're planning
> to
> > > > > maintain
> > > > > > > > > > multiple
> > > > > > > > > > > >> > > > release streams in parallel, but I guess it
> can
> > > wait
> > > > > for
> > > > > > > > after
> > > > > > > > > > > >> Apache
> > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Thank you for reading, and I'm looking forward
> > to
> > > > > > hearing
> > > > > > > > back
> > > > > > > > > > > from
> > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Of course, alternative solutions are possible.
> > > This
> > > > > > email,
> > > > > > > > > > > however,
> > > > > > > > > > > >> > > > summarizes my view of how we should attack the
> > > > > problem,
> > > > > > > > > > > considering
> > > > > > > > > > > >> > > > disruption, required effort, the release
> process
> > > > > itself,
> > > > > > > and
> > > > > > > > > > > >> history.
> > > > > > > > > > > >> > > > Feel free to propose alternatives. This is
> not a
> > > > > voting
> > > > > > > > > thread.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >>
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > dev-help@kie.apache.org
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by ricardo zanini fernandes <ri...@gmail.com>.
Hi!
Clearly, you all understand that moving images and the operator to
kie-tools is a workaround and wrong in all possible scenarios, right? We
won't undo once we merge. I'm pretty positive that once we have a release
train going people will add all the obstacles they can add saying "It's
working, let's not change it".
Also, I understand that we need to unblock the release. We can compromise
in COPYING the code, do the release, and then make the necessary changes.
Images and cloud code are *integration platforms*. Should be the last in a
stream. Tooling SHOULD NOT, in any case, depend on the images to build.
So we can:
1. Accept Tiago's proposal (very well detailed, thanks!) but COPYING the
code base, not MERGING. The contributions still flow to the right repos.
2. After release we:
1. Move the CLI to the operator repo, removing this dependency from
tools to image
2. Adjust the CI
3. Remove the copied code
Moving forward, I'd like to see a clear boundary between the projects (as
stated in the temporary website). At the moment, we do not have. And it's
hard for anyone from outside to understand what we are doing.
On Wed, Mar 13, 2024 at 9:37 AM Alex Porcelli <al...@porcelli.me> wrote:
> Francisco and Gabriele,
>
> I understand and acknowledge your desire to find the “right” solution
> instead to work on a temporary “patch” - however without a detailed
> proposal I don’t think we can properly evaluate the impact of your
> suggestion.
>
> When I spoke with different SMEs that included tools and CI, the
> guesstimate for making the necessary changes on CI and codebase to
> basically have images and operators in the end of the build chain is
> something like 2 months of effort. Another impact that needs to be
> discussed is that KIE Tools repo had to be injected in the middle of all
> pipelines - forcing all PR checks and nightlies to build all repos (PR
> checks will likely take 12+ hours… I even heard that it could be even 24
> hours).
>
> Based on the input above, I think it’s quite risk to move in such direction
> without a more detailed plan… because 2 months could be turned easily in 6!
> And this is exactly what happened when we guessed that moving to Apache
> would take no more than 3 months. But here we are.
>
> I really strongly suggest that we focus on a release that could be
> achievable in less than a month from now, and we - after release - have a
> in depth discussion about the overall codebase and ci organization.
>
>
> On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> gabriele.cardosi@gmail.com>
> wrote:
>
> > Alex,
> > my suggestion is to move the building of all docker images, from whatever
> > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > invoked after all the others.
> > I'm not sure if this would solve all the issues, and since I could not
> > enter in the details of all the involved code, my suggestion may be too
> > naive.
> > Having spent almost all of the last year in CI, I may say that, at least
> > for the kie-tools repo, removing the image build step from it should not
> be
> > too difficult (since it is an issue we already faced and solved).
> > If, with "detailed proposal", you mean a complete list of all modules to
> be
> > moved and dependency refactoring, of course I can not provide it right
> now.
> >
> > Anyway, I share the concern from Francisco: undoing something is almost
> > always harder than doing it "rightly" from scratch...
> >
> >
> >
> >
> > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti <
> > ftirados@redhat.com> ha scritto:
> >
> > > I do not think estimations should be the only driver to make a
> decision,
> > > especially when the current proposal is conceptually incompatible with
> > the
> > > multi repo approach that is taken elsewhere in the project.
> > > Given my knowledge of the CI it is nearly impossible for me to give a
> > fair
> > > estimate of how much it might take to achieve step 2) of my previous
> > e-mail
> > > . It might take a while or it might be pretty easy after all, I don't
> > > really know, but I think it will be a good idea if some of the experts
> > on
> > > CI in the team (the ones that set up the pipeline, which was a huge
> > > achievement) give an estimate, not me. Estimating how much it takes to
> > > merge two existing repos (without altering CI) is easier, but it does
> not
> > > mean we are doing the right thing.
> > > My main concern is that it will be very difficult for me to explain to
> > > someone that arrives new to the team, that having experts on CI on the
> > > team, we decided to merge two repos (once merged, it would be rather
> > > difficult to unmerge) rather than fix the CI, because of expediency.
> > >
> > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> > > wrote:
> > >
> > > > Francisco,
> > > >
> > > > Please take the time to make the more in depth analysis needed and
> > > provide
> > > > a more detailed plan… so we - as community- can evaluate the size of
> > the
> > > > effort. In the conceptual level you shared it’s near impossible to
> > > estimate
> > > > the size of the effort and compare with the current proposal.
> > > >
> > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > ftirados@redhat.com> wrote:
> > > >
> > > > > I think I already did a high level proposal.
> > > > > 1) Remove all dependencies from tooling to images, so images
> depend
> > on
> > > > > tooling but tooling does not depend on images.
> > > > > 2) Then change CI to deal with tooling repo before dealing with
> > images
> > > > > repo.
> > > > > I understand that CI details are tricky and since I'm not familiar
> > with
> > > > CI
> > > > > in any way, I barely can make a low level design, but we do not
> need
> > to
> > > > fix
> > > > > everything, just achieve 2), a change of compilation order.
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > >
> > > > > > Francisco and Grabriele,
> > > > > >
> > > > > > You may not like or understand why the current state of the CI is
> > > like
> > > > > > that… actually has been in Red Hat and has been replicated in
> > Apache
> > > as
> > > > > > used to be….
> > > > > >
> > > > > > But the fact is that this is the current reality.
> > > > > >
> > > > > > If you disagree with the current plan, please provide a detailed
> > > > > > alternative so we, as community, can better evaluate the pros and
> > > cons
> > > > of
> > > > > > each proposal.
> > > > > >
> > > > > >
> > > > > > I think it’s also fair to say that, post 10 release we need to
> > have a
> > > > > much
> > > > > > in depth discussion about how our codebase is organized, it’s
> clear
> > > > that
> > > > > > it’s not working.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > gabriele.cardosi@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > As Francisco said,
> > > > > > > I also have the impression that the "images" (if we are talking
> > of
> > > > > docker
> > > > > > > images) should be the very last one to be built, in a
> standalone
> > > > repo.
> > > > > > > That way, they may "combine" artifacts that are built in
> > different
> > > > > repos,
> > > > > > > regardless of the order in which those are built.
> > > > > > > Moving them out of all the repos (kogito-apps/kie-tools) maybe
> > > could
> > > > > > > simplify the situation a bit.
> > > > > > > (I also think there are some statements of undisputable needs
> > while
> > > > > they
> > > > > > > are, actually, just technical choices.
> > > > > > > Anyway, this latter point is for longer, following,
> discussion.)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> Tirado
> > > > Sarti
> > > > > <
> > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > >
> > > > > > > > Alex,
> > > > > > > > There are two assumptions that deserve further discussion:
> > > > > > > > 1) That tool has to be the last to build. why? it does not
> have
> > > > more
> > > > > > > sense
> > > > > > > > to build final images after everything else has been built?-
> > > > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> > > bigger
> > > > > than
> > > > > > > the
> > > > > > > > impact (long term consequences) of consolidating two
> unrelated
> > > > piece
> > > > > of
> > > > > > > > software within the same repository.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > alex@porcelli.me
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco,
> > > > > > > > >
> > > > > > > > > This was discussed as an alternative solution, however it
> has
> > > > major
> > > > > > > > impact
> > > > > > > > > on CI and there’s also the fact Tool has been always the
> last
> > > to
> > > > > > build
> > > > > > > > and
> > > > > > > > > has no Snapshot published (actually in JavaScript world
> there
> > > is
> > > > no
> > > > > > > > > snapshot concept).
> > > > > > > > >
> > > > > > > > > So, based on our evaluation… the proposal here is the least
> > > > > > disruptive
> > > > > > > > and
> > > > > > > > > will take less time to unblock the release.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > _____________
> > > > > > > > > Alex Porcelli
> > > > > > > > > http://porcelli.me
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > Sarti <
> > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > > After kie-tools, sorry. I think we are not embracing the
> > fact
> > > > > that
> > > > > > > > > > kogito-images depend on kie-tools, because we want those
> > > images
> > > > > to
> > > > > > > > > include
> > > > > > > > > > tools.
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado
> > > Sarti
> > > > <
> > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > It can be an alternative solution to move
> > > kn-plugin-workflow
> > > > to
> > > > > > > > > > > kogito-images (so there is not longer dependency from
> > tools
> > > > to
> > > > > > > > images)
> > > > > > > > > > and
> > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > Martinez
> > > <
> > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > >>
> > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > >> escribió:
> > > > > > > > > > >>
> > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > alex@porcelli.me
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > > +1
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I spent the last day or so working closely with
> > Tiago,
> > > > > > > exploring
> > > > > > > > > > >> > different
> > > > > > > > > > >> > > options and getting deeper on the impact and
> > > evaluating
> > > > > the
> > > > > > > > > overall
> > > > > > > > > > >> > release
> > > > > > > > > > >> > > procedure steps required. I agree with the
> proposal
> > as
> > > > the
> > > > > > > most
> > > > > > > > > > >> > > viable option for unblocking the 10 release in the
> > > > > > reasonable
> > > > > > > > time
> > > > > > > > > > >> frame.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > >> > wrote:
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time, as
> > this
> > > > > > matter
> > > > > > > > > > >> requires a
> > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > > > according
> > > > > > to
> > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > > > >> > > > (
> > > > > > > > >
> > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > ),
> > > > > > > > > > >> > > > many of us were working towards removing a
> > circular
> > > > > > > dependency
> > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > `kie-tools`.
> > > > > > As
> > > > > > > we
> > > > > > > > > > >> > > > progressed towards a solution, we kept finding
> the
> > > > > > circular
> > > > > > > > > > >> dependency
> > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of
> the
> > > > things
> > > > > > we
> > > > > > > > did,
> > > > > > > > > > and
> > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Right now, even though we started the effort to
> > move
> > > > the
> > > > > > > > Quarkus
> > > > > > > > > > Dev
> > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been able
> to
> > > do
> > > > it
> > > > > > > yet,
> > > > > > > > as
> > > > > > > > > > >> we've
> > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17, Maven
> > > 3.9.6,
> > > > > and
> > > > > > > > > Quarkus
> > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > This
> > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > >> > > >
> > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > .
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 01.
> incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > >> > > > C | 03. incubator-kie-kogito-examples
> > > > > > > > > > >> > > > Y | 04. incubator-kie-kogito-images
> > > > > > > > > > >> > > > C | 05.
> > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > >> > > > E | 06.
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> depends
> > > on
> > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > >> > > > * and
> > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > depend
> > > > > > > > > > >> on
> > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`,
> > we
> > > > > > would've
> > > > > > > > > had:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 01.
> incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > >> > > > 03.
> incubator-kie-kogito-examples
> > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > >> > > > Y | 05.
> > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > >> > > > L | 06.
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > depends
> > > on
> > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > >> > > > * and `kogito-images`/kogito-swf-devmode
> > > > depends
> > > > > > on
> > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > > > `kie-tools`,
> > > > > > > we
> > > > > > > > > > >> would've
> > > > > > > > > > >> > > > had:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 01.
> incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > >> > > > 03.
> incubator-kie-kogito-examples
> > > > > > > > > > >> > > > 04. incubator-kie-kogito-images
> > > > > > > > > > >> > > > C |==> 05.
> > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > >> > > > C | 06.
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > >> > > > E
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > depends
> > > on
> > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> depends
> > > on
> > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Clearly, we have a much bigger problem than a
> > simple
> > > > > > > circular
> > > > > > > > > > >> > dependency.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > After multiple conversations with a lot of
> people,
> > > > it's
> > > > > > been
> > > > > > > > > > really
> > > > > > > > > > >> > > > hard coming up with a simple solution that makes
> > it
> > > > > > possible
> > > > > > > > to
> > > > > > > > > > >> build
> > > > > > > > > > >> > > > Apache KIE in one shot, while preserving the way
> > > > > everyone
> > > > > > is
> > > > > > > > > used
> > > > > > > > > > to
> > > > > > > > > > >> > > > contributing to the multiple repositories we
> have.
> > > > More
> > > > > > than
> > > > > > > > > that,
> > > > > > > > > > >> > > > while making this assessment, I found more
> > problems
> > > > > that,
> > > > > > in
> > > > > > > > my
> > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > In light of that difficulty, I'm coming forward
> > with
> > > > my
> > > > > > > > proposal
> > > > > > > > > > for
> > > > > > > > > > >> > > > the Apache KIE release process, so we can use
> > > Apache's
> > > > > > > > > mechanisms
> > > > > > > > > > to
> > > > > > > > > > >> > > > have a slower-paced, in-depth debate about this
> > > really
> > > > > > > > > complicated
> > > > > > > > > > >> > > > matter.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > current
> > > > > > > situation
> > > > > > > > > of
> > > > > > > > > > >> our
> > > > > > > > > > >> > > > codebase, as well as problems I can currently
> see.
> > > > I'll
> > > > > > > start
> > > > > > > > > with
> > > > > > > > > > >> an
> > > > > > > > > > >> > > > analysis of the repositories and their purposes,
> > > point
> > > > > out
> > > > > > > > some
> > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > release,
> > > > > > explain
> > > > > > > > my
> > > > > > > > > > >> > > > proposal and discuss some consequences to what
> I'm
> > > > > > > proposing.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> > > `0.0.0`
> > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > >> > > > (Issues only, README should be updated @
> > `main`.
> > > > > Same
> > > > > > > for
> > > > > > > > > > GitHub
> > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > >> > > > (The Kogito website. Develop & deploy at the
> > > > `main`
> > > > > > > > branch.)
> > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > > > `deploy`
> > > > > to
> > > > > > > > > update
> > > > > > > > > > >> the
> > > > > > > > > > >> > > > website.)
> > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > >> > > > (GitHub pages used to host sandbox.kie.org
> > and
> > > > KIE
> > > > > > > Tools'
> > > > > > > > > > >> Chrome
> > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > > > >> > > > (Same as above, but for manual sanity checks
> > > > during
> > > > > > the
> > > > > > > > > > staging
> > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I grouped the repositories by category, and
> listed
> > > > them
> > > > > > in a
> > > > > > > > > > >> > > > topological order. Keep in mind that when
> > flattening
> > > > > out a
> > > > > > > > tree,
> > > > > > > > > > >> there
> > > > > > > > > > >> > > > are multiple possibilities. For example,
> > OptaPlanner
> > > > > > > could've
> > > > > > > > > been
> > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category A repos are what I've been referring to
> > as
> > > > > > `drools`
> > > > > > > > and
> > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is
> inside
> > > > that
> > > > > > > > stream,
> > > > > > > > > as
> > > > > > > > > > >> the
> > > > > > > > > > >> > > > way these repositories reference each other are
> > > > through
> > > > > > > Maven
> > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > > > version.
> > > > > > This
> > > > > > > > > > >> mechanism
> > > > > > > > > > >> > > > is well-known to the team, and although flawed
> for
> > > > > > intra-day
> > > > > > > > > > builds
> > > > > > > > > > >> > > > and disruptive for people in many different time
> > > > zones,
> > > > > it
> > > > > > > is
> > > > > > > > > > >> already
> > > > > > > > > > >> > > > very comfortable for everyone to work with, I
> > > assume.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Contributions made to Category A have some
> > dedicated
> > > > > > > > pipelines,
> > > > > > > > > > >> which
> > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > cross-repo
> > > > > PRs
> > > > > > > > > > together
> > > > > > > > > > >> > > > and verify that the codebase will continue
> working
> > > as
> > > > > > > expected
> > > > > > > > > > after
> > > > > > > > > > >> > > > they're all merged. From what I could gather,
> > there
> > > > are
> > > > > > some
> > > > > > > > > > >> > > > "sub-streams" currently configured for
> cross-repo
> > > PRs.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > kogito-examples
> > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > >> > > > - kogito-images, and kogito-serverless-operator
> > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > > > combination
> > > > > > of
> > > > > > > > > repos
> > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> cannot
> > be
> > > > > > > verified
> > > > > > > > > > before
> > > > > > > > > > >> > > > merging, making our contribution model dependent
> > on
> > > > > > > individual
> > > > > > > > > > >> > > > contributors building stuff on their machines to
> > > > verify
> > > > > > that
> > > > > > > > it
> > > > > > > > > > >> works.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > >> > > > ,
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > >> > > > ,
> > > > > > > > > > >> > > > and
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > >> > > > .
> > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > pipelines,
> > > > so
> > > > > > > > please
> > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category B repos are what I've been referring to
> > as
> > > > > > > > `kie-tools`
> > > > > > > > > > >> > > > stream. The first repo there is a template
> > > repository
> > > > > that
> > > > > > > is
> > > > > > > > > used
> > > > > > > > > > >> by
> > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > Sandbox,
> > > > > > > similar
> > > > > > > > > to a
> > > > > > > > > > >> > > > Maven archetype, if you will. The other one is
> the
> > > KIE
> > > > > > Tools
> > > > > > > > > > >> monorepo,
> > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > system.
> > > > > > > > Currently,
> > > > > > > > > > KIE
> > > > > > > > > > >> > > > Tools hosts Java libraries and apps, TypeScript
> > > > > libraries
> > > > > > > and
> > > > > > > > > > apps,
> > > > > > > > > > >> Go
> > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > `kie-tools`
> > > > > > > monorepo
> > > > > > > > > is
> > > > > > > > > > >> > > > configured to work with sparse checkouts and can
> > do
> > > > > > partial
> > > > > > > > > > builds.
> > > > > > > > > > >> > > > Category B repos refer to Category A repos
> through
> > > > > > > timestamped
> > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > > > introduced
> > > > > > > that
> > > > > > > > > > will
> > > > > > > > > > >> > > > build and publish immutable, persistent
> artifacts
> > > > under
> > > > > a
> > > > > > > > > version
> > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > published
> > > > > > weekly
> > > > > > > > > every
> > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > evolution
> > > > to
> > > > > > the
> > > > > > > > > Kogito
> > > > > > > > > > >> > > > releases, as we're now targeting one release for
> > all
> > > > of
> > > > > > > Apache
> > > > > > > > > > KIE,
> > > > > > > > > > >> so
> > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > An important note here is that Category B
> > > repositories
> > > > > > have
> > > > > > > > been
> > > > > > > > > > >> > > > historically kept out of any automations we used
> > to
> > > > > have,
> > > > > > > way
> > > > > > > > > back
> > > > > > > > > > >> > > > when Kogito started and we had the Business
> > Central
> > > > > > (a.k.a.
> > > > > > > > v7)
> > > > > > > > > > >> stream
> > > > > > > > > > >> > > > still going on. For this reason, Category B
> > projects
> > > > > have
> > > > > > > > > > developed
> > > > > > > > > > >> > > > their own automations, based on GitHub Actions.
> > > > > Category B
> > > > > > > > repos
> > > > > > > > > > >> have
> > > > > > > > > > >> > > > always depended on Category A repos using fixed
> > > > > versions.
> > > > > > If
> > > > > > > > > > >> Category
> > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > breaking
> > > > > > changes
> > > > > > > > on
> > > > > > > > > > >> > > > Category A repositories would've had the
> potential
> > > to
> > > > > > break
> > > > > > > > > > >> Category B
> > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > development
> > > > > > > stream,
> > > > > > > > > and
> > > > > > > > > > >> > > > introducing unpleasant surprises for maintainers
> > of
> > > > > > > Category B
> > > > > > > > > > >> repos,
> > > > > > > > > > >> > > > as historically Category A contributors were not
> > > > > familiar
> > > > > > > with
> > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Contributions made to Category B repos go
> through
> > a
> > > > > GitHub
> > > > > > > > > Actions
> > > > > > > > > > >> > > > workflow that builds the relevant part of the
> > > > > `kie-tools`
> > > > > > > > > monorepo
> > > > > > > > > > >> for
> > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > pipeline
> > > > > > itself
> > > > > > > > are
> > > > > > > > > > also
> > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do
> things
> > > > like
> > > > > > > > > atomically
> > > > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > > > importantly,
> > > > > > > it
> > > > > > > > > > >> allows
> > > > > > > > > > >> > > > us to upgrade the repository to a new
> timestamped
> > > > > SNAPSHOT
> > > > > > > > > > together
> > > > > > > > > > >> > > > with the changes necessary to make it stay
> green.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This setup, however, makes it impossible to have
> > > > > > cross-repo
> > > > > > > > PRs
> > > > > > > > > > >> > > > involving Category A and Category B
> > simultaneously,
> > > > with
> > > > > > the
> > > > > > > > > > current
> > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category C repos are kind of floating around,
> and
> > > I'm
> > > > > not
> > > > > > > sure
> > > > > > > > > if
> > > > > > > > > > >> > > > there's much activity going on there.
> Regardless,
> > as
> > > > > > they're
> > > > > > > > > part
> > > > > > > > > > of
> > > > > > > > > > >> > > > Apache KIE, they will be part of our release,
> so I
> > > > > listed
> > > > > > > them
> > > > > > > > > for
> > > > > > > > > > >> us
> > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category D is self explanatory. There's only one
> > > repo
> > > > > that
> > > > > > > has
> > > > > > > > > > >> already
> > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category E are repos that do not host code
> > directly,
> > > > and
> > > > > > are
> > > > > > > > > > either
> > > > > > > > > > >> > > > organizational entities, or host websites, that
> > > > > currently
> > > > > > > are
> > > > > > > > > not
> > > > > > > > > > >> part
> > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This lack of unification between Category A and
> > > > > Category B
> > > > > > > is,
> > > > > > > > > > IMHO,
> > > > > > > > > > >> > > > what allowed us to introduce the infamous
> circular
> > > > > > > dependency
> > > > > > > > > > >> between
> > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now can
> > > > describe
> > > > > > as
> > > > > > > a
> > > > > > > > > > >> circular
> > > > > > > > > > >> > > > dependency between Category A and Category B.
> The
> > > way
> > > > I
> > > > > > see
> > > > > > > > it,
> > > > > > > > > if
> > > > > > > > > > >> we
> > > > > > > > > > >> > > > had a single pipeline, building everything from
> > > > `drools`
> > > > > > to
> > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > introduced,
> > > > > > and
> > > > > > > we
> > > > > > > > > > >> > > > wouldn't be having this huge problem in our
> hands
> > > > right
> > > > > > now.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > My proposal for the Apache KIE release process
> > sees
> > > > this
> > > > > > > lack
> > > > > > > > of
> > > > > > > > > > >> > > > unification as a central problem, not only for
> > this
> > > > > > release
> > > > > > > in
> > > > > > > > > > >> > > > particular, but for the community as a whole. It
> > is
> > > my
> > > > > > > belief
> > > > > > > > > that
> > > > > > > > > > >> we
> > > > > > > > > > >> > > > are all under the same roof, and that no
> > > contribution
> > > > > > should
> > > > > > > > be
> > > > > > > > > > >> > > > allowed to break any part of our codebase. With
> > the
> > > > > > > increasing
> > > > > > > > > > >> volume
> > > > > > > > > > >> > > > of code, and hopefully number of contributors
> too,
> > > we
> > > > > > cannot
> > > > > > > > > keep
> > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > things.
> > > > > We're
> > > > > > > all
> > > > > > > > > > >> humans
> > > > > > > > > > >> > > > after all, and it is our job to have mechanisms
> in
> > > > place
> > > > > > to
> > > > > > > > > > prevent
> > > > > > > > > > >> us
> > > > > > > > > > >> > > > from unwillingly making mistakes. Especially
> when
> > > > these
> > > > > > > > mistakes
> > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > individually,
> > > > > > > > probably
> > > > > > > > > > >> can't
> > > > > > > > > > >> > > > fix.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on
> > > > > > kiegroup's
> > > > > > > > KIE
> > > > > > > > > > >> Tools
> > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > `kogito-images`
> > > > > > > depending
> > > > > > > > on
> > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > kiegroup's
> > > > > > > `lienzo`
> > > > > > > > > and
> > > > > > > > > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps` depending
> on
> > > > > > > kiegroup's
> > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > >> > > > * This module was removed from the KIE codebase
> > > here:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > >> > > >
> > > > > > > > > >
> > > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > ,
> > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > >> > > > * This new repo depends on Kogito and
> OptaPlanner,
> > > > > > pointing
> > > > > > > to
> > > > > > > > > > older
> > > > > > > > > > >> > > > versions.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator`
> > > > > depending
> > > > > > on
> > > > > > > > > > Kogito
> > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P6. Category C repos are out of date and not
> part
> > of
> > > > the
> > > > > > > > > Category
> > > > > > > > > > A
> > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > version
> > > is
> > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > >> > > > depending on Kogito without a specific version,
> > only
> > > > by
> > > > > > > using
> > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version is
> > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has
> > its
> > > > E2E
> > > > > > > > disabled
> > > > > > > > > > >> after
> > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > solution,
> > > > as
> > > > > > they
> > > > > > > > > both
> > > > > > > > > > >> > > > suffer from the circular dependency between
> > > Category A
> > > > > and
> > > > > > > > > > Category
> > > > > > > > > > >> B.
> > > > > > > > > > >> > > > As Category A and Category B are both streams
> that
> > > > have
> > > > > > been
> > > > > > > > > > really
> > > > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > > > contributions
> > > > > > > > that
> > > > > > > > > > >> > > > cannot be done, given that Category A depends on
> > > > > Category
> > > > > > B
> > > > > > > > > with a
> > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P3 and P4, although not ideal, can be understood
> > as
> > > > > > > technical
> > > > > > > > > > debt.
> > > > > > > > > > >> > > > Depending on unmaintained projects is something
> > > we'll
> > > > > > always
> > > > > > > > be
> > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > matter
> > > of
> > > > > > > making
> > > > > > > > > them
> > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P7 is an isolated problem that won't impact the
> > > > > structure
> > > > > > or
> > > > > > > > > > >> anything
> > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > regression
> > > > we
> > > > > > > > > > introduced
> > > > > > > > > > >> > > > recently.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE
> > 10,
> > > > and
> > > > > > > that
> > > > > > > > > P5,
> > > > > > > > > > >> P6,
> > > > > > > > > > >> > > > and P7 have easy fixes, the only problems left
> to
> > > > > discuss
> > > > > > > are
> > > > > > > > P1
> > > > > > > > > > and
> > > > > > > > > > >> > > > P2, which can't be done without a proper
> proposal.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I'll try to be very meticulous here, since from
> my
> > > > > > > experience,
> > > > > > > > > any
> > > > > > > > > > >> > > > little miscalculation can lead to our release
> not
> > > > > working
> > > > > > > out
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > >> > > > end. To try and avoid that as much as possible,
> > and
> > > > make
> > > > > > > > > > everything
> > > > > > > > > > >> we
> > > > > > > > > > >> > > > can to have a successful Apache KIE 10 release,
> > bear
> > > > > with
> > > > > > > me.
> > > > > > > > > I'll
> > > > > > > > > > >> lay
> > > > > > > > > > >> > > > out a timeline of events that need to happen in
> > > order
> > > > > for
> > > > > > > our
> > > > > > > > > > >> release
> > > > > > > > > > >> > > > to be published, with all artifacts ending up in
> > the
> > > > > right
> > > > > > > > > places,
> > > > > > > > > > >> but
> > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > As you saw at the beginning of this email, all
> the
> > > > > > attempts
> > > > > > > we
> > > > > > > > > > made
> > > > > > > > > > >> > > > left us with the circular dependency showing up
> > at a
> > > > > > > different
> > > > > > > > > > >> place,
> > > > > > > > > > >> > > > but something all these places have in common is
> > > that
> > > > > > > they're
> > > > > > > > > all
> > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > The first part of my proposal is the following:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > Quarkus
> > > > Dev
> > > > > > UIs
> > > > > > > > from
> > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > Management
> > > > > and
> > > > > > > > Task
> > > > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > `kogito-swf-builder`
> > > > > > > > > > images
> > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > >> > > > S3. We move the entire
> > `kogito-serverless-operator`
> > > > repo
> > > > > > > > inside
> > > > > > > > > a
> > > > > > > > > > >> new
> > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve problems
> > P1
> > > > and
> > > > > > P2.
> > > > > > > Of
> > > > > > > > > > >> course
> > > > > > > > > > >> > > > the rest of
> > > > > > > > > > >>
> > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This doesn't come without consequences, of
> course,
> > > as
> > > > > the
> > > > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> > > images,
> > > > > and
> > > > > > > the
> > > > > > > > > > >> > > > `kogito-serverless-operator` would be moving
> from
> > > > > > Category A
> > > > > > > > to
> > > > > > > > > > >> > > > Category B. This move would make them have to
> > > > reference
> > > > > > > > > Category A
> > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > `kogito-images`
> > > > > > > and
> > > > > > > > > > >> > > > `kogito-serverless-operator` are already their
> own
> > > > > > > > "sub-stream"
> > > > > > > > > > >> inside
> > > > > > > > > > >> > > > Category A, though, contributions made in a
> > > cross-repo
> > > > > > > fashion
> > > > > > > > > to
> > > > > > > > > > >> this
> > > > > > > > > > >> > > > "sub-stream" will continue being possible, now
> > via a
> > > > > > single
> > > > > > > PR
> > > > > > > > > to
> > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A
> and
> > > > > > Category
> > > > > > > B
> > > > > > > > > will
> > > > > > > > > > >> > > > continue not being possible, and a 1-week delay
> > > > between
> > > > > > > > merging
> > > > > > > > > > >> > > > something on Category A and using it on
> Category B
> > > > will
> > > > > > > still
> > > > > > > > > > >> happen.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`, however,
> > > does
> > > > > > allow
> > > > > > > > for
> > > > > > > > > > >> sparse
> > > > > > > > > > >> > > > checkouts and partial builds, so working with a
> > > subset
> > > > > of
> > > > > > > the
> > > > > > > > > > >> monorepo
> > > > > > > > > > >> > > > is possible and encouraged. Making changes only
> to
> > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example, will
> > > have
> > > > > the
> > > > > > PR
> > > > > > > > > > checks
> > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > >> > > > .
> > > > > > > > > > >> > > > We're not compromising when running partial
> builds
> > > > too.
> > > > > We
> > > > > > > > know
> > > > > > > > > > that
> > > > > > > > > > >> > > > the entire repo will continue working even after
> > > only
> > > > > > > > building a
> > > > > > > > > > >> small
> > > > > > > > > > >> > > > subset of the changes. Doing partial or full
> > builds
> > > is
> > > > > > > > > > automatically
> > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Keep in mind that, even though I'm proposing we
> > > move a
> > > > > > bunch
> > > > > > > > of
> > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see this
> as a
> > > > > > TEMPORARY
> > > > > > > > > > >> solution
> > > > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > > > additional
> > > > > > > stuff
> > > > > > > > > > >> > > > TEMPORARILY so that we can release and continue
> > > moving
> > > > > > > > forward.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> > became a
> > > > > > > polyglot
> > > > > > > > > > >> monorepo
> > > > > > > > > > >> > > > out of necessity, and although I'm really proud
> of
> > > > what
> > > > > we
> > > > > > > > > > achieved
> > > > > > > > > > >> > > > there so far, I don't think `kie-tools` has a
> > setup
> > > > that
> > > > > > is
> > > > > > > > > > suitable
> > > > > > > > > > >> > > > for all the different nuances that compose our
> > > > > community.
> > > > > > > I'm
> > > > > > > > > well
> > > > > > > > > > >> > > > aware that a polyglot monorepo that does not
> > follow
> > > > > > > widespread
> > > > > > > > > > >> > > > conventions will scare some people away, and as
> > much
> > > > as
> > > > > > > we've
> > > > > > > > > > tried
> > > > > > > > > > >> to
> > > > > > > > > > >> > > > make build instructions clear, we can't always
> get
> > > > past
> > > > > > the
> > > > > > > > > > >> prejudice
> > > > > > > > > > >> > > > some people have towards the "front-end"
> > ecosystem.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > With all that said, I keep thinking this is the
> > best
> > > > > > course
> > > > > > > of
> > > > > > > > > > >> action
> > > > > > > > > > >> > > > for us right now. We keep most of our stuff
> > > unchanged,
> > > > > we
> > > > > > > > > unblock
> > > > > > > > > > >> the
> > > > > > > > > > >> > > > release, and we have a working setup that will
> > suit
> > > us
> > > > > > well
> > > > > > > > > while
> > > > > > > > > > we
> > > > > > > > > > >> > > > discuss and reach a conclusion regarding the
> > future
> > > of
> > > > > our
> > > > > > > > > > codebase
> > > > > > > > > > >> > > > structure.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Let me paint a quick picture here of what our
> code
> > > > base
> > > > > > > would
> > > > > > > > > look
> > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> accepted:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > >> > > > A
> incubator-kie-optaplanner-quickstarts
> > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > B
> > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > >> > > > E incubator-kie-kogito-online-staging
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > > > >> > > > `kogito-serverless-operator` moves entirely
> inside
> > > > > > > > `kie-tools`.
> > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > > > > > > > >> > > > `kogito-serverless-operator` inside `kie-tools`,
> > > there
> > > > > are
> > > > > > > no
> > > > > > > > > > cycles
> > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> granularly
> > > > build:
> > > > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > >> and
> > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > >> > > > 4. packages/sonataflow-operator (contents
> from
> > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > The second part of the proposal is the release
> > > process
> > > > > > > itself,
> > > > > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as
> > > cutting
> > > > > > point
> > > > > > > > for
> > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > >> > > > 2. Update Category B repos to point to this
> > > > timestamped
> > > > > > > > > SNAPSHOT,
> > > > > > > > > > >> and
> > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > >> > > > 3. At this point, with everything working, we
> can
> > > > branch
> > > > > > out
> > > > > > > > to
> > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> SNAPSHOT
> > > > tag,
> > > > > > and
> > > > > > > > > > >> Category B
> > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > >> > > > 4. All Category A and Category B repos update
> > their
> > > > > > versions
> > > > > > > > to
> > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > >> > > > 5. Update Category B repos to point to Category
> A
> > > > repos
> > > > > > > using
> > > > > > > > > the
> > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > >> > > > 6. At this point, we can vote on the release
> based
> > > on
> > > > > the
> > > > > > > > > `10.0.x`
> > > > > > > > > > >> > > > branches, given we don't expect any code changes
> > > > > anymore.
> > > > > > > > > > >> > > > 7. After voting passes, we're good to start the
> > > > release
> > > > > > > > process.
> > > > > > > > > > >> > > > 8. Category A repos follow their
> manual/automated
> > > > > release
> > > > > > > > > process,
> > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to
> > Git,
> > > > and
> > > > > > > built
> > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > >> > > > 9. We wait a little bit for Category A artifacts
> > to
> > > be
> > > > > > > > > propagated
> > > > > > > > > > on
> > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > >> > > > 10. Category B repos follow their
> manual/automated
> > > > > release
> > > > > > > > > > process,
> > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to
> > Git,
> > > > and
> > > > > > > built
> > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > >> > > > 12. Category E repos can be manually tagged with
> > > > 10.0.0
> > > > > > from
> > > > > > > > > their
> > > > > > > > > > >> > > > default branches.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > More needs to be discussed if we're planning to
> > > > maintain
> > > > > > > > > multiple
> > > > > > > > > > >> > > > release streams in parallel, but I guess it can
> > wait
> > > > for
> > > > > > > after
> > > > > > > > > > >> Apache
> > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Thank you for reading, and I'm looking forward
> to
> > > > > hearing
> > > > > > > back
> > > > > > > > > > from
> > > > > > > > > > >> > > > everyone.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Of course, alternative solutions are possible.
> > This
> > > > > email,
> > > > > > > > > > however,
> > > > > > > > > > >> > > > summarizes my view of how we should attack the
> > > > problem,
> > > > > > > > > > considering
> > > > > > > > > > >> > > > disruption, required effort, the release process
> > > > itself,
> > > > > > and
> > > > > > > > > > >> history.
> > > > > > > > > > >> > > > Feel free to propose alternatives. This is not a
> > > > voting
> > > > > > > > thread.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Regards,
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >>
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > dev-help@kie.apache.org
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
I think we all want to unblock the release, the question is how, because
one way or another we need to do something to unblock it.
If the proposed solution was one that was not really jeopardizing the
evolution of the project, I will accept it.
But since I really believe the proposed solution is not better, it does not
necessarily take less time to achieve than the alternative I mentioned, can
someone fluent on CI tell everyone how much it really cost to tell our
current CI to compile tools repo before operator one?
On Wed, Mar 13, 2024 at 2:26 PM Tibor Zimányi <tz...@apache.org> wrote:
> Hi everyone,
>
> I just want to remind everyone, that we have not released a release for
> more than half a year (6 months). We are being constantly asked, when will
> we release a new release, due to multiple reasons. E.g. Quarkus 3 support,
> newer Java support etc. Keep in mind that the current release, that is out,
> is outdated on many fronts, e.g. security, as it contains outdated
> dependencies and frameworks support. I even heard the need to have a
> release internally, from our commiters members, because they need it for
> their projects that they are working on, and they are blocked, until we
> have a new release. So I personally think we cannot solve the current
> problem now. As Alex mentioned, I would also suggest to fix it for now as
> it is proposed. After the release, we can discuss whatever we want, to fix
> it properly. But we need to finally have a release. Everyone involved put
> great effort to this (including people discussing in this thread), so I
> have the feeling postponing the release for another two or more months will
> just grow frustration within the community.
> Please keep this all in mind. I think everyone would like to fix this
> properly. However sometimes doing that just doesn't help at all at the
> moment. Sometimes a temporary solution is better in my opinion.
>
> Best regards,
> Tibor
>
> Dňa st 13. 3. 2024, 14:12 Alex Porcelli <po...@apache.org> napísal(a):
>
> > Francisco,
> >
> > Please feel free to open a new thread with such a proposal, although I
> > still consider that it’s necessary more details to be properly evaluated.
> >
> > Keep in mind that CI code, configs and infrastructure is accessible for
> all
> > committers.
> >
> > Please let’s keep this thread focused on the detailed proposal shared.
> >
> > In case of multiple proposals we can start an official vote.
> >
> >
> > On Wed, Mar 13, 2024 at 9:05 AM Francisco Javier Tirado Sarti <
> > ftirados@redhat.com> wrote:
> >
> > > I hardly see a difference in detail between the proposal to move
> > > kn-workflow module from tooling to images (it should have never been in
> > > tooling repo) plus changing CI stream to compile tooling repo before
> > images
> > > repo (which I hope we all agree is the natural order) and the proposal
> to
> > > move all stuff from images that depends on tooling to tooling repo
> > (which I
> > > hope we all agree hardly fits in current multi repo structure) and
> sort
> > > out the "details" on the ci pipeline associated to that repo (which
> > implies
> > > CI knowledge after all)
> > > The key point here is, does Tiago (as tooling SME, it seems that there
> > is a
> > > tools team but there is not a drools team ;)) agree that tooling should
> > be
> > > executed before images because there is a logical dependency between
> > images
> > > and tooling?
> > > In my opinion, the least we can do is to explore how it really costs to
> > > change CI to execute tooling before images.
> > >
> > >
> > > On Wed, Mar 13, 2024 at 1:36 PM Alex Porcelli <al...@porcelli.me>
> wrote:
> > >
> > > > Francisco and Gabriele,
> > > >
> > > > I understand and acknowledge your desire to find the “right” solution
> > > > instead to work on a temporary “patch” - however without a detailed
> > > > proposal I don’t think we can properly evaluate the impact of your
> > > > suggestion.
> > > >
> > > > When I spoke with different SMEs that included tools and CI, the
> > > > guesstimate for making the necessary changes on CI and codebase to
> > > > basically have images and operators in the end of the build chain is
> > > > something like 2 months of effort. Another impact that needs to be
> > > > discussed is that KIE Tools repo had to be injected in the middle of
> > all
> > > > pipelines - forcing all PR checks and nightlies to build all repos
> (PR
> > > > checks will likely take 12+ hours… I even heard that it could be even
> > 24
> > > > hours).
> > > >
> > > > Based on the input above, I think it’s quite risk to move in such
> > > direction
> > > > without a more detailed plan… because 2 months could be turned easily
> > in
> > > 6!
> > > > And this is exactly what happened when we guessed that moving to
> Apache
> > > > would take no more than 3 months. But here we are.
> > > >
> > > > I really strongly suggest that we focus on a release that could be
> > > > achievable in less than a month from now, and we - after release -
> > have a
> > > > in depth discussion about the overall codebase and ci organization.
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > gabriele.cardosi@gmail.com>
> > > > wrote:
> > > >
> > > > > Alex,
> > > > > my suggestion is to move the building of all docker images, from
> > > whatever
> > > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to
> be
> > > > > invoked after all the others.
> > > > > I'm not sure if this would solve all the issues, and since I could
> > not
> > > > > enter in the details of all the involved code, my suggestion may be
> > too
> > > > > naive.
> > > > > Having spent almost all of the last year in CI, I may say that, at
> > > least
> > > > > for the kie-tools repo, removing the image build step from it
> should
> > > not
> > > > be
> > > > > too difficult (since it is an issue we already faced and solved).
> > > > > If, with "detailed proposal", you mean a complete list of all
> modules
> > > to
> > > > be
> > > > > moved and dependency refactoring, of course I can not provide it
> > right
> > > > now.
> > > > >
> > > > > Anyway, I share the concern from Francisco: undoing something is
> > almost
> > > > > always harder than doing it "rightly" from scratch...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado
> > Sarti
> > > <
> > > > > ftirados@redhat.com> ha scritto:
> > > > >
> > > > > > I do not think estimations should be the only driver to make a
> > > > decision,
> > > > > > especially when the current proposal is conceptually incompatible
> > > with
> > > > > the
> > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > Given my knowledge of the CI it is nearly impossible for me to
> > give
> > > a
> > > > > fair
> > > > > > estimate of how much it might take to achieve step 2) of my
> > previous
> > > > > e-mail
> > > > > > . It might take a while or it might be pretty easy after all, I
> > don't
> > > > > > really know, but I think it will be a good idea if some of the
> > > experts
> > > > > on
> > > > > > CI in the team (the ones that set up the pipeline, which was a
> huge
> > > > > > achievement) give an estimate, not me. Estimating how much it
> > takes
> > > to
> > > > > > merge two existing repos (without altering CI) is easier, but it
> > does
> > > > not
> > > > > > mean we are doing the right thing.
> > > > > > My main concern is that it will be very difficult for me to
> explain
> > > to
> > > > > > someone that arrives new to the team, that having experts on CI
> on
> > > the
> > > > > > team, we decided to merge two repos (once merged, it would be
> > rather
> > > > > > difficult to unmerge) rather than fix the CI, because of
> > expediency.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > porcelli@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Francisco,
> > > > > > >
> > > > > > > Please take the time to make the more in depth analysis needed
> > and
> > > > > > provide
> > > > > > > a more detailed plan… so we - as community- can evaluate the
> size
> > > of
> > > > > the
> > > > > > > effort. In the conceptual level you shared it’s near impossible
> > to
> > > > > > estimate
> > > > > > > the size of the effort and compare with the current proposal.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > > > ftirados@redhat.com> wrote:
> > > > > > >
> > > > > > > > I think I already did a high level proposal.
> > > > > > > > 1) Remove all dependencies from tooling to images, so images
> > > > depend
> > > > > on
> > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > 2) Then change CI to deal with tooling repo before dealing
> with
> > > > > images
> > > > > > > > repo.
> > > > > > > > I understand that CI details are tricky and since I'm not
> > > familiar
> > > > > with
> > > > > > > CI
> > > > > > > > in any way, I barely can make a low level design, but we do
> not
> > > > need
> > > > > to
> > > > > > > fix
> > > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > alex@porcelli.me
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco and Grabriele,
> > > > > > > > >
> > > > > > > > > You may not like or understand why the current state of the
> > CI
> > > is
> > > > > > like
> > > > > > > > > that… actually has been in Red Hat and has been replicated
> in
> > > > > Apache
> > > > > > as
> > > > > > > > > used to be….
> > > > > > > > >
> > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > >
> > > > > > > > > If you disagree with the current plan, please provide a
> > > detailed
> > > > > > > > > alternative so we, as community, can better evaluate the
> pros
> > > and
> > > > > > cons
> > > > > > > of
> > > > > > > > > each proposal.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think it’s also fair to say that, post 10 release we need
> > to
> > > > > have a
> > > > > > > > much
> > > > > > > > > in depth discussion about how our codebase is organized,
> it’s
> > > > clear
> > > > > > > that
> > > > > > > > > it’s not working.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > As Francisco said,
> > > > > > > > > > I also have the impression that the "images" (if we are
> > > talking
> > > > > of
> > > > > > > > docker
> > > > > > > > > > images) should be the very last one to be built, in a
> > > > standalone
> > > > > > > repo.
> > > > > > > > > > That way, they may "combine" artifacts that are built in
> > > > > different
> > > > > > > > repos,
> > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> > > maybe
> > > > > > could
> > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > (I also think there are some statements of undisputable
> > needs
> > > > > while
> > > > > > > > they
> > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > discussion.)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > > > Tirado
> > > > > > > Sarti
> > > > > > > > <
> > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > >
> > > > > > > > > > > Alex,
> > > > > > > > > > > There are two assumptions that deserve further
> > discussion:
> > > > > > > > > > > 1) That tool has to be the last to build. why? it does
> > not
> > > > have
> > > > > > > more
> > > > > > > > > > sense
> > > > > > > > > > > to build final images after everything else has been
> > > built?-
> > > > > > > > > > > 2) That the impact (in terms of effort now) on fixing
> CI
> > is
> > > > > > bigger
> > > > > > > > than
> > > > > > > > > > the
> > > > > > > > > > > impact (long term consequences) of consolidating two
> > > > unrelated
> > > > > > > piece
> > > > > > > > of
> > > > > > > > > > > software within the same repository.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > alex@porcelli.me
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Francisco,
> > > > > > > > > > > >
> > > > > > > > > > > > This was discussed as an alternative solution,
> however
> > it
> > > > has
> > > > > > > major
> > > > > > > > > > > impact
> > > > > > > > > > > > on CI and there’s also the fact Tool has been always
> > the
> > > > last
> > > > > > to
> > > > > > > > > build
> > > > > > > > > > > and
> > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> world
> > > > there
> > > > > > is
> > > > > > > no
> > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > >
> > > > > > > > > > > > So, based on our evaluation… the proposal here is the
> > > least
> > > > > > > > > disruptive
> > > > > > > > > > > and
> > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > _____________
> > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> Tirado
> > > > > Sarti <
> > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> embracing
> > > the
> > > > > fact
> > > > > > > > that
> > > > > > > > > > > > > kogito-images depend on kie-tools, because we want
> > > those
> > > > > > images
> > > > > > > > to
> > > > > > > > > > > > include
> > > > > > > > > > > > > tools.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > > Tirado
> > > > > > Sarti
> > > > > > > <
> > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > kn-plugin-workflow
> > > > > > > to
> > > > > > > > > > > > > > kogito-images (so there is not longer dependency
> > from
> > > > > tools
> > > > > > > to
> > > > > > > > > > > images)
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > > > Martinez
> > > > > > <
> > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > (apache)
> > > <
> > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > > > alex@porcelli.me
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > I spent the last day or so working closely
> > with
> > > > > Tiago,
> > > > > > > > > > exploring
> > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > > > evaluating
> > > > > > > > the
> > > > > > > > > > > > overall
> > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > > proposal
> > > > > as
> > > > > > > the
> > > > > > > > > > most
> > > > > > > > > > > > > >> > > viable option for unblocking the 10 release
> in
> > > the
> > > > > > > > > reasonable
> > > > > > > > > > > time
> > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento
> <
> > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> time,
> > > as
> > > > > this
> > > > > > > > > matter
> > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This email will take you < 20 minutes to
> > read,
> > > > > > > according
> > > > > > > > > to
> > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > thread
> > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > >
> > > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > ),
> > > > > > > > > > > > > >> > > > many of us were working towards removing a
> > > > > circular
> > > > > > > > > > dependency
> > > > > > > > > > > > > >> > > > currently present between `kogito-apps`
> and
> > > > > > > `kie-tools`.
> > > > > > > > > As
> > > > > > > > > > we
> > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > finding
> > > > the
> > > > > > > > > circular
> > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown
> > of
> > > > the
> > > > > > > things
> > > > > > > > > we
> > > > > > > > > > > did,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Right now, even though we started the
> effort
> > > to
> > > > > move
> > > > > > > the
> > > > > > > > > > > Quarkus
> > > > > > > > > > > > > Dev
> > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> > > able
> > > > to
> > > > > > do
> > > > > > > it
> > > > > > > > > > yet,
> > > > > > > > > > > as
> > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> > > Maven
> > > > > > 3.9.6,
> > > > > > > > and
> > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > This
> > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > >> > > >
> > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > .
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > C | 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > Y | 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > >> > > > * and
> > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > depend
> > > > > > > > > > > > > >> on
> > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > `kie-tools`,
> > > > > we
> > > > > > > > > would've
> > > > > > > > > > > > had:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > C |==> 04.
> incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As
> `kie-tools`/kn-plugin-workflow
> > > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > >> > > > * and
> > > `kogito-images`/kogito-swf-devmode
> > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> image
> > to
> > > > > > > > > `kie-tools`,
> > > > > > > > > > we
> > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As
> `kie-tools`/kn-plugin-workflow
> > > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> than
> > a
> > > > > simple
> > > > > > > > > > circular
> > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > > > people,
> > > > > > > it's
> > > > > > > > > been
> > > > > > > > > > > > > really
> > > > > > > > > > > > > >> > > > hard coming up with a simple solution that
> > > makes
> > > > > it
> > > > > > > > > possible
> > > > > > > > > > > to
> > > > > > > > > > > > > >> build
> > > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving
> the
> > > way
> > > > > > > > everyone
> > > > > > > > > is
> > > > > > > > > > > > used
> > > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > contributing to the multiple repositories
> we
> > > > have.
> > > > > > > More
> > > > > > > > > than
> > > > > > > > > > > > that,
> > > > > > > > > > > > > >> > > > while making this assessment, I found more
> > > > > problems
> > > > > > > > that,
> > > > > > > > > in
> > > > > > > > > > > my
> > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > > forward
> > > > > with
> > > > > > > my
> > > > > > > > > > > proposal
> > > > > > > > > > > > > for
> > > > > > > > > > > > > >> > > > the Apache KIE release process, so we can
> > use
> > > > > > Apache's
> > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> > > this
> > > > > > really
> > > > > > > > > > > > complicated
> > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I'll lay out my entire perspective about
> the
> > > > > current
> > > > > > > > > > situation
> > > > > > > > > > > > of
> > > > > > > > > > > > > >> our
> > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > currently
> > > > see.
> > > > > > > I'll
> > > > > > > > > > start
> > > > > > > > > > > > with
> > > > > > > > > > > > > >> an
> > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > purposes,
> > > > > > point
> > > > > > > > out
> > > > > > > > > > > some
> > > > > > > > > > > > > >> > > > problems that I believe are blocking our
> 10
> > > > > release,
> > > > > > > > > explain
> > > > > > > > > > > my
> > > > > > > > > > > > > >> > > > proposal and discuss some consequences to
> > what
> > > > I'm
> > > > > > > > > > proposing.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count:
> 11)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> > > `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-serverless-operator @
> > > > > `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > >> > > > -
> incubator-kie-sandbox-quarkus-accelerator
> > @
> > > > > > `0.0.0`
> > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > >> > > > (Issues only, README should be
> updated @
> > > > > `main`.
> > > > > > > > Same
> > > > > > > > > > for
> > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy
> at
> > > the
> > > > > > > `main`
> > > > > > > > > > > branch.)
> > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`.
> > Push @
> > > > > > > `deploy`
> > > > > > > > to
> > > > > > > > > > > > update
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > sandbox.kie.org
> > > > > and
> > > > > > > KIE
> > > > > > > > > > Tools'
> > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @
> > `main`
> > > > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> > > checks
> > > > > > > during
> > > > > > > > > the
> > > > > > > > > > > > > staging
> > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I grouped the repositories by category,
> and
> > > > listed
> > > > > > > them
> > > > > > > > > in a
> > > > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > > > flattening
> > > > > > > > out a
> > > > > > > > > > > tree,
> > > > > > > > > > > > > >> there
> > > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > > OptaPlanner
> > > > > > > > > > could've
> > > > > > > > > > > > been
> > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > referring
> > > to
> > > > > as
> > > > > > > > > `drools`
> > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner
> is
> > > > inside
> > > > > > > that
> > > > > > > > > > > stream,
> > > > > > > > > > > > as
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > way these repositories reference each
> other
> > > are
> > > > > > > through
> > > > > > > > > > Maven
> > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > 999-SNAPSHOT
> > > > > > > version.
> > > > > > > > > This
> > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > >> > > > is well-known to the team, and although
> > flawed
> > > > for
> > > > > > > > > intra-day
> > > > > > > > > > > > > builds
> > > > > > > > > > > > > >> > > > and disruptive for people in many
> different
> > > time
> > > > > > > zones,
> > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > > > > >> already
> > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> with,
> > I
> > > > > > assume.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > > > dedicated
> > > > > > > > > > > pipelines,
> > > > > > > > > > > > > >> which
> > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> build
> > > > > > cross-repo
> > > > > > > > PRs
> > > > > > > > > > > > > together
> > > > > > > > > > > > > >> > > > and verify that the codebase will continue
> > > > working
> > > > > > as
> > > > > > > > > > expected
> > > > > > > > > > > > > after
> > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > gather,
> > > > > there
> > > > > > > are
> > > > > > > > > some
> > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > cross-repo
> > > > > > PRs.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps,
> and
> > > > > > > > > kogito-examples
> > > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > > > >> > > > - kogito-images, and
> > > kogito-serverless-operator
> > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to
> > any
> > > > > > > > combination
> > > > > > > > > of
> > > > > > > > > > > > repos
> > > > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > > > cannot
> > > > > be
> > > > > > > > > > verified
> > > > > > > > > > > > > before
> > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > dependent
> > > > > on
> > > > > > > > > > individual
> > > > > > > > > > > > > >> > > > contributors building stuff on their
> > machines
> > > to
> > > > > > > verify
> > > > > > > > > that
> > > > > > > > > > > it
> > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > > > pipelines,
> > > > > > > so
> > > > > > > > > > > please
> > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > referring
> > > to
> > > > > as
> > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > > > repository
> > > > > > > > that
> > > > > > > > > > is
> > > > > > > > > > > > used
> > > > > > > > > > > > > >> by
> > > > > > > > > > > > > >> > > > people starting projects from scratch on
> KIE
> > > > > > Sandbox,
> > > > > > > > > > similar
> > > > > > > > > > > > to a
> > > > > > > > > > > > > >> > > > Maven archetype, if you will. The other
> one
> > is
> > > > the
> > > > > > KIE
> > > > > > > > > Tools
> > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> build
> > > > > system.
> > > > > > > > > > > Currently,
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > TypeScript
> > > > > > > > libraries
> > > > > > > > > > and
> > > > > > > > > > > > > apps,
> > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > > > `kie-tools`
> > > > > > > > > > monorepo
> > > > > > > > > > > > is
> > > > > > > > > > > > > >> > > > configured to work with sparse checkouts
> and
> > > can
> > > > > do
> > > > > > > > > partial
> > > > > > > > > > > > > builds.
> > > > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > > > through
> > > > > > > > > > timestamped
> > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > recently
> > > > > > > > introduced
> > > > > > > > > > that
> > > > > > > > > > > > > will
> > > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > > artifacts
> > > > > > > under
> > > > > > > > a
> > > > > > > > > > > > version
> > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> format,
> > > > > > published
> > > > > > > > > weekly
> > > > > > > > > > > > every
> > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > > > evolution
> > > > > > > to
> > > > > > > > > the
> > > > > > > > > > > > Kogito
> > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> release
> > > for
> > > > > all
> > > > > > > of
> > > > > > > > > > Apache
> > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > >> so
> > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > An important note here is that Category B
> > > > > > repositories
> > > > > > > > > have
> > > > > > > > > > > been
> > > > > > > > > > > > > >> > > > historically kept out of any automations
> we
> > > used
> > > > > to
> > > > > > > > have,
> > > > > > > > > > way
> > > > > > > > > > > > back
> > > > > > > > > > > > > >> > > > when Kogito started and we had the
> Business
> > > > > Central
> > > > > > > > > (a.k.a.
> > > > > > > > > > > v7)
> > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > >> > > > still going on. For this reason, Category
> B
> > > > > projects
> > > > > > > > have
> > > > > > > > > > > > > developed
> > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > Actions.
> > > > > > > > Category B
> > > > > > > > > > > repos
> > > > > > > > > > > > > >> have
> > > > > > > > > > > > > >> > > > always depended on Category A repos using
> > > fixed
> > > > > > > > versions.
> > > > > > > > > If
> > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> SNAPSHOTs,
> > > > > breaking
> > > > > > > > > changes
> > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > > potential
> > > > > > to
> > > > > > > > > break
> > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > > > development
> > > > > > > > > > stream,
> > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > maintainers
> > > > > of
> > > > > > > > > > Category B
> > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > >> > > > as historically Category A contributors
> were
> > > not
> > > > > > > > familiar
> > > > > > > > > > with
> > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > > > through
> > > > > a
> > > > > > > > GitHub
> > > > > > > > > > > > Actions
> > > > > > > > > > > > > >> > > > workflow that builds the relevant part of
> > the
> > > > > > > > `kie-tools`
> > > > > > > > > > > > monorepo
> > > > > > > > > > > > > >> for
> > > > > > > > > > > > > >> > > > the changes introduced. Changes made to
> the
> > > > > pipeline
> > > > > > > > > itself
> > > > > > > > > > > are
> > > > > > > > > > > > > also
> > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to
> do
> > > > things
> > > > > > > like
> > > > > > > > > > > > atomically
> > > > > > > > > > > > > >> > > > bumping the Node.js version, for example.
> > More
> > > > > > > > > importantly,
> > > > > > > > > > it
> > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > timestamped
> > > > > > > > SNAPSHOT
> > > > > > > > > > > > > together
> > > > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > > > green.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This setup, however, makes it impossible
> to
> > > have
> > > > > > > > > cross-repo
> > > > > > > > > > > PRs
> > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > simultaneously,
> > > > > > > with
> > > > > > > > > the
> > > > > > > > > > > > > current
> > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > around,
> > > > and
> > > > > > I'm
> > > > > > > > not
> > > > > > > > > > sure
> > > > > > > > > > > > if
> > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > Regardless,
> > > > > as
> > > > > > > > > they're
> > > > > > > > > > > > part
> > > > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > release,
> > > > so I
> > > > > > > > listed
> > > > > > > > > > them
> > > > > > > > > > > > for
> > > > > > > > > > > > > >> us
> > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category D is self explanatory. There's
> only
> > > one
> > > > > > repo
> > > > > > > > that
> > > > > > > > > > has
> > > > > > > > > > > > > >> already
> > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > > > directly,
> > > > > > > and
> > > > > > > > > are
> > > > > > > > > > > > > either
> > > > > > > > > > > > > >> > > > organizational entities, or host websites,
> > > that
> > > > > > > > currently
> > > > > > > > > > are
> > > > > > > > > > > > not
> > > > > > > > > > > > > >> part
> > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This lack of unification between Category
> A
> > > and
> > > > > > > > Category B
> > > > > > > > > > is,
> > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > > > circular
> > > > > > > > > > dependency
> > > > > > > > > > > > > >> between
> > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we
> now
> > > can
> > > > > > > describe
> > > > > > > > > as
> > > > > > > > > > a
> > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > >> > > > dependency between Category A and Category
> > B.
> > > > The
> > > > > > way
> > > > > > > I
> > > > > > > > > see
> > > > > > > > > > > it,
> > > > > > > > > > > > if
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > had a single pipeline, building everything
> > > from
> > > > > > > `drools`
> > > > > > > > > to
> > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> been
> > > > > > > introduced,
> > > > > > > > > and
> > > > > > > > > > we
> > > > > > > > > > > > > >> > > > wouldn't be having this huge problem in
> our
> > > > hands
> > > > > > > right
> > > > > > > > > now.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > process
> > > > > sees
> > > > > > > this
> > > > > > > > > > lack
> > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > unification as a central problem, not only
> > for
> > > > > this
> > > > > > > > > release
> > > > > > > > > > in
> > > > > > > > > > > > > >> > > > particular, but for the community as a
> > whole.
> > > It
> > > > > is
> > > > > > my
> > > > > > > > > > belief
> > > > > > > > > > > > that
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > > contribution
> > > > > > > > > should
> > > > > > > > > > > be
> > > > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> > > With
> > > > > the
> > > > > > > > > > increasing
> > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > contributors
> > > > too,
> > > > > > we
> > > > > > > > > cannot
> > > > > > > > > > > > keep
> > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> breaking
> > > > > things.
> > > > > > > > We're
> > > > > > > > > > all
> > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > mechanisms
> > > > in
> > > > > > > place
> > > > > > > > > to
> > > > > > > > > > > > > prevent
> > > > > > > > > > > > > >> us
> > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> Especially
> > > > when
> > > > > > > these
> > > > > > > > > > > mistakes
> > > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > > individually,
> > > > > > > > > > > probably
> > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > depending
> > > on
> > > > > > > > > kiegroup's
> > > > > > > > > > > KIE
> > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > `kogito-images`
> > > > > > > > > > depending
> > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > > > kiegroup's
> > > > > > > > > > `lienzo`
> > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > `7.59.0.Final`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > depending
> > > > on
> > > > > > > > > > kiegroup's
> > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > codebase
> > > > > > here:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >
> > > > > > > >
> > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > ,
> > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > OptaPlanner,
> > > > > > > > > pointing
> > > > > > > > > > to
> > > > > > > > > > > > > older
> > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P5.
> > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > depending
> > > > > > > > > on
> > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P6. Category C repos are out of date and
> not
> > > > part
> > > > > of
> > > > > > > the
> > > > > > > > > > > > Category
> > > > > > > > > > > > > A
> > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> (Current
> > > > > version
> > > > > > is
> > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > version,
> > > > > only
> > > > > > > by
> > > > > > > > > > using
> > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> version
> > > is
> > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > OptaPlanner
> > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P7.
> `kie-tools`/packages/kn-plugin-workflow
> > > has
> > > > > its
> > > > > > > E2E
> > > > > > > > > > > disabled
> > > > > > > > > > > > > >> after
> > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > > > solution,
> > > > > > > as
> > > > > > > > > they
> > > > > > > > > > > > both
> > > > > > > > > > > > > >> > > > suffer from the circular dependency
> between
> > > > > > Category A
> > > > > > > > and
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > >> > > > As Category A and Category B are both
> > streams
> > > > that
> > > > > > > have
> > > > > > > > > been
> > > > > > > > > > > > > really
> > > > > > > > > > > > > >> > > > active, I see this as a blocker, as there
> > are
> > > > > > > > > contributions
> > > > > > > > > > > that
> > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> > depends
> > > on
> > > > > > > > Category
> > > > > > > > > B
> > > > > > > > > > > > with a
> > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > understood
> > > > > as
> > > > > > > > > > technical
> > > > > > > > > > > > > debt.
> > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > something
> > > > > > we'll
> > > > > > > > > always
> > > > > > > > > > > be
> > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> just a
> > > > > matter
> > > > > > of
> > > > > > > > > > making
> > > > > > > > > > > > them
> > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> impact
> > > the
> > > > > > > > structure
> > > > > > > > > or
> > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > > > regression
> > > > > > > we
> > > > > > > > > > > > > introduced
> > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> Apache
> > > KIE
> > > > > 10,
> > > > > > > and
> > > > > > > > > > that
> > > > > > > > > > > > P5,
> > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems
> > left
> > > > to
> > > > > > > > discuss
> > > > > > > > > > are
> > > > > > > > > > > P1
> > > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > > > proposal.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> > > from
> > > > my
> > > > > > > > > > experience,
> > > > > > > > > > > > any
> > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> > release
> > > > not
> > > > > > > > working
> > > > > > > > > > out
> > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > possible,
> > > > > and
> > > > > > > make
> > > > > > > > > > > > > everything
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > release,
> > > > > bear
> > > > > > > > with
> > > > > > > > > > me.
> > > > > > > > > > > > I'll
> > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > >> > > > out a timeline of events that need to
> happen
> > > in
> > > > > > order
> > > > > > > > for
> > > > > > > > > > our
> > > > > > > > > > > > > >> release
> > > > > > > > > > > > > >> > > > to be published, with all artifacts ending
> > up
> > > in
> > > > > the
> > > > > > > > right
> > > > > > > > > > > > places,
> > > > > > > > > > > > > >> but
> > > > > > > > > > > > > >> > > > first, we need to solve problems P1 and
> P2.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As you saw at the beginning of this email,
> > all
> > > > the
> > > > > > > > > attempts
> > > > > > > > > > we
> > > > > > > > > > > > > made
> > > > > > > > > > > > > >> > > > left us with the circular dependency
> showing
> > > up
> > > > > at a
> > > > > > > > > > different
> > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > >> > > > but something all these places have in
> > common
> > > is
> > > > > > that
> > > > > > > > > > they're
> > > > > > > > > > > > all
> > > > > > > > > > > > > >> > > > after kogito-apps, and before to Category
> B.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > following:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > S1. We keep the original plan of moving
> the
> > > > > Quarkus
> > > > > > > Dev
> > > > > > > > > UIs
> > > > > > > > > > > from
> > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> with
> > > > > > Management
> > > > > > > > and
> > > > > > > > > > > Task
> > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> > `kie-tools`.
> > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > images
> > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > `kogito-serverless-operator`
> > > > > > > repo
> > > > > > > > > > > inside
> > > > > > > > > > > > a
> > > > > > > > > > > > > >> new
> > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> history.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> > > problems
> > > > > P1
> > > > > > > and
> > > > > > > > > P2.
> > > > > >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Tibor Zimányi <tz...@apache.org>.
Hi everyone,
I just want to remind everyone, that we have not released a release for
more than half a year (6 months). We are being constantly asked, when will
we release a new release, due to multiple reasons. E.g. Quarkus 3 support,
newer Java support etc. Keep in mind that the current release, that is out,
is outdated on many fronts, e.g. security, as it contains outdated
dependencies and frameworks support. I even heard the need to have a
release internally, from our commiters members, because they need it for
their projects that they are working on, and they are blocked, until we
have a new release. So I personally think we cannot solve the current
problem now. As Alex mentioned, I would also suggest to fix it for now as
it is proposed. After the release, we can discuss whatever we want, to fix
it properly. But we need to finally have a release. Everyone involved put
great effort to this (including people discussing in this thread), so I
have the feeling postponing the release for another two or more months will
just grow frustration within the community.
Please keep this all in mind. I think everyone would like to fix this
properly. However sometimes doing that just doesn't help at all at the
moment. Sometimes a temporary solution is better in my opinion.
Best regards,
Tibor
Dňa st 13. 3. 2024, 14:12 Alex Porcelli <po...@apache.org> napísal(a):
> Francisco,
>
> Please feel free to open a new thread with such a proposal, although I
> still consider that it’s necessary more details to be properly evaluated.
>
> Keep in mind that CI code, configs and infrastructure is accessible for all
> committers.
>
> Please let’s keep this thread focused on the detailed proposal shared.
>
> In case of multiple proposals we can start an official vote.
>
>
> On Wed, Mar 13, 2024 at 9:05 AM Francisco Javier Tirado Sarti <
> ftirados@redhat.com> wrote:
>
> > I hardly see a difference in detail between the proposal to move
> > kn-workflow module from tooling to images (it should have never been in
> > tooling repo) plus changing CI stream to compile tooling repo before
> images
> > repo (which I hope we all agree is the natural order) and the proposal to
> > move all stuff from images that depends on tooling to tooling repo
> (which I
> > hope we all agree hardly fits in current multi repo structure) and sort
> > out the "details" on the ci pipeline associated to that repo (which
> implies
> > CI knowledge after all)
> > The key point here is, does Tiago (as tooling SME, it seems that there
> is a
> > tools team but there is not a drools team ;)) agree that tooling should
> be
> > executed before images because there is a logical dependency between
> images
> > and tooling?
> > In my opinion, the least we can do is to explore how it really costs to
> > change CI to execute tooling before images.
> >
> >
> > On Wed, Mar 13, 2024 at 1:36 PM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > Francisco and Gabriele,
> > >
> > > I understand and acknowledge your desire to find the “right” solution
> > > instead to work on a temporary “patch” - however without a detailed
> > > proposal I don’t think we can properly evaluate the impact of your
> > > suggestion.
> > >
> > > When I spoke with different SMEs that included tools and CI, the
> > > guesstimate for making the necessary changes on CI and codebase to
> > > basically have images and operators in the end of the build chain is
> > > something like 2 months of effort. Another impact that needs to be
> > > discussed is that KIE Tools repo had to be injected in the middle of
> all
> > > pipelines - forcing all PR checks and nightlies to build all repos (PR
> > > checks will likely take 12+ hours… I even heard that it could be even
> 24
> > > hours).
> > >
> > > Based on the input above, I think it’s quite risk to move in such
> > direction
> > > without a more detailed plan… because 2 months could be turned easily
> in
> > 6!
> > > And this is exactly what happened when we guessed that moving to Apache
> > > would take no more than 3 months. But here we are.
> > >
> > > I really strongly suggest that we focus on a release that could be
> > > achievable in less than a month from now, and we - after release -
> have a
> > > in depth discussion about the overall codebase and ci organization.
> > >
> > >
> > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > gabriele.cardosi@gmail.com>
> > > wrote:
> > >
> > > > Alex,
> > > > my suggestion is to move the building of all docker images, from
> > whatever
> > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > > > invoked after all the others.
> > > > I'm not sure if this would solve all the issues, and since I could
> not
> > > > enter in the details of all the involved code, my suggestion may be
> too
> > > > naive.
> > > > Having spent almost all of the last year in CI, I may say that, at
> > least
> > > > for the kie-tools repo, removing the image build step from it should
> > not
> > > be
> > > > too difficult (since it is an issue we already faced and solved).
> > > > If, with "detailed proposal", you mean a complete list of all modules
> > to
> > > be
> > > > moved and dependency refactoring, of course I can not provide it
> right
> > > now.
> > > >
> > > > Anyway, I share the concern from Francisco: undoing something is
> almost
> > > > always harder than doing it "rightly" from scratch...
> > > >
> > > >
> > > >
> > > >
> > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado
> Sarti
> > <
> > > > ftirados@redhat.com> ha scritto:
> > > >
> > > > > I do not think estimations should be the only driver to make a
> > > decision,
> > > > > especially when the current proposal is conceptually incompatible
> > with
> > > > the
> > > > > multi repo approach that is taken elsewhere in the project.
> > > > > Given my knowledge of the CI it is nearly impossible for me to
> give
> > a
> > > > fair
> > > > > estimate of how much it might take to achieve step 2) of my
> previous
> > > > e-mail
> > > > > . It might take a while or it might be pretty easy after all, I
> don't
> > > > > really know, but I think it will be a good idea if some of the
> > experts
> > > > on
> > > > > CI in the team (the ones that set up the pipeline, which was a huge
> > > > > achievement) give an estimate, not me. Estimating how much it
> takes
> > to
> > > > > merge two existing repos (without altering CI) is easier, but it
> does
> > > not
> > > > > mean we are doing the right thing.
> > > > > My main concern is that it will be very difficult for me to explain
> > to
> > > > > someone that arrives new to the team, that having experts on CI on
> > the
> > > > > team, we decided to merge two repos (once merged, it would be
> rather
> > > > > difficult to unmerge) rather than fix the CI, because of
> expediency.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> porcelli@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Francisco,
> > > > > >
> > > > > > Please take the time to make the more in depth analysis needed
> and
> > > > > provide
> > > > > > a more detailed plan… so we - as community- can evaluate the size
> > of
> > > > the
> > > > > > effort. In the conceptual level you shared it’s near impossible
> to
> > > > > estimate
> > > > > > the size of the effort and compare with the current proposal.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > > ftirados@redhat.com> wrote:
> > > > > >
> > > > > > > I think I already did a high level proposal.
> > > > > > > 1) Remove all dependencies from tooling to images, so images
> > > depend
> > > > on
> > > > > > > tooling but tooling does not depend on images.
> > > > > > > 2) Then change CI to deal with tooling repo before dealing with
> > > > images
> > > > > > > repo.
> > > > > > > I understand that CI details are tricky and since I'm not
> > familiar
> > > > with
> > > > > > CI
> > > > > > > in any way, I barely can make a low level design, but we do not
> > > need
> > > > to
> > > > > > fix
> > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> alex@porcelli.me
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Francisco and Grabriele,
> > > > > > > >
> > > > > > > > You may not like or understand why the current state of the
> CI
> > is
> > > > > like
> > > > > > > > that… actually has been in Red Hat and has been replicated in
> > > > Apache
> > > > > as
> > > > > > > > used to be….
> > > > > > > >
> > > > > > > > But the fact is that this is the current reality.
> > > > > > > >
> > > > > > > > If you disagree with the current plan, please provide a
> > detailed
> > > > > > > > alternative so we, as community, can better evaluate the pros
> > and
> > > > > cons
> > > > > > of
> > > > > > > > each proposal.
> > > > > > > >
> > > > > > > >
> > > > > > > > I think it’s also fair to say that, post 10 release we need
> to
> > > > have a
> > > > > > > much
> > > > > > > > in depth discussion about how our codebase is organized, it’s
> > > clear
> > > > > > that
> > > > > > > > it’s not working.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > As Francisco said,
> > > > > > > > > I also have the impression that the "images" (if we are
> > talking
> > > > of
> > > > > > > docker
> > > > > > > > > images) should be the very last one to be built, in a
> > > standalone
> > > > > > repo.
> > > > > > > > > That way, they may "combine" artifacts that are built in
> > > > different
> > > > > > > repos,
> > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> > maybe
> > > > > could
> > > > > > > > > simplify the situation a bit.
> > > > > > > > > (I also think there are some statements of undisputable
> needs
> > > > while
> > > > > > > they
> > > > > > > > > are, actually, just technical choices.
> > > > > > > > > Anyway, this latter point is for longer, following,
> > > discussion.)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > > Tirado
> > > > > > Sarti
> > > > > > > <
> > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > >
> > > > > > > > > > Alex,
> > > > > > > > > > There are two assumptions that deserve further
> discussion:
> > > > > > > > > > 1) That tool has to be the last to build. why? it does
> not
> > > have
> > > > > > more
> > > > > > > > > sense
> > > > > > > > > > to build final images after everything else has been
> > built?-
> > > > > > > > > > 2) That the impact (in terms of effort now) on fixing CI
> is
> > > > > bigger
> > > > > > > than
> > > > > > > > > the
> > > > > > > > > > impact (long term consequences) of consolidating two
> > > unrelated
> > > > > > piece
> > > > > > > of
> > > > > > > > > > software within the same repository.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > alex@porcelli.me
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Francisco,
> > > > > > > > > > >
> > > > > > > > > > > This was discussed as an alternative solution, however
> it
> > > has
> > > > > > major
> > > > > > > > > > impact
> > > > > > > > > > > on CI and there’s also the fact Tool has been always
> the
> > > last
> > > > > to
> > > > > > > > build
> > > > > > > > > > and
> > > > > > > > > > > has no Snapshot published (actually in JavaScript world
> > > there
> > > > > is
> > > > > > no
> > > > > > > > > > > snapshot concept).
> > > > > > > > > > >
> > > > > > > > > > > So, based on our evaluation… the proposal here is the
> > least
> > > > > > > > disruptive
> > > > > > > > > > and
> > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > _____________
> > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > http://porcelli.me
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > > > Sarti <
> > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > After kie-tools, sorry. I think we are not embracing
> > the
> > > > fact
> > > > > > > that
> > > > > > > > > > > > kogito-images depend on kie-tools, because we want
> > those
> > > > > images
> > > > > > > to
> > > > > > > > > > > include
> > > > > > > > > > > > tools.
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > Tirado
> > > > > Sarti
> > > > > > <
> > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > It can be an alternative solution to move
> > > > > kn-plugin-workflow
> > > > > > to
> > > > > > > > > > > > > kogito-images (so there is not longer dependency
> from
> > > > tools
> > > > > > to
> > > > > > > > > > images)
> > > > > > > > > > > > and
> > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > > Martinez
> > > > > <
> > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> (apache)
> > <
> > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > > alex@porcelli.me
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > I spent the last day or so working closely
> with
> > > > Tiago,
> > > > > > > > > exploring
> > > > > > > > > > > > >> > different
> > > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > > evaluating
> > > > > > > the
> > > > > > > > > > > overall
> > > > > > > > > > > > >> > release
> > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > proposal
> > > > as
> > > > > > the
> > > > > > > > > most
> > > > > > > > > > > > >> > > viable option for unblocking the 10 release in
> > the
> > > > > > > > reasonable
> > > > > > > > > > time
> > > > > > > > > > > > >> frame.
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time,
> > as
> > > > this
> > > > > > > > matter
> > > > > > > > > > > > >> requires a
> > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This email will take you < 20 minutes to
> read,
> > > > > > according
> > > > > > > > to
> > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > As you may have followed on a separate
> thread
> > > > > > > > > > > > >> > > > (
> > > > > > > > > > >
> > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > ),
> > > > > > > > > > > > >> > > > many of us were working towards removing a
> > > > circular
> > > > > > > > > dependency
> > > > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > > > `kie-tools`.
> > > > > > > > As
> > > > > > > > > we
> > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> finding
> > > the
> > > > > > > > circular
> > > > > > > > > > > > >> dependency
> > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown
> of
> > > the
> > > > > > things
> > > > > > > > we
> > > > > > > > > > did,
> > > > > > > > > > > > and
> > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Right now, even though we started the effort
> > to
> > > > move
> > > > > > the
> > > > > > > > > > Quarkus
> > > > > > > > > > > > Dev
> > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> > able
> > > to
> > > > > do
> > > > > > it
> > > > > > > > > yet,
> > > > > > > > > > as
> > > > > > > > > > > > >> we've
> > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> > Maven
> > > > > 3.9.6,
> > > > > > > and
> > > > > > > > > > > Quarkus
> > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > This
> > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > >> > > >
> > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > .
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > C | 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > Y | 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > >> > > > * and
> > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > depend
> > > > > > > > > > > > >> on
> > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > `kie-tools`,
> > > > we
> > > > > > > > would've
> > > > > > > > > > > had:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > >> > > > * and
> > `kogito-images`/kogito-swf-devmode
> > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image
> to
> > > > > > > > `kie-tools`,
> > > > > > > > > we
> > > > > > > > > > > > >> would've
> > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem than
> a
> > > > simple
> > > > > > > > > circular
> > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > > people,
> > > > > > it's
> > > > > > > > been
> > > > > > > > > > > > really
> > > > > > > > > > > > >> > > > hard coming up with a simple solution that
> > makes
> > > > it
> > > > > > > > possible
> > > > > > > > > > to
> > > > > > > > > > > > >> build
> > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving the
> > way
> > > > > > > everyone
> > > > > > > > is
> > > > > > > > > > > used
> > > > > > > > > > > > to
> > > > > > > > > > > > >> > > > contributing to the multiple repositories we
> > > have.
> > > > > > More
> > > > > > > > than
> > > > > > > > > > > that,
> > > > > > > > > > > > >> > > > while making this assessment, I found more
> > > > problems
> > > > > > > that,
> > > > > > > > in
> > > > > > > > > > my
> > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > forward
> > > > with
> > > > > > my
> > > > > > > > > > proposal
> > > > > > > > > > > > for
> > > > > > > > > > > > >> > > > the Apache KIE release process, so we can
> use
> > > > > Apache's
> > > > > > > > > > > mechanisms
> > > > > > > > > > > > to
> > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> > this
> > > > > really
> > > > > > > > > > > complicated
> > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > > > current
> > > > > > > > > situation
> > > > > > > > > > > of
> > > > > > > > > > > > >> our
> > > > > > > > > > > > >> > > > codebase, as well as problems I can
> currently
> > > see.
> > > > > > I'll
> > > > > > > > > start
> > > > > > > > > > > with
> > > > > > > > > > > > >> an
> > > > > > > > > > > > >> > > > analysis of the repositories and their
> > purposes,
> > > > > point
> > > > > > > out
> > > > > > > > > > some
> > > > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > > > release,
> > > > > > > > explain
> > > > > > > > > > my
> > > > > > > > > > > > >> > > > proposal and discuss some consequences to
> what
> > > I'm
> > > > > > > > > proposing.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> > `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > > > `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator
> @
> > > > > `0.0.0`
> > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > >> > > > (Issues only, README should be updated @
> > > > `main`.
> > > > > > > Same
> > > > > > > > > for
> > > > > > > > > > > > GitHub
> > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy at
> > the
> > > > > > `main`
> > > > > > > > > > branch.)
> > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`.
> Push @
> > > > > > `deploy`
> > > > > > > to
> > > > > > > > > > > update
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > > >> > > > (GitHub pages used to host
> > sandbox.kie.org
> > > > and
> > > > > > KIE
> > > > > > > > > Tools'
> > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @
> `main`
> > > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> > checks
> > > > > > during
> > > > > > > > the
> > > > > > > > > > > > staging
> > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I grouped the repositories by category, and
> > > listed
> > > > > > them
> > > > > > > > in a
> > > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > > flattening
> > > > > > > out a
> > > > > > > > > > tree,
> > > > > > > > > > > > >> there
> > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > OptaPlanner
> > > > > > > > > could've
> > > > > > > > > > > been
> > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category A repos are what I've been
> referring
> > to
> > > > as
> > > > > > > > `drools`
> > > > > > > > > > and
> > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is
> > > inside
> > > > > > that
> > > > > > > > > > stream,
> > > > > > > > > > > as
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> > > > way these repositories reference each other
> > are
> > > > > > through
> > > > > > > > > Maven
> > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> 999-SNAPSHOT
> > > > > > version.
> > > > > > > > This
> > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > >> > > > is well-known to the team, and although
> flawed
> > > for
> > > > > > > > intra-day
> > > > > > > > > > > > builds
> > > > > > > > > > > > >> > > > and disruptive for people in many different
> > time
> > > > > > zones,
> > > > > > > it
> > > > > > > > > is
> > > > > > > > > > > > >> already
> > > > > > > > > > > > >> > > > very comfortable for everyone to work with,
> I
> > > > > assume.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > > dedicated
> > > > > > > > > > pipelines,
> > > > > > > > > > > > >> which
> > > > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > > > cross-repo
> > > > > > > PRs
> > > > > > > > > > > > together
> > > > > > > > > > > > >> > > > and verify that the codebase will continue
> > > working
> > > > > as
> > > > > > > > > expected
> > > > > > > > > > > > after
> > > > > > > > > > > > >> > > > they're all merged. From what I could
> gather,
> > > > there
> > > > > > are
> > > > > > > > some
> > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > cross-repo
> > > > > PRs.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > > > kogito-examples
> > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > > >> > > > - kogito-images, and
> > kogito-serverless-operator
> > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to
> any
> > > > > > > combination
> > > > > > > > of
> > > > > > > > > > > repos
> > > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > > cannot
> > > > be
> > > > > > > > > verified
> > > > > > > > > > > > before
> > > > > > > > > > > > >> > > > merging, making our contribution model
> > dependent
> > > > on
> > > > > > > > > individual
> > > > > > > > > > > > >> > > > contributors building stuff on their
> machines
> > to
> > > > > > verify
> > > > > > > > that
> > > > > > > > > > it
> > > > > > > > > > > > >> works.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > > pipelines,
> > > > > > so
> > > > > > > > > > please
> > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category B repos are what I've been
> referring
> > to
> > > > as
> > > > > > > > > > `kie-tools`
> > > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > > repository
> > > > > > > that
> > > > > > > > > is
> > > > > > > > > > > used
> > > > > > > > > > > > >> by
> > > > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > > > Sandbox,
> > > > > > > > > similar
> > > > > > > > > > > to a
> > > > > > > > > > > > >> > > > Maven archetype, if you will. The other one
> is
> > > the
> > > > > KIE
> > > > > > > > Tools
> > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > > > system.
> > > > > > > > > > Currently,
> > > > > > > > > > > > KIE
> > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > TypeScript
> > > > > > > libraries
> > > > > > > > > and
> > > > > > > > > > > > apps,
> > > > > > > > > > > > >> Go
> > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > > `kie-tools`
> > > > > > > > > monorepo
> > > > > > > > > > > is
> > > > > > > > > > > > >> > > > configured to work with sparse checkouts and
> > can
> > > > do
> > > > > > > > partial
> > > > > > > > > > > > builds.
> > > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > > through
> > > > > > > > > timestamped
> > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> recently
> > > > > > > introduced
> > > > > > > > > that
> > > > > > > > > > > > will
> > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > artifacts
> > > > > > under
> > > > > > > a
> > > > > > > > > > > version
> > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > > > published
> > > > > > > > weekly
> > > > > > > > > > > every
> > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > > evolution
> > > > > > to
> > > > > > > > the
> > > > > > > > > > > Kogito
> > > > > > > > > > > > >> > > > releases, as we're now targeting one release
> > for
> > > > all
> > > > > > of
> > > > > > > > > Apache
> > > > > > > > > > > > KIE,
> > > > > > > > > > > > >> so
> > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > An important note here is that Category B
> > > > > repositories
> > > > > > > > have
> > > > > > > > > > been
> > > > > > > > > > > > >> > > > historically kept out of any automations we
> > used
> > > > to
> > > > > > > have,
> > > > > > > > > way
> > > > > > > > > > > back
> > > > > > > > > > > > >> > > > when Kogito started and we had the Business
> > > > Central
> > > > > > > > (a.k.a.
> > > > > > > > > > v7)
> > > > > > > > > > > > >> stream
> > > > > > > > > > > > >> > > > still going on. For this reason, Category B
> > > > projects
> > > > > > > have
> > > > > > > > > > > > developed
> > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > Actions.
> > > > > > > Category B
> > > > > > > > > > repos
> > > > > > > > > > > > >> have
> > > > > > > > > > > > >> > > > always depended on Category A repos using
> > fixed
> > > > > > > versions.
> > > > > > > > If
> > > > > > > > > > > > >> Category
> > > > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > > > breaking
> > > > > > > > changes
> > > > > > > > > > on
> > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > potential
> > > > > to
> > > > > > > > break
> > > > > > > > > > > > >> Category B
> > > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > > development
> > > > > > > > > stream,
> > > > > > > > > > > and
> > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > maintainers
> > > > of
> > > > > > > > > Category B
> > > > > > > > > > > > >> repos,
> > > > > > > > > > > > >> > > > as historically Category A contributors were
> > not
> > > > > > > familiar
> > > > > > > > > with
> > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > > through
> > > > a
> > > > > > > GitHub
> > > > > > > > > > > Actions
> > > > > > > > > > > > >> > > > workflow that builds the relevant part of
> the
> > > > > > > `kie-tools`
> > > > > > > > > > > monorepo
> > > > > > > > > > > > >> for
> > > > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > > > pipeline
> > > > > > > > itself
> > > > > > > > > > are
> > > > > > > > > > > > also
> > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do
> > > things
> > > > > > like
> > > > > > > > > > > atomically
> > > > > > > > > > > > >> > > > bumping the Node.js version, for example.
> More
> > > > > > > > importantly,
> > > > > > > > > it
> > > > > > > > > > > > >> allows
> > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > timestamped
> > > > > > > SNAPSHOT
> > > > > > > > > > > > together
> > > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > > green.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This setup, however, makes it impossible to
> > have
> > > > > > > > cross-repo
> > > > > > > > > > PRs
> > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > simultaneously,
> > > > > > with
> > > > > > > > the
> > > > > > > > > > > > current
> > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category C repos are kind of floating
> around,
> > > and
> > > > > I'm
> > > > > > > not
> > > > > > > > > sure
> > > > > > > > > > > if
> > > > > > > > > > > > >> > > > there's much activity going on there.
> > > Regardless,
> > > > as
> > > > > > > > they're
> > > > > > > > > > > part
> > > > > > > > > > > > of
> > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> release,
> > > so I
> > > > > > > listed
> > > > > > > > > them
> > > > > > > > > > > for
> > > > > > > > > > > > >> us
> > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category D is self explanatory. There's only
> > one
> > > > > repo
> > > > > > > that
> > > > > > > > > has
> > > > > > > > > > > > >> already
> > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > > directly,
> > > > > > and
> > > > > > > > are
> > > > > > > > > > > > either
> > > > > > > > > > > > >> > > > organizational entities, or host websites,
> > that
> > > > > > > currently
> > > > > > > > > are
> > > > > > > > > > > not
> > > > > > > > > > > > >> part
> > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This lack of unification between Category A
> > and
> > > > > > > Category B
> > > > > > > > > is,
> > > > > > > > > > > > IMHO,
> > > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > > circular
> > > > > > > > > dependency
> > > > > > > > > > > > >> between
> > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now
> > can
> > > > > > describe
> > > > > > > > as
> > > > > > > > > a
> > > > > > > > > > > > >> circular
> > > > > > > > > > > > >> > > > dependency between Category A and Category
> B.
> > > The
> > > > > way
> > > > > > I
> > > > > > > > see
> > > > > > > > > > it,
> > > > > > > > > > > if
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > had a single pipeline, building everything
> > from
> > > > > > `drools`
> > > > > > > > to
> > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > > > introduced,
> > > > > > > > and
> > > > > > > > > we
> > > > > > > > > > > > >> > > > wouldn't be having this huge problem in our
> > > hands
> > > > > > right
> > > > > > > > now.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> process
> > > > sees
> > > > > > this
> > > > > > > > > lack
> > > > > > > > > > of
> > > > > > > > > > > > >> > > > unification as a central problem, not only
> for
> > > > this
> > > > > > > > release
> > > > > > > > > in
> > > > > > > > > > > > >> > > > particular, but for the community as a
> whole.
> > It
> > > > is
> > > > > my
> > > > > > > > > belief
> > > > > > > > > > > that
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > contribution
> > > > > > > > should
> > > > > > > > > > be
> > > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> > With
> > > > the
> > > > > > > > > increasing
> > > > > > > > > > > > >> volume
> > > > > > > > > > > > >> > > > of code, and hopefully number of
> contributors
> > > too,
> > > > > we
> > > > > > > > cannot
> > > > > > > > > > > keep
> > > > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > > > things.
> > > > > > > We're
> > > > > > > > > all
> > > > > > > > > > > > >> humans
> > > > > > > > > > > > >> > > > after all, and it is our job to have
> > mechanisms
> > > in
> > > > > > place
> > > > > > > > to
> > > > > > > > > > > > prevent
> > > > > > > > > > > > >> us
> > > > > > > > > > > > >> > > > from unwillingly making mistakes. Especially
> > > when
> > > > > > these
> > > > > > > > > > mistakes
> > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > individually,
> > > > > > > > > > probably
> > > > > > > > > > > > >> can't
> > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> depending
> > on
> > > > > > > > kiegroup's
> > > > > > > > > > KIE
> > > > > > > > > > > > >> Tools
> > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > `kogito-images`
> > > > > > > > > depending
> > > > > > > > > > on
> > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > > kiegroup's
> > > > > > > > > `lienzo`
> > > > > > > > > > > and
> > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > `7.59.0.Final`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > depending
> > > on
> > > > > > > > > kiegroup's
> > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > codebase
> > > > > here:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > >
> > > > > > >
> > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > ,
> > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > OptaPlanner,
> > > > > > > > pointing
> > > > > > > > > to
> > > > > > > > > > > > older
> > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P5.
> > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > depending
> > > > > > > > on
> > > > > > > > > > > > Kogito
> > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P6. Category C repos are out of date and not
> > > part
> > > > of
> > > > > > the
> > > > > > > > > > > Category
> > > > > > > > > > > > A
> > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > > > version
> > > > > is
> > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > version,
> > > > only
> > > > > > by
> > > > > > > > > using
> > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version
> > is
> > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > OptaPlanner
> > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow
> > has
> > > > its
> > > > > > E2E
> > > > > > > > > > disabled
> > > > > > > > > > > > >> after
> > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > > solution,
> > > > > > as
> > > > > > > > they
> > > > > > > > > > > both
> > > > > > > > > > > > >> > > > suffer from the circular dependency between
> > > > > Category A
> > > > > > > and
> > > > > > > > > > > > Category
> > > > > > > > > > > > >> B.
> > > > > > > > > > > > >> > > > As Category A and Category B are both
> streams
> > > that
> > > > > > have
> > > > > > > > been
> > > > > > > > > > > > really
> > > > > > > > > > > > >> > > > active, I see this as a blocker, as there
> are
> > > > > > > > contributions
> > > > > > > > > > that
> > > > > > > > > > > > >> > > > cannot be done, given that Category A
> depends
> > on
> > > > > > > Category
> > > > > > > > B
> > > > > > > > > > > with a
> > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > understood
> > > > as
> > > > > > > > > technical
> > > > > > > > > > > > debt.
> > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > something
> > > > > we'll
> > > > > > > > always
> > > > > > > > > > be
> > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > > > matter
> > > > > of
> > > > > > > > > making
> > > > > > > > > > > them
> > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P7 is an isolated problem that won't impact
> > the
> > > > > > > structure
> > > > > > > > or
> > > > > > > > > > > > >> anything
> > > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > > regression
> > > > > > we
> > > > > > > > > > > > introduced
> > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache
> > KIE
> > > > 10,
> > > > > > and
> > > > > > > > > that
> > > > > > > > > > > P5,
> > > > > > > > > > > > >> P6,
> > > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems
> left
> > > to
> > > > > > > discuss
> > > > > > > > > are
> > > > > > > > > > P1
> > > > > > > > > > > > and
> > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > > proposal.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> > from
> > > my
> > > > > > > > > experience,
> > > > > > > > > > > any
> > > > > > > > > > > > >> > > > little miscalculation can lead to our
> release
> > > not
> > > > > > > working
> > > > > > > > > out
> > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > possible,
> > > > and
> > > > > > make
> > > > > > > > > > > > everything
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > release,
> > > > bear
> > > > > > > with
> > > > > > > > > me.
> > > > > > > > > > > I'll
> > > > > > > > > > > > >> lay
> > > > > > > > > > > > >> > > > out a timeline of events that need to happen
> > in
> > > > > order
> > > > > > > for
> > > > > > > > > our
> > > > > > > > > > > > >> release
> > > > > > > > > > > > >> > > > to be published, with all artifacts ending
> up
> > in
> > > > the
> > > > > > > right
> > > > > > > > > > > places,
> > > > > > > > > > > > >> but
> > > > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > As you saw at the beginning of this email,
> all
> > > the
> > > > > > > > attempts
> > > > > > > > > we
> > > > > > > > > > > > made
> > > > > > > > > > > > >> > > > left us with the circular dependency showing
> > up
> > > > at a
> > > > > > > > > different
> > > > > > > > > > > > >> place,
> > > > > > > > > > > > >> > > > but something all these places have in
> common
> > is
> > > > > that
> > > > > > > > > they're
> > > > > > > > > > > all
> > > > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > The first part of my proposal is the
> > following:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > > > Quarkus
> > > > > > Dev
> > > > > > > > UIs
> > > > > > > > > > from
> > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > > > Management
> > > > > > > and
> > > > > > > > > > Task
> > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> `kie-tools`.
> > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > images
> > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > >> > > > S3. We move the entire
> > > > `kogito-serverless-operator`
> > > > > > repo
> > > > > > > > > > inside
> > > > > > > > > > > a
> > > > > > > > > > > > >> new
> > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> > problems
> > > > P1
> > > > > > and
> > > > > > > > P2.
> > > > >
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <po...@apache.org>.
Francisco,
Please feel free to open a new thread with such a proposal, although I
still consider that it’s necessary more details to be properly evaluated.
Keep in mind that CI code, configs and infrastructure is accessible for all
committers.
Please let’s keep this thread focused on the detailed proposal shared.
In case of multiple proposals we can start an official vote.
On Wed, Mar 13, 2024 at 9:05 AM Francisco Javier Tirado Sarti <
ftirados@redhat.com> wrote:
> I hardly see a difference in detail between the proposal to move
> kn-workflow module from tooling to images (it should have never been in
> tooling repo) plus changing CI stream to compile tooling repo before images
> repo (which I hope we all agree is the natural order) and the proposal to
> move all stuff from images that depends on tooling to tooling repo (which I
> hope we all agree hardly fits in current multi repo structure) and sort
> out the "details" on the ci pipeline associated to that repo (which implies
> CI knowledge after all)
> The key point here is, does Tiago (as tooling SME, it seems that there is a
> tools team but there is not a drools team ;)) agree that tooling should be
> executed before images because there is a logical dependency between images
> and tooling?
> In my opinion, the least we can do is to explore how it really costs to
> change CI to execute tooling before images.
>
>
> On Wed, Mar 13, 2024 at 1:36 PM Alex Porcelli <al...@porcelli.me> wrote:
>
> > Francisco and Gabriele,
> >
> > I understand and acknowledge your desire to find the “right” solution
> > instead to work on a temporary “patch” - however without a detailed
> > proposal I don’t think we can properly evaluate the impact of your
> > suggestion.
> >
> > When I spoke with different SMEs that included tools and CI, the
> > guesstimate for making the necessary changes on CI and codebase to
> > basically have images and operators in the end of the build chain is
> > something like 2 months of effort. Another impact that needs to be
> > discussed is that KIE Tools repo had to be injected in the middle of all
> > pipelines - forcing all PR checks and nightlies to build all repos (PR
> > checks will likely take 12+ hours… I even heard that it could be even 24
> > hours).
> >
> > Based on the input above, I think it’s quite risk to move in such
> direction
> > without a more detailed plan… because 2 months could be turned easily in
> 6!
> > And this is exactly what happened when we guessed that moving to Apache
> > would take no more than 3 months. But here we are.
> >
> > I really strongly suggest that we focus on a release that could be
> > achievable in less than a month from now, and we - after release - have a
> > in depth discussion about the overall codebase and ci organization.
> >
> >
> > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > gabriele.cardosi@gmail.com>
> > wrote:
> >
> > > Alex,
> > > my suggestion is to move the building of all docker images, from
> whatever
> > > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > > invoked after all the others.
> > > I'm not sure if this would solve all the issues, and since I could not
> > > enter in the details of all the involved code, my suggestion may be too
> > > naive.
> > > Having spent almost all of the last year in CI, I may say that, at
> least
> > > for the kie-tools repo, removing the image build step from it should
> not
> > be
> > > too difficult (since it is an issue we already faced and solved).
> > > If, with "detailed proposal", you mean a complete list of all modules
> to
> > be
> > > moved and dependency refactoring, of course I can not provide it right
> > now.
> > >
> > > Anyway, I share the concern from Francisco: undoing something is almost
> > > always harder than doing it "rightly" from scratch...
> > >
> > >
> > >
> > >
> > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti
> <
> > > ftirados@redhat.com> ha scritto:
> > >
> > > > I do not think estimations should be the only driver to make a
> > decision,
> > > > especially when the current proposal is conceptually incompatible
> with
> > > the
> > > > multi repo approach that is taken elsewhere in the project.
> > > > Given my knowledge of the CI it is nearly impossible for me to give
> a
> > > fair
> > > > estimate of how much it might take to achieve step 2) of my previous
> > > e-mail
> > > > . It might take a while or it might be pretty easy after all, I don't
> > > > really know, but I think it will be a good idea if some of the
> experts
> > > on
> > > > CI in the team (the ones that set up the pipeline, which was a huge
> > > > achievement) give an estimate, not me. Estimating how much it takes
> to
> > > > merge two existing repos (without altering CI) is easier, but it does
> > not
> > > > mean we are doing the right thing.
> > > > My main concern is that it will be very difficult for me to explain
> to
> > > > someone that arrives new to the team, that having experts on CI on
> the
> > > > team, we decided to merge two repos (once merged, it would be rather
> > > > difficult to unmerge) rather than fix the CI, because of expediency.
> > > >
> > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> > > > wrote:
> > > >
> > > > > Francisco,
> > > > >
> > > > > Please take the time to make the more in depth analysis needed and
> > > > provide
> > > > > a more detailed plan… so we - as community- can evaluate the size
> of
> > > the
> > > > > effort. In the conceptual level you shared it’s near impossible to
> > > > estimate
> > > > > the size of the effort and compare with the current proposal.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > ftirados@redhat.com> wrote:
> > > > >
> > > > > > I think I already did a high level proposal.
> > > > > > 1) Remove all dependencies from tooling to images, so images
> > depend
> > > on
> > > > > > tooling but tooling does not depend on images.
> > > > > > 2) Then change CI to deal with tooling repo before dealing with
> > > images
> > > > > > repo.
> > > > > > I understand that CI details are tricky and since I'm not
> familiar
> > > with
> > > > > CI
> > > > > > in any way, I barely can make a low level design, but we do not
> > need
> > > to
> > > > > fix
> > > > > > everything, just achieve 2), a change of compilation order.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <alex@porcelli.me
> >
> > > > wrote:
> > > > > >
> > > > > > > Francisco and Grabriele,
> > > > > > >
> > > > > > > You may not like or understand why the current state of the CI
> is
> > > > like
> > > > > > > that… actually has been in Red Hat and has been replicated in
> > > Apache
> > > > as
> > > > > > > used to be….
> > > > > > >
> > > > > > > But the fact is that this is the current reality.
> > > > > > >
> > > > > > > If you disagree with the current plan, please provide a
> detailed
> > > > > > > alternative so we, as community, can better evaluate the pros
> and
> > > > cons
> > > > > of
> > > > > > > each proposal.
> > > > > > >
> > > > > > >
> > > > > > > I think it’s also fair to say that, post 10 release we need to
> > > have a
> > > > > > much
> > > > > > > in depth discussion about how our codebase is organized, it’s
> > clear
> > > > > that
> > > > > > > it’s not working.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > As Francisco said,
> > > > > > > > I also have the impression that the "images" (if we are
> talking
> > > of
> > > > > > docker
> > > > > > > > images) should be the very last one to be built, in a
> > standalone
> > > > > repo.
> > > > > > > > That way, they may "combine" artifacts that are built in
> > > different
> > > > > > repos,
> > > > > > > > regardless of the order in which those are built.
> > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> maybe
> > > > could
> > > > > > > > simplify the situation a bit.
> > > > > > > > (I also think there are some statements of undisputable needs
> > > while
> > > > > > they
> > > > > > > > are, actually, just technical choices.
> > > > > > > > Anyway, this latter point is for longer, following,
> > discussion.)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > Tirado
> > > > > Sarti
> > > > > > <
> > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > >
> > > > > > > > > Alex,
> > > > > > > > > There are two assumptions that deserve further discussion:
> > > > > > > > > 1) That tool has to be the last to build. why? it does not
> > have
> > > > > more
> > > > > > > > sense
> > > > > > > > > to build final images after everything else has been
> built?-
> > > > > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> > > > bigger
> > > > > > than
> > > > > > > > the
> > > > > > > > > impact (long term consequences) of consolidating two
> > unrelated
> > > > > piece
> > > > > > of
> > > > > > > > > software within the same repository.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > alex@porcelli.me
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco,
> > > > > > > > > >
> > > > > > > > > > This was discussed as an alternative solution, however it
> > has
> > > > > major
> > > > > > > > > impact
> > > > > > > > > > on CI and there’s also the fact Tool has been always the
> > last
> > > > to
> > > > > > > build
> > > > > > > > > and
> > > > > > > > > > has no Snapshot published (actually in JavaScript world
> > there
> > > > is
> > > > > no
> > > > > > > > > > snapshot concept).
> > > > > > > > > >
> > > > > > > > > > So, based on our evaluation… the proposal here is the
> least
> > > > > > > disruptive
> > > > > > > > > and
> > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > _____________
> > > > > > > > > > Alex Porcelli
> > > > > > > > > > http://porcelli.me
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > > Sarti <
> > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > After kie-tools, sorry. I think we are not embracing
> the
> > > fact
> > > > > > that
> > > > > > > > > > > kogito-images depend on kie-tools, because we want
> those
> > > > images
> > > > > > to
> > > > > > > > > > include
> > > > > > > > > > > tools.
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> Tirado
> > > > Sarti
> > > > > <
> > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > It can be an alternative solution to move
> > > > kn-plugin-workflow
> > > > > to
> > > > > > > > > > > > kogito-images (so there is not longer dependency from
> > > tools
> > > > > to
> > > > > > > > > images)
> > > > > > > > > > > and
> > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > Martinez
> > > > <
> > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > >>
> > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache)
> <
> > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > >> escribió:
> > > > > > > > > > > >>
> > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > alex@porcelli.me
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > > +1
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > I spent the last day or so working closely with
> > > Tiago,
> > > > > > > > exploring
> > > > > > > > > > > >> > different
> > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > evaluating
> > > > > > the
> > > > > > > > > > overall
> > > > > > > > > > > >> > release
> > > > > > > > > > > >> > > procedure steps required. I agree with the
> > proposal
> > > as
> > > > > the
> > > > > > > > most
> > > > > > > > > > > >> > > viable option for unblocking the 10 release in
> the
> > > > > > > reasonable
> > > > > > > > > time
> > > > > > > > > > > >> frame.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > >> > wrote:
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time,
> as
> > > this
> > > > > > > matter
> > > > > > > > > > > >> requires a
> > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > > > > according
> > > > > > > to
> > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > > > > >> > > > (
> > > > > > > > > >
> > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > ),
> > > > > > > > > > > >> > > > many of us were working towards removing a
> > > circular
> > > > > > > > dependency
> > > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > > `kie-tools`.
> > > > > > > As
> > > > > > > > we
> > > > > > > > > > > >> > > > progressed towards a solution, we kept finding
> > the
> > > > > > > circular
> > > > > > > > > > > >> dependency
> > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of
> > the
> > > > > things
> > > > > > > we
> > > > > > > > > did,
> > > > > > > > > > > and
> > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Right now, even though we started the effort
> to
> > > move
> > > > > the
> > > > > > > > > Quarkus
> > > > > > > > > > > Dev
> > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> able
> > to
> > > > do
> > > > > it
> > > > > > > > yet,
> > > > > > > > > as
> > > > > > > > > > > >> we've
> > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> Maven
> > > > 3.9.6,
> > > > > > and
> > > > > > > > > > Quarkus
> > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > This
> > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > >> > > >
> > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > .
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > C | 03.
> incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > Y | 04.
> incubator-kie-kogito-images
> > > > > > > > > > > >> > > > C | 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > >> > > > E | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > >> > > > * and
> > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > depend
> > > > > > > > > > > >> on
> > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> `kie-tools`,
> > > we
> > > > > > > would've
> > > > > > > > > > had:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > > >> > > > Y | 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > >> > > > L | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > >> > > > * and
> `kogito-images`/kogito-swf-devmode
> > > > > depends
> > > > > > > on
> > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > > > > `kie-tools`,
> > > > > > > > we
> > > > > > > > > > > >> would've
> > > > > > > > > > > >> > > > had:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > 04.
> incubator-kie-kogito-images
> > > > > > > > > > > >> > > > C |==> 05.
> > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > >> > > > C | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > > E
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > depends
> > > > on
> > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Clearly, we have a much bigger problem than a
> > > simple
> > > > > > > > circular
> > > > > > > > > > > >> > dependency.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > people,
> > > > > it's
> > > > > > > been
> > > > > > > > > > > really
> > > > > > > > > > > >> > > > hard coming up with a simple solution that
> makes
> > > it
> > > > > > > possible
> > > > > > > > > to
> > > > > > > > > > > >> build
> > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving the
> way
> > > > > > everyone
> > > > > > > is
> > > > > > > > > > used
> > > > > > > > > > > to
> > > > > > > > > > > >> > > > contributing to the multiple repositories we
> > have.
> > > > > More
> > > > > > > than
> > > > > > > > > > that,
> > > > > > > > > > > >> > > > while making this assessment, I found more
> > > problems
> > > > > > that,
> > > > > > > in
> > > > > > > > > my
> > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> forward
> > > with
> > > > > my
> > > > > > > > > proposal
> > > > > > > > > > > for
> > > > > > > > > > > >> > > > the Apache KIE release process, so we can use
> > > > Apache's
> > > > > > > > > > mechanisms
> > > > > > > > > > > to
> > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> this
> > > > really
> > > > > > > > > > complicated
> > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > > current
> > > > > > > > situation
> > > > > > > > > > of
> > > > > > > > > > > >> our
> > > > > > > > > > > >> > > > codebase, as well as problems I can currently
> > see.
> > > > > I'll
> > > > > > > > start
> > > > > > > > > > with
> > > > > > > > > > > >> an
> > > > > > > > > > > >> > > > analysis of the repositories and their
> purposes,
> > > > point
> > > > > > out
> > > > > > > > > some
> > > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > > release,
> > > > > > > explain
> > > > > > > > > my
> > > > > > > > > > > >> > > > proposal and discuss some consequences to what
> > I'm
> > > > > > > > proposing.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > > `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> > > > `0.0.0`
> > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > >> > > > (Issues only, README should be updated @
> > > `main`.
> > > > > > Same
> > > > > > > > for
> > > > > > > > > > > GitHub
> > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy at
> the
> > > > > `main`
> > > > > > > > > branch.)
> > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > > > > `deploy`
> > > > > > to
> > > > > > > > > > update
> > > > > > > > > > > >> the
> > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > >> > > > (GitHub pages used to host
> sandbox.kie.org
> > > and
> > > > > KIE
> > > > > > > > Tools'
> > > > > > > > > > > >> Chrome
> > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> checks
> > > > > during
> > > > > > > the
> > > > > > > > > > > staging
> > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I grouped the repositories by category, and
> > listed
> > > > > them
> > > > > > > in a
> > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > flattening
> > > > > > out a
> > > > > > > > > tree,
> > > > > > > > > > > >> there
> > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > OptaPlanner
> > > > > > > > could've
> > > > > > > > > > been
> > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category A repos are what I've been referring
> to
> > > as
> > > > > > > `drools`
> > > > > > > > > and
> > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is
> > inside
> > > > > that
> > > > > > > > > stream,
> > > > > > > > > > as
> > > > > > > > > > > >> the
> > > > > > > > > > > >> > > > way these repositories reference each other
> are
> > > > > through
> > > > > > > > Maven
> > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > > > > version.
> > > > > > > This
> > > > > > > > > > > >> mechanism
> > > > > > > > > > > >> > > > is well-known to the team, and although flawed
> > for
> > > > > > > intra-day
> > > > > > > > > > > builds
> > > > > > > > > > > >> > > > and disruptive for people in many different
> time
> > > > > zones,
> > > > > > it
> > > > > > > > is
> > > > > > > > > > > >> already
> > > > > > > > > > > >> > > > very comfortable for everyone to work with, I
> > > > assume.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > dedicated
> > > > > > > > > pipelines,
> > > > > > > > > > > >> which
> > > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > > cross-repo
> > > > > > PRs
> > > > > > > > > > > together
> > > > > > > > > > > >> > > > and verify that the codebase will continue
> > working
> > > > as
> > > > > > > > expected
> > > > > > > > > > > after
> > > > > > > > > > > >> > > > they're all merged. From what I could gather,
> > > there
> > > > > are
> > > > > > > some
> > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > cross-repo
> > > > PRs.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > > kogito-examples
> > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > >> > > > - kogito-images, and
> kogito-serverless-operator
> > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > > > > combination
> > > > > > > of
> > > > > > > > > > repos
> > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > cannot
> > > be
> > > > > > > > verified
> > > > > > > > > > > before
> > > > > > > > > > > >> > > > merging, making our contribution model
> dependent
> > > on
> > > > > > > > individual
> > > > > > > > > > > >> > > > contributors building stuff on their machines
> to
> > > > > verify
> > > > > > > that
> > > > > > > > > it
> > > > > > > > > > > >> works.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > >> > > > ,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > >> > > > ,
> > > > > > > > > > > >> > > > and
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > >> > > > .
> > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > pipelines,
> > > > > so
> > > > > > > > > please
> > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category B repos are what I've been referring
> to
> > > as
> > > > > > > > > `kie-tools`
> > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > repository
> > > > > > that
> > > > > > > > is
> > > > > > > > > > used
> > > > > > > > > > > >> by
> > > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > > Sandbox,
> > > > > > > > similar
> > > > > > > > > > to a
> > > > > > > > > > > >> > > > Maven archetype, if you will. The other one is
> > the
> > > > KIE
> > > > > > > Tools
> > > > > > > > > > > >> monorepo,
> > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > > system.
> > > > > > > > > Currently,
> > > > > > > > > > > KIE
> > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> TypeScript
> > > > > > libraries
> > > > > > > > and
> > > > > > > > > > > apps,
> > > > > > > > > > > >> Go
> > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > `kie-tools`
> > > > > > > > monorepo
> > > > > > > > > > is
> > > > > > > > > > > >> > > > configured to work with sparse checkouts and
> can
> > > do
> > > > > > > partial
> > > > > > > > > > > builds.
> > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > through
> > > > > > > > timestamped
> > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > > > > introduced
> > > > > > > > that
> > > > > > > > > > > will
> > > > > > > > > > > >> > > > build and publish immutable, persistent
> > artifacts
> > > > > under
> > > > > > a
> > > > > > > > > > version
> > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > > published
> > > > > > > weekly
> > > > > > > > > > every
> > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > evolution
> > > > > to
> > > > > > > the
> > > > > > > > > > Kogito
> > > > > > > > > > > >> > > > releases, as we're now targeting one release
> for
> > > all
> > > > > of
> > > > > > > > Apache
> > > > > > > > > > > KIE,
> > > > > > > > > > > >> so
> > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > An important note here is that Category B
> > > > repositories
> > > > > > > have
> > > > > > > > > been
> > > > > > > > > > > >> > > > historically kept out of any automations we
> used
> > > to
> > > > > > have,
> > > > > > > > way
> > > > > > > > > > back
> > > > > > > > > > > >> > > > when Kogito started and we had the Business
> > > Central
> > > > > > > (a.k.a.
> > > > > > > > > v7)
> > > > > > > > > > > >> stream
> > > > > > > > > > > >> > > > still going on. For this reason, Category B
> > > projects
> > > > > > have
> > > > > > > > > > > developed
> > > > > > > > > > > >> > > > their own automations, based on GitHub
> Actions.
> > > > > > Category B
> > > > > > > > > repos
> > > > > > > > > > > >> have
> > > > > > > > > > > >> > > > always depended on Category A repos using
> fixed
> > > > > > versions.
> > > > > > > If
> > > > > > > > > > > >> Category
> > > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > > breaking
> > > > > > > changes
> > > > > > > > > on
> > > > > > > > > > > >> > > > Category A repositories would've had the
> > potential
> > > > to
> > > > > > > break
> > > > > > > > > > > >> Category B
> > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > development
> > > > > > > > stream,
> > > > > > > > > > and
> > > > > > > > > > > >> > > > introducing unpleasant surprises for
> maintainers
> > > of
> > > > > > > > Category B
> > > > > > > > > > > >> repos,
> > > > > > > > > > > >> > > > as historically Category A contributors were
> not
> > > > > > familiar
> > > > > > > > with
> > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > through
> > > a
> > > > > > GitHub
> > > > > > > > > > Actions
> > > > > > > > > > > >> > > > workflow that builds the relevant part of the
> > > > > > `kie-tools`
> > > > > > > > > > monorepo
> > > > > > > > > > > >> for
> > > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > > pipeline
> > > > > > > itself
> > > > > > > > > are
> > > > > > > > > > > also
> > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do
> > things
> > > > > like
> > > > > > > > > > atomically
> > > > > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > > > > importantly,
> > > > > > > > it
> > > > > > > > > > > >> allows
> > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > timestamped
> > > > > > SNAPSHOT
> > > > > > > > > > > together
> > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > green.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This setup, however, makes it impossible to
> have
> > > > > > > cross-repo
> > > > > > > > > PRs
> > > > > > > > > > > >> > > > involving Category A and Category B
> > > simultaneously,
> > > > > with
> > > > > > > the
> > > > > > > > > > > current
> > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category C repos are kind of floating around,
> > and
> > > > I'm
> > > > > > not
> > > > > > > > sure
> > > > > > > > > > if
> > > > > > > > > > > >> > > > there's much activity going on there.
> > Regardless,
> > > as
> > > > > > > they're
> > > > > > > > > > part
> > > > > > > > > > > of
> > > > > > > > > > > >> > > > Apache KIE, they will be part of our release,
> > so I
> > > > > > listed
> > > > > > > > them
> > > > > > > > > > for
> > > > > > > > > > > >> us
> > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category D is self explanatory. There's only
> one
> > > > repo
> > > > > > that
> > > > > > > > has
> > > > > > > > > > > >> already
> > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > directly,
> > > > > and
> > > > > > > are
> > > > > > > > > > > either
> > > > > > > > > > > >> > > > organizational entities, or host websites,
> that
> > > > > > currently
> > > > > > > > are
> > > > > > > > > > not
> > > > > > > > > > > >> part
> > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This lack of unification between Category A
> and
> > > > > > Category B
> > > > > > > > is,
> > > > > > > > > > > IMHO,
> > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > circular
> > > > > > > > dependency
> > > > > > > > > > > >> between
> > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now
> can
> > > > > describe
> > > > > > > as
> > > > > > > > a
> > > > > > > > > > > >> circular
> > > > > > > > > > > >> > > > dependency between Category A and Category B.
> > The
> > > > way
> > > > > I
> > > > > > > see
> > > > > > > > > it,
> > > > > > > > > > if
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > had a single pipeline, building everything
> from
> > > > > `drools`
> > > > > > > to
> > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > > introduced,
> > > > > > > and
> > > > > > > > we
> > > > > > > > > > > >> > > > wouldn't be having this huge problem in our
> > hands
> > > > > right
> > > > > > > now.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > My proposal for the Apache KIE release process
> > > sees
> > > > > this
> > > > > > > > lack
> > > > > > > > > of
> > > > > > > > > > > >> > > > unification as a central problem, not only for
> > > this
> > > > > > > release
> > > > > > > > in
> > > > > > > > > > > >> > > > particular, but for the community as a whole.
> It
> > > is
> > > > my
> > > > > > > > belief
> > > > > > > > > > that
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > contribution
> > > > > > > should
> > > > > > > > > be
> > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> With
> > > the
> > > > > > > > increasing
> > > > > > > > > > > >> volume
> > > > > > > > > > > >> > > > of code, and hopefully number of contributors
> > too,
> > > > we
> > > > > > > cannot
> > > > > > > > > > keep
> > > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > > things.
> > > > > > We're
> > > > > > > > all
> > > > > > > > > > > >> humans
> > > > > > > > > > > >> > > > after all, and it is our job to have
> mechanisms
> > in
> > > > > place
> > > > > > > to
> > > > > > > > > > > prevent
> > > > > > > > > > > >> us
> > > > > > > > > > > >> > > > from unwillingly making mistakes. Especially
> > when
> > > > > these
> > > > > > > > > mistakes
> > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > individually,
> > > > > > > > > probably
> > > > > > > > > > > >> can't
> > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending
> on
> > > > > > > kiegroup's
> > > > > > > > > KIE
> > > > > > > > > > > >> Tools
> > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > `kogito-images`
> > > > > > > > depending
> > > > > > > > > on
> > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > kiegroup's
> > > > > > > > `lienzo`
> > > > > > > > > > and
> > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> `7.59.0.Final`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> depending
> > on
> > > > > > > > kiegroup's
> > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > >> > > > * This module was removed from the KIE
> codebase
> > > > here:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > >> > > >
> > > > > > > > > > >
> > > > > >
> https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > ,
> > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > OptaPlanner,
> > > > > > > pointing
> > > > > > > > to
> > > > > > > > > > > older
> > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P5.
> `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > depending
> > > > > > > on
> > > > > > > > > > > Kogito
> > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P6. Category C repos are out of date and not
> > part
> > > of
> > > > > the
> > > > > > > > > > Category
> > > > > > > > > > > A
> > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > > version
> > > > is
> > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > >> > > > depending on Kogito without a specific
> version,
> > > only
> > > > > by
> > > > > > > > using
> > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version
> is
> > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> OptaPlanner
> > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow
> has
> > > its
> > > > > E2E
> > > > > > > > > disabled
> > > > > > > > > > > >> after
> > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > solution,
> > > > > as
> > > > > > > they
> > > > > > > > > > both
> > > > > > > > > > > >> > > > suffer from the circular dependency between
> > > > Category A
> > > > > > and
> > > > > > > > > > > Category
> > > > > > > > > > > >> B.
> > > > > > > > > > > >> > > > As Category A and Category B are both streams
> > that
> > > > > have
> > > > > > > been
> > > > > > > > > > > really
> > > > > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > > > > contributions
> > > > > > > > > that
> > > > > > > > > > > >> > > > cannot be done, given that Category A depends
> on
> > > > > > Category
> > > > > > > B
> > > > > > > > > > with a
> > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> understood
> > > as
> > > > > > > > technical
> > > > > > > > > > > debt.
> > > > > > > > > > > >> > > > Depending on unmaintained projects is
> something
> > > > we'll
> > > > > > > always
> > > > > > > > > be
> > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > > matter
> > > > of
> > > > > > > > making
> > > > > > > > > > them
> > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P7 is an isolated problem that won't impact
> the
> > > > > > structure
> > > > > > > or
> > > > > > > > > > > >> anything
> > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > regression
> > > > > we
> > > > > > > > > > > introduced
> > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache
> KIE
> > > 10,
> > > > > and
> > > > > > > > that
> > > > > > > > > > P5,
> > > > > > > > > > > >> P6,
> > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems left
> > to
> > > > > > discuss
> > > > > > > > are
> > > > > > > > > P1
> > > > > > > > > > > and
> > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > proposal.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> from
> > my
> > > > > > > > experience,
> > > > > > > > > > any
> > > > > > > > > > > >> > > > little miscalculation can lead to our release
> > not
> > > > > > working
> > > > > > > > out
> > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > >> > > > end. To try and avoid that as much as
> possible,
> > > and
> > > > > make
> > > > > > > > > > > everything
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> release,
> > > bear
> > > > > > with
> > > > > > > > me.
> > > > > > > > > > I'll
> > > > > > > > > > > >> lay
> > > > > > > > > > > >> > > > out a timeline of events that need to happen
> in
> > > > order
> > > > > > for
> > > > > > > > our
> > > > > > > > > > > >> release
> > > > > > > > > > > >> > > > to be published, with all artifacts ending up
> in
> > > the
> > > > > > right
> > > > > > > > > > places,
> > > > > > > > > > > >> but
> > > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As you saw at the beginning of this email, all
> > the
> > > > > > > attempts
> > > > > > > > we
> > > > > > > > > > > made
> > > > > > > > > > > >> > > > left us with the circular dependency showing
> up
> > > at a
> > > > > > > > different
> > > > > > > > > > > >> place,
> > > > > > > > > > > >> > > > but something all these places have in common
> is
> > > > that
> > > > > > > > they're
> > > > > > > > > > all
> > > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > The first part of my proposal is the
> following:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > > Quarkus
> > > > > Dev
> > > > > > > UIs
> > > > > > > > > from
> > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > > Management
> > > > > > and
> > > > > > > > > Task
> > > > > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > images
> > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > >> > > > S3. We move the entire
> > > `kogito-serverless-operator`
> > > > > repo
> > > > > > > > > inside
> > > > > > > > > > a
> > > > > > > > > > > >> new
> > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> problems
> > > P1
> > > > > and
> > > > > > > P2.
> > > > > > > > Of
> > > > > > > > > > > >> course
> > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > >>
> > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This doesn't come without consequences, of
> > course,
> > > > as
> > > > > > the
> > > > > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> > > > images,
> > > > > > and
> > > > > > > > the
> > > > > > > > > > > >> > > > `kogito-serverless-operator` would be moving
> > from
> > > > > > > Category A
> > > > > > > > > to
> > > > > > > > > > > >> > > > Category B. This move would make them have to
> > > > > reference
> > > > > > > > > > Category A
> > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > `kogito-images`
> > > > > > > > and
> > > > > > > > > > > >> > > > `kogito-serverless-operator` are already their
> > own
> > > > > > > > > "sub-stream"
> > > > > > > > > > > >> inside
> > > > > > > > > > > >> > > > Category A, though, contributions made in a
> > > > cross-repo
> > > > > > > > fashion
> > > > > > > > > > to
> > > > > > > > > > > >> this
> > > > > > > > > > > >> > > > "sub-stream" will continue being possible, now
> > > via a
> > > > > > > single
> > > > > > > > PR
> > > > > > > > > > to
> > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A
> > and
> > > > > > > Category
> > > > > > > > B
> > > > > > > > > > will
> > > > > > > > > > > >> > > > continue not being possible, and a 1-week
> delay
> > > > > between
> > > > > > > > > merging
> > > > > > > > > > > >> > > > something on Category A and using it on
> > Category B
> > > > > will
> > > > > > > > still
> > > > > > > > > > > >> happen.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> however,
> > > > does
> > > > > > > allow
> > > > > > > > > for
> > > > > > > > > > > >> sparse
> > > > > > > > > > > >> > > > checkouts and partial builds, so working with
> a
> > > > subset
> > > > > > of
> > > > > > > > the
> > > > > > > > > > > >> monorepo
> > > > > > > > > > > >> > > > is possible and encouraged. Making changes
> only
> > to
> > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example,
> will
> > > > have
> > > > > > the
> > > > > > > PR
> > > > > > > > > > > checks
> > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > >> > > > .
> > > > > > > > > > > >> > > > We're not compromising when running partial
> > builds
> > > > > too.
> > > > > > We
> > > > > > > > > know
> > > > > > > > > > > that
> > > > > > > > > > > >> > > > the entire repo will continue working even
> after
> > > > only
> > > > > > > > > building a
> > > > > > > > > > > >> small
> > > > > > > > > > > >> > > > subset of the changes. Doing partial or full
> > > builds
> > > > is
> > > > > > > > > > > automatically
> > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Keep in mind that, even though I'm proposing
> we
> > > > move a
> > > > > > > bunch
> > > > > > > > > of
> > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see this
> > as a
> > > > > > > TEMPORARY
> > > > > > > > > > > >> solution
> > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > > > > additional
> > > > > > > > stuff
> > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> continue
> > > > moving
> > > > > > > > > forward.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> > > became a
> > > > > > > > polyglot
> > > > > > > > > > > >> monorepo
> > > > > > > > > > > >> > > > out of necessity, and although I'm really
> proud
> > of
> > > > > what
> > > > > > we
> > > > > > > > > > > achieved
> > > > > > > > > > > >> > > > there so far, I don't think `kie-tools` has a
> > > setup
> > > > > that
> > > > > > > is
> > > > > > > > > > > suitable
> > > > > > > > >
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
I hardly see a difference in detail between the proposal to move
kn-workflow module from tooling to images (it should have never been in
tooling repo) plus changing CI stream to compile tooling repo before images
repo (which I hope we all agree is the natural order) and the proposal to
move all stuff from images that depends on tooling to tooling repo (which I
hope we all agree hardly fits in current multi repo structure) and sort
out the "details" on the ci pipeline associated to that repo (which implies
CI knowledge after all)
The key point here is, does Tiago (as tooling SME, it seems that there is a
tools team but there is not a drools team ;)) agree that tooling should be
executed before images because there is a logical dependency between images
and tooling?
In my opinion, the least we can do is to explore how it really costs to
change CI to execute tooling before images.
On Wed, Mar 13, 2024 at 1:36 PM Alex Porcelli <al...@porcelli.me> wrote:
> Francisco and Gabriele,
>
> I understand and acknowledge your desire to find the “right” solution
> instead to work on a temporary “patch” - however without a detailed
> proposal I don’t think we can properly evaluate the impact of your
> suggestion.
>
> When I spoke with different SMEs that included tools and CI, the
> guesstimate for making the necessary changes on CI and codebase to
> basically have images and operators in the end of the build chain is
> something like 2 months of effort. Another impact that needs to be
> discussed is that KIE Tools repo had to be injected in the middle of all
> pipelines - forcing all PR checks and nightlies to build all repos (PR
> checks will likely take 12+ hours… I even heard that it could be even 24
> hours).
>
> Based on the input above, I think it’s quite risk to move in such direction
> without a more detailed plan… because 2 months could be turned easily in 6!
> And this is exactly what happened when we guessed that moving to Apache
> would take no more than 3 months. But here we are.
>
> I really strongly suggest that we focus on a release that could be
> achievable in less than a month from now, and we - after release - have a
> in depth discussion about the overall codebase and ci organization.
>
>
> On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> gabriele.cardosi@gmail.com>
> wrote:
>
> > Alex,
> > my suggestion is to move the building of all docker images, from whatever
> > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > invoked after all the others.
> > I'm not sure if this would solve all the issues, and since I could not
> > enter in the details of all the involved code, my suggestion may be too
> > naive.
> > Having spent almost all of the last year in CI, I may say that, at least
> > for the kie-tools repo, removing the image build step from it should not
> be
> > too difficult (since it is an issue we already faced and solved).
> > If, with "detailed proposal", you mean a complete list of all modules to
> be
> > moved and dependency refactoring, of course I can not provide it right
> now.
> >
> > Anyway, I share the concern from Francisco: undoing something is almost
> > always harder than doing it "rightly" from scratch...
> >
> >
> >
> >
> > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti <
> > ftirados@redhat.com> ha scritto:
> >
> > > I do not think estimations should be the only driver to make a
> decision,
> > > especially when the current proposal is conceptually incompatible with
> > the
> > > multi repo approach that is taken elsewhere in the project.
> > > Given my knowledge of the CI it is nearly impossible for me to give a
> > fair
> > > estimate of how much it might take to achieve step 2) of my previous
> > e-mail
> > > . It might take a while or it might be pretty easy after all, I don't
> > > really know, but I think it will be a good idea if some of the experts
> > on
> > > CI in the team (the ones that set up the pipeline, which was a huge
> > > achievement) give an estimate, not me. Estimating how much it takes to
> > > merge two existing repos (without altering CI) is easier, but it does
> not
> > > mean we are doing the right thing.
> > > My main concern is that it will be very difficult for me to explain to
> > > someone that arrives new to the team, that having experts on CI on the
> > > team, we decided to merge two repos (once merged, it would be rather
> > > difficult to unmerge) rather than fix the CI, because of expediency.
> > >
> > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> > > wrote:
> > >
> > > > Francisco,
> > > >
> > > > Please take the time to make the more in depth analysis needed and
> > > provide
> > > > a more detailed plan… so we - as community- can evaluate the size of
> > the
> > > > effort. In the conceptual level you shared it’s near impossible to
> > > estimate
> > > > the size of the effort and compare with the current proposal.
> > > >
> > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > ftirados@redhat.com> wrote:
> > > >
> > > > > I think I already did a high level proposal.
> > > > > 1) Remove all dependencies from tooling to images, so images
> depend
> > on
> > > > > tooling but tooling does not depend on images.
> > > > > 2) Then change CI to deal with tooling repo before dealing with
> > images
> > > > > repo.
> > > > > I understand that CI details are tricky and since I'm not familiar
> > with
> > > > CI
> > > > > in any way, I barely can make a low level design, but we do not
> need
> > to
> > > > fix
> > > > > everything, just achieve 2), a change of compilation order.
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > >
> > > > > > Francisco and Grabriele,
> > > > > >
> > > > > > You may not like or understand why the current state of the CI is
> > > like
> > > > > > that… actually has been in Red Hat and has been replicated in
> > Apache
> > > as
> > > > > > used to be….
> > > > > >
> > > > > > But the fact is that this is the current reality.
> > > > > >
> > > > > > If you disagree with the current plan, please provide a detailed
> > > > > > alternative so we, as community, can better evaluate the pros and
> > > cons
> > > > of
> > > > > > each proposal.
> > > > > >
> > > > > >
> > > > > > I think it’s also fair to say that, post 10 release we need to
> > have a
> > > > > much
> > > > > > in depth discussion about how our codebase is organized, it’s
> clear
> > > > that
> > > > > > it’s not working.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > gabriele.cardosi@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > As Francisco said,
> > > > > > > I also have the impression that the "images" (if we are talking
> > of
> > > > > docker
> > > > > > > images) should be the very last one to be built, in a
> standalone
> > > > repo.
> > > > > > > That way, they may "combine" artifacts that are built in
> > different
> > > > > repos,
> > > > > > > regardless of the order in which those are built.
> > > > > > > Moving them out of all the repos (kogito-apps/kie-tools) maybe
> > > could
> > > > > > > simplify the situation a bit.
> > > > > > > (I also think there are some statements of undisputable needs
> > while
> > > > > they
> > > > > > > are, actually, just technical choices.
> > > > > > > Anyway, this latter point is for longer, following,
> discussion.)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> Tirado
> > > > Sarti
> > > > > <
> > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > >
> > > > > > > > Alex,
> > > > > > > > There are two assumptions that deserve further discussion:
> > > > > > > > 1) That tool has to be the last to build. why? it does not
> have
> > > > more
> > > > > > > sense
> > > > > > > > to build final images after everything else has been built?-
> > > > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> > > bigger
> > > > > than
> > > > > > > the
> > > > > > > > impact (long term consequences) of consolidating two
> unrelated
> > > > piece
> > > > > of
> > > > > > > > software within the same repository.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > alex@porcelli.me
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco,
> > > > > > > > >
> > > > > > > > > This was discussed as an alternative solution, however it
> has
> > > > major
> > > > > > > > impact
> > > > > > > > > on CI and there’s also the fact Tool has been always the
> last
> > > to
> > > > > > build
> > > > > > > > and
> > > > > > > > > has no Snapshot published (actually in JavaScript world
> there
> > > is
> > > > no
> > > > > > > > > snapshot concept).
> > > > > > > > >
> > > > > > > > > So, based on our evaluation… the proposal here is the least
> > > > > > disruptive
> > > > > > > > and
> > > > > > > > > will take less time to unblock the release.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > _____________
> > > > > > > > > Alex Porcelli
> > > > > > > > > http://porcelli.me
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > Sarti <
> > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > > After kie-tools, sorry. I think we are not embracing the
> > fact
> > > > > that
> > > > > > > > > > kogito-images depend on kie-tools, because we want those
> > > images
> > > > > to
> > > > > > > > > include
> > > > > > > > > > tools.
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado
> > > Sarti
> > > > <
> > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > It can be an alternative solution to move
> > > kn-plugin-workflow
> > > > to
> > > > > > > > > > > kogito-images (so there is not longer dependency from
> > tools
> > > > to
> > > > > > > > images)
> > > > > > > > > > and
> > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > Martinez
> > > <
> > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > >>
> > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > >> escribió:
> > > > > > > > > > >>
> > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > alex@porcelli.me
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > > +1
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I spent the last day or so working closely with
> > Tiago,
> > > > > > > exploring
> > > > > > > > > > >> > different
> > > > > > > > > > >> > > options and getting deeper on the impact and
> > > evaluating
> > > > > the
> > > > > > > > > overall
> > > > > > > > > > >> > release
> > > > > > > > > > >> > > procedure steps required. I agree with the
> proposal
> > as
> > > > the
> > > > > > > most
> > > > > > > > > > >> > > viable option for unblocking the 10 release in the
> > > > > > reasonable
> > > > > > > > time
> > > > > > > > > > >> frame.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > >> > wrote:
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time, as
> > this
> > > > > > matter
> > > > > > > > > > >> requires a
> > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > > > according
> > > > > > to
> > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > > > >> > > > (
> > > > > > > > >
> > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > ),
> > > > > > > > > > >> > > > many of us were working towards removing a
> > circular
> > > > > > > dependency
> > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > `kie-tools`.
> > > > > > As
> > > > > > > we
> > > > > > > > > > >> > > > progressed towards a solution, we kept finding
> the
> > > > > > circular
> > > > > > > > > > >> dependency
> > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of
> the
> > > > things
> > > > > > we
> > > > > > > > did,
> > > > > > > > > > and
> > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Right now, even though we started the effort to
> > move
> > > > the
> > > > > > > > Quarkus
> > > > > > > > > > Dev
> > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been able
> to
> > > do
> > > > it
> > > > > > > yet,
> > > > > > > > as
> > > > > > > > > > >> we've
> > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17, Maven
> > > 3.9.6,
> > > > > and
> > > > > > > > > Quarkus
> > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > This
> > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > >> > > >
> > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > .
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 01.
> incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > >> > > > C | 03. incubator-kie-kogito-examples
> > > > > > > > > > >> > > > Y | 04. incubator-kie-kogito-images
> > > > > > > > > > >> > > > C | 05.
> > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > >> > > > E | 06.
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> depends
> > > on
> > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > >> > > > * and
> > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > depend
> > > > > > > > > > >> on
> > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`,
> > we
> > > > > > would've
> > > > > > > > > had:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 01.
> incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > >> > > > 03.
> incubator-kie-kogito-examples
> > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > >> > > > Y | 05.
> > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > >> > > > L | 06.
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > depends
> > > on
> > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > >> > > > * and `kogito-images`/kogito-swf-devmode
> > > > depends
> > > > > > on
> > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > > > `kie-tools`,
> > > > > > > we
> > > > > > > > > > >> would've
> > > > > > > > > > >> > > > had:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 01.
> incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > >> > > > 03.
> incubator-kie-kogito-examples
> > > > > > > > > > >> > > > 04. incubator-kie-kogito-images
> > > > > > > > > > >> > > > C |==> 05.
> > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > >> > > > C | 06.
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > >> > > > E
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > depends
> > > on
> > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> depends
> > > on
> > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Clearly, we have a much bigger problem than a
> > simple
> > > > > > > circular
> > > > > > > > > > >> > dependency.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > After multiple conversations with a lot of
> people,
> > > > it's
> > > > > > been
> > > > > > > > > > really
> > > > > > > > > > >> > > > hard coming up with a simple solution that makes
> > it
> > > > > > possible
> > > > > > > > to
> > > > > > > > > > >> build
> > > > > > > > > > >> > > > Apache KIE in one shot, while preserving the way
> > > > > everyone
> > > > > > is
> > > > > > > > > used
> > > > > > > > > > to
> > > > > > > > > > >> > > > contributing to the multiple repositories we
> have.
> > > > More
> > > > > > than
> > > > > > > > > that,
> > > > > > > > > > >> > > > while making this assessment, I found more
> > problems
> > > > > that,
> > > > > > in
> > > > > > > > my
> > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > In light of that difficulty, I'm coming forward
> > with
> > > > my
> > > > > > > > proposal
> > > > > > > > > > for
> > > > > > > > > > >> > > > the Apache KIE release process, so we can use
> > > Apache's
> > > > > > > > > mechanisms
> > > > > > > > > > to
> > > > > > > > > > >> > > > have a slower-paced, in-depth debate about this
> > > really
> > > > > > > > > complicated
> > > > > > > > > > >> > > > matter.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > current
> > > > > > > situation
> > > > > > > > > of
> > > > > > > > > > >> our
> > > > > > > > > > >> > > > codebase, as well as problems I can currently
> see.
> > > > I'll
> > > > > > > start
> > > > > > > > > with
> > > > > > > > > > >> an
> > > > > > > > > > >> > > > analysis of the repositories and their purposes,
> > > point
> > > > > out
> > > > > > > > some
> > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > release,
> > > > > > explain
> > > > > > > > my
> > > > > > > > > > >> > > > proposal and discuss some consequences to what
> I'm
> > > > > > > proposing.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> > > `0.0.0`
> > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > >> > > > (Issues only, README should be updated @
> > `main`.
> > > > > Same
> > > > > > > for
> > > > > > > > > > GitHub
> > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > >> > > > (The Kogito website. Develop & deploy at the
> > > > `main`
> > > > > > > > branch.)
> > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > > > `deploy`
> > > > > to
> > > > > > > > > update
> > > > > > > > > > >> the
> > > > > > > > > > >> > > > website.)
> > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > >> > > > (GitHub pages used to host sandbox.kie.org
> > and
> > > > KIE
> > > > > > > Tools'
> > > > > > > > > > >> Chrome
> > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > > > >> > > > (Same as above, but for manual sanity checks
> > > > during
> > > > > > the
> > > > > > > > > > staging
> > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I grouped the repositories by category, and
> listed
> > > > them
> > > > > > in a
> > > > > > > > > > >> > > > topological order. Keep in mind that when
> > flattening
> > > > > out a
> > > > > > > > tree,
> > > > > > > > > > >> there
> > > > > > > > > > >> > > > are multiple possibilities. For example,
> > OptaPlanner
> > > > > > > could've
> > > > > > > > > been
> > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category A repos are what I've been referring to
> > as
> > > > > > `drools`
> > > > > > > > and
> > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is
> inside
> > > > that
> > > > > > > > stream,
> > > > > > > > > as
> > > > > > > > > > >> the
> > > > > > > > > > >> > > > way these repositories reference each other are
> > > > through
> > > > > > > Maven
> > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > > > version.
> > > > > > This
> > > > > > > > > > >> mechanism
> > > > > > > > > > >> > > > is well-known to the team, and although flawed
> for
> > > > > > intra-day
> > > > > > > > > > builds
> > > > > > > > > > >> > > > and disruptive for people in many different time
> > > > zones,
> > > > > it
> > > > > > > is
> > > > > > > > > > >> already
> > > > > > > > > > >> > > > very comfortable for everyone to work with, I
> > > assume.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Contributions made to Category A have some
> > dedicated
> > > > > > > > pipelines,
> > > > > > > > > > >> which
> > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > cross-repo
> > > > > PRs
> > > > > > > > > > together
> > > > > > > > > > >> > > > and verify that the codebase will continue
> working
> > > as
> > > > > > > expected
> > > > > > > > > > after
> > > > > > > > > > >> > > > they're all merged. From what I could gather,
> > there
> > > > are
> > > > > > some
> > > > > > > > > > >> > > > "sub-streams" currently configured for
> cross-repo
> > > PRs.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > kogito-examples
> > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > >> > > > - kogito-images, and kogito-serverless-operator
> > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > > > combination
> > > > > > of
> > > > > > > > > repos
> > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> cannot
> > be
> > > > > > > verified
> > > > > > > > > > before
> > > > > > > > > > >> > > > merging, making our contribution model dependent
> > on
> > > > > > > individual
> > > > > > > > > > >> > > > contributors building stuff on their machines to
> > > > verify
> > > > > > that
> > > > > > > > it
> > > > > > > > > > >> works.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > >> > > > ,
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > >> > > > ,
> > > > > > > > > > >> > > > and
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > >> > > > .
> > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > pipelines,
> > > > so
> > > > > > > > please
> > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category B repos are what I've been referring to
> > as
> > > > > > > > `kie-tools`
> > > > > > > > > > >> > > > stream. The first repo there is a template
> > > repository
> > > > > that
> > > > > > > is
> > > > > > > > > used
> > > > > > > > > > >> by
> > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > Sandbox,
> > > > > > > similar
> > > > > > > > > to a
> > > > > > > > > > >> > > > Maven archetype, if you will. The other one is
> the
> > > KIE
> > > > > > Tools
> > > > > > > > > > >> monorepo,
> > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > system.
> > > > > > > > Currently,
> > > > > > > > > > KIE
> > > > > > > > > > >> > > > Tools hosts Java libraries and apps, TypeScript
> > > > > libraries
> > > > > > > and
> > > > > > > > > > apps,
> > > > > > > > > > >> Go
> > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > `kie-tools`
> > > > > > > monorepo
> > > > > > > > > is
> > > > > > > > > > >> > > > configured to work with sparse checkouts and can
> > do
> > > > > > partial
> > > > > > > > > > builds.
> > > > > > > > > > >> > > > Category B repos refer to Category A repos
> through
> > > > > > > timestamped
> > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > > > introduced
> > > > > > > that
> > > > > > > > > > will
> > > > > > > > > > >> > > > build and publish immutable, persistent
> artifacts
> > > > under
> > > > > a
> > > > > > > > > version
> > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > published
> > > > > > weekly
> > > > > > > > > every
> > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > evolution
> > > > to
> > > > > > the
> > > > > > > > > Kogito
> > > > > > > > > > >> > > > releases, as we're now targeting one release for
> > all
> > > > of
> > > > > > > Apache
> > > > > > > > > > KIE,
> > > > > > > > > > >> so
> > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > An important note here is that Category B
> > > repositories
> > > > > > have
> > > > > > > > been
> > > > > > > > > > >> > > > historically kept out of any automations we used
> > to
> > > > > have,
> > > > > > > way
> > > > > > > > > back
> > > > > > > > > > >> > > > when Kogito started and we had the Business
> > Central
> > > > > > (a.k.a.
> > > > > > > > v7)
> > > > > > > > > > >> stream
> > > > > > > > > > >> > > > still going on. For this reason, Category B
> > projects
> > > > > have
> > > > > > > > > > developed
> > > > > > > > > > >> > > > their own automations, based on GitHub Actions.
> > > > > Category B
> > > > > > > > repos
> > > > > > > > > > >> have
> > > > > > > > > > >> > > > always depended on Category A repos using fixed
> > > > > versions.
> > > > > > If
> > > > > > > > > > >> Category
> > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > breaking
> > > > > > changes
> > > > > > > > on
> > > > > > > > > > >> > > > Category A repositories would've had the
> potential
> > > to
> > > > > > break
> > > > > > > > > > >> Category B
> > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > development
> > > > > > > stream,
> > > > > > > > > and
> > > > > > > > > > >> > > > introducing unpleasant surprises for maintainers
> > of
> > > > > > > Category B
> > > > > > > > > > >> repos,
> > > > > > > > > > >> > > > as historically Category A contributors were not
> > > > > familiar
> > > > > > > with
> > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Contributions made to Category B repos go
> through
> > a
> > > > > GitHub
> > > > > > > > > Actions
> > > > > > > > > > >> > > > workflow that builds the relevant part of the
> > > > > `kie-tools`
> > > > > > > > > monorepo
> > > > > > > > > > >> for
> > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > pipeline
> > > > > > itself
> > > > > > > > are
> > > > > > > > > > also
> > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do
> things
> > > > like
> > > > > > > > > atomically
> > > > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > > > importantly,
> > > > > > > it
> > > > > > > > > > >> allows
> > > > > > > > > > >> > > > us to upgrade the repository to a new
> timestamped
> > > > > SNAPSHOT
> > > > > > > > > > together
> > > > > > > > > > >> > > > with the changes necessary to make it stay
> green.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This setup, however, makes it impossible to have
> > > > > > cross-repo
> > > > > > > > PRs
> > > > > > > > > > >> > > > involving Category A and Category B
> > simultaneously,
> > > > with
> > > > > > the
> > > > > > > > > > current
> > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category C repos are kind of floating around,
> and
> > > I'm
> > > > > not
> > > > > > > sure
> > > > > > > > > if
> > > > > > > > > > >> > > > there's much activity going on there.
> Regardless,
> > as
> > > > > > they're
> > > > > > > > > part
> > > > > > > > > > of
> > > > > > > > > > >> > > > Apache KIE, they will be part of our release,
> so I
> > > > > listed
> > > > > > > them
> > > > > > > > > for
> > > > > > > > > > >> us
> > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category D is self explanatory. There's only one
> > > repo
> > > > > that
> > > > > > > has
> > > > > > > > > > >> already
> > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category E are repos that do not host code
> > directly,
> > > > and
> > > > > > are
> > > > > > > > > > either
> > > > > > > > > > >> > > > organizational entities, or host websites, that
> > > > > currently
> > > > > > > are
> > > > > > > > > not
> > > > > > > > > > >> part
> > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This lack of unification between Category A and
> > > > > Category B
> > > > > > > is,
> > > > > > > > > > IMHO,
> > > > > > > > > > >> > > > what allowed us to introduce the infamous
> circular
> > > > > > > dependency
> > > > > > > > > > >> between
> > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now can
> > > > describe
> > > > > > as
> > > > > > > a
> > > > > > > > > > >> circular
> > > > > > > > > > >> > > > dependency between Category A and Category B.
> The
> > > way
> > > > I
> > > > > > see
> > > > > > > > it,
> > > > > > > > > if
> > > > > > > > > > >> we
> > > > > > > > > > >> > > > had a single pipeline, building everything from
> > > > `drools`
> > > > > > to
> > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > introduced,
> > > > > > and
> > > > > > > we
> > > > > > > > > > >> > > > wouldn't be having this huge problem in our
> hands
> > > > right
> > > > > > now.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > My proposal for the Apache KIE release process
> > sees
> > > > this
> > > > > > > lack
> > > > > > > > of
> > > > > > > > > > >> > > > unification as a central problem, not only for
> > this
> > > > > > release
> > > > > > > in
> > > > > > > > > > >> > > > particular, but for the community as a whole. It
> > is
> > > my
> > > > > > > belief
> > > > > > > > > that
> > > > > > > > > > >> we
> > > > > > > > > > >> > > > are all under the same roof, and that no
> > > contribution
> > > > > > should
> > > > > > > > be
> > > > > > > > > > >> > > > allowed to break any part of our codebase. With
> > the
> > > > > > > increasing
> > > > > > > > > > >> volume
> > > > > > > > > > >> > > > of code, and hopefully number of contributors
> too,
> > > we
> > > > > > cannot
> > > > > > > > > keep
> > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > things.
> > > > > We're
> > > > > > > all
> > > > > > > > > > >> humans
> > > > > > > > > > >> > > > after all, and it is our job to have mechanisms
> in
> > > > place
> > > > > > to
> > > > > > > > > > prevent
> > > > > > > > > > >> us
> > > > > > > > > > >> > > > from unwillingly making mistakes. Especially
> when
> > > > these
> > > > > > > > mistakes
> > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > individually,
> > > > > > > > probably
> > > > > > > > > > >> can't
> > > > > > > > > > >> > > > fix.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on
> > > > > > kiegroup's
> > > > > > > > KIE
> > > > > > > > > > >> Tools
> > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > `kogito-images`
> > > > > > > depending
> > > > > > > > on
> > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > kiegroup's
> > > > > > > `lienzo`
> > > > > > > > > and
> > > > > > > > > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps` depending
> on
> > > > > > > kiegroup's
> > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > >> > > > * This module was removed from the KIE codebase
> > > here:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > >> > > >
> > > > > > > > > >
> > > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > ,
> > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > >> > > > * This new repo depends on Kogito and
> OptaPlanner,
> > > > > > pointing
> > > > > > > to
> > > > > > > > > > older
> > > > > > > > > > >> > > > versions.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator`
> > > > > depending
> > > > > > on
> > > > > > > > > > Kogito
> > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P6. Category C repos are out of date and not
> part
> > of
> > > > the
> > > > > > > > > Category
> > > > > > > > > > A
> > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > version
> > > is
> > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > >> > > > depending on Kogito without a specific version,
> > only
> > > > by
> > > > > > > using
> > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version is
> > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has
> > its
> > > > E2E
> > > > > > > > disabled
> > > > > > > > > > >> after
> > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > solution,
> > > > as
> > > > > > they
> > > > > > > > > both
> > > > > > > > > > >> > > > suffer from the circular dependency between
> > > Category A
> > > > > and
> > > > > > > > > > Category
> > > > > > > > > > >> B.
> > > > > > > > > > >> > > > As Category A and Category B are both streams
> that
> > > > have
> > > > > > been
> > > > > > > > > > really
> > > > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > > > contributions
> > > > > > > > that
> > > > > > > > > > >> > > > cannot be done, given that Category A depends on
> > > > > Category
> > > > > > B
> > > > > > > > > with a
> > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P3 and P4, although not ideal, can be understood
> > as
> > > > > > > technical
> > > > > > > > > > debt.
> > > > > > > > > > >> > > > Depending on unmaintained projects is something
> > > we'll
> > > > > > always
> > > > > > > > be
> > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > matter
> > > of
> > > > > > > making
> > > > > > > > > them
> > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P7 is an isolated problem that won't impact the
> > > > > structure
> > > > > > or
> > > > > > > > > > >> anything
> > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > regression
> > > > we
> > > > > > > > > > introduced
> > > > > > > > > > >> > > > recently.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE
> > 10,
> > > > and
> > > > > > > that
> > > > > > > > > P5,
> > > > > > > > > > >> P6,
> > > > > > > > > > >> > > > and P7 have easy fixes, the only problems left
> to
> > > > > discuss
> > > > > > > are
> > > > > > > > P1
> > > > > > > > > > and
> > > > > > > > > > >> > > > P2, which can't be done without a proper
> proposal.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I'll try to be very meticulous here, since from
> my
> > > > > > > experience,
> > > > > > > > > any
> > > > > > > > > > >> > > > little miscalculation can lead to our release
> not
> > > > > working
> > > > > > > out
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > >> > > > end. To try and avoid that as much as possible,
> > and
> > > > make
> > > > > > > > > > everything
> > > > > > > > > > >> we
> > > > > > > > > > >> > > > can to have a successful Apache KIE 10 release,
> > bear
> > > > > with
> > > > > > > me.
> > > > > > > > > I'll
> > > > > > > > > > >> lay
> > > > > > > > > > >> > > > out a timeline of events that need to happen in
> > > order
> > > > > for
> > > > > > > our
> > > > > > > > > > >> release
> > > > > > > > > > >> > > > to be published, with all artifacts ending up in
> > the
> > > > > right
> > > > > > > > > places,
> > > > > > > > > > >> but
> > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > As you saw at the beginning of this email, all
> the
> > > > > > attempts
> > > > > > > we
> > > > > > > > > > made
> > > > > > > > > > >> > > > left us with the circular dependency showing up
> > at a
> > > > > > > different
> > > > > > > > > > >> place,
> > > > > > > > > > >> > > > but something all these places have in common is
> > > that
> > > > > > > they're
> > > > > > > > > all
> > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > The first part of my proposal is the following:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > Quarkus
> > > > Dev
> > > > > > UIs
> > > > > > > > from
> > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > Management
> > > > > and
> > > > > > > > Task
> > > > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > `kogito-swf-builder`
> > > > > > > > > > images
> > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > >> > > > S3. We move the entire
> > `kogito-serverless-operator`
> > > > repo
> > > > > > > > inside
> > > > > > > > > a
> > > > > > > > > > >> new
> > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve problems
> > P1
> > > > and
> > > > > > P2.
> > > > > > > Of
> > > > > > > > > > >> course
> > > > > > > > > > >> > > > the rest of
> > > > > > > > > > >>
> > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This doesn't come without consequences, of
> course,
> > > as
> > > > > the
> > > > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> > > images,
> > > > > and
> > > > > > > the
> > > > > > > > > > >> > > > `kogito-serverless-operator` would be moving
> from
> > > > > > Category A
> > > > > > > > to
> > > > > > > > > > >> > > > Category B. This move would make them have to
> > > > reference
> > > > > > > > > Category A
> > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > `kogito-images`
> > > > > > > and
> > > > > > > > > > >> > > > `kogito-serverless-operator` are already their
> own
> > > > > > > > "sub-stream"
> > > > > > > > > > >> inside
> > > > > > > > > > >> > > > Category A, though, contributions made in a
> > > cross-repo
> > > > > > > fashion
> > > > > > > > > to
> > > > > > > > > > >> this
> > > > > > > > > > >> > > > "sub-stream" will continue being possible, now
> > via a
> > > > > > single
> > > > > > > PR
> > > > > > > > > to
> > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A
> and
> > > > > > Category
> > > > > > > B
> > > > > > > > > will
> > > > > > > > > > >> > > > continue not being possible, and a 1-week delay
> > > > between
> > > > > > > > merging
> > > > > > > > > > >> > > > something on Category A and using it on
> Category B
> > > > will
> > > > > > > still
> > > > > > > > > > >> happen.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`, however,
> > > does
> > > > > > allow
> > > > > > > > for
> > > > > > > > > > >> sparse
> > > > > > > > > > >> > > > checkouts and partial builds, so working with a
> > > subset
> > > > > of
> > > > > > > the
> > > > > > > > > > >> monorepo
> > > > > > > > > > >> > > > is possible and encouraged. Making changes only
> to
> > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example, will
> > > have
> > > > > the
> > > > > > PR
> > > > > > > > > > checks
> > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > >> > > > .
> > > > > > > > > > >> > > > We're not compromising when running partial
> builds
> > > > too.
> > > > > We
> > > > > > > > know
> > > > > > > > > > that
> > > > > > > > > > >> > > > the entire repo will continue working even after
> > > only
> > > > > > > > building a
> > > > > > > > > > >> small
> > > > > > > > > > >> > > > subset of the changes. Doing partial or full
> > builds
> > > is
> > > > > > > > > > automatically
> > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Keep in mind that, even though I'm proposing we
> > > move a
> > > > > > bunch
> > > > > > > > of
> > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see this
> as a
> > > > > > TEMPORARY
> > > > > > > > > > >> solution
> > > > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > > > additional
> > > > > > > stuff
> > > > > > > > > > >> > > > TEMPORARILY so that we can release and continue
> > > moving
> > > > > > > > forward.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> > became a
> > > > > > > polyglot
> > > > > > > > > > >> monorepo
> > > > > > > > > > >> > > > out of necessity, and although I'm really proud
> of
> > > > what
> > > > > we
> > > > > > > > > > achieved
> > > > > > > > > > >> > > > there so far, I don't think `kie-tools` has a
> > setup
> > > > that
> > > > > > is
> > > > > > > > > > suitable
> > > > > > > > > > >> > > > for all the different nuances that compose our
> > > > > community.
> > > > > > > I'm
> > > > > > > > > well
> > > > > > > > > > >> > > > aware that a polyglot monorepo that does not
> > follow
> > > > > > > widespread
> > > > > > > > > > >> > > > conventions will scare some people away, and as
> > much
> > > > as
> > > > > > > we've
> > > > > > > > > > tried
> > > > > > > > > > >> to
> > > > > > > > > > >> > > > make build instructions clear, we can't always
> get
> > > > past
> > > > > > the
> > > > > > > > > > >> prejudice
> > > > > > > > > > >> > > > some people have towards the "front-end"
> > ecosystem.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > With all that said, I keep thinking this is the
> > best
> > > > > > course
> > > > > > > of
> > > > > > > > > > >> action
> > > > > > > > > > >> > > > for us right now. We keep most of our stuff
> > > unchanged,
> > > > > we
> > > > > > > > > unblock
> > > > > > > > > > >> the
> > > > > > > > > > >> > > > release, and we have a working setup that will
> > suit
> > > us
> > > > > > well
> > > > > > > > > while
> > > > > > > > > > we
> > > > > > > > > > >> > > > discuss and reach a conclusion regarding the
> > future
> > > of
> > > > > our
> > > > > > > > > > codebase
> > > > > > > > > > >> > > > structure.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Let me paint a quick picture here of what our
> code
> > > > base
> > > > > > > would
> > > > > > > > > look
> > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> accepted:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > >> > > > A
> incubator-kie-optaplanner-quickstarts
> > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > B
> > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > >> > > > E incubator-kie-kogito-online-staging
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > > > >> > > > `kogito-serverless-operator` moves entirely
> inside
> > > > > > > > `kie-tools`.
> > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > > > > > > > >> > > > `kogito-serverless-operator` inside `kie-tools`,
> > > there
> > > > > are
> > > > > > > no
> > > > > > > > > > cycles
> > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> granularly
> > > > build:
> > > > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > >> and
> > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > >> > > > 4. packages/sonataflow-operator (contents
> from
> > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > The second part of the proposal is the release
> > > process
> > > > > > > itself,
> > > > > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as
> > > cutting
> > > > > > point
> > > > > > > > for
> > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > >> > > > 2. Update Category B repos to point to this
> > > > timestamped
> > > > > > > > > SNAPSHOT,
> > > > > > > > > > >> and
> > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > >> > > > 3. At this point, with everything working, we
> can
> > > > branch
> > > > > > out
> > > > > > > > to
> > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> SNAPSHOT
> > > > tag,
> > > > > > and
> > > > > > > > > > >> Category B
> > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > >> > > > 4. All Category A and Category B repos update
> > their
> > > > > > versions
> > > > > > > > to
> > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > >> > > > 5. Update Category B repos to point to Category
> A
> > > > repos
> > > > > > > using
> > > > > > > > > the
> > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > >> > > > 6. At this point, we can vote on the release
> based
> > > on
> > > > > the
> > > > > > > > > `10.0.x`
> > > > > > > > > > >> > > > branches, given we don't expect any code changes
> > > > > anymore.
> > > > > > > > > > >> > > > 7. After voting passes, we're good to start the
> > > > release
> > > > > > > > process.
> > > > > > > > > > >> > > > 8. Category A repos follow their
> manual/automated
> > > > > release
> > > > > > > > > process,
> > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to
> > Git,
> > > > and
> > > > > > > built
> > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > >> > > > 9. We wait a little bit for Category A artifacts
> > to
> > > be
> > > > > > > > > propagated
> > > > > > > > > > on
> > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > >> > > > 10. Category B repos follow their
> manual/automated
> > > > > release
> > > > > > > > > > process,
> > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to
> > Git,
> > > > and
> > > > > > > built
> > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > >> > > > 12. Category E repos can be manually tagged with
> > > > 10.0.0
> > > > > > from
> > > > > > > > > their
> > > > > > > > > > >> > > > default branches.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > More needs to be discussed if we're planning to
> > > > maintain
> > > > > > > > > multiple
> > > > > > > > > > >> > > > release streams in parallel, but I guess it can
> > wait
> > > > for
> > > > > > > after
> > > > > > > > > > >> Apache
> > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Thank you for reading, and I'm looking forward
> to
> > > > > hearing
> > > > > > > back
> > > > > > > > > > from
> > > > > > > > > > >> > > > everyone.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Of course, alternative solutions are possible.
> > This
> > > > > email,
> > > > > > > > > > however,
> > > > > > > > > > >> > > > summarizes my view of how we should attack the
> > > > problem,
> > > > > > > > > > considering
> > > > > > > > > > >> > > > disruption, required effort, the release process
> > > > itself,
> > > > > > and
> > > > > > > > > > >> history.
> > > > > > > > > > >> > > > Feel free to propose alternatives. This is not a
> > > > voting
> > > > > > > > thread.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Regards,
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >>
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > dev-help@kie.apache.org
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
I forgot the most important part ;)
It is pretty obvious that we have a big mess between images and tools repo
dependencies, so merging or not merging them should be the least of our
concerns. Lets clarify the picture between you, Guilherme and Ricardo, and
adapt CI and repo structures as soon as possible in the easiest possible
way to make the release a reality. I think you are already on it so let's
not waste time discussing dependency theory ;)
Good luck and if you need any help with the runtime/apps part, do not
hesitate to ask.
Cheers
On Thu, Mar 14, 2024 at 8:08 PM Francisco Javier Tirado Sarti <
ftirados@redhat.com> wrote:
> Tiago,
> Maybe I did not explain myself well.
> If you have a dependency in a pom and that dependency does not longer
> exits, the build will fail, of course. I do not think this is related at
> all with using one kind of snapshot or another. In fact, as a proof that
> absolute truths are really rare, if that arficat would have a release
> version, you will believe that your dependency tree is perfectly fine when
> in fact it is obsoleted, so it can be argues than using the same snapshot
> helps to find the issue earlier in the development cycle.
> Anyway, when I refer to strong vs weak dependency (just to let you know
> that spanish translation of fallacy is worse than spanish translation of
> wrong, which does not have such negative connotation, but its ok, I got the
> idea ;)), Im referring to case A( weak) and B (strong)
> A) Examples depends on the recently renamed sonataflow-quarkus-devui
> artfifact. You can remove that dependency from the pom and the example
> still works. Thats a weak dependency, you lose some functionality
> (deployment of tools along the example) but the example is still usable and
> it passes the IT test.
> B) Not compatible modification of drools interface. That's a strong one.
> The sooner we find it the better and I think (its pretty obvious the
> sooner occurs when both drools and runtimes use the same snapshot number,
> rather than relying on a fixed snapshot, when we might realize long after
> the drools change has been performed) .
> So, no su much fallacy after all.
>
> On Thu, Mar 14, 2024 at 7:44 PM Tiago Bento <ti...@gmail.com>
> wrote:
>
>> New day, new findings.
>>
>> Yesterday, in a very fruitful conversation with Caponetto, I
>> discovered that `kie-tools` is currently referencing two additional
>> images from `kogito-images`. The current dependencies between
>> `kie-tools` and `kogito-images` are the following:
>>
>> 1. `packages/kn-plugin-workflow` --> `
>> quay.io/kiegroup/kogito-swf-devmode`
>> <http://quay.io/kiegroup/kogito-swf-devmode>
>> 2. `packages/serverless-logic-web-tools-swf-builder-image` -->
>> `quay.io/kiegroup/kogito-swf-builder`
>> <http://quay.io/kiegroup/kogito-swf-builder>
>> 3. `packages/serverless-logic-web-tools-base-builder-image` -->
>> `quay.io/kiegroup/kogito-base-builder`
>> <http://quay.io/kiegroup/kogito-base-builder>
>> 4. `packages/serverless-logic-web-tools-swf-dev-mode-image` -->
>> `quay.io/kiegroup/kogito-base-builder`
>> <http://quay.io/kiegroup/kogito-base-builder>
>>
>> All these references were already correctly pointing to the `-nightly`
>> builds of each image, mirroring the timestamped SNAPSHOT strategy we
>> currently have. Except for reference 2., which was pointing to
>> `latest`. I sent a PR
>> (https://github.com/apache/incubator-kie-tools/pull/2198) to fix the
>> discrepancy, and to my surprise the PR broke, with a `999-SNAPSHOT`
>> reference not being found during the build.
>>
>> All three images that depend on `kogito-images` are dependencies of
>> the Serverless Logic Web Tools app.
>>
>> This is a clear example of the problems I explained in my previous
>> messages. Let me explain this manifestation of the problem here in
>> more depth.
>>
>> The problem here is a module from a Category A repo was renamed, and
>> the `main-2024-02-18` tag of `quay.io/kiegroup/kogito-swf-builder`
>> <http://quay.io/kiegroup/kogito-swf-builder> was
>> published with a reference to
>>
>> `org.kie.kogito:kogito-addons-quarkus-knative-serving-deployment:999-SNAPSHOT`.
>> An artifact with this GAV does not exist anymore, as SNAPSHOTs are not
>> only mutable, but also ephemeral. IMHO, Maven SNAPSHOTs are NOT a
>> reliable mechanism for repo synchronicity, but that's a problem for
>> later.
>>
>> `kogito-images` depending on upstream repos through mutable, ephemeral
>> SNAPSHOTs, is making `kie-tools` indirectly depend on them too, and as
>> you could see, the build is broken, simply because a module was
>> renamed. With the risk of getting ahead of myself, I just want to make
>> it clear that if `kie-tools` just pointed to the `latest` tag of
>> `kogito-images`, it would be exactly the same case as a Dockerized
>> version of Maven SNAPSHOTs, which, of course, would be problematic,
>> as already extensively explained in this thread.
>>
>> The outcome of my findings between yesterday and today are:
>>
>> A. `kn-plugin-workflow` is not the only package on `kie-tools`
>> depending on `kogito-images`. We also have
>> `serverless-logic-web-tools-swf-builder-image`,
>> `serverless-logic-web-tools-base-builder-image`, and
>> `serverless-logic-web-tools-base-builder-image`. All dependencies to
>> the Serverless Logic Web Tools app.
>> B. weak vs. strong dependencies is a fallacy. Testing and developing
>> require us to have the dependencies available, in sync, at all times.
>> The way I see things, a dependency is a dependency. Period.
>> C. The nightly builds of `kogito-images` are potentially all broken
>> after some modules were renamed, rendering them not usable. This can
>> be mitigated by upgrading to a more recent timestamped SNAPSHOT/tag,
>> which is already PRed
>> (https://github.com/apache/incubator-kie-tools/pull/2193), but the
>> architectural problem will remain, unless we change the automation
>> jobs of `kogito-images` to point to timestamped SNAPSHOTs of upstream
>> artifacts when publishing their own timestamped tags under the
>> "-nightly" prefix. Which I think we have to do, btw.
>>
>> To conclude, the proposal initially shared on this email thread still
>> holds for unblocking and releasing Apache KIE 10, even after those new
>> discoveries.
>>
>> On Thu, Mar 14, 2024 at 1:43 PM Francisco Javier Tirado Sarti
>> <ft...@redhat.com> wrote:
>> >
>> > Hi Jan
>> > Yes, that's why I was also discussing the suitability of timestamped
>> > snapshots.
>> > For me, both amplification of tools repo with unrelated code and
>> > timestamped snapshots are against fixed snapshot and multi repo
>> philosophy
>> > employed in the rest of the project (it will be far easier from CI
>> > perspective to have just one huge repo containing drools, runtimes, apps
>> > and examples, but we are not doing that)
>> > Therefore we are kind of sanctioning two different philosophies in our
>> > first apache release. Since there is apparently no other alternative
>> with
>> > the resources we have, we will have to release it with this discrepancy.
>> > But it is sad and I think we should learn from this experience to avoid
>> > repeating it in the future. In my opinion, this proposal should have
>> been
>> > shared long before to not make it a fait accompli.
>> >
>> > On Thu, Mar 14, 2024 at 6:18 PM Jan Šťastný <js...@apache.org>
>> wrote:
>> >
>> > > Hello,
>> > > I'll try to summarize the challenges I am aware of in relation to CI
>> at the
>> > > moment and with the proposals.
>> > >
>> > > (I am referring to projects forming the build chain as upstream <->
>> > > downstream depending on their placing in the overall chain.)
>> > >
>> > > Current state:
>> > > Category A projects:
>> > > - We don't have one, but rather 3 sets of pipelines for project
>> groups:
>> > > drools, kogito and optaplanner, all these three utilizing a
>> combination of
>> > > GHA (mostly PR checks) and Jenkins pipelines based on
>> > > apache/incubator-kie-kogito-pipelines framework (kogito-pipelines FW).
>> > > - For these builds, we use build-chain tool, which allows to define
>> > > cross-repository relations between projects, clone repositories and
>> run
>> > > custom commands in each of those, depending in what part of the build
>> chain
>> > > (considering the project triggering the build) they are invoked
>> (upstream,
>> > > downstream, current). Examples of the build-chain project dependencies
>> > > configuration Tiago provided in the first email. Build-chain is a
>> powerful
>> > > tool, though we have limited knowledge (Roberto being the sole
>> contributor
>> > > of fixes since our move to ASF).
>> > > - As part of the kogito pipeline kogito-images and *-operator jobs are
>> > > attached, but relation to repositories earlier up the chain is either
>> > > assumed (building from main branch of kogito-apps) or loose (building
>> > > kogito-examples from main-nightly branch, which is created in
>> preceding
>> > > kogito-examples nightly build). It's not part of PR checks for
>> repositories
>> > > up the stream.
>> > >
>> > > Category B projects:
>> > > - We have a unique solution based mainly on GHA, but recently also
>> some
>> > > parts (is it a backup?) in ASF Jenkins, but NOT using the
>> kogito-pipelines
>> > > FW.
>> > >
>> > > Category C projects:
>> > > - There are loosely managed jobs for *-benchmarks repositories, just a
>> > > matter of updating versions, easily manageable - won't discuss
>> further.
>> > >
>> > > Current gaps:
>> > >
>> > > Category A projects:
>> > > - Generally the current jenkins solution for PR checks is lacking, we
>> have
>> > > just a single kind of PR check, not allowing custom triggers (e.g. by
>> > > comments) or various modes (like quarkus native build).
>> > > - We don't have downstream builds as part of PR checks.
>> > > - We build all in a single job. Which has resulted in execution time
>> over 8
>> > > hours which was not bearable. Thus we reduced the build scope to sort
>> of
>> > > compile downstream builds - we run tests for repositories that are
>> part of
>> > > the PR, but their dependents (coming after them) are only run without
>> > > tests.
>> > > - With the introduction of unified SNAPSHOTs we have not fully
>> adjusted for
>> > > this in our pipelines, leaving out relations like optaplanner ->
>> drools and
>> > > kogito-apps -> optaplanner - so problems will be missed in case of
>> related
>> > > PRs. This SNAPSHOT version unification indicates that instead of 3
>> distinct
>> > > buildchain configurations, we should now switch to a single one,
>> especially
>> > > for the sake of unification.
>> > > - Part of the repositories (starting with kogito-images) are not
>> attached
>> > > in the build-chain build at all, but are rather consecutively executed
>> > > pipelines relying on publishing artifacts for consumption downstream.
>> > >
>> > > Proposal assessment:
>> > > - Almost any repository could be part of the build-chain
>> configuration,
>> > > complex invocations can be hidden e.g. using make.
>> > > - Any changes to PR checks should have the following prerequisite not
>> to
>> > > increase complexity and to limit execution times: moving of all PR
>> checks
>> > > into GHA, introduction of isolated limited-scope PR checks, on-demand
>> full
>> > > downstream build.
>> > > - Timestamped SNAPSHOTs consumed by kie-tools would call against
>> attaching
>> > > kie-tools into build-chain of drools/kogito, because we would be
>> running PR
>> > > checks/nightly against main which might differ from the timestamped
>> > > SNAPSHOT. So this seems like either/or decision to me.
>> > > - Build-chain would probably not be able to replicate the fine-grained
>> > > build execution based on the changes in PR as kie-tools currently has
>> in
>> > > place.
>> > > - It's not clear to me how/if we could generally limit scope of
>> execution
>> > > in downstream builds depending on scope of upstream repository
>> changes.
>> > > - Community CI has really limited human resources, I personally
>> switched to
>> > > an ad-hoc way of working on that, only when something breaks.
>> > > - It's not clear to me how a build-chain would work in terms of
>> > > consuming/passing artifacts outside of maven projects and artifacts.
>> > > - It's fair to say that we have SMEs for CI/build in Category A
>> (engines or
>> > > cloud), Category B, but I don't think there's anyone knowing deep
>> internals
>> > > of all, to be able to provide a reliable estimate of efforts involved
>> in
>> > > bigger refactoring.
>> > >
>> > > Summary:
>> > > I don't see an easy way how a simple change in CI would help to
>> unblock the
>> > > current situation. Considering Tiago's proposal, timestamped SNAPSHOTs
>> > > already in place, assumed relative simplicity of making the
>> components part
>> > > of kie-tools build ...
>> > >
>> > > +1 from me
>> > >
>> > > Thanks.
>> > > Best Regards
>> > > Jan
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Thu, 14 Mar 2024 at 11:24, Francisco Javier Tirado Sarti <
>> > > ftirados@redhat.com> wrote:
>> > >
>> > > > Hi Tiago, Thanks for the detailed explanation
>> > > > Actually, for tooling, where there is not strong dependency (as
>> between
>> > > > engine code in runtime and kie server api in drools), the fixed
>> snapshot
>> > > > mechanism will work pretty well, in my opinion.
>> > > > On one side, an example that depends on devui will not fail to
>> compile
>> > > > because the snapshot is old. The contrary is also true, if we add a
>> new
>> > > > functionality in the server side that is going to be used by any
>> tool,
>> > > the
>> > > > worst that might happen is that the functionality is not there in
>> the old
>> > > > snapshot, but it wont block tooling compilation (obviously if you
>> need
>> > > that
>> > > > functionality to test a new UI feature, you will need the update
>> > > snapshot,
>> > > > but that's expected and I guess is also happening now, you need to
>> wait
>> > > for
>> > > > the server artifact to be published on Maven)
>> > > > Because of that loose dependency, tooling can be run, as it is, as
>> an
>> > > > almost completely separate project but also because of that, I feel
>> it
>> > > > might be easily integrated (except for CI changes, which are always
>> > > > delicate) with the rest of the repos to achieve a single release
>> number,
>> > > > because, if all repos use the same snapshot, as far as there is one
>> > > > snapshot, in the day by day experience everything will normally
>> compile.
>> > > > I think we agree that the natural place of tooling in the dependency
>> > > chain
>> > > > is after apps (service) and before images. With that in mind and
>> if we
>> > > > wholly embrace the consequence of being a single release, in my
>> opinion,
>> > > it
>> > > > means that tooling become one more repo (no A no B category),
>> which use
>> > > a
>> > > > fixed snapshot as the rest, and it is subject to the need to
>> eventually
>> > > > wait for the updated snapshot (or in case you cannot wait, a local
>> full
>> > > > build), in the unlikely case there is a change that blocks its local
>> > > > compilation. The implication of this is that the development cycle
>> that
>> > > is
>> > > > implicit in your proposal to use a "fixed snapshot" in category A
>> repos
>> > > no
>> > > > longer apply.
>> > > > This means no time to adjust, which can sound like an herexy, but,
>> if
>> > > there
>> > > > is no need for a gap between drools and runtimes, why is there a
>> need
>> > > for a
>> > > > gap between tooling and apps (services)? (I think we agree a Java
>> API
>> > > > dependency is stronger than a REST API) Do we have a real
>> precedent that
>> > > > justify that? I kind of feel that here we are converting an old
>> habit
>> > > into
>> > > > an axiomatic need (probably because Im lacking context)
>> > > > Now my proposal for CI, we do not really need a single stream right
>> now.
>> > > We
>> > > > can keep the current kogito stream as it is, except for images, and
>> > > > integrate tooling into the stream that is now used for the operator
>> (the
>> > > > assumption here is that a change in drools-runtimes hardly breaks
>> the
>> > > tools
>> > > > and in any case that is already happening, so we do not lose
>> anything)
>> > > >
>> > > >
>> > > > On Wed, Mar 13, 2024 at 8:18 PM ricardo zanini fernandes <
>> > > > ricardozanini@gmail.com> wrote:
>> > > >
>> > > > > Hey Tiago, thanks for the insights, I appreciate it.
>> > > > >
>> > > > > Just one thing regarding building from kie-tools one module that
>> images
>> > > > > need to sync changes. That might happen, of course. If I see a
>> problem
>> > > in
>> > > > > devui, I just report it in the tools repo, we work on the bug,
>> and in
>> > > the
>> > > > > next image build we get the changes. By the nature of the
>> > > > operator/images,
>> > > > > such changes won't impact our builds. What impact our builds are
>> > > > > self-contained on those repos or work made in the engines, where
>> we
>> > > rely
>> > > > on
>> > > > > Snapshots.
>> > > > >
>> > > > > I understand your concern and it's a valid point, but in
>> practice, it's
>> > > > not
>> > > > > what happens. We can live with the latest released version from
>> npm
>> > > > > packages during the dev phase without any problems. From the
>> > > > > images/operator perspective, they are yet another package I need
>> to
>> > > > install
>> > > > > on my container. Like `cat` or `jq`.
>> > > > >
>> > > > > But we need to sit down and try to understand our boundaries and
>> how to
>> > > > do
>> > > > > integration tests based on them. For example, deploying a devmode
>> > > > workflow
>> > > > > in Kubernetes and starting a workflow instance via the devui
>> console.
>> > > > >
>> > > > > On Wed, Mar 13, 2024 at 3:54 PM Tiago Bento <
>> > > > tiagobentofernandes@gmail.com
>> > > > > >
>> > > > > wrote:
>> > > > >
>> > > > > > Francisco,
>> > > > > >
>> > > > > > I agree with you that both reasonings are not antagonistic, as
>> an
>> > > > > > antagonistic reasoning in this case would be one that doesn't
>> work.
>> > > > > > And I believe it is clear now that the initial proposal shared
>> on
>> > > this
>> > > > > > email thread does work, but it is not the only possibility.
>> From the
>> > > > > > beginning I said there are alternatives, but I wanted to start
>> the
>> > > > > > conversation from my point of view, sharing what I think is
>> best. We
>> > > > > > have to acknowledge, though, IMHO, that the discussions we had
>> thus
>> > > > > > far cannot be understood as clearly as what was initially laid
>> out,
>> > > > > > given the lack of details/analysis and a clear execution plan.
>> > > > > >
>> > > > > > Let me elaborate on top of the 3-step plan you shared.
>> > > > > >
>> > > > > > 1)
>> > > > > > No comment. This should be pretty simple to do.
>> > > > > >
>> > > > > > 2)
>> > > > > > There is no global CI stream to be changed, we would have to
>> create
>> > > > > > one. And this has serious implications to our contribution
>> model for
>> > > > > > cross-repo PRs. As I described on the first email of this
>> thread,
>> > > > > > Category A repos are configured in several disjoint streams.
>> Sending
>> > > a
>> > > > > > PR to `drools` and `kogito-runtimes` will work great, but
>> sending a
>> > > PR
>> > > > > > to `drools` and `kogito-images`, or `drools` and `optaplanner`
>> won't
>> > > > > > verify that everything will continue working after the PRs are
>> > > merged,
>> > > > > > as our PR checks are not prepared to build this combination of
>> repos
>> > > > > > together. This is a problem, in my view, but I hardly
>> contribute to
>> > > > > > Category A repos, so I'm assuming things are working fine for
>> those
>> > > > > > who do. The proposal shared on the first email of this thread
>> does
>> > > not
>> > > > > > change the contribution workflow for any repo of Apache KIE, and
>> > > > > > everyone can continue contributing the way they're used to,
>> except
>> > > for
>> > > > > > people contributing to the `kogito-swf-{builder,devmode}`
>> images, and
>> > > > > > to `kogito-serverless-operator`. On the other hand, having
>> > > `kie-tools`
>> > > > > > built in the middle of a new global CI stream, would span
>> another
>> > > > > > class of problem, which is very closely related to the third
>> bullet
>> > > > > > point of the plan you shared.
>> > > > > >
>> > > > > > 3)
>> > > > > > Maven has a mechanism to achieve this pseudo-synchronicity
>> between
>> > > > > > multiple repositories. The mutable SNAPSHOT version, built
>> nightly.
>> > > It
>> > > > > > is not perfect, though, as I'm sure many of us already
>> experienced
>> > > > > > pulling from the `main` branch of a single repo only to find
>> out that
>> > > > > > a PR ensemble had been merged a few moments prior, requiring us
>> to
>> > > > > > rebuild the entire stack, since our local SNAPSHOTs had become
>> > > > > > out-of-date. That's what we used to have back in Business
>> Central
>> > > > > > (a.k.a. v7) days. Making a `git pull` on a single repo in this
>> setup
>> > > > > > potentially requires all repos to be pulled and rebuilt. I'm
>> sure
>> > > this
>> > > > > > still happens sometimes when developing Category A projects.
>> > > > > >
>> > > > > > NPM packages don't have mutable SNAPSHOTs. Every published NPM
>> > > package
>> > > > > > is immutable, and it is really cumbersome and error-prone to
>> > > integrate
>> > > > > > downstream repos with upstream NPM-bound repos, as not having a
>> > > > > > lockfile brings all sorts of security and stability problems.
>> That's
>> > > > > > why monorepos became so popular in the JavaScript ecosystem.
>> This
>> > > lack
>> > > > > > of a mutable SNAPSHOT mechanism makes depending on NPM artifacts
>> > > > > > coming from `kie-tools` really hard. The way I see it, moving
>> repos
>> > > > > > downstream of `kie-tools` will require everyone to build
>> `kie-tools`
>> > > > > > anyway, potentially on a daily basis, since it would've then
>> become
>> > > > > > part of the stack that needs to be built before `kogito-images`
>> and
>> > > > > > `kogito-serverless-operator`. More than that, since there would
>> be no
>> > > > > > way to determine what subset of packages of `kie-tools` would
>> need to
>> > > > > > be built to satisfy downstream references, everyone would have
>> to do
>> > > a
>> > > > > > full build, or handpick individual packages of the monorepo to
>> build.
>> > > > > >
>> > > > > > I hope I was able to offer more insight in the way I see things,
>> > > along
>> > > > > > with my take on using Maven SNAPSHOTs as the de-facto solution
>> for a
>> > > > > > poly-repo codebase. I don't think we can escape from the
>> complexity
>> > > of
>> > > > > > our codebase and the nature of the technologies we use, only
>> > > > > > accommodate it in the most comfortable place possible, if even
>> there
>> > > > > > is such a place :)
>> > > > > >
>> > > > > > Now, there are some things I'd like to say regarding the initial
>> > > > > > proposal shared on this email thread.
>> > > > > >
>> > > > > > I understand you, and others, are concerned about moving stuff
>> into
>> > > > > > `kie-tools` for some reasons I could gather from your messages.
>> I'll
>> > > > > > try and list them here, along with my perspective on each of
>> them.
>> > > > > >
>> > > > > > 1. Never being able to move them out of `kie-tools` again.
>> > > > > > This is going to be as hard as it would be removing
>> > > > > > `kn-plugin-workflow` from it now. So, as you and others
>> mentioned
>> > > this
>> > > > > > possibility, I assume you understand it to be doable.
>> > > > > >
>> > > > > > 2. "Heterodoxizing" an orthodox repository
>> > > > > > (`kogito-serverless-operator`), potentially harming external
>> > > > > > contributions.
>> > > > > > Agree with this point. `kie-tools` is one of a kind, built
>> around
>> > > > > > front-end tooling with some completely unique in-house
>> apparatus. In
>> > > > > > my experience, though, there are a multitude of factors that
>> make
>> > > > > > people want to contribute to an open source project.
>> Conformance to
>> > > > > > well-known widespread technologies and tools is just one of
>> them.
>> > > > > > Being open about it and writing material to smooth out those
>> edges
>> > > can
>> > > > > > work pretty well. People do not contribute because a codebase is
>> > > > > > "pure". People contribute because they care about the project.
>> And
>> > > I'm
>> > > > > > always surprised by the lengths people go to when they want to
>> get
>> > > > > > involved.
>> > > > > >
>> > > > > > 3. Disruption to the contribution workflow of those
>> contributing to
>> > > > > > `kogito-swf-{builder,devmode}` images, and to
>> > > > > > `kogito-serverless-operator`.
>> > > > > > It is clear to me now that we can't unblock and release Apache
>> KIE 10
>> > > > > > without impacting anyone, but I hope the first part of this
>> reply
>> > > > > > sheds some light on this complicated matter.
>> > > > > >
>> > > > > > Anyway, that's my attempt to offer a different perspective to
>> some of
>> > > > > > the problems you expressed concern about, perhaps even making
>> the
>> > > > > > initial proposal shared on this email thread be seen with less
>> > > > > > uncertainty.
>> > > > > >
>> > > > > > On Wed, Mar 13, 2024 at 11:40 AM Francisco Javier Tirado Sarti
>> > > > > > <ft...@redhat.com> wrote:
>> > > > > > >
>> > > > > > > Tiago,
>> > > > > > > Unfortunately, my plan is too conceptually simple to write
>> more
>> > > than
>> > > > I
>> > > > > > > already wrote.
>> > > > > > > 1) Move kn-plugin-workflow module to operator repo (this
>> remove the
>> > > > > > > dependency between tools and operator, breaking the loop)
>> > > > > > > 2) Change CI global stream to execute tooling repo before
>> operator
>> > > > repo
>> > > > > > > (this seems to take 2 months unless Tristan helps and reduce
>> the
>> > > time
>> > > > > to
>> > > > > > 2
>> > > > > > > weeks)
>> > > > > > > 3) Optionally, and just as a consequence of that CI change,
>> set
>> > > > > > > 999-SNAPSHOT version to all poms in all repos (if current
>> snapshot
>> > > > > > numbers
>> > > > > > > turns out to be a problem, in any case this is just
>> search-replace)
>> > > > > > >
>> > > > > > > The current plan is:
>> > > > > > > 1) Move everything depending on tools to tools repo, which
>> includes
>> > > > > > > operator code and examples.
>> > > > > > > 2) Change CI of tooling repo to enforce dependencies between
>> the
>> > > > > existing
>> > > > > > > modules there and the newly moved ones (this seems to take 3
>> weeks
>> > > or
>> > > > > > less)
>> > > > > > >
>> > > > > > > I think rather than asking for a more detailed alternative,
>> what
>> > > > needs
>> > > > > to
>> > > > > > > be done is to refine the existing proposal with the feedback
>> > > > received.
>> > > > > I
>> > > > > > do
>> > > > > > > not think both proposals are antagonistic. I think that,
>> being now
>> > > > > clear
>> > > > > > we
>> > > > > > > have the same overall goal (execute tooling before operator),
>> it is
>> > > > > just
>> > > > > > a
>> > > > > > > question of deciding between move more stuff to an already
>> > > heterodox
>> > > > > > repo,
>> > > > > > > coming from repos not as heterodox, plus changing the repo CI
>> to
>> > > > impose
>> > > > > > > certain order between these modules or pull out the the
>> operator
>> > > > stuff
>> > > > > > from
>> > > > > > > tool repo and put it inside the operator repo plus changing
>> the CI
>> > > > > > > handling repos to impose the desired order: first tooling and
>> then
>> > > > > > operator.
>> > > > > > >
>> > > > > > > On Wed, Mar 13, 2024 at 4:12 PM Tiago Bento <
>> > > > > > tiagobentofernandes@gmail.com>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > Francisco,
>> > > > > > > >
>> > > > > > > > 1) `kie-tools` is already a heterodox repo. The reason why I
>> > > > proposed
>> > > > > > > > my proposal is because it is what I think is the best
>> course of
>> > > > > action
>> > > > > > > > for our community right now. If you think there's a better
>> way to
>> > > > do
>> > > > > > > > it, I think everyone, including me, needs to see a proposal
>> with
>> > > a
>> > > > > > > > clear execution plan with a comparable level of detail and
>> > > analysis
>> > > > > in
>> > > > > > > > regards to disruption of the current state, the required
>> effort,
>> > > > the
>> > > > > > > > contribution workflow for cross-repo PRs, and the release
>> process
>> > > > > > > > itself. Otherwise, we risk having gaps that each person
>> will fill
>> > > > in
>> > > > > a
>> > > > > > > > different way, and IMHO, that's where problems happen. +1
>> for
>> > > > > examples
>> > > > > > > > unification, btw :)
>> > > > > > > >
>> > > > > > > > 2) Ok, and +1 for no categorization.
>> > > > > > > >
>> > > > > > > > On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado
>> Sarti
>> > > > > > > > <ft...@redhat.com> wrote:
>> > > > > > > > >
>> > > > > > > > > 1) Ok, if that is the case, I do not get why your first
>> > > proposal
>> > > > > was
>> > > > > > not
>> > > > > > > > > the one I'm proposing and it is apparently not detailed
>> enough.
>> > > > To
>> > > > > > move
>> > > > > > > > > kn-workflow from tooling to operator one and change the
>> order
>> > > in
>> > > > > > which
>> > > > > > > > the
>> > > > > > > > > repos are being processed. Basically, the problem of the
>> > > proposed
>> > > > > > > > solution
>> > > > > > > > > is that it kind of converts tooling repo into a pretty
>> > > heterodox
>> > > > > repo
>> > > > > > > > > compared with runtimes, drools or operator one. Also once
>> > > tooling
>> > > > > is
>> > > > > > not
>> > > > > > > > a
>> > > > > > > > > final repo in the overall chain, we can consider moving
>> > > examples
>> > > > as
>> > > > > > the
>> > > > > > > > > final one and include tooling showcases there (rather than
>> > > > > splitting
>> > > > > > > > > examples into examples with tooling and examples without
>> > > > tooling).
>> > > > > > > > > 2) I think this distinction between A and B is one between
>> > > > several
>> > > > > > > > possible
>> > > > > > > > > categorizations (not much, including no categorization at
>> all)
>> > > > that
>> > > > > > > > > deserves a separate discussion. I will open a separate
>> thread
>> > > for
>> > > > > > that
>> > > > > > > > > purpose, since we are not going to change that now and it
>> is
>> > > not
>> > > > > > really
>> > > > > > > > > part of the proposal.
>> > > > > > > > >
>> > > > > > > > > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
>> > > > > > > > tiagobentofernandes@gmail.com>
>> > > > > > > > > wrote:
>> > > > > > > > >
>> > > > > > > > > > Francisco,
>> > > > > > > > > >
>> > > > > > > > > > 1) That's what this thread is all about... You know I
>> don't
>> > > > think
>> > > > > > it's
>> > > > > > > > > > ok. That's why I'm proposing the two images and the
>> operator
>> > > to
>> > > > > > move
>> > > > > > > > > > into the `kie-tools` repo, where we can more granularly
>> > > control
>> > > > > the
>> > > > > > > > > > order things are built, thus removing the dependency
>> cycle.
>> > > > > > > > > >
>> > > > > > > > > > 2) Not sure we understand the same thing by "freeze". My
>> > > > proposal
>> > > > > > is
>> > > > > > > > > > that we select a timestamped SNAPSHOT version from
>> Category A
>> > > > > > repos to
>> > > > > > > > > > use as base for a release. We give Category B repos
>> some time
>> > > > to
>> > > > > > > > > > adjust, and then cut the release branches. This can
>> happen
>> > > > > anytime,
>> > > > > > > > > > and no contributions would ever stop because of it. The
>> > > > > development
>> > > > > > > > > > branches can continue accepting PRs normally, even
>> during the
>> > > > > > release
>> > > > > > > > > > process. Now, if what you're asking is why Category B
>> repos
>> > > > refer
>> > > > > > to
>> > > > > > > > > > Category A repos via timestamped SNAPSHOTs, the answer
>> is in
>> > > my
>> > > > > > first
>> > > > > > > > > > email. See the paragraph starting with "An important
>> note
>> > > here
>> > > > is
>> > > > > > that
>> > > > > > > > > > Category B repositories...".
>> > > > > > > > > >
>> > > > > > > > > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado
>> > > Sarti
>> > > > > > > > > > <ft...@redhat.com> wrote:
>> > > > > > > > > > >
>> > > > > > > > > > > Tiago
>> > > > > > > > > > > There are a couple of simple and straightforward
>> questions
>> > > > > that
>> > > > > > I
>> > > > > > > > > > > formulated, but since we both write a lot, it might
>> have
>> > > been
>> > > > > > lost.
>> > > > > > > > > > Please
>> > > > > > > > > > > let me ask them again.
>> > > > > > > > > > > 1) Do you think it is ok that tools repo is executed
>> after
>> > > > > > > > generation of
>> > > > > > > > > > > docker images that are supposed to include those
>> tools or
>> > > the
>> > > > > > > > operator
>> > > > > > > > > > that
>> > > > > > > > > > > is supposed to deploy such images?
>> > > > > > > > > > That's what this thread is all about... You know I'm
>> not ok
>> > > > with
>> > > > > > it,
>> > > > > > > > > > that's why I'm proposing the two images and the
>> operator to
>> > > > move
>> > > > > > into
>> > > > > > > > > > the `kie-tools` repo, where we can more granularly
>> control
>> > > the
>> > > > > > order
>> > > > > > > > > > things are built and remove the dependency cycle.
>> > > > > > > > > > > 2) Besides that, although not directly related with
>> the
>> > > > current
>> > > > > > > > proposal
>> > > > > > > > > > we
>> > > > > > > > > > > are discussing, I really think there are some
>> restrictions
>> > > > > taken
>> > > > > > for
>> > > > > > > > > > > granted that are arbitrary and difficult to sustain on
>> > > > strictly
>> > > > > > > > technical
>> > > > > > > > > > > arguments. For example, the need to freeze the rest
>> of the
>> > > > > > software
>> > > > > > > > > > before
>> > > > > > > > > > > tools are generated. Why? We have dependencies between
>> > > repos
>> > > > > that
>> > > > > > > > are not
>> > > > > > > > > > > handled that way: Apps depend on runtimes. Runtimes
>> depend
>> > > on
>> > > > > > drools,
>> > > > > > > > > > > Operator depend on runtimes,....and we are not
>> freezing
>> > > that
>> > > > > > repos
>> > > > > > > > since
>> > > > > > > > > > we
>> > > > > > > > > > > are all releasing at the same time. If we are all
>> releasing
>> > > > at
>> > > > > > the
>> > > > > > > > same
>> > > > > > > > > > > time, what's the rationale behind the freeze?
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <
>> > > > > > tiagobento@apache.org>
>> > > > > > > > > > wrote:
>> > > > > > > > > > >
>> > > > > > > > > > > > Glad to see the interest this proposal has gotten,
>> and
>> > > it's
>> > > > > > good to
>> > > > > > > > > > > > see some alternatives being drafted here, although
>> still
>> > > > > > lacking
>> > > > > > > > clear
>> > > > > > > > > > > > definitions and analysis in regards to disruption,
>> > > required
>> > > > > > effort,
>> > > > > > > > > > > > the release process itself, and history. Of course,
>> lots
>> > > of
>> > > > > > details
>> > > > > > > > > > > > and clarity on the execution part would be missing
>> too.
>> > > > > > > > > > > >
>> > > > > > > > > > > > As of this moment, based on what I read here, I'm
>> > > assuming
>> > > > > that
>> > > > > > > > > > > > everyone who participated so far doesn't see the
>> initial
>> > > > > > proposal
>> > > > > > > > as
>> > > > > > > > > > > > problematic in terms of feasibility, but some of you
>> > > have a
>> > > > > > > > preference
>> > > > > > > > > > > > not to go with it, because it is "wrong", and
>> apparently
>> > > > > > because it
>> > > > > > > > > > > > would "jeopardize the evolution of the project".
>> Reading
>> > > > > these
>> > > > > > last
>> > > > > > > > > > > > words made me a little sad, to be honest. But I can
>> deal
>> > > > with
>> > > > > > it :)
>> > > > > > > > > > > >
>> > > > > > > > > > > > Please let's try and keep the discussion as
>> objective as
>> > > > > > possible.
>> > > > > > > > > > > > "Right" and "wrong" are too subjective for this
>> kind of
>> > > > > > > > conversation.
>> > > > > > > > > > > >
>> > > > > > > > > > > > Now, being practical, unless there are clear
>> arguments
>> > > > based
>> > > > > on
>> > > > > > > > facts
>> > > > > > > > > > > > and objective concepts that invalidate the initial
>> > > proposal
>> > > > > > shared
>> > > > > > > > on
>> > > > > > > > > > > > this email, it seems to me that it is currently the
>> only
>> > > > > viable
>> > > > > > > > > > > > proposal we have for unblocking and releasing
>> Apache KIE
>> > > > 10.
>> > > > > Of
>> > > > > > > > > > > > course, if we end up seeing an alternative proposal
>> with
>> > > > > enough
>> > > > > > > > > > > > details and a clear execution plan, I think then
>> we'll be
>> > > > in
>> > > > > a
>> > > > > > very
>> > > > > > > > > > > > good position to choose from multiple options!
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <
>> > > > > > alex@porcelli.me>
>> > > > > > > > > > wrote:
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > Francisco and Gabriele,
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > I understand and acknowledge your desire to find
>> the
>> > > > > “right”
>> > > > > > > > solution
>> > > > > > > > > > > > > instead to work on a temporary “patch” - however
>> > > without
>> > > > a
>> > > > > > > > detailed
>> > > > > > > > > > > > > proposal I don’t think we can properly evaluate
>> the
>> > > > impact
>> > > > > of
>> > > > > > > > your
>> > > > > > > > > > > > > suggestion.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > When I spoke with different SMEs that included
>> tools
>> > > and
>> > > > > CI,
>> > > > > > the
>> > > > > > > > > > > > > guesstimate for making the necessary changes on
>> CI and
>> > > > > > codebase
>> > > > > > > > to
>> > > > > > > > > > > > > basically have images and operators in the end of
>> the
>> > > > build
>> > > > > > > > chain is
>> > > > > > > > > > > > > something like 2 months of effort. Another impact
>> that
>> > > > > needs
>> > > > > > to
>> > > > > > > > be
>> > > > > > > > > > > > > discussed is that KIE Tools repo had to be
>> injected in
>> > > > the
>> > > > > > > > middle of
>> > > > > > > > > > all
>> > > > > > > > > > > > > pipelines - forcing all PR checks and nightlies to
>> > > build
>> > > > > all
>> > > > > > > > repos
>> > > > > > > > > > (PR
>> > > > > > > > > > > > > checks will likely take 12+ hours… I even heard
>> that it
>> > > > > > could be
>> > > > > > > > > > even 24
>> > > > > > > > > > > > > hours).
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > Based on the input above, I think it’s quite risk
>> to
>> > > move
>> > > > > in
>> > > > > > such
>> > > > > > > > > > > > direction
>> > > > > > > > > > > > > without a more detailed plan… because 2 months
>> could be
>> > > > > > turned
>> > > > > > > > > > easily in
>> > > > > > > > > > > > 6!
>> > > > > > > > > > > > > And this is exactly what happened when we guessed
>> that
>> > > > > > moving to
>> > > > > > > > > > Apache
>> > > > > > > > > > > > > would take no more than 3 months. But here we are.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > I really strongly suggest that we focus on a
>> release
>> > > that
>> > > > > > could
>> > > > > > > > be
>> > > > > > > > > > > > > achievable in less than a month from now, and we -
>> > > after
>> > > > > > release
>> > > > > > > > -
>> > > > > > > > > > have a
>> > > > > > > > > > > > > in depth discussion about the overall codebase
>> and ci
>> > > > > > > > organization.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
>> > > > > > > > > > > > gabriele.cardosi@gmail.com>
>> > > > > > > > > > > > > wrote:
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > > Alex,
>> > > > > > > > > > > > > > my suggestion is to move the building of all
>> docker
>> > > > > images,
>> > > > > > > > from
>> > > > > > > > > > > > whatever
>> > > > > > > > > > > > > > repo (kogito-apps, kie-tools) in a different,
>> > > > downstream
>> > > > > > repo,
>> > > > > > > > to
>> > > > > > > > > > be
>> > > > > > > > > > > > > > invoked after all the others.
>> > > > > > > > > > > > > > I'm not sure if this would solve all the
>> issues, and
>> > > > > since
>> > > > > > I
>> > > > > > > > could
>> > > > > > > > > > not
>> > > > > > > > > > > > > > enter in the details of all the involved code,
>> my
>> > > > > > suggestion
>> > > > > > > > may
>> > > > > > > > > > be too
>> > > > > > > > > > > > > > naive.
>> > > > > > > > > > > > > > Having spent almost all of the last year in
>> CI, I
>> > > may
>> > > > > say
>> > > > > > > > that, at
>> > > > > > > > > > > > least
>> > > > > > > > > > > > > > for the kie-tools repo, removing the image
>> build step
>> > > > > from
>> > > > > > it
>> > > > > > > > > > should
>> > > > > > > > > > > > not be
>> > > > > > > > > > > > > > too difficult (since it is an issue we already
>> faced
>> > > > and
>> > > > > > > > solved).
>> > > > > > > > > > > > > > If, with "detailed proposal", you mean a
>> complete
>> > > list
>> > > > of
>> > > > > > all
>> > > > > > > > > > modules
>> > > > > > > > > > > > to be
>> > > > > > > > > > > > > > moved and dependency refactoring, of course I
>> can not
>> > > > > > provide
>> > > > > > > > it
>> > > > > > > > > > right
>> > > > > > > > > > > > now.
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > Anyway, I share the concern from Francisco:
>> undoing
>> > > > > > something
>> > > > > > > > is
>> > > > > > > > > > almost
>> > > > > > > > > > > > > > always harder than doing it "rightly" from
>> scratch...
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43
>> Francisco
>> > > > Javier
>> > > > > > > > Tirado
>> > > > > > > > > > Sarti
>> > > > > > > > > > > > <
>> > > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > I do not think estimations should be the only
>> > > driver
>> > > > to
>> > > > > > make
>> > > > > > > > a
>> > > > > > > > > > > > decision,
>> > > > > > > > > > > > > > > especially when the current proposal is
>> > > conceptually
>> > > > > > > > incompatible
>> > > > > > > > > > > > with
>> > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > multi repo approach that is taken elsewhere
>> in the
>> > > > > > project.
>> > > > > > > > > > > > > > > Given my knowledge of the CI it is nearly
>> > > impossible
>> > > > > for
>> > > > > > me
>> > > > > > > > to
>> > > > > > > > > > give
>> > > > > > > > > > > > a
>> > > > > > > > > > > > > > fair
>> > > > > > > > > > > > > > > estimate of how much it might take to achieve
>> step
>> > > 2)
>> > > > > of
>> > > > > > my
>> > > > > > > > > > previous
>> > > > > > > > > > > > > > e-mail
>> > > > > > > > > > > > > > > . It might take a while or it might be pretty
>> easy
>> > > > > after
>> > > > > > > > all, I
>> > > > > > > > > > don't
>> > > > > > > > > > > > > > > really know, but I think it will be a good
>> idea if
>> > > > > some
>> > > > > > of
>> > > > > > > > the
>> > > > > > > > > > > > experts
>> > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > CI in the team (the ones that set up the
>> pipeline,
>> > > > > which
>> > > > > > was
>> > > > > > > > a
>> > > > > > > > > > huge
>> > > > > > > > > > > > > > > achievement) give an estimate, not me.
>> Estimating
>> > > > how
>> > > > > > much
>> > > > > > > > it
>> > > > > > > > > > takes
>> > > > > > > > > > > > to
>> > > > > > > > > > > > > > > merge two existing repos (without altering
>> CI) is
>> > > > > easier,
>> > > > > > > > but it
>> > > > > > > > > > > > does not
>> > > > > > > > > > > > > > > mean we are doing the right thing.
>> > > > > > > > > > > > > > > My main concern is that it will be very
>> difficult
>> > > for
>> > > > > me
>> > > > > > to
>> > > > > > > > > > explain
>> > > > > > > > > > > > to
>> > > > > > > > > > > > > > > someone that arrives new to the team, that
>> having
>> > > > > > experts on
>> > > > > > > > CI
>> > > > > > > > > > on
>> > > > > > > > > > > > the
>> > > > > > > > > > > > > > > team, we decided to merge two repos (once
>> merged,
>> > > it
>> > > > > > would be
>> > > > > > > > > > rather
>> > > > > > > > > > > > > > > difficult to unmerge) rather than fix the CI,
>> > > because
>> > > > > of
>> > > > > > > > > > expediency.
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex
>> Porcelli <
>> > > > > > > > > > porcelli@apache.org>
>> > > > > > > > > > > > > > > wrote:
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > Francisco,
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > Please take the time to make the more in
>> depth
>> > > > > analysis
>> > > > > > > > needed
>> > > > > > > > > > and
>> > > > > > > > > > > > > > > provide
>> > > > > > > > > > > > > > > > a more detailed plan… so we - as community-
>> can
>> > > > > > evaluate
>> > > > > > > > the
>> > > > > > > > > > size
>> > > > > > > > > > > > of
>> > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > effort. In the conceptual level you shared
>> it’s
>> > > > near
>> > > > > > > > > > impossible to
>> > > > > > > > > > > > > > > estimate
>> > > > > > > > > > > > > > > > the size of the effort and compare with the
>> > > current
>> > > > > > > > proposal.
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco
>> Javier
>> > > > > Tirado
>> > > > > > > > Sarti <
>> > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > I think I already did a high level
>> proposal.
>> > > > > > > > > > > > > > > > > 1) Remove all dependencies from tooling
>> to
>> > > > images,
>> > > > > > so
>> > > > > > > > images
>> > > > > > > > > > > > depend
>> > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > tooling but tooling does not depend on
>> images.
>> > > > > > > > > > > > > > > > > 2) Then change CI to deal with tooling
>> repo
>> > > > before
>> > > > > > > > dealing
>> > > > > > > > > > with
>> > > > > > > > > > > > > > images
>> > > > > > > > > > > > > > > > > repo.
>> > > > > > > > > > > > > > > > > I understand that CI details are tricky
>> and
>> > > since
>> > > > > > I'm not
>> > > > > > > > > > > > familiar
>> > > > > > > > > > > > > > with
>> > > > > > > > > > > > > > > > CI
>> > > > > > > > > > > > > > > > > in any way, I barely can make a low level
>> > > design,
>> > > > > > but we
>> > > > > > > > do
>> > > > > > > > > > not
>> > > > > > > > > > > > need
>> > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > fix
>> > > > > > > > > > > > > > > > > everything, just achieve 2), a change of
>> > > > > compilation
>> > > > > > > > order.
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex
>> Porcelli
>> > > <
>> > > > > > > > > > alex@porcelli.me
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > > > wrote:
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > Francisco and Grabriele,
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > You may not like or understand why the
>> > > current
>> > > > > > state of
>> > > > > > > > > > the CI
>> > > > > > > > > > > > is
>> > > > > > > > > > > > > > > like
>> > > > > > > > > > > > > > > > > > that… actually has been in Red Hat and
>> has
>> > > been
>> > > > > > > > replicated
>> > > > > > > > > > in
>> > > > > > > > > > > > > > Apache
>> > > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > > used to be….
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > But the fact is that this is the current
>> > > > reality.
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > If you disagree with the current plan,
>> please
>> > > > > > provide a
>> > > > > > > > > > > > detailed
>> > > > > > > > > > > > > > > > > > alternative so we, as community, can
>> better
>> > > > > > evaluate
>> > > > > > > > the
>> > > > > > > > > > pros
>> > > > > > > > > > > > and
>> > > > > > > > > > > > > > > cons
>> > > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > each proposal.
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > I think it’s also fair to say that,
>> post 10
>> > > > > > release we
>> > > > > > > > > > need to
>> > > > > > > > > > > > > > have a
>> > > > > > > > > > > > > > > > > much
>> > > > > > > > > > > > > > > > > > in depth discussion about how our
>> codebase is
>> > > > > > > > organized,
>> > > > > > > > > > it’s
>> > > > > > > > > > > > clear
>> > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > it’s not working.
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele
>> > > > Cardosi
>> > > > > <
>> > > > > > > > > > > > > > > > > > gabriele.cardosi@gmail.com>
>> > > > > > > > > > > > > > > > > > wrote:
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > As Francisco said,
>> > > > > > > > > > > > > > > > > > > I also have the impression that the
>> > > "images"
>> > > > > (if
>> > > > > > we
>> > > > > > > > are
>> > > > > > > > > > > > talking
>> > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > docker
>> > > > > > > > > > > > > > > > > > > images) should be the very last one
>> to be
>> > > > > built,
>> > > > > > in a
>> > > > > > > > > > > > standalone
>> > > > > > > > > > > > > > > > repo.
>> > > > > > > > > > > > > > > > > > > That way, they may "combine"
>> artifacts that
>> > > > are
>> > > > > > > > built in
>> > > > > > > > > > > > > > different
>> > > > > > > > > > > > > > > > > repos,
>> > > > > > > > > > > > > > > > > > > regardless of the order in which
>> those are
>> > > > > built.
>> > > > > > > > > > > > > > > > > > > Moving them out of all the repos
>> > > > > > > > (kogito-apps/kie-tools)
>> > > > > > > > > > > > maybe
>> > > > > > > > > > > > > > > could
>> > > > > > > > > > > > > > > > > > > simplify the situation a bit.
>> > > > > > > > > > > > > > > > > > > (I also think there are some
>> statements of
>> > > > > > > > undisputable
>> > > > > > > > > > needs
>> > > > > > > > > > > > > > while
>> > > > > > > > > > > > > > > > > they
>> > > > > > > > > > > > > > > > > > > are, actually, just technical choices.
>> > > > > > > > > > > > > > > > > > > Anyway, this latter point is for
>> longer,
>> > > > > > following,
>> > > > > > > > > > > > discussion.)
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore
>> 11:23
>> > > > > > Francisco
>> > > > > > > > Javier
>> > > > > > > > > > > > Tirado
>> > > > > > > > > > > > > > > > Sarti
>> > > > > > > > > > > > > > > > > <
>> > > > > > > > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > Alex,
>> > > > > > > > > > > > > > > > > > > > There are two assumptions that
>> deserve
>> > > > > further
>> > > > > > > > > > discussion:
>> > > > > > > > > > > > > > > > > > > > 1) That tool has to be the last to
>> build.
>> > > > > why?
>> > > > > > it
>> > > > > > > > does
>> > > > > > > > > > not
>> > > > > > > > > > > > have
>> > > > > > > > > > > > > > > > more
>> > > > > > > > > > > > > > > > > > > sense
>> > > > > > > > > > > > > > > > > > > > to build final images after
>> everything
>> > > else
>> > > > > has
>> > > > > > > > been
>> > > > > > > > > > > > built?-
>> > > > > > > > > > > > > > > > > > > > 2) That the impact (in terms of
>> effort
>> > > now)
>> > > > > on
>> > > > > > > > fixing
>> > > > > > > > > > CI is
>> > > > > > > > > > > > > > > bigger
>> > > > > > > > > > > > > > > > > than
>> > > > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > impact (long term consequences) of
>> > > > > > consolidating
>> > > > > > > > two
>> > > > > > > > > > > > unrelated
>> > > > > > > > > > > > > > > > piece
>> > > > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > > > software within the same repository.
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM
>> Alex
>> > > > > Porcelli
>> > > > > > <
>> > > > > > > > > > > > > > alex@porcelli.me
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > wrote:
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > Francisco,
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > This was discussed as an
>> alternative
>> > > > > > solution,
>> > > > > > > > > > however
>> > > > > > > > > > > > it has
>> > > > > > > > > > > > > > > > major
>> > > > > > > > > > > > > > > > > > > > impact
>> > > > > > > > > > > > > > > > > > > > > on CI and there’s also the fact
>> Tool
>> > > has
>> > > > > been
>> > > > > > > > always
>> > > > > > > > > > the
>> > > > > > > > > > > > last
>> > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > build
>> > > > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > has no Snapshot published
>> (actually in
>> > > > > > JavaScript
>> > > > > > > > > > world
>> > > > > > > > > > > > there
>> > > > > > > > > > > > > > > is
>> > > > > > > > > > > > > > > > no
>> > > > > > > > > > > > > > > > > > > > > snapshot concept).
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > So, based on our evaluation… the
>> > > proposal
>> > > > > > here
>> > > > > > > > is the
>> > > > > > > > > > > > least
>> > > > > > > > > > > > > > > > > > disruptive
>> > > > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > will take less time to unblock the
>> > > > release.
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > Regards,
>> > > > > > > > > > > > > > > > > > > > > _____________
>> > > > > > > > > > > > > > > > > > > > > Alex Porcelli
>> > > > > > > > > > > > > > > > > > > > > http://porcelli.me
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM
>> > > Francisco
>> > > > > > Javier
>> > > > > > > > > > Tirado
>> > > > > > > > > > > > > > Sarti <
>> > > > > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > > After kie-tools, sorry. I think
>> we
>> > > are
>> > > > > not
>> > > > > > > > > > embracing
>> > > > > > > > > > > > the
>> > > > > > > > > > > > > > fact
>> > > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > > > > > kogito-images depend on
>> kie-tools,
>> > > > > because
>> > > > > > we
>> > > > > > > > want
>> > > > > > > > > > > > those
>> > > > > > > > > > > > > > > images
>> > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > include
>> > > > > > > > > > > > > > > > > > > > > > tools.
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM
>> > > > > Francisco
>> > > > > > > > Javier
>> > > > > > > > > > > > Tirado
>> > > > > > > > > > > > > > > Sarti
>> > > > > > > > > > > > > > > > <
>> > > > > > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > > > Hi Tiago,
>> > > > > > > > > > > > > > > > > > > > > > > It can be an alternative
>> solution
>> > > to
>> > > > > move
>> > > > > > > > > > > > > > > kn-plugin-workflow
>> > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > > kogito-images (so there is not
>> > > longer
>> > > > > > > > dependency
>> > > > > > > > > > from
>> > > > > > > > > > > > > > tools
>> > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > images)
>> > > > > > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > > then build kogito-images after
>> > > > > > kogito-tools?
>> > > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at
>> 11:01 AM
>> > > > > Enrique
>> > > > > > > > Gonzalez
>> > > > > > > > > > > > > > Martinez
>> > > > > > > > > > > > > > > <
>> > > > > > > > > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
>> > > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > > >> +1 to unblock release
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48,
>> Pere
>> > > > > > Fernandez
>> > > > > > > > > > (apache)
>> > > > > > > > > > > > <
>> > > > > > > > > > > > > > > > > > > > > > pefernan@apache.org>
>> > > > > > > > > > > > > > > > > > > > > > >> escribió:
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > > >> > I say +1 in order to move
>> > > forward
>> > > > > with
>> > > > > > > > the 10.
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at
>> 21:45,
>> > > Alex
>> > > > > > > > Porcelli <
>> > > > > > > > > > > > > > > > > alex@porcelli.me
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > wrote:
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >> > > +1
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > I spent the last day or
>> so
>> > > > working
>> > > > > > > > closely
>> > > > > > > > > > with
>> > > > > > > > > > > > > > Tiago,
>> > > > > > > > > > > > > > > > > > > exploring
>> > > > > > > > > > > > > > > > > > > > > > >> > different
>> > > > > > > > > > > > > > > > > > > > > > >> > > options and getting
>> deeper on
>> > > > the
>> > > > > > > > impact and
>> > > > > > > > > > > > > > > evaluating
>> > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > overall
>> > > > > > > > > > > > > > > > > > > > > > >> > release
>> > > > > > > > > > > > > > > > > > > > > > >> > > procedure steps
>> required. I
>> > > > agree
>> > > > > > with
>> > > > > > > > the
>> > > > > > > > > > > > proposal
>> > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > most
>> > > > > > > > > > > > > > > > > > > > > > >> > > viable option for
>> unblocking
>> > > the
>> > > > > 10
>> > > > > > > > release
>> > > > > > > > > > in
>> > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > reasonable
>> > > > > > > > > > > > > > > > > > > > time
>> > > > > > > > > > > > > > > > > > > > > > >> frame.
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at
>> > > 3:45 PM
>> > > > > > Tiago
>> > > > > > > > Bento
>> > > > > > > > > > <
>> > > > > > > > > > > > > > > > > > > > > tiagobento@apache.org>
>> > > > > > > > > > > > > > > > > > > > > > >> > wrote:
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Hi everyone,
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Unfortunately, I can't
>> do a
>> > > > > tl;dr
>> > > > > > this
>> > > > > > > > > > time,
>> > > > > > > > > > > > as
>> > > > > > > > > > > > > > this
>> > > > > > > > > > > > > > > > > > matter
>> > > > > > > > > > > > > > > > > > > > > > >> requires a
>> > > > > > > > > > > > > > > > > > > > > > >> > > > lot of context.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > This email will take
>> you <
>> > > 20
>> > > > > > minutes
>> > > > > > > > to
>> > > > > > > > > > read,
>> > > > > > > > > > > > > > > > according
>> > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> https://thereadtime.com/.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > As you may have
>> followed on
>> > > a
>> > > > > > separate
>> > > > > > > > > > thread
>> > > > > > > > > > > > > > > > > > > > > > >> > > > (
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > >
>> https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
>> > > > > > > > > > > > > > > > > > > > > > ),
>> > > > > > > > > > > > > > > > > > > > > > >> > > > many of us were working
>> > > > towards
>> > > > > > > > removing a
>> > > > > > > > > > > > > > circular
>> > > > > > > > > > > > > > > > > > > dependency
>> > > > > > > > > > > > > > > > > > > > > > >> > > > currently present
>> between
>> > > > > > > > `kogito-apps`
>> > > > > > > > > > and
>> > > > > > > > > > > > > > > > `kie-tools`.
>> > > > > > > > > > > > > > > > > > As
>> > > > > > > > > > > > > > > > > > > we
>> > > > > > > > > > > > > > > > > > > > > > >> > > > progressed towards a
>> > > solution,
>> > > > > we
>> > > > > > kept
>> > > > > > > > > > > > finding the
>> > > > > > > > > > > > > > > > > > circular
>> > > > > > > > > > > > > > > > > > > > > > >> dependency
>> > > > > > > > > > > > > > > > > > > > > > >> > > > pop up somewhere else.
>> I'll
>> > > > do a
>> > > > > > > > > > breakdown of
>> > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > things
>> > > > > > > > > > > > > > > > > > we
>> > > > > > > > > > > > > > > > > > > > did,
>> > > > > > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > >> > > > the results we had.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Right now, even though
>> we
>> > > > > started
>> > > > > > the
>> > > > > > > > > > effort
>> > > > > > > > > > > > to
>> > > > > > > > > > > > > > move
>> > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > Quarkus
>> > > > > > > > > > > > > > > > > > > > > > Dev
>> > > > > > > > > > > > > > > > > > > > > > >> > > > UI modules to
>> `kie-tools`,
>> > > we
>> > > > > > haven't
>> > > > > > > > been
>> > > > > > > > > > > > able to
>> > > > > > > > > > > > > > > do
>> > > > > > > > > > > > > > > > it
>> > > > > > > > > > > > > > > > > > > yet,
>> > > > > > > > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > > > > > > >> we've
>> > > > > > > > > > > > > > > > > > > > > > >> > > > been busy upgrading KIE
>> > > Tools
>> > > > to
>> > > > > > Java
>> > > > > > > > 17,
>> > > > > > > > > > > > Maven
>> > > > > > > > > > > > > > > 3.9.6,
>> > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > Quarkus
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with
>> > > Kogito
>> > > > > > Runtimes
>> > > > > > > > > > > > > > > > > > > 999-20240218-SNAPSHOT.
>> > > > > > > > > > > > > > > > > > > > > This
>> > > > > > > > > > > > > > > > > > > > > > >> > > > effort was concluded
>> this
>> > > > > Monday,
>> > > > > > with
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > >
>> > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
>> > > > > > > > > > > > > > > > > .
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > The current scenario
>> we have
>> > > > is:
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 01.
>> > > > > > > > > > > > incubator-kie-kogito-runtimes
>> > > > > > > > > > > > > > > > > > > > > > >> > > > |==> 02.
>> > > > > > > > incubator-kie-kogito-apps
>> > > > > > > > > > > > > > > > > > > > > > >> > > > C | 03.
>> > > > > > > > > > > > incubator-kie-kogito-examples
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Y | 04.
>> > > > > > > > > > > > incubator-kie-kogito-images
>> > > > > > > > > > > > > > > > > > > > > > >> > > > C | 05.
>> > > > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
>> > > > > > > > > > > > > > > > > > > > > > >> > > > L |
>> > > > > > > > ==========================
>> > > > > > > > > > > > > > > > > > > > > > >> > > > E | 06.
>> > > > > > > > > > > > > > > > > > >
>> incubator-kie-sandbox-quarkus-accelerator
>> > > > > > > > > > > > > > > > > > > > > > >> > > > |==> 07.
>> > > > > > incubator-kie-tools
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > * As
>> > > > > > > > `kie-tools`/extended-services
>> > > > > > > > > > > > depends
>> > > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> `kogito-apps`/jitexecutor;
>> > > > > > > > > > > > > > > > > > > > > > >> > > > * and
>> > > > > > > > > > > > > > > > > >
>> `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
>> > > > > > > > > > > > > > > > > > > > > depend
>> > > > > > > > > > > > > > > > > > > > > > >> on
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`/{many
>> packages}
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > After moving the
>> Quarkus Dev
>> > > > UIs
>> > > > > > to
>> > > > > > > > > > > > `kie-tools`,
>> > > > > > > > > > > > > > we
>> > > > > > > > > > > > > > > > > > would've
>> > > > > > > > > > > > > > > > > > > > > had:
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 01.
>> > > > > > > > > > > > incubator-kie-kogito-runtimes
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 02.
>> > > > > > > > > > incubator-kie-kogito-apps
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 03.
>> > > > > > > > > > > > incubator-kie-kogito-examples
>> > > > > > > > > > > > > > > > > > > > > > >> > > > C |==> 04.
>> > > > > > > > > > incubator-kie-kogito-images
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Y | 05.
>> > > > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
>> > > > > > > > > > > > > > > > > > > > > > >> > > > C |
>> > > > > > =====================
>> > > > > > > > > > > > > > > > > > > > > > >> > > > L | 06.
>> > > > > > > > > > > > > > > > > > >
>> incubator-kie-sandbox-quarkus-accelerator
>> > > > > > > > > > > > > > > > > > > > > > >> > > > E |==> 07.
>> > > > > > incubator-kie-tools
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > * As
>> > > > > > > > > > `kie-tools`/kn-plugin-workflow
>> > > > > > > > > > > > > > depends
>> > > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > `kogito-images`/kogito-swf-devmode;
>> > > > > > > > > > > > > > > > > > > > > > >> > > > * and
>> > > > > > > > > > > > `kogito-images`/kogito-swf-devmode
>> > > > > > > > > > > > > > > > depends
>> > > > > > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > `kie-tools`/sonataflow-quarkus-devui
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > After moving the
>> > > > > > `kogito-swf-devmode`
>> > > > > > > > > > image to
>> > > > > > > > > > > > > > > > > > `kie-tools`,
>> > > > > > > > > > > > > > > > > > > we
>> > > > > > > > > > > > > > > > > > > > > > >> would've
>> > > > > > > > > > > > > > > > > > > > > > >> > > > had:
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 01.
>> > > > > > > > > > > > incubator-kie-kogito-runtimes
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 02.
>> > > > > > > > > > incubator-kie-kogito-apps
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 03.
>> > > > > > > > > > > > incubator-kie-kogito-examples
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 04.
>> > > > > > > > > > > > incubator-kie-kogito-images
>> > > > > > > > > > > > > > > > > > > > > > >> > > > C |==> 05.
>> > > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Y |
>> > > > > > =====================
>> > > > > > > > > > > > > > > > > > > > > > >> > > > C | 06.
>> > > > > > > > > > > > > > > > > > >
>> incubator-kie-sandbox-quarkus-accelerator
>> > > > > > > > > > > > > > > > > > > > > > >> > > > L |==> 07.
>> > > > > > incubator-kie-tools
>> > > > > > > > > > > > > > > > > > > > > > >> > > > E
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > * As
>> > > > > > > > > > `kie-tools`/kn-plugin-workflow
>> > > > > > > > > > > > > > depends
>> > > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > `kogito-serverless-operator`;
>> > > > > > > > > > > > > > > > > > > > > > >> > > > * and
>> > > > > > > > `kogito-serverless-operator`
>> > > > > > > > > > > > depends
>> > > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > `kie-tools`/kogito-swf-devmode
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Clearly, we have a much
>> > > bigger
>> > > > > > problem
>> > > > > > > > > > than a
>> > > > > > > > > > > > > > simple
>> > > > > > > > > > > > > > > > > > > circular
>> > > > > > > > > > > > > > > > > > > > > > >> > dependency.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > After multiple
>> conversations
>> > > > > with
>> > > > > > a
>> > > > > > > > lot of
>> > > > > > > > > > > > people,
>> > > > > > > > > > > > > > > > it's
>> > > > > > > > > > > > > > > > > > been
>> > > > > > > > > > > > > > > > > > > > > > really
>> > > > > > > > > > > > > > > > > > > > > > >> > > > hard coming up with a
>> simple
>> > > > > > solution
>> > > > > > > > that
>> > > > > > > > > > > > makes
>> > > > > > > > > > > > > > it
>> > > > > > > > > > > > > > > > > > possible
>> > > > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > >> build
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Apache KIE in one shot,
>> > > while
>> > > > > > > > preserving
>> > > > > > > > > > the
>> > > > > > > > > > > > way
>> > > > > > > > > > > > > > > > > everyone
>> > > > > > > > > > > > > > > > > > is
>> > > > > > > > > > > > > > > > > > > > > used
>> > > > > > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > >> > > > contributing to the
>> multiple
>> > > > > > > > repositories
>> > > > > > > > > > we
>> > > > > > > > > > > > have.
>> > > > > > > > > > > > > > > > More
>> > > > > > > > > > > > > > > > > > than
>> > > > > > > > > > > > > > > > > > > > > that,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > while making this
>> > > assessment,
>> > > > I
>> > > > > > found
>> > > > > > > > more
>> > > > > > > > > > > > > > problems
>> > > > > > > > > > > > > > > > > that,
>> > > > > > > > > > > > > > > > > > in
>> > > > > > > > > > > > > > > > > > > > my
>> > > > > > > > > > > > > > > > > > > > > > >> > > > perspective, block
>> Apache
>> > > KIE
>> > > > > 10.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > In light of that
>> difficulty,
>> > > > I'm
>> > > > > > > > coming
>> > > > > > > > > > > > forward
>> > > > > > > > > > > > > > with
>> > > > > > > > > > > > > > > > my
>> > > > > > > > > > > > > > > > > > > > proposal
>> > > > > > > > > > > > > > > > > > > > > > for
>> > > > > > > > > > > > > > > > > > > > > > >> > > > the Apache KIE release
>> > > > process,
>> > > > > > so we
>> > > > > > > > can
>> > > > > > > > > > use
>> > > > > > > > > > > > > > > Apache's
>> > > > > > > > > > > > > > > > > > > > > mechanisms
>> > > > > > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > >> > > > have a slower-paced,
>> > > in-depth
>> > > > > > debate
>> > > > > > > > about
>> > > > > > > > > > > > this
>> > > > > > > > > > > > > > > really
>> > > > > > > > > > > > > > > > > > > > > complicated
>> > > > > > > > > > > > > > > > > > > > > > >> > > > matter.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > I'll lay out my entire
>> > > > > perspective
>> > > > > > > > about
>> > > > > > > > > > the
>> > > > > > > > > > > > > > current
>> > > > > > > > > > > > > > > > > > > situation
>> > > > > > > > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > > > > > >> our
>> > > > > > > > > > > > > > > > > > > > > > >> > > > codebase, as well as
>> > > problems
>> > > > I
>> > > > > > can
>> > > > > > > > > > currently
>> > > > > > > > > > > > see.
>> > > > > > > > > > > > > > > > I'll
>> > > > > > > > > > > > > > > > > > > start
>> > > > > > > > > > > > > > > > > > > > > with
>> > > > > > > > > > > > > > > > > > > > > > >> an
>> > > > > > > > > > > > > > > > > > > > > > >> > > > analysis of the
>> repositories
>> > > > and
>> > > > > > their
>> > > > > > > > > > > > purposes,
>> > > > > > > > > > > > > > > point
>> > > > > > > > > > > > > > > > > out
>> > > > > > > > > > > > > > > > > > > > some
>> > > > > > > > > > > > > > > > > > > > > > >> > > > problems that I
>> believe are
>> > > > > > blocking
>> > > > > > > > our
>> > > > > > > > > > 10
>> > > > > > > > > > > > > > release,
>> > > > > > > > > > > > > > > > > > explain
>> > > > > > > > > > > > > > > > > > > > my
>> > > > > > > > > > > > > > > > > > > > > > >> > > > proposal and discuss
>> some
>> > > > > > > > consequences to
>> > > > > > > > > > > > what I'm
>> > > > > > > > > > > > > > > > > > > proposing.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Let's begin.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER,
>> &
>> > > > KOGITO
>> > > > > > > > (count:
>> > > > > > > > > > 11)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > incubator-kie-kogito-pipelines @
>> > > > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-drools
>> @
>> > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> incubator-kie-optaplanner
>> > > @
>> > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > > > > incubator-kie-optaplanner-quickstarts @
>> > > > > > > > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > incubator-kie-kogito-runtimes
>> > > > > @
>> > > > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> incubator-kie-kogito-apps
>> > > @
>> > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > incubator-kie-kogito-examples
>> > > > > @
>> > > > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > incubator-kie-kogito-images
>> > > > @
>> > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > > > > > > incubator-kie-kogito-serverless-operator @
>> > > > > > > > > > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> incubator-kie-kogito-docs
>> > > @
>> > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @
>> > > > > > `main-kogito`
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator @
>> > > > > > > > > > > > > > > `0.0.0`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @
>> > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count:
>> 2)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > incubator-kie-kogito-benchmarks
>> > > > > > @
>> > > > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> incubator-kie-benchmarks @
>> > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > incubator-kie-kogito-operator
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count:
>> 5)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-issues
>> @
>> > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > (Issues only,
>> README
>> > > > should
>> > > > > be
>> > > > > > > > > > updated @
>> > > > > > > > > > > > > > `main`.
>> > > > > > > > > > > > > > > > > Same
>> > > > > > > > > > > > > > > > > > > for
>> > > > > > > > > > > > > > > > > > > > > > GitHub
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Actions workflows.)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > incubator-kie-kogito-website @
>> > > > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > (The Kogito
>> website.
>> > > > > Develop &
>> > > > > > > > deploy
>> > > > > > > > > > at
>> > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > branch.)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> incubator-kie-website @
>> > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > (The KIE website.
>> > > Develop
>> > > > @
>> > > > > > > > `main`.
>> > > > > > > > > > Push @
>> > > > > > > > > > > > > > > > `deploy`
>> > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > update
>> > > > > > > > > > > > > > > > > > > > > > >> the
>> > > > > > > > > > > > > > > > > > > > > > >> > > > website.)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > incubator-kie-kogito-online
>> > > > @
>> > > > > > > > `gh-pages`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > (GitHub pages used
>> to
>> > > host
>> > > > > > > > > > > > sandbox.kie.org
>> > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > KIE
>> > > > > > > > > > > > > > > > > > > Tools'
>> > > > > > > > > > > > > > > > > > > > > > >> Chrome
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Extension assets.)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > > incubator-kie-kogito-online-staging
>> > > > > > > > @
>> > > > > > > > > > `main`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > (Same as above,
>> but for
>> > > > > manual
>> > > > > > > > sanity
>> > > > > > > > > > > > checks
>> > > > > > > > > > > > > > > > during
>> > > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > > staging
>> > > > > > > > > > > > > > > > > > > > > > >> > > > phase of a release.)
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > I grouped the
>> repositories
>> > > by
>> > > > > > > > category,
>> > > > > > > > > > and
>> > > > > > > > > > > > listed
>> > > > > > > > > > > > > > > > them
>> > > > > > > > > > > > > > > > > > in a
>> > > > > > > > > > > > > > > > > > > > > > >> > > > topological order.
>> Keep in
>> > > > mind
>> > > > > > that
>> > > > > > > > when
>> > > > > > > > > > > > > > flattening
>> > > > > > > > > > > > > > > > > out a
>> > > > > > > > > > > > > > > > > > > > tree,
>> > > > > > > > > > > > > > > > > > > > > > >> there
>> > > > > > > > > > > > > > > > > > > > > > >> > > > are multiple
>> possibilities.
>> > > > For
>> > > > > > > > example,
>> > > > > > > > > > > > > > OptaPlanner
>> > > > > > > > > > > > > > > > > > > could've
>> > > > > > > > > > > > > > > > > > > > > been
>> > > > > > > > > > > > > > > > > > > > > > >> > > > placed in any position
>> after
>> > > > > > Drools.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Category A repos are
>> what
>> > > I've
>> > > > > > been
>> > > > > > > > > > referring
>> > > > > > > > > > > > to
>> > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > > `drools`
>> > > > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of
>> course
>> > > > > > > > OptaPlanner
>> > > > > > > > > > is
>> > > > > > > > > > > > inside
>> > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > > > stream,
>> > > > > > > > > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > > > > > > >> the
>> > > > > > > > > > > > > > > > > > > > > > >> > > > way these repositories
>> > > > reference
>> > > > > > each
>> > > > > > > > > > other
>> > > > > > > > > > > > are
>> > > > > > > > > > > > > > > > through
>> > > > > > > > > > > > > > > > > > > Maven
>> > > > > > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More
>> > > specifically,
>> > > > > the
>> > > > > > > > > > 999-SNAPSHOT
>> > > > > > > > > > > > > > > > version.
>> > > > > > > > > > > > > > > > > > This
>> > > > > > > > > > > > > > > > > > > > > > >> mechanism
>> > > > > > > > > > > > > > > > > > > > > > >> > > > is well-known to the
>> team,
>> > > and
>> > > > > > > > although
>> > > > > > > > > > > > flawed for
>> > > > > > > > > > > > > > > > > > intra-day
>> > > > > > > > > > > > > > > > > > > > > > builds
>> > > > > > > > > > > > > > > > > > > > > > >> > > > and disruptive for
>> people in
>> > > > > many
>> > > > > > > > > > different
>> > > > > > > > > > > > time
>> > > > > > > > > > > > > > > > zones,
>> > > > > > > > > > > > > > > > > it
>> > > > > > > > > > > > > > > > > > > is
>> > > > > > > > > > > > > > > > > > > > > > >> already
>> > > > > > > > > > > > > > > > > > > > > > >> > > > very comfortable for
>> > > everyone
>> > > > to
>> > > > > > work
>> > > > > > > > > > with, I
>> > > > > > > > > > > > > > > assume.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Contributions made to
>> > > > Category A
>> > > > > > have
>> > > > > > > > some
>> > > > > > > > > > > > > > dedicated
>> > > > > > > > > > > > > > > > > > > > pipelines,
>> > > > > > > > > > > > > > > > > > > > > > >> which
>> > > > > > > > > > > > > > > > > > > > > > >> > > > are, at least to some
>> > > extent,
>> > > > > > able to
>> > > > > > > > > > build
>> > > > > > > > > > > > > > > cross-repo
>> > > > > > > > > > > > > > > > > PRs
>> > > > > > > > > > > > > > > > > > > > > > together
>> > > > > > > > > > > > > > > > > > > > > > >> > > > and verify that the
>> codebase
>> > > > > will
>> > > > > > > > continue
>> > > > > > > > > > > > working
>> > > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > > > expected
>> > > > > > > > > > > > > > > > > > > > > > after
>> > > > > > > > > > > > > > > > > > > > > > >> > > > they're all merged.
>> From
>> > > what
>> > > > I
>> > > > > > could
>> > > > > > > > > > gather,
>> > > > > > > > > > > > > > there
>> > > > > > > > > > > > > > > > are
>> > > > > > > > > > > > > > > > > > some
>> > > > > > > > > > > > > > > > > > > > > > >> > > > "sub-streams" currently
>> > > > > > configured for
>> > > > > > > > > > > > cross-repo
>> > > > > > > > > > > > > > > PRs.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > - kogito-pipelines
>> > > > > > > > > > > > > > > > > > > > > > >> > > > - drools,
>> kogito-runtimes,
>> > > > > > > > kogito-apps,
>> > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > kogito-examples
>> > > > > > > > > > > > > > > > > > > > > > >> > > > - optaplanner, and
>> > > > > > > > optaplanner-quickstarts
>> > > > > > > > > > > > > > > > > > > > > > >> > > > - kogito-images, and
>> > > > > > > > > > > > kogito-serverless-operator
>> > > > > > > > > > > > > > > > > > > > > > >> > > > - kogito-docs
>> > > > > > > > > > > > > > > > > > > > > > >> > > > - kie-docs
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > This means that sending
>> > > > > cross-repo
>> > > > > > > > PRs to
>> > > > > > > > > > any
>> > > > > > > > > > > > > > > > > combination
>> > > > > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > > > > repos
>> > > > > > > > > > > > > > > > > > > > > > >> > > > that are not part of
>> the
>> > > same
>> > > > > > > > "sub-stream"
>> > > > > > > > > > > > cannot
>> > > > > > > > > > > > > > be
>> > > > > > > > > > > > > > > > > > > verified
>> > > > > > > > > > > > > > > > > > > > > > before
>> > > > > > > > > > > > > > > > > > > > > > >> > > > merging, making our
>> > > > contribution
>> > > > > > model
>> > > > > > > > > > > > dependent
>> > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > > > individual
>> > > > > > > > > > > > > > > > > > > > > > >> > > > contributors building
>> stuff
>> > > on
>> > > > > > their
>> > > > > > > > > > machines
>> > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > verify
>> > > > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > > > it
>> > > > > > > > > > > > > > > > > > > > > > >> works.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > I based this analysis
>> on
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
>> > > > > > > > > > > > > > > > > > > > > > >> > > > ,
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
>> > > > > > > > > > > > > > > > > > > > > > >> > > > ,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > and
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
>> > > > > > > > > > > > > > > > > > > > > > >> > > > .
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Note that I'm not that
>> > > > familiar
>> > > > > > with
>> > > > > > > > these
>> > > > > > > > > > > > > > > pipelines,
>> > > > > > > > > > > > > > > > so
>> > > > > > > > > > > > > > > > > > > > please
>> > > > > > > > > > > > > > > > > > > > > > >> > > > someone correct me if
>> I'm
>> > > > wrong.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Category B repos are
>> what
>> > > I've
>> > > > > > been
>> > > > > > > > > > referring
>> > > > > > > > > > > > to
>> > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > > > > `kie-tools`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > stream. The first repo
>> there
>> > > > is
>> > > > > a
>> > > > > > > > template
>> > > > > > > > > > > > > > > repository
>> > > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > > is
>> > > > > > > > > > > > > > > > > > > > > used
>> > > > > > > > > > > > > > > > > > > > > > >> by
>> > > > > > > > > > > > > > > > > > > > > > >> > > > people starting
>> projects
>> > > from
>> > > > > > scratch
>> > > > > > > > on
>> > > > > > > > > > KIE
>> > > > > > > > > > > > > > > Sandbox,
>> > > > > > > > > > > > > > > > > > > similar
>> > > > > > > > > > > > > > > > > > > > > to a
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Maven archetype, if you
>> > > will.
>> > > > > The
>> > > > > > > > other
>> > > > > > > > > > one
>> > > > > > > > > > > > is the
>> > > > > > > > > > > > > > > KIE
>> > > > > > > > > > > > > > > > > > Tools
>> > > > > > > > > > > > > > > > > > > > > > >> monorepo,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > a polyglot monorepo
>> with
>> > > > `pnpm`
>> > > > > > as its
>> > > > > > > > > > build
>> > > > > > > > > > > > > > system.
>> > > > > > > > > > > > > > > > > > > > Currently,
>> > > > > > > > > > > > > > > > > > > > > > KIE
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Tools hosts Java
>> libraries
>> > > and
>> > > > > > apps,
>> > > > > > > > > > > > TypeScript
>> > > > > > > > > > > > > > > > > libraries
>> > > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > apps,
>> > > > > > > > > > > > > > > > > > > > > > >> Go
>> > > > > > > > > > > > > > > > > > > > > > >> > > > apps, Docker images,
>> and
>> > > Helm
>> > > > > > charts.
>> > > > > > > > The
>> > > > > > > > > > > > > > > `kie-tools`
>> > > > > > > > > > > > > > > > > > > monorepo
>> > > > > > > > > > > > > > > > > > > > > is
>> > > > > > > > > > > > > > > > > > > > > > >> > > > configured to work with
>> > > sparse
>> > > > > > > > checkouts
>> > > > > > > > > > and
>> > > > > > > > > > > > can
>> > > > > > > > > > > > > > do
>> > > > > > > > > > > > > > > > > > partial
>> > > > > > > > > > > > > > > > > > > > > > builds.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Category B repos refer
>> to
>> > > > > > Category A
>> > > > > > > > repos
>> > > > > > > > > > > > through
>> > > > > > > > > > > > > > > > > > > timestamped
>> > > > > > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a
>> new
>> > > > > > mechanism we
>> > > > > > > > > > recently
>> > > > > > > > > > > > > > > > > introduced
>> > > > > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > > > > > will
>> > > > > > > > > > > > > > > > > > > > > > >> > > > build and publish
>> immutable,
>> > > > > > > > persistent
>> > > > > > > > > > > > artifacts
>> > > > > > > > > > > > > > > > under
>> > > > > > > > > > > > > > > > > a
>> > > > > > > > > > > > > > > > > > > > > version
>> > > > > > > > > > > > > > > > > > > > > > >> > > > following the
>> > > > > > 999-YYYYMMDD-SNAPSHOT
>> > > > > > > > > > format,
>> > > > > > > > > > > > > > > published
>> > > > > > > > > > > > > > > > > > weekly
>> > > > > > > > > > > > > > > > > > > > > every
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Sunday night.
>> Timestamped
>> > > > > > SNAPSHOTs
>> > > > > > > > are an
>> > > > > > > > > > > > > > evolution
>> > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > Kogito
>> > > > > > > > > > > > > > > > > > > > > > >> > > > releases, as we're now
>> > > > targeting
>> > > > > > one
>> > > > > > > > > > release
>> > > > > > > > > > > > for
>> > > > > > > > > > > > > > all
>> > > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > > Apache
>> > > > > > > > > > > > > > > > > > > > > > KIE,
>> > > > > > > > > > > > > > > > > > > > > > >> so
>> > > > > > > > > > > > > > > > > > > > > > >> > > > we can't have Kogito
>> > > releases
>> > > > > > anymore.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > An important note here
>> is
>> > > that
>> > > > > > > > Category B
>> > > > > > > > > > > > > > > repositories
>> > > > > > > > > > > > > > > > > > have
>> > > > > > > > > > > > > > > > > > > > been
>> > > > > > > > > > > > > > > > > > > > > > >> > > > historically kept out
>> of any
>> > > > > > > > automations
>> > > > > > > > > > we
>> > > > > > > > > > > > used
>> > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > have,
>> > > > > > > > > > > > > > > > > > > way
>> > > > > > > > > > > > > > > > > > > > > back
>> > > > > > > > > > > > > > > > > > > > > > >> > > > when Kogito started
>> and we
>> > > had
>> > > > > the
>> > > > > > > > > > Business
>> > > > > > > > > > > > > > Central
>> > > > > > > > > > > > > > > > > > (a.k.a.
>> > > > > > > > > > > > > > > > > > > > v7)
>> > > > > > > > > > > > > > > > > > > > > > >> stream
>> > > > > > > > > > > > > > > > > > > > > > >> > > > still going on. For
>> this
>> > > > reason,
>> > > > > > > > Category
>> > > > > > > > > > B
>> > > > > > > > > > > > > > projects
>> > > > > > > > > > > > > > > > > have
>> > > > > > > > > > > > > > > > > > > > > > developed
>> > > > > > > > > > > > > > > > > > > > > > >> > > > their own automations,
>> based
>> > > > on
>> > > > > > GitHub
>> > > > > > > > > > > > Actions.
>> > > > > > > > > > > > > > > > > Category B
>> > > > > > > > > > > > > > > > > > > > repos
>> > > > > > > > > > > > > > > > > > > > > > >> have
>> > > > > > > > > > > > > > > > > > > > > > >> > > > always depended on
>> Category
>> > > A
>> > > > > > repos
>> > > > > > > > using
>> > > > > > > > > > > > fixed
>> > > > > > > > > > > > > > > > > versions.
>> > > > > > > > > > > > > > > > > > If
>> > > > > > > > > > > > > > > > > > > > > > >> Category
>> > > > > > > > > > > > > > > > > > > > > > >> > > > B repos have had
>> adopted
>> > > > mutable
>> > > > > > > > > > SNAPSHOTs,
>> > > > > > > > > > > > > > breaking
>> > > > > > > > > > > > > > > > > > changes
>> > > > > > > > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Category A repositories
>> > > > would've
>> > > > > > had
>> > > > > > > > the
>> > > > > > > > > > > > potential
>> > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > break
>> > > > > > > > > > > > > > > > > > > > > > >> Category B
>> > > > > > > > > > > > > > > > > > > > > > >> > > > silently, leaving
>> Category B
>> > > > > with
>> > > > > > a
>> > > > > > > > broken
>> > > > > > > > > > > > > > > development
>> > > > > > > > > > > > > > > > > > > stream,
>> > > > > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > >> > > > introducing unpleasant
>> > > > surprises
>> > > > > > for
>> > > > > > > > > > > > maintainers
>> > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > > Category B
>> > > > > > > > > > > > > > > > > > > > > > >> repos,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > as historically
>> Category A
>> > > > > > > > contributors
>> > > > > > > > > > were
>> > > > > > > > > > > > not
>> > > > > > > > > > > > > > > > > familiar
>> > > > > > > > > > > > > > > > > > > with
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Category B repos.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Contributions made to
>> > > > Category B
>> > > > > > > > repos go
>> > > > > > > > > > > > through
>> > > > > > > > > > > > > > a
>> > > > > > > > > > > > > > > > > GitHub
>> > > > > > > > > > > > > > > > > > > > > Actions
>> > > > > > > > > > > > > > > > > > > > > > >> > > > workflow that builds
>> the
>> > > > > relevant
>> > > > > > > > part of
>> > > > > > > > > > the
>> > > > > > > > > > > > > > > > > `kie-tools`
>> > > > > > > > > > > > > > > > > > > > > monorepo
>> > > > > > > > > > > > > > > > > > > > > > >> for
>> > > > > > > > > > > > > > > > > > > > > > >> > > > the changes introduced.
>> > > > Changes
>> > > > > > made
>> > > > > > > > to
>> > > > > > > > > > the
>> > > > > > > > > > > > > > pipeline
>> > > > > > > > > > > > > > > > > > itself
>> > > > > > > > > > > > > > > > > > > > are
>> > > > > > > > > > > > > > > > > > > > > > also
>> > > > > > > > > > > > > > > > > > > > > > >> > > > picked up as part of
>> PRs,
>> > > > > > allowing us
>> > > > > > > > to
>> > > > > > > > > > do
>> > > > > > > > > > > > things
>> > > > > > > > > > > > > > > > like
>> > > > > > > > > > > > > > > > > > > > > atomically
>> > > > > > > > > > > > > > > > > > > > > > >> > > > bumping the Node.js
>> version,
>> > > > for
>> > > > > > > > example.
>> > > > > > > > > > More
>> > > > > > > > > > > > > > > > > > importantly,
>> > > > > > > > > > > > > > > > > > > it
>> > > > > > > > > > > > > > > > > > > > > > >> allows
>> > > > > > > > > > > > > > > > > > > > > > >> > > > us to upgrade the
>> repository
>> > > > to
>> > > > > a
>> > > > > > new
>> > > > > > > > > > > > timestamped
>> > > > > > > > > > > > > > > > > SNAPSHOT
>> > > > > > > > > > > > > > > > > > > > > > together
>> > > > > > > > > > > > > > > > > > > > > > >> > > > with the changes
>> necessary
>> > > to
>> > > > > > make it
>> > > > > > > > stay
>> > > > > > > > > > > > green.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > This setup, however,
>> makes
>> > > it
>> > > > > > > > impossible
>> > > > > > > > > > to
>> > > > > > > > > > > > have
>> > > > > > > > > > > > > > > > > > cross-repo
>> > > > > > > > > > > > > > > > > > > > PRs
>> > > > > > > > > > > > > > > > > > > > > > >> > > > involving Category A
>> and
>> > > > > Category
>> > > > > > B
>> > > > > > > > > > > > > > simultaneously,
>> > > > > > > > > > > > > > > > with
>> > > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > > current
>> > > > > > > > > > > > > > > > > > > > > > >> > > > automations we have.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Category C repos are
>> kind of
>> > > > > > floating
>> > > > > > > > > > around,
>> > > > > > > > > > > > and
>> > > > > > > > > > > > > > > I'm
>> > > > > > > > > > > > > > > > > not
>> > > > > > > > > > > > > > > > > > > sure
>> > > > > > > > > > > > > > > > > > > > > if
>> > > > > > > > > > > > > > > > > > > > > > >> > > > there's much activity
>> going
>> > > on
>> > > > > > there.
>> > > > > > > > > > > > Regardless,
>> > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > > they're
>> > > > > > > > > > > > > > > > > > > > > part
>> > > > > > > > > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Apache KIE, they will
>> be
>> > > part
>> > > > of
>> > > > > > our
>> > > > > > > > > > release,
>> > > > > > > > > > > > so I
>> > > > > > > > > > > > > > > > > listed
>> > > > > > > > > > > > > > > > > > > them
>> > > > > > > > > > > > > > > > > > > > > for
>> > > > > > > > > > > > > > > > > > > > > > >> us
>> > > > > > > > > > > > > > > > > > > > > > >> > > > to take them into
>> > > > consideration
>> > > > > > too.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Category D is self
>> > > > explanatory.
>> > > > > > > > There's
>> > > > > > > > > > only
>> > > > > > > > > > > > one
>> > > > > > > > > > > > > > > repo
>> > > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > > has
>> > > > > > > > > > > > > > > > > > > > > > >> already
>> > > > > > > > > > > > > > > > > > > > > > >> > > > been marked for being
>> > > > archived.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Category E are repos
>> that do
>> > > > not
>> > > > > > host
>> > > > > > > > code
>> > > > > > > > > > > > > > directly,
>> > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > are
>> > > > > > > > > > > > > > > > > > > > > > either
>> > > > > > > > > > > > > > > > > > > > > > >> > > > organizational
>> entities, or
>> > > > host
>> > > > > > > > websites,
>> > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > currently
>> > > > > > > > > > > > > > > > > > > are
>> > > > > > > > > > > > > > > > > > > > > not
>> > > > > > > > > > > > > > > > > > > > > > >> part
>> > > > > > > > > > > > > > > > > > > > > > >> > > > of any pipelines we
>> have.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > This lack of
>> unification
>> > > > between
>> > > > > > > > Category
>> > > > > > > > > > A
>> > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > Category B
>> > > > > > > > > > > > > > > > > > > is,
>> > > > > > > > > > > > > > > > > > > > > > IMHO,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > what allowed us to
>> introduce
>> > > > the
>> > > > > > > > infamous
>> > > > > > > > > > > > circular
>> > > > > > > > > > > > > > > > > > > dependency
>> > > > > > > > > > > > > > > > > > > > > > >> between
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools` and
>> > > `kogito-apps`,
>> > > > > > which
>> > > > > > > > we
>> > > > > > > > > > now
>> > > > > > > > > > > > can
>> > > > > > > > > > > > > > > > describe
>> > > > > > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > > > a
>> > > > > > > > > > > > > > > > > > > > > > >> circular
>> > > > > > > > > > > > > > > > > > > > > > >> > > > dependency between
>> Category
>> > > A
>> > > > > and
>> > > > > > > > > > Category B.
>> > > > > > > > > > > > The
>> > > > > > > > > > > > > > > way
>> > > > > > > > > > > > > > > > I
>> > > > > > > > > > > > > > > > > > see
>> > > > > > > > > > > > > > > > > > > > it,
>> > > > > > > > > > > > > > > > > > > > > if
>> > > > > > > > > > > > > > > > > > > > > > >> we
>> > > > > > > > > > > > > > > > > > > > > > >> > > > had a single pipeline,
>> > > > building
>> > > > > > > > everything
>> > > > > > > > > > > > from
>> > > > > > > > > > > > > > > > `drools`
>> > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws
>> > > > would've
>> > > > > > never
>> > > > > > > > > > been
>> > > > > > > > > > > > > > > > introduced,
>> > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > we
>> > > > > > > > > > > > > > > > > > > > > > >> > > > wouldn't be having
>> this huge
>> > > > > > problem
>> > > > > > > > in
>> > > > > > > > > > our
>> > > > > > > > > > > > hands
>> > > > > > > > > > > > > > > > right
>> > > > > > > > > > > > > > > > > > now.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > My proposal for the
>> Apache
>> > > KIE
>> > > > > > release
>> > > > > > > > > > process
>> > > > > > > > > > > > > > sees
>> > > > > > > > > > > > > > > > this
>> > > > > > > > > > > > > > > > > > > lack
>> > > > > > > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > > > > > >> > > > unification as a
>> central
>> > > > > problem,
>> > > > > > not
>> > > > > > > > > > only for
>> > > > > > > > > > > > > > this
>> > > > > > > > > > > > > > > > > > release
>> > > > > > > > > > > > > > > > > > > in
>> > > > > > > > > > > > > > > > > > > > > > >> > > > particular, but for the
>> > > > > community
>> > > > > > as a
>> > > > > > > > > > whole.
>> > > > > > > > > > > > It
>> > > > > > > > > > > > > > is
>> > > > > > > > > > > > > > > my
>> > > > > > > > > > > > > > > > > > > belief
>> > > > > > > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > > > > > >> we
>> > > > > > > > > > > > > > > > > > > > > > >> > > > are all under the same
>> roof,
>> > > > and
>> > > > > > that
>> > > > > > > > no
>> > > > > > > > > > > > > > > contribution
>> > > > > > > > > > > > > > > > > > should
>> > > > > > > > > > > > > > > > > > > > be
>> > > > > > > > > > > > > > > > > > > > > > >> > > > allowed to break any
>> part of
>> > > > our
>> > > > > > > > codebase.
>> > > > > > > > > > > > With
>> > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > increasing
>> > > > > > > > > > > > > > > > > > > > > > >> volume
>> > > > > > > > > > > > > > > > > > > > > > >> > > > of code, and hopefully
>> > > number
>> > > > of
>> > > > > > > > > > contributors
>> > > > > > > > > > > > too,
>> > > > > > > > > > > > > > > we
>> > > > > > > > > > > > > > > > > > cannot
>> > > > > > > > > > > > > > > > > > > > > keep
>> > > > > > > > > > > > > > > > > > > > > > >> > > > counting on "common
>> sense"
>> > > to
>> > > > > > avoid
>> > > > > > > > > > breaking
>> > > > > > > > > > > > > > things.
>> > > > > > > > > > > > > > > > > We're
>> > > > > > > > > > > > > > > > > > > all
>> > > > > > > > > > > > > > > > > > > > > > >> humans
>> > > > > > > > > > > > > > > > > > > > > > >> > > > after all, and it is
>> our job
>> > > > to
>> > > > > > have
>> > > > > > > > > > > > mechanisms in
>> > > > > > > > > > > > > > > > place
>> > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > prevent
>> > > > > > > > > > > > > > > > > > > > > > >> us
>> > > > > > > > > > > > > > > > > > > > > > >> > > > from unwillingly making
>> > > > > mistakes.
>> > > > > > > > > > Especially
>> > > > > > > > > > > > when
>> > > > > > > > > > > > > > > > these
>> > > > > > > > > > > > > > > > > > > > mistakes
>> > > > > > > > > > > > > > > > > > > > > > >> > > > impact on parts of the
>> > > > codebase
>> > > > > > that
>> > > > > > > > we,
>> > > > > > > > > > > > > > > individually,
>> > > > > > > > > > > > > > > > > > > > probably
>> > > > > > > > > > > > > > > > > > > > > > >> can't
>> > > > > > > > > > > > > > > > > > > > > > >> > > > fix.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE
>> RIGHT
>> > > > NOW
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @
>> > > > > > `kogito-apps`
>> > > > > > > > > > depending
>> > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > > kiegroup's
>> > > > > > > > > > > > > > > > > > > > KIE
>> > > > > > > > > > > > > > > > > > > > > > >> Tools
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `0.32.0`.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > See:
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito
>> SWF
>> > > > > images
>> > > > > > @
>> > > > > > > > > > > > > > `kogito-images`
>> > > > > > > > > > > > > > > > > > > depending
>> > > > > > > > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools
>> > > `0.32.0`.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > See:
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > P3. DashBuilder @
>> > > `kie-tools`
>> > > > > > > > depending on
>> > > > > > > > > > > > > > > kiegroup's
>> > > > > > > > > > > > > > > > > > > `lienzo`
>> > > > > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at
>> > > > version
>> > > > > > > > > > > > `7.59.0.Final`.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > See:
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > P4. Multiple packages @
>> > > > > > `kogito-apps`
>> > > > > > > > > > > > depending on
>> > > > > > > > > > > > > > > > > > > kiegroup's
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Explainability
>> > > `1.22.1.Final`.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > * This module was
>> removed
>> > > from
>> > > > > > the KIE
>> > > > > > > > > > > > codebase
>> > > > > > > > > > > > > > > here:
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
>> > > > > > > > > > > > > > > > > > > > > > >> > > > and now lives on
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > >
>> https://github.com/trustyai-explainability/trustyai-explainability
>> > > > > > > > > > > > > > > > > > ,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > under a different GAV.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > * This new repo
>> depends on
>> > > > > Kogito
>> > > > > > and
>> > > > > > > > > > > > OptaPlanner,
>> > > > > > > > > > > > > > > > > > pointing
>> > > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > older
>> > > > > > > > > > > > > > > > > > > > > > >> > > > versions.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > See:
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > P5.
>> > > > > > > > > > > > `incubator-kie-sandbox-quarkus-accelerator`
>> > > > > > > > > > > > > > > > > depending
>> > > > > > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > > > > > > Kogito
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and
>> Quarkus
>> > > > > > > > `2.15.3.Final`.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > See:
>> > > > > > > > > > > > > > > > > > > > > > >> > > > -
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > P6. Category C repos
>> are out
>> > > > of
>> > > > > > date
>> > > > > > > > and
>> > > > > > > > > > not
>> > > > > > > > > > > > part
>> > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > Category
>> > > > > > > > > > > > > > > > > > > > > > A
>> > > > > > > > > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > *
>> > > > > incubator-kie-kogito-benchmarks:
>> > > > > > > > > > (Current
>> > > > > > > > > > > > > > version
>> > > > > > > > > > > > > > > is
>> > > > > > > > > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > depending on Kogito
>> without
>> > > a
>> > > > > > specific
>> > > > > > > > > > > > version,
>> > > > > > > > > > > > > > only
>> > > > > > > > > > > > > > > > by
>> > > > > > > > > > > > > > > > > > > using
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `http://localhost:8080
>> `)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > *
>> incubator-kie-benchmarks:
>> > > > > > (Current
>> > > > > > > > > > version
>> > > > > > > > > > > > is
>> > > > > > > > > > > > > > > > > > > > `1.0-SNAPSHOT`,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > pointing to Drools
>> > > > 999-SNAPSHOT
>> > > > > > and
>> > > > > > > > > > > > OptaPlanner
>> > > > > > > > > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > P7.
>> > > > > > > > > > `kie-tools`/packages/kn-plugin-workflow
>> > > > > > > > > > > > has
>> > > > > > > > > > > > > > its
>> > > > > > > > > > > > > > > > E2E
>> > > > > > > > > > > > > > > > > > > > disabled
>> > > > > > > > > > > > > > > > > > > > > > >> after
>> > > > > > > > > > > > > > > > > > > > > > >> > > > upgrading to
>> > > > > > 999-20240218-SNAPSHOT.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > In my perspective, P1
>> and P2
>> > > > > have
>> > > > > > the
>> > > > > > > > same
>> > > > > > > > > > > > > > solution,
>> > > > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > > they
>> > > > > > > > > > > > > > > > > > > > > both
>> > > > > > > > > > > > > > > > > > > > > > >> > > > suffer from the
>> circular
>> > > > > > dependency
>> > > > > > > > > > between
>> > > > > > > > > > > > > > > Category A
>> > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > Category
>> > > > > > > > > > > > > > > > > > > > > > >> B.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > As Category A and
>> Category B
>> > > > are
>> > > > > > both
>> > > > > > > > > > streams
>> > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > have
>> > > > > > > > > > > > > > > > > > been
>> > > > > > > > > > > > > > > > > > > > > > really
>> > > > > > > > > > > > > > > > > > > > > > >> > > > active, I see this as a
>> > > > blocker,
>> > > > > > as
>> > > > > > > > there
>> > > > > > > > > > are
>> > > > > > > > > > > > > > > > > > contributions
>> > > > > > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > > > > > >> > > > cannot be done, given
>> that
>> > > > > > Category A
>> > > > > > > > > > depends
>> > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > Category
>> > > > > > > > > > > > > > > > > > B
>> > > > > > > > > > > > > > > > > > > > > with a
>> > > > > > > > > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > P3 and P4, although not
>> > > ideal,
>> > > > > > can be
>> > > > > > > > > > > > understood
>> > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > > > technical
>> > > > > > > > > > > > > > > > > > > > > > debt.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Depending on
>> unmaintained
>> > > > > > projects is
>> > > > > > > > > > > > something
>> > > > > > > > > > > > > > > we'll
>> > > > > > > > > > > > > > > > > > always
>> > > > > > > > > > > > > > > > > > > > be
>> > > > > > > > > > > > > > > > > > > > > > >> > > > susceptible to, given
>> time.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > P5 and P6 are easily
>> > > fixable,
>> > > > as
>> > > > > > it's
>> > > > > > > > > > just a
>> > > > > > > > > > > > > > matter
>> > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > > making
>> > > > > > > > > > > > > > > > > > > > > them
>> > > > > > > > > > > > > > > > > > > > > > >> > > > part of the play.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > P7 is an isolated
>> problem
>> > > that
>> > > > > > won't
>> > > > > > > > > > impact
>> > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > structure
>> > > > > > > > > > > > > > > > > > or
>> > > > > > > > > > > > > > > > > > > > > > >> anything
>> > > > > > > > > > > > > > > > > > > > > > >> > > > that we're talking
>> about
>> > > here,
>> > > > > > but it
>> > > > > > > > is a
>> > > > > > > > > > > > > > > regression
>> > > > > > > > > > > > > > > > we
>> > > > > > > > > > > > > > > > > > > > > > introduced
>> > > > > > > > > > > > > > > > > > > > > > >> > > > recently.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can
>> be
>> > > > > ignored
>> > > > > > for
>> > > > > > > > > > Apache
>> > > > > > > > > > > > KIE
>> > > > > > > > > > > > > > 10,
>> > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > > > > P5,
>> > > > > > > > > > > > > > > > > > > > > > >> P6,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > and P7 have easy
>> fixes, the
>> > > > only
>> > > > > > > > problems
>> > > > > > > > > > > > left to
>> > > > > > > > > > > > > > > > > discuss
>> > > > > > > > > > > > > > > > > > > are
>> > > > > > > > > > > > > > > > > > > > P1
>> > > > > > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > >> > > > P2, which can't be done
>> > > > without
>> > > > > a
>> > > > > > > > proper
>> > > > > > > > > > > > proposal.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > I'll try to be very
>> > > meticulous
>> > > > > > here,
>> > > > > > > > since
>> > > > > > > > > > > > from my
>> > > > > > > > > > > > > > > > > > > experience,
>> > > > > > > > > > > > > > > > > > > > > any
>> > > > > > > > > > > > > > > > > > > > > > >> > > > little miscalculation
>> can
>> > > lead
>> > > > > to
>> > > > > > our
>> > > > > > > > > > release
>> > > > > > > > > > > > not
>> > > > > > > > > > > > > > > > > working
>> > > > > > > > > > > > > > > > > > > out
>> > > > > > > > > > > > > > > > > > > > in
>> > > > > > > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > > >> > > > end. To try and avoid
>> that
>> > > as
>> > > > > > much as
>> > > > > > > > > > > > possible,
>> > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > make
>> > > > > > > > > > > > > > > > > > > > > > everything
>> > > > > > > > > > > > > > > > > > > > > > >> we
>> > > > > > > > > > > > > > > > > > > > > > >> > > > can to have a
>> successful
>> > > > Apache
>> > > > > > KIE 10
>> > > > > > > > > > > > release,
>> > > > > > > > > > > > > > bear
>> > > > > > > > > > > > > > > > > with
>> > > > > > > > > > > > > > > > > > > me.
>> > > > > > > > > > > > > > > > > > > > > I'll
>> > > > > > > > > > > > > > > > > > > > > > >> lay
>> > > > > > > > > > > > > > > > > > > > > > >> > > > out a timeline of
>> events
>> > > that
>> > > > > > need to
>> > > > > > > > > > happen
>> > > > > > > > > > > > in
>> > > > > > > > > > > > > > > order
>> > > > > > > > > > > > > > > > > for
>> > > > > > > > > > > > > > > > > > > our
>> > > > > > > > > > > > > > > > > > > > > > >> release
>> > > > > > > > > > > > > > > > > > > > > > >> > > > to be published, with
>> all
>> > > > > > artifacts
>> > > > > > > > > > ending up
>> > > > > > > > > > > > in
>> > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > right
>> > > > > > > > > > > > > > > > > > > > > places,
>> > > > > > > > > > > > > > > > > > > > > > >> but
>> > > > > > > > > > > > > > > > > > > > > > >> > > > first, we need to solve
>> > > > problems
>> > > > > > P1
>> > > > > > > > and
>> > > > > > > > > > P2.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > As you saw at the
>> beginning
>> > > of
>> > > > > > this
>> > > > > > > > email,
>> > > > > > > > > > > > all the
>> > > > > > > > > > > > > > > > > > attempts
>> > > > > > > > > > > > > > > > > > > we
>> > > > > > > > > > > > > > > > > > > > > > made
>> > > > > > > > > > > > > > > > > > > > > > >> > > > left us with the
>> circular
>> > > > > > dependency
>> > > > > > > > > > showing
>> > > > > > > > > > > > up
>> > > > > > > > > > > > > > at a
>> > > > > > > > > > > > > > > > > > > different
>> > > > > > > > > > > > > > > > > > > > > > >> place,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > but something all these
>> > > places
>> > > > > > have in
>> > > > > > > > > > common
>> > > > > > > > > > > > is
>> > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > > they're
>> > > > > > > > > > > > > > > > > > > > > all
>> > > > > > > > > > > > > > > > > > > > > > >> > > > after kogito-apps, and
>> > > before
>> > > > to
>> > > > > > > > Category
>> > > > > > > > > > B.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > The first part of my
>> > > proposal
>> > > > is
>> > > > > > the
>> > > > > > > > > > > > following:
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > S1. We keep the
>> original
>> > > plan
>> > > > of
>> > > > > > > > moving
>> > > > > > > > > > the
>> > > > > > > > > > > > > > Quarkus
>> > > > > > > > > > > > > > > > Dev
>> > > > > > > > > > > > > > > > > > UIs
>> > > > > > > > > > > > > > > > > > > > from
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-apps` to
>> > > `kie-tools`,
>> > > > > > together
>> > > > > > > > > > with
>> > > > > > > > > > > > > > > Management
>> > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > Task
>> > > > > > > > > > > > > > > > > > > > > > >> > > > consoles from
>> > > `kogito-images`
>> > > > to
>> > > > > > > > > > `kie-tools`.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > S2. We move the
>> > > > > > `kogito-swf-devmode`
>> > > > > > > > and
>> > > > > > > > > > > > > > > > > > > `kogito-swf-builder`
>> > > > > > > > > > > > > > > > > > > > > > images
>> > > > > > > > > > > > > > > > > > > > > > >> > > > from `kogito-images` to
>> > > > > > `kie-tools`
>> > > > > > > > too.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > S3. We move the entire
>> > > > > > > > > > > > > > `kogito-serverless-operator`
>> > > > > > > > > > > > > > > > repo
>> > > > > > > > > > > > > > > > > > > > inside
>> > > > > > > > > > > > > > > > > > > > > a
>> > > > > > > > > > > > > > > > > > > > > > >> new
>> > > > > > > > > > > > > > > > > > > > > > >> > > > package on `kie-tools`,
>> > > > keeping
>> > > > > > Git
>> > > > > > > > > > history.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and
>> S3
>> > > > > together
>> > > > > > > > solve
>> > > > > > > > > > > > problems
>> > > > > > > > > > > > > > P1
>> > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > P2.
>> > > > > > > > > > > > > > > > > > > Of
>> > > > > > > > > > > > > > > > > > > > > > >> course
>> > > > > > > > > > > > > > > > > > > > > > >> > > > the rest of
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > >
>> > > > > https://github.com/apache/incubator-kie-issues/issues/967
>> > > > > > > > > > > > > > > > > > > > > > >> > > > would still be done
>> too.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > This doesn't come
>> without
>> > > > > > > > consequences, of
>> > > > > > > > > > > > course,
>> > > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`
>> and
>> > > > > > > > > > `kogito-swf-builder`
>> > > > > > > > > > > > > > > images,
>> > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> `kogito-serverless-operator`
>> > > > > > would be
>> > > > > > > > > > moving
>> > > > > > > > > > > > from
>> > > > > > > > > > > > > > > > > > Category A
>> > > > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Category B. This move
>> would
>> > > > make
>> > > > > > them
>> > > > > > > > > > have to
>> > > > > > > > > > > > > > > > reference
>> > > > > > > > > > > > > > > > > > > > > Category A
>> > > > > > > > > > > > > > > > > > > > > > >> > > > repos through
>> timestamped
>> > > > > > SNAPSHOTs.
>> > > > > > > > Since
>> > > > > > > > > > > > > > > > > `kogito-images`
>> > > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> `kogito-serverless-operator`
>> > > > are
>> > > > > > > > already
>> > > > > > > > > > > > their own
>> > > > > > > > > > > > > > > > > > > > "sub-stream"
>> > > > > > > > > > > > > > > > > > > > > > >> inside
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Category A, though,
>> > > > > contributions
>> > > > > > > > made in
>> > > > > > > > > > a
>> > > > > > > > > > > > > > > cross-repo
>> > > > > > > > > > > > > > > > > > > fashion
>> > > > > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > >> this
>> > > > > > > > > > > > > > > > > > > > > > >> > > > "sub-stream" will
>> continue
>> > > > being
>> > > > > > > > > > possible, now
>> > > > > > > > > > > > > > via a
>> > > > > > > > > > > > > > > > > > single
>> > > > > > > > > > > > > > > > > > > PR
>> > > > > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`.
>> Cross-repo PRs
>> > > > > > between
>> > > > > > > > > > Category
>> > > > > > > > > > > > A and
>> > > > > > > > > > > > > > > > > > Category
>> > > > > > > > > > > > > > > > > > > B
>> > > > > > > > > > > > > > > > > > > > > will
>> > > > > > > > > > > > > > > > > > > > > > >> > > > continue not being
>> possible,
>> > > > > and a
>> > > > > > > > 1-week
>> > > > > > > > > > > > delay
>> > > > > > > > > > > > > > > > between
>> > > > > > > > > > > > > > > > > > > > merging
>> > > > > > > > > > > > > > > > > > > > > > >> > > > something on Category
>> A and
>> > > > > using
>> > > > > > it
>> > > > > > > > on
>> > > > > > > > > > > > Category B
>> > > > > > > > > > > > > > > > will
>> > > > > > > > > > > > > > > > > > > still
>> > > > > > > > > > > > > > > > > > > > > > >> happen.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > It's worth mentioning
>> that
>> > > > > > > > `kie-tools`,
>> > > > > > > > > > > > however,
>> > > > > > > > > > > > > > > does
>> > > > > > > > > > > > > > > > > > allow
>> > > > > > > > > > > > > > > > > > > > for
>> > > > > > > > > > > > > > > > > > > > > > >> sparse
>> > > > > > > > > > > > > > > > > > > > > > >> > > > checkouts and partial
>> > > builds,
>> > > > so
>> > > > > > > > working
>> > > > > > > > > > with
>> > > > > > > > > > > > a
>> > > > > > > > > > > > > > > subset
>> > > > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > > >> monorepo
>> > > > > > > > > > > > > > > > > > > > > > >> > > > is possible and
>> encouraged.
>> > > > > Making
>> > > > > > > > changes
>> > > > > > > > > > > > only to
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > `packages/kn-plugin-workflow`,
>> > > > > for
>> > > > > > > > > > example,
>> > > > > > > > > > > > will
>> > > > > > > > > > > > > > > have
>> > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > PR
>> > > > > > > > > > > > > > > > > > > > > > checks
>> > > > > > > > > > > > > > > > > > > > > > >> > > > run in < 10 minutes,
>> as you
>> > > > can
>> > > > > > see
>> > > > > > > > here:
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
>> > > > > > > > > > > > > > > > > > > > > > >> > > > .
>> > > > > > > > > > > > > > > > > > > > > > >> > > > We're not compromising
>> when
>> > > > > > running
>> > > > > > > > > > partial
>> > > > > > > > > > > > builds
>> > > > > > > > > > > > > > > > too.
>> > > > > > > > > > > > > > > > > We
>> > > > > > > > > > > > > > > > > > > > know
>> > > > > > > > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > > > > > >> > > > the entire repo will
>> > > continue
>> > > > > > working
>> > > > > > > > even
>> > > > > > > > > > > > after
>> > > > > > > > > > > > > > > only
>> > > > > > > > > > > > > > > > > > > > building a
>> > > > > > > > > > > > > > > > > > > > > > >> small
>> > > > > > > > > > > > > > > > > > > > > > >> > > > subset of the changes.
>> Doing
>> > > > > > partial
>> > > > > > > > or
>> > > > > > > > > > full
>> > > > > > > > > > > > > > builds
>> > > > > > > > > > > > > > > is
>> > > > > > > > > > > > > > > > > > > > > > automatically
>> > > > > > > > > > > > > > > > > > > > > > >> > > > determined by the
>> changes
>> > > of a
>> > > > > PR.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Keep in mind that, even
>> > > though
>> > > > > I'm
>> > > > > > > > > > proposing
>> > > > > > > > > > > > we
>> > > > > > > > > > > > > > > move a
>> > > > > > > > > > > > > > > > > > bunch
>> > > > > > > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > > > > > >> > > > additional stuff into
>> > > > > > `kie-tools`, I
>> > > > > > > > see
>> > > > > > > > > > this
>> > > > > > > > > > > > as a
>> > > > > > > > > > > > > > > > > > TEMPORARY
>> > > > > > > > > > > > > > > > > > > > > > >> solution
>> > > > > > > > > > > > > > > > > > > > > > >> > > > for our codebase.
>> > > `kie-tools`
>> > > > > > would
>> > > > > > > > host
>> > > > > > > > > > some
>> > > > > > > > > > > > > > > > additional
>> > > > > > > > > > > > > > > > > > > stuff
>> > > > > > > > > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we
>> can
>> > > > > > release and
>> > > > > > > > > > > > continue
>> > > > > > > > > > > > > > > moving
>> > > > > > > > > > > > > > > > > > > > forward.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > As I mentioned on other
>> > > > places,
>> > > > > > > > > > `kie-tools`
>> > > > > > > > > > > > > > became a
>> > > > > > > > > > > > > > > > > > > polyglot
>> > > > > > > > > > > > > > > > > > > > > > >> monorepo
>> > > > > > > > > > > > > > > > > > > > > > >> > > > out of necessity, and
>> > > although
>> > > > > I'm
>> > > > > > > > really
>> > > > > > > > > > > > proud of
>> > > > > > > > > > > > > > > > what
>> > > > > > > > > > > > > > > > > we
>> > > > > > > > > > > > > > > > > > > > > > achieved
>> > > > > > > > > > > > > > > > > > > > > > >> > > > there so far, I don't
>> think
>> > > > > > > > `kie-tools`
>> > > > > > > > > > has a
>> > > > > > > > > > > > > > setup
>> > > > > > > > > > > > > > > > that
>> > > > > > > > > > > > > > > > > > is
>> > > > > > > > > > > > > > > > > > > > > > suitable
>> > > > > > > > > > > > > > > > > > > > > > >> > > > for all the different
>> > > nuances
>> > > > > that
>> > > > > > > > > > compose our
>> > > > > > > > > > > > > > > > > community.
>> > > > > > > > > > > > > > > > > > > I'm
>> > > > > > > > > > > > > > > > > > > > > well
>> > > > > > > > > > > > > > > > > > > > > > >> > > > aware that a polyglot
>> > > monorepo
>> > > > > > that
>> > > > > > > > does
>> > > > > > > > > > not
>> > > > > > > > > > > > > > follow
>> > > > > > > > > > > > > > > > > > > widespread
>> > > > > > > > > > > > > > > > > > > > > > >> > > > conventions will scare
>> some
>> > > > > people
>> > > > > > > > away,
>> > > > > > > > > > and
>> > > > > > > > > > > > as
>> > > > > > > > > > > > > > much
>> > > > > > > > > > > > > > > > as
>> > > > > > > > > > > > > > > > > > > we've
>> > > > > > > > > > > > > > > > > > > > > > tried
>> > > > > > > > > > > > > > > > > > > > > > >> to
>> > > > > > > > > > > > > > > > > > > > > > >> > > > make build instructions
>> > > clear,
>> > > > > we
>> > > > > > > > can't
>> > > > > > > > > > > > always get
>> > > > > > > > > > > > > > > > past
>> > > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > > >> prejudice
>> > > > > > > > > > > > > > > > > > > > > > >> > > > some people have
>> towards the
>> > > > > > > > "front-end"
>> > > > > > > > > > > > > > ecosystem.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > With all that said, I
>> keep
>> > > > > > thinking
>> > > > > > > > this
>> > > > > > > > > > is
>> > > > > > > > > > > > the
>> > > > > > > > > > > > > > best
>> > > > > > > > > > > > > > > > > > course
>> > > > > > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > > > > > > >> action
>> > > > > > > > > > > > > > > > > > > > > > >> > > > for us right now. We
>> keep
>> > > most
>> > > > > of
>> > > > > > our
>> > > > > > > > > > stuff
>> > > > > > > > > > > > > > > unchanged,
>> > > > > > > > > > > > > > > > > we
>> > > > > > > > > > > > > > > > > > > > > unblock
>> > > > > > > > > > > > > > > > > > > > > > >> the
>> > > > > > > > > > > > > > > > > > > > > > >> > > > release, and we have a
>> > > working
>> > > > > > setup
>> > > > > > > > that
>> > > > > > > > > > will
>> > > > > > > > > > > > > > suit
>> > > > > > > > > > > > > > > us
>> > > > > > > > > > > > > > > > > > well
>> > > > > > > > > > > > > > > > > > > > > while
>> > > > > > > > > > > > > > > > > > > > > > we
>> > > > > > > > > > > > > > > > > > > > > > >> > > > discuss and reach a
>> > > conclusion
>> > > > > > > > regarding
>> > > > > > > > > > the
>> > > > > > > > > > > > > > future
>> > > > > > > > > > > > > > > of
>> > > > > > > > > > > > > > > > > our
>> > > > > > > > > > > > > > > > > > > > > > codebase
>> > > > > > > > > > > > > > > > > > > > > > >> > > > structure.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Let me paint a quick
>> picture
>> > > > > here
>> > > > > > of
>> > > > > > > > what
>> > > > > > > > > > our
>> > > > > > > > > > > > code
>> > > > > > > > > > > > > > > > base
>> > > > > > > > > > > > > > > > > > > would
>> > > > > > > > > > > > > > > > > > > > > look
>> > > > > > > > > > > > > > > > > > > > > > >> > > > like, repository-wise,
>> if my
>> > > > > > proposal
>> > > > > > > > is
>> > > > > > > > > > > > accepted:
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > CATEGORY REPO
>> > > > > > > > > > > > > > > > > > > > > > >> > > > =====================
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > > > > > > incubator-kie-kogito-pipelines
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > > incubator-kie-drools
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > > > > incubator-kie-optaplanner
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > > > > > > > > > > incubator-kie-optaplanner-quickstarts
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > > > > > > incubator-kie-kogito-runtimes
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > > > > incubator-kie-kogito-apps
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > > > > > > incubator-kie-kogito-examples
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > > > > > > incubator-kie-kogito-images
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > > > > incubator-kie-kogito-docs
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > > > > > > > > incubator-kie-kogito-benchmarks
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > incubator-kie-docs
>> > > > > > > > > > > > > > > > > > > > > > >> > > > A
>> > > > > > incubator-kie-benchmarks
>> > > > > > > > > > > > > > > > > > > > > > >> > > > =====================
>> > > > > > > > > > > > > > > > > > > > > > >> > > > B
>> > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
>> > > > > > > > > > > > > > > > > > > > > > >> > > > B
>> > > > incubator-kie-tools
>> > > > > > > > > > > > > > > > > > > > > > >> > > > =====================
>> > > > > > > > > > > > > > > > > > > > > > >> > > > D
>> > > > > > > > incubator-kie-kogito-operator
>> > > > > > > > > > > > > > > > > > > > > > >> > > > =====================
>> > > > > > > > > > > > > > > > > > > > > > >> > > > E
>> > > > incubator-kie-issues
>> > > > > > > > > > > > > > > > > > > > > > >> > > > E
>> > > > > > > > incubator-kie-kogito-website
>> > > > > > > > > > > > > > > > > > > > > > >> > > > E
>> > > > > incubator-kie-website
>> > > > > > > > > > > > > > > > > > > > > > >> > > > E
>> > > > > > > > incubator-kie-kogito-online
>> > > > > > > > > > > > > > > > > > > > > > >> > > > E
>> > > > > > > > > > > > incubator-kie-kogito-online-staging
>> > > > > > > > > > > > > > > > > > > > > > >> > > > =====================
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > * Category C becomes
>> part of
>> > > > > > Category
>> > > > > > > > A,
>> > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> `kogito-serverless-operator`
>> > > > > moves
>> > > > > > > > > > entirely
>> > > > > > > > > > > > inside
>> > > > > > > > > > > > > > > > > > > > `kie-tools`.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > * With
>> > > > > > `kogito-swf-{builder,devmode}`
>> > > > > > > > > > images
>> > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> `kogito-serverless-operator`
>> > > > > > inside
>> > > > > > > > > > > > `kie-tools`,
>> > > > > > > > > > > > > > > there
>> > > > > > > > > > > > > > > > > are
>> > > > > > > > > > > > > > > > > > > no
>> > > > > > > > > > > > > > > > > > > > > > cycles
>> > > > > > > > > > > > > > > > > > > > > > >> > > > anymore, as inside
>> > > > `kie-tools`,
>> > > > > > we can
>> > > > > > > > > > > > granularly
>> > > > > > > > > > > > > > > > build:
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 1.
>> > > > > > > > > > packages/sonataflow-deployment-webapp
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 2.
>> > > > > > > > packages/sonataflow-quarkus-devui
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 3.
>> > > > > packages/sonataflow-images
>> > > > > > > > > > (containing
>> > > > > > > > > > > > > > > > > > > > > `kogito-swf-builder`
>> > > > > > > > > > > > > > > > > > > > > > >> and
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 4.
>> > > > > > packages/sonataflow-operator
>> > > > > > > > > > (contents
>> > > > > > > > > > > > from
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > `kogito-serverless-operator`)
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 5.
>> > > > > > packages/kn-plugin-sonataflow
>> > > > > > > > > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > but renamed)
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > The second part of the
>> > > > proposal
>> > > > > > is the
>> > > > > > > > > > release
>> > > > > > > > > > > > > > > process
>> > > > > > > > > > > > > > > > > > > itself,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > assuming the structure
>> above
>> > > > is
>> > > > > > what
>> > > > > > > > we
>> > > > > > > > > > have.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Here it is:
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 1. Define a timestamped
>> > > > SNAPSHOT
>> > > > > > to be
>> > > > > > > > > > used as
>> > > > > > > > > > > > > > > cutting
>> > > > > > > > > > > > > > > > > > point
>> > > > > > > > > > > > > > > > > > > > for
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Category A repos.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 2. Update Category B
>> repos
>> > > to
>> > > > > > point to
>> > > > > > > > > > this
>> > > > > > > > > > > > > > > > timestamped
>> > > > > > > > > > > > > > > > > > > > > SNAPSHOT,
>> > > > > > > > > > > > > > > > > > > > > > >> and
>> > > > > > > > > > > > > > > > > > > > > > >> > > > verify that everything
>> is
>> > > > > working.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 3. At this point, with
>> > > > > everything
>> > > > > > > > > > working, we
>> > > > > > > > > > > > can
>> > > > > > > > > > > > > > > > branch
>> > > > > > > > > > > > > > > > > > out
>> > > > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A
>> from
>> > > the
>> > > > > > > > timestamped
>> > > > > > > > > > > > SNAPSHOT
>> > > > > > > > > > > > > > > > tag,
>> > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > >> Category B
>> > > > > > > > > > > > > > > > > > > > > > >> > > > from `main`.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 4. All Category A and
>> > > > Category B
>> > > > > > repos
>> > > > > > > > > > update
>> > > > > > > > > > > > > > their
>> > > > > > > > > > > > > > > > > > versions
>> > > > > > > > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 10.0.0, in their
>> `10.0.x`
>> > > > > > branches.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 5. Update Category B
>> repos
>> > > to
>> > > > > > point to
>> > > > > > > > > > > > Category A
>> > > > > > > > > > > > > > > > repos
>> > > > > > > > > > > > > > > > > > > using
>> > > > > > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 10.0.0 version.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 6. At this point, we
>> can
>> > > vote
>> > > > on
>> > > > > > the
>> > > > > > > > > > release
>> > > > > > > > > > > > based
>> > > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > > > > > > `10.0.x`
>> > > > > > > > > > > > > > > > > > > > > > >> > > > branches, given we
>> don't
>> > > > expect
>> > > > > > any
>> > > > > > > > code
>> > > > > > > > > > > > changes
>> > > > > > > > > > > > > > > > > anymore.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 7. After voting passes,
>> > > we're
>> > > > > > good to
>> > > > > > > > > > start
>> > > > > > > > > > > > the
>> > > > > > > > > > > > > > > > release
>> > > > > > > > > > > > > > > > > > > > process.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 8. Category A repos
>> follow
>> > > > their
>> > > > > > > > > > > > manual/automated
>> > > > > > > > > > > > > > > > > release
>> > > > > > > > > > > > > > > > > > > > > process,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > pointing to the
>> `10.0.x`
>> > > > branch.
>> > > > > > Tags
>> > > > > > > > > > pushed
>> > > > > > > > > > > > to
>> > > > > > > > > > > > > > Git,
>> > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > built
>> > > > > > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to
>> their
>> > > > > > registries.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 9. We wait a little
>> bit for
>> > > > > > Category A
>> > > > > > > > > > > > artifacts
>> > > > > > > > > > > > > > to
>> > > > > > > > > > > > > > > be
>> > > > > > > > > > > > > > > > > > > > > propagated
>> > > > > > > > > > > > > > > > > > > > > > on
>> > > > > > > > > > > > > > > > > > > > > > >> > > > registries. ~1 day.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 10. Category B repos
>> follow
>> > > > > their
>> > > > > > > > > > > > manual/automated
>> > > > > > > > > > > > > > > > > release
>> > > > > > > > > > > > > > > > > > > > > > process,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > pointing to the
>> `10.0.x`
>> > > > branch.
>> > > > > > Tags
>> > > > > > > > > > pushed
>> > > > > > > > > > > > to
>> > > > > > > > > > > > > > Git,
>> > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > built
>> > > > > > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to
>> their
>> > > > > > registries.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 11. Category D repos
>> are
>> > > > > ignored.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > 12. Category E repos
>> can be
>> > > > > > manually
>> > > > > > > > > > tagged
>> > > > > > > > > > > > with
>> > > > > > > > > > > > > > > > 10.0.0
>> > > > > > > > > > > > > > > > > > from
>> > > > > > > > > > > > > > > > > > > > > their
>> > > > > > > > > > > > > > > > > > > > > > >> > > > default branches.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > More needs to be
>> discussed
>> > > if
>> > > > > > we're
>> > > > > > > > > > planning
>> > > > > > > > > > > > to
>> > > > > > > > > > > > > > > > maintain
>> > > > > > > > > > > > > > > > > > > > > multiple
>> > > > > > > > > > > > > > > > > > > > > > >> > > > release streams in
>> parallel,
>> > > > > but I
>> > > > > > > > guess
>> > > > > > > > > > it
>> > > > > > > > > > > > can
>> > > > > > > > > > > > > > wait
>> > > > > > > > > > > > > > > > for
>> > > > > > > > > > > > > > > > > > > after
>> > > > > > > > > > > > > > > > > > > > > > >> Apache
>> > > > > > > > > > > > > > > > > > > > > > >> > > > KIE 10.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Thank you for reading,
>> and
>> > > I'm
>> > > > > > looking
>> > > > > > > > > > > > forward to
>> > > > > > > > > > > > > > > > > hearing
>> > > > > > > > > > > > > > > > > > > back
>> > > > > > > > > > > > > > > > > > > > > > from
>> > > > > > > > > > > > > > > > > > > > > > >> > > > everyone.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Of course, alternative
>> > > > solutions
>> > > > > > are
>> > > > > > > > > > possible.
>> > > > > > > > > > > > > > This
>> > > > > > > > > > > > > > > > > email,
>> > > > > > > > > > > > > > > > > > > > > > however,
>> > > > > > > > > > > > > > > > > > > > > > >> > > > summarizes my view of
>> how we
>> > > > > > should
>> > > > > > > > > > attack the
>> > > > > > > > > > > > > > > > problem,
>> > > > > > > > > > > > > > > > > > > > > > considering
>> > > > > > > > > > > > > > > > > > > > > > >> > > > disruption, required
>> effort,
>> > > > the
>> > > > > > > > release
>> > > > > > > > > > > > process
>> > > > > > > > > > > > > > > > itself,
>> > > > > > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > > > > > > > > >> history.
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Feel free to propose
>> > > > > alternatives.
>> > > > > > > > This is
>> > > > > > > > > > > > not a
>> > > > > > > > > > > > > > > > voting
>> > > > > > > > > > > > > > > > > > > > thread.
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Regards,
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > > Tiago Bento
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
>> > > > > > > > > > > > > > > > dev-unsubscribe@kie.apache.org
>> > > > > > > > > > > > > > > > > > > > > > >> > > > For additional
>> commands,
>> > > > e-mail:
>> > > > > > > > > > > > > > > > > dev-help@kie.apache.org
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > > > > > > > > > > > >> > >
>> > > > > > > > > > > > > > > > > > > > > > >> >
>> > > > > > > > > > > > > > > > > > > > > > >>
>> > > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > > > > To unsubscribe, e-mail:
>> dev-unsubscribe@kie.apache.org
>> > > > > > > > > > > > For additional commands, e-mail:
>> dev-help@kie.apache.org
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
>> > > > > > > > > > For additional commands, e-mail:
>> dev-help@kie.apache.org
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
>> > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
>> > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > > >
>> ---------------------------------------------------------------------
>> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
>> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
>> For additional commands, e-mail: dev-help@kie.apache.org
>>
>>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Tiago,
Maybe I did not explain myself well.
If you have a dependency in a pom and that dependency does not longer
exits, the build will fail, of course. I do not think this is related at
all with using one kind of snapshot or another. In fact, as a proof that
absolute truths are really rare, if that arficat would have a release
version, you will believe that your dependency tree is perfectly fine when
in fact it is obsoleted, so it can be argues than using the same snapshot
helps to find the issue earlier in the development cycle.
Anyway, when I refer to strong vs weak dependency (just to let you know
that spanish translation of fallacy is worse than spanish translation of
wrong, which does not have such negative connotation, but its ok, I got the
idea ;)), Im referring to case A( weak) and B (strong)
A) Examples depends on the recently renamed sonataflow-quarkus-devui
artfifact. You can remove that dependency from the pom and the example
still works. Thats a weak dependency, you lose some functionality
(deployment of tools along the example) but the example is still usable and
it passes the IT test.
B) Not compatible modification of drools interface. That's a strong one.
The sooner we find it the better and I think (its pretty obvious the sooner
occurs when both drools and runtimes use the same snapshot number, rather
than relying on a fixed snapshot, when we might realize long after the
drools change has been performed) .
So, no su much fallacy after all.
On Thu, Mar 14, 2024 at 7:44 PM Tiago Bento <ti...@gmail.com>
wrote:
> New day, new findings.
>
> Yesterday, in a very fruitful conversation with Caponetto, I
> discovered that `kie-tools` is currently referencing two additional
> images from `kogito-images`. The current dependencies between
> `kie-tools` and `kogito-images` are the following:
>
> 1. `packages/kn-plugin-workflow` --> `quay.io/kiegroup/kogito-swf-devmode`
> <http://quay.io/kiegroup/kogito-swf-devmode>
> 2. `packages/serverless-logic-web-tools-swf-builder-image` -->
> `quay.io/kiegroup/kogito-swf-builder`
> <http://quay.io/kiegroup/kogito-swf-builder>
> 3. `packages/serverless-logic-web-tools-base-builder-image` -->
> `quay.io/kiegroup/kogito-base-builder`
> <http://quay.io/kiegroup/kogito-base-builder>
> 4. `packages/serverless-logic-web-tools-swf-dev-mode-image` -->
> `quay.io/kiegroup/kogito-base-builder`
> <http://quay.io/kiegroup/kogito-base-builder>
>
> All these references were already correctly pointing to the `-nightly`
> builds of each image, mirroring the timestamped SNAPSHOT strategy we
> currently have. Except for reference 2., which was pointing to
> `latest`. I sent a PR
> (https://github.com/apache/incubator-kie-tools/pull/2198) to fix the
> discrepancy, and to my surprise the PR broke, with a `999-SNAPSHOT`
> reference not being found during the build.
>
> All three images that depend on `kogito-images` are dependencies of
> the Serverless Logic Web Tools app.
>
> This is a clear example of the problems I explained in my previous
> messages. Let me explain this manifestation of the problem here in
> more depth.
>
> The problem here is a module from a Category A repo was renamed, and
> the `main-2024-02-18` tag of `quay.io/kiegroup/kogito-swf-builder`
> <http://quay.io/kiegroup/kogito-swf-builder> was
> published with a reference to
>
> `org.kie.kogito:kogito-addons-quarkus-knative-serving-deployment:999-SNAPSHOT`.
> An artifact with this GAV does not exist anymore, as SNAPSHOTs are not
> only mutable, but also ephemeral. IMHO, Maven SNAPSHOTs are NOT a
> reliable mechanism for repo synchronicity, but that's a problem for
> later.
>
> `kogito-images` depending on upstream repos through mutable, ephemeral
> SNAPSHOTs, is making `kie-tools` indirectly depend on them too, and as
> you could see, the build is broken, simply because a module was
> renamed. With the risk of getting ahead of myself, I just want to make
> it clear that if `kie-tools` just pointed to the `latest` tag of
> `kogito-images`, it would be exactly the same case as a Dockerized
> version of Maven SNAPSHOTs, which, of course, would be problematic,
> as already extensively explained in this thread.
>
> The outcome of my findings between yesterday and today are:
>
> A. `kn-plugin-workflow` is not the only package on `kie-tools`
> depending on `kogito-images`. We also have
> `serverless-logic-web-tools-swf-builder-image`,
> `serverless-logic-web-tools-base-builder-image`, and
> `serverless-logic-web-tools-base-builder-image`. All dependencies to
> the Serverless Logic Web Tools app.
> B. weak vs. strong dependencies is a fallacy. Testing and developing
> require us to have the dependencies available, in sync, at all times.
> The way I see things, a dependency is a dependency. Period.
> C. The nightly builds of `kogito-images` are potentially all broken
> after some modules were renamed, rendering them not usable. This can
> be mitigated by upgrading to a more recent timestamped SNAPSHOT/tag,
> which is already PRed
> (https://github.com/apache/incubator-kie-tools/pull/2193), but the
> architectural problem will remain, unless we change the automation
> jobs of `kogito-images` to point to timestamped SNAPSHOTs of upstream
> artifacts when publishing their own timestamped tags under the
> "-nightly" prefix. Which I think we have to do, btw.
>
> To conclude, the proposal initially shared on this email thread still
> holds for unblocking and releasing Apache KIE 10, even after those new
> discoveries.
>
> On Thu, Mar 14, 2024 at 1:43 PM Francisco Javier Tirado Sarti
> <ft...@redhat.com> wrote:
> >
> > Hi Jan
> > Yes, that's why I was also discussing the suitability of timestamped
> > snapshots.
> > For me, both amplification of tools repo with unrelated code and
> > timestamped snapshots are against fixed snapshot and multi repo
> philosophy
> > employed in the rest of the project (it will be far easier from CI
> > perspective to have just one huge repo containing drools, runtimes, apps
> > and examples, but we are not doing that)
> > Therefore we are kind of sanctioning two different philosophies in our
> > first apache release. Since there is apparently no other alternative with
> > the resources we have, we will have to release it with this discrepancy.
> > But it is sad and I think we should learn from this experience to avoid
> > repeating it in the future. In my opinion, this proposal should have been
> > shared long before to not make it a fait accompli.
> >
> > On Thu, Mar 14, 2024 at 6:18 PM Jan Šťastný <js...@apache.org>
> wrote:
> >
> > > Hello,
> > > I'll try to summarize the challenges I am aware of in relation to CI
> at the
> > > moment and with the proposals.
> > >
> > > (I am referring to projects forming the build chain as upstream <->
> > > downstream depending on their placing in the overall chain.)
> > >
> > > Current state:
> > > Category A projects:
> > > - We don't have one, but rather 3 sets of pipelines for project groups:
> > > drools, kogito and optaplanner, all these three utilizing a
> combination of
> > > GHA (mostly PR checks) and Jenkins pipelines based on
> > > apache/incubator-kie-kogito-pipelines framework (kogito-pipelines FW).
> > > - For these builds, we use build-chain tool, which allows to define
> > > cross-repository relations between projects, clone repositories and run
> > > custom commands in each of those, depending in what part of the build
> chain
> > > (considering the project triggering the build) they are invoked
> (upstream,
> > > downstream, current). Examples of the build-chain project dependencies
> > > configuration Tiago provided in the first email. Build-chain is a
> powerful
> > > tool, though we have limited knowledge (Roberto being the sole
> contributor
> > > of fixes since our move to ASF).
> > > - As part of the kogito pipeline kogito-images and *-operator jobs are
> > > attached, but relation to repositories earlier up the chain is either
> > > assumed (building from main branch of kogito-apps) or loose (building
> > > kogito-examples from main-nightly branch, which is created in preceding
> > > kogito-examples nightly build). It's not part of PR checks for
> repositories
> > > up the stream.
> > >
> > > Category B projects:
> > > - We have a unique solution based mainly on GHA, but recently also some
> > > parts (is it a backup?) in ASF Jenkins, but NOT using the
> kogito-pipelines
> > > FW.
> > >
> > > Category C projects:
> > > - There are loosely managed jobs for *-benchmarks repositories, just a
> > > matter of updating versions, easily manageable - won't discuss further.
> > >
> > > Current gaps:
> > >
> > > Category A projects:
> > > - Generally the current jenkins solution for PR checks is lacking, we
> have
> > > just a single kind of PR check, not allowing custom triggers (e.g. by
> > > comments) or various modes (like quarkus native build).
> > > - We don't have downstream builds as part of PR checks.
> > > - We build all in a single job. Which has resulted in execution time
> over 8
> > > hours which was not bearable. Thus we reduced the build scope to sort
> of
> > > compile downstream builds - we run tests for repositories that are
> part of
> > > the PR, but their dependents (coming after them) are only run without
> > > tests.
> > > - With the introduction of unified SNAPSHOTs we have not fully
> adjusted for
> > > this in our pipelines, leaving out relations like optaplanner ->
> drools and
> > > kogito-apps -> optaplanner - so problems will be missed in case of
> related
> > > PRs. This SNAPSHOT version unification indicates that instead of 3
> distinct
> > > buildchain configurations, we should now switch to a single one,
> especially
> > > for the sake of unification.
> > > - Part of the repositories (starting with kogito-images) are not
> attached
> > > in the build-chain build at all, but are rather consecutively executed
> > > pipelines relying on publishing artifacts for consumption downstream.
> > >
> > > Proposal assessment:
> > > - Almost any repository could be part of the build-chain configuration,
> > > complex invocations can be hidden e.g. using make.
> > > - Any changes to PR checks should have the following prerequisite not
> to
> > > increase complexity and to limit execution times: moving of all PR
> checks
> > > into GHA, introduction of isolated limited-scope PR checks, on-demand
> full
> > > downstream build.
> > > - Timestamped SNAPSHOTs consumed by kie-tools would call against
> attaching
> > > kie-tools into build-chain of drools/kogito, because we would be
> running PR
> > > checks/nightly against main which might differ from the timestamped
> > > SNAPSHOT. So this seems like either/or decision to me.
> > > - Build-chain would probably not be able to replicate the fine-grained
> > > build execution based on the changes in PR as kie-tools currently has
> in
> > > place.
> > > - It's not clear to me how/if we could generally limit scope of
> execution
> > > in downstream builds depending on scope of upstream repository changes.
> > > - Community CI has really limited human resources, I personally
> switched to
> > > an ad-hoc way of working on that, only when something breaks.
> > > - It's not clear to me how a build-chain would work in terms of
> > > consuming/passing artifacts outside of maven projects and artifacts.
> > > - It's fair to say that we have SMEs for CI/build in Category A
> (engines or
> > > cloud), Category B, but I don't think there's anyone knowing deep
> internals
> > > of all, to be able to provide a reliable estimate of efforts involved
> in
> > > bigger refactoring.
> > >
> > > Summary:
> > > I don't see an easy way how a simple change in CI would help to
> unblock the
> > > current situation. Considering Tiago's proposal, timestamped SNAPSHOTs
> > > already in place, assumed relative simplicity of making the components
> part
> > > of kie-tools build ...
> > >
> > > +1 from me
> > >
> > > Thanks.
> > > Best Regards
> > > Jan
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, 14 Mar 2024 at 11:24, Francisco Javier Tirado Sarti <
> > > ftirados@redhat.com> wrote:
> > >
> > > > Hi Tiago, Thanks for the detailed explanation
> > > > Actually, for tooling, where there is not strong dependency (as
> between
> > > > engine code in runtime and kie server api in drools), the fixed
> snapshot
> > > > mechanism will work pretty well, in my opinion.
> > > > On one side, an example that depends on devui will not fail to
> compile
> > > > because the snapshot is old. The contrary is also true, if we add a
> new
> > > > functionality in the server side that is going to be used by any
> tool,
> > > the
> > > > worst that might happen is that the functionality is not there in
> the old
> > > > snapshot, but it wont block tooling compilation (obviously if you
> need
> > > that
> > > > functionality to test a new UI feature, you will need the update
> > > snapshot,
> > > > but that's expected and I guess is also happening now, you need to
> wait
> > > for
> > > > the server artifact to be published on Maven)
> > > > Because of that loose dependency, tooling can be run, as it is, as an
> > > > almost completely separate project but also because of that, I feel
> it
> > > > might be easily integrated (except for CI changes, which are always
> > > > delicate) with the rest of the repos to achieve a single release
> number,
> > > > because, if all repos use the same snapshot, as far as there is one
> > > > snapshot, in the day by day experience everything will normally
> compile.
> > > > I think we agree that the natural place of tooling in the dependency
> > > chain
> > > > is after apps (service) and before images. With that in mind and if
> we
> > > > wholly embrace the consequence of being a single release, in my
> opinion,
> > > it
> > > > means that tooling become one more repo (no A no B category), which
> use
> > > a
> > > > fixed snapshot as the rest, and it is subject to the need to
> eventually
> > > > wait for the updated snapshot (or in case you cannot wait, a local
> full
> > > > build), in the unlikely case there is a change that blocks its local
> > > > compilation. The implication of this is that the development cycle
> that
> > > is
> > > > implicit in your proposal to use a "fixed snapshot" in category A
> repos
> > > no
> > > > longer apply.
> > > > This means no time to adjust, which can sound like an herexy, but, if
> > > there
> > > > is no need for a gap between drools and runtimes, why is there a need
> > > for a
> > > > gap between tooling and apps (services)? (I think we agree a Java API
> > > > dependency is stronger than a REST API) Do we have a real precedent
> that
> > > > justify that? I kind of feel that here we are converting an old habit
> > > into
> > > > an axiomatic need (probably because Im lacking context)
> > > > Now my proposal for CI, we do not really need a single stream right
> now.
> > > We
> > > > can keep the current kogito stream as it is, except for images, and
> > > > integrate tooling into the stream that is now used for the operator
> (the
> > > > assumption here is that a change in drools-runtimes hardly breaks the
> > > tools
> > > > and in any case that is already happening, so we do not lose
> anything)
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 8:18 PM ricardo zanini fernandes <
> > > > ricardozanini@gmail.com> wrote:
> > > >
> > > > > Hey Tiago, thanks for the insights, I appreciate it.
> > > > >
> > > > > Just one thing regarding building from kie-tools one module that
> images
> > > > > need to sync changes. That might happen, of course. If I see a
> problem
> > > in
> > > > > devui, I just report it in the tools repo, we work on the bug, and
> in
> > > the
> > > > > next image build we get the changes. By the nature of the
> > > > operator/images,
> > > > > such changes won't impact our builds. What impact our builds are
> > > > > self-contained on those repos or work made in the engines, where we
> > > rely
> > > > on
> > > > > Snapshots.
> > > > >
> > > > > I understand your concern and it's a valid point, but in practice,
> it's
> > > > not
> > > > > what happens. We can live with the latest released version from npm
> > > > > packages during the dev phase without any problems. From the
> > > > > images/operator perspective, they are yet another package I need to
> > > > install
> > > > > on my container. Like `cat` or `jq`.
> > > > >
> > > > > But we need to sit down and try to understand our boundaries and
> how to
> > > > do
> > > > > integration tests based on them. For example, deploying a devmode
> > > > workflow
> > > > > in Kubernetes and starting a workflow instance via the devui
> console.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 3:54 PM Tiago Bento <
> > > > tiagobentofernandes@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Francisco,
> > > > > >
> > > > > > I agree with you that both reasonings are not antagonistic, as an
> > > > > > antagonistic reasoning in this case would be one that doesn't
> work.
> > > > > > And I believe it is clear now that the initial proposal shared on
> > > this
> > > > > > email thread does work, but it is not the only possibility. From
> the
> > > > > > beginning I said there are alternatives, but I wanted to start
> the
> > > > > > conversation from my point of view, sharing what I think is
> best. We
> > > > > > have to acknowledge, though, IMHO, that the discussions we had
> thus
> > > > > > far cannot be understood as clearly as what was initially laid
> out,
> > > > > > given the lack of details/analysis and a clear execution plan.
> > > > > >
> > > > > > Let me elaborate on top of the 3-step plan you shared.
> > > > > >
> > > > > > 1)
> > > > > > No comment. This should be pretty simple to do.
> > > > > >
> > > > > > 2)
> > > > > > There is no global CI stream to be changed, we would have to
> create
> > > > > > one. And this has serious implications to our contribution model
> for
> > > > > > cross-repo PRs. As I described on the first email of this thread,
> > > > > > Category A repos are configured in several disjoint streams.
> Sending
> > > a
> > > > > > PR to `drools` and `kogito-runtimes` will work great, but
> sending a
> > > PR
> > > > > > to `drools` and `kogito-images`, or `drools` and `optaplanner`
> won't
> > > > > > verify that everything will continue working after the PRs are
> > > merged,
> > > > > > as our PR checks are not prepared to build this combination of
> repos
> > > > > > together. This is a problem, in my view, but I hardly contribute
> to
> > > > > > Category A repos, so I'm assuming things are working fine for
> those
> > > > > > who do. The proposal shared on the first email of this thread
> does
> > > not
> > > > > > change the contribution workflow for any repo of Apache KIE, and
> > > > > > everyone can continue contributing the way they're used to,
> except
> > > for
> > > > > > people contributing to the `kogito-swf-{builder,devmode}`
> images, and
> > > > > > to `kogito-serverless-operator`. On the other hand, having
> > > `kie-tools`
> > > > > > built in the middle of a new global CI stream, would span another
> > > > > > class of problem, which is very closely related to the third
> bullet
> > > > > > point of the plan you shared.
> > > > > >
> > > > > > 3)
> > > > > > Maven has a mechanism to achieve this pseudo-synchronicity
> between
> > > > > > multiple repositories. The mutable SNAPSHOT version, built
> nightly.
> > > It
> > > > > > is not perfect, though, as I'm sure many of us already
> experienced
> > > > > > pulling from the `main` branch of a single repo only to find out
> that
> > > > > > a PR ensemble had been merged a few moments prior, requiring us
> to
> > > > > > rebuild the entire stack, since our local SNAPSHOTs had become
> > > > > > out-of-date. That's what we used to have back in Business Central
> > > > > > (a.k.a. v7) days. Making a `git pull` on a single repo in this
> setup
> > > > > > potentially requires all repos to be pulled and rebuilt. I'm sure
> > > this
> > > > > > still happens sometimes when developing Category A projects.
> > > > > >
> > > > > > NPM packages don't have mutable SNAPSHOTs. Every published NPM
> > > package
> > > > > > is immutable, and it is really cumbersome and error-prone to
> > > integrate
> > > > > > downstream repos with upstream NPM-bound repos, as not having a
> > > > > > lockfile brings all sorts of security and stability problems.
> That's
> > > > > > why monorepos became so popular in the JavaScript ecosystem. This
> > > lack
> > > > > > of a mutable SNAPSHOT mechanism makes depending on NPM artifacts
> > > > > > coming from `kie-tools` really hard. The way I see it, moving
> repos
> > > > > > downstream of `kie-tools` will require everyone to build
> `kie-tools`
> > > > > > anyway, potentially on a daily basis, since it would've then
> become
> > > > > > part of the stack that needs to be built before `kogito-images`
> and
> > > > > > `kogito-serverless-operator`. More than that, since there would
> be no
> > > > > > way to determine what subset of packages of `kie-tools` would
> need to
> > > > > > be built to satisfy downstream references, everyone would have
> to do
> > > a
> > > > > > full build, or handpick individual packages of the monorepo to
> build.
> > > > > >
> > > > > > I hope I was able to offer more insight in the way I see things,
> > > along
> > > > > > with my take on using Maven SNAPSHOTs as the de-facto solution
> for a
> > > > > > poly-repo codebase. I don't think we can escape from the
> complexity
> > > of
> > > > > > our codebase and the nature of the technologies we use, only
> > > > > > accommodate it in the most comfortable place possible, if even
> there
> > > > > > is such a place :)
> > > > > >
> > > > > > Now, there are some things I'd like to say regarding the initial
> > > > > > proposal shared on this email thread.
> > > > > >
> > > > > > I understand you, and others, are concerned about moving stuff
> into
> > > > > > `kie-tools` for some reasons I could gather from your messages.
> I'll
> > > > > > try and list them here, along with my perspective on each of
> them.
> > > > > >
> > > > > > 1. Never being able to move them out of `kie-tools` again.
> > > > > > This is going to be as hard as it would be removing
> > > > > > `kn-plugin-workflow` from it now. So, as you and others mentioned
> > > this
> > > > > > possibility, I assume you understand it to be doable.
> > > > > >
> > > > > > 2. "Heterodoxizing" an orthodox repository
> > > > > > (`kogito-serverless-operator`), potentially harming external
> > > > > > contributions.
> > > > > > Agree with this point. `kie-tools` is one of a kind, built around
> > > > > > front-end tooling with some completely unique in-house
> apparatus. In
> > > > > > my experience, though, there are a multitude of factors that make
> > > > > > people want to contribute to an open source project. Conformance
> to
> > > > > > well-known widespread technologies and tools is just one of them.
> > > > > > Being open about it and writing material to smooth out those
> edges
> > > can
> > > > > > work pretty well. People do not contribute because a codebase is
> > > > > > "pure". People contribute because they care about the project.
> And
> > > I'm
> > > > > > always surprised by the lengths people go to when they want to
> get
> > > > > > involved.
> > > > > >
> > > > > > 3. Disruption to the contribution workflow of those contributing
> to
> > > > > > `kogito-swf-{builder,devmode}` images, and to
> > > > > > `kogito-serverless-operator`.
> > > > > > It is clear to me now that we can't unblock and release Apache
> KIE 10
> > > > > > without impacting anyone, but I hope the first part of this reply
> > > > > > sheds some light on this complicated matter.
> > > > > >
> > > > > > Anyway, that's my attempt to offer a different perspective to
> some of
> > > > > > the problems you expressed concern about, perhaps even making the
> > > > > > initial proposal shared on this email thread be seen with less
> > > > > > uncertainty.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 11:40 AM Francisco Javier Tirado Sarti
> > > > > > <ft...@redhat.com> wrote:
> > > > > > >
> > > > > > > Tiago,
> > > > > > > Unfortunately, my plan is too conceptually simple to write more
> > > than
> > > > I
> > > > > > > already wrote.
> > > > > > > 1) Move kn-plugin-workflow module to operator repo (this
> remove the
> > > > > > > dependency between tools and operator, breaking the loop)
> > > > > > > 2) Change CI global stream to execute tooling repo before
> operator
> > > > repo
> > > > > > > (this seems to take 2 months unless Tristan helps and reduce
> the
> > > time
> > > > > to
> > > > > > 2
> > > > > > > weeks)
> > > > > > > 3) Optionally, and just as a consequence of that CI change, set
> > > > > > > 999-SNAPSHOT version to all poms in all repos (if current
> snapshot
> > > > > > numbers
> > > > > > > turns out to be a problem, in any case this is just
> search-replace)
> > > > > > >
> > > > > > > The current plan is:
> > > > > > > 1) Move everything depending on tools to tools repo, which
> includes
> > > > > > > operator code and examples.
> > > > > > > 2) Change CI of tooling repo to enforce dependencies between
> the
> > > > > existing
> > > > > > > modules there and the newly moved ones (this seems to take 3
> weeks
> > > or
> > > > > > less)
> > > > > > >
> > > > > > > I think rather than asking for a more detailed alternative,
> what
> > > > needs
> > > > > to
> > > > > > > be done is to refine the existing proposal with the feedback
> > > > received.
> > > > > I
> > > > > > do
> > > > > > > not think both proposals are antagonistic. I think that, being
> now
> > > > > clear
> > > > > > we
> > > > > > > have the same overall goal (execute tooling before operator),
> it is
> > > > > just
> > > > > > a
> > > > > > > question of deciding between move more stuff to an already
> > > heterodox
> > > > > > repo,
> > > > > > > coming from repos not as heterodox, plus changing the repo CI
> to
> > > > impose
> > > > > > > certain order between these modules or pull out the the
> operator
> > > > stuff
> > > > > > from
> > > > > > > tool repo and put it inside the operator repo plus changing
> the CI
> > > > > > > handling repos to impose the desired order: first tooling and
> then
> > > > > > operator.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 4:12 PM Tiago Bento <
> > > > > > tiagobentofernandes@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Francisco,
> > > > > > > >
> > > > > > > > 1) `kie-tools` is already a heterodox repo. The reason why I
> > > > proposed
> > > > > > > > my proposal is because it is what I think is the best course
> of
> > > > > action
> > > > > > > > for our community right now. If you think there's a better
> way to
> > > > do
> > > > > > > > it, I think everyone, including me, needs to see a proposal
> with
> > > a
> > > > > > > > clear execution plan with a comparable level of detail and
> > > analysis
> > > > > in
> > > > > > > > regards to disruption of the current state, the required
> effort,
> > > > the
> > > > > > > > contribution workflow for cross-repo PRs, and the release
> process
> > > > > > > > itself. Otherwise, we risk having gaps that each person will
> fill
> > > > in
> > > > > a
> > > > > > > > different way, and IMHO, that's where problems happen. +1 for
> > > > > examples
> > > > > > > > unification, btw :)
> > > > > > > >
> > > > > > > > 2) Ok, and +1 for no categorization.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado
> Sarti
> > > > > > > > <ft...@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > 1) Ok, if that is the case, I do not get why your first
> > > proposal
> > > > > was
> > > > > > not
> > > > > > > > > the one I'm proposing and it is apparently not detailed
> enough.
> > > > To
> > > > > > move
> > > > > > > > > kn-workflow from tooling to operator one and change the
> order
> > > in
> > > > > > which
> > > > > > > > the
> > > > > > > > > repos are being processed. Basically, the problem of the
> > > proposed
> > > > > > > > solution
> > > > > > > > > is that it kind of converts tooling repo into a pretty
> > > heterodox
> > > > > repo
> > > > > > > > > compared with runtimes, drools or operator one. Also once
> > > tooling
> > > > > is
> > > > > > not
> > > > > > > > a
> > > > > > > > > final repo in the overall chain, we can consider moving
> > > examples
> > > > as
> > > > > > the
> > > > > > > > > final one and include tooling showcases there (rather than
> > > > > splitting
> > > > > > > > > examples into examples with tooling and examples without
> > > > tooling).
> > > > > > > > > 2) I think this distinction between A and B is one between
> > > > several
> > > > > > > > possible
> > > > > > > > > categorizations (not much, including no categorization at
> all)
> > > > that
> > > > > > > > > deserves a separate discussion. I will open a separate
> thread
> > > for
> > > > > > that
> > > > > > > > > purpose, since we are not going to change that now and it
> is
> > > not
> > > > > > really
> > > > > > > > > part of the proposal.
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
> > > > > > > > tiagobentofernandes@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco,
> > > > > > > > > >
> > > > > > > > > > 1) That's what this thread is all about... You know I
> don't
> > > > think
> > > > > > it's
> > > > > > > > > > ok. That's why I'm proposing the two images and the
> operator
> > > to
> > > > > > move
> > > > > > > > > > into the `kie-tools` repo, where we can more granularly
> > > control
> > > > > the
> > > > > > > > > > order things are built, thus removing the dependency
> cycle.
> > > > > > > > > >
> > > > > > > > > > 2) Not sure we understand the same thing by "freeze". My
> > > > proposal
> > > > > > is
> > > > > > > > > > that we select a timestamped SNAPSHOT version from
> Category A
> > > > > > repos to
> > > > > > > > > > use as base for a release. We give Category B repos some
> time
> > > > to
> > > > > > > > > > adjust, and then cut the release branches. This can
> happen
> > > > > anytime,
> > > > > > > > > > and no contributions would ever stop because of it. The
> > > > > development
> > > > > > > > > > branches can continue accepting PRs normally, even
> during the
> > > > > > release
> > > > > > > > > > process. Now, if what you're asking is why Category B
> repos
> > > > refer
> > > > > > to
> > > > > > > > > > Category A repos via timestamped SNAPSHOTs, the answer
> is in
> > > my
> > > > > > first
> > > > > > > > > > email. See the paragraph starting with "An important note
> > > here
> > > > is
> > > > > > that
> > > > > > > > > > Category B repositories...".
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado
> > > Sarti
> > > > > > > > > > <ft...@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Tiago
> > > > > > > > > > > There are a couple of simple and straightforward
> questions
> > > > > that
> > > > > > I
> > > > > > > > > > > formulated, but since we both write a lot, it might
> have
> > > been
> > > > > > lost.
> > > > > > > > > > Please
> > > > > > > > > > > let me ask them again.
> > > > > > > > > > > 1) Do you think it is ok that tools repo is executed
> after
> > > > > > > > generation of
> > > > > > > > > > > docker images that are supposed to include those tools
> or
> > > the
> > > > > > > > operator
> > > > > > > > > > that
> > > > > > > > > > > is supposed to deploy such images?
> > > > > > > > > > That's what this thread is all about... You know I'm not
> ok
> > > > with
> > > > > > it,
> > > > > > > > > > that's why I'm proposing the two images and the operator
> to
> > > > move
> > > > > > into
> > > > > > > > > > the `kie-tools` repo, where we can more granularly
> control
> > > the
> > > > > > order
> > > > > > > > > > things are built and remove the dependency cycle.
> > > > > > > > > > > 2) Besides that, although not directly related with the
> > > > current
> > > > > > > > proposal
> > > > > > > > > > we
> > > > > > > > > > > are discussing, I really think there are some
> restrictions
> > > > > taken
> > > > > > for
> > > > > > > > > > > granted that are arbitrary and difficult to sustain on
> > > > strictly
> > > > > > > > technical
> > > > > > > > > > > arguments. For example, the need to freeze the rest of
> the
> > > > > > software
> > > > > > > > > > before
> > > > > > > > > > > tools are generated. Why? We have dependencies between
> > > repos
> > > > > that
> > > > > > > > are not
> > > > > > > > > > > handled that way: Apps depend on runtimes. Runtimes
> depend
> > > on
> > > > > > drools,
> > > > > > > > > > > Operator depend on runtimes,....and we are not freezing
> > > that
> > > > > > repos
> > > > > > > > since
> > > > > > > > > > we
> > > > > > > > > > > are all releasing at the same time. If we are all
> releasing
> > > > at
> > > > > > the
> > > > > > > > same
> > > > > > > > > > > time, what's the rationale behind the freeze?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <
> > > > > > tiagobento@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Glad to see the interest this proposal has gotten,
> and
> > > it's
> > > > > > good to
> > > > > > > > > > > > see some alternatives being drafted here, although
> still
> > > > > > lacking
> > > > > > > > clear
> > > > > > > > > > > > definitions and analysis in regards to disruption,
> > > required
> > > > > > effort,
> > > > > > > > > > > > the release process itself, and history. Of course,
> lots
> > > of
> > > > > > details
> > > > > > > > > > > > and clarity on the execution part would be missing
> too.
> > > > > > > > > > > >
> > > > > > > > > > > > As of this moment, based on what I read here, I'm
> > > assuming
> > > > > that
> > > > > > > > > > > > everyone who participated so far doesn't see the
> initial
> > > > > > proposal
> > > > > > > > as
> > > > > > > > > > > > problematic in terms of feasibility, but some of you
> > > have a
> > > > > > > > preference
> > > > > > > > > > > > not to go with it, because it is "wrong", and
> apparently
> > > > > > because it
> > > > > > > > > > > > would "jeopardize the evolution of the project".
> Reading
> > > > > these
> > > > > > last
> > > > > > > > > > > > words made me a little sad, to be honest. But I can
> deal
> > > > with
> > > > > > it :)
> > > > > > > > > > > >
> > > > > > > > > > > > Please let's try and keep the discussion as
> objective as
> > > > > > possible.
> > > > > > > > > > > > "Right" and "wrong" are too subjective for this kind
> of
> > > > > > > > conversation.
> > > > > > > > > > > >
> > > > > > > > > > > > Now, being practical, unless there are clear
> arguments
> > > > based
> > > > > on
> > > > > > > > facts
> > > > > > > > > > > > and objective concepts that invalidate the initial
> > > proposal
> > > > > > shared
> > > > > > > > on
> > > > > > > > > > > > this email, it seems to me that it is currently the
> only
> > > > > viable
> > > > > > > > > > > > proposal we have for unblocking and releasing Apache
> KIE
> > > > 10.
> > > > > Of
> > > > > > > > > > > > course, if we end up seeing an alternative proposal
> with
> > > > > enough
> > > > > > > > > > > > details and a clear execution plan, I think then
> we'll be
> > > > in
> > > > > a
> > > > > > very
> > > > > > > > > > > > good position to choose from multiple options!
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <
> > > > > > alex@porcelli.me>
> > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Francisco and Gabriele,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I understand and acknowledge your desire to find
> the
> > > > > “right”
> > > > > > > > solution
> > > > > > > > > > > > > instead to work on a temporary “patch” - however
> > > without
> > > > a
> > > > > > > > detailed
> > > > > > > > > > > > > proposal I don’t think we can properly evaluate the
> > > > impact
> > > > > of
> > > > > > > > your
> > > > > > > > > > > > > suggestion.
> > > > > > > > > > > > >
> > > > > > > > > > > > > When I spoke with different SMEs that included
> tools
> > > and
> > > > > CI,
> > > > > > the
> > > > > > > > > > > > > guesstimate for making the necessary changes on CI
> and
> > > > > > codebase
> > > > > > > > to
> > > > > > > > > > > > > basically have images and operators in the end of
> the
> > > > build
> > > > > > > > chain is
> > > > > > > > > > > > > something like 2 months of effort. Another impact
> that
> > > > > needs
> > > > > > to
> > > > > > > > be
> > > > > > > > > > > > > discussed is that KIE Tools repo had to be
> injected in
> > > > the
> > > > > > > > middle of
> > > > > > > > > > all
> > > > > > > > > > > > > pipelines - forcing all PR checks and nightlies to
> > > build
> > > > > all
> > > > > > > > repos
> > > > > > > > > > (PR
> > > > > > > > > > > > > checks will likely take 12+ hours… I even heard
> that it
> > > > > > could be
> > > > > > > > > > even 24
> > > > > > > > > > > > > hours).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Based on the input above, I think it’s quite risk
> to
> > > move
> > > > > in
> > > > > > such
> > > > > > > > > > > > direction
> > > > > > > > > > > > > without a more detailed plan… because 2 months
> could be
> > > > > > turned
> > > > > > > > > > easily in
> > > > > > > > > > > > 6!
> > > > > > > > > > > > > And this is exactly what happened when we guessed
> that
> > > > > > moving to
> > > > > > > > > > Apache
> > > > > > > > > > > > > would take no more than 3 months. But here we are.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I really strongly suggest that we focus on a
> release
> > > that
> > > > > > could
> > > > > > > > be
> > > > > > > > > > > > > achievable in less than a month from now, and we -
> > > after
> > > > > > release
> > > > > > > > -
> > > > > > > > > > have a
> > > > > > > > > > > > > in depth discussion about the overall codebase and
> ci
> > > > > > > > organization.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > > my suggestion is to move the building of all
> docker
> > > > > images,
> > > > > > > > from
> > > > > > > > > > > > whatever
> > > > > > > > > > > > > > repo (kogito-apps, kie-tools) in a different,
> > > > downstream
> > > > > > repo,
> > > > > > > > to
> > > > > > > > > > be
> > > > > > > > > > > > > > invoked after all the others.
> > > > > > > > > > > > > > I'm not sure if this would solve all the issues,
> and
> > > > > since
> > > > > > I
> > > > > > > > could
> > > > > > > > > > not
> > > > > > > > > > > > > > enter in the details of all the involved code, my
> > > > > > suggestion
> > > > > > > > may
> > > > > > > > > > be too
> > > > > > > > > > > > > > naive.
> > > > > > > > > > > > > > Having spent almost all of the last year in CI,
> I
> > > may
> > > > > say
> > > > > > > > that, at
> > > > > > > > > > > > least
> > > > > > > > > > > > > > for the kie-tools repo, removing the image build
> step
> > > > > from
> > > > > > it
> > > > > > > > > > should
> > > > > > > > > > > > not be
> > > > > > > > > > > > > > too difficult (since it is an issue we already
> faced
> > > > and
> > > > > > > > solved).
> > > > > > > > > > > > > > If, with "detailed proposal", you mean a complete
> > > list
> > > > of
> > > > > > all
> > > > > > > > > > modules
> > > > > > > > > > > > to be
> > > > > > > > > > > > > > moved and dependency refactoring, of course I
> can not
> > > > > > provide
> > > > > > > > it
> > > > > > > > > > right
> > > > > > > > > > > > now.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Anyway, I share the concern from Francisco:
> undoing
> > > > > > something
> > > > > > > > is
> > > > > > > > > > almost
> > > > > > > > > > > > > > always harder than doing it "rightly" from
> scratch...
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43
> Francisco
> > > > Javier
> > > > > > > > Tirado
> > > > > > > > > > Sarti
> > > > > > > > > > > > <
> > > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I do not think estimations should be the only
> > > driver
> > > > to
> > > > > > make
> > > > > > > > a
> > > > > > > > > > > > decision,
> > > > > > > > > > > > > > > especially when the current proposal is
> > > conceptually
> > > > > > > > incompatible
> > > > > > > > > > > > with
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > multi repo approach that is taken elsewhere in
> the
> > > > > > project.
> > > > > > > > > > > > > > > Given my knowledge of the CI it is nearly
> > > impossible
> > > > > for
> > > > > > me
> > > > > > > > to
> > > > > > > > > > give
> > > > > > > > > > > > a
> > > > > > > > > > > > > > fair
> > > > > > > > > > > > > > > estimate of how much it might take to achieve
> step
> > > 2)
> > > > > of
> > > > > > my
> > > > > > > > > > previous
> > > > > > > > > > > > > > e-mail
> > > > > > > > > > > > > > > . It might take a while or it might be pretty
> easy
> > > > > after
> > > > > > > > all, I
> > > > > > > > > > don't
> > > > > > > > > > > > > > > really know, but I think it will be a good
> idea if
> > > > > some
> > > > > > of
> > > > > > > > the
> > > > > > > > > > > > experts
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > CI in the team (the ones that set up the
> pipeline,
> > > > > which
> > > > > > was
> > > > > > > > a
> > > > > > > > > > huge
> > > > > > > > > > > > > > > achievement) give an estimate, not me.
> Estimating
> > > > how
> > > > > > much
> > > > > > > > it
> > > > > > > > > > takes
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > merge two existing repos (without altering CI)
> is
> > > > > easier,
> > > > > > > > but it
> > > > > > > > > > > > does not
> > > > > > > > > > > > > > > mean we are doing the right thing.
> > > > > > > > > > > > > > > My main concern is that it will be very
> difficult
> > > for
> > > > > me
> > > > > > to
> > > > > > > > > > explain
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > someone that arrives new to the team, that
> having
> > > > > > experts on
> > > > > > > > CI
> > > > > > > > > > on
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > team, we decided to merge two repos (once
> merged,
> > > it
> > > > > > would be
> > > > > > > > > > rather
> > > > > > > > > > > > > > > difficult to unmerge) rather than fix the CI,
> > > because
> > > > > of
> > > > > > > > > > expediency.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli
> <
> > > > > > > > > > porcelli@apache.org>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Please take the time to make the more in
> depth
> > > > > analysis
> > > > > > > > needed
> > > > > > > > > > and
> > > > > > > > > > > > > > > provide
> > > > > > > > > > > > > > > > a more detailed plan… so we - as community-
> can
> > > > > > evaluate
> > > > > > > > the
> > > > > > > > > > size
> > > > > > > > > > > > of
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > effort. In the conceptual level you shared
> it’s
> > > > near
> > > > > > > > > > impossible to
> > > > > > > > > > > > > > > estimate
> > > > > > > > > > > > > > > > the size of the effort and compare with the
> > > current
> > > > > > > > proposal.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco
> Javier
> > > > > Tirado
> > > > > > > > Sarti <
> > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think I already did a high level
> proposal.
> > > > > > > > > > > > > > > > > 1) Remove all dependencies from tooling to
> > > > images,
> > > > > > so
> > > > > > > > images
> > > > > > > > > > > > depend
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > tooling but tooling does not depend on
> images.
> > > > > > > > > > > > > > > > > 2) Then change CI to deal with tooling repo
> > > > before
> > > > > > > > dealing
> > > > > > > > > > with
> > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > > repo.
> > > > > > > > > > > > > > > > > I understand that CI details are tricky and
> > > since
> > > > > > I'm not
> > > > > > > > > > > > familiar
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > CI
> > > > > > > > > > > > > > > > > in any way, I barely can make a low level
> > > design,
> > > > > > but we
> > > > > > > > do
> > > > > > > > > > not
> > > > > > > > > > > > need
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > fix
> > > > > > > > > > > > > > > > > everything, just achieve 2), a change of
> > > > > compilation
> > > > > > > > order.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex
> Porcelli
> > > <
> > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > You may not like or understand why the
> > > current
> > > > > > state of
> > > > > > > > > > the CI
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > > that… actually has been in Red Hat and
> has
> > > been
> > > > > > > > replicated
> > > > > > > > > > in
> > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > used to be….
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > But the fact is that this is the current
> > > > reality.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you disagree with the current plan,
> please
> > > > > > provide a
> > > > > > > > > > > > detailed
> > > > > > > > > > > > > > > > > > alternative so we, as community, can
> better
> > > > > > evaluate
> > > > > > > > the
> > > > > > > > > > pros
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > cons
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > each proposal.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I think it’s also fair to say that, post
> 10
> > > > > > release we
> > > > > > > > > > need to
> > > > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > > much
> > > > > > > > > > > > > > > > > > in depth discussion about how our
> codebase is
> > > > > > > > organized,
> > > > > > > > > > it’s
> > > > > > > > > > > > clear
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > it’s not working.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele
> > > > Cardosi
> > > > > <
> > > > > > > > > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > > > > > > > > I also have the impression that the
> > > "images"
> > > > > (if
> > > > > > we
> > > > > > > > are
> > > > > > > > > > > > talking
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > docker
> > > > > > > > > > > > > > > > > > > images) should be the very last one to
> be
> > > > > built,
> > > > > > in a
> > > > > > > > > > > > standalone
> > > > > > > > > > > > > > > > repo.
> > > > > > > > > > > > > > > > > > > That way, they may "combine" artifacts
> that
> > > > are
> > > > > > > > built in
> > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > > repos,
> > > > > > > > > > > > > > > > > > > regardless of the order in which those
> are
> > > > > built.
> > > > > > > > > > > > > > > > > > > Moving them out of all the repos
> > > > > > > > (kogito-apps/kie-tools)
> > > > > > > > > > > > maybe
> > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > > > > > > > > (I also think there are some
> statements of
> > > > > > > > undisputable
> > > > > > > > > > needs
> > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > > > > > > > > Anyway, this latter point is for
> longer,
> > > > > > following,
> > > > > > > > > > > > discussion.)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore
> 11:23
> > > > > > Francisco
> > > > > > > > Javier
> > > > > > > > > > > > Tirado
> > > > > > > > > > > > > > > > Sarti
> > > > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > > > > > > > > There are two assumptions that
> deserve
> > > > > further
> > > > > > > > > > discussion:
> > > > > > > > > > > > > > > > > > > > 1) That tool has to be the last to
> build.
> > > > > why?
> > > > > > it
> > > > > > > > does
> > > > > > > > > > not
> > > > > > > > > > > > have
> > > > > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > > > > > to build final images after
> everything
> > > else
> > > > > has
> > > > > > > > been
> > > > > > > > > > > > built?-
> > > > > > > > > > > > > > > > > > > > 2) That the impact (in terms of
> effort
> > > now)
> > > > > on
> > > > > > > > fixing
> > > > > > > > > > CI is
> > > > > > > > > > > > > > > bigger
> > > > > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > impact (long term consequences) of
> > > > > > consolidating
> > > > > > > > two
> > > > > > > > > > > > unrelated
> > > > > > > > > > > > > > > > piece
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex
> > > > > Porcelli
> > > > > > <
> > > > > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > This was discussed as an
> alternative
> > > > > > solution,
> > > > > > > > > > however
> > > > > > > > > > > > it has
> > > > > > > > > > > > > > > > major
> > > > > > > > > > > > > > > > > > > > impact
> > > > > > > > > > > > > > > > > > > > > on CI and there’s also the fact
> Tool
> > > has
> > > > > been
> > > > > > > > always
> > > > > > > > > > the
> > > > > > > > > > > > last
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > build
> > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > has no Snapshot published
> (actually in
> > > > > > JavaScript
> > > > > > > > > > world
> > > > > > > > > > > > there
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > So, based on our evaluation… the
> > > proposal
> > > > > > here
> > > > > > > > is the
> > > > > > > > > > > > least
> > > > > > > > > > > > > > > > > > disruptive
> > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > will take less time to unblock the
> > > > release.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM
> > > Francisco
> > > > > > Javier
> > > > > > > > > > Tirado
> > > > > > > > > > > > > > Sarti <
> > > > > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > After kie-tools, sorry. I think
> we
> > > are
> > > > > not
> > > > > > > > > > embracing
> > > > > > > > > > > > the
> > > > > > > > > > > > > > fact
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > > kogito-images depend on
> kie-tools,
> > > > > because
> > > > > > we
> > > > > > > > want
> > > > > > > > > > > > those
> > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM
> > > > > Francisco
> > > > > > > > Javier
> > > > > > > > > > > > Tirado
> > > > > > > > > > > > > > > Sarti
> > > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > > > > > > > > It can be an alternative
> solution
> > > to
> > > > > move
> > > > > > > > > > > > > > > kn-plugin-workflow
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > kogito-images (so there is not
> > > longer
> > > > > > > > dependency
> > > > > > > > > > from
> > > > > > > > > > > > > > tools
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > > then build kogito-images after
> > > > > > kogito-tools?
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at
> 11:01 AM
> > > > > Enrique
> > > > > > > > Gonzalez
> > > > > > > > > > > > > > Martinez
> > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48,
> Pere
> > > > > > Fernandez
> > > > > > > > > > (apache)
> > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >> > I say +1 in order to move
> > > forward
> > > > > with
> > > > > > > > the 10.
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at
> 21:45,
> > > Alex
> > > > > > > > Porcelli <
> > > > > > > > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> > > I spent the last day or so
> > > > working
> > > > > > > > closely
> > > > > > > > > > with
> > > > > > > > > > > > > > Tiago,
> > > > > > > > > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > > > > > > > > >> > > options and getting
> deeper on
> > > > the
> > > > > > > > impact and
> > > > > > > > > > > > > > > evaluating
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > > > > > > > > >> > > procedure steps required.
> I
> > > > agree
> > > > > > with
> > > > > > > > the
> > > > > > > > > > > > proposal
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > most
> > > > > > > > > > > > > > > > > > > > > > >> > > viable option for
> unblocking
> > > the
> > > > > 10
> > > > > > > > release
> > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > reasonable
> > > > > > > > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at
> > > 3:45 PM
> > > > > > Tiago
> > > > > > > > Bento
> > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Unfortunately, I can't
> do a
> > > > > tl;dr
> > > > > > this
> > > > > > > > > > time,
> > > > > > > > > > > > as
> > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > > > matter
> > > > > > > > > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > This email will take
> you <
> > > 20
> > > > > > minutes
> > > > > > > > to
> > > > > > > > > > read,
> > > > > > > > > > > > > > > > according
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> https://thereadtime.com/.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > As you may have
> followed on
> > > a
> > > > > > separate
> > > > > > > > > > thread
> > > > > > > > > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > >
> https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > > > > > > > > >> > > > many of us were working
> > > > towards
> > > > > > > > removing a
> > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > > > > > > >> > > > currently present
> between
> > > > > > > > `kogito-apps`
> > > > > > > > > > and
> > > > > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > > As
> > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > >> > > > progressed towards a
> > > solution,
> > > > > we
> > > > > > kept
> > > > > > > > > > > > finding the
> > > > > > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > > > > > > > > >> > > > pop up somewhere else.
> I'll
> > > > do a
> > > > > > > > > > breakdown of
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > things
> > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Right now, even though
> we
> > > > > started
> > > > > > the
> > > > > > > > > > effort
> > > > > > > > > > > > to
> > > > > > > > > > > > > > move
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > > > > > > > >> > > > UI modules to
> `kie-tools`,
> > > we
> > > > > > haven't
> > > > > > > > been
> > > > > > > > > > > > able to
> > > > > > > > > > > > > > > do
> > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > yet,
> > > > > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > > > > > > > > >> > > > been busy upgrading KIE
> > > Tools
> > > > to
> > > > > > Java
> > > > > > > > 17,
> > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > 3.9.6,
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with
> > > Kogito
> > > > > > Runtimes
> > > > > > > > > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > > > > >> > > > effort was concluded
> this
> > > > > Monday,
> > > > > > with
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >
> > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > > > > > > > > .
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > The current scenario we
> have
> > > > is:
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > > > >> > > > |==> 02.
> > > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > > > >> > > > L |
> > > > > > > > ==========================
> > > > > > > > > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > > > > > > > >
> incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > > > >> > > > |==> 07.
> > > > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > > `kie-tools`/extended-services
> > > > > > > > > > > > depends
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > > > > > > > >
> `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`/{many
> packages}
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > After moving the
> Quarkus Dev
> > > > UIs
> > > > > > to
> > > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > would've
> > > > > > > > > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > > > >> > > > C |
> > > > > > =====================
> > > > > > > > > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > > > > > > > >
> incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > > > >> > > > E |==> 07.
> > > > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > > > > > depends
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > > > > > > > > depends
> > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > After moving the
> > > > > > `kogito-swf-devmode`
> > > > > > > > > > image to
> > > > > > > > > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > > > >> > > > 04.
> > > > > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > > > >> > > > Y |
> > > > > > =====================
> > > > > > > > > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > > > > > > > >
> incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > > > >> > > > L |==> 07.
> > > > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > > > > > depends
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > `kogito-serverless-operator`
> > > > > > > > > > > > depends
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Clearly, we have a much
> > > bigger
> > > > > > problem
> > > > > > > > > > than a
> > > > > > > > > > > > > > simple
> > > > > > > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > After multiple
> conversations
> > > > > with
> > > > > > a
> > > > > > > > lot of
> > > > > > > > > > > > people,
> > > > > > > > > > > > > > > > it's
> > > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > > > > >> > > > hard coming up with a
> simple
> > > > > > solution
> > > > > > > > that
> > > > > > > > > > > > makes
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > possible
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > > > > > > > > >> > > > Apache KIE in one shot,
> > > while
> > > > > > > > preserving
> > > > > > > > > > the
> > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > everyone
> > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > >> > > > contributing to the
> multiple
> > > > > > > > repositories
> > > > > > > > > > we
> > > > > > > > > > > > have.
> > > > > > > > > > > > > > > > More
> > > > > > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > > > > > > > > >> > > > while making this
> > > assessment,
> > > > I
> > > > > > found
> > > > > > > > more
> > > > > > > > > > > > > > problems
> > > > > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > > > > > >> > > > perspective, block
> Apache
> > > KIE
> > > > > 10.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > In light of that
> difficulty,
> > > > I'm
> > > > > > > > coming
> > > > > > > > > > > > forward
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > >> > > > the Apache KIE release
> > > > process,
> > > > > > so we
> > > > > > > > can
> > > > > > > > > > use
> > > > > > > > > > > > > > > Apache's
> > > > > > > > > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > >> > > > have a slower-paced,
> > > in-depth
> > > > > > debate
> > > > > > > > about
> > > > > > > > > > > > this
> > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > I'll lay out my entire
> > > > > perspective
> > > > > > > > about
> > > > > > > > > > the
> > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > > > > > situation
> > > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > > > > > > > > >> > > > codebase, as well as
> > > problems
> > > > I
> > > > > > can
> > > > > > > > > > currently
> > > > > > > > > > > > see.
> > > > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > > > > > start
> > > > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > > > > > > > >> > > > analysis of the
> repositories
> > > > and
> > > > > > their
> > > > > > > > > > > > purposes,
> > > > > > > > > > > > > > > point
> > > > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > > > >> > > > problems that I believe
> are
> > > > > > blocking
> > > > > > > > our
> > > > > > > > > > 10
> > > > > > > > > > > > > > release,
> > > > > > > > > > > > > > > > > > explain
> > > > > > > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > > > > > >> > > > proposal and discuss
> some
> > > > > > > > consequences to
> > > > > > > > > > > > what I'm
> > > > > > > > > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, &
> > > > KOGITO
> > > > > > > > (count:
> > > > > > > > > > 11)
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > incubator-kie-kogito-pipelines @
> > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @
> > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-optaplanner
> > > @
> > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > incubator-kie-optaplanner-quickstarts @
> > > > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-kogito-runtimes
> > > > > @
> > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-apps
> > > @
> > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-kogito-examples
> > > > > @
> > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-images
> > > > @
> > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > incubator-kie-kogito-serverless-operator @
> > > > > > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-docs
> > > @
> > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @
> > > > > > `main-kogito`
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @
> > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > incubator-kie-kogito-benchmarks
> > > > > > @
> > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-benchmarks @
> > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @
> > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > (Issues only, README
> > > > should
> > > > > be
> > > > > > > > > > updated @
> > > > > > > > > > > > > > `main`.
> > > > > > > > > > > > > > > > > Same
> > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-kogito-website @
> > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > (The Kogito website.
> > > > > Develop &
> > > > > > > > deploy
> > > > > > > > > > at
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-website
> @
> > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > (The KIE website.
> > > Develop
> > > > @
> > > > > > > > `main`.
> > > > > > > > > > Push @
> > > > > > > > > > > > > > > > `deploy`
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-online
> > > > @
> > > > > > > > `gh-pages`
> > > > > > > > > > > > > > > > > > > > > > >> > > > (GitHub pages used
> to
> > > host
> > > > > > > > > > > > sandbox.kie.org
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > incubator-kie-kogito-online-staging
> > > > > > > > @
> > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > > >> > > > (Same as above, but
> for
> > > > > manual
> > > > > > > > sanity
> > > > > > > > > > > > checks
> > > > > > > > > > > > > > > > during
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > I grouped the
> repositories
> > > by
> > > > > > > > category,
> > > > > > > > > > and
> > > > > > > > > > > > listed
> > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > > in a
> > > > > > > > > > > > > > > > > > > > > > >> > > > topological order. Keep
> in
> > > > mind
> > > > > > that
> > > > > > > > when
> > > > > > > > > > > > > > flattening
> > > > > > > > > > > > > > > > > out a
> > > > > > > > > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > > > > > > > > >> > > > are multiple
> possibilities.
> > > > For
> > > > > > > > example,
> > > > > > > > > > > > > > OptaPlanner
> > > > > > > > > > > > > > > > > > > could've
> > > > > > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > > > >> > > > placed in any position
> after
> > > > > > Drools.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Category A repos are
> what
> > > I've
> > > > > > been
> > > > > > > > > > referring
> > > > > > > > > > > > to
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of
> course
> > > > > > > > OptaPlanner
> > > > > > > > > > is
> > > > > > > > > > > > inside
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > > > > >> > > > way these repositories
> > > > reference
> > > > > > each
> > > > > > > > > > other
> > > > > > > > > > > > are
> > > > > > > > > > > > > > > > through
> > > > > > > > > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More
> > > specifically,
> > > > > the
> > > > > > > > > > 999-SNAPSHOT
> > > > > > > > > > > > > > > > version.
> > > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > > > > > > > > >> > > > is well-known to the
> team,
> > > and
> > > > > > > > although
> > > > > > > > > > > > flawed for
> > > > > > > > > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > > > > > > > > >> > > > and disruptive for
> people in
> > > > > many
> > > > > > > > > > different
> > > > > > > > > > > > time
> > > > > > > > > > > > > > > > zones,
> > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > > > > > > >> > > > very comfortable for
> > > everyone
> > > > to
> > > > > > work
> > > > > > > > > > with, I
> > > > > > > > > > > > > > > assume.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Contributions made to
> > > > Category A
> > > > > > have
> > > > > > > > some
> > > > > > > > > > > > > > dedicated
> > > > > > > > > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > > > > > > > >> > > > are, at least to some
> > > extent,
> > > > > > able to
> > > > > > > > > > build
> > > > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > > > > > > >> > > > and verify that the
> codebase
> > > > > will
> > > > > > > > continue
> > > > > > > > > > > > working
> > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > expected
> > > > > > > > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > > > > > >> > > > they're all merged. From
> > > what
> > > > I
> > > > > > could
> > > > > > > > > > gather,
> > > > > > > > > > > > > > there
> > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > > > >> > > > "sub-streams" currently
> > > > > > configured for
> > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > PRs.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > > > > > > > > >> > > > - drools,
> kogito-runtimes,
> > > > > > > > kogito-apps,
> > > > > > > > > > and
> > > > > > > > > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > > > > > > > > >> > > > - optaplanner, and
> > > > > > > > optaplanner-quickstarts
> > > > > > > > > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > > > > > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > This means that sending
> > > > > cross-repo
> > > > > > > > PRs to
> > > > > > > > > > any
> > > > > > > > > > > > > > > > > combination
> > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > > > > > >> > > > that are not part of the
> > > same
> > > > > > > > "sub-stream"
> > > > > > > > > > > > cannot
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > verified
> > > > > > > > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > > > > > > > >> > > > merging, making our
> > > > contribution
> > > > > > model
> > > > > > > > > > > > dependent
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > individual
> > > > > > > > > > > > > > > > > > > > > > >> > > > contributors building
> stuff
> > > on
> > > > > > their
> > > > > > > > > > machines
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > verify
> > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > > > > > > >> > > > Note that I'm not that
> > > > familiar
> > > > > > with
> > > > > > > > these
> > > > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > > > > > > > >> > > > someone correct me if
> I'm
> > > > wrong.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Category B repos are
> what
> > > I've
> > > > > > been
> > > > > > > > > > referring
> > > > > > > > > > > > to
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > > > > > > >> > > > stream. The first repo
> there
> > > > is
> > > > > a
> > > > > > > > template
> > > > > > > > > > > > > > > repository
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > > > > > > > > >> > > > people starting projects
> > > from
> > > > > > scratch
> > > > > > > > on
> > > > > > > > > > KIE
> > > > > > > > > > > > > > > Sandbox,
> > > > > > > > > > > > > > > > > > > similar
> > > > > > > > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > > > > > >> > > > Maven archetype, if you
> > > will.
> > > > > The
> > > > > > > > other
> > > > > > > > > > one
> > > > > > > > > > > > is the
> > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > Tools
> > > > > > > > > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > > > > > > > > >> > > > a polyglot monorepo with
> > > > `pnpm`
> > > > > > as its
> > > > > > > > > > build
> > > > > > > > > > > > > > system.
> > > > > > > > > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > > > > > >> > > > Tools hosts Java
> libraries
> > > and
> > > > > > apps,
> > > > > > > > > > > > TypeScript
> > > > > > > > > > > > > > > > > libraries
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > > > > > > > > >> > > > apps, Docker images, and
> > > Helm
> > > > > > charts.
> > > > > > > > The
> > > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > > >> > > > configured to work with
> > > sparse
> > > > > > > > checkouts
> > > > > > > > > > and
> > > > > > > > > > > > can
> > > > > > > > > > > > > > do
> > > > > > > > > > > > > > > > > > partial
> > > > > > > > > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > > > > > > > > >> > > > Category B repos refer
> to
> > > > > > Category A
> > > > > > > > repos
> > > > > > > > > > > > through
> > > > > > > > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new
> > > > > > mechanism we
> > > > > > > > > > recently
> > > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > > > > > >> > > > build and publish
> immutable,
> > > > > > > > persistent
> > > > > > > > > > > > artifacts
> > > > > > > > > > > > > > > > under
> > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > > > > > > > >> > > > following the
> > > > > > 999-YYYYMMDD-SNAPSHOT
> > > > > > > > > > format,
> > > > > > > > > > > > > > > published
> > > > > > > > > > > > > > > > > > weekly
> > > > > > > > > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > > > > > > > > >> > > > Sunday night.
> Timestamped
> > > > > > SNAPSHOTs
> > > > > > > > are an
> > > > > > > > > > > > > > evolution
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > > > > > > >> > > > releases, as we're now
> > > > targeting
> > > > > > one
> > > > > > > > > > release
> > > > > > > > > > > > for
> > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > > > > > > > >> > > > we can't have Kogito
> > > releases
> > > > > > anymore.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > An important note here
> is
> > > that
> > > > > > > > Category B
> > > > > > > > > > > > > > > repositories
> > > > > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > > > >> > > > historically kept out
> of any
> > > > > > > > automations
> > > > > > > > > > we
> > > > > > > > > > > > used
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > have,
> > > > > > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > > > > > > >> > > > when Kogito started and
> we
> > > had
> > > > > the
> > > > > > > > > > Business
> > > > > > > > > > > > > > Central
> > > > > > > > > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > > > > > > > > >> > > > still going on. For this
> > > > reason,
> > > > > > > > Category
> > > > > > > > > > B
> > > > > > > > > > > > > > projects
> > > > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > > > > > > > > >> > > > their own automations,
> based
> > > > on
> > > > > > GitHub
> > > > > > > > > > > > Actions.
> > > > > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > > > > > > > > >> > > > always depended on
> Category
> > > A
> > > > > > repos
> > > > > > > > using
> > > > > > > > > > > > fixed
> > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > If
> > > > > > > > > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > > > > > > > > >> > > > B repos have had adopted
> > > > mutable
> > > > > > > > > > SNAPSHOTs,
> > > > > > > > > > > > > > breaking
> > > > > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > >> > > > Category A repositories
> > > > would've
> > > > > > had
> > > > > > > > the
> > > > > > > > > > > > potential
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > break
> > > > > > > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > > > > > > >> > > > silently, leaving
> Category B
> > > > > with
> > > > > > a
> > > > > > > > broken
> > > > > > > > > > > > > > > development
> > > > > > > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > >> > > > introducing unpleasant
> > > > surprises
> > > > > > for
> > > > > > > > > > > > maintainers
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > > > > > > > > >> > > > as historically
> Category A
> > > > > > > > contributors
> > > > > > > > > > were
> > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > familiar
> > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Contributions made to
> > > > Category B
> > > > > > > > repos go
> > > > > > > > > > > > through
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > > > > > > > > >> > > > workflow that builds the
> > > > > relevant
> > > > > > > > part of
> > > > > > > > > > the
> > > > > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > > > > > >> > > > the changes introduced.
> > > > Changes
> > > > > > made
> > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > > > > > > pipeline
> > > > > > > > > > > > > > > > > > itself
> > > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > > > > > > > > >> > > > picked up as part of
> PRs,
> > > > > > allowing us
> > > > > > > > to
> > > > > > > > > > do
> > > > > > > > > > > > things
> > > > > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > > > > > > > > >> > > > bumping the Node.js
> version,
> > > > for
> > > > > > > > example.
> > > > > > > > > > More
> > > > > > > > > > > > > > > > > > importantly,
> > > > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > > > > > > > > >> > > > us to upgrade the
> repository
> > > > to
> > > > > a
> > > > > > new
> > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > > > > > > >> > > > with the changes
> necessary
> > > to
> > > > > > make it
> > > > > > > > stay
> > > > > > > > > > > > green.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > This setup, however,
> makes
> > > it
> > > > > > > > impossible
> > > > > > > > > > to
> > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > > > > > > >> > > > involving Category A and
> > > > > Category
> > > > > > B
> > > > > > > > > > > > > > simultaneously,
> > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Category C repos are
> kind of
> > > > > > floating
> > > > > > > > > > around,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > > > > > > >> > > > there's much activity
> going
> > > on
> > > > > > there.
> > > > > > > > > > > > Regardless,
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > >> > > > Apache KIE, they will be
> > > part
> > > > of
> > > > > > our
> > > > > > > > > > release,
> > > > > > > > > > > > so I
> > > > > > > > > > > > > > > > > listed
> > > > > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > > > > > > >> > > > to take them into
> > > > consideration
> > > > > > too.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Category D is self
> > > > explanatory.
> > > > > > > > There's
> > > > > > > > > > only
> > > > > > > > > > > > one
> > > > > > > > > > > > > > > repo
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > has
> > > > > > > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > > > > > > >> > > > been marked for being
> > > > archived.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Category E are repos
> that do
> > > > not
> > > > > > host
> > > > > > > > code
> > > > > > > > > > > > > > directly,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > > > > > > > > >> > > > organizational
> entities, or
> > > > host
> > > > > > > > websites,
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > currently
> > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > > > > > > > > >> > > > of any pipelines we
> have.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > This lack of unification
> > > > between
> > > > > > > > Category
> > > > > > > > > > A
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > > > is,
> > > > > > > > > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > > > > > > > > >> > > > what allowed us to
> introduce
> > > > the
> > > > > > > > infamous
> > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools` and
> > > `kogito-apps`,
> > > > > > which
> > > > > > > > we
> > > > > > > > > > now
> > > > > > > > > > > > can
> > > > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > > > > > > > > >> > > > dependency between
> Category
> > > A
> > > > > and
> > > > > > > > > > Category B.
> > > > > > > > > > > > The
> > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > > > see
> > > > > > > > > > > > > > > > > > > > it,
> > > > > > > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > > > > >> > > > had a single pipeline,
> > > > building
> > > > > > > > everything
> > > > > > > > > > > > from
> > > > > > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws
> > > > would've
> > > > > > never
> > > > > > > > > > been
> > > > > > > > > > > > > > > > introduced,
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > >> > > > wouldn't be having this
> huge
> > > > > > problem
> > > > > > > > in
> > > > > > > > > > our
> > > > > > > > > > > > hands
> > > > > > > > > > > > > > > > right
> > > > > > > > > > > > > > > > > > now.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > My proposal for the
> Apache
> > > KIE
> > > > > > release
> > > > > > > > > > process
> > > > > > > > > > > > > > sees
> > > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > > > > lack
> > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > >> > > > unification as a central
> > > > > problem,
> > > > > > not
> > > > > > > > > > only for
> > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > > > >> > > > particular, but for the
> > > > > community
> > > > > > as a
> > > > > > > > > > whole.
> > > > > > > > > > > > It
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > > belief
> > > > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > > > > >> > > > are all under the same
> roof,
> > > > and
> > > > > > that
> > > > > > > > no
> > > > > > > > > > > > > > > contribution
> > > > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > > > > >> > > > allowed to break any
> part of
> > > > our
> > > > > > > > codebase.
> > > > > > > > > > > > With
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > > > > > > > > >> > > > of code, and hopefully
> > > number
> > > > of
> > > > > > > > > > contributors
> > > > > > > > > > > > too,
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > > > > > > > > >> > > > counting on "common
> sense"
> > > to
> > > > > > avoid
> > > > > > > > > > breaking
> > > > > > > > > > > > > > things.
> > > > > > > > > > > > > > > > > We're
> > > > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > > > > > > > > >> > > > after all, and it is
> our job
> > > > to
> > > > > > have
> > > > > > > > > > > > mechanisms in
> > > > > > > > > > > > > > > > place
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > > > > > > >> > > > from unwillingly making
> > > > > mistakes.
> > > > > > > > > > Especially
> > > > > > > > > > > > when
> > > > > > > > > > > > > > > > these
> > > > > > > > > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > > > > > > > > >> > > > impact on parts of the
> > > > codebase
> > > > > > that
> > > > > > > > we,
> > > > > > > > > > > > > > > individually,
> > > > > > > > > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE
> RIGHT
> > > > NOW
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @
> > > > > > `kogito-apps`
> > > > > > > > > > depending
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito
> SWF
> > > > > images
> > > > > > @
> > > > > > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools
> > > `0.32.0`.
> > > > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > P3. DashBuilder @
> > > `kie-tools`
> > > > > > > > depending on
> > > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at
> > > > version
> > > > > > > > > > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > P4. Multiple packages @
> > > > > > `kogito-apps`
> > > > > > > > > > > > depending on
> > > > > > > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > > > > > > >> > > > Explainability
> > > `1.22.1.Final`.
> > > > > > > > > > > > > > > > > > > > > > >> > > > * This module was
> removed
> > > from
> > > > > > the KIE
> > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > here:
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > >
> https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > > > > > > > > > ,
> > > > > > > > > > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > > > > > > > > > >> > > > * This new repo depends
> on
> > > > > Kogito
> > > > > > and
> > > > > > > > > > > > OptaPlanner,
> > > > > > > > > > > > > > > > > > pointing
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > older
> > > > > > > > > > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > P5.
> > > > > > > > > > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and
> Quarkus
> > > > > > > > `2.15.3.Final`.
> > > > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > P6. Category C repos
> are out
> > > > of
> > > > > > date
> > > > > > > > and
> > > > > > > > > > not
> > > > > > > > > > > > part
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > > > > > > > > > >> > > > *
> > > > > incubator-kie-kogito-benchmarks:
> > > > > > > > > > (Current
> > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > > > > > > >> > > > depending on Kogito
> without
> > > a
> > > > > > specific
> > > > > > > > > > > > version,
> > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > by
> > > > > > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > > > > > > > >> > > > `http://localhost:8080
> `)
> > > > > > > > > > > > > > > > > > > > > > >> > > > *
> incubator-kie-benchmarks:
> > > > > > (Current
> > > > > > > > > > version
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > > > > > > >> > > > pointing to Drools
> > > > 999-SNAPSHOT
> > > > > > and
> > > > > > > > > > > > OptaPlanner
> > > > > > > > > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > P7.
> > > > > > > > > > `kie-tools`/packages/kn-plugin-workflow
> > > > > > > > > > > > has
> > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > E2E
> > > > > > > > > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > > > > > > > > > >> > > > upgrading to
> > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > In my perspective, P1
> and P2
> > > > > have
> > > > > > the
> > > > > > > > same
> > > > > > > > > > > > > > solution,
> > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > > > > > > > > >> > > > suffer from the circular
> > > > > > dependency
> > > > > > > > > > between
> > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > > > > > > > > > >> > > > As Category A and
> Category B
> > > > are
> > > > > > both
> > > > > > > > > > streams
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > > > > >> > > > active, I see this as a
> > > > blocker,
> > > > > > as
> > > > > > > > there
> > > > > > > > > > are
> > > > > > > > > > > > > > > > > > contributions
> > > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > > >> > > > cannot be done, given
> that
> > > > > > Category A
> > > > > > > > > > depends
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > P3 and P4, although not
> > > ideal,
> > > > > > can be
> > > > > > > > > > > > understood
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > technical
> > > > > > > > > > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > > > > > > > > > >> > > > Depending on
> unmaintained
> > > > > > projects is
> > > > > > > > > > > > something
> > > > > > > > > > > > > > > we'll
> > > > > > > > > > > > > > > > > > always
> > > > > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > > > > >> > > > susceptible to, given
> time.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > P5 and P6 are easily
> > > fixable,
> > > > as
> > > > > > it's
> > > > > > > > > > just a
> > > > > > > > > > > > > > matter
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > making
> > > > > > > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > P7 is an isolated
> problem
> > > that
> > > > > > won't
> > > > > > > > > > impact
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > structure
> > > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > > > > > > > > > >> > > > that we're talking about
> > > here,
> > > > > > but it
> > > > > > > > is a
> > > > > > > > > > > > > > > regression
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can
> be
> > > > > ignored
> > > > > > for
> > > > > > > > > > Apache
> > > > > > > > > > > > KIE
> > > > > > > > > > > > > > 10,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > > > > > > > > > >> > > > and P7 have easy fixes,
> the
> > > > only
> > > > > > > > problems
> > > > > > > > > > > > left to
> > > > > > > > > > > > > > > > > discuss
> > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > >> > > > P2, which can't be done
> > > > without
> > > > > a
> > > > > > > > proper
> > > > > > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > I'll try to be very
> > > meticulous
> > > > > > here,
> > > > > > > > since
> > > > > > > > > > > > from my
> > > > > > > > > > > > > > > > > > > experience,
> > > > > > > > > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > > > > > > > > >> > > > little miscalculation
> can
> > > lead
> > > > > to
> > > > > > our
> > > > > > > > > > release
> > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > working
> > > > > > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > >> > > > end. To try and avoid
> that
> > > as
> > > > > > much as
> > > > > > > > > > > > possible,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > > > > >> > > > can to have a successful
> > > > Apache
> > > > > > KIE 10
> > > > > > > > > > > > release,
> > > > > > > > > > > > > > bear
> > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > me.
> > > > > > > > > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > > > > > > > > > >> > > > out a timeline of events
> > > that
> > > > > > need to
> > > > > > > > > > happen
> > > > > > > > > > > > in
> > > > > > > > > > > > > > > order
> > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > > > > > > > > > >> > > > to be published, with
> all
> > > > > > artifacts
> > > > > > > > > > ending up
> > > > > > > > > > > > in
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > right
> > > > > > > > > > > > > > > > > > > > > places,
> > > > > > > > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > > > > > > > >> > > > first, we need to solve
> > > > problems
> > > > > > P1
> > > > > > > > and
> > > > > > > > > > P2.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > As you saw at the
> beginning
> > > of
> > > > > > this
> > > > > > > > email,
> > > > > > > > > > > > all the
> > > > > > > > > > > > > > > > > > attempts
> > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > made
> > > > > > > > > > > > > > > > > > > > > > >> > > > left us with the
> circular
> > > > > > dependency
> > > > > > > > > > showing
> > > > > > > > > > > > up
> > > > > > > > > > > > > > at a
> > > > > > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > > > > > > > > > >> > > > but something all these
> > > places
> > > > > > have in
> > > > > > > > > > common
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > > > >> > > > after kogito-apps, and
> > > before
> > > > to
> > > > > > > > Category
> > > > > > > > > > B.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > The first part of my
> > > proposal
> > > > is
> > > > > > the
> > > > > > > > > > > > following:
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > S1. We keep the original
> > > plan
> > > > of
> > > > > > > > moving
> > > > > > > > > > the
> > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > > > UIs
> > > > > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-apps` to
> > > `kie-tools`,
> > > > > > together
> > > > > > > > > > with
> > > > > > > > > > > > > > > Management
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > Task
> > > > > > > > > > > > > > > > > > > > > > >> > > > consoles from
> > > `kogito-images`
> > > > to
> > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > > > > > > >> > > > S2. We move the
> > > > > > `kogito-swf-devmode`
> > > > > > > > and
> > > > > > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > > > > > > > >> > > > from `kogito-images` to
> > > > > > `kie-tools`
> > > > > > > > too.
> > > > > > > > > > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > > > > > > > > > `kogito-serverless-operator`
> > > > > > > > > > > > > > > > repo
> > > > > > > > > > > > > > > > > > > > inside
> > > > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > > > > > > > > > >> > > > package on `kie-tools`,
> > > > keeping
> > > > > > Git
> > > > > > > > > > history.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3
> > > > > together
> > > > > > > > solve
> > > > > > > > > > > > problems
> > > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > P2.
> > > > > > > > > > > > > > > > > > > Of
> > > > > > > > > > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > This doesn't come
> without
> > > > > > > > consequences, of
> > > > > > > > > > > > course,
> > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > images,
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> `kogito-serverless-operator`
> > > > > > would be
> > > > > > > > > > moving
> > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > >> > > > Category B. This move
> would
> > > > make
> > > > > > them
> > > > > > > > > > have to
> > > > > > > > > > > > > > > > reference
> > > > > > > > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > > > > > > > >> > > > repos through
> timestamped
> > > > > > SNAPSHOTs.
> > > > > > > > Since
> > > > > > > > > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> `kogito-serverless-operator`
> > > > are
> > > > > > > > already
> > > > > > > > > > > > their own
> > > > > > > > > > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > > > > > > > > > >> > > > Category A, though,
> > > > > contributions
> > > > > > > > made in
> > > > > > > > > > a
> > > > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > > > > > fashion
> > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > > > > > > > > > >> > > > "sub-stream" will
> continue
> > > > being
> > > > > > > > > > possible, now
> > > > > > > > > > > > > > via a
> > > > > > > > > > > > > > > > > > single
> > > > > > > > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo
> PRs
> > > > > > between
> > > > > > > > > > Category
> > > > > > > > > > > > A and
> > > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > > > > > >> > > > continue not being
> possible,
> > > > > and a
> > > > > > > > 1-week
> > > > > > > > > > > > delay
> > > > > > > > > > > > > > > > between
> > > > > > > > > > > > > > > > > > > > merging
> > > > > > > > > > > > > > > > > > > > > > >> > > > something on Category A
> and
> > > > > using
> > > > > > it
> > > > > > > > on
> > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > > still
> > > > > > > > > > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > It's worth mentioning
> that
> > > > > > > > `kie-tools`,
> > > > > > > > > > > > however,
> > > > > > > > > > > > > > > does
> > > > > > > > > > > > > > > > > > allow
> > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > > > > > > > > > >> > > > checkouts and partial
> > > builds,
> > > > so
> > > > > > > > working
> > > > > > > > > > with
> > > > > > > > > > > > a
> > > > > > > > > > > > > > > subset
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > > > > > > >> > > > is possible and
> encouraged.
> > > > > Making
> > > > > > > > changes
> > > > > > > > > > > > only to
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > `packages/kn-plugin-workflow`,
> > > > > for
> > > > > > > > > > example,
> > > > > > > > > > > > will
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as
> you
> > > > can
> > > > > > see
> > > > > > > > here:
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > > > > > > >> > > > We're not compromising
> when
> > > > > > running
> > > > > > > > > > partial
> > > > > > > > > > > > builds
> > > > > > > > > > > > > > > > too.
> > > > > > > > > > > > > > > > > We
> > > > > > > > > > > > > > > > > > > > know
> > > > > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > > >> > > > the entire repo will
> > > continue
> > > > > > working
> > > > > > > > even
> > > > > > > > > > > > after
> > > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > > > building a
> > > > > > > > > > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > > > > > > > > > >> > > > subset of the changes.
> Doing
> > > > > > partial
> > > > > > > > or
> > > > > > > > > > full
> > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > > > > > > > > > >> > > > determined by the
> changes
> > > of a
> > > > > PR.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Keep in mind that, even
> > > though
> > > > > I'm
> > > > > > > > > > proposing
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > move a
> > > > > > > > > > > > > > > > > > bunch
> > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > >> > > > additional stuff into
> > > > > > `kie-tools`, I
> > > > > > > > see
> > > > > > > > > > this
> > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > > > > > > > > > >> > > > for our codebase.
> > > `kie-tools`
> > > > > > would
> > > > > > > > host
> > > > > > > > > > some
> > > > > > > > > > > > > > > > additional
> > > > > > > > > > > > > > > > > > > stuff
> > > > > > > > > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we
> can
> > > > > > release and
> > > > > > > > > > > > continue
> > > > > > > > > > > > > > > moving
> > > > > > > > > > > > > > > > > > > > forward.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > As I mentioned on other
> > > > places,
> > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > became a
> > > > > > > > > > > > > > > > > > > polyglot
> > > > > > > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > > > > > > >> > > > out of necessity, and
> > > although
> > > > > I'm
> > > > > > > > really
> > > > > > > > > > > > proud of
> > > > > > > > > > > > > > > > what
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > > > > > > > > > >> > > > there so far, I don't
> think
> > > > > > > > `kie-tools`
> > > > > > > > > > has a
> > > > > > > > > > > > > > setup
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > > > > > > > > > >> > > > for all the different
> > > nuances
> > > > > that
> > > > > > > > > > compose our
> > > > > > > > > > > > > > > > > community.
> > > > > > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > > > > > > > >> > > > aware that a polyglot
> > > monorepo
> > > > > > that
> > > > > > > > does
> > > > > > > > > > not
> > > > > > > > > > > > > > follow
> > > > > > > > > > > > > > > > > > > widespread
> > > > > > > > > > > > > > > > > > > > > > >> > > > conventions will scare
> some
> > > > > people
> > > > > > > > away,
> > > > > > > > > > and
> > > > > > > > > > > > as
> > > > > > > > > > > > > > much
> > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > we've
> > > > > > > > > > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > > > > > >> > > > make build instructions
> > > clear,
> > > > > we
> > > > > > > > can't
> > > > > > > > > > > > always get
> > > > > > > > > > > > > > > > past
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > > > > > > > > > >> > > > some people have
> towards the
> > > > > > > > "front-end"
> > > > > > > > > > > > > > ecosystem.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > With all that said, I
> keep
> > > > > > thinking
> > > > > > > > this
> > > > > > > > > > is
> > > > > > > > > > > > the
> > > > > > > > > > > > > > best
> > > > > > > > > > > > > > > > > > course
> > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > > > > > > > > > >> > > > for us right now. We
> keep
> > > most
> > > > > of
> > > > > > our
> > > > > > > > > > stuff
> > > > > > > > > > > > > > > unchanged,
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > > > > >> > > > release, and we have a
> > > working
> > > > > > setup
> > > > > > > > that
> > > > > > > > > > will
> > > > > > > > > > > > > > suit
> > > > > > > > > > > > > > > us
> > > > > > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > >> > > > discuss and reach a
> > > conclusion
> > > > > > > > regarding
> > > > > > > > > > the
> > > > > > > > > > > > > > future
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Let me paint a quick
> picture
> > > > > here
> > > > > > of
> > > > > > > > what
> > > > > > > > > > our
> > > > > > > > > > > > code
> > > > > > > > > > > > > > > > base
> > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > > > > > > > > >> > > > like, repository-wise,
> if my
> > > > > > proposal
> > > > > > > > is
> > > > > > > > > > > > accepted:
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-drools
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > incubator-kie-optaplanner
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > incubator-kie-kogito-docs
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > > > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-docs
> > > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > incubator-kie-benchmarks
> > > > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > > > >> > > > B
> > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > > > >> > > > B
> > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > > > >> > > > D
> > > > > > > > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > incubator-kie-issues
> > > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > incubator-kie-kogito-website
> > > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > incubator-kie-website
> > > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > incubator-kie-kogito-online
> > > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > * Category C becomes
> part of
> > > > > > Category
> > > > > > > > A,
> > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> `kogito-serverless-operator`
> > > > > moves
> > > > > > > > > > entirely
> > > > > > > > > > > > inside
> > > > > > > > > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > > > > > > >> > > > * With
> > > > > > `kogito-swf-{builder,devmode}`
> > > > > > > > > > images
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> `kogito-serverless-operator`
> > > > > > inside
> > > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > > > there
> > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > > > > > > > > > >> > > > anymore, as inside
> > > > `kie-tools`,
> > > > > > we can
> > > > > > > > > > > > granularly
> > > > > > > > > > > > > > > > build:
> > > > > > > > > > > > > > > > > > > > > > >> > > > 1.
> > > > > > > > > > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > > > > > > >> > > > 2.
> > > > > > > > packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > > > > > > >> > > > 3.
> > > > > packages/sonataflow-images
> > > > > > > > > > (containing
> > > > > > > > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > > > > > > > > > >> > > > 4.
> > > > > > packages/sonataflow-operator
> > > > > > > > > > (contents
> > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > > > > > > > > > >> > > > 5.
> > > > > > packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > The second part of the
> > > > proposal
> > > > > > is the
> > > > > > > > > > release
> > > > > > > > > > > > > > > process
> > > > > > > > > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > > > > > > > > >> > > > assuming the structure
> above
> > > > is
> > > > > > what
> > > > > > > > we
> > > > > > > > > > have.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > 1. Define a timestamped
> > > > SNAPSHOT
> > > > > > to be
> > > > > > > > > > used as
> > > > > > > > > > > > > > > cutting
> > > > > > > > > > > > > > > > > > point
> > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > > > > > > > > > >> > > > 2. Update Category B
> repos
> > > to
> > > > > > point to
> > > > > > > > > > this
> > > > > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > > > > > >> > > > verify that everything
> is
> > > > > working.
> > > > > > > > > > > > > > > > > > > > > > >> > > > 3. At this point, with
> > > > > everything
> > > > > > > > > > working, we
> > > > > > > > > > > > can
> > > > > > > > > > > > > > > > branch
> > > > > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A
> from
> > > the
> > > > > > > > timestamped
> > > > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > > tag,
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > > > > > > > > > >> > > > 4. All Category A and
> > > > Category B
> > > > > > repos
> > > > > > > > > > update
> > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > > > > versions
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > >> > > > 10.0.0, in their
> `10.0.x`
> > > > > > branches.
> > > > > > > > > > > > > > > > > > > > > > >> > > > 5. Update Category B
> repos
> > > to
> > > > > > point to
> > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > > > > > > > > > >> > > > 6. At this point, we can
> > > vote
> > > > on
> > > > > > the
> > > > > > > > > > release
> > > > > > > > > > > > based
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > > > > > > > > > >> > > > branches, given we don't
> > > > expect
> > > > > > any
> > > > > > > > code
> > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > anymore.
> > > > > > > > > > > > > > > > > > > > > > >> > > > 7. After voting passes,
> > > we're
> > > > > > good to
> > > > > > > > > > start
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > > > > > > > > >> > > > 8. Category A repos
> follow
> > > > their
> > > > > > > > > > > > manual/automated
> > > > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x`
> > > > branch.
> > > > > > Tags
> > > > > > > > > > pushed
> > > > > > > > > > > > to
> > > > > > > > > > > > > > Git,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to
> their
> > > > > > registries.
> > > > > > > > > > > > > > > > > > > > > > >> > > > 9. We wait a little bit
> for
> > > > > > Category A
> > > > > > > > > > > > artifacts
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > > > > > > > > > >> > > > 10. Category B repos
> follow
> > > > > their
> > > > > > > > > > > > manual/automated
> > > > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x`
> > > > branch.
> > > > > > Tags
> > > > > > > > > > pushed
> > > > > > > > > > > > to
> > > > > > > > > > > > > > Git,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to
> their
> > > > > > registries.
> > > > > > > > > > > > > > > > > > > > > > >> > > > 11. Category D repos are
> > > > > ignored.
> > > > > > > > > > > > > > > > > > > > > > >> > > > 12. Category E repos
> can be
> > > > > > manually
> > > > > > > > > > tagged
> > > > > > > > > > > > with
> > > > > > > > > > > > > > > > 10.0.0
> > > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > More needs to be
> discussed
> > > if
> > > > > > we're
> > > > > > > > > > planning
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > maintain
> > > > > > > > > > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > > > > > > > > > >> > > > release streams in
> parallel,
> > > > > but I
> > > > > > > > guess
> > > > > > > > > > it
> > > > > > > > > > > > can
> > > > > > > > > > > > > > wait
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Thank you for reading,
> and
> > > I'm
> > > > > > looking
> > > > > > > > > > > > forward to
> > > > > > > > > > > > > > > > > hearing
> > > > > > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Of course, alternative
> > > > solutions
> > > > > > are
> > > > > > > > > > possible.
> > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > email,
> > > > > > > > > > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > > > > > > > > > >> > > > summarizes my view of
> how we
> > > > > > should
> > > > > > > > > > attack the
> > > > > > > > > > > > > > > > problem,
> > > > > > > > > > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > > > > > > > > > >> > > > disruption, required
> effort,
> > > > the
> > > > > > > > release
> > > > > > > > > > > > process
> > > > > > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > > > > > > > > > >> > > > Feel free to propose
> > > > > alternatives.
> > > > > > > > This is
> > > > > > > > > > > > not a
> > > > > > > > > > > > > > > > voting
> > > > > > > > > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > > > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > > > > > > > > > >> > > > For additional commands,
> > > > e-mail:
> > > > > > > > > > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > > > To unsubscribe, e-mail:
> dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > For additional commands, e-mail:
> dev-help@kie.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Tiago Bento <ti...@gmail.com>.
New day, new findings.
Yesterday, in a very fruitful conversation with Caponetto, I
discovered that `kie-tools` is currently referencing two additional
images from `kogito-images`. The current dependencies between
`kie-tools` and `kogito-images` are the following:
1. `packages/kn-plugin-workflow` --> `quay.io/kiegroup/kogito-swf-devmode`
2. `packages/serverless-logic-web-tools-swf-builder-image` -->
`quay.io/kiegroup/kogito-swf-builder`
3. `packages/serverless-logic-web-tools-base-builder-image` -->
`quay.io/kiegroup/kogito-base-builder`
4. `packages/serverless-logic-web-tools-swf-dev-mode-image` -->
`quay.io/kiegroup/kogito-base-builder`
All these references were already correctly pointing to the `-nightly`
builds of each image, mirroring the timestamped SNAPSHOT strategy we
currently have. Except for reference 2., which was pointing to
`latest`. I sent a PR
(https://github.com/apache/incubator-kie-tools/pull/2198) to fix the
discrepancy, and to my surprise the PR broke, with a `999-SNAPSHOT`
reference not being found during the build.
All three images that depend on `kogito-images` are dependencies of
the Serverless Logic Web Tools app.
This is a clear example of the problems I explained in my previous
messages. Let me explain this manifestation of the problem here in
more depth.
The problem here is a module from a Category A repo was renamed, and
the `main-2024-02-18` tag of `quay.io/kiegroup/kogito-swf-builder` was
published with a reference to
`org.kie.kogito:kogito-addons-quarkus-knative-serving-deployment:999-SNAPSHOT`.
An artifact with this GAV does not exist anymore, as SNAPSHOTs are not
only mutable, but also ephemeral. IMHO, Maven SNAPSHOTs are NOT a
reliable mechanism for repo synchronicity, but that's a problem for
later.
`kogito-images` depending on upstream repos through mutable, ephemeral
SNAPSHOTs, is making `kie-tools` indirectly depend on them too, and as
you could see, the build is broken, simply because a module was
renamed. With the risk of getting ahead of myself, I just want to make
it clear that if `kie-tools` just pointed to the `latest` tag of
`kogito-images`, it would be exactly the same case as a Dockerized
version of Maven SNAPSHOTs, which, of course, would be problematic,
as already extensively explained in this thread.
The outcome of my findings between yesterday and today are:
A. `kn-plugin-workflow` is not the only package on `kie-tools`
depending on `kogito-images`. We also have
`serverless-logic-web-tools-swf-builder-image`,
`serverless-logic-web-tools-base-builder-image`, and
`serverless-logic-web-tools-base-builder-image`. All dependencies to
the Serverless Logic Web Tools app.
B. weak vs. strong dependencies is a fallacy. Testing and developing
require us to have the dependencies available, in sync, at all times.
The way I see things, a dependency is a dependency. Period.
C. The nightly builds of `kogito-images` are potentially all broken
after some modules were renamed, rendering them not usable. This can
be mitigated by upgrading to a more recent timestamped SNAPSHOT/tag,
which is already PRed
(https://github.com/apache/incubator-kie-tools/pull/2193), but the
architectural problem will remain, unless we change the automation
jobs of `kogito-images` to point to timestamped SNAPSHOTs of upstream
artifacts when publishing their own timestamped tags under the
"-nightly" prefix. Which I think we have to do, btw.
To conclude, the proposal initially shared on this email thread still
holds for unblocking and releasing Apache KIE 10, even after those new
discoveries.
On Thu, Mar 14, 2024 at 1:43 PM Francisco Javier Tirado Sarti
<ft...@redhat.com> wrote:
>
> Hi Jan
> Yes, that's why I was also discussing the suitability of timestamped
> snapshots.
> For me, both amplification of tools repo with unrelated code and
> timestamped snapshots are against fixed snapshot and multi repo philosophy
> employed in the rest of the project (it will be far easier from CI
> perspective to have just one huge repo containing drools, runtimes, apps
> and examples, but we are not doing that)
> Therefore we are kind of sanctioning two different philosophies in our
> first apache release. Since there is apparently no other alternative with
> the resources we have, we will have to release it with this discrepancy.
> But it is sad and I think we should learn from this experience to avoid
> repeating it in the future. In my opinion, this proposal should have been
> shared long before to not make it a fait accompli.
>
> On Thu, Mar 14, 2024 at 6:18 PM Jan Šťastný <js...@apache.org> wrote:
>
> > Hello,
> > I'll try to summarize the challenges I am aware of in relation to CI at the
> > moment and with the proposals.
> >
> > (I am referring to projects forming the build chain as upstream <->
> > downstream depending on their placing in the overall chain.)
> >
> > Current state:
> > Category A projects:
> > - We don't have one, but rather 3 sets of pipelines for project groups:
> > drools, kogito and optaplanner, all these three utilizing a combination of
> > GHA (mostly PR checks) and Jenkins pipelines based on
> > apache/incubator-kie-kogito-pipelines framework (kogito-pipelines FW).
> > - For these builds, we use build-chain tool, which allows to define
> > cross-repository relations between projects, clone repositories and run
> > custom commands in each of those, depending in what part of the build chain
> > (considering the project triggering the build) they are invoked (upstream,
> > downstream, current). Examples of the build-chain project dependencies
> > configuration Tiago provided in the first email. Build-chain is a powerful
> > tool, though we have limited knowledge (Roberto being the sole contributor
> > of fixes since our move to ASF).
> > - As part of the kogito pipeline kogito-images and *-operator jobs are
> > attached, but relation to repositories earlier up the chain is either
> > assumed (building from main branch of kogito-apps) or loose (building
> > kogito-examples from main-nightly branch, which is created in preceding
> > kogito-examples nightly build). It's not part of PR checks for repositories
> > up the stream.
> >
> > Category B projects:
> > - We have a unique solution based mainly on GHA, but recently also some
> > parts (is it a backup?) in ASF Jenkins, but NOT using the kogito-pipelines
> > FW.
> >
> > Category C projects:
> > - There are loosely managed jobs for *-benchmarks repositories, just a
> > matter of updating versions, easily manageable - won't discuss further.
> >
> > Current gaps:
> >
> > Category A projects:
> > - Generally the current jenkins solution for PR checks is lacking, we have
> > just a single kind of PR check, not allowing custom triggers (e.g. by
> > comments) or various modes (like quarkus native build).
> > - We don't have downstream builds as part of PR checks.
> > - We build all in a single job. Which has resulted in execution time over 8
> > hours which was not bearable. Thus we reduced the build scope to sort of
> > compile downstream builds - we run tests for repositories that are part of
> > the PR, but their dependents (coming after them) are only run without
> > tests.
> > - With the introduction of unified SNAPSHOTs we have not fully adjusted for
> > this in our pipelines, leaving out relations like optaplanner -> drools and
> > kogito-apps -> optaplanner - so problems will be missed in case of related
> > PRs. This SNAPSHOT version unification indicates that instead of 3 distinct
> > buildchain configurations, we should now switch to a single one, especially
> > for the sake of unification.
> > - Part of the repositories (starting with kogito-images) are not attached
> > in the build-chain build at all, but are rather consecutively executed
> > pipelines relying on publishing artifacts for consumption downstream.
> >
> > Proposal assessment:
> > - Almost any repository could be part of the build-chain configuration,
> > complex invocations can be hidden e.g. using make.
> > - Any changes to PR checks should have the following prerequisite not to
> > increase complexity and to limit execution times: moving of all PR checks
> > into GHA, introduction of isolated limited-scope PR checks, on-demand full
> > downstream build.
> > - Timestamped SNAPSHOTs consumed by kie-tools would call against attaching
> > kie-tools into build-chain of drools/kogito, because we would be running PR
> > checks/nightly against main which might differ from the timestamped
> > SNAPSHOT. So this seems like either/or decision to me.
> > - Build-chain would probably not be able to replicate the fine-grained
> > build execution based on the changes in PR as kie-tools currently has in
> > place.
> > - It's not clear to me how/if we could generally limit scope of execution
> > in downstream builds depending on scope of upstream repository changes.
> > - Community CI has really limited human resources, I personally switched to
> > an ad-hoc way of working on that, only when something breaks.
> > - It's not clear to me how a build-chain would work in terms of
> > consuming/passing artifacts outside of maven projects and artifacts.
> > - It's fair to say that we have SMEs for CI/build in Category A (engines or
> > cloud), Category B, but I don't think there's anyone knowing deep internals
> > of all, to be able to provide a reliable estimate of efforts involved in
> > bigger refactoring.
> >
> > Summary:
> > I don't see an easy way how a simple change in CI would help to unblock the
> > current situation. Considering Tiago's proposal, timestamped SNAPSHOTs
> > already in place, assumed relative simplicity of making the components part
> > of kie-tools build ...
> >
> > +1 from me
> >
> > Thanks.
> > Best Regards
> > Jan
> >
> >
> >
> >
> >
> >
> > On Thu, 14 Mar 2024 at 11:24, Francisco Javier Tirado Sarti <
> > ftirados@redhat.com> wrote:
> >
> > > Hi Tiago, Thanks for the detailed explanation
> > > Actually, for tooling, where there is not strong dependency (as between
> > > engine code in runtime and kie server api in drools), the fixed snapshot
> > > mechanism will work pretty well, in my opinion.
> > > On one side, an example that depends on devui will not fail to compile
> > > because the snapshot is old. The contrary is also true, if we add a new
> > > functionality in the server side that is going to be used by any tool,
> > the
> > > worst that might happen is that the functionality is not there in the old
> > > snapshot, but it wont block tooling compilation (obviously if you need
> > that
> > > functionality to test a new UI feature, you will need the update
> > snapshot,
> > > but that's expected and I guess is also happening now, you need to wait
> > for
> > > the server artifact to be published on Maven)
> > > Because of that loose dependency, tooling can be run, as it is, as an
> > > almost completely separate project but also because of that, I feel it
> > > might be easily integrated (except for CI changes, which are always
> > > delicate) with the rest of the repos to achieve a single release number,
> > > because, if all repos use the same snapshot, as far as there is one
> > > snapshot, in the day by day experience everything will normally compile.
> > > I think we agree that the natural place of tooling in the dependency
> > chain
> > > is after apps (service) and before images. With that in mind and if we
> > > wholly embrace the consequence of being a single release, in my opinion,
> > it
> > > means that tooling become one more repo (no A no B category), which use
> > a
> > > fixed snapshot as the rest, and it is subject to the need to eventually
> > > wait for the updated snapshot (or in case you cannot wait, a local full
> > > build), in the unlikely case there is a change that blocks its local
> > > compilation. The implication of this is that the development cycle that
> > is
> > > implicit in your proposal to use a "fixed snapshot" in category A repos
> > no
> > > longer apply.
> > > This means no time to adjust, which can sound like an herexy, but, if
> > there
> > > is no need for a gap between drools and runtimes, why is there a need
> > for a
> > > gap between tooling and apps (services)? (I think we agree a Java API
> > > dependency is stronger than a REST API) Do we have a real precedent that
> > > justify that? I kind of feel that here we are converting an old habit
> > into
> > > an axiomatic need (probably because Im lacking context)
> > > Now my proposal for CI, we do not really need a single stream right now.
> > We
> > > can keep the current kogito stream as it is, except for images, and
> > > integrate tooling into the stream that is now used for the operator (the
> > > assumption here is that a change in drools-runtimes hardly breaks the
> > tools
> > > and in any case that is already happening, so we do not lose anything)
> > >
> > >
> > > On Wed, Mar 13, 2024 at 8:18 PM ricardo zanini fernandes <
> > > ricardozanini@gmail.com> wrote:
> > >
> > > > Hey Tiago, thanks for the insights, I appreciate it.
> > > >
> > > > Just one thing regarding building from kie-tools one module that images
> > > > need to sync changes. That might happen, of course. If I see a problem
> > in
> > > > devui, I just report it in the tools repo, we work on the bug, and in
> > the
> > > > next image build we get the changes. By the nature of the
> > > operator/images,
> > > > such changes won't impact our builds. What impact our builds are
> > > > self-contained on those repos or work made in the engines, where we
> > rely
> > > on
> > > > Snapshots.
> > > >
> > > > I understand your concern and it's a valid point, but in practice, it's
> > > not
> > > > what happens. We can live with the latest released version from npm
> > > > packages during the dev phase without any problems. From the
> > > > images/operator perspective, they are yet another package I need to
> > > install
> > > > on my container. Like `cat` or `jq`.
> > > >
> > > > But we need to sit down and try to understand our boundaries and how to
> > > do
> > > > integration tests based on them. For example, deploying a devmode
> > > workflow
> > > > in Kubernetes and starting a workflow instance via the devui console.
> > > >
> > > > On Wed, Mar 13, 2024 at 3:54 PM Tiago Bento <
> > > tiagobentofernandes@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Francisco,
> > > > >
> > > > > I agree with you that both reasonings are not antagonistic, as an
> > > > > antagonistic reasoning in this case would be one that doesn't work.
> > > > > And I believe it is clear now that the initial proposal shared on
> > this
> > > > > email thread does work, but it is not the only possibility. From the
> > > > > beginning I said there are alternatives, but I wanted to start the
> > > > > conversation from my point of view, sharing what I think is best. We
> > > > > have to acknowledge, though, IMHO, that the discussions we had thus
> > > > > far cannot be understood as clearly as what was initially laid out,
> > > > > given the lack of details/analysis and a clear execution plan.
> > > > >
> > > > > Let me elaborate on top of the 3-step plan you shared.
> > > > >
> > > > > 1)
> > > > > No comment. This should be pretty simple to do.
> > > > >
> > > > > 2)
> > > > > There is no global CI stream to be changed, we would have to create
> > > > > one. And this has serious implications to our contribution model for
> > > > > cross-repo PRs. As I described on the first email of this thread,
> > > > > Category A repos are configured in several disjoint streams. Sending
> > a
> > > > > PR to `drools` and `kogito-runtimes` will work great, but sending a
> > PR
> > > > > to `drools` and `kogito-images`, or `drools` and `optaplanner` won't
> > > > > verify that everything will continue working after the PRs are
> > merged,
> > > > > as our PR checks are not prepared to build this combination of repos
> > > > > together. This is a problem, in my view, but I hardly contribute to
> > > > > Category A repos, so I'm assuming things are working fine for those
> > > > > who do. The proposal shared on the first email of this thread does
> > not
> > > > > change the contribution workflow for any repo of Apache KIE, and
> > > > > everyone can continue contributing the way they're used to, except
> > for
> > > > > people contributing to the `kogito-swf-{builder,devmode}` images, and
> > > > > to `kogito-serverless-operator`. On the other hand, having
> > `kie-tools`
> > > > > built in the middle of a new global CI stream, would span another
> > > > > class of problem, which is very closely related to the third bullet
> > > > > point of the plan you shared.
> > > > >
> > > > > 3)
> > > > > Maven has a mechanism to achieve this pseudo-synchronicity between
> > > > > multiple repositories. The mutable SNAPSHOT version, built nightly.
> > It
> > > > > is not perfect, though, as I'm sure many of us already experienced
> > > > > pulling from the `main` branch of a single repo only to find out that
> > > > > a PR ensemble had been merged a few moments prior, requiring us to
> > > > > rebuild the entire stack, since our local SNAPSHOTs had become
> > > > > out-of-date. That's what we used to have back in Business Central
> > > > > (a.k.a. v7) days. Making a `git pull` on a single repo in this setup
> > > > > potentially requires all repos to be pulled and rebuilt. I'm sure
> > this
> > > > > still happens sometimes when developing Category A projects.
> > > > >
> > > > > NPM packages don't have mutable SNAPSHOTs. Every published NPM
> > package
> > > > > is immutable, and it is really cumbersome and error-prone to
> > integrate
> > > > > downstream repos with upstream NPM-bound repos, as not having a
> > > > > lockfile brings all sorts of security and stability problems. That's
> > > > > why monorepos became so popular in the JavaScript ecosystem. This
> > lack
> > > > > of a mutable SNAPSHOT mechanism makes depending on NPM artifacts
> > > > > coming from `kie-tools` really hard. The way I see it, moving repos
> > > > > downstream of `kie-tools` will require everyone to build `kie-tools`
> > > > > anyway, potentially on a daily basis, since it would've then become
> > > > > part of the stack that needs to be built before `kogito-images` and
> > > > > `kogito-serverless-operator`. More than that, since there would be no
> > > > > way to determine what subset of packages of `kie-tools` would need to
> > > > > be built to satisfy downstream references, everyone would have to do
> > a
> > > > > full build, or handpick individual packages of the monorepo to build.
> > > > >
> > > > > I hope I was able to offer more insight in the way I see things,
> > along
> > > > > with my take on using Maven SNAPSHOTs as the de-facto solution for a
> > > > > poly-repo codebase. I don't think we can escape from the complexity
> > of
> > > > > our codebase and the nature of the technologies we use, only
> > > > > accommodate it in the most comfortable place possible, if even there
> > > > > is such a place :)
> > > > >
> > > > > Now, there are some things I'd like to say regarding the initial
> > > > > proposal shared on this email thread.
> > > > >
> > > > > I understand you, and others, are concerned about moving stuff into
> > > > > `kie-tools` for some reasons I could gather from your messages. I'll
> > > > > try and list them here, along with my perspective on each of them.
> > > > >
> > > > > 1. Never being able to move them out of `kie-tools` again.
> > > > > This is going to be as hard as it would be removing
> > > > > `kn-plugin-workflow` from it now. So, as you and others mentioned
> > this
> > > > > possibility, I assume you understand it to be doable.
> > > > >
> > > > > 2. "Heterodoxizing" an orthodox repository
> > > > > (`kogito-serverless-operator`), potentially harming external
> > > > > contributions.
> > > > > Agree with this point. `kie-tools` is one of a kind, built around
> > > > > front-end tooling with some completely unique in-house apparatus. In
> > > > > my experience, though, there are a multitude of factors that make
> > > > > people want to contribute to an open source project. Conformance to
> > > > > well-known widespread technologies and tools is just one of them.
> > > > > Being open about it and writing material to smooth out those edges
> > can
> > > > > work pretty well. People do not contribute because a codebase is
> > > > > "pure". People contribute because they care about the project. And
> > I'm
> > > > > always surprised by the lengths people go to when they want to get
> > > > > involved.
> > > > >
> > > > > 3. Disruption to the contribution workflow of those contributing to
> > > > > `kogito-swf-{builder,devmode}` images, and to
> > > > > `kogito-serverless-operator`.
> > > > > It is clear to me now that we can't unblock and release Apache KIE 10
> > > > > without impacting anyone, but I hope the first part of this reply
> > > > > sheds some light on this complicated matter.
> > > > >
> > > > > Anyway, that's my attempt to offer a different perspective to some of
> > > > > the problems you expressed concern about, perhaps even making the
> > > > > initial proposal shared on this email thread be seen with less
> > > > > uncertainty.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 11:40 AM Francisco Javier Tirado Sarti
> > > > > <ft...@redhat.com> wrote:
> > > > > >
> > > > > > Tiago,
> > > > > > Unfortunately, my plan is too conceptually simple to write more
> > than
> > > I
> > > > > > already wrote.
> > > > > > 1) Move kn-plugin-workflow module to operator repo (this remove the
> > > > > > dependency between tools and operator, breaking the loop)
> > > > > > 2) Change CI global stream to execute tooling repo before operator
> > > repo
> > > > > > (this seems to take 2 months unless Tristan helps and reduce the
> > time
> > > > to
> > > > > 2
> > > > > > weeks)
> > > > > > 3) Optionally, and just as a consequence of that CI change, set
> > > > > > 999-SNAPSHOT version to all poms in all repos (if current snapshot
> > > > > numbers
> > > > > > turns out to be a problem, in any case this is just search-replace)
> > > > > >
> > > > > > The current plan is:
> > > > > > 1) Move everything depending on tools to tools repo, which includes
> > > > > > operator code and examples.
> > > > > > 2) Change CI of tooling repo to enforce dependencies between the
> > > > existing
> > > > > > modules there and the newly moved ones (this seems to take 3 weeks
> > or
> > > > > less)
> > > > > >
> > > > > > I think rather than asking for a more detailed alternative, what
> > > needs
> > > > to
> > > > > > be done is to refine the existing proposal with the feedback
> > > received.
> > > > I
> > > > > do
> > > > > > not think both proposals are antagonistic. I think that, being now
> > > > clear
> > > > > we
> > > > > > have the same overall goal (execute tooling before operator), it is
> > > > just
> > > > > a
> > > > > > question of deciding between move more stuff to an already
> > heterodox
> > > > > repo,
> > > > > > coming from repos not as heterodox, plus changing the repo CI to
> > > impose
> > > > > > certain order between these modules or pull out the the operator
> > > stuff
> > > > > from
> > > > > > tool repo and put it inside the operator repo plus changing the CI
> > > > > > handling repos to impose the desired order: first tooling and then
> > > > > operator.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 4:12 PM Tiago Bento <
> > > > > tiagobentofernandes@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Francisco,
> > > > > > >
> > > > > > > 1) `kie-tools` is already a heterodox repo. The reason why I
> > > proposed
> > > > > > > my proposal is because it is what I think is the best course of
> > > > action
> > > > > > > for our community right now. If you think there's a better way to
> > > do
> > > > > > > it, I think everyone, including me, needs to see a proposal with
> > a
> > > > > > > clear execution plan with a comparable level of detail and
> > analysis
> > > > in
> > > > > > > regards to disruption of the current state, the required effort,
> > > the
> > > > > > > contribution workflow for cross-repo PRs, and the release process
> > > > > > > itself. Otherwise, we risk having gaps that each person will fill
> > > in
> > > > a
> > > > > > > different way, and IMHO, that's where problems happen. +1 for
> > > > examples
> > > > > > > unification, btw :)
> > > > > > >
> > > > > > > 2) Ok, and +1 for no categorization.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado Sarti
> > > > > > > <ft...@redhat.com> wrote:
> > > > > > > >
> > > > > > > > 1) Ok, if that is the case, I do not get why your first
> > proposal
> > > > was
> > > > > not
> > > > > > > > the one I'm proposing and it is apparently not detailed enough.
> > > To
> > > > > move
> > > > > > > > kn-workflow from tooling to operator one and change the order
> > in
> > > > > which
> > > > > > > the
> > > > > > > > repos are being processed. Basically, the problem of the
> > proposed
> > > > > > > solution
> > > > > > > > is that it kind of converts tooling repo into a pretty
> > heterodox
> > > > repo
> > > > > > > > compared with runtimes, drools or operator one. Also once
> > tooling
> > > > is
> > > > > not
> > > > > > > a
> > > > > > > > final repo in the overall chain, we can consider moving
> > examples
> > > as
> > > > > the
> > > > > > > > final one and include tooling showcases there (rather than
> > > > splitting
> > > > > > > > examples into examples with tooling and examples without
> > > tooling).
> > > > > > > > 2) I think this distinction between A and B is one between
> > > several
> > > > > > > possible
> > > > > > > > categorizations (not much, including no categorization at all)
> > > that
> > > > > > > > deserves a separate discussion. I will open a separate thread
> > for
> > > > > that
> > > > > > > > purpose, since we are not going to change that now and it is
> > not
> > > > > really
> > > > > > > > part of the proposal.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
> > > > > > > tiagobentofernandes@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco,
> > > > > > > > >
> > > > > > > > > 1) That's what this thread is all about... You know I don't
> > > think
> > > > > it's
> > > > > > > > > ok. That's why I'm proposing the two images and the operator
> > to
> > > > > move
> > > > > > > > > into the `kie-tools` repo, where we can more granularly
> > control
> > > > the
> > > > > > > > > order things are built, thus removing the dependency cycle.
> > > > > > > > >
> > > > > > > > > 2) Not sure we understand the same thing by "freeze". My
> > > proposal
> > > > > is
> > > > > > > > > that we select a timestamped SNAPSHOT version from Category A
> > > > > repos to
> > > > > > > > > use as base for a release. We give Category B repos some time
> > > to
> > > > > > > > > adjust, and then cut the release branches. This can happen
> > > > anytime,
> > > > > > > > > and no contributions would ever stop because of it. The
> > > > development
> > > > > > > > > branches can continue accepting PRs normally, even during the
> > > > > release
> > > > > > > > > process. Now, if what you're asking is why Category B repos
> > > refer
> > > > > to
> > > > > > > > > Category A repos via timestamped SNAPSHOTs, the answer is in
> > my
> > > > > first
> > > > > > > > > email. See the paragraph starting with "An important note
> > here
> > > is
> > > > > that
> > > > > > > > > Category B repositories...".
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado
> > Sarti
> > > > > > > > > <ft...@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Tiago
> > > > > > > > > > There are a couple of simple and straightforward questions
> > > > that
> > > > > I
> > > > > > > > > > formulated, but since we both write a lot, it might have
> > been
> > > > > lost.
> > > > > > > > > Please
> > > > > > > > > > let me ask them again.
> > > > > > > > > > 1) Do you think it is ok that tools repo is executed after
> > > > > > > generation of
> > > > > > > > > > docker images that are supposed to include those tools or
> > the
> > > > > > > operator
> > > > > > > > > that
> > > > > > > > > > is supposed to deploy such images?
> > > > > > > > > That's what this thread is all about... You know I'm not ok
> > > with
> > > > > it,
> > > > > > > > > that's why I'm proposing the two images and the operator to
> > > move
> > > > > into
> > > > > > > > > the `kie-tools` repo, where we can more granularly control
> > the
> > > > > order
> > > > > > > > > things are built and remove the dependency cycle.
> > > > > > > > > > 2) Besides that, although not directly related with the
> > > current
> > > > > > > proposal
> > > > > > > > > we
> > > > > > > > > > are discussing, I really think there are some restrictions
> > > > taken
> > > > > for
> > > > > > > > > > granted that are arbitrary and difficult to sustain on
> > > strictly
> > > > > > > technical
> > > > > > > > > > arguments. For example, the need to freeze the rest of the
> > > > > software
> > > > > > > > > before
> > > > > > > > > > tools are generated. Why? We have dependencies between
> > repos
> > > > that
> > > > > > > are not
> > > > > > > > > > handled that way: Apps depend on runtimes. Runtimes depend
> > on
> > > > > drools,
> > > > > > > > > > Operator depend on runtimes,....and we are not freezing
> > that
> > > > > repos
> > > > > > > since
> > > > > > > > > we
> > > > > > > > > > are all releasing at the same time. If we are all releasing
> > > at
> > > > > the
> > > > > > > same
> > > > > > > > > > time, what's the rationale behind the freeze?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <
> > > > > tiagobento@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Glad to see the interest this proposal has gotten, and
> > it's
> > > > > good to
> > > > > > > > > > > see some alternatives being drafted here, although still
> > > > > lacking
> > > > > > > clear
> > > > > > > > > > > definitions and analysis in regards to disruption,
> > required
> > > > > effort,
> > > > > > > > > > > the release process itself, and history. Of course, lots
> > of
> > > > > details
> > > > > > > > > > > and clarity on the execution part would be missing too.
> > > > > > > > > > >
> > > > > > > > > > > As of this moment, based on what I read here, I'm
> > assuming
> > > > that
> > > > > > > > > > > everyone who participated so far doesn't see the initial
> > > > > proposal
> > > > > > > as
> > > > > > > > > > > problematic in terms of feasibility, but some of you
> > have a
> > > > > > > preference
> > > > > > > > > > > not to go with it, because it is "wrong", and apparently
> > > > > because it
> > > > > > > > > > > would "jeopardize the evolution of the project". Reading
> > > > these
> > > > > last
> > > > > > > > > > > words made me a little sad, to be honest. But I can deal
> > > with
> > > > > it :)
> > > > > > > > > > >
> > > > > > > > > > > Please let's try and keep the discussion as objective as
> > > > > possible.
> > > > > > > > > > > "Right" and "wrong" are too subjective for this kind of
> > > > > > > conversation.
> > > > > > > > > > >
> > > > > > > > > > > Now, being practical, unless there are clear arguments
> > > based
> > > > on
> > > > > > > facts
> > > > > > > > > > > and objective concepts that invalidate the initial
> > proposal
> > > > > shared
> > > > > > > on
> > > > > > > > > > > this email, it seems to me that it is currently the only
> > > > viable
> > > > > > > > > > > proposal we have for unblocking and releasing Apache KIE
> > > 10.
> > > > Of
> > > > > > > > > > > course, if we end up seeing an alternative proposal with
> > > > enough
> > > > > > > > > > > details and a clear execution plan, I think then we'll be
> > > in
> > > > a
> > > > > very
> > > > > > > > > > > good position to choose from multiple options!
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <
> > > > > alex@porcelli.me>
> > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Francisco and Gabriele,
> > > > > > > > > > > >
> > > > > > > > > > > > I understand and acknowledge your desire to find the
> > > > “right”
> > > > > > > solution
> > > > > > > > > > > > instead to work on a temporary “patch” - however
> > without
> > > a
> > > > > > > detailed
> > > > > > > > > > > > proposal I don’t think we can properly evaluate the
> > > impact
> > > > of
> > > > > > > your
> > > > > > > > > > > > suggestion.
> > > > > > > > > > > >
> > > > > > > > > > > > When I spoke with different SMEs that included tools
> > and
> > > > CI,
> > > > > the
> > > > > > > > > > > > guesstimate for making the necessary changes on CI and
> > > > > codebase
> > > > > > > to
> > > > > > > > > > > > basically have images and operators in the end of the
> > > build
> > > > > > > chain is
> > > > > > > > > > > > something like 2 months of effort. Another impact that
> > > > needs
> > > > > to
> > > > > > > be
> > > > > > > > > > > > discussed is that KIE Tools repo had to be injected in
> > > the
> > > > > > > middle of
> > > > > > > > > all
> > > > > > > > > > > > pipelines - forcing all PR checks and nightlies to
> > build
> > > > all
> > > > > > > repos
> > > > > > > > > (PR
> > > > > > > > > > > > checks will likely take 12+ hours… I even heard that it
> > > > > could be
> > > > > > > > > even 24
> > > > > > > > > > > > hours).
> > > > > > > > > > > >
> > > > > > > > > > > > Based on the input above, I think it’s quite risk to
> > move
> > > > in
> > > > > such
> > > > > > > > > > > direction
> > > > > > > > > > > > without a more detailed plan… because 2 months could be
> > > > > turned
> > > > > > > > > easily in
> > > > > > > > > > > 6!
> > > > > > > > > > > > And this is exactly what happened when we guessed that
> > > > > moving to
> > > > > > > > > Apache
> > > > > > > > > > > > would take no more than 3 months. But here we are.
> > > > > > > > > > > >
> > > > > > > > > > > > I really strongly suggest that we focus on a release
> > that
> > > > > could
> > > > > > > be
> > > > > > > > > > > > achievable in less than a month from now, and we -
> > after
> > > > > release
> > > > > > > -
> > > > > > > > > have a
> > > > > > > > > > > > in depth discussion about the overall codebase and ci
> > > > > > > organization.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > my suggestion is to move the building of all docker
> > > > images,
> > > > > > > from
> > > > > > > > > > > whatever
> > > > > > > > > > > > > repo (kogito-apps, kie-tools) in a different,
> > > downstream
> > > > > repo,
> > > > > > > to
> > > > > > > > > be
> > > > > > > > > > > > > invoked after all the others.
> > > > > > > > > > > > > I'm not sure if this would solve all the issues, and
> > > > since
> > > > > I
> > > > > > > could
> > > > > > > > > not
> > > > > > > > > > > > > enter in the details of all the involved code, my
> > > > > suggestion
> > > > > > > may
> > > > > > > > > be too
> > > > > > > > > > > > > naive.
> > > > > > > > > > > > > Having spent almost all of the last year in CI, I
> > may
> > > > say
> > > > > > > that, at
> > > > > > > > > > > least
> > > > > > > > > > > > > for the kie-tools repo, removing the image build step
> > > > from
> > > > > it
> > > > > > > > > should
> > > > > > > > > > > not be
> > > > > > > > > > > > > too difficult (since it is an issue we already faced
> > > and
> > > > > > > solved).
> > > > > > > > > > > > > If, with "detailed proposal", you mean a complete
> > list
> > > of
> > > > > all
> > > > > > > > > modules
> > > > > > > > > > > to be
> > > > > > > > > > > > > moved and dependency refactoring, of course I can not
> > > > > provide
> > > > > > > it
> > > > > > > > > right
> > > > > > > > > > > now.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Anyway, I share the concern from Francisco: undoing
> > > > > something
> > > > > > > is
> > > > > > > > > almost
> > > > > > > > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco
> > > Javier
> > > > > > > Tirado
> > > > > > > > > Sarti
> > > > > > > > > > > <
> > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I do not think estimations should be the only
> > driver
> > > to
> > > > > make
> > > > > > > a
> > > > > > > > > > > decision,
> > > > > > > > > > > > > > especially when the current proposal is
> > conceptually
> > > > > > > incompatible
> > > > > > > > > > > with
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > multi repo approach that is taken elsewhere in the
> > > > > project.
> > > > > > > > > > > > > > Given my knowledge of the CI it is nearly
> > impossible
> > > > for
> > > > > me
> > > > > > > to
> > > > > > > > > give
> > > > > > > > > > > a
> > > > > > > > > > > > > fair
> > > > > > > > > > > > > > estimate of how much it might take to achieve step
> > 2)
> > > > of
> > > > > my
> > > > > > > > > previous
> > > > > > > > > > > > > e-mail
> > > > > > > > > > > > > > . It might take a while or it might be pretty easy
> > > > after
> > > > > > > all, I
> > > > > > > > > don't
> > > > > > > > > > > > > > really know, but I think it will be a good idea if
> > > > some
> > > > > of
> > > > > > > the
> > > > > > > > > > > experts
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > CI in the team (the ones that set up the pipeline,
> > > > which
> > > > > was
> > > > > > > a
> > > > > > > > > huge
> > > > > > > > > > > > > > achievement) give an estimate, not me. Estimating
> > > how
> > > > > much
> > > > > > > it
> > > > > > > > > takes
> > > > > > > > > > > to
> > > > > > > > > > > > > > merge two existing repos (without altering CI) is
> > > > easier,
> > > > > > > but it
> > > > > > > > > > > does not
> > > > > > > > > > > > > > mean we are doing the right thing.
> > > > > > > > > > > > > > My main concern is that it will be very difficult
> > for
> > > > me
> > > > > to
> > > > > > > > > explain
> > > > > > > > > > > to
> > > > > > > > > > > > > > someone that arrives new to the team, that having
> > > > > experts on
> > > > > > > CI
> > > > > > > > > on
> > > > > > > > > > > the
> > > > > > > > > > > > > > team, we decided to merge two repos (once merged,
> > it
> > > > > would be
> > > > > > > > > rather
> > > > > > > > > > > > > > difficult to unmerge) rather than fix the CI,
> > because
> > > > of
> > > > > > > > > expediency.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > > > > > > > porcelli@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Please take the time to make the more in depth
> > > > analysis
> > > > > > > needed
> > > > > > > > > and
> > > > > > > > > > > > > > provide
> > > > > > > > > > > > > > > a more detailed plan… so we - as community- can
> > > > > evaluate
> > > > > > > the
> > > > > > > > > size
> > > > > > > > > > > of
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > effort. In the conceptual level you shared it’s
> > > near
> > > > > > > > > impossible to
> > > > > > > > > > > > > > estimate
> > > > > > > > > > > > > > > the size of the effort and compare with the
> > current
> > > > > > > proposal.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier
> > > > Tirado
> > > > > > > Sarti <
> > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > > > > > > > 1) Remove all dependencies from tooling to
> > > images,
> > > > > so
> > > > > > > images
> > > > > > > > > > > depend
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > > > > > > > 2) Then change CI to deal with tooling repo
> > > before
> > > > > > > dealing
> > > > > > > > > with
> > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > repo.
> > > > > > > > > > > > > > > > I understand that CI details are tricky and
> > since
> > > > > I'm not
> > > > > > > > > > > familiar
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > > CI
> > > > > > > > > > > > > > > > in any way, I barely can make a low level
> > design,
> > > > > but we
> > > > > > > do
> > > > > > > > > not
> > > > > > > > > > > need
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > fix
> > > > > > > > > > > > > > > > everything, just achieve 2), a change of
> > > > compilation
> > > > > > > order.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli
> > <
> > > > > > > > > alex@porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > You may not like or understand why the
> > current
> > > > > state of
> > > > > > > > > the CI
> > > > > > > > > > > is
> > > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > that… actually has been in Red Hat and has
> > been
> > > > > > > replicated
> > > > > > > > > in
> > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > used to be….
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But the fact is that this is the current
> > > reality.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you disagree with the current plan, please
> > > > > provide a
> > > > > > > > > > > detailed
> > > > > > > > > > > > > > > > > alternative so we, as community, can better
> > > > > evaluate
> > > > > > > the
> > > > > > > > > pros
> > > > > > > > > > > and
> > > > > > > > > > > > > > cons
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > each proposal.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think it’s also fair to say that, post 10
> > > > > release we
> > > > > > > > > need to
> > > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > much
> > > > > > > > > > > > > > > > > in depth discussion about how our codebase is
> > > > > > > organized,
> > > > > > > > > it’s
> > > > > > > > > > > clear
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > it’s not working.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele
> > > Cardosi
> > > > <
> > > > > > > > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > > > > > > > I also have the impression that the
> > "images"
> > > > (if
> > > > > we
> > > > > > > are
> > > > > > > > > > > talking
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > docker
> > > > > > > > > > > > > > > > > > images) should be the very last one to be
> > > > built,
> > > > > in a
> > > > > > > > > > > standalone
> > > > > > > > > > > > > > > repo.
> > > > > > > > > > > > > > > > > > That way, they may "combine" artifacts that
> > > are
> > > > > > > built in
> > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > repos,
> > > > > > > > > > > > > > > > > > regardless of the order in which those are
> > > > built.
> > > > > > > > > > > > > > > > > > Moving them out of all the repos
> > > > > > > (kogito-apps/kie-tools)
> > > > > > > > > > > maybe
> > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > > > > > > > (I also think there are some statements of
> > > > > > > undisputable
> > > > > > > > > needs
> > > > > > > > > > > > > while
> > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > > > > > > > Anyway, this latter point is for longer,
> > > > > following,
> > > > > > > > > > > discussion.)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23
> > > > > Francisco
> > > > > > > Javier
> > > > > > > > > > > Tirado
> > > > > > > > > > > > > > > Sarti
> > > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > > > > > > > There are two assumptions that deserve
> > > > further
> > > > > > > > > discussion:
> > > > > > > > > > > > > > > > > > > 1) That tool has to be the last to build.
> > > > why?
> > > > > it
> > > > > > > does
> > > > > > > > > not
> > > > > > > > > > > have
> > > > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > > > > to build final images after everything
> > else
> > > > has
> > > > > > > been
> > > > > > > > > > > built?-
> > > > > > > > > > > > > > > > > > > 2) That the impact (in terms of effort
> > now)
> > > > on
> > > > > > > fixing
> > > > > > > > > CI is
> > > > > > > > > > > > > > bigger
> > > > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > impact (long term consequences) of
> > > > > consolidating
> > > > > > > two
> > > > > > > > > > > unrelated
> > > > > > > > > > > > > > > piece
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex
> > > > Porcelli
> > > > > <
> > > > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > This was discussed as an alternative
> > > > > solution,
> > > > > > > > > however
> > > > > > > > > > > it has
> > > > > > > > > > > > > > > major
> > > > > > > > > > > > > > > > > > > impact
> > > > > > > > > > > > > > > > > > > > on CI and there’s also the fact Tool
> > has
> > > > been
> > > > > > > always
> > > > > > > > > the
> > > > > > > > > > > last
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > build
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > has no Snapshot published (actually in
> > > > > JavaScript
> > > > > > > > > world
> > > > > > > > > > > there
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > So, based on our evaluation… the
> > proposal
> > > > > here
> > > > > > > is the
> > > > > > > > > > > least
> > > > > > > > > > > > > > > > > disruptive
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > will take less time to unblock the
> > > release.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM
> > Francisco
> > > > > Javier
> > > > > > > > > Tirado
> > > > > > > > > > > > > Sarti <
> > > > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > After kie-tools, sorry. I think we
> > are
> > > > not
> > > > > > > > > embracing
> > > > > > > > > > > the
> > > > > > > > > > > > > fact
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > kogito-images depend on kie-tools,
> > > > because
> > > > > we
> > > > > > > want
> > > > > > > > > > > those
> > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM
> > > > Francisco
> > > > > > > Javier
> > > > > > > > > > > Tirado
> > > > > > > > > > > > > > Sarti
> > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > > > > > > > It can be an alternative solution
> > to
> > > > move
> > > > > > > > > > > > > > kn-plugin-workflow
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > kogito-images (so there is not
> > longer
> > > > > > > dependency
> > > > > > > > > from
> > > > > > > > > > > > > tools
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > then build kogito-images after
> > > > > kogito-tools?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM
> > > > Enrique
> > > > > > > Gonzalez
> > > > > > > > > > > > > Martinez
> > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere
> > > > > Fernandez
> > > > > > > > > (apache)
> > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >> > I say +1 in order to move
> > forward
> > > > with
> > > > > > > the 10.
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45,
> > Alex
> > > > > > > Porcelli <
> > > > > > > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> > > I spent the last day or so
> > > working
> > > > > > > closely
> > > > > > > > > with
> > > > > > > > > > > > > Tiago,
> > > > > > > > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > > > > > > > >> > > options and getting deeper on
> > > the
> > > > > > > impact and
> > > > > > > > > > > > > > evaluating
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > > > > > > > >> > > procedure steps required. I
> > > agree
> > > > > with
> > > > > > > the
> > > > > > > > > > > proposal
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > most
> > > > > > > > > > > > > > > > > > > > > >> > > viable option for unblocking
> > the
> > > > 10
> > > > > > > release
> > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > > > > > > > reasonable
> > > > > > > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at
> > 3:45 PM
> > > > > Tiago
> > > > > > > Bento
> > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a
> > > > tl;dr
> > > > > this
> > > > > > > > > time,
> > > > > > > > > > > as
> > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > > matter
> > > > > > > > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > This email will take you <
> > 20
> > > > > minutes
> > > > > > > to
> > > > > > > > > read,
> > > > > > > > > > > > > > > according
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > As you may have followed on
> > a
> > > > > separate
> > > > > > > > > thread
> > > > > > > > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > > > > > > > >> > > > many of us were working
> > > towards
> > > > > > > removing a
> > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > > > > > >> > > > currently present between
> > > > > > > `kogito-apps`
> > > > > > > > > and
> > > > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > As
> > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > >> > > > progressed towards a
> > solution,
> > > > we
> > > > > kept
> > > > > > > > > > > finding the
> > > > > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll
> > > do a
> > > > > > > > > breakdown of
> > > > > > > > > > > the
> > > > > > > > > > > > > > > things
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Right now, even though we
> > > > started
> > > > > the
> > > > > > > > > effort
> > > > > > > > > > > to
> > > > > > > > > > > > > move
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`,
> > we
> > > > > haven't
> > > > > > > been
> > > > > > > > > > > able to
> > > > > > > > > > > > > > do
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > yet,
> > > > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > > > > > > > >> > > > been busy upgrading KIE
> > Tools
> > > to
> > > > > Java
> > > > > > > 17,
> > > > > > > > > > > Maven
> > > > > > > > > > > > > > 3.9.6,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with
> > Kogito
> > > > > Runtimes
> > > > > > > > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > > > >> > > > effort was concluded this
> > > > Monday,
> > > > > with
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >
> > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > > > > > > > .
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > The current scenario we have
> > > is:
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > > >> > > > |==> 02.
> > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > > >> > > > L |
> > > > > > > ==========================
> > > > > > > > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > > >> > > > |==> 07.
> > > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > `kie-tools`/extended-services
> > > > > > > > > > > depends
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev
> > > UIs
> > > > > to
> > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > would've
> > > > > > > > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > > >> > > > C |
> > > > > =====================
> > > > > > > > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > > >> > > > E |==> 07.
> > > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > > > > depends
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > > > > > > > depends
> > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > After moving the
> > > > > `kogito-swf-devmode`
> > > > > > > > > image to
> > > > > > > > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > > >> > > > 04.
> > > > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > > >> > > > Y |
> > > > > =====================
> > > > > > > > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > > >> > > > L |==> 07.
> > > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > > > > depends
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > `kogito-serverless-operator`
> > > > > > > > > > > depends
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Clearly, we have a much
> > bigger
> > > > > problem
> > > > > > > > > than a
> > > > > > > > > > > > > simple
> > > > > > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > After multiple conversations
> > > > with
> > > > > a
> > > > > > > lot of
> > > > > > > > > > > people,
> > > > > > > > > > > > > > > it's
> > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > > > >> > > > hard coming up with a simple
> > > > > solution
> > > > > > > that
> > > > > > > > > > > makes
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > possible
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > > > > > > > >> > > > Apache KIE in one shot,
> > while
> > > > > > > preserving
> > > > > > > > > the
> > > > > > > > > > > way
> > > > > > > > > > > > > > > > everyone
> > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> > > > contributing to the multiple
> > > > > > > repositories
> > > > > > > > > we
> > > > > > > > > > > have.
> > > > > > > > > > > > > > > More
> > > > > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > > > > > > > >> > > > while making this
> > assessment,
> > > I
> > > > > found
> > > > > > > more
> > > > > > > > > > > > > problems
> > > > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > > > > >> > > > perspective, block Apache
> > KIE
> > > > 10.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > In light of that difficulty,
> > > I'm
> > > > > > > coming
> > > > > > > > > > > forward
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > >> > > > the Apache KIE release
> > > process,
> > > > > so we
> > > > > > > can
> > > > > > > > > use
> > > > > > > > > > > > > > Apache's
> > > > > > > > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> > > > have a slower-paced,
> > in-depth
> > > > > debate
> > > > > > > about
> > > > > > > > > > > this
> > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > I'll lay out my entire
> > > > perspective
> > > > > > > about
> > > > > > > > > the
> > > > > > > > > > > > > current
> > > > > > > > > > > > > > > > > > situation
> > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > > > > > > > >> > > > codebase, as well as
> > problems
> > > I
> > > > > can
> > > > > > > > > currently
> > > > > > > > > > > see.
> > > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > > > > start
> > > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > > > > > > >> > > > analysis of the repositories
> > > and
> > > > > their
> > > > > > > > > > > purposes,
> > > > > > > > > > > > > > point
> > > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > > >> > > > problems that I believe are
> > > > > blocking
> > > > > > > our
> > > > > > > > > 10
> > > > > > > > > > > > > release,
> > > > > > > > > > > > > > > > > explain
> > > > > > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > > > > >> > > > proposal and discuss some
> > > > > > > consequences to
> > > > > > > > > > > what I'm
> > > > > > > > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, &
> > > KOGITO
> > > > > > > (count:
> > > > > > > > > 11)
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-kogito-pipelines @
> > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @
> > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner
> > @
> > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > incubator-kie-optaplanner-quickstarts @
> > > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-runtimes
> > > > @
> > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps
> > @
> > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-examples
> > > > @
> > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-images
> > > @
> > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > incubator-kie-kogito-serverless-operator @
> > > > > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs
> > @
> > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @
> > > > > `main-kogito`
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @
> > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-kogito-benchmarks
> > > > > @
> > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @
> > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @
> > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > (Issues only, README
> > > should
> > > > be
> > > > > > > > > updated @
> > > > > > > > > > > > > `main`.
> > > > > > > > > > > > > > > > Same
> > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-website @
> > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > (The Kogito website.
> > > > Develop &
> > > > > > > deploy
> > > > > > > > > at
> > > > > > > > > > > the
> > > > > > > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-website @
> > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > (The KIE website.
> > Develop
> > > @
> > > > > > > `main`.
> > > > > > > > > Push @
> > > > > > > > > > > > > > > `deploy`
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-online
> > > @
> > > > > > > `gh-pages`
> > > > > > > > > > > > > > > > > > > > > >> > > > (GitHub pages used to
> > host
> > > > > > > > > > > sandbox.kie.org
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > incubator-kie-kogito-online-staging
> > > > > > > @
> > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > > >> > > > (Same as above, but for
> > > > manual
> > > > > > > sanity
> > > > > > > > > > > checks
> > > > > > > > > > > > > > > during
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > I grouped the repositories
> > by
> > > > > > > category,
> > > > > > > > > and
> > > > > > > > > > > listed
> > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > in a
> > > > > > > > > > > > > > > > > > > > > >> > > > topological order. Keep in
> > > mind
> > > > > that
> > > > > > > when
> > > > > > > > > > > > > flattening
> > > > > > > > > > > > > > > > out a
> > > > > > > > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > > > > > > > >> > > > are multiple possibilities.
> > > For
> > > > > > > example,
> > > > > > > > > > > > > OptaPlanner
> > > > > > > > > > > > > > > > > > could've
> > > > > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > > >> > > > placed in any position after
> > > > > Drools.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Category A repos are what
> > I've
> > > > > been
> > > > > > > > > referring
> > > > > > > > > > > to
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> > > > > > > OptaPlanner
> > > > > > > > > is
> > > > > > > > > > > inside
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > > > >> > > > way these repositories
> > > reference
> > > > > each
> > > > > > > > > other
> > > > > > > > > > > are
> > > > > > > > > > > > > > > through
> > > > > > > > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More
> > specifically,
> > > > the
> > > > > > > > > 999-SNAPSHOT
> > > > > > > > > > > > > > > version.
> > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > > > > > > > >> > > > is well-known to the team,
> > and
> > > > > > > although
> > > > > > > > > > > flawed for
> > > > > > > > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > > > > > > > >> > > > and disruptive for people in
> > > > many
> > > > > > > > > different
> > > > > > > > > > > time
> > > > > > > > > > > > > > > zones,
> > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > > > > > >> > > > very comfortable for
> > everyone
> > > to
> > > > > work
> > > > > > > > > with, I
> > > > > > > > > > > > > > assume.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Contributions made to
> > > Category A
> > > > > have
> > > > > > > some
> > > > > > > > > > > > > dedicated
> > > > > > > > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > > > > > > >> > > > are, at least to some
> > extent,
> > > > > able to
> > > > > > > > > build
> > > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > > > > > >> > > > and verify that the codebase
> > > > will
> > > > > > > continue
> > > > > > > > > > > working
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > expected
> > > > > > > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > > > > >> > > > they're all merged. From
> > what
> > > I
> > > > > could
> > > > > > > > > gather,
> > > > > > > > > > > > > there
> > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > > >> > > > "sub-streams" currently
> > > > > configured for
> > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > PRs.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> > > > > > > kogito-apps,
> > > > > > > > > and
> > > > > > > > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > > > > > > > >> > > > - optaplanner, and
> > > > > > > optaplanner-quickstarts
> > > > > > > > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > > > > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > This means that sending
> > > > cross-repo
> > > > > > > PRs to
> > > > > > > > > any
> > > > > > > > > > > > > > > > combination
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > > > > >> > > > that are not part of the
> > same
> > > > > > > "sub-stream"
> > > > > > > > > > > cannot
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > verified
> > > > > > > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > > > > > > >> > > > merging, making our
> > > contribution
> > > > > model
> > > > > > > > > > > dependent
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > individual
> > > > > > > > > > > > > > > > > > > > > >> > > > contributors building stuff
> > on
> > > > > their
> > > > > > > > > machines
> > > > > > > > > > > to
> > > > > > > > > > > > > > > verify
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > > > > > >> > > > Note that I'm not that
> > > familiar
> > > > > with
> > > > > > > these
> > > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > > > > > > >> > > > someone correct me if I'm
> > > wrong.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Category B repos are what
> > I've
> > > > > been
> > > > > > > > > referring
> > > > > > > > > > > to
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > > > > > >> > > > stream. The first repo there
> > > is
> > > > a
> > > > > > > template
> > > > > > > > > > > > > > repository
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > > > > > > > >> > > > people starting projects
> > from
> > > > > scratch
> > > > > > > on
> > > > > > > > > KIE
> > > > > > > > > > > > > > Sandbox,
> > > > > > > > > > > > > > > > > > similar
> > > > > > > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > > > > >> > > > Maven archetype, if you
> > will.
> > > > The
> > > > > > > other
> > > > > > > > > one
> > > > > > > > > > > is the
> > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > Tools
> > > > > > > > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > > > > > > > >> > > > a polyglot monorepo with
> > > `pnpm`
> > > > > as its
> > > > > > > > > build
> > > > > > > > > > > > > system.
> > > > > > > > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries
> > and
> > > > > apps,
> > > > > > > > > > > TypeScript
> > > > > > > > > > > > > > > > libraries
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > > > > > > > >> > > > apps, Docker images, and
> > Helm
> > > > > charts.
> > > > > > > The
> > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > >> > > > configured to work with
> > sparse
> > > > > > > checkouts
> > > > > > > > > and
> > > > > > > > > > > can
> > > > > > > > > > > > > do
> > > > > > > > > > > > > > > > > partial
> > > > > > > > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > > > > > > > >> > > > Category B repos refer to
> > > > > Category A
> > > > > > > repos
> > > > > > > > > > > through
> > > > > > > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new
> > > > > mechanism we
> > > > > > > > > recently
> > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > > > > >> > > > build and publish immutable,
> > > > > > > persistent
> > > > > > > > > > > artifacts
> > > > > > > > > > > > > > > under
> > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > > > > > > >> > > > following the
> > > > > 999-YYYYMMDD-SNAPSHOT
> > > > > > > > > format,
> > > > > > > > > > > > > > published
> > > > > > > > > > > > > > > > > weekly
> > > > > > > > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped
> > > > > SNAPSHOTs
> > > > > > > are an
> > > > > > > > > > > > > evolution
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > > > > > >> > > > releases, as we're now
> > > targeting
> > > > > one
> > > > > > > > > release
> > > > > > > > > > > for
> > > > > > > > > > > > > all
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > > > > > > >> > > > we can't have Kogito
> > releases
> > > > > anymore.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > An important note here is
> > that
> > > > > > > Category B
> > > > > > > > > > > > > > repositories
> > > > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > > >> > > > historically kept out of any
> > > > > > > automations
> > > > > > > > > we
> > > > > > > > > > > used
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > have,
> > > > > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > > > > > >> > > > when Kogito started and we
> > had
> > > > the
> > > > > > > > > Business
> > > > > > > > > > > > > Central
> > > > > > > > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > > > > > > > >> > > > still going on. For this
> > > reason,
> > > > > > > Category
> > > > > > > > > B
> > > > > > > > > > > > > projects
> > > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > > > > > > > >> > > > their own automations, based
> > > on
> > > > > GitHub
> > > > > > > > > > > Actions.
> > > > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > > > > > > > >> > > > always depended on Category
> > A
> > > > > repos
> > > > > > > using
> > > > > > > > > > > fixed
> > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > If
> > > > > > > > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > > > > > > > >> > > > B repos have had adopted
> > > mutable
> > > > > > > > > SNAPSHOTs,
> > > > > > > > > > > > > breaking
> > > > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > > Category A repositories
> > > would've
> > > > > had
> > > > > > > the
> > > > > > > > > > > potential
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > break
> > > > > > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > > > > > >> > > > silently, leaving Category B
> > > > with
> > > > > a
> > > > > > > broken
> > > > > > > > > > > > > > development
> > > > > > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> > > > introducing unpleasant
> > > surprises
> > > > > for
> > > > > > > > > > > maintainers
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > > > > > > > >> > > > as historically Category A
> > > > > > > contributors
> > > > > > > > > were
> > > > > > > > > > > not
> > > > > > > > > > > > > > > > familiar
> > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Contributions made to
> > > Category B
> > > > > > > repos go
> > > > > > > > > > > through
> > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > > > > > > > >> > > > workflow that builds the
> > > > relevant
> > > > > > > part of
> > > > > > > > > the
> > > > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > > > > >> > > > the changes introduced.
> > > Changes
> > > > > made
> > > > > > > to
> > > > > > > > > the
> > > > > > > > > > > > > pipeline
> > > > > > > > > > > > > > > > > itself
> > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > > > > > > > >> > > > picked up as part of PRs,
> > > > > allowing us
> > > > > > > to
> > > > > > > > > do
> > > > > > > > > > > things
> > > > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > > > > > > > >> > > > bumping the Node.js version,
> > > for
> > > > > > > example.
> > > > > > > > > More
> > > > > > > > > > > > > > > > > importantly,
> > > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > > > > > > > >> > > > us to upgrade the repository
> > > to
> > > > a
> > > > > new
> > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > > > > > >> > > > with the changes necessary
> > to
> > > > > make it
> > > > > > > stay
> > > > > > > > > > > green.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > This setup, however, makes
> > it
> > > > > > > impossible
> > > > > > > > > to
> > > > > > > > > > > have
> > > > > > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > > > > > >> > > > involving Category A and
> > > > Category
> > > > > B
> > > > > > > > > > > > > simultaneously,
> > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Category C repos are kind of
> > > > > floating
> > > > > > > > > around,
> > > > > > > > > > > and
> > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > > > > > >> > > > there's much activity going
> > on
> > > > > there.
> > > > > > > > > > > Regardless,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > >> > > > Apache KIE, they will be
> > part
> > > of
> > > > > our
> > > > > > > > > release,
> > > > > > > > > > > so I
> > > > > > > > > > > > > > > > listed
> > > > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > > > > > >> > > > to take them into
> > > consideration
> > > > > too.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Category D is self
> > > explanatory.
> > > > > > > There's
> > > > > > > > > only
> > > > > > > > > > > one
> > > > > > > > > > > > > > repo
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > has
> > > > > > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > > > > > >> > > > been marked for being
> > > archived.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Category E are repos that do
> > > not
> > > > > host
> > > > > > > code
> > > > > > > > > > > > > directly,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > > > > > > > >> > > > organizational entities, or
> > > host
> > > > > > > websites,
> > > > > > > > > > > that
> > > > > > > > > > > > > > > > currently
> > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > This lack of unification
> > > between
> > > > > > > Category
> > > > > > > > > A
> > > > > > > > > > > and
> > > > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > > is,
> > > > > > > > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > > > > > > > >> > > > what allowed us to introduce
> > > the
> > > > > > > infamous
> > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools` and
> > `kogito-apps`,
> > > > > which
> > > > > > > we
> > > > > > > > > now
> > > > > > > > > > > can
> > > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > > > > > > > >> > > > dependency between Category
> > A
> > > > and
> > > > > > > > > Category B.
> > > > > > > > > > > The
> > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > > see
> > > > > > > > > > > > > > > > > > > it,
> > > > > > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > > > >> > > > had a single pipeline,
> > > building
> > > > > > > everything
> > > > > > > > > > > from
> > > > > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws
> > > would've
> > > > > never
> > > > > > > > > been
> > > > > > > > > > > > > > > introduced,
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > >> > > > wouldn't be having this huge
> > > > > problem
> > > > > > > in
> > > > > > > > > our
> > > > > > > > > > > hands
> > > > > > > > > > > > > > > right
> > > > > > > > > > > > > > > > > now.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > My proposal for the Apache
> > KIE
> > > > > release
> > > > > > > > > process
> > > > > > > > > > > > > sees
> > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > > > lack
> > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > >> > > > unification as a central
> > > > problem,
> > > > > not
> > > > > > > > > only for
> > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > > >> > > > particular, but for the
> > > > community
> > > > > as a
> > > > > > > > > whole.
> > > > > > > > > > > It
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > belief
> > > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > > > >> > > > are all under the same roof,
> > > and
> > > > > that
> > > > > > > no
> > > > > > > > > > > > > > contribution
> > > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > > > >> > > > allowed to break any part of
> > > our
> > > > > > > codebase.
> > > > > > > > > > > With
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > > > > > > > >> > > > of code, and hopefully
> > number
> > > of
> > > > > > > > > contributors
> > > > > > > > > > > too,
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > > > > > > > >> > > > counting on "common sense"
> > to
> > > > > avoid
> > > > > > > > > breaking
> > > > > > > > > > > > > things.
> > > > > > > > > > > > > > > > We're
> > > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > > > > > > > >> > > > after all, and it is our job
> > > to
> > > > > have
> > > > > > > > > > > mechanisms in
> > > > > > > > > > > > > > > place
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > > > > > >> > > > from unwillingly making
> > > > mistakes.
> > > > > > > > > Especially
> > > > > > > > > > > when
> > > > > > > > > > > > > > > these
> > > > > > > > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > > > > > > > >> > > > impact on parts of the
> > > codebase
> > > > > that
> > > > > > > we,
> > > > > > > > > > > > > > individually,
> > > > > > > > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT
> > > NOW
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @
> > > > > `kogito-apps`
> > > > > > > > > depending
> > > > > > > > > > > on
> > > > > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF
> > > > images
> > > > > @
> > > > > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools
> > `0.32.0`.
> > > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > P3. DashBuilder @
> > `kie-tools`
> > > > > > > depending on
> > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at
> > > version
> > > > > > > > > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > P4. Multiple packages @
> > > > > `kogito-apps`
> > > > > > > > > > > depending on
> > > > > > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > > > > > >> > > > Explainability
> > `1.22.1.Final`.
> > > > > > > > > > > > > > > > > > > > > >> > > > * This module was removed
> > from
> > > > > the KIE
> > > > > > > > > > > codebase
> > > > > > > > > > > > > > here:
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > > > > > > > > ,
> > > > > > > > > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > > > > > > > > >> > > > * This new repo depends on
> > > > Kogito
> > > > > and
> > > > > > > > > > > OptaPlanner,
> > > > > > > > > > > > > > > > > pointing
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > older
> > > > > > > > > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > P5.
> > > > > > > > > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> > > > > > > `2.15.3.Final`.
> > > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > P6. Category C repos are out
> > > of
> > > > > date
> > > > > > > and
> > > > > > > > > not
> > > > > > > > > > > part
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > > > > > > > > >> > > > *
> > > > incubator-kie-kogito-benchmarks:
> > > > > > > > > (Current
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > > > > > >> > > > depending on Kogito without
> > a
> > > > > specific
> > > > > > > > > > > version,
> > > > > > > > > > > > > only
> > > > > > > > > > > > > > > by
> > > > > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks:
> > > > > (Current
> > > > > > > > > version
> > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > > > > > >> > > > pointing to Drools
> > > 999-SNAPSHOT
> > > > > and
> > > > > > > > > > > OptaPlanner
> > > > > > > > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > P7.
> > > > > > > > > `kie-tools`/packages/kn-plugin-workflow
> > > > > > > > > > > has
> > > > > > > > > > > > > its
> > > > > > > > > > > > > > > E2E
> > > > > > > > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > > > > > > > > >> > > > upgrading to
> > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2
> > > > have
> > > > > the
> > > > > > > same
> > > > > > > > > > > > > solution,
> > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > > > > > > > >> > > > suffer from the circular
> > > > > dependency
> > > > > > > > > between
> > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > > > > > > > > >> > > > As Category A and Category B
> > > are
> > > > > both
> > > > > > > > > streams
> > > > > > > > > > > that
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > > > >> > > > active, I see this as a
> > > blocker,
> > > > > as
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > > > > > > > > contributions
> > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > >> > > > cannot be done, given that
> > > > > Category A
> > > > > > > > > depends
> > > > > > > > > > > on
> > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > P3 and P4, although not
> > ideal,
> > > > > can be
> > > > > > > > > > > understood
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > technical
> > > > > > > > > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > > > > > > > > >> > > > Depending on unmaintained
> > > > > projects is
> > > > > > > > > > > something
> > > > > > > > > > > > > > we'll
> > > > > > > > > > > > > > > > > always
> > > > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > P5 and P6 are easily
> > fixable,
> > > as
> > > > > it's
> > > > > > > > > just a
> > > > > > > > > > > > > matter
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > making
> > > > > > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > P7 is an isolated problem
> > that
> > > > > won't
> > > > > > > > > impact
> > > > > > > > > > > the
> > > > > > > > > > > > > > > > structure
> > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > > > > > > > > >> > > > that we're talking about
> > here,
> > > > > but it
> > > > > > > is a
> > > > > > > > > > > > > > regression
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be
> > > > ignored
> > > > > for
> > > > > > > > > Apache
> > > > > > > > > > > KIE
> > > > > > > > > > > > > 10,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the
> > > only
> > > > > > > problems
> > > > > > > > > > > left to
> > > > > > > > > > > > > > > > discuss
> > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> > > > P2, which can't be done
> > > without
> > > > a
> > > > > > > proper
> > > > > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > I'll try to be very
> > meticulous
> > > > > here,
> > > > > > > since
> > > > > > > > > > > from my
> > > > > > > > > > > > > > > > > > experience,
> > > > > > > > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > > > > > > > >> > > > little miscalculation can
> > lead
> > > > to
> > > > > our
> > > > > > > > > release
> > > > > > > > > > > not
> > > > > > > > > > > > > > > > working
> > > > > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > >> > > > end. To try and avoid that
> > as
> > > > > much as
> > > > > > > > > > > possible,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > > > >> > > > can to have a successful
> > > Apache
> > > > > KIE 10
> > > > > > > > > > > release,
> > > > > > > > > > > > > bear
> > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > me.
> > > > > > > > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > > > > > > > > >> > > > out a timeline of events
> > that
> > > > > need to
> > > > > > > > > happen
> > > > > > > > > > > in
> > > > > > > > > > > > > > order
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > > > > > > > > >> > > > to be published, with all
> > > > > artifacts
> > > > > > > > > ending up
> > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > right
> > > > > > > > > > > > > > > > > > > > places,
> > > > > > > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > > > > > > >> > > > first, we need to solve
> > > problems
> > > > > P1
> > > > > > > and
> > > > > > > > > P2.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > As you saw at the beginning
> > of
> > > > > this
> > > > > > > email,
> > > > > > > > > > > all the
> > > > > > > > > > > > > > > > > attempts
> > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > made
> > > > > > > > > > > > > > > > > > > > > >> > > > left us with the circular
> > > > > dependency
> > > > > > > > > showing
> > > > > > > > > > > up
> > > > > > > > > > > > > at a
> > > > > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > > > > > > > > >> > > > but something all these
> > places
> > > > > have in
> > > > > > > > > common
> > > > > > > > > > > is
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > > >> > > > after kogito-apps, and
> > before
> > > to
> > > > > > > Category
> > > > > > > > > B.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > The first part of my
> > proposal
> > > is
> > > > > the
> > > > > > > > > > > following:
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > S1. We keep the original
> > plan
> > > of
> > > > > > > moving
> > > > > > > > > the
> > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > > UIs
> > > > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-apps` to
> > `kie-tools`,
> > > > > together
> > > > > > > > > with
> > > > > > > > > > > > > > Management
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > Task
> > > > > > > > > > > > > > > > > > > > > >> > > > consoles from
> > `kogito-images`
> > > to
> > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > > > > > >> > > > S2. We move the
> > > > > `kogito-swf-devmode`
> > > > > > > and
> > > > > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > > > > > > >> > > > from `kogito-images` to
> > > > > `kie-tools`
> > > > > > > too.
> > > > > > > > > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > > > > > > > > `kogito-serverless-operator`
> > > > > > > > > > > > > > > repo
> > > > > > > > > > > > > > > > > > > inside
> > > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > > > > > > > > >> > > > package on `kie-tools`,
> > > keeping
> > > > > Git
> > > > > > > > > history.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3
> > > > together
> > > > > > > solve
> > > > > > > > > > > problems
> > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > P2.
> > > > > > > > > > > > > > > > > > Of
> > > > > > > > > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > This doesn't come without
> > > > > > > consequences, of
> > > > > > > > > > > course,
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > images,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > > > > would be
> > > > > > > > > moving
> > > > > > > > > > > from
> > > > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> > > > Category B. This move would
> > > make
> > > > > them
> > > > > > > > > have to
> > > > > > > > > > > > > > > reference
> > > > > > > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > > > > > > >> > > > repos through timestamped
> > > > > SNAPSHOTs.
> > > > > > > Since
> > > > > > > > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > > are
> > > > > > > already
> > > > > > > > > > > their own
> > > > > > > > > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > > > > > > > > >> > > > Category A, though,
> > > > contributions
> > > > > > > made in
> > > > > > > > > a
> > > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > > > > fashion
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > > > > > > > > >> > > > "sub-stream" will continue
> > > being
> > > > > > > > > possible, now
> > > > > > > > > > > > > via a
> > > > > > > > > > > > > > > > > single
> > > > > > > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs
> > > > > between
> > > > > > > > > Category
> > > > > > > > > > > A and
> > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > > > > >> > > > continue not being possible,
> > > > and a
> > > > > > > 1-week
> > > > > > > > > > > delay
> > > > > > > > > > > > > > > between
> > > > > > > > > > > > > > > > > > > merging
> > > > > > > > > > > > > > > > > > > > > >> > > > something on Category A and
> > > > using
> > > > > it
> > > > > > > on
> > > > > > > > > > > Category B
> > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > still
> > > > > > > > > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > It's worth mentioning that
> > > > > > > `kie-tools`,
> > > > > > > > > > > however,
> > > > > > > > > > > > > > does
> > > > > > > > > > > > > > > > > allow
> > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > > > > > > > > >> > > > checkouts and partial
> > builds,
> > > so
> > > > > > > working
> > > > > > > > > with
> > > > > > > > > > > a
> > > > > > > > > > > > > > subset
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > > > > > >> > > > is possible and encouraged.
> > > > Making
> > > > > > > changes
> > > > > > > > > > > only to
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > `packages/kn-plugin-workflow`,
> > > > for
> > > > > > > > > example,
> > > > > > > > > > > will
> > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you
> > > can
> > > > > see
> > > > > > > here:
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > > > > > >> > > > We're not compromising when
> > > > > running
> > > > > > > > > partial
> > > > > > > > > > > builds
> > > > > > > > > > > > > > > too.
> > > > > > > > > > > > > > > > We
> > > > > > > > > > > > > > > > > > > know
> > > > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > >> > > > the entire repo will
> > continue
> > > > > working
> > > > > > > even
> > > > > > > > > > > after
> > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > > building a
> > > > > > > > > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > > > > > > > > >> > > > subset of the changes. Doing
> > > > > partial
> > > > > > > or
> > > > > > > > > full
> > > > > > > > > > > > > builds
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > > > > > > > > >> > > > determined by the changes
> > of a
> > > > PR.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Keep in mind that, even
> > though
> > > > I'm
> > > > > > > > > proposing
> > > > > > > > > > > we
> > > > > > > > > > > > > > move a
> > > > > > > > > > > > > > > > > bunch
> > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > >> > > > additional stuff into
> > > > > `kie-tools`, I
> > > > > > > see
> > > > > > > > > this
> > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > > > > > > > > >> > > > for our codebase.
> > `kie-tools`
> > > > > would
> > > > > > > host
> > > > > > > > > some
> > > > > > > > > > > > > > > additional
> > > > > > > > > > > > > > > > > > stuff
> > > > > > > > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can
> > > > > release and
> > > > > > > > > > > continue
> > > > > > > > > > > > > > moving
> > > > > > > > > > > > > > > > > > > forward.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > As I mentioned on other
> > > places,
> > > > > > > > > `kie-tools`
> > > > > > > > > > > > > became a
> > > > > > > > > > > > > > > > > > polyglot
> > > > > > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > > > > > >> > > > out of necessity, and
> > although
> > > > I'm
> > > > > > > really
> > > > > > > > > > > proud of
> > > > > > > > > > > > > > > what
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > > > > > > > > >> > > > there so far, I don't think
> > > > > > > `kie-tools`
> > > > > > > > > has a
> > > > > > > > > > > > > setup
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > > > > > > > > >> > > > for all the different
> > nuances
> > > > that
> > > > > > > > > compose our
> > > > > > > > > > > > > > > > community.
> > > > > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > > > > > > >> > > > aware that a polyglot
> > monorepo
> > > > > that
> > > > > > > does
> > > > > > > > > not
> > > > > > > > > > > > > follow
> > > > > > > > > > > > > > > > > > widespread
> > > > > > > > > > > > > > > > > > > > > >> > > > conventions will scare some
> > > > people
> > > > > > > away,
> > > > > > > > > and
> > > > > > > > > > > as
> > > > > > > > > > > > > much
> > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > we've
> > > > > > > > > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > > > > >> > > > make build instructions
> > clear,
> > > > we
> > > > > > > can't
> > > > > > > > > > > always get
> > > > > > > > > > > > > > > past
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > > > > > > > > >> > > > some people have towards the
> > > > > > > "front-end"
> > > > > > > > > > > > > ecosystem.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > With all that said, I keep
> > > > > thinking
> > > > > > > this
> > > > > > > > > is
> > > > > > > > > > > the
> > > > > > > > > > > > > best
> > > > > > > > > > > > > > > > > course
> > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > > > > > > > > >> > > > for us right now. We keep
> > most
> > > > of
> > > > > our
> > > > > > > > > stuff
> > > > > > > > > > > > > > unchanged,
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > > > >> > > > release, and we have a
> > working
> > > > > setup
> > > > > > > that
> > > > > > > > > will
> > > > > > > > > > > > > suit
> > > > > > > > > > > > > > us
> > > > > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > >> > > > discuss and reach a
> > conclusion
> > > > > > > regarding
> > > > > > > > > the
> > > > > > > > > > > > > future
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Let me paint a quick picture
> > > > here
> > > > > of
> > > > > > > what
> > > > > > > > > our
> > > > > > > > > > > code
> > > > > > > > > > > > > > > base
> > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > > > > > > > >> > > > like, repository-wise, if my
> > > > > proposal
> > > > > > > is
> > > > > > > > > > > accepted:
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-drools
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-optaplanner
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-kogito-docs
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-docs
> > > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-benchmarks
> > > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > > >> > > > B
> > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > > >> > > > B
> > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > > >> > > > D
> > > > > > > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > incubator-kie-issues
> > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > incubator-kie-kogito-website
> > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > incubator-kie-website
> > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > incubator-kie-kogito-online
> > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > * Category C becomes part of
> > > > > Category
> > > > > > > A,
> > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > > > moves
> > > > > > > > > entirely
> > > > > > > > > > > inside
> > > > > > > > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > > > > > >> > > > * With
> > > > > `kogito-swf-{builder,devmode}`
> > > > > > > > > images
> > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > > > > inside
> > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > > there
> > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > > > > > > > > >> > > > anymore, as inside
> > > `kie-tools`,
> > > > > we can
> > > > > > > > > > > granularly
> > > > > > > > > > > > > > > build:
> > > > > > > > > > > > > > > > > > > > > >> > > > 1.
> > > > > > > > > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > > > > > >> > > > 2.
> > > > > > > packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > > > > > >> > > > 3.
> > > > packages/sonataflow-images
> > > > > > > > > (containing
> > > > > > > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > > > > > > > > >> > > > 4.
> > > > > packages/sonataflow-operator
> > > > > > > > > (contents
> > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > `kogito-serverless-operator`)
> > > > > > > > > > > > > > > > > > > > > >> > > > 5.
> > > > > packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > The second part of the
> > > proposal
> > > > > is the
> > > > > > > > > release
> > > > > > > > > > > > > > process
> > > > > > > > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > > > > > > > >> > > > assuming the structure above
> > > is
> > > > > what
> > > > > > > we
> > > > > > > > > have.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > 1. Define a timestamped
> > > SNAPSHOT
> > > > > to be
> > > > > > > > > used as
> > > > > > > > > > > > > > cutting
> > > > > > > > > > > > > > > > > point
> > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > > > > > > > > >> > > > 2. Update Category B repos
> > to
> > > > > point to
> > > > > > > > > this
> > > > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > > > > >> > > > verify that everything is
> > > > working.
> > > > > > > > > > > > > > > > > > > > > >> > > > 3. At this point, with
> > > > everything
> > > > > > > > > working, we
> > > > > > > > > > > can
> > > > > > > > > > > > > > > branch
> > > > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from
> > the
> > > > > > > timestamped
> > > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > tag,
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > > > > > > > > >> > > > 4. All Category A and
> > > Category B
> > > > > repos
> > > > > > > > > update
> > > > > > > > > > > > > their
> > > > > > > > > > > > > > > > > versions
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x`
> > > > > branches.
> > > > > > > > > > > > > > > > > > > > > >> > > > 5. Update Category B repos
> > to
> > > > > point to
> > > > > > > > > > > Category A
> > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > > > > > > > > >> > > > 6. At this point, we can
> > vote
> > > on
> > > > > the
> > > > > > > > > release
> > > > > > > > > > > based
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > > > > > > > > >> > > > branches, given we don't
> > > expect
> > > > > any
> > > > > > > code
> > > > > > > > > > > changes
> > > > > > > > > > > > > > > > anymore.
> > > > > > > > > > > > > > > > > > > > > >> > > > 7. After voting passes,
> > we're
> > > > > good to
> > > > > > > > > start
> > > > > > > > > > > the
> > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > > > > > > > >> > > > 8. Category A repos follow
> > > their
> > > > > > > > > > > manual/automated
> > > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x`
> > > branch.
> > > > > Tags
> > > > > > > > > pushed
> > > > > > > > > > > to
> > > > > > > > > > > > > Git,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to their
> > > > > registries.
> > > > > > > > > > > > > > > > > > > > > >> > > > 9. We wait a little bit for
> > > > > Category A
> > > > > > > > > > > artifacts
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > > > > > > > > >> > > > 10. Category B repos follow
> > > > their
> > > > > > > > > > > manual/automated
> > > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x`
> > > branch.
> > > > > Tags
> > > > > > > > > pushed
> > > > > > > > > > > to
> > > > > > > > > > > > > Git,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to their
> > > > > registries.
> > > > > > > > > > > > > > > > > > > > > >> > > > 11. Category D repos are
> > > > ignored.
> > > > > > > > > > > > > > > > > > > > > >> > > > 12. Category E repos can be
> > > > > manually
> > > > > > > > > tagged
> > > > > > > > > > > with
> > > > > > > > > > > > > > > 10.0.0
> > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > More needs to be discussed
> > if
> > > > > we're
> > > > > > > > > planning
> > > > > > > > > > > to
> > > > > > > > > > > > > > > maintain
> > > > > > > > > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > > > > > > > > >> > > > release streams in parallel,
> > > > but I
> > > > > > > guess
> > > > > > > > > it
> > > > > > > > > > > can
> > > > > > > > > > > > > wait
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Thank you for reading, and
> > I'm
> > > > > looking
> > > > > > > > > > > forward to
> > > > > > > > > > > > > > > > hearing
> > > > > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Of course, alternative
> > > solutions
> > > > > are
> > > > > > > > > possible.
> > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > email,
> > > > > > > > > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > > > > > > > > >> > > > summarizes my view of how we
> > > > > should
> > > > > > > > > attack the
> > > > > > > > > > > > > > > problem,
> > > > > > > > > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > > > > > > > > >> > > > disruption, required effort,
> > > the
> > > > > > > release
> > > > > > > > > > > process
> > > > > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > > > > > > > > >> > > > Feel free to propose
> > > > alternatives.
> > > > > > > This is
> > > > > > > > > > > not a
> > > > > > > > > > > > > > > voting
> > > > > > > > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > > > > > > > > >> > > > For additional commands,
> > > e-mail:
> > > > > > > > > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <al...@porcelli.me>.
Francisco,
Unfortunately we just learned all this very recently… and, as we keep
digging more, we keep finding more (new dependencies between images and
tools has been found on serverless workflow).
I’d argue that this discussion is in the end positive, because we all could
realize the importance of CI and the required need to organize codebase in
a more sustainable way.
On Thu, Mar 14, 2024 at 1:43 PM Francisco Javier Tirado Sarti <
ftirados@redhat.com> wrote:
> Hi Jan
> Yes, that's why I was also discussing the suitability of timestamped
> snapshots.
> For me, both amplification of tools repo with unrelated code and
> timestamped snapshots are against fixed snapshot and multi repo philosophy
> employed in the rest of the project (it will be far easier from CI
> perspective to have just one huge repo containing drools, runtimes, apps
> and examples, but we are not doing that)
> Therefore we are kind of sanctioning two different philosophies in our
> first apache release. Since there is apparently no other alternative with
> the resources we have, we will have to release it with this discrepancy.
> But it is sad and I think we should learn from this experience to avoid
> repeating it in the future. In my opinion, this proposal should have been
> shared long before to not make it a fait accompli.
>
> On Thu, Mar 14, 2024 at 6:18 PM Jan Šťastný <js...@apache.org> wrote:
>
> > Hello,
> > I'll try to summarize the challenges I am aware of in relation to CI at
> the
> > moment and with the proposals.
> >
> > (I am referring to projects forming the build chain as upstream <->
> > downstream depending on their placing in the overall chain.)
> >
> > Current state:
> > Category A projects:
> > - We don't have one, but rather 3 sets of pipelines for project groups:
> > drools, kogito and optaplanner, all these three utilizing a combination
> of
> > GHA (mostly PR checks) and Jenkins pipelines based on
> > apache/incubator-kie-kogito-pipelines framework (kogito-pipelines FW).
> > - For these builds, we use build-chain tool, which allows to define
> > cross-repository relations between projects, clone repositories and run
> > custom commands in each of those, depending in what part of the build
> chain
> > (considering the project triggering the build) they are invoked
> (upstream,
> > downstream, current). Examples of the build-chain project dependencies
> > configuration Tiago provided in the first email. Build-chain is a
> powerful
> > tool, though we have limited knowledge (Roberto being the sole
> contributor
> > of fixes since our move to ASF).
> > - As part of the kogito pipeline kogito-images and *-operator jobs are
> > attached, but relation to repositories earlier up the chain is either
> > assumed (building from main branch of kogito-apps) or loose (building
> > kogito-examples from main-nightly branch, which is created in preceding
> > kogito-examples nightly build). It's not part of PR checks for
> repositories
> > up the stream.
> >
> > Category B projects:
> > - We have a unique solution based mainly on GHA, but recently also some
> > parts (is it a backup?) in ASF Jenkins, but NOT using the
> kogito-pipelines
> > FW.
> >
> > Category C projects:
> > - There are loosely managed jobs for *-benchmarks repositories, just a
> > matter of updating versions, easily manageable - won't discuss further.
> >
> > Current gaps:
> >
> > Category A projects:
> > - Generally the current jenkins solution for PR checks is lacking, we
> have
> > just a single kind of PR check, not allowing custom triggers (e.g. by
> > comments) or various modes (like quarkus native build).
> > - We don't have downstream builds as part of PR checks.
> > - We build all in a single job. Which has resulted in execution time
> over 8
> > hours which was not bearable. Thus we reduced the build scope to sort of
> > compile downstream builds - we run tests for repositories that are part
> of
> > the PR, but their dependents (coming after them) are only run without
> > tests.
> > - With the introduction of unified SNAPSHOTs we have not fully adjusted
> for
> > this in our pipelines, leaving out relations like optaplanner -> drools
> and
> > kogito-apps -> optaplanner - so problems will be missed in case of
> related
> > PRs. This SNAPSHOT version unification indicates that instead of 3
> distinct
> > buildchain configurations, we should now switch to a single one,
> especially
> > for the sake of unification.
> > - Part of the repositories (starting with kogito-images) are not attached
> > in the build-chain build at all, but are rather consecutively executed
> > pipelines relying on publishing artifacts for consumption downstream.
> >
> > Proposal assessment:
> > - Almost any repository could be part of the build-chain configuration,
> > complex invocations can be hidden e.g. using make.
> > - Any changes to PR checks should have the following prerequisite not to
> > increase complexity and to limit execution times: moving of all PR checks
> > into GHA, introduction of isolated limited-scope PR checks, on-demand
> full
> > downstream build.
> > - Timestamped SNAPSHOTs consumed by kie-tools would call against
> attaching
> > kie-tools into build-chain of drools/kogito, because we would be running
> PR
> > checks/nightly against main which might differ from the timestamped
> > SNAPSHOT. So this seems like either/or decision to me.
> > - Build-chain would probably not be able to replicate the fine-grained
> > build execution based on the changes in PR as kie-tools currently has in
> > place.
> > - It's not clear to me how/if we could generally limit scope of execution
> > in downstream builds depending on scope of upstream repository changes.
> > - Community CI has really limited human resources, I personally switched
> to
> > an ad-hoc way of working on that, only when something breaks.
> > - It's not clear to me how a build-chain would work in terms of
> > consuming/passing artifacts outside of maven projects and artifacts.
> > - It's fair to say that we have SMEs for CI/build in Category A (engines
> or
> > cloud), Category B, but I don't think there's anyone knowing deep
> internals
> > of all, to be able to provide a reliable estimate of efforts involved in
> > bigger refactoring.
> >
> > Summary:
> > I don't see an easy way how a simple change in CI would help to unblock
> the
> > current situation. Considering Tiago's proposal, timestamped SNAPSHOTs
> > already in place, assumed relative simplicity of making the components
> part
> > of kie-tools build ...
> >
> > +1 from me
> >
> > Thanks.
> > Best Regards
> > Jan
> >
> >
> >
> >
> >
> >
> > On Thu, 14 Mar 2024 at 11:24, Francisco Javier Tirado Sarti <
> > ftirados@redhat.com> wrote:
> >
> > > Hi Tiago, Thanks for the detailed explanation
> > > Actually, for tooling, where there is not strong dependency (as between
> > > engine code in runtime and kie server api in drools), the fixed
> snapshot
> > > mechanism will work pretty well, in my opinion.
> > > On one side, an example that depends on devui will not fail to compile
> > > because the snapshot is old. The contrary is also true, if we add a new
> > > functionality in the server side that is going to be used by any tool,
> > the
> > > worst that might happen is that the functionality is not there in the
> old
> > > snapshot, but it wont block tooling compilation (obviously if you need
> > that
> > > functionality to test a new UI feature, you will need the update
> > snapshot,
> > > but that's expected and I guess is also happening now, you need to wait
> > for
> > > the server artifact to be published on Maven)
> > > Because of that loose dependency, tooling can be run, as it is, as an
> > > almost completely separate project but also because of that, I feel it
> > > might be easily integrated (except for CI changes, which are always
> > > delicate) with the rest of the repos to achieve a single release
> number,
> > > because, if all repos use the same snapshot, as far as there is one
> > > snapshot, in the day by day experience everything will normally
> compile.
> > > I think we agree that the natural place of tooling in the dependency
> > chain
> > > is after apps (service) and before images. With that in mind and if we
> > > wholly embrace the consequence of being a single release, in my
> opinion,
> > it
> > > means that tooling become one more repo (no A no B category), which
> use
> > a
> > > fixed snapshot as the rest, and it is subject to the need to eventually
> > > wait for the updated snapshot (or in case you cannot wait, a local full
> > > build), in the unlikely case there is a change that blocks its local
> > > compilation. The implication of this is that the development cycle that
> > is
> > > implicit in your proposal to use a "fixed snapshot" in category A repos
> > no
> > > longer apply.
> > > This means no time to adjust, which can sound like an herexy, but, if
> > there
> > > is no need for a gap between drools and runtimes, why is there a need
> > for a
> > > gap between tooling and apps (services)? (I think we agree a Java API
> > > dependency is stronger than a REST API) Do we have a real precedent
> that
> > > justify that? I kind of feel that here we are converting an old habit
> > into
> > > an axiomatic need (probably because Im lacking context)
> > > Now my proposal for CI, we do not really need a single stream right
> now.
> > We
> > > can keep the current kogito stream as it is, except for images, and
> > > integrate tooling into the stream that is now used for the operator
> (the
> > > assumption here is that a change in drools-runtimes hardly breaks the
> > tools
> > > and in any case that is already happening, so we do not lose anything)
> > >
> > >
> > > On Wed, Mar 13, 2024 at 8:18 PM ricardo zanini fernandes <
> > > ricardozanini@gmail.com> wrote:
> > >
> > > > Hey Tiago, thanks for the insights, I appreciate it.
> > > >
> > > > Just one thing regarding building from kie-tools one module that
> images
> > > > need to sync changes. That might happen, of course. If I see a
> problem
> > in
> > > > devui, I just report it in the tools repo, we work on the bug, and in
> > the
> > > > next image build we get the changes. By the nature of the
> > > operator/images,
> > > > such changes won't impact our builds. What impact our builds are
> > > > self-contained on those repos or work made in the engines, where we
> > rely
> > > on
> > > > Snapshots.
> > > >
> > > > I understand your concern and it's a valid point, but in practice,
> it's
> > > not
> > > > what happens. We can live with the latest released version from npm
> > > > packages during the dev phase without any problems. From the
> > > > images/operator perspective, they are yet another package I need to
> > > install
> > > > on my container. Like `cat` or `jq`.
> > > >
> > > > But we need to sit down and try to understand our boundaries and how
> to
> > > do
> > > > integration tests based on them. For example, deploying a devmode
> > > workflow
> > > > in Kubernetes and starting a workflow instance via the devui console.
> > > >
> > > > On Wed, Mar 13, 2024 at 3:54 PM Tiago Bento <
> > > tiagobentofernandes@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Francisco,
> > > > >
> > > > > I agree with you that both reasonings are not antagonistic, as an
> > > > > antagonistic reasoning in this case would be one that doesn't work.
> > > > > And I believe it is clear now that the initial proposal shared on
> > this
> > > > > email thread does work, but it is not the only possibility. From
> the
> > > > > beginning I said there are alternatives, but I wanted to start the
> > > > > conversation from my point of view, sharing what I think is best.
> We
> > > > > have to acknowledge, though, IMHO, that the discussions we had thus
> > > > > far cannot be understood as clearly as what was initially laid out,
> > > > > given the lack of details/analysis and a clear execution plan.
> > > > >
> > > > > Let me elaborate on top of the 3-step plan you shared.
> > > > >
> > > > > 1)
> > > > > No comment. This should be pretty simple to do.
> > > > >
> > > > > 2)
> > > > > There is no global CI stream to be changed, we would have to create
> > > > > one. And this has serious implications to our contribution model
> for
> > > > > cross-repo PRs. As I described on the first email of this thread,
> > > > > Category A repos are configured in several disjoint streams.
> Sending
> > a
> > > > > PR to `drools` and `kogito-runtimes` will work great, but sending a
> > PR
> > > > > to `drools` and `kogito-images`, or `drools` and `optaplanner`
> won't
> > > > > verify that everything will continue working after the PRs are
> > merged,
> > > > > as our PR checks are not prepared to build this combination of
> repos
> > > > > together. This is a problem, in my view, but I hardly contribute to
> > > > > Category A repos, so I'm assuming things are working fine for those
> > > > > who do. The proposal shared on the first email of this thread does
> > not
> > > > > change the contribution workflow for any repo of Apache KIE, and
> > > > > everyone can continue contributing the way they're used to, except
> > for
> > > > > people contributing to the `kogito-swf-{builder,devmode}` images,
> and
> > > > > to `kogito-serverless-operator`. On the other hand, having
> > `kie-tools`
> > > > > built in the middle of a new global CI stream, would span another
> > > > > class of problem, which is very closely related to the third bullet
> > > > > point of the plan you shared.
> > > > >
> > > > > 3)
> > > > > Maven has a mechanism to achieve this pseudo-synchronicity between
> > > > > multiple repositories. The mutable SNAPSHOT version, built nightly.
> > It
> > > > > is not perfect, though, as I'm sure many of us already experienced
> > > > > pulling from the `main` branch of a single repo only to find out
> that
> > > > > a PR ensemble had been merged a few moments prior, requiring us to
> > > > > rebuild the entire stack, since our local SNAPSHOTs had become
> > > > > out-of-date. That's what we used to have back in Business Central
> > > > > (a.k.a. v7) days. Making a `git pull` on a single repo in this
> setup
> > > > > potentially requires all repos to be pulled and rebuilt. I'm sure
> > this
> > > > > still happens sometimes when developing Category A projects.
> > > > >
> > > > > NPM packages don't have mutable SNAPSHOTs. Every published NPM
> > package
> > > > > is immutable, and it is really cumbersome and error-prone to
> > integrate
> > > > > downstream repos with upstream NPM-bound repos, as not having a
> > > > > lockfile brings all sorts of security and stability problems.
> That's
> > > > > why monorepos became so popular in the JavaScript ecosystem. This
> > lack
> > > > > of a mutable SNAPSHOT mechanism makes depending on NPM artifacts
> > > > > coming from `kie-tools` really hard. The way I see it, moving repos
> > > > > downstream of `kie-tools` will require everyone to build
> `kie-tools`
> > > > > anyway, potentially on a daily basis, since it would've then become
> > > > > part of the stack that needs to be built before `kogito-images` and
> > > > > `kogito-serverless-operator`. More than that, since there would be
> no
> > > > > way to determine what subset of packages of `kie-tools` would need
> to
> > > > > be built to satisfy downstream references, everyone would have to
> do
> > a
> > > > > full build, or handpick individual packages of the monorepo to
> build.
> > > > >
> > > > > I hope I was able to offer more insight in the way I see things,
> > along
> > > > > with my take on using Maven SNAPSHOTs as the de-facto solution for
> a
> > > > > poly-repo codebase. I don't think we can escape from the complexity
> > of
> > > > > our codebase and the nature of the technologies we use, only
> > > > > accommodate it in the most comfortable place possible, if even
> there
> > > > > is such a place :)
> > > > >
> > > > > Now, there are some things I'd like to say regarding the initial
> > > > > proposal shared on this email thread.
> > > > >
> > > > > I understand you, and others, are concerned about moving stuff into
> > > > > `kie-tools` for some reasons I could gather from your messages.
> I'll
> > > > > try and list them here, along with my perspective on each of them.
> > > > >
> > > > > 1. Never being able to move them out of `kie-tools` again.
> > > > > This is going to be as hard as it would be removing
> > > > > `kn-plugin-workflow` from it now. So, as you and others mentioned
> > this
> > > > > possibility, I assume you understand it to be doable.
> > > > >
> > > > > 2. "Heterodoxizing" an orthodox repository
> > > > > (`kogito-serverless-operator`), potentially harming external
> > > > > contributions.
> > > > > Agree with this point. `kie-tools` is one of a kind, built around
> > > > > front-end tooling with some completely unique in-house apparatus.
> In
> > > > > my experience, though, there are a multitude of factors that make
> > > > > people want to contribute to an open source project. Conformance to
> > > > > well-known widespread technologies and tools is just one of them.
> > > > > Being open about it and writing material to smooth out those edges
> > can
> > > > > work pretty well. People do not contribute because a codebase is
> > > > > "pure". People contribute because they care about the project. And
> > I'm
> > > > > always surprised by the lengths people go to when they want to get
> > > > > involved.
> > > > >
> > > > > 3. Disruption to the contribution workflow of those contributing to
> > > > > `kogito-swf-{builder,devmode}` images, and to
> > > > > `kogito-serverless-operator`.
> > > > > It is clear to me now that we can't unblock and release Apache KIE
> 10
> > > > > without impacting anyone, but I hope the first part of this reply
> > > > > sheds some light on this complicated matter.
> > > > >
> > > > > Anyway, that's my attempt to offer a different perspective to some
> of
> > > > > the problems you expressed concern about, perhaps even making the
> > > > > initial proposal shared on this email thread be seen with less
> > > > > uncertainty.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 11:40 AM Francisco Javier Tirado Sarti
> > > > > <ft...@redhat.com> wrote:
> > > > > >
> > > > > > Tiago,
> > > > > > Unfortunately, my plan is too conceptually simple to write more
> > than
> > > I
> > > > > > already wrote.
> > > > > > 1) Move kn-plugin-workflow module to operator repo (this remove
> the
> > > > > > dependency between tools and operator, breaking the loop)
> > > > > > 2) Change CI global stream to execute tooling repo before
> operator
> > > repo
> > > > > > (this seems to take 2 months unless Tristan helps and reduce the
> > time
> > > > to
> > > > > 2
> > > > > > weeks)
> > > > > > 3) Optionally, and just as a consequence of that CI change, set
> > > > > > 999-SNAPSHOT version to all poms in all repos (if current
> snapshot
> > > > > numbers
> > > > > > turns out to be a problem, in any case this is just
> search-replace)
> > > > > >
> > > > > > The current plan is:
> > > > > > 1) Move everything depending on tools to tools repo, which
> includes
> > > > > > operator code and examples.
> > > > > > 2) Change CI of tooling repo to enforce dependencies between the
> > > > existing
> > > > > > modules there and the newly moved ones (this seems to take 3
> weeks
> > or
> > > > > less)
> > > > > >
> > > > > > I think rather than asking for a more detailed alternative, what
> > > needs
> > > > to
> > > > > > be done is to refine the existing proposal with the feedback
> > > received.
> > > > I
> > > > > do
> > > > > > not think both proposals are antagonistic. I think that, being
> now
> > > > clear
> > > > > we
> > > > > > have the same overall goal (execute tooling before operator), it
> is
> > > > just
> > > > > a
> > > > > > question of deciding between move more stuff to an already
> > heterodox
> > > > > repo,
> > > > > > coming from repos not as heterodox, plus changing the repo CI to
> > > impose
> > > > > > certain order between these modules or pull out the the operator
> > > stuff
> > > > > from
> > > > > > tool repo and put it inside the operator repo plus changing the
> CI
> > > > > > handling repos to impose the desired order: first tooling and
> then
> > > > > operator.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 4:12 PM Tiago Bento <
> > > > > tiagobentofernandes@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Francisco,
> > > > > > >
> > > > > > > 1) `kie-tools` is already a heterodox repo. The reason why I
> > > proposed
> > > > > > > my proposal is because it is what I think is the best course of
> > > > action
> > > > > > > for our community right now. If you think there's a better way
> to
> > > do
> > > > > > > it, I think everyone, including me, needs to see a proposal
> with
> > a
> > > > > > > clear execution plan with a comparable level of detail and
> > analysis
> > > > in
> > > > > > > regards to disruption of the current state, the required
> effort,
> > > the
> > > > > > > contribution workflow for cross-repo PRs, and the release
> process
> > > > > > > itself. Otherwise, we risk having gaps that each person will
> fill
> > > in
> > > > a
> > > > > > > different way, and IMHO, that's where problems happen. +1 for
> > > > examples
> > > > > > > unification, btw :)
> > > > > > >
> > > > > > > 2) Ok, and +1 for no categorization.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado Sarti
> > > > > > > <ft...@redhat.com> wrote:
> > > > > > > >
> > > > > > > > 1) Ok, if that is the case, I do not get why your first
> > proposal
> > > > was
> > > > > not
> > > > > > > > the one I'm proposing and it is apparently not detailed
> enough.
> > > To
> > > > > move
> > > > > > > > kn-workflow from tooling to operator one and change the order
> > in
> > > > > which
> > > > > > > the
> > > > > > > > repos are being processed. Basically, the problem of the
> > proposed
> > > > > > > solution
> > > > > > > > is that it kind of converts tooling repo into a pretty
> > heterodox
> > > > repo
> > > > > > > > compared with runtimes, drools or operator one. Also once
> > tooling
> > > > is
> > > > > not
> > > > > > > a
> > > > > > > > final repo in the overall chain, we can consider moving
> > examples
> > > as
> > > > > the
> > > > > > > > final one and include tooling showcases there (rather than
> > > > splitting
> > > > > > > > examples into examples with tooling and examples without
> > > tooling).
> > > > > > > > 2) I think this distinction between A and B is one between
> > > several
> > > > > > > possible
> > > > > > > > categorizations (not much, including no categorization at
> all)
> > > that
> > > > > > > > deserves a separate discussion. I will open a separate thread
> > for
> > > > > that
> > > > > > > > purpose, since we are not going to change that now and it is
> > not
> > > > > really
> > > > > > > > part of the proposal.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
> > > > > > > tiagobentofernandes@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco,
> > > > > > > > >
> > > > > > > > > 1) That's what this thread is all about... You know I don't
> > > think
> > > > > it's
> > > > > > > > > ok. That's why I'm proposing the two images and the
> operator
> > to
> > > > > move
> > > > > > > > > into the `kie-tools` repo, where we can more granularly
> > control
> > > > the
> > > > > > > > > order things are built, thus removing the dependency cycle.
> > > > > > > > >
> > > > > > > > > 2) Not sure we understand the same thing by "freeze". My
> > > proposal
> > > > > is
> > > > > > > > > that we select a timestamped SNAPSHOT version from
> Category A
> > > > > repos to
> > > > > > > > > use as base for a release. We give Category B repos some
> time
> > > to
> > > > > > > > > adjust, and then cut the release branches. This can happen
> > > > anytime,
> > > > > > > > > and no contributions would ever stop because of it. The
> > > > development
> > > > > > > > > branches can continue accepting PRs normally, even during
> the
> > > > > release
> > > > > > > > > process. Now, if what you're asking is why Category B repos
> > > refer
> > > > > to
> > > > > > > > > Category A repos via timestamped SNAPSHOTs, the answer is
> in
> > my
> > > > > first
> > > > > > > > > email. See the paragraph starting with "An important note
> > here
> > > is
> > > > > that
> > > > > > > > > Category B repositories...".
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado
> > Sarti
> > > > > > > > > <ft...@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Tiago
> > > > > > > > > > There are a couple of simple and straightforward
> questions
> > > > that
> > > > > I
> > > > > > > > > > formulated, but since we both write a lot, it might have
> > been
> > > > > lost.
> > > > > > > > > Please
> > > > > > > > > > let me ask them again.
> > > > > > > > > > 1) Do you think it is ok that tools repo is executed
> after
> > > > > > > generation of
> > > > > > > > > > docker images that are supposed to include those tools or
> > the
> > > > > > > operator
> > > > > > > > > that
> > > > > > > > > > is supposed to deploy such images?
> > > > > > > > > That's what this thread is all about... You know I'm not ok
> > > with
> > > > > it,
> > > > > > > > > that's why I'm proposing the two images and the operator to
> > > move
> > > > > into
> > > > > > > > > the `kie-tools` repo, where we can more granularly control
> > the
> > > > > order
> > > > > > > > > things are built and remove the dependency cycle.
> > > > > > > > > > 2) Besides that, although not directly related with the
> > > current
> > > > > > > proposal
> > > > > > > > > we
> > > > > > > > > > are discussing, I really think there are some
> restrictions
> > > > taken
> > > > > for
> > > > > > > > > > granted that are arbitrary and difficult to sustain on
> > > strictly
> > > > > > > technical
> > > > > > > > > > arguments. For example, the need to freeze the rest of
> the
> > > > > software
> > > > > > > > > before
> > > > > > > > > > tools are generated. Why? We have dependencies between
> > repos
> > > > that
> > > > > > > are not
> > > > > > > > > > handled that way: Apps depend on runtimes. Runtimes
> depend
> > on
> > > > > drools,
> > > > > > > > > > Operator depend on runtimes,....and we are not freezing
> > that
> > > > > repos
> > > > > > > since
> > > > > > > > > we
> > > > > > > > > > are all releasing at the same time. If we are all
> releasing
> > > at
> > > > > the
> > > > > > > same
> > > > > > > > > > time, what's the rationale behind the freeze?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <
> > > > > tiagobento@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Glad to see the interest this proposal has gotten, and
> > it's
> > > > > good to
> > > > > > > > > > > see some alternatives being drafted here, although
> still
> > > > > lacking
> > > > > > > clear
> > > > > > > > > > > definitions and analysis in regards to disruption,
> > required
> > > > > effort,
> > > > > > > > > > > the release process itself, and history. Of course,
> lots
> > of
> > > > > details
> > > > > > > > > > > and clarity on the execution part would be missing too.
> > > > > > > > > > >
> > > > > > > > > > > As of this moment, based on what I read here, I'm
> > assuming
> > > > that
> > > > > > > > > > > everyone who participated so far doesn't see the
> initial
> > > > > proposal
> > > > > > > as
> > > > > > > > > > > problematic in terms of feasibility, but some of you
> > have a
> > > > > > > preference
> > > > > > > > > > > not to go with it, because it is "wrong", and
> apparently
> > > > > because it
> > > > > > > > > > > would "jeopardize the evolution of the project".
> Reading
> > > > these
> > > > > last
> > > > > > > > > > > words made me a little sad, to be honest. But I can
> deal
> > > with
> > > > > it :)
> > > > > > > > > > >
> > > > > > > > > > > Please let's try and keep the discussion as objective
> as
> > > > > possible.
> > > > > > > > > > > "Right" and "wrong" are too subjective for this kind of
> > > > > > > conversation.
> > > > > > > > > > >
> > > > > > > > > > > Now, being practical, unless there are clear arguments
> > > based
> > > > on
> > > > > > > facts
> > > > > > > > > > > and objective concepts that invalidate the initial
> > proposal
> > > > > shared
> > > > > > > on
> > > > > > > > > > > this email, it seems to me that it is currently the
> only
> > > > viable
> > > > > > > > > > > proposal we have for unblocking and releasing Apache
> KIE
> > > 10.
> > > > Of
> > > > > > > > > > > course, if we end up seeing an alternative proposal
> with
> > > > enough
> > > > > > > > > > > details and a clear execution plan, I think then we'll
> be
> > > in
> > > > a
> > > > > very
> > > > > > > > > > > good position to choose from multiple options!
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <
> > > > > alex@porcelli.me>
> > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Francisco and Gabriele,
> > > > > > > > > > > >
> > > > > > > > > > > > I understand and acknowledge your desire to find the
> > > > “right”
> > > > > > > solution
> > > > > > > > > > > > instead to work on a temporary “patch” - however
> > without
> > > a
> > > > > > > detailed
> > > > > > > > > > > > proposal I don’t think we can properly evaluate the
> > > impact
> > > > of
> > > > > > > your
> > > > > > > > > > > > suggestion.
> > > > > > > > > > > >
> > > > > > > > > > > > When I spoke with different SMEs that included tools
> > and
> > > > CI,
> > > > > the
> > > > > > > > > > > > guesstimate for making the necessary changes on CI
> and
> > > > > codebase
> > > > > > > to
> > > > > > > > > > > > basically have images and operators in the end of the
> > > build
> > > > > > > chain is
> > > > > > > > > > > > something like 2 months of effort. Another impact
> that
> > > > needs
> > > > > to
> > > > > > > be
> > > > > > > > > > > > discussed is that KIE Tools repo had to be injected
> in
> > > the
> > > > > > > middle of
> > > > > > > > > all
> > > > > > > > > > > > pipelines - forcing all PR checks and nightlies to
> > build
> > > > all
> > > > > > > repos
> > > > > > > > > (PR
> > > > > > > > > > > > checks will likely take 12+ hours… I even heard that
> it
> > > > > could be
> > > > > > > > > even 24
> > > > > > > > > > > > hours).
> > > > > > > > > > > >
> > > > > > > > > > > > Based on the input above, I think it’s quite risk to
> > move
> > > > in
> > > > > such
> > > > > > > > > > > direction
> > > > > > > > > > > > without a more detailed plan… because 2 months could
> be
> > > > > turned
> > > > > > > > > easily in
> > > > > > > > > > > 6!
> > > > > > > > > > > > And this is exactly what happened when we guessed
> that
> > > > > moving to
> > > > > > > > > Apache
> > > > > > > > > > > > would take no more than 3 months. But here we are.
> > > > > > > > > > > >
> > > > > > > > > > > > I really strongly suggest that we focus on a release
> > that
> > > > > could
> > > > > > > be
> > > > > > > > > > > > achievable in less than a month from now, and we -
> > after
> > > > > release
> > > > > > > -
> > > > > > > > > have a
> > > > > > > > > > > > in depth discussion about the overall codebase and ci
> > > > > > > organization.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > my suggestion is to move the building of all docker
> > > > images,
> > > > > > > from
> > > > > > > > > > > whatever
> > > > > > > > > > > > > repo (kogito-apps, kie-tools) in a different,
> > > downstream
> > > > > repo,
> > > > > > > to
> > > > > > > > > be
> > > > > > > > > > > > > invoked after all the others.
> > > > > > > > > > > > > I'm not sure if this would solve all the issues,
> and
> > > > since
> > > > > I
> > > > > > > could
> > > > > > > > > not
> > > > > > > > > > > > > enter in the details of all the involved code, my
> > > > > suggestion
> > > > > > > may
> > > > > > > > > be too
> > > > > > > > > > > > > naive.
> > > > > > > > > > > > > Having spent almost all of the last year in CI, I
> > may
> > > > say
> > > > > > > that, at
> > > > > > > > > > > least
> > > > > > > > > > > > > for the kie-tools repo, removing the image build
> step
> > > > from
> > > > > it
> > > > > > > > > should
> > > > > > > > > > > not be
> > > > > > > > > > > > > too difficult (since it is an issue we already
> faced
> > > and
> > > > > > > solved).
> > > > > > > > > > > > > If, with "detailed proposal", you mean a complete
> > list
> > > of
> > > > > all
> > > > > > > > > modules
> > > > > > > > > > > to be
> > > > > > > > > > > > > moved and dependency refactoring, of course I can
> not
> > > > > provide
> > > > > > > it
> > > > > > > > > right
> > > > > > > > > > > now.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Anyway, I share the concern from Francisco: undoing
> > > > > something
> > > > > > > is
> > > > > > > > > almost
> > > > > > > > > > > > > always harder than doing it "rightly" from
> scratch...
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco
> > > Javier
> > > > > > > Tirado
> > > > > > > > > Sarti
> > > > > > > > > > > <
> > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I do not think estimations should be the only
> > driver
> > > to
> > > > > make
> > > > > > > a
> > > > > > > > > > > decision,
> > > > > > > > > > > > > > especially when the current proposal is
> > conceptually
> > > > > > > incompatible
> > > > > > > > > > > with
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > multi repo approach that is taken elsewhere in
> the
> > > > > project.
> > > > > > > > > > > > > > Given my knowledge of the CI it is nearly
> > impossible
> > > > for
> > > > > me
> > > > > > > to
> > > > > > > > > give
> > > > > > > > > > > a
> > > > > > > > > > > > > fair
> > > > > > > > > > > > > > estimate of how much it might take to achieve
> step
> > 2)
> > > > of
> > > > > my
> > > > > > > > > previous
> > > > > > > > > > > > > e-mail
> > > > > > > > > > > > > > . It might take a while or it might be pretty
> easy
> > > > after
> > > > > > > all, I
> > > > > > > > > don't
> > > > > > > > > > > > > > really know, but I think it will be a good idea
> if
> > > > some
> > > > > of
> > > > > > > the
> > > > > > > > > > > experts
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > CI in the team (the ones that set up the
> pipeline,
> > > > which
> > > > > was
> > > > > > > a
> > > > > > > > > huge
> > > > > > > > > > > > > > achievement) give an estimate, not me.
> Estimating
> > > how
> > > > > much
> > > > > > > it
> > > > > > > > > takes
> > > > > > > > > > > to
> > > > > > > > > > > > > > merge two existing repos (without altering CI) is
> > > > easier,
> > > > > > > but it
> > > > > > > > > > > does not
> > > > > > > > > > > > > > mean we are doing the right thing.
> > > > > > > > > > > > > > My main concern is that it will be very difficult
> > for
> > > > me
> > > > > to
> > > > > > > > > explain
> > > > > > > > > > > to
> > > > > > > > > > > > > > someone that arrives new to the team, that having
> > > > > experts on
> > > > > > > CI
> > > > > > > > > on
> > > > > > > > > > > the
> > > > > > > > > > > > > > team, we decided to merge two repos (once merged,
> > it
> > > > > would be
> > > > > > > > > rather
> > > > > > > > > > > > > > difficult to unmerge) rather than fix the CI,
> > because
> > > > of
> > > > > > > > > expediency.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > > > > > > > porcelli@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Please take the time to make the more in depth
> > > > analysis
> > > > > > > needed
> > > > > > > > > and
> > > > > > > > > > > > > > provide
> > > > > > > > > > > > > > > a more detailed plan… so we - as community- can
> > > > > evaluate
> > > > > > > the
> > > > > > > > > size
> > > > > > > > > > > of
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > effort. In the conceptual level you shared it’s
> > > near
> > > > > > > > > impossible to
> > > > > > > > > > > > > > estimate
> > > > > > > > > > > > > > > the size of the effort and compare with the
> > current
> > > > > > > proposal.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco
> Javier
> > > > Tirado
> > > > > > > Sarti <
> > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > > > > > > > 1) Remove all dependencies from tooling to
> > > images,
> > > > > so
> > > > > > > images
> > > > > > > > > > > depend
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > tooling but tooling does not depend on
> images.
> > > > > > > > > > > > > > > > 2) Then change CI to deal with tooling repo
> > > before
> > > > > > > dealing
> > > > > > > > > with
> > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > repo.
> > > > > > > > > > > > > > > > I understand that CI details are tricky and
> > since
> > > > > I'm not
> > > > > > > > > > > familiar
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > > CI
> > > > > > > > > > > > > > > > in any way, I barely can make a low level
> > design,
> > > > > but we
> > > > > > > do
> > > > > > > > > not
> > > > > > > > > > > need
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > fix
> > > > > > > > > > > > > > > > everything, just achieve 2), a change of
> > > > compilation
> > > > > > > order.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex
> Porcelli
> > <
> > > > > > > > > alex@porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > You may not like or understand why the
> > current
> > > > > state of
> > > > > > > > > the CI
> > > > > > > > > > > is
> > > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > that… actually has been in Red Hat and has
> > been
> > > > > > > replicated
> > > > > > > > > in
> > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > used to be….
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But the fact is that this is the current
> > > reality.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you disagree with the current plan,
> please
> > > > > provide a
> > > > > > > > > > > detailed
> > > > > > > > > > > > > > > > > alternative so we, as community, can better
> > > > > evaluate
> > > > > > > the
> > > > > > > > > pros
> > > > > > > > > > > and
> > > > > > > > > > > > > > cons
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > each proposal.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think it’s also fair to say that, post 10
> > > > > release we
> > > > > > > > > need to
> > > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > much
> > > > > > > > > > > > > > > > > in depth discussion about how our codebase
> is
> > > > > > > organized,
> > > > > > > > > it’s
> > > > > > > > > > > clear
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > it’s not working.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele
> > > Cardosi
> > > > <
> > > > > > > > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > > > > > > > I also have the impression that the
> > "images"
> > > > (if
> > > > > we
> > > > > > > are
> > > > > > > > > > > talking
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > docker
> > > > > > > > > > > > > > > > > > images) should be the very last one to be
> > > > built,
> > > > > in a
> > > > > > > > > > > standalone
> > > > > > > > > > > > > > > repo.
> > > > > > > > > > > > > > > > > > That way, they may "combine" artifacts
> that
> > > are
> > > > > > > built in
> > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > repos,
> > > > > > > > > > > > > > > > > > regardless of the order in which those
> are
> > > > built.
> > > > > > > > > > > > > > > > > > Moving them out of all the repos
> > > > > > > (kogito-apps/kie-tools)
> > > > > > > > > > > maybe
> > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > > > > > > > (I also think there are some statements
> of
> > > > > > > undisputable
> > > > > > > > > needs
> > > > > > > > > > > > > while
> > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > > > > > > > Anyway, this latter point is for longer,
> > > > > following,
> > > > > > > > > > > discussion.)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23
> > > > > Francisco
> > > > > > > Javier
> > > > > > > > > > > Tirado
> > > > > > > > > > > > > > > Sarti
> > > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > > > > > > > There are two assumptions that deserve
> > > > further
> > > > > > > > > discussion:
> > > > > > > > > > > > > > > > > > > 1) That tool has to be the last to
> build.
> > > > why?
> > > > > it
> > > > > > > does
> > > > > > > > > not
> > > > > > > > > > > have
> > > > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > > > > to build final images after everything
> > else
> > > > has
> > > > > > > been
> > > > > > > > > > > built?-
> > > > > > > > > > > > > > > > > > > 2) That the impact (in terms of effort
> > now)
> > > > on
> > > > > > > fixing
> > > > > > > > > CI is
> > > > > > > > > > > > > > bigger
> > > > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > impact (long term consequences) of
> > > > > consolidating
> > > > > > > two
> > > > > > > > > > > unrelated
> > > > > > > > > > > > > > > piece
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex
> > > > Porcelli
> > > > > <
> > > > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > This was discussed as an alternative
> > > > > solution,
> > > > > > > > > however
> > > > > > > > > > > it has
> > > > > > > > > > > > > > > major
> > > > > > > > > > > > > > > > > > > impact
> > > > > > > > > > > > > > > > > > > > on CI and there’s also the fact Tool
> > has
> > > > been
> > > > > > > always
> > > > > > > > > the
> > > > > > > > > > > last
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > build
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > has no Snapshot published (actually
> in
> > > > > JavaScript
> > > > > > > > > world
> > > > > > > > > > > there
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > So, based on our evaluation… the
> > proposal
> > > > > here
> > > > > > > is the
> > > > > > > > > > > least
> > > > > > > > > > > > > > > > > disruptive
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > will take less time to unblock the
> > > release.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM
> > Francisco
> > > > > Javier
> > > > > > > > > Tirado
> > > > > > > > > > > > > Sarti <
> > > > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > After kie-tools, sorry. I think we
> > are
> > > > not
> > > > > > > > > embracing
> > > > > > > > > > > the
> > > > > > > > > > > > > fact
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > kogito-images depend on kie-tools,
> > > > because
> > > > > we
> > > > > > > want
> > > > > > > > > > > those
> > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM
> > > > Francisco
> > > > > > > Javier
> > > > > > > > > > > Tirado
> > > > > > > > > > > > > > Sarti
> > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > > > > > > > It can be an alternative solution
> > to
> > > > move
> > > > > > > > > > > > > > kn-plugin-workflow
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > kogito-images (so there is not
> > longer
> > > > > > > dependency
> > > > > > > > > from
> > > > > > > > > > > > > tools
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > then build kogito-images after
> > > > > kogito-tools?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM
> > > > Enrique
> > > > > > > Gonzalez
> > > > > > > > > > > > > Martinez
> > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere
> > > > > Fernandez
> > > > > > > > > (apache)
> > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >> > I say +1 in order to move
> > forward
> > > > with
> > > > > > > the 10.
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45,
> > Alex
> > > > > > > Porcelli <
> > > > > > > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> > > I spent the last day or so
> > > working
> > > > > > > closely
> > > > > > > > > with
> > > > > > > > > > > > > Tiago,
> > > > > > > > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > > > > > > > >> > > options and getting deeper
> on
> > > the
> > > > > > > impact and
> > > > > > > > > > > > > > evaluating
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > > > > > > > >> > > procedure steps required. I
> > > agree
> > > > > with
> > > > > > > the
> > > > > > > > > > > proposal
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > most
> > > > > > > > > > > > > > > > > > > > > >> > > viable option for unblocking
> > the
> > > > 10
> > > > > > > release
> > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > > > > > > > reasonable
> > > > > > > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at
> > 3:45 PM
> > > > > Tiago
> > > > > > > Bento
> > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do
> a
> > > > tl;dr
> > > > > this
> > > > > > > > > time,
> > > > > > > > > > > as
> > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > > matter
> > > > > > > > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > This email will take you <
> > 20
> > > > > minutes
> > > > > > > to
> > > > > > > > > read,
> > > > > > > > > > > > > > > according
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > As you may have followed
> on
> > a
> > > > > separate
> > > > > > > > > thread
> > > > > > > > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > >
> https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > > > > > > > >> > > > many of us were working
> > > towards
> > > > > > > removing a
> > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > > > > > >> > > > currently present between
> > > > > > > `kogito-apps`
> > > > > > > > > and
> > > > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > As
> > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > >> > > > progressed towards a
> > solution,
> > > > we
> > > > > kept
> > > > > > > > > > > finding the
> > > > > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > > > > > > > >> > > > pop up somewhere else.
> I'll
> > > do a
> > > > > > > > > breakdown of
> > > > > > > > > > > the
> > > > > > > > > > > > > > > things
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Right now, even though we
> > > > started
> > > > > the
> > > > > > > > > effort
> > > > > > > > > > > to
> > > > > > > > > > > > > move
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`,
> > we
> > > > > haven't
> > > > > > > been
> > > > > > > > > > > able to
> > > > > > > > > > > > > > do
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > yet,
> > > > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > > > > > > > >> > > > been busy upgrading KIE
> > Tools
> > > to
> > > > > Java
> > > > > > > 17,
> > > > > > > > > > > Maven
> > > > > > > > > > > > > > 3.9.6,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with
> > Kogito
> > > > > Runtimes
> > > > > > > > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > > > >> > > > effort was concluded this
> > > > Monday,
> > > > > with
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >
> > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > > > > > > > .
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > The current scenario we
> have
> > > is:
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > > >> > > > |==> 02.
> > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > > >> > > > L |
> > > > > > > ==========================
> > > > > > > > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > > >> > > > |==> 07.
> > > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > `kie-tools`/extended-services
> > > > > > > > > > > depends
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > > > > > > >
> `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`/{many
> packages}
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > After moving the Quarkus
> Dev
> > > UIs
> > > > > to
> > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > would've
> > > > > > > > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > > >> > > > C |
> > > > > =====================
> > > > > > > > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > > >> > > > E |==> 07.
> > > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > > > > depends
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > > > > > > > depends
> > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > After moving the
> > > > > `kogito-swf-devmode`
> > > > > > > > > image to
> > > > > > > > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > > >> > > > 04.
> > > > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > > >> > > > Y |
> > > > > =====================
> > > > > > > > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > > >> > > > L |==> 07.
> > > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > > > > depends
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > `kogito-serverless-operator`
> > > > > > > > > > > depends
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > Clearly, we have a much
> > bigger
> > > > > problem
> > > > > > > > > than a
> > > > > > > > > > > > > simple
> > > > > > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > > >> > > > After multiple
> conversations
> > > > with
> > > > > a
> > > > > > > lot of
> > > > > > > > > > > people,
> > > > > > > > > > > > > > > it's
> > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > > > >> > > > hard coming up with a
> simple
> > > > > solution
> > > > > > > that
> > > > > > > > > > > makes
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > possible
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > > > > > > > >> > > > Apache KIE in one shot,
> > while
> > > > > > > preserving
> > > > > > > > > the
> > > > > > > > > > > way
> > > > > > > > > > > > > > > > everyone
> > > > > > > > > > > > > > > > > is
> > > >
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Hi Jan
Yes, that's why I was also discussing the suitability of timestamped
snapshots.
For me, both amplification of tools repo with unrelated code and
timestamped snapshots are against fixed snapshot and multi repo philosophy
employed in the rest of the project (it will be far easier from CI
perspective to have just one huge repo containing drools, runtimes, apps
and examples, but we are not doing that)
Therefore we are kind of sanctioning two different philosophies in our
first apache release. Since there is apparently no other alternative with
the resources we have, we will have to release it with this discrepancy.
But it is sad and I think we should learn from this experience to avoid
repeating it in the future. In my opinion, this proposal should have been
shared long before to not make it a fait accompli.
On Thu, Mar 14, 2024 at 6:18 PM Jan Šťastný <js...@apache.org> wrote:
> Hello,
> I'll try to summarize the challenges I am aware of in relation to CI at the
> moment and with the proposals.
>
> (I am referring to projects forming the build chain as upstream <->
> downstream depending on their placing in the overall chain.)
>
> Current state:
> Category A projects:
> - We don't have one, but rather 3 sets of pipelines for project groups:
> drools, kogito and optaplanner, all these three utilizing a combination of
> GHA (mostly PR checks) and Jenkins pipelines based on
> apache/incubator-kie-kogito-pipelines framework (kogito-pipelines FW).
> - For these builds, we use build-chain tool, which allows to define
> cross-repository relations between projects, clone repositories and run
> custom commands in each of those, depending in what part of the build chain
> (considering the project triggering the build) they are invoked (upstream,
> downstream, current). Examples of the build-chain project dependencies
> configuration Tiago provided in the first email. Build-chain is a powerful
> tool, though we have limited knowledge (Roberto being the sole contributor
> of fixes since our move to ASF).
> - As part of the kogito pipeline kogito-images and *-operator jobs are
> attached, but relation to repositories earlier up the chain is either
> assumed (building from main branch of kogito-apps) or loose (building
> kogito-examples from main-nightly branch, which is created in preceding
> kogito-examples nightly build). It's not part of PR checks for repositories
> up the stream.
>
> Category B projects:
> - We have a unique solution based mainly on GHA, but recently also some
> parts (is it a backup?) in ASF Jenkins, but NOT using the kogito-pipelines
> FW.
>
> Category C projects:
> - There are loosely managed jobs for *-benchmarks repositories, just a
> matter of updating versions, easily manageable - won't discuss further.
>
> Current gaps:
>
> Category A projects:
> - Generally the current jenkins solution for PR checks is lacking, we have
> just a single kind of PR check, not allowing custom triggers (e.g. by
> comments) or various modes (like quarkus native build).
> - We don't have downstream builds as part of PR checks.
> - We build all in a single job. Which has resulted in execution time over 8
> hours which was not bearable. Thus we reduced the build scope to sort of
> compile downstream builds - we run tests for repositories that are part of
> the PR, but their dependents (coming after them) are only run without
> tests.
> - With the introduction of unified SNAPSHOTs we have not fully adjusted for
> this in our pipelines, leaving out relations like optaplanner -> drools and
> kogito-apps -> optaplanner - so problems will be missed in case of related
> PRs. This SNAPSHOT version unification indicates that instead of 3 distinct
> buildchain configurations, we should now switch to a single one, especially
> for the sake of unification.
> - Part of the repositories (starting with kogito-images) are not attached
> in the build-chain build at all, but are rather consecutively executed
> pipelines relying on publishing artifacts for consumption downstream.
>
> Proposal assessment:
> - Almost any repository could be part of the build-chain configuration,
> complex invocations can be hidden e.g. using make.
> - Any changes to PR checks should have the following prerequisite not to
> increase complexity and to limit execution times: moving of all PR checks
> into GHA, introduction of isolated limited-scope PR checks, on-demand full
> downstream build.
> - Timestamped SNAPSHOTs consumed by kie-tools would call against attaching
> kie-tools into build-chain of drools/kogito, because we would be running PR
> checks/nightly against main which might differ from the timestamped
> SNAPSHOT. So this seems like either/or decision to me.
> - Build-chain would probably not be able to replicate the fine-grained
> build execution based on the changes in PR as kie-tools currently has in
> place.
> - It's not clear to me how/if we could generally limit scope of execution
> in downstream builds depending on scope of upstream repository changes.
> - Community CI has really limited human resources, I personally switched to
> an ad-hoc way of working on that, only when something breaks.
> - It's not clear to me how a build-chain would work in terms of
> consuming/passing artifacts outside of maven projects and artifacts.
> - It's fair to say that we have SMEs for CI/build in Category A (engines or
> cloud), Category B, but I don't think there's anyone knowing deep internals
> of all, to be able to provide a reliable estimate of efforts involved in
> bigger refactoring.
>
> Summary:
> I don't see an easy way how a simple change in CI would help to unblock the
> current situation. Considering Tiago's proposal, timestamped SNAPSHOTs
> already in place, assumed relative simplicity of making the components part
> of kie-tools build ...
>
> +1 from me
>
> Thanks.
> Best Regards
> Jan
>
>
>
>
>
>
> On Thu, 14 Mar 2024 at 11:24, Francisco Javier Tirado Sarti <
> ftirados@redhat.com> wrote:
>
> > Hi Tiago, Thanks for the detailed explanation
> > Actually, for tooling, where there is not strong dependency (as between
> > engine code in runtime and kie server api in drools), the fixed snapshot
> > mechanism will work pretty well, in my opinion.
> > On one side, an example that depends on devui will not fail to compile
> > because the snapshot is old. The contrary is also true, if we add a new
> > functionality in the server side that is going to be used by any tool,
> the
> > worst that might happen is that the functionality is not there in the old
> > snapshot, but it wont block tooling compilation (obviously if you need
> that
> > functionality to test a new UI feature, you will need the update
> snapshot,
> > but that's expected and I guess is also happening now, you need to wait
> for
> > the server artifact to be published on Maven)
> > Because of that loose dependency, tooling can be run, as it is, as an
> > almost completely separate project but also because of that, I feel it
> > might be easily integrated (except for CI changes, which are always
> > delicate) with the rest of the repos to achieve a single release number,
> > because, if all repos use the same snapshot, as far as there is one
> > snapshot, in the day by day experience everything will normally compile.
> > I think we agree that the natural place of tooling in the dependency
> chain
> > is after apps (service) and before images. With that in mind and if we
> > wholly embrace the consequence of being a single release, in my opinion,
> it
> > means that tooling become one more repo (no A no B category), which use
> a
> > fixed snapshot as the rest, and it is subject to the need to eventually
> > wait for the updated snapshot (or in case you cannot wait, a local full
> > build), in the unlikely case there is a change that blocks its local
> > compilation. The implication of this is that the development cycle that
> is
> > implicit in your proposal to use a "fixed snapshot" in category A repos
> no
> > longer apply.
> > This means no time to adjust, which can sound like an herexy, but, if
> there
> > is no need for a gap between drools and runtimes, why is there a need
> for a
> > gap between tooling and apps (services)? (I think we agree a Java API
> > dependency is stronger than a REST API) Do we have a real precedent that
> > justify that? I kind of feel that here we are converting an old habit
> into
> > an axiomatic need (probably because Im lacking context)
> > Now my proposal for CI, we do not really need a single stream right now.
> We
> > can keep the current kogito stream as it is, except for images, and
> > integrate tooling into the stream that is now used for the operator (the
> > assumption here is that a change in drools-runtimes hardly breaks the
> tools
> > and in any case that is already happening, so we do not lose anything)
> >
> >
> > On Wed, Mar 13, 2024 at 8:18 PM ricardo zanini fernandes <
> > ricardozanini@gmail.com> wrote:
> >
> > > Hey Tiago, thanks for the insights, I appreciate it.
> > >
> > > Just one thing regarding building from kie-tools one module that images
> > > need to sync changes. That might happen, of course. If I see a problem
> in
> > > devui, I just report it in the tools repo, we work on the bug, and in
> the
> > > next image build we get the changes. By the nature of the
> > operator/images,
> > > such changes won't impact our builds. What impact our builds are
> > > self-contained on those repos or work made in the engines, where we
> rely
> > on
> > > Snapshots.
> > >
> > > I understand your concern and it's a valid point, but in practice, it's
> > not
> > > what happens. We can live with the latest released version from npm
> > > packages during the dev phase without any problems. From the
> > > images/operator perspective, they are yet another package I need to
> > install
> > > on my container. Like `cat` or `jq`.
> > >
> > > But we need to sit down and try to understand our boundaries and how to
> > do
> > > integration tests based on them. For example, deploying a devmode
> > workflow
> > > in Kubernetes and starting a workflow instance via the devui console.
> > >
> > > On Wed, Mar 13, 2024 at 3:54 PM Tiago Bento <
> > tiagobentofernandes@gmail.com
> > > >
> > > wrote:
> > >
> > > > Francisco,
> > > >
> > > > I agree with you that both reasonings are not antagonistic, as an
> > > > antagonistic reasoning in this case would be one that doesn't work.
> > > > And I believe it is clear now that the initial proposal shared on
> this
> > > > email thread does work, but it is not the only possibility. From the
> > > > beginning I said there are alternatives, but I wanted to start the
> > > > conversation from my point of view, sharing what I think is best. We
> > > > have to acknowledge, though, IMHO, that the discussions we had thus
> > > > far cannot be understood as clearly as what was initially laid out,
> > > > given the lack of details/analysis and a clear execution plan.
> > > >
> > > > Let me elaborate on top of the 3-step plan you shared.
> > > >
> > > > 1)
> > > > No comment. This should be pretty simple to do.
> > > >
> > > > 2)
> > > > There is no global CI stream to be changed, we would have to create
> > > > one. And this has serious implications to our contribution model for
> > > > cross-repo PRs. As I described on the first email of this thread,
> > > > Category A repos are configured in several disjoint streams. Sending
> a
> > > > PR to `drools` and `kogito-runtimes` will work great, but sending a
> PR
> > > > to `drools` and `kogito-images`, or `drools` and `optaplanner` won't
> > > > verify that everything will continue working after the PRs are
> merged,
> > > > as our PR checks are not prepared to build this combination of repos
> > > > together. This is a problem, in my view, but I hardly contribute to
> > > > Category A repos, so I'm assuming things are working fine for those
> > > > who do. The proposal shared on the first email of this thread does
> not
> > > > change the contribution workflow for any repo of Apache KIE, and
> > > > everyone can continue contributing the way they're used to, except
> for
> > > > people contributing to the `kogito-swf-{builder,devmode}` images, and
> > > > to `kogito-serverless-operator`. On the other hand, having
> `kie-tools`
> > > > built in the middle of a new global CI stream, would span another
> > > > class of problem, which is very closely related to the third bullet
> > > > point of the plan you shared.
> > > >
> > > > 3)
> > > > Maven has a mechanism to achieve this pseudo-synchronicity between
> > > > multiple repositories. The mutable SNAPSHOT version, built nightly.
> It
> > > > is not perfect, though, as I'm sure many of us already experienced
> > > > pulling from the `main` branch of a single repo only to find out that
> > > > a PR ensemble had been merged a few moments prior, requiring us to
> > > > rebuild the entire stack, since our local SNAPSHOTs had become
> > > > out-of-date. That's what we used to have back in Business Central
> > > > (a.k.a. v7) days. Making a `git pull` on a single repo in this setup
> > > > potentially requires all repos to be pulled and rebuilt. I'm sure
> this
> > > > still happens sometimes when developing Category A projects.
> > > >
> > > > NPM packages don't have mutable SNAPSHOTs. Every published NPM
> package
> > > > is immutable, and it is really cumbersome and error-prone to
> integrate
> > > > downstream repos with upstream NPM-bound repos, as not having a
> > > > lockfile brings all sorts of security and stability problems. That's
> > > > why monorepos became so popular in the JavaScript ecosystem. This
> lack
> > > > of a mutable SNAPSHOT mechanism makes depending on NPM artifacts
> > > > coming from `kie-tools` really hard. The way I see it, moving repos
> > > > downstream of `kie-tools` will require everyone to build `kie-tools`
> > > > anyway, potentially on a daily basis, since it would've then become
> > > > part of the stack that needs to be built before `kogito-images` and
> > > > `kogito-serverless-operator`. More than that, since there would be no
> > > > way to determine what subset of packages of `kie-tools` would need to
> > > > be built to satisfy downstream references, everyone would have to do
> a
> > > > full build, or handpick individual packages of the monorepo to build.
> > > >
> > > > I hope I was able to offer more insight in the way I see things,
> along
> > > > with my take on using Maven SNAPSHOTs as the de-facto solution for a
> > > > poly-repo codebase. I don't think we can escape from the complexity
> of
> > > > our codebase and the nature of the technologies we use, only
> > > > accommodate it in the most comfortable place possible, if even there
> > > > is such a place :)
> > > >
> > > > Now, there are some things I'd like to say regarding the initial
> > > > proposal shared on this email thread.
> > > >
> > > > I understand you, and others, are concerned about moving stuff into
> > > > `kie-tools` for some reasons I could gather from your messages. I'll
> > > > try and list them here, along with my perspective on each of them.
> > > >
> > > > 1. Never being able to move them out of `kie-tools` again.
> > > > This is going to be as hard as it would be removing
> > > > `kn-plugin-workflow` from it now. So, as you and others mentioned
> this
> > > > possibility, I assume you understand it to be doable.
> > > >
> > > > 2. "Heterodoxizing" an orthodox repository
> > > > (`kogito-serverless-operator`), potentially harming external
> > > > contributions.
> > > > Agree with this point. `kie-tools` is one of a kind, built around
> > > > front-end tooling with some completely unique in-house apparatus. In
> > > > my experience, though, there are a multitude of factors that make
> > > > people want to contribute to an open source project. Conformance to
> > > > well-known widespread technologies and tools is just one of them.
> > > > Being open about it and writing material to smooth out those edges
> can
> > > > work pretty well. People do not contribute because a codebase is
> > > > "pure". People contribute because they care about the project. And
> I'm
> > > > always surprised by the lengths people go to when they want to get
> > > > involved.
> > > >
> > > > 3. Disruption to the contribution workflow of those contributing to
> > > > `kogito-swf-{builder,devmode}` images, and to
> > > > `kogito-serverless-operator`.
> > > > It is clear to me now that we can't unblock and release Apache KIE 10
> > > > without impacting anyone, but I hope the first part of this reply
> > > > sheds some light on this complicated matter.
> > > >
> > > > Anyway, that's my attempt to offer a different perspective to some of
> > > > the problems you expressed concern about, perhaps even making the
> > > > initial proposal shared on this email thread be seen with less
> > > > uncertainty.
> > > >
> > > > On Wed, Mar 13, 2024 at 11:40 AM Francisco Javier Tirado Sarti
> > > > <ft...@redhat.com> wrote:
> > > > >
> > > > > Tiago,
> > > > > Unfortunately, my plan is too conceptually simple to write more
> than
> > I
> > > > > already wrote.
> > > > > 1) Move kn-plugin-workflow module to operator repo (this remove the
> > > > > dependency between tools and operator, breaking the loop)
> > > > > 2) Change CI global stream to execute tooling repo before operator
> > repo
> > > > > (this seems to take 2 months unless Tristan helps and reduce the
> time
> > > to
> > > > 2
> > > > > weeks)
> > > > > 3) Optionally, and just as a consequence of that CI change, set
> > > > > 999-SNAPSHOT version to all poms in all repos (if current snapshot
> > > > numbers
> > > > > turns out to be a problem, in any case this is just search-replace)
> > > > >
> > > > > The current plan is:
> > > > > 1) Move everything depending on tools to tools repo, which includes
> > > > > operator code and examples.
> > > > > 2) Change CI of tooling repo to enforce dependencies between the
> > > existing
> > > > > modules there and the newly moved ones (this seems to take 3 weeks
> or
> > > > less)
> > > > >
> > > > > I think rather than asking for a more detailed alternative, what
> > needs
> > > to
> > > > > be done is to refine the existing proposal with the feedback
> > received.
> > > I
> > > > do
> > > > > not think both proposals are antagonistic. I think that, being now
> > > clear
> > > > we
> > > > > have the same overall goal (execute tooling before operator), it is
> > > just
> > > > a
> > > > > question of deciding between move more stuff to an already
> heterodox
> > > > repo,
> > > > > coming from repos not as heterodox, plus changing the repo CI to
> > impose
> > > > > certain order between these modules or pull out the the operator
> > stuff
> > > > from
> > > > > tool repo and put it inside the operator repo plus changing the CI
> > > > > handling repos to impose the desired order: first tooling and then
> > > > operator.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 4:12 PM Tiago Bento <
> > > > tiagobentofernandes@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Francisco,
> > > > > >
> > > > > > 1) `kie-tools` is already a heterodox repo. The reason why I
> > proposed
> > > > > > my proposal is because it is what I think is the best course of
> > > action
> > > > > > for our community right now. If you think there's a better way to
> > do
> > > > > > it, I think everyone, including me, needs to see a proposal with
> a
> > > > > > clear execution plan with a comparable level of detail and
> analysis
> > > in
> > > > > > regards to disruption of the current state, the required effort,
> > the
> > > > > > contribution workflow for cross-repo PRs, and the release process
> > > > > > itself. Otherwise, we risk having gaps that each person will fill
> > in
> > > a
> > > > > > different way, and IMHO, that's where problems happen. +1 for
> > > examples
> > > > > > unification, btw :)
> > > > > >
> > > > > > 2) Ok, and +1 for no categorization.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado Sarti
> > > > > > <ft...@redhat.com> wrote:
> > > > > > >
> > > > > > > 1) Ok, if that is the case, I do not get why your first
> proposal
> > > was
> > > > not
> > > > > > > the one I'm proposing and it is apparently not detailed enough.
> > To
> > > > move
> > > > > > > kn-workflow from tooling to operator one and change the order
> in
> > > > which
> > > > > > the
> > > > > > > repos are being processed. Basically, the problem of the
> proposed
> > > > > > solution
> > > > > > > is that it kind of converts tooling repo into a pretty
> heterodox
> > > repo
> > > > > > > compared with runtimes, drools or operator one. Also once
> tooling
> > > is
> > > > not
> > > > > > a
> > > > > > > final repo in the overall chain, we can consider moving
> examples
> > as
> > > > the
> > > > > > > final one and include tooling showcases there (rather than
> > > splitting
> > > > > > > examples into examples with tooling and examples without
> > tooling).
> > > > > > > 2) I think this distinction between A and B is one between
> > several
> > > > > > possible
> > > > > > > categorizations (not much, including no categorization at all)
> > that
> > > > > > > deserves a separate discussion. I will open a separate thread
> for
> > > > that
> > > > > > > purpose, since we are not going to change that now and it is
> not
> > > > really
> > > > > > > part of the proposal.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
> > > > > > tiagobentofernandes@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Francisco,
> > > > > > > >
> > > > > > > > 1) That's what this thread is all about... You know I don't
> > think
> > > > it's
> > > > > > > > ok. That's why I'm proposing the two images and the operator
> to
> > > > move
> > > > > > > > into the `kie-tools` repo, where we can more granularly
> control
> > > the
> > > > > > > > order things are built, thus removing the dependency cycle.
> > > > > > > >
> > > > > > > > 2) Not sure we understand the same thing by "freeze". My
> > proposal
> > > > is
> > > > > > > > that we select a timestamped SNAPSHOT version from Category A
> > > > repos to
> > > > > > > > use as base for a release. We give Category B repos some time
> > to
> > > > > > > > adjust, and then cut the release branches. This can happen
> > > anytime,
> > > > > > > > and no contributions would ever stop because of it. The
> > > development
> > > > > > > > branches can continue accepting PRs normally, even during the
> > > > release
> > > > > > > > process. Now, if what you're asking is why Category B repos
> > refer
> > > > to
> > > > > > > > Category A repos via timestamped SNAPSHOTs, the answer is in
> my
> > > > first
> > > > > > > > email. See the paragraph starting with "An important note
> here
> > is
> > > > that
> > > > > > > > Category B repositories...".
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado
> Sarti
> > > > > > > > <ft...@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > Tiago
> > > > > > > > > There are a couple of simple and straightforward questions
> > > that
> > > > I
> > > > > > > > > formulated, but since we both write a lot, it might have
> been
> > > > lost.
> > > > > > > > Please
> > > > > > > > > let me ask them again.
> > > > > > > > > 1) Do you think it is ok that tools repo is executed after
> > > > > > generation of
> > > > > > > > > docker images that are supposed to include those tools or
> the
> > > > > > operator
> > > > > > > > that
> > > > > > > > > is supposed to deploy such images?
> > > > > > > > That's what this thread is all about... You know I'm not ok
> > with
> > > > it,
> > > > > > > > that's why I'm proposing the two images and the operator to
> > move
> > > > into
> > > > > > > > the `kie-tools` repo, where we can more granularly control
> the
> > > > order
> > > > > > > > things are built and remove the dependency cycle.
> > > > > > > > > 2) Besides that, although not directly related with the
> > current
> > > > > > proposal
> > > > > > > > we
> > > > > > > > > are discussing, I really think there are some restrictions
> > > taken
> > > > for
> > > > > > > > > granted that are arbitrary and difficult to sustain on
> > strictly
> > > > > > technical
> > > > > > > > > arguments. For example, the need to freeze the rest of the
> > > > software
> > > > > > > > before
> > > > > > > > > tools are generated. Why? We have dependencies between
> repos
> > > that
> > > > > > are not
> > > > > > > > > handled that way: Apps depend on runtimes. Runtimes depend
> on
> > > > drools,
> > > > > > > > > Operator depend on runtimes,....and we are not freezing
> that
> > > > repos
> > > > > > since
> > > > > > > > we
> > > > > > > > > are all releasing at the same time. If we are all releasing
> > at
> > > > the
> > > > > > same
> > > > > > > > > time, what's the rationale behind the freeze?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <
> > > > tiagobento@apache.org>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Glad to see the interest this proposal has gotten, and
> it's
> > > > good to
> > > > > > > > > > see some alternatives being drafted here, although still
> > > > lacking
> > > > > > clear
> > > > > > > > > > definitions and analysis in regards to disruption,
> required
> > > > effort,
> > > > > > > > > > the release process itself, and history. Of course, lots
> of
> > > > details
> > > > > > > > > > and clarity on the execution part would be missing too.
> > > > > > > > > >
> > > > > > > > > > As of this moment, based on what I read here, I'm
> assuming
> > > that
> > > > > > > > > > everyone who participated so far doesn't see the initial
> > > > proposal
> > > > > > as
> > > > > > > > > > problematic in terms of feasibility, but some of you
> have a
> > > > > > preference
> > > > > > > > > > not to go with it, because it is "wrong", and apparently
> > > > because it
> > > > > > > > > > would "jeopardize the evolution of the project". Reading
> > > these
> > > > last
> > > > > > > > > > words made me a little sad, to be honest. But I can deal
> > with
> > > > it :)
> > > > > > > > > >
> > > > > > > > > > Please let's try and keep the discussion as objective as
> > > > possible.
> > > > > > > > > > "Right" and "wrong" are too subjective for this kind of
> > > > > > conversation.
> > > > > > > > > >
> > > > > > > > > > Now, being practical, unless there are clear arguments
> > based
> > > on
> > > > > > facts
> > > > > > > > > > and objective concepts that invalidate the initial
> proposal
> > > > shared
> > > > > > on
> > > > > > > > > > this email, it seems to me that it is currently the only
> > > viable
> > > > > > > > > > proposal we have for unblocking and releasing Apache KIE
> > 10.
> > > Of
> > > > > > > > > > course, if we end up seeing an alternative proposal with
> > > enough
> > > > > > > > > > details and a clear execution plan, I think then we'll be
> > in
> > > a
> > > > very
> > > > > > > > > > good position to choose from multiple options!
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <
> > > > alex@porcelli.me>
> > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Francisco and Gabriele,
> > > > > > > > > > >
> > > > > > > > > > > I understand and acknowledge your desire to find the
> > > “right”
> > > > > > solution
> > > > > > > > > > > instead to work on a temporary “patch” - however
> without
> > a
> > > > > > detailed
> > > > > > > > > > > proposal I don’t think we can properly evaluate the
> > impact
> > > of
> > > > > > your
> > > > > > > > > > > suggestion.
> > > > > > > > > > >
> > > > > > > > > > > When I spoke with different SMEs that included tools
> and
> > > CI,
> > > > the
> > > > > > > > > > > guesstimate for making the necessary changes on CI and
> > > > codebase
> > > > > > to
> > > > > > > > > > > basically have images and operators in the end of the
> > build
> > > > > > chain is
> > > > > > > > > > > something like 2 months of effort. Another impact that
> > > needs
> > > > to
> > > > > > be
> > > > > > > > > > > discussed is that KIE Tools repo had to be injected in
> > the
> > > > > > middle of
> > > > > > > > all
> > > > > > > > > > > pipelines - forcing all PR checks and nightlies to
> build
> > > all
> > > > > > repos
> > > > > > > > (PR
> > > > > > > > > > > checks will likely take 12+ hours… I even heard that it
> > > > could be
> > > > > > > > even 24
> > > > > > > > > > > hours).
> > > > > > > > > > >
> > > > > > > > > > > Based on the input above, I think it’s quite risk to
> move
> > > in
> > > > such
> > > > > > > > > > direction
> > > > > > > > > > > without a more detailed plan… because 2 months could be
> > > > turned
> > > > > > > > easily in
> > > > > > > > > > 6!
> > > > > > > > > > > And this is exactly what happened when we guessed that
> > > > moving to
> > > > > > > > Apache
> > > > > > > > > > > would take no more than 3 months. But here we are.
> > > > > > > > > > >
> > > > > > > > > > > I really strongly suggest that we focus on a release
> that
> > > > could
> > > > > > be
> > > > > > > > > > > achievable in less than a month from now, and we -
> after
> > > > release
> > > > > > -
> > > > > > > > have a
> > > > > > > > > > > in depth discussion about the overall codebase and ci
> > > > > > organization.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Alex,
> > > > > > > > > > > > my suggestion is to move the building of all docker
> > > images,
> > > > > > from
> > > > > > > > > > whatever
> > > > > > > > > > > > repo (kogito-apps, kie-tools) in a different,
> > downstream
> > > > repo,
> > > > > > to
> > > > > > > > be
> > > > > > > > > > > > invoked after all the others.
> > > > > > > > > > > > I'm not sure if this would solve all the issues, and
> > > since
> > > > I
> > > > > > could
> > > > > > > > not
> > > > > > > > > > > > enter in the details of all the involved code, my
> > > > suggestion
> > > > > > may
> > > > > > > > be too
> > > > > > > > > > > > naive.
> > > > > > > > > > > > Having spent almost all of the last year in CI, I
> may
> > > say
> > > > > > that, at
> > > > > > > > > > least
> > > > > > > > > > > > for the kie-tools repo, removing the image build step
> > > from
> > > > it
> > > > > > > > should
> > > > > > > > > > not be
> > > > > > > > > > > > too difficult (since it is an issue we already faced
> > and
> > > > > > solved).
> > > > > > > > > > > > If, with "detailed proposal", you mean a complete
> list
> > of
> > > > all
> > > > > > > > modules
> > > > > > > > > > to be
> > > > > > > > > > > > moved and dependency refactoring, of course I can not
> > > > provide
> > > > > > it
> > > > > > > > right
> > > > > > > > > > now.
> > > > > > > > > > > >
> > > > > > > > > > > > Anyway, I share the concern from Francisco: undoing
> > > > something
> > > > > > is
> > > > > > > > almost
> > > > > > > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco
> > Javier
> > > > > > Tirado
> > > > > > > > Sarti
> > > > > > > > > > <
> > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > >
> > > > > > > > > > > > > I do not think estimations should be the only
> driver
> > to
> > > > make
> > > > > > a
> > > > > > > > > > decision,
> > > > > > > > > > > > > especially when the current proposal is
> conceptually
> > > > > > incompatible
> > > > > > > > > > with
> > > > > > > > > > > > the
> > > > > > > > > > > > > multi repo approach that is taken elsewhere in the
> > > > project.
> > > > > > > > > > > > > Given my knowledge of the CI it is nearly
> impossible
> > > for
> > > > me
> > > > > > to
> > > > > > > > give
> > > > > > > > > > a
> > > > > > > > > > > > fair
> > > > > > > > > > > > > estimate of how much it might take to achieve step
> 2)
> > > of
> > > > my
> > > > > > > > previous
> > > > > > > > > > > > e-mail
> > > > > > > > > > > > > . It might take a while or it might be pretty easy
> > > after
> > > > > > all, I
> > > > > > > > don't
> > > > > > > > > > > > > really know, but I think it will be a good idea if
> > > some
> > > > of
> > > > > > the
> > > > > > > > > > experts
> > > > > > > > > > > > on
> > > > > > > > > > > > > CI in the team (the ones that set up the pipeline,
> > > which
> > > > was
> > > > > > a
> > > > > > > > huge
> > > > > > > > > > > > > achievement) give an estimate, not me. Estimating
> > how
> > > > much
> > > > > > it
> > > > > > > > takes
> > > > > > > > > > to
> > > > > > > > > > > > > merge two existing repos (without altering CI) is
> > > easier,
> > > > > > but it
> > > > > > > > > > does not
> > > > > > > > > > > > > mean we are doing the right thing.
> > > > > > > > > > > > > My main concern is that it will be very difficult
> for
> > > me
> > > > to
> > > > > > > > explain
> > > > > > > > > > to
> > > > > > > > > > > > > someone that arrives new to the team, that having
> > > > experts on
> > > > > > CI
> > > > > > > > on
> > > > > > > > > > the
> > > > > > > > > > > > > team, we decided to merge two repos (once merged,
> it
> > > > would be
> > > > > > > > rather
> > > > > > > > > > > > > difficult to unmerge) rather than fix the CI,
> because
> > > of
> > > > > > > > expediency.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > > > > > > porcelli@apache.org>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Please take the time to make the more in depth
> > > analysis
> > > > > > needed
> > > > > > > > and
> > > > > > > > > > > > > provide
> > > > > > > > > > > > > > a more detailed plan… so we - as community- can
> > > > evaluate
> > > > > > the
> > > > > > > > size
> > > > > > > > > > of
> > > > > > > > > > > > the
> > > > > > > > > > > > > > effort. In the conceptual level you shared it’s
> > near
> > > > > > > > impossible to
> > > > > > > > > > > > > estimate
> > > > > > > > > > > > > > the size of the effort and compare with the
> current
> > > > > > proposal.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier
> > > Tirado
> > > > > > Sarti <
> > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > > > > > > 1) Remove all dependencies from tooling to
> > images,
> > > > so
> > > > > > images
> > > > > > > > > > depend
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > > > > > > 2) Then change CI to deal with tooling repo
> > before
> > > > > > dealing
> > > > > > > > with
> > > > > > > > > > > > images
> > > > > > > > > > > > > > > repo.
> > > > > > > > > > > > > > > I understand that CI details are tricky and
> since
> > > > I'm not
> > > > > > > > > > familiar
> > > > > > > > > > > > with
> > > > > > > > > > > > > > CI
> > > > > > > > > > > > > > > in any way, I barely can make a low level
> design,
> > > > but we
> > > > > > do
> > > > > > > > not
> > > > > > > > > > need
> > > > > > > > > > > > to
> > > > > > > > > > > > > > fix
> > > > > > > > > > > > > > > everything, just achieve 2), a change of
> > > compilation
> > > > > > order.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli
> <
> > > > > > > > alex@porcelli.me
> > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > You may not like or understand why the
> current
> > > > state of
> > > > > > > > the CI
> > > > > > > > > > is
> > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > that… actually has been in Red Hat and has
> been
> > > > > > replicated
> > > > > > > > in
> > > > > > > > > > > > Apache
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > used to be….
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But the fact is that this is the current
> > reality.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you disagree with the current plan, please
> > > > provide a
> > > > > > > > > > detailed
> > > > > > > > > > > > > > > > alternative so we, as community, can better
> > > > evaluate
> > > > > > the
> > > > > > > > pros
> > > > > > > > > > and
> > > > > > > > > > > > > cons
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > each proposal.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think it’s also fair to say that, post 10
> > > > release we
> > > > > > > > need to
> > > > > > > > > > > > have a
> > > > > > > > > > > > > > > much
> > > > > > > > > > > > > > > > in depth discussion about how our codebase is
> > > > > > organized,
> > > > > > > > it’s
> > > > > > > > > > clear
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > it’s not working.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele
> > Cardosi
> > > <
> > > > > > > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > > > > > > I also have the impression that the
> "images"
> > > (if
> > > > we
> > > > > > are
> > > > > > > > > > talking
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > docker
> > > > > > > > > > > > > > > > > images) should be the very last one to be
> > > built,
> > > > in a
> > > > > > > > > > standalone
> > > > > > > > > > > > > > repo.
> > > > > > > > > > > > > > > > > That way, they may "combine" artifacts that
> > are
> > > > > > built in
> > > > > > > > > > > > different
> > > > > > > > > > > > > > > repos,
> > > > > > > > > > > > > > > > > regardless of the order in which those are
> > > built.
> > > > > > > > > > > > > > > > > Moving them out of all the repos
> > > > > > (kogito-apps/kie-tools)
> > > > > > > > > > maybe
> > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > > > > > > (I also think there are some statements of
> > > > > > undisputable
> > > > > > > > needs
> > > > > > > > > > > > while
> > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > > > > > > Anyway, this latter point is for longer,
> > > > following,
> > > > > > > > > > discussion.)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23
> > > > Francisco
> > > > > > Javier
> > > > > > > > > > Tirado
> > > > > > > > > > > > > > Sarti
> > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > > > > > > There are two assumptions that deserve
> > > further
> > > > > > > > discussion:
> > > > > > > > > > > > > > > > > > 1) That tool has to be the last to build.
> > > why?
> > > > it
> > > > > > does
> > > > > > > > not
> > > > > > > > > > have
> > > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > > > to build final images after everything
> else
> > > has
> > > > > > been
> > > > > > > > > > built?-
> > > > > > > > > > > > > > > > > > 2) That the impact (in terms of effort
> now)
> > > on
> > > > > > fixing
> > > > > > > > CI is
> > > > > > > > > > > > > bigger
> > > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > impact (long term consequences) of
> > > > consolidating
> > > > > > two
> > > > > > > > > > unrelated
> > > > > > > > > > > > > > piece
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex
> > > Porcelli
> > > > <
> > > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > This was discussed as an alternative
> > > > solution,
> > > > > > > > however
> > > > > > > > > > it has
> > > > > > > > > > > > > > major
> > > > > > > > > > > > > > > > > > impact
> > > > > > > > > > > > > > > > > > > on CI and there’s also the fact Tool
> has
> > > been
> > > > > > always
> > > > > > > > the
> > > > > > > > > > last
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > build
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > has no Snapshot published (actually in
> > > > JavaScript
> > > > > > > > world
> > > > > > > > > > there
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > So, based on our evaluation… the
> proposal
> > > > here
> > > > > > is the
> > > > > > > > > > least
> > > > > > > > > > > > > > > > disruptive
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > will take less time to unblock the
> > release.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM
> Francisco
> > > > Javier
> > > > > > > > Tirado
> > > > > > > > > > > > Sarti <
> > > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > After kie-tools, sorry. I think we
> are
> > > not
> > > > > > > > embracing
> > > > > > > > > > the
> > > > > > > > > > > > fact
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > kogito-images depend on kie-tools,
> > > because
> > > > we
> > > > > > want
> > > > > > > > > > those
> > > > > > > > > > > > > images
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM
> > > Francisco
> > > > > > Javier
> > > > > > > > > > Tirado
> > > > > > > > > > > > > Sarti
> > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > > > > > > It can be an alternative solution
> to
> > > move
> > > > > > > > > > > > > kn-plugin-workflow
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > kogito-images (so there is not
> longer
> > > > > > dependency
> > > > > > > > from
> > > > > > > > > > > > tools
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > then build kogito-images after
> > > > kogito-tools?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM
> > > Enrique
> > > > > > Gonzalez
> > > > > > > > > > > > Martinez
> > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere
> > > > Fernandez
> > > > > > > > (apache)
> > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >> > I say +1 in order to move
> forward
> > > with
> > > > > > the 10.
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45,
> Alex
> > > > > > Porcelli <
> > > > > > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> > > I spent the last day or so
> > working
> > > > > > closely
> > > > > > > > with
> > > > > > > > > > > > Tiago,
> > > > > > > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > > > > > > >> > > options and getting deeper on
> > the
> > > > > > impact and
> > > > > > > > > > > > > evaluating
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > > > > > > >> > > procedure steps required. I
> > agree
> > > > with
> > > > > > the
> > > > > > > > > > proposal
> > > > > > > > > > > > as
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > most
> > > > > > > > > > > > > > > > > > > > >> > > viable option for unblocking
> the
> > > 10
> > > > > > release
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > > > > > > reasonable
> > > > > > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at
> 3:45 PM
> > > > Tiago
> > > > > > Bento
> > > > > > > > <
> > > > > > > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a
> > > tl;dr
> > > > this
> > > > > > > > time,
> > > > > > > > > > as
> > > > > > > > > > > > this
> > > > > > > > > > > > > > > > matter
> > > > > > > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > This email will take you <
> 20
> > > > minutes
> > > > > > to
> > > > > > > > read,
> > > > > > > > > > > > > > according
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > As you may have followed on
> a
> > > > separate
> > > > > > > > thread
> > > > > > > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > > > > > > >> > > > many of us were working
> > towards
> > > > > > removing a
> > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > > > > >> > > > currently present between
> > > > > > `kogito-apps`
> > > > > > > > and
> > > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > As
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > >> > > > progressed towards a
> solution,
> > > we
> > > > kept
> > > > > > > > > > finding the
> > > > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll
> > do a
> > > > > > > > breakdown of
> > > > > > > > > > the
> > > > > > > > > > > > > > things
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Right now, even though we
> > > started
> > > > the
> > > > > > > > effort
> > > > > > > > > > to
> > > > > > > > > > > > move
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`,
> we
> > > > haven't
> > > > > > been
> > > > > > > > > > able to
> > > > > > > > > > > > > do
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > yet,
> > > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > > > > > > >> > > > been busy upgrading KIE
> Tools
> > to
> > > > Java
> > > > > > 17,
> > > > > > > > > > Maven
> > > > > > > > > > > > > 3.9.6,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with
> Kogito
> > > > Runtimes
> > > > > > > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > > >> > > > effort was concluded this
> > > Monday,
> > > > with
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >
> > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > > > > > > .
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > The current scenario we have
> > is:
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > >> > > > |==> 02.
> > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > >> > > > L |
> > > > > > ==========================
> > > > > > > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > >> > > > |==> 07.
> > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > `kie-tools`/extended-services
> > > > > > > > > > depends
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev
> > UIs
> > > > to
> > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > > would've
> > > > > > > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > >> > > > C |
> > > > =====================
> > > > > > > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > >> > > > E |==> 07.
> > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > > > depends
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > > > > > > depends
> > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > After moving the
> > > > `kogito-swf-devmode`
> > > > > > > > image to
> > > > > > > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > >> > > > 04.
> > > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > >> > > > Y |
> > > > =====================
> > > > > > > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > >> > > > L |==> 07.
> > > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > > > depends
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > >> > > >
> `kogito-serverless-operator`;
> > > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > `kogito-serverless-operator`
> > > > > > > > > > depends
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > >> > > >
> `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Clearly, we have a much
> bigger
> > > > problem
> > > > > > > > than a
> > > > > > > > > > > > simple
> > > > > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > After multiple conversations
> > > with
> > > > a
> > > > > > lot of
> > > > > > > > > > people,
> > > > > > > > > > > > > > it's
> > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > > >> > > > hard coming up with a simple
> > > > solution
> > > > > > that
> > > > > > > > > > makes
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > > possible
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > > > > > > >> > > > Apache KIE in one shot,
> while
> > > > > > preserving
> > > > > > > > the
> > > > > > > > > > way
> > > > > > > > > > > > > > > everyone
> > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > >> > > > contributing to the multiple
> > > > > > repositories
> > > > > > > > we
> > > > > > > > > > have.
> > > > > > > > > > > > > > More
> > > > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > > > > > > >> > > > while making this
> assessment,
> > I
> > > > found
> > > > > > more
> > > > > > > > > > > > problems
> > > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > > > >> > > > perspective, block Apache
> KIE
> > > 10.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > In light of that difficulty,
> > I'm
> > > > > > coming
> > > > > > > > > > forward
> > > > > > > > > > > > with
> > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > >> > > > the Apache KIE release
> > process,
> > > > so we
> > > > > > can
> > > > > > > > use
> > > > > > > > > > > > > Apache's
> > > > > > > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > >> > > > have a slower-paced,
> in-depth
> > > > debate
> > > > > > about
> > > > > > > > > > this
> > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > I'll lay out my entire
> > > perspective
> > > > > > about
> > > > > > > > the
> > > > > > > > > > > > current
> > > > > > > > > > > > > > > > > situation
> > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > > > > > > >> > > > codebase, as well as
> problems
> > I
> > > > can
> > > > > > > > currently
> > > > > > > > > > see.
> > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > > > start
> > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > > > > > >> > > > analysis of the repositories
> > and
> > > > their
> > > > > > > > > > purposes,
> > > > > > > > > > > > > point
> > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > >> > > > problems that I believe are
> > > > blocking
> > > > > > our
> > > > > > > > 10
> > > > > > > > > > > > release,
> > > > > > > > > > > > > > > > explain
> > > > > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > > > >> > > > proposal and discuss some
> > > > > > consequences to
> > > > > > > > > > what I'm
> > > > > > > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, &
> > KOGITO
> > > > > > (count:
> > > > > > > > 11)
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-pipelines @
> > > > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @
> > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner
> @
> > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > incubator-kie-optaplanner-quickstarts @
> > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-runtimes
> > > @
> > > > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps
> @
> > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-examples
> > > @
> > > > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-images
> > @
> > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > incubator-kie-kogito-serverless-operator @
> > > > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs
> @
> > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @
> > > > `main-kogito`
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @
> `main`
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-benchmarks
> > > > @
> > > > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @
> > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @
> > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > (Issues only, README
> > should
> > > be
> > > > > > > > updated @
> > > > > > > > > > > > `main`.
> > > > > > > > > > > > > > > Same
> > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-website @
> > > > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > (The Kogito website.
> > > Develop &
> > > > > > deploy
> > > > > > > > at
> > > > > > > > > > the
> > > > > > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-website @
> > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > (The KIE website.
> Develop
> > @
> > > > > > `main`.
> > > > > > > > Push @
> > > > > > > > > > > > > > `deploy`
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-online
> > @
> > > > > > `gh-pages`
> > > > > > > > > > > > > > > > > > > > >> > > > (GitHub pages used to
> host
> > > > > > > > > > sandbox.kie.org
> > > > > > > > > > > > and
> > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-kogito-online-staging
> > > > > > @
> > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > > >> > > > (Same as above, but for
> > > manual
> > > > > > sanity
> > > > > > > > > > checks
> > > > > > > > > > > > > > during
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > I grouped the repositories
> by
> > > > > > category,
> > > > > > > > and
> > > > > > > > > > listed
> > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > in a
> > > > > > > > > > > > > > > > > > > > >> > > > topological order. Keep in
> > mind
> > > > that
> > > > > > when
> > > > > > > > > > > > flattening
> > > > > > > > > > > > > > > out a
> > > > > > > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > > > > > > >> > > > are multiple possibilities.
> > For
> > > > > > example,
> > > > > > > > > > > > OptaPlanner
> > > > > > > > > > > > > > > > > could've
> > > > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > >> > > > placed in any position after
> > > > Drools.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Category A repos are what
> I've
> > > > been
> > > > > > > > referring
> > > > > > > > > > to
> > > > > > > > > > > > as
> > > > > > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> > > > > > OptaPlanner
> > > > > > > > is
> > > > > > > > > > inside
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > > >> > > > way these repositories
> > reference
> > > > each
> > > > > > > > other
> > > > > > > > > > are
> > > > > > > > > > > > > > through
> > > > > > > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More
> specifically,
> > > the
> > > > > > > > 999-SNAPSHOT
> > > > > > > > > > > > > > version.
> > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > > > > > > >> > > > is well-known to the team,
> and
> > > > > > although
> > > > > > > > > > flawed for
> > > > > > > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > > > > > > >> > > > and disruptive for people in
> > > many
> > > > > > > > different
> > > > > > > > > > time
> > > > > > > > > > > > > > zones,
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > > > > >> > > > very comfortable for
> everyone
> > to
> > > > work
> > > > > > > > with, I
> > > > > > > > > > > > > assume.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Contributions made to
> > Category A
> > > > have
> > > > > > some
> > > > > > > > > > > > dedicated
> > > > > > > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > > > > > >> > > > are, at least to some
> extent,
> > > > able to
> > > > > > > > build
> > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > > > > >> > > > and verify that the codebase
> > > will
> > > > > > continue
> > > > > > > > > > working
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > expected
> > > > > > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > > > >> > > > they're all merged. From
> what
> > I
> > > > could
> > > > > > > > gather,
> > > > > > > > > > > > there
> > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > >> > > > "sub-streams" currently
> > > > configured for
> > > > > > > > > > cross-repo
> > > > > > > > > > > > > PRs.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> > > > > > kogito-apps,
> > > > > > > > and
> > > > > > > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > > > > > > >> > > > - optaplanner, and
> > > > > > optaplanner-quickstarts
> > > > > > > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > > > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > This means that sending
> > > cross-repo
> > > > > > PRs to
> > > > > > > > any
> > > > > > > > > > > > > > > combination
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > > > >> > > > that are not part of the
> same
> > > > > > "sub-stream"
> > > > > > > > > > cannot
> > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > verified
> > > > > > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > > > > > >> > > > merging, making our
> > contribution
> > > > model
> > > > > > > > > > dependent
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > individual
> > > > > > > > > > > > > > > > > > > > >> > > > contributors building stuff
> on
> > > > their
> > > > > > > > machines
> > > > > > > > > > to
> > > > > > > > > > > > > > verify
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > > > > >> > > > Note that I'm not that
> > familiar
> > > > with
> > > > > > these
> > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > > > > > >> > > > someone correct me if I'm
> > wrong.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Category B repos are what
> I've
> > > > been
> > > > > > > > referring
> > > > > > > > > > to
> > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > > > > >> > > > stream. The first repo there
> > is
> > > a
> > > > > > template
> > > > > > > > > > > > > repository
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > > > > > > >> > > > people starting projects
> from
> > > > scratch
> > > > > > on
> > > > > > > > KIE
> > > > > > > > > > > > > Sandbox,
> > > > > > > > > > > > > > > > > similar
> > > > > > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > > > >> > > > Maven archetype, if you
> will.
> > > The
> > > > > > other
> > > > > > > > one
> > > > > > > > > > is the
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > Tools
> > > > > > > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > > > > > > >> > > > a polyglot monorepo with
> > `pnpm`
> > > > as its
> > > > > > > > build
> > > > > > > > > > > > system.
> > > > > > > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries
> and
> > > > apps,
> > > > > > > > > > TypeScript
> > > > > > > > > > > > > > > libraries
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > > > > > > >> > > > apps, Docker images, and
> Helm
> > > > charts.
> > > > > > The
> > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > >> > > > configured to work with
> sparse
> > > > > > checkouts
> > > > > > > > and
> > > > > > > > > > can
> > > > > > > > > > > > do
> > > > > > > > > > > > > > > > partial
> > > > > > > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > > > > > > >> > > > Category B repos refer to
> > > > Category A
> > > > > > repos
> > > > > > > > > > through
> > > > > > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new
> > > > mechanism we
> > > > > > > > recently
> > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > > > >> > > > build and publish immutable,
> > > > > > persistent
> > > > > > > > > > artifacts
> > > > > > > > > > > > > > under
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > > > > > >> > > > following the
> > > > 999-YYYYMMDD-SNAPSHOT
> > > > > > > > format,
> > > > > > > > > > > > > published
> > > > > > > > > > > > > > > > weekly
> > > > > > > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped
> > > > SNAPSHOTs
> > > > > > are an
> > > > > > > > > > > > evolution
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > > > > >> > > > releases, as we're now
> > targeting
> > > > one
> > > > > > > > release
> > > > > > > > > > for
> > > > > > > > > > > > all
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > > > > > >> > > > we can't have Kogito
> releases
> > > > anymore.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > An important note here is
> that
> > > > > > Category B
> > > > > > > > > > > > > repositories
> > > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > >> > > > historically kept out of any
> > > > > > automations
> > > > > > > > we
> > > > > > > > > > used
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > have,
> > > > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > > > > >> > > > when Kogito started and we
> had
> > > the
> > > > > > > > Business
> > > > > > > > > > > > Central
> > > > > > > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > > > > > > >> > > > still going on. For this
> > reason,
> > > > > > Category
> > > > > > > > B
> > > > > > > > > > > > projects
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > > > > > > >> > > > their own automations, based
> > on
> > > > GitHub
> > > > > > > > > > Actions.
> > > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > > > > > > >> > > > always depended on Category
> A
> > > > repos
> > > > > > using
> > > > > > > > > > fixed
> > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > If
> > > > > > > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > > > > > > >> > > > B repos have had adopted
> > mutable
> > > > > > > > SNAPSHOTs,
> > > > > > > > > > > > breaking
> > > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > >> > > > Category A repositories
> > would've
> > > > had
> > > > > > the
> > > > > > > > > > potential
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > break
> > > > > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > > > > >> > > > silently, leaving Category B
> > > with
> > > > a
> > > > > > broken
> > > > > > > > > > > > > development
> > > > > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > >> > > > introducing unpleasant
> > surprises
> > > > for
> > > > > > > > > > maintainers
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > > > > > > >> > > > as historically Category A
> > > > > > contributors
> > > > > > > > were
> > > > > > > > > > not
> > > > > > > > > > > > > > > familiar
> > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Contributions made to
> > Category B
> > > > > > repos go
> > > > > > > > > > through
> > > > > > > > > > > > a
> > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > > > > > > >> > > > workflow that builds the
> > > relevant
> > > > > > part of
> > > > > > > > the
> > > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > > > >> > > > the changes introduced.
> > Changes
> > > > made
> > > > > > to
> > > > > > > > the
> > > > > > > > > > > > pipeline
> > > > > > > > > > > > > > > > itself
> > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > > > > > > >> > > > picked up as part of PRs,
> > > > allowing us
> > > > > > to
> > > > > > > > do
> > > > > > > > > > things
> > > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > > > > > > >> > > > bumping the Node.js version,
> > for
> > > > > > example.
> > > > > > > > More
> > > > > > > > > > > > > > > > importantly,
> > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > > > > > > >> > > > us to upgrade the repository
> > to
> > > a
> > > > new
> > > > > > > > > > timestamped
> > > > > > > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > > > > >> > > > with the changes necessary
> to
> > > > make it
> > > > > > stay
> > > > > > > > > > green.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > This setup, however, makes
> it
> > > > > > impossible
> > > > > > > > to
> > > > > > > > > > have
> > > > > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > > > > >> > > > involving Category A and
> > > Category
> > > > B
> > > > > > > > > > > > simultaneously,
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Category C repos are kind of
> > > > floating
> > > > > > > > around,
> > > > > > > > > > and
> > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > > > > >> > > > there's much activity going
> on
> > > > there.
> > > > > > > > > > Regardless,
> > > > > > > > > > > > as
> > > > > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > >> > > > Apache KIE, they will be
> part
> > of
> > > > our
> > > > > > > > release,
> > > > > > > > > > so I
> > > > > > > > > > > > > > > listed
> > > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > > > > >> > > > to take them into
> > consideration
> > > > too.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Category D is self
> > explanatory.
> > > > > > There's
> > > > > > > > only
> > > > > > > > > > one
> > > > > > > > > > > > > repo
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > has
> > > > > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > > > > >> > > > been marked for being
> > archived.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Category E are repos that do
> > not
> > > > host
> > > > > > code
> > > > > > > > > > > > directly,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > > > > > > >> > > > organizational entities, or
> > host
> > > > > > websites,
> > > > > > > > > > that
> > > > > > > > > > > > > > > currently
> > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > This lack of unification
> > between
> > > > > > Category
> > > > > > > > A
> > > > > > > > > > and
> > > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > is,
> > > > > > > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > > > > > > >> > > > what allowed us to introduce
> > the
> > > > > > infamous
> > > > > > > > > > circular
> > > > > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools` and
> `kogito-apps`,
> > > > which
> > > > > > we
> > > > > > > > now
> > > > > > > > > > can
> > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > > > > > > >> > > > dependency between Category
> A
> > > and
> > > > > > > > Category B.
> > > > > > > > > > The
> > > > > > > > > > > > > way
> > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > see
> > > > > > > > > > > > > > > > > > it,
> > > > > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > > >> > > > had a single pipeline,
> > building
> > > > > > everything
> > > > > > > > > > from
> > > > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws
> > would've
> > > > never
> > > > > > > > been
> > > > > > > > > > > > > > introduced,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > >> > > > wouldn't be having this huge
> > > > problem
> > > > > > in
> > > > > > > > our
> > > > > > > > > > hands
> > > > > > > > > > > > > > right
> > > > > > > > > > > > > > > > now.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > My proposal for the Apache
> KIE
> > > > release
> > > > > > > > process
> > > > > > > > > > > > sees
> > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > > lack
> > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > >> > > > unification as a central
> > > problem,
> > > > not
> > > > > > > > only for
> > > > > > > > > > > > this
> > > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > >> > > > particular, but for the
> > > community
> > > > as a
> > > > > > > > whole.
> > > > > > > > > > It
> > > > > > > > > > > > is
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > belief
> > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > > >> > > > are all under the same roof,
> > and
> > > > that
> > > > > > no
> > > > > > > > > > > > > contribution
> > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > > >> > > > allowed to break any part of
> > our
> > > > > > codebase.
> > > > > > > > > > With
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > > > > > > >> > > > of code, and hopefully
> number
> > of
> > > > > > > > contributors
> > > > > > > > > > too,
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > > > > > > >> > > > counting on "common sense"
> to
> > > > avoid
> > > > > > > > breaking
> > > > > > > > > > > > things.
> > > > > > > > > > > > > > > We're
> > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > > > > > > >> > > > after all, and it is our job
> > to
> > > > have
> > > > > > > > > > mechanisms in
> > > > > > > > > > > > > > place
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > > > > >> > > > from unwillingly making
> > > mistakes.
> > > > > > > > Especially
> > > > > > > > > > when
> > > > > > > > > > > > > > these
> > > > > > > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > > > > > > >> > > > impact on parts of the
> > codebase
> > > > that
> > > > > > we,
> > > > > > > > > > > > > individually,
> > > > > > > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT
> > NOW
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @
> > > > `kogito-apps`
> > > > > > > > depending
> > > > > > > > > > on
> > > > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF
> > > images
> > > > @
> > > > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools
> `0.32.0`.
> > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > P3. DashBuilder @
> `kie-tools`
> > > > > > depending on
> > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at
> > version
> > > > > > > > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > P4. Multiple packages @
> > > > `kogito-apps`
> > > > > > > > > > depending on
> > > > > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > > > > >> > > > Explainability
> `1.22.1.Final`.
> > > > > > > > > > > > > > > > > > > > >> > > > * This module was removed
> from
> > > > the KIE
> > > > > > > > > > codebase
> > > > > > > > > > > > > here:
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > >
> > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > > > > > > > ,
> > > > > > > > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > > > > > > > >> > > > * This new repo depends on
> > > Kogito
> > > > and
> > > > > > > > > > OptaPlanner,
> > > > > > > > > > > > > > > > pointing
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > older
> > > > > > > > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > P5.
> > > > > > > > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> > > > > > `2.15.3.Final`.
> > > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > P6. Category C repos are out
> > of
> > > > date
> > > > > > and
> > > > > > > > not
> > > > > > > > > > part
> > > > > > > > > > > > of
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > > > > > > > >> > > > *
> > > incubator-kie-kogito-benchmarks:
> > > > > > > > (Current
> > > > > > > > > > > > version
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > > > > >> > > > depending on Kogito without
> a
> > > > specific
> > > > > > > > > > version,
> > > > > > > > > > > > only
> > > > > > > > > > > > > > by
> > > > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks:
> > > > (Current
> > > > > > > > version
> > > > > > > > > > is
> > > > > > > > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > > > > >> > > > pointing to Drools
> > 999-SNAPSHOT
> > > > and
> > > > > > > > > > OptaPlanner
> > > > > > > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > P7.
> > > > > > > > `kie-tools`/packages/kn-plugin-workflow
> > > > > > > > > > has
> > > > > > > > > > > > its
> > > > > > > > > > > > > > E2E
> > > > > > > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > > > > > > > >> > > > upgrading to
> > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2
> > > have
> > > > the
> > > > > > same
> > > > > > > > > > > > solution,
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > > > > > > >> > > > suffer from the circular
> > > > dependency
> > > > > > > > between
> > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > > > > > > > >> > > > As Category A and Category B
> > are
> > > > both
> > > > > > > > streams
> > > > > > > > > > that
> > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > > >> > > > active, I see this as a
> > blocker,
> > > > as
> > > > > > there
> > > > > > > > are
> > > > > > > > > > > > > > > > contributions
> > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > >> > > > cannot be done, given that
> > > > Category A
> > > > > > > > depends
> > > > > > > > > > on
> > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > P3 and P4, although not
> ideal,
> > > > can be
> > > > > > > > > > understood
> > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > technical
> > > > > > > > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > > > > > > > >> > > > Depending on unmaintained
> > > > projects is
> > > > > > > > > > something
> > > > > > > > > > > > > we'll
> > > > > > > > > > > > > > > > always
> > > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > P5 and P6 are easily
> fixable,
> > as
> > > > it's
> > > > > > > > just a
> > > > > > > > > > > > matter
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > making
> > > > > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > P7 is an isolated problem
> that
> > > > won't
> > > > > > > > impact
> > > > > > > > > > the
> > > > > > > > > > > > > > > structure
> > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > > > > > > > >> > > > that we're talking about
> here,
> > > > but it
> > > > > > is a
> > > > > > > > > > > > > regression
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be
> > > ignored
> > > > for
> > > > > > > > Apache
> > > > > > > > > > KIE
> > > > > > > > > > > > 10,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the
> > only
> > > > > > problems
> > > > > > > > > > left to
> > > > > > > > > > > > > > > discuss
> > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > >> > > > P2, which can't be done
> > without
> > > a
> > > > > > proper
> > > > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > I'll try to be very
> meticulous
> > > > here,
> > > > > > since
> > > > > > > > > > from my
> > > > > > > > > > > > > > > > > experience,
> > > > > > > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > > > > > > >> > > > little miscalculation can
> lead
> > > to
> > > > our
> > > > > > > > release
> > > > > > > > > > not
> > > > > > > > > > > > > > > working
> > > > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > >> > > > end. To try and avoid that
> as
> > > > much as
> > > > > > > > > > possible,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > > >> > > > can to have a successful
> > Apache
> > > > KIE 10
> > > > > > > > > > release,
> > > > > > > > > > > > bear
> > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > me.
> > > > > > > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > > > > > > > >> > > > out a timeline of events
> that
> > > > need to
> > > > > > > > happen
> > > > > > > > > > in
> > > > > > > > > > > > > order
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > > > > > > > >> > > > to be published, with all
> > > > artifacts
> > > > > > > > ending up
> > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > right
> > > > > > > > > > > > > > > > > > > places,
> > > > > > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > > > > > >> > > > first, we need to solve
> > problems
> > > > P1
> > > > > > and
> > > > > > > > P2.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > As you saw at the beginning
> of
> > > > this
> > > > > > email,
> > > > > > > > > > all the
> > > > > > > > > > > > > > > > attempts
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > made
> > > > > > > > > > > > > > > > > > > > >> > > > left us with the circular
> > > > dependency
> > > > > > > > showing
> > > > > > > > > > up
> > > > > > > > > > > > at a
> > > > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > > > > > > > >> > > > but something all these
> places
> > > > have in
> > > > > > > > common
> > > > > > > > > > is
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > >> > > > after kogito-apps, and
> before
> > to
> > > > > > Category
> > > > > > > > B.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > The first part of my
> proposal
> > is
> > > > the
> > > > > > > > > > following:
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > S1. We keep the original
> plan
> > of
> > > > > > moving
> > > > > > > > the
> > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > UIs
> > > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > > >> > > > `kogito-apps` to
> `kie-tools`,
> > > > together
> > > > > > > > with
> > > > > > > > > > > > > Management
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > Task
> > > > > > > > > > > > > > > > > > > > >> > > > consoles from
> `kogito-images`
> > to
> > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > > > > >> > > > S2. We move the
> > > > `kogito-swf-devmode`
> > > > > > and
> > > > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > > > > > >> > > > from `kogito-images` to
> > > > `kie-tools`
> > > > > > too.
> > > > > > > > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > > > > > > > `kogito-serverless-operator`
> > > > > > > > > > > > > > repo
> > > > > > > > > > > > > > > > > > inside
> > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > > > > > > > >> > > > package on `kie-tools`,
> > keeping
> > > > Git
> > > > > > > > history.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3
> > > together
> > > > > > solve
> > > > > > > > > > problems
> > > > > > > > > > > > P1
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > P2.
> > > > > > > > > > > > > > > > > Of
> > > > > > > > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > This doesn't come without
> > > > > > consequences, of
> > > > > > > > > > course,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > images,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > > > would be
> > > > > > > > moving
> > > > > > > > > > from
> > > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > >> > > > Category B. This move would
> > make
> > > > them
> > > > > > > > have to
> > > > > > > > > > > > > > reference
> > > > > > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > > > > > >> > > > repos through timestamped
> > > > SNAPSHOTs.
> > > > > > Since
> > > > > > > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > are
> > > > > > already
> > > > > > > > > > their own
> > > > > > > > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > > > > > > > >> > > > Category A, though,
> > > contributions
> > > > > > made in
> > > > > > > > a
> > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > > > fashion
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > > > > > > > >> > > > "sub-stream" will continue
> > being
> > > > > > > > possible, now
> > > > > > > > > > > > via a
> > > > > > > > > > > > > > > > single
> > > > > > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs
> > > > between
> > > > > > > > Category
> > > > > > > > > > A and
> > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > > > >> > > > continue not being possible,
> > > and a
> > > > > > 1-week
> > > > > > > > > > delay
> > > > > > > > > > > > > > between
> > > > > > > > > > > > > > > > > > merging
> > > > > > > > > > > > > > > > > > > > >> > > > something on Category A and
> > > using
> > > > it
> > > > > > on
> > > > > > > > > > Category B
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > still
> > > > > > > > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > It's worth mentioning that
> > > > > > `kie-tools`,
> > > > > > > > > > however,
> > > > > > > > > > > > > does
> > > > > > > > > > > > > > > > allow
> > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > > > > > > > >> > > > checkouts and partial
> builds,
> > so
> > > > > > working
> > > > > > > > with
> > > > > > > > > > a
> > > > > > > > > > > > > subset
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > > > > >> > > > is possible and encouraged.
> > > Making
> > > > > > changes
> > > > > > > > > > only to
> > > > > > > > > > > > > > > > > > > > >> > > >
> `packages/kn-plugin-workflow`,
> > > for
> > > > > > > > example,
> > > > > > > > > > will
> > > > > > > > > > > > > have
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you
> > can
> > > > see
> > > > > > here:
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > > > > >> > > > We're not compromising when
> > > > running
> > > > > > > > partial
> > > > > > > > > > builds
> > > > > > > > > > > > > > too.
> > > > > > > > > > > > > > > We
> > > > > > > > > > > > > > > > > > know
> > > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > >> > > > the entire repo will
> continue
> > > > working
> > > > > > even
> > > > > > > > > > after
> > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > building a
> > > > > > > > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > > > > > > > >> > > > subset of the changes. Doing
> > > > partial
> > > > > > or
> > > > > > > > full
> > > > > > > > > > > > builds
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > > > > > > > >> > > > determined by the changes
> of a
> > > PR.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Keep in mind that, even
> though
> > > I'm
> > > > > > > > proposing
> > > > > > > > > > we
> > > > > > > > > > > > > move a
> > > > > > > > > > > > > > > > bunch
> > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > >> > > > additional stuff into
> > > > `kie-tools`, I
> > > > > > see
> > > > > > > > this
> > > > > > > > > > as a
> > > > > > > > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > > > > > > > >> > > > for our codebase.
> `kie-tools`
> > > > would
> > > > > > host
> > > > > > > > some
> > > > > > > > > > > > > > additional
> > > > > > > > > > > > > > > > > stuff
> > > > > > > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can
> > > > release and
> > > > > > > > > > continue
> > > > > > > > > > > > > moving
> > > > > > > > > > > > > > > > > > forward.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > As I mentioned on other
> > places,
> > > > > > > > `kie-tools`
> > > > > > > > > > > > became a
> > > > > > > > > > > > > > > > > polyglot
> > > > > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > > > > >> > > > out of necessity, and
> although
> > > I'm
> > > > > > really
> > > > > > > > > > proud of
> > > > > > > > > > > > > > what
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > > > > > > > >> > > > there so far, I don't think
> > > > > > `kie-tools`
> > > > > > > > has a
> > > > > > > > > > > > setup
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > > > > > > > >> > > > for all the different
> nuances
> > > that
> > > > > > > > compose our
> > > > > > > > > > > > > > > community.
> > > > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > > > > > >> > > > aware that a polyglot
> monorepo
> > > > that
> > > > > > does
> > > > > > > > not
> > > > > > > > > > > > follow
> > > > > > > > > > > > > > > > > widespread
> > > > > > > > > > > > > > > > > > > > >> > > > conventions will scare some
> > > people
> > > > > > away,
> > > > > > > > and
> > > > > > > > > > as
> > > > > > > > > > > > much
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > we've
> > > > > > > > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > > > >> > > > make build instructions
> clear,
> > > we
> > > > > > can't
> > > > > > > > > > always get
> > > > > > > > > > > > > > past
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > > > > > > > >> > > > some people have towards the
> > > > > > "front-end"
> > > > > > > > > > > > ecosystem.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > With all that said, I keep
> > > > thinking
> > > > > > this
> > > > > > > > is
> > > > > > > > > > the
> > > > > > > > > > > > best
> > > > > > > > > > > > > > > > course
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > > > > > > > >> > > > for us right now. We keep
> most
> > > of
> > > > our
> > > > > > > > stuff
> > > > > > > > > > > > > unchanged,
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > > >> > > > release, and we have a
> working
> > > > setup
> > > > > > that
> > > > > > > > will
> > > > > > > > > > > > suit
> > > > > > > > > > > > > us
> > > > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > >> > > > discuss and reach a
> conclusion
> > > > > > regarding
> > > > > > > > the
> > > > > > > > > > > > future
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Let me paint a quick picture
> > > here
> > > > of
> > > > > > what
> > > > > > > > our
> > > > > > > > > > code
> > > > > > > > > > > > > > base
> > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > > > > > > >> > > > like, repository-wise, if my
> > > > proposal
> > > > > > is
> > > > > > > > > > accepted:
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-drools
> > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-optaplanner
> > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-kogito-docs
> > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > > > > > > > >> > > > A
> incubator-kie-docs
> > > > > > > > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-benchmarks
> > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > >> > > > B
> > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > > >> > > > B
> > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > >> > > > D
> > > > > > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > >> > > > E
> > incubator-kie-issues
> > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > incubator-kie-kogito-website
> > > > > > > > > > > > > > > > > > > > >> > > > E
> > > incubator-kie-website
> > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > incubator-kie-kogito-online
> > > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > * Category C becomes part of
> > > > Category
> > > > > > A,
> > > > > > > > and
> > > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > > moves
> > > > > > > > entirely
> > > > > > > > > > inside
> > > > > > > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > > > > >> > > > * With
> > > > `kogito-swf-{builder,devmode}`
> > > > > > > > images
> > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > > > inside
> > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > there
> > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > > > > > > > >> > > > anymore, as inside
> > `kie-tools`,
> > > > we can
> > > > > > > > > > granularly
> > > > > > > > > > > > > > build:
> > > > > > > > > > > > > > > > > > > > >> > > > 1.
> > > > > > > > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > > > > >> > > > 2.
> > > > > > packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > > > > >> > > > 3.
> > > packages/sonataflow-images
> > > > > > > > (containing
> > > > > > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > > > > > > > >> > > > 4.
> > > > packages/sonataflow-operator
> > > > > > > > (contents
> > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > > >> > > >
> `kogito-serverless-operator`)
> > > > > > > > > > > > > > > > > > > > >> > > > 5.
> > > > packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > The second part of the
> > proposal
> > > > is the
> > > > > > > > release
> > > > > > > > > > > > > process
> > > > > > > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > > > > > > >> > > > assuming the structure above
> > is
> > > > what
> > > > > > we
> > > > > > > > have.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > 1. Define a timestamped
> > SNAPSHOT
> > > > to be
> > > > > > > > used as
> > > > > > > > > > > > > cutting
> > > > > > > > > > > > > > > > point
> > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > > > > > > > >> > > > 2. Update Category B repos
> to
> > > > point to
> > > > > > > > this
> > > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > > > >> > > > verify that everything is
> > > working.
> > > > > > > > > > > > > > > > > > > > >> > > > 3. At this point, with
> > > everything
> > > > > > > > working, we
> > > > > > > > > > can
> > > > > > > > > > > > > > branch
> > > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from
> the
> > > > > > timestamped
> > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > tag,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > > > > > > > >> > > > 4. All Category A and
> > Category B
> > > > repos
> > > > > > > > update
> > > > > > > > > > > > their
> > > > > > > > > > > > > > > > versions
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x`
> > > > branches.
> > > > > > > > > > > > > > > > > > > > >> > > > 5. Update Category B repos
> to
> > > > point to
> > > > > > > > > > Category A
> > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > > > > > > > >> > > > 6. At this point, we can
> vote
> > on
> > > > the
> > > > > > > > release
> > > > > > > > > > based
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > > > > > > > >> > > > branches, given we don't
> > expect
> > > > any
> > > > > > code
> > > > > > > > > > changes
> > > > > > > > > > > > > > > anymore.
> > > > > > > > > > > > > > > > > > > > >> > > > 7. After voting passes,
> we're
> > > > good to
> > > > > > > > start
> > > > > > > > > > the
> > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > > > > > > >> > > > 8. Category A repos follow
> > their
> > > > > > > > > > manual/automated
> > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x`
> > branch.
> > > > Tags
> > > > > > > > pushed
> > > > > > > > > > to
> > > > > > > > > > > > Git,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to their
> > > > registries.
> > > > > > > > > > > > > > > > > > > > >> > > > 9. We wait a little bit for
> > > > Category A
> > > > > > > > > > artifacts
> > > > > > > > > > > > to
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > > > > > > > >> > > > 10. Category B repos follow
> > > their
> > > > > > > > > > manual/automated
> > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x`
> > branch.
> > > > Tags
> > > > > > > > pushed
> > > > > > > > > > to
> > > > > > > > > > > > Git,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to their
> > > > registries.
> > > > > > > > > > > > > > > > > > > > >> > > > 11. Category D repos are
> > > ignored.
> > > > > > > > > > > > > > > > > > > > >> > > > 12. Category E repos can be
> > > > manually
> > > > > > > > tagged
> > > > > > > > > > with
> > > > > > > > > > > > > > 10.0.0
> > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > More needs to be discussed
> if
> > > > we're
> > > > > > > > planning
> > > > > > > > > > to
> > > > > > > > > > > > > > maintain
> > > > > > > > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > > > > > > > >> > > > release streams in parallel,
> > > but I
> > > > > > guess
> > > > > > > > it
> > > > > > > > > > can
> > > > > > > > > > > > wait
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Thank you for reading, and
> I'm
> > > > looking
> > > > > > > > > > forward to
> > > > > > > > > > > > > > > hearing
> > > > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Of course, alternative
> > solutions
> > > > are
> > > > > > > > possible.
> > > > > > > > > > > > This
> > > > > > > > > > > > > > > email,
> > > > > > > > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > > > > > > > >> > > > summarizes my view of how we
> > > > should
> > > > > > > > attack the
> > > > > > > > > > > > > > problem,
> > > > > > > > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > > > > > > > >> > > > disruption, required effort,
> > the
> > > > > > release
> > > > > > > > > > process
> > > > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > > > > > > > >> > > > Feel free to propose
> > > alternatives.
> > > > > > This is
> > > > > > > > > > not a
> > > > > > > > > > > > > > voting
> > > > > > > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > > > > > > > >> > > > For additional commands,
> > e-mail:
> > > > > > > > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Jan Šťastný <js...@apache.org>.
Hello,
I'll try to summarize the challenges I am aware of in relation to CI at the
moment and with the proposals.
(I am referring to projects forming the build chain as upstream <->
downstream depending on their placing in the overall chain.)
Current state:
Category A projects:
- We don't have one, but rather 3 sets of pipelines for project groups:
drools, kogito and optaplanner, all these three utilizing a combination of
GHA (mostly PR checks) and Jenkins pipelines based on
apache/incubator-kie-kogito-pipelines framework (kogito-pipelines FW).
- For these builds, we use build-chain tool, which allows to define
cross-repository relations between projects, clone repositories and run
custom commands in each of those, depending in what part of the build chain
(considering the project triggering the build) they are invoked (upstream,
downstream, current). Examples of the build-chain project dependencies
configuration Tiago provided in the first email. Build-chain is a powerful
tool, though we have limited knowledge (Roberto being the sole contributor
of fixes since our move to ASF).
- As part of the kogito pipeline kogito-images and *-operator jobs are
attached, but relation to repositories earlier up the chain is either
assumed (building from main branch of kogito-apps) or loose (building
kogito-examples from main-nightly branch, which is created in preceding
kogito-examples nightly build). It's not part of PR checks for repositories
up the stream.
Category B projects:
- We have a unique solution based mainly on GHA, but recently also some
parts (is it a backup?) in ASF Jenkins, but NOT using the kogito-pipelines
FW.
Category C projects:
- There are loosely managed jobs for *-benchmarks repositories, just a
matter of updating versions, easily manageable - won't discuss further.
Current gaps:
Category A projects:
- Generally the current jenkins solution for PR checks is lacking, we have
just a single kind of PR check, not allowing custom triggers (e.g. by
comments) or various modes (like quarkus native build).
- We don't have downstream builds as part of PR checks.
- We build all in a single job. Which has resulted in execution time over 8
hours which was not bearable. Thus we reduced the build scope to sort of
compile downstream builds - we run tests for repositories that are part of
the PR, but their dependents (coming after them) are only run without tests.
- With the introduction of unified SNAPSHOTs we have not fully adjusted for
this in our pipelines, leaving out relations like optaplanner -> drools and
kogito-apps -> optaplanner - so problems will be missed in case of related
PRs. This SNAPSHOT version unification indicates that instead of 3 distinct
buildchain configurations, we should now switch to a single one, especially
for the sake of unification.
- Part of the repositories (starting with kogito-images) are not attached
in the build-chain build at all, but are rather consecutively executed
pipelines relying on publishing artifacts for consumption downstream.
Proposal assessment:
- Almost any repository could be part of the build-chain configuration,
complex invocations can be hidden e.g. using make.
- Any changes to PR checks should have the following prerequisite not to
increase complexity and to limit execution times: moving of all PR checks
into GHA, introduction of isolated limited-scope PR checks, on-demand full
downstream build.
- Timestamped SNAPSHOTs consumed by kie-tools would call against attaching
kie-tools into build-chain of drools/kogito, because we would be running PR
checks/nightly against main which might differ from the timestamped
SNAPSHOT. So this seems like either/or decision to me.
- Build-chain would probably not be able to replicate the fine-grained
build execution based on the changes in PR as kie-tools currently has in
place.
- It's not clear to me how/if we could generally limit scope of execution
in downstream builds depending on scope of upstream repository changes.
- Community CI has really limited human resources, I personally switched to
an ad-hoc way of working on that, only when something breaks.
- It's not clear to me how a build-chain would work in terms of
consuming/passing artifacts outside of maven projects and artifacts.
- It's fair to say that we have SMEs for CI/build in Category A (engines or
cloud), Category B, but I don't think there's anyone knowing deep internals
of all, to be able to provide a reliable estimate of efforts involved in
bigger refactoring.
Summary:
I don't see an easy way how a simple change in CI would help to unblock the
current situation. Considering Tiago's proposal, timestamped SNAPSHOTs
already in place, assumed relative simplicity of making the components part
of kie-tools build ...
+1 from me
Thanks.
Best Regards
Jan
On Thu, 14 Mar 2024 at 11:24, Francisco Javier Tirado Sarti <
ftirados@redhat.com> wrote:
> Hi Tiago, Thanks for the detailed explanation
> Actually, for tooling, where there is not strong dependency (as between
> engine code in runtime and kie server api in drools), the fixed snapshot
> mechanism will work pretty well, in my opinion.
> On one side, an example that depends on devui will not fail to compile
> because the snapshot is old. The contrary is also true, if we add a new
> functionality in the server side that is going to be used by any tool, the
> worst that might happen is that the functionality is not there in the old
> snapshot, but it wont block tooling compilation (obviously if you need that
> functionality to test a new UI feature, you will need the update snapshot,
> but that's expected and I guess is also happening now, you need to wait for
> the server artifact to be published on Maven)
> Because of that loose dependency, tooling can be run, as it is, as an
> almost completely separate project but also because of that, I feel it
> might be easily integrated (except for CI changes, which are always
> delicate) with the rest of the repos to achieve a single release number,
> because, if all repos use the same snapshot, as far as there is one
> snapshot, in the day by day experience everything will normally compile.
> I think we agree that the natural place of tooling in the dependency chain
> is after apps (service) and before images. With that in mind and if we
> wholly embrace the consequence of being a single release, in my opinion, it
> means that tooling become one more repo (no A no B category), which use a
> fixed snapshot as the rest, and it is subject to the need to eventually
> wait for the updated snapshot (or in case you cannot wait, a local full
> build), in the unlikely case there is a change that blocks its local
> compilation. The implication of this is that the development cycle that is
> implicit in your proposal to use a "fixed snapshot" in category A repos no
> longer apply.
> This means no time to adjust, which can sound like an herexy, but, if there
> is no need for a gap between drools and runtimes, why is there a need for a
> gap between tooling and apps (services)? (I think we agree a Java API
> dependency is stronger than a REST API) Do we have a real precedent that
> justify that? I kind of feel that here we are converting an old habit into
> an axiomatic need (probably because Im lacking context)
> Now my proposal for CI, we do not really need a single stream right now. We
> can keep the current kogito stream as it is, except for images, and
> integrate tooling into the stream that is now used for the operator (the
> assumption here is that a change in drools-runtimes hardly breaks the tools
> and in any case that is already happening, so we do not lose anything)
>
>
> On Wed, Mar 13, 2024 at 8:18 PM ricardo zanini fernandes <
> ricardozanini@gmail.com> wrote:
>
> > Hey Tiago, thanks for the insights, I appreciate it.
> >
> > Just one thing regarding building from kie-tools one module that images
> > need to sync changes. That might happen, of course. If I see a problem in
> > devui, I just report it in the tools repo, we work on the bug, and in the
> > next image build we get the changes. By the nature of the
> operator/images,
> > such changes won't impact our builds. What impact our builds are
> > self-contained on those repos or work made in the engines, where we rely
> on
> > Snapshots.
> >
> > I understand your concern and it's a valid point, but in practice, it's
> not
> > what happens. We can live with the latest released version from npm
> > packages during the dev phase without any problems. From the
> > images/operator perspective, they are yet another package I need to
> install
> > on my container. Like `cat` or `jq`.
> >
> > But we need to sit down and try to understand our boundaries and how to
> do
> > integration tests based on them. For example, deploying a devmode
> workflow
> > in Kubernetes and starting a workflow instance via the devui console.
> >
> > On Wed, Mar 13, 2024 at 3:54 PM Tiago Bento <
> tiagobentofernandes@gmail.com
> > >
> > wrote:
> >
> > > Francisco,
> > >
> > > I agree with you that both reasonings are not antagonistic, as an
> > > antagonistic reasoning in this case would be one that doesn't work.
> > > And I believe it is clear now that the initial proposal shared on this
> > > email thread does work, but it is not the only possibility. From the
> > > beginning I said there are alternatives, but I wanted to start the
> > > conversation from my point of view, sharing what I think is best. We
> > > have to acknowledge, though, IMHO, that the discussions we had thus
> > > far cannot be understood as clearly as what was initially laid out,
> > > given the lack of details/analysis and a clear execution plan.
> > >
> > > Let me elaborate on top of the 3-step plan you shared.
> > >
> > > 1)
> > > No comment. This should be pretty simple to do.
> > >
> > > 2)
> > > There is no global CI stream to be changed, we would have to create
> > > one. And this has serious implications to our contribution model for
> > > cross-repo PRs. As I described on the first email of this thread,
> > > Category A repos are configured in several disjoint streams. Sending a
> > > PR to `drools` and `kogito-runtimes` will work great, but sending a PR
> > > to `drools` and `kogito-images`, or `drools` and `optaplanner` won't
> > > verify that everything will continue working after the PRs are merged,
> > > as our PR checks are not prepared to build this combination of repos
> > > together. This is a problem, in my view, but I hardly contribute to
> > > Category A repos, so I'm assuming things are working fine for those
> > > who do. The proposal shared on the first email of this thread does not
> > > change the contribution workflow for any repo of Apache KIE, and
> > > everyone can continue contributing the way they're used to, except for
> > > people contributing to the `kogito-swf-{builder,devmode}` images, and
> > > to `kogito-serverless-operator`. On the other hand, having `kie-tools`
> > > built in the middle of a new global CI stream, would span another
> > > class of problem, which is very closely related to the third bullet
> > > point of the plan you shared.
> > >
> > > 3)
> > > Maven has a mechanism to achieve this pseudo-synchronicity between
> > > multiple repositories. The mutable SNAPSHOT version, built nightly. It
> > > is not perfect, though, as I'm sure many of us already experienced
> > > pulling from the `main` branch of a single repo only to find out that
> > > a PR ensemble had been merged a few moments prior, requiring us to
> > > rebuild the entire stack, since our local SNAPSHOTs had become
> > > out-of-date. That's what we used to have back in Business Central
> > > (a.k.a. v7) days. Making a `git pull` on a single repo in this setup
> > > potentially requires all repos to be pulled and rebuilt. I'm sure this
> > > still happens sometimes when developing Category A projects.
> > >
> > > NPM packages don't have mutable SNAPSHOTs. Every published NPM package
> > > is immutable, and it is really cumbersome and error-prone to integrate
> > > downstream repos with upstream NPM-bound repos, as not having a
> > > lockfile brings all sorts of security and stability problems. That's
> > > why monorepos became so popular in the JavaScript ecosystem. This lack
> > > of a mutable SNAPSHOT mechanism makes depending on NPM artifacts
> > > coming from `kie-tools` really hard. The way I see it, moving repos
> > > downstream of `kie-tools` will require everyone to build `kie-tools`
> > > anyway, potentially on a daily basis, since it would've then become
> > > part of the stack that needs to be built before `kogito-images` and
> > > `kogito-serverless-operator`. More than that, since there would be no
> > > way to determine what subset of packages of `kie-tools` would need to
> > > be built to satisfy downstream references, everyone would have to do a
> > > full build, or handpick individual packages of the monorepo to build.
> > >
> > > I hope I was able to offer more insight in the way I see things, along
> > > with my take on using Maven SNAPSHOTs as the de-facto solution for a
> > > poly-repo codebase. I don't think we can escape from the complexity of
> > > our codebase and the nature of the technologies we use, only
> > > accommodate it in the most comfortable place possible, if even there
> > > is such a place :)
> > >
> > > Now, there are some things I'd like to say regarding the initial
> > > proposal shared on this email thread.
> > >
> > > I understand you, and others, are concerned about moving stuff into
> > > `kie-tools` for some reasons I could gather from your messages. I'll
> > > try and list them here, along with my perspective on each of them.
> > >
> > > 1. Never being able to move them out of `kie-tools` again.
> > > This is going to be as hard as it would be removing
> > > `kn-plugin-workflow` from it now. So, as you and others mentioned this
> > > possibility, I assume you understand it to be doable.
> > >
> > > 2. "Heterodoxizing" an orthodox repository
> > > (`kogito-serverless-operator`), potentially harming external
> > > contributions.
> > > Agree with this point. `kie-tools` is one of a kind, built around
> > > front-end tooling with some completely unique in-house apparatus. In
> > > my experience, though, there are a multitude of factors that make
> > > people want to contribute to an open source project. Conformance to
> > > well-known widespread technologies and tools is just one of them.
> > > Being open about it and writing material to smooth out those edges can
> > > work pretty well. People do not contribute because a codebase is
> > > "pure". People contribute because they care about the project. And I'm
> > > always surprised by the lengths people go to when they want to get
> > > involved.
> > >
> > > 3. Disruption to the contribution workflow of those contributing to
> > > `kogito-swf-{builder,devmode}` images, and to
> > > `kogito-serverless-operator`.
> > > It is clear to me now that we can't unblock and release Apache KIE 10
> > > without impacting anyone, but I hope the first part of this reply
> > > sheds some light on this complicated matter.
> > >
> > > Anyway, that's my attempt to offer a different perspective to some of
> > > the problems you expressed concern about, perhaps even making the
> > > initial proposal shared on this email thread be seen with less
> > > uncertainty.
> > >
> > > On Wed, Mar 13, 2024 at 11:40 AM Francisco Javier Tirado Sarti
> > > <ft...@redhat.com> wrote:
> > > >
> > > > Tiago,
> > > > Unfortunately, my plan is too conceptually simple to write more than
> I
> > > > already wrote.
> > > > 1) Move kn-plugin-workflow module to operator repo (this remove the
> > > > dependency between tools and operator, breaking the loop)
> > > > 2) Change CI global stream to execute tooling repo before operator
> repo
> > > > (this seems to take 2 months unless Tristan helps and reduce the time
> > to
> > > 2
> > > > weeks)
> > > > 3) Optionally, and just as a consequence of that CI change, set
> > > > 999-SNAPSHOT version to all poms in all repos (if current snapshot
> > > numbers
> > > > turns out to be a problem, in any case this is just search-replace)
> > > >
> > > > The current plan is:
> > > > 1) Move everything depending on tools to tools repo, which includes
> > > > operator code and examples.
> > > > 2) Change CI of tooling repo to enforce dependencies between the
> > existing
> > > > modules there and the newly moved ones (this seems to take 3 weeks or
> > > less)
> > > >
> > > > I think rather than asking for a more detailed alternative, what
> needs
> > to
> > > > be done is to refine the existing proposal with the feedback
> received.
> > I
> > > do
> > > > not think both proposals are antagonistic. I think that, being now
> > clear
> > > we
> > > > have the same overall goal (execute tooling before operator), it is
> > just
> > > a
> > > > question of deciding between move more stuff to an already heterodox
> > > repo,
> > > > coming from repos not as heterodox, plus changing the repo CI to
> impose
> > > > certain order between these modules or pull out the the operator
> stuff
> > > from
> > > > tool repo and put it inside the operator repo plus changing the CI
> > > > handling repos to impose the desired order: first tooling and then
> > > operator.
> > > >
> > > > On Wed, Mar 13, 2024 at 4:12 PM Tiago Bento <
> > > tiagobentofernandes@gmail.com>
> > > > wrote:
> > > >
> > > > > Francisco,
> > > > >
> > > > > 1) `kie-tools` is already a heterodox repo. The reason why I
> proposed
> > > > > my proposal is because it is what I think is the best course of
> > action
> > > > > for our community right now. If you think there's a better way to
> do
> > > > > it, I think everyone, including me, needs to see a proposal with a
> > > > > clear execution plan with a comparable level of detail and analysis
> > in
> > > > > regards to disruption of the current state, the required effort,
> the
> > > > > contribution workflow for cross-repo PRs, and the release process
> > > > > itself. Otherwise, we risk having gaps that each person will fill
> in
> > a
> > > > > different way, and IMHO, that's where problems happen. +1 for
> > examples
> > > > > unification, btw :)
> > > > >
> > > > > 2) Ok, and +1 for no categorization.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado Sarti
> > > > > <ft...@redhat.com> wrote:
> > > > > >
> > > > > > 1) Ok, if that is the case, I do not get why your first proposal
> > was
> > > not
> > > > > > the one I'm proposing and it is apparently not detailed enough.
> To
> > > move
> > > > > > kn-workflow from tooling to operator one and change the order in
> > > which
> > > > > the
> > > > > > repos are being processed. Basically, the problem of the proposed
> > > > > solution
> > > > > > is that it kind of converts tooling repo into a pretty heterodox
> > repo
> > > > > > compared with runtimes, drools or operator one. Also once tooling
> > is
> > > not
> > > > > a
> > > > > > final repo in the overall chain, we can consider moving examples
> as
> > > the
> > > > > > final one and include tooling showcases there (rather than
> > splitting
> > > > > > examples into examples with tooling and examples without
> tooling).
> > > > > > 2) I think this distinction between A and B is one between
> several
> > > > > possible
> > > > > > categorizations (not much, including no categorization at all)
> that
> > > > > > deserves a separate discussion. I will open a separate thread for
> > > that
> > > > > > purpose, since we are not going to change that now and it is not
> > > really
> > > > > > part of the proposal.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
> > > > > tiagobentofernandes@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Francisco,
> > > > > > >
> > > > > > > 1) That's what this thread is all about... You know I don't
> think
> > > it's
> > > > > > > ok. That's why I'm proposing the two images and the operator to
> > > move
> > > > > > > into the `kie-tools` repo, where we can more granularly control
> > the
> > > > > > > order things are built, thus removing the dependency cycle.
> > > > > > >
> > > > > > > 2) Not sure we understand the same thing by "freeze". My
> proposal
> > > is
> > > > > > > that we select a timestamped SNAPSHOT version from Category A
> > > repos to
> > > > > > > use as base for a release. We give Category B repos some time
> to
> > > > > > > adjust, and then cut the release branches. This can happen
> > anytime,
> > > > > > > and no contributions would ever stop because of it. The
> > development
> > > > > > > branches can continue accepting PRs normally, even during the
> > > release
> > > > > > > process. Now, if what you're asking is why Category B repos
> refer
> > > to
> > > > > > > Category A repos via timestamped SNAPSHOTs, the answer is in my
> > > first
> > > > > > > email. See the paragraph starting with "An important note here
> is
> > > that
> > > > > > > Category B repositories...".
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti
> > > > > > > <ft...@redhat.com> wrote:
> > > > > > > >
> > > > > > > > Tiago
> > > > > > > > There are a couple of simple and straightforward questions
> > that
> > > I
> > > > > > > > formulated, but since we both write a lot, it might have been
> > > lost.
> > > > > > > Please
> > > > > > > > let me ask them again.
> > > > > > > > 1) Do you think it is ok that tools repo is executed after
> > > > > generation of
> > > > > > > > docker images that are supposed to include those tools or the
> > > > > operator
> > > > > > > that
> > > > > > > > is supposed to deploy such images?
> > > > > > > That's what this thread is all about... You know I'm not ok
> with
> > > it,
> > > > > > > that's why I'm proposing the two images and the operator to
> move
> > > into
> > > > > > > the `kie-tools` repo, where we can more granularly control the
> > > order
> > > > > > > things are built and remove the dependency cycle.
> > > > > > > > 2) Besides that, although not directly related with the
> current
> > > > > proposal
> > > > > > > we
> > > > > > > > are discussing, I really think there are some restrictions
> > taken
> > > for
> > > > > > > > granted that are arbitrary and difficult to sustain on
> strictly
> > > > > technical
> > > > > > > > arguments. For example, the need to freeze the rest of the
> > > software
> > > > > > > before
> > > > > > > > tools are generated. Why? We have dependencies between repos
> > that
> > > > > are not
> > > > > > > > handled that way: Apps depend on runtimes. Runtimes depend on
> > > drools,
> > > > > > > > Operator depend on runtimes,....and we are not freezing that
> > > repos
> > > > > since
> > > > > > > we
> > > > > > > > are all releasing at the same time. If we are all releasing
> at
> > > the
> > > > > same
> > > > > > > > time, what's the rationale behind the freeze?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <
> > > tiagobento@apache.org>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Glad to see the interest this proposal has gotten, and it's
> > > good to
> > > > > > > > > see some alternatives being drafted here, although still
> > > lacking
> > > > > clear
> > > > > > > > > definitions and analysis in regards to disruption, required
> > > effort,
> > > > > > > > > the release process itself, and history. Of course, lots of
> > > details
> > > > > > > > > and clarity on the execution part would be missing too.
> > > > > > > > >
> > > > > > > > > As of this moment, based on what I read here, I'm assuming
> > that
> > > > > > > > > everyone who participated so far doesn't see the initial
> > > proposal
> > > > > as
> > > > > > > > > problematic in terms of feasibility, but some of you have a
> > > > > preference
> > > > > > > > > not to go with it, because it is "wrong", and apparently
> > > because it
> > > > > > > > > would "jeopardize the evolution of the project". Reading
> > these
> > > last
> > > > > > > > > words made me a little sad, to be honest. But I can deal
> with
> > > it :)
> > > > > > > > >
> > > > > > > > > Please let's try and keep the discussion as objective as
> > > possible.
> > > > > > > > > "Right" and "wrong" are too subjective for this kind of
> > > > > conversation.
> > > > > > > > >
> > > > > > > > > Now, being practical, unless there are clear arguments
> based
> > on
> > > > > facts
> > > > > > > > > and objective concepts that invalidate the initial proposal
> > > shared
> > > > > on
> > > > > > > > > this email, it seems to me that it is currently the only
> > viable
> > > > > > > > > proposal we have for unblocking and releasing Apache KIE
> 10.
> > Of
> > > > > > > > > course, if we end up seeing an alternative proposal with
> > enough
> > > > > > > > > details and a clear execution plan, I think then we'll be
> in
> > a
> > > very
> > > > > > > > > good position to choose from multiple options!
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <
> > > alex@porcelli.me>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Francisco and Gabriele,
> > > > > > > > > >
> > > > > > > > > > I understand and acknowledge your desire to find the
> > “right”
> > > > > solution
> > > > > > > > > > instead to work on a temporary “patch” - however without
> a
> > > > > detailed
> > > > > > > > > > proposal I don’t think we can properly evaluate the
> impact
> > of
> > > > > your
> > > > > > > > > > suggestion.
> > > > > > > > > >
> > > > > > > > > > When I spoke with different SMEs that included tools and
> > CI,
> > > the
> > > > > > > > > > guesstimate for making the necessary changes on CI and
> > > codebase
> > > > > to
> > > > > > > > > > basically have images and operators in the end of the
> build
> > > > > chain is
> > > > > > > > > > something like 2 months of effort. Another impact that
> > needs
> > > to
> > > > > be
> > > > > > > > > > discussed is that KIE Tools repo had to be injected in
> the
> > > > > middle of
> > > > > > > all
> > > > > > > > > > pipelines - forcing all PR checks and nightlies to build
> > all
> > > > > repos
> > > > > > > (PR
> > > > > > > > > > checks will likely take 12+ hours… I even heard that it
> > > could be
> > > > > > > even 24
> > > > > > > > > > hours).
> > > > > > > > > >
> > > > > > > > > > Based on the input above, I think it’s quite risk to move
> > in
> > > such
> > > > > > > > > direction
> > > > > > > > > > without a more detailed plan… because 2 months could be
> > > turned
> > > > > > > easily in
> > > > > > > > > 6!
> > > > > > > > > > And this is exactly what happened when we guessed that
> > > moving to
> > > > > > > Apache
> > > > > > > > > > would take no more than 3 months. But here we are.
> > > > > > > > > >
> > > > > > > > > > I really strongly suggest that we focus on a release that
> > > could
> > > > > be
> > > > > > > > > > achievable in less than a month from now, and we - after
> > > release
> > > > > -
> > > > > > > have a
> > > > > > > > > > in depth discussion about the overall codebase and ci
> > > > > organization.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Alex,
> > > > > > > > > > > my suggestion is to move the building of all docker
> > images,
> > > > > from
> > > > > > > > > whatever
> > > > > > > > > > > repo (kogito-apps, kie-tools) in a different,
> downstream
> > > repo,
> > > > > to
> > > > > > > be
> > > > > > > > > > > invoked after all the others.
> > > > > > > > > > > I'm not sure if this would solve all the issues, and
> > since
> > > I
> > > > > could
> > > > > > > not
> > > > > > > > > > > enter in the details of all the involved code, my
> > > suggestion
> > > > > may
> > > > > > > be too
> > > > > > > > > > > naive.
> > > > > > > > > > > Having spent almost all of the last year in CI, I may
> > say
> > > > > that, at
> > > > > > > > > least
> > > > > > > > > > > for the kie-tools repo, removing the image build step
> > from
> > > it
> > > > > > > should
> > > > > > > > > not be
> > > > > > > > > > > too difficult (since it is an issue we already faced
> and
> > > > > solved).
> > > > > > > > > > > If, with "detailed proposal", you mean a complete list
> of
> > > all
> > > > > > > modules
> > > > > > > > > to be
> > > > > > > > > > > moved and dependency refactoring, of course I can not
> > > provide
> > > > > it
> > > > > > > right
> > > > > > > > > now.
> > > > > > > > > > >
> > > > > > > > > > > Anyway, I share the concern from Francisco: undoing
> > > something
> > > > > is
> > > > > > > almost
> > > > > > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco
> Javier
> > > > > Tirado
> > > > > > > Sarti
> > > > > > > > > <
> > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > >
> > > > > > > > > > > > I do not think estimations should be the only driver
> to
> > > make
> > > > > a
> > > > > > > > > decision,
> > > > > > > > > > > > especially when the current proposal is conceptually
> > > > > incompatible
> > > > > > > > > with
> > > > > > > > > > > the
> > > > > > > > > > > > multi repo approach that is taken elsewhere in the
> > > project.
> > > > > > > > > > > > Given my knowledge of the CI it is nearly impossible
> > for
> > > me
> > > > > to
> > > > > > > give
> > > > > > > > > a
> > > > > > > > > > > fair
> > > > > > > > > > > > estimate of how much it might take to achieve step 2)
> > of
> > > my
> > > > > > > previous
> > > > > > > > > > > e-mail
> > > > > > > > > > > > . It might take a while or it might be pretty easy
> > after
> > > > > all, I
> > > > > > > don't
> > > > > > > > > > > > really know, but I think it will be a good idea if
> > some
> > > of
> > > > > the
> > > > > > > > > experts
> > > > > > > > > > > on
> > > > > > > > > > > > CI in the team (the ones that set up the pipeline,
> > which
> > > was
> > > > > a
> > > > > > > huge
> > > > > > > > > > > > achievement) give an estimate, not me. Estimating
> how
> > > much
> > > > > it
> > > > > > > takes
> > > > > > > > > to
> > > > > > > > > > > > merge two existing repos (without altering CI) is
> > easier,
> > > > > but it
> > > > > > > > > does not
> > > > > > > > > > > > mean we are doing the right thing.
> > > > > > > > > > > > My main concern is that it will be very difficult for
> > me
> > > to
> > > > > > > explain
> > > > > > > > > to
> > > > > > > > > > > > someone that arrives new to the team, that having
> > > experts on
> > > > > CI
> > > > > > > on
> > > > > > > > > the
> > > > > > > > > > > > team, we decided to merge two repos (once merged, it
> > > would be
> > > > > > > rather
> > > > > > > > > > > > difficult to unmerge) rather than fix the CI, because
> > of
> > > > > > > expediency.
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > > > > > porcelli@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Please take the time to make the more in depth
> > analysis
> > > > > needed
> > > > > > > and
> > > > > > > > > > > > provide
> > > > > > > > > > > > > a more detailed plan… so we - as community- can
> > > evaluate
> > > > > the
> > > > > > > size
> > > > > > > > > of
> > > > > > > > > > > the
> > > > > > > > > > > > > effort. In the conceptual level you shared it’s
> near
> > > > > > > impossible to
> > > > > > > > > > > > estimate
> > > > > > > > > > > > > the size of the effort and compare with the current
> > > > > proposal.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier
> > Tirado
> > > > > Sarti <
> > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > > > > > 1) Remove all dependencies from tooling to
> images,
> > > so
> > > > > images
> > > > > > > > > depend
> > > > > > > > > > > on
> > > > > > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > > > > > 2) Then change CI to deal with tooling repo
> before
> > > > > dealing
> > > > > > > with
> > > > > > > > > > > images
> > > > > > > > > > > > > > repo.
> > > > > > > > > > > > > > I understand that CI details are tricky and since
> > > I'm not
> > > > > > > > > familiar
> > > > > > > > > > > with
> > > > > > > > > > > > > CI
> > > > > > > > > > > > > > in any way, I barely can make a low level design,
> > > but we
> > > > > do
> > > > > > > not
> > > > > > > > > need
> > > > > > > > > > > to
> > > > > > > > > > > > > fix
> > > > > > > > > > > > > > everything, just achieve 2), a change of
> > compilation
> > > > > order.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > > > > > > alex@porcelli.me
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > You may not like or understand why the current
> > > state of
> > > > > > > the CI
> > > > > > > > > is
> > > > > > > > > > > > like
> > > > > > > > > > > > > > > that… actually has been in Red Hat and has been
> > > > > replicated
> > > > > > > in
> > > > > > > > > > > Apache
> > > > > > > > > > > > as
> > > > > > > > > > > > > > > used to be….
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > But the fact is that this is the current
> reality.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you disagree with the current plan, please
> > > provide a
> > > > > > > > > detailed
> > > > > > > > > > > > > > > alternative so we, as community, can better
> > > evaluate
> > > > > the
> > > > > > > pros
> > > > > > > > > and
> > > > > > > > > > > > cons
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > each proposal.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think it’s also fair to say that, post 10
> > > release we
> > > > > > > need to
> > > > > > > > > > > have a
> > > > > > > > > > > > > > much
> > > > > > > > > > > > > > > in depth discussion about how our codebase is
> > > > > organized,
> > > > > > > it’s
> > > > > > > > > clear
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > it’s not working.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele
> Cardosi
> > <
> > > > > > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > > > > > I also have the impression that the "images"
> > (if
> > > we
> > > > > are
> > > > > > > > > talking
> > > > > > > > > > > of
> > > > > > > > > > > > > > docker
> > > > > > > > > > > > > > > > images) should be the very last one to be
> > built,
> > > in a
> > > > > > > > > standalone
> > > > > > > > > > > > > repo.
> > > > > > > > > > > > > > > > That way, they may "combine" artifacts that
> are
> > > > > built in
> > > > > > > > > > > different
> > > > > > > > > > > > > > repos,
> > > > > > > > > > > > > > > > regardless of the order in which those are
> > built.
> > > > > > > > > > > > > > > > Moving them out of all the repos
> > > > > (kogito-apps/kie-tools)
> > > > > > > > > maybe
> > > > > > > > > > > > could
> > > > > > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > > > > > (I also think there are some statements of
> > > > > undisputable
> > > > > > > needs
> > > > > > > > > > > while
> > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > > > > > Anyway, this latter point is for longer,
> > > following,
> > > > > > > > > discussion.)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23
> > > Francisco
> > > > > Javier
> > > > > > > > > Tirado
> > > > > > > > > > > > > Sarti
> > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > > > > > There are two assumptions that deserve
> > further
> > > > > > > discussion:
> > > > > > > > > > > > > > > > > 1) That tool has to be the last to build.
> > why?
> > > it
> > > > > does
> > > > > > > not
> > > > > > > > > have
> > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > > to build final images after everything else
> > has
> > > > > been
> > > > > > > > > built?-
> > > > > > > > > > > > > > > > > 2) That the impact (in terms of effort now)
> > on
> > > > > fixing
> > > > > > > CI is
> > > > > > > > > > > > bigger
> > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > impact (long term consequences) of
> > > consolidating
> > > > > two
> > > > > > > > > unrelated
> > > > > > > > > > > > > piece
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex
> > Porcelli
> > > <
> > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This was discussed as an alternative
> > > solution,
> > > > > > > however
> > > > > > > > > it has
> > > > > > > > > > > > > major
> > > > > > > > > > > > > > > > > impact
> > > > > > > > > > > > > > > > > > on CI and there’s also the fact Tool has
> > been
> > > > > always
> > > > > > > the
> > > > > > > > > last
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > build
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > has no Snapshot published (actually in
> > > JavaScript
> > > > > > > world
> > > > > > > > > there
> > > > > > > > > > > > is
> > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > So, based on our evaluation… the proposal
> > > here
> > > > > is the
> > > > > > > > > least
> > > > > > > > > > > > > > > disruptive
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > will take less time to unblock the
> release.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco
> > > Javier
> > > > > > > Tirado
> > > > > > > > > > > Sarti <
> > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > After kie-tools, sorry. I think we are
> > not
> > > > > > > embracing
> > > > > > > > > the
> > > > > > > > > > > fact
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > kogito-images depend on kie-tools,
> > because
> > > we
> > > > > want
> > > > > > > > > those
> > > > > > > > > > > > images
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM
> > Francisco
> > > > > Javier
> > > > > > > > > Tirado
> > > > > > > > > > > > Sarti
> > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > > > > > It can be an alternative solution to
> > move
> > > > > > > > > > > > kn-plugin-workflow
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > kogito-images (so there is not longer
> > > > > dependency
> > > > > > > from
> > > > > > > > > > > tools
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > then build kogito-images after
> > > kogito-tools?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM
> > Enrique
> > > > > Gonzalez
> > > > > > > > > > > Martinez
> > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere
> > > Fernandez
> > > > > > > (apache)
> > > > > > > > > <
> > > > > > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >> > I say +1 in order to move forward
> > with
> > > > > the 10.
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex
> > > > > Porcelli <
> > > > > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> > > I spent the last day or so
> working
> > > > > closely
> > > > > > > with
> > > > > > > > > > > Tiago,
> > > > > > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > > > > > >> > > options and getting deeper on
> the
> > > > > impact and
> > > > > > > > > > > > evaluating
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > > > > > >> > > procedure steps required. I
> agree
> > > with
> > > > > the
> > > > > > > > > proposal
> > > > > > > > > > > as
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > most
> > > > > > > > > > > > > > > > > > > >> > > viable option for unblocking the
> > 10
> > > > > release
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > > > > > reasonable
> > > > > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM
> > > Tiago
> > > > > Bento
> > > > > > > <
> > > > > > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a
> > tl;dr
> > > this
> > > > > > > time,
> > > > > > > > > as
> > > > > > > > > > > this
> > > > > > > > > > > > > > > matter
> > > > > > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > This email will take you < 20
> > > minutes
> > > > > to
> > > > > > > read,
> > > > > > > > > > > > > according
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > As you may have followed on a
> > > separate
> > > > > > > thread
> > > > > > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > > > > > >> > > > many of us were working
> towards
> > > > > removing a
> > > > > > > > > > > circular
> > > > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > > > >> > > > currently present between
> > > > > `kogito-apps`
> > > > > > > and
> > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > As
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > >> > > > progressed towards a solution,
> > we
> > > kept
> > > > > > > > > finding the
> > > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll
> do a
> > > > > > > breakdown of
> > > > > > > > > the
> > > > > > > > > > > > > things
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Right now, even though we
> > started
> > > the
> > > > > > > effort
> > > > > > > > > to
> > > > > > > > > > > move
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we
> > > haven't
> > > > > been
> > > > > > > > > able to
> > > > > > > > > > > > do
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > yet,
> > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools
> to
> > > Java
> > > > > 17,
> > > > > > > > > Maven
> > > > > > > > > > > > 3.9.6,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito
> > > Runtimes
> > > > > > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > >> > > > effort was concluded this
> > Monday,
> > > with
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >
> > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > > > > > .
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > The current scenario we have
> is:
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > >> > > > |==> 02.
> > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > >> > > > L |
> > > > > ==========================
> > > > > > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > >> > > > |==> 07.
> > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > `kie-tools`/extended-services
> > > > > > > > > depends
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev
> UIs
> > > to
> > > > > > > > > `kie-tools`,
> > > > > > > > > > > we
> > > > > > > > > > > > > > > would've
> > > > > > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > >> > > > C |
> > > =====================
> > > > > > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > >> > > > E |==> 07.
> > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > > depends
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > >> > > >
> > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > > > > > depends
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > >> > > >
> > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > After moving the
> > > `kogito-swf-devmode`
> > > > > > > image to
> > > > > > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > >> > > > 04.
> > > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > >> > > > Y |
> > > =====================
> > > > > > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > >> > > > L |==> 07.
> > > incubator-kie-tools
> > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > > depends
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > `kogito-serverless-operator`
> > > > > > > > > depends
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger
> > > problem
> > > > > > > than a
> > > > > > > > > > > simple
> > > > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > After multiple conversations
> > with
> > > a
> > > > > lot of
> > > > > > > > > people,
> > > > > > > > > > > > > it's
> > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > >> > > > hard coming up with a simple
> > > solution
> > > > > that
> > > > > > > > > makes
> > > > > > > > > > > it
> > > > > > > > > > > > > > > possible
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while
> > > > > preserving
> > > > > > > the
> > > > > > > > > way
> > > > > > > > > > > > > > everyone
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > >> > > > contributing to the multiple
> > > > > repositories
> > > > > > > we
> > > > > > > > > have.
> > > > > > > > > > > > > More
> > > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > > > > > >> > > > while making this assessment,
> I
> > > found
> > > > > more
> > > > > > > > > > > problems
> > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > > >> > > > perspective, block Apache KIE
> > 10.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > In light of that difficulty,
> I'm
> > > > > coming
> > > > > > > > > forward
> > > > > > > > > > > with
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > >> > > > the Apache KIE release
> process,
> > > so we
> > > > > can
> > > > > > > use
> > > > > > > > > > > > Apache's
> > > > > > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth
> > > debate
> > > > > about
> > > > > > > > > this
> > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > I'll lay out my entire
> > perspective
> > > > > about
> > > > > > > the
> > > > > > > > > > > current
> > > > > > > > > > > > > > > > situation
> > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > > > > > >> > > > codebase, as well as problems
> I
> > > can
> > > > > > > currently
> > > > > > > > > see.
> > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > > start
> > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > > > > >> > > > analysis of the repositories
> and
> > > their
> > > > > > > > > purposes,
> > > > > > > > > > > > point
> > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > >> > > > problems that I believe are
> > > blocking
> > > > > our
> > > > > > > 10
> > > > > > > > > > > release,
> > > > > > > > > > > > > > > explain
> > > > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > > >> > > > proposal and discuss some
> > > > > consequences to
> > > > > > > > > what I'm
> > > > > > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, &
> KOGITO
> > > > > (count:
> > > > > > > 11)
> > > > > > > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-pipelines @
> > > > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @
> `main`
> > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @
> > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > incubator-kie-optaplanner-quickstarts @
> > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-runtimes
> > @
> > > > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @
> > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-examples
> > @
> > > > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images
> @
> > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > incubator-kie-kogito-serverless-operator @
> > > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @
> > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @
> > > `main-kogito`
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-benchmarks
> > > @
> > > > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @
> > > `main`
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @
> `main`
> > > > > > > > > > > > > > > > > > > >> > > > (Issues only, README
> should
> > be
> > > > > > > updated @
> > > > > > > > > > > `main`.
> > > > > > > > > > > > > > Same
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-website @
> > > > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > (The Kogito website.
> > Develop &
> > > > > deploy
> > > > > > > at
> > > > > > > > > the
> > > > > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-website @
> `main`
> > > > > > > > > > > > > > > > > > > >> > > > (The KIE website. Develop
> @
> > > > > `main`.
> > > > > > > Push @
> > > > > > > > > > > > > `deploy`
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online
> @
> > > > > `gh-pages`
> > > > > > > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > > > > > > sandbox.kie.org
> > > > > > > > > > > and
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-online-staging
> > > > > @
> > > > > > > `main`
> > > > > > > > > > > > > > > > > > > >> > > > (Same as above, but for
> > manual
> > > > > sanity
> > > > > > > > > checks
> > > > > > > > > > > > > during
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > I grouped the repositories by
> > > > > category,
> > > > > > > and
> > > > > > > > > listed
> > > > > > > > > > > > > them
> > > > > > > > > > > > > > > in a
> > > > > > > > > > > > > > > > > > > >> > > > topological order. Keep in
> mind
> > > that
> > > > > when
> > > > > > > > > > > flattening
> > > > > > > > > > > > > > out a
> > > > > > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > > > > > >> > > > are multiple possibilities.
> For
> > > > > example,
> > > > > > > > > > > OptaPlanner
> > > > > > > > > > > > > > > > could've
> > > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > >> > > > placed in any position after
> > > Drools.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Category A repos are what I've
> > > been
> > > > > > > referring
> > > > > > > > > to
> > > > > > > > > > > as
> > > > > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> > > > > OptaPlanner
> > > > > > > is
> > > > > > > > > inside
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > >> > > > way these repositories
> reference
> > > each
> > > > > > > other
> > > > > > > > > are
> > > > > > > > > > > > > through
> > > > > > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically,
> > the
> > > > > > > 999-SNAPSHOT
> > > > > > > > > > > > > version.
> > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > > > > > >> > > > is well-known to the team, and
> > > > > although
> > > > > > > > > flawed for
> > > > > > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > > > > > >> > > > and disruptive for people in
> > many
> > > > > > > different
> > > > > > > > > time
> > > > > > > > > > > > > zones,
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > > > >> > > > very comfortable for everyone
> to
> > > work
> > > > > > > with, I
> > > > > > > > > > > > assume.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Contributions made to
> Category A
> > > have
> > > > > some
> > > > > > > > > > > dedicated
> > > > > > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > > > > >> > > > are, at least to some extent,
> > > able to
> > > > > > > build
> > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > > > >> > > > and verify that the codebase
> > will
> > > > > continue
> > > > > > > > > working
> > > > > > > > > > > > as
> > > > > > > > > > > > > > > > expected
> > > > > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > > >> > > > they're all merged. From what
> I
> > > could
> > > > > > > gather,
> > > > > > > > > > > there
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > >> > > > "sub-streams" currently
> > > configured for
> > > > > > > > > cross-repo
> > > > > > > > > > > > PRs.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> > > > > kogito-apps,
> > > > > > > and
> > > > > > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > > > > > >> > > > - optaplanner, and
> > > > > optaplanner-quickstarts
> > > > > > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > This means that sending
> > cross-repo
> > > > > PRs to
> > > > > > > any
> > > > > > > > > > > > > > combination
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > > >> > > > that are not part of the same
> > > > > "sub-stream"
> > > > > > > > > cannot
> > > > > > > > > > > be
> > > > > > > > > > > > > > > > verified
> > > > > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > > > > >> > > > merging, making our
> contribution
> > > model
> > > > > > > > > dependent
> > > > > > > > > > > on
> > > > > > > > > > > > > > > > individual
> > > > > > > > > > > > > > > > > > > >> > > > contributors building stuff on
> > > their
> > > > > > > machines
> > > > > > > > > to
> > > > > > > > > > > > > verify
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > > > >> > > > Note that I'm not that
> familiar
> > > with
> > > > > these
> > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > > > > >> > > > someone correct me if I'm
> wrong.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Category B repos are what I've
> > > been
> > > > > > > referring
> > > > > > > > > to
> > > > > > > > > > > as
> > > > > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > > > >> > > > stream. The first repo there
> is
> > a
> > > > > template
> > > > > > > > > > > > repository
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > > > > > >> > > > people starting projects from
> > > scratch
> > > > > on
> > > > > > > KIE
> > > > > > > > > > > > Sandbox,
> > > > > > > > > > > > > > > > similar
> > > > > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > > >> > > > Maven archetype, if you will.
> > The
> > > > > other
> > > > > > > one
> > > > > > > > > is the
> > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > Tools
> > > > > > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > > > > > >> > > > a polyglot monorepo with
> `pnpm`
> > > as its
> > > > > > > build
> > > > > > > > > > > system.
> > > > > > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and
> > > apps,
> > > > > > > > > TypeScript
> > > > > > > > > > > > > > libraries
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm
> > > charts.
> > > > > The
> > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > >> > > > configured to work with sparse
> > > > > checkouts
> > > > > > > and
> > > > > > > > > can
> > > > > > > > > > > do
> > > > > > > > > > > > > > > partial
> > > > > > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > > > > > >> > > > Category B repos refer to
> > > Category A
> > > > > repos
> > > > > > > > > through
> > > > > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new
> > > mechanism we
> > > > > > > recently
> > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > > >> > > > build and publish immutable,
> > > > > persistent
> > > > > > > > > artifacts
> > > > > > > > > > > > > under
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > > > > >> > > > following the
> > > 999-YYYYMMDD-SNAPSHOT
> > > > > > > format,
> > > > > > > > > > > > published
> > > > > > > > > > > > > > > weekly
> > > > > > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped
> > > SNAPSHOTs
> > > > > are an
> > > > > > > > > > > evolution
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > > > >> > > > releases, as we're now
> targeting
> > > one
> > > > > > > release
> > > > > > > > > for
> > > > > > > > > > > all
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > > > > >> > > > we can't have Kogito releases
> > > anymore.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > An important note here is that
> > > > > Category B
> > > > > > > > > > > > repositories
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > >> > > > historically kept out of any
> > > > > automations
> > > > > > > we
> > > > > > > > > used
> > > > > > > > > > > to
> > > > > > > > > > > > > > have,
> > > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > > > >> > > > when Kogito started and we had
> > the
> > > > > > > Business
> > > > > > > > > > > Central
> > > > > > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > > > > > >> > > > still going on. For this
> reason,
> > > > > Category
> > > > > > > B
> > > > > > > > > > > projects
> > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > > > > > >> > > > their own automations, based
> on
> > > GitHub
> > > > > > > > > Actions.
> > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > > > > > >> > > > always depended on Category A
> > > repos
> > > > > using
> > > > > > > > > fixed
> > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > If
> > > > > > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > > > > > >> > > > B repos have had adopted
> mutable
> > > > > > > SNAPSHOTs,
> > > > > > > > > > > breaking
> > > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > >> > > > Category A repositories
> would've
> > > had
> > > > > the
> > > > > > > > > potential
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > break
> > > > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > > > >> > > > silently, leaving Category B
> > with
> > > a
> > > > > broken
> > > > > > > > > > > > development
> > > > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > >> > > > introducing unpleasant
> surprises
> > > for
> > > > > > > > > maintainers
> > > > > > > > > > > of
> > > > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > > > > > >> > > > as historically Category A
> > > > > contributors
> > > > > > > were
> > > > > > > > > not
> > > > > > > > > > > > > > familiar
> > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Contributions made to
> Category B
> > > > > repos go
> > > > > > > > > through
> > > > > > > > > > > a
> > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > > > > > >> > > > workflow that builds the
> > relevant
> > > > > part of
> > > > > > > the
> > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > > >> > > > the changes introduced.
> Changes
> > > made
> > > > > to
> > > > > > > the
> > > > > > > > > > > pipeline
> > > > > > > > > > > > > > > itself
> > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > > > > > >> > > > picked up as part of PRs,
> > > allowing us
> > > > > to
> > > > > > > do
> > > > > > > > > things
> > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > > > > > >> > > > bumping the Node.js version,
> for
> > > > > example.
> > > > > > > More
> > > > > > > > > > > > > > > importantly,
> > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > > > > > >> > > > us to upgrade the repository
> to
> > a
> > > new
> > > > > > > > > timestamped
> > > > > > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > > > >> > > > with the changes necessary to
> > > make it
> > > > > stay
> > > > > > > > > green.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > This setup, however, makes it
> > > > > impossible
> > > > > > > to
> > > > > > > > > have
> > > > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > > > >> > > > involving Category A and
> > Category
> > > B
> > > > > > > > > > > simultaneously,
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Category C repos are kind of
> > > floating
> > > > > > > around,
> > > > > > > > > and
> > > > > > > > > > > > I'm
> > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > > > >> > > > there's much activity going on
> > > there.
> > > > > > > > > Regardless,
> > > > > > > > > > > as
> > > > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > >> > > > Apache KIE, they will be part
> of
> > > our
> > > > > > > release,
> > > > > > > > > so I
> > > > > > > > > > > > > > listed
> > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > > > >> > > > to take them into
> consideration
> > > too.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Category D is self
> explanatory.
> > > > > There's
> > > > > > > only
> > > > > > > > > one
> > > > > > > > > > > > repo
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > has
> > > > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > > > >> > > > been marked for being
> archived.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Category E are repos that do
> not
> > > host
> > > > > code
> > > > > > > > > > > directly,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > > > > > >> > > > organizational entities, or
> host
> > > > > websites,
> > > > > > > > > that
> > > > > > > > > > > > > > currently
> > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > This lack of unification
> between
> > > > > Category
> > > > > > > A
> > > > > > > > > and
> > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > is,
> > > > > > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > > > > > >> > > > what allowed us to introduce
> the
> > > > > infamous
> > > > > > > > > circular
> > > > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`,
> > > which
> > > > > we
> > > > > > > now
> > > > > > > > > can
> > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > > > > > >> > > > dependency between Category A
> > and
> > > > > > > Category B.
> > > > > > > > > The
> > > > > > > > > > > > way
> > > > > > > > > > > > > I
> > > > > > > > > > > > > > > see
> > > > > > > > > > > > > > > > > it,
> > > > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > >> > > > had a single pipeline,
> building
> > > > > everything
> > > > > > > > > from
> > > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws
> would've
> > > never
> > > > > > > been
> > > > > > > > > > > > > introduced,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > >> > > > wouldn't be having this huge
> > > problem
> > > > > in
> > > > > > > our
> > > > > > > > > hands
> > > > > > > > > > > > > right
> > > > > > > > > > > > > > > now.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE
> > > release
> > > > > > > process
> > > > > > > > > > > sees
> > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > lack
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > >> > > > unification as a central
> > problem,
> > > not
> > > > > > > only for
> > > > > > > > > > > this
> > > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > >> > > > particular, but for the
> > community
> > > as a
> > > > > > > whole.
> > > > > > > > > It
> > > > > > > > > > > is
> > > > > > > > > > > > my
> > > > > > > > > > > > > > > > belief
> > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > >> > > > are all under the same roof,
> and
> > > that
> > > > > no
> > > > > > > > > > > > contribution
> > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > >> > > > allowed to break any part of
> our
> > > > > codebase.
> > > > > > > > > With
> > > > > > > > > > > the
> > > > > > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > > > > > >> > > > of code, and hopefully number
> of
> > > > > > > contributors
> > > > > > > > > too,
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > > > > > >> > > > counting on "common sense" to
> > > avoid
> > > > > > > breaking
> > > > > > > > > > > things.
> > > > > > > > > > > > > > We're
> > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > > > > > >> > > > after all, and it is our job
> to
> > > have
> > > > > > > > > mechanisms in
> > > > > > > > > > > > > place
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > > > >> > > > from unwillingly making
> > mistakes.
> > > > > > > Especially
> > > > > > > > > when
> > > > > > > > > > > > > these
> > > > > > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > > > > > >> > > > impact on parts of the
> codebase
> > > that
> > > > > we,
> > > > > > > > > > > > individually,
> > > > > > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT
> NOW
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @
> > > `kogito-apps`
> > > > > > > depending
> > > > > > > > > on
> > > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF
> > images
> > > @
> > > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools`
> > > > > depending on
> > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at
> version
> > > > > > > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > P4. Multiple packages @
> > > `kogito-apps`
> > > > > > > > > depending on
> > > > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > > > > > > >> > > > * This module was removed from
> > > the KIE
> > > > > > > > > codebase
> > > > > > > > > > > > here:
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > >
> > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > > > > > > ,
> > > > > > > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > > > > > > >> > > > * This new repo depends on
> > Kogito
> > > and
> > > > > > > > > OptaPlanner,
> > > > > > > > > > > > > > > pointing
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > older
> > > > > > > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > P5.
> > > > > > > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> > > > > `2.15.3.Final`.
> > > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > P6. Category C repos are out
> of
> > > date
> > > > > and
> > > > > > > not
> > > > > > > > > part
> > > > > > > > > > > of
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > > > > > > >> > > > *
> > incubator-kie-kogito-benchmarks:
> > > > > > > (Current
> > > > > > > > > > > version
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > > > >> > > > depending on Kogito without a
> > > specific
> > > > > > > > > version,
> > > > > > > > > > > only
> > > > > > > > > > > > > by
> > > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks:
> > > (Current
> > > > > > > version
> > > > > > > > > is
> > > > > > > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > > > >> > > > pointing to Drools
> 999-SNAPSHOT
> > > and
> > > > > > > > > OptaPlanner
> > > > > > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > P7.
> > > > > > > `kie-tools`/packages/kn-plugin-workflow
> > > > > > > > > has
> > > > > > > > > > > its
> > > > > > > > > > > > > E2E
> > > > > > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > > > > > > >> > > > upgrading to
> > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2
> > have
> > > the
> > > > > same
> > > > > > > > > > > solution,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > > > > > >> > > > suffer from the circular
> > > dependency
> > > > > > > between
> > > > > > > > > > > > Category A
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > > > > > > >> > > > As Category A and Category B
> are
> > > both
> > > > > > > streams
> > > > > > > > > that
> > > > > > > > > > > > > have
> > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > > >> > > > active, I see this as a
> blocker,
> > > as
> > > > > there
> > > > > > > are
> > > > > > > > > > > > > > > contributions
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > >> > > > cannot be done, given that
> > > Category A
> > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal,
> > > can be
> > > > > > > > > understood
> > > > > > > > > > > as
> > > > > > > > > > > > > > > > technical
> > > > > > > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > > > > > > >> > > > Depending on unmaintained
> > > projects is
> > > > > > > > > something
> > > > > > > > > > > > we'll
> > > > > > > > > > > > > > > always
> > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable,
> as
> > > it's
> > > > > > > just a
> > > > > > > > > > > matter
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > > making
> > > > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > P7 is an isolated problem that
> > > won't
> > > > > > > impact
> > > > > > > > > the
> > > > > > > > > > > > > > structure
> > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > > > > > > >> > > > that we're talking about here,
> > > but it
> > > > > is a
> > > > > > > > > > > > regression
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be
> > ignored
> > > for
> > > > > > > Apache
> > > > > > > > > KIE
> > > > > > > > > > > 10,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the
> only
> > > > > problems
> > > > > > > > > left to
> > > > > > > > > > > > > > discuss
> > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > >> > > > P2, which can't be done
> without
> > a
> > > > > proper
> > > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > I'll try to be very meticulous
> > > here,
> > > > > since
> > > > > > > > > from my
> > > > > > > > > > > > > > > > experience,
> > > > > > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > > > > > >> > > > little miscalculation can lead
> > to
> > > our
> > > > > > > release
> > > > > > > > > not
> > > > > > > > > > > > > > working
> > > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > >> > > > end. To try and avoid that as
> > > much as
> > > > > > > > > possible,
> > > > > > > > > > > and
> > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > >> > > > can to have a successful
> Apache
> > > KIE 10
> > > > > > > > > release,
> > > > > > > > > > > bear
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > me.
> > > > > > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > > > > > > >> > > > out a timeline of events that
> > > need to
> > > > > > > happen
> > > > > > > > > in
> > > > > > > > > > > > order
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > > > > > > >> > > > to be published, with all
> > > artifacts
> > > > > > > ending up
> > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > > > > right
> > > > > > > > > > > > > > > > > > places,
> > > > > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > > > > >> > > > first, we need to solve
> problems
> > > P1
> > > > > and
> > > > > > > P2.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > As you saw at the beginning of
> > > this
> > > > > email,
> > > > > > > > > all the
> > > > > > > > > > > > > > > attempts
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > made
> > > > > > > > > > > > > > > > > > > >> > > > left us with the circular
> > > dependency
> > > > > > > showing
> > > > > > > > > up
> > > > > > > > > > > at a
> > > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > > > > > > >> > > > but something all these places
> > > have in
> > > > > > > common
> > > > > > > > > is
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > >> > > > after kogito-apps, and before
> to
> > > > > Category
> > > > > > > B.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > The first part of my proposal
> is
> > > the
> > > > > > > > > following:
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > S1. We keep the original plan
> of
> > > > > moving
> > > > > > > the
> > > > > > > > > > > Quarkus
> > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > UIs
> > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`,
> > > together
> > > > > > > with
> > > > > > > > > > > > Management
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > Task
> > > > > > > > > > > > > > > > > > > >> > > > consoles from `kogito-images`
> to
> > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > > > >> > > > S2. We move the
> > > `kogito-swf-devmode`
> > > > > and
> > > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > > > > >> > > > from `kogito-images` to
> > > `kie-tools`
> > > > > too.
> > > > > > > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > > > > > > `kogito-serverless-operator`
> > > > > > > > > > > > > repo
> > > > > > > > > > > > > > > > > inside
> > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > > > > > > >> > > > package on `kie-tools`,
> keeping
> > > Git
> > > > > > > history.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3
> > together
> > > > > solve
> > > > > > > > > problems
> > > > > > > > > > > P1
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > P2.
> > > > > > > > > > > > > > > > Of
> > > > > > > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > >
> > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > This doesn't come without
> > > > > consequences, of
> > > > > > > > > course,
> > > > > > > > > > > > as
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > images,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > > would be
> > > > > > > moving
> > > > > > > > > from
> > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > >> > > > Category B. This move would
> make
> > > them
> > > > > > > have to
> > > > > > > > > > > > > reference
> > > > > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > > > > >> > > > repos through timestamped
> > > SNAPSHOTs.
> > > > > Since
> > > > > > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> are
> > > > > already
> > > > > > > > > their own
> > > > > > > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > > > > > > >> > > > Category A, though,
> > contributions
> > > > > made in
> > > > > > > a
> > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > > fashion
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > > > > > > >> > > > "sub-stream" will continue
> being
> > > > > > > possible, now
> > > > > > > > > > > via a
> > > > > > > > > > > > > > > single
> > > > > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs
> > > between
> > > > > > > Category
> > > > > > > > > A and
> > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > > >> > > > continue not being possible,
> > and a
> > > > > 1-week
> > > > > > > > > delay
> > > > > > > > > > > > > between
> > > > > > > > > > > > > > > > > merging
> > > > > > > > > > > > > > > > > > > >> > > > something on Category A and
> > using
> > > it
> > > > > on
> > > > > > > > > Category B
> > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > still
> > > > > > > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > It's worth mentioning that
> > > > > `kie-tools`,
> > > > > > > > > however,
> > > > > > > > > > > > does
> > > > > > > > > > > > > > > allow
> > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > > > > > > >> > > > checkouts and partial builds,
> so
> > > > > working
> > > > > > > with
> > > > > > > > > a
> > > > > > > > > > > > subset
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > > > >> > > > is possible and encouraged.
> > Making
> > > > > changes
> > > > > > > > > only to
> > > > > > > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`,
> > for
> > > > > > > example,
> > > > > > > > > will
> > > > > > > > > > > > have
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you
> can
> > > see
> > > > > here:
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > > > >> > > > We're not compromising when
> > > running
> > > > > > > partial
> > > > > > > > > builds
> > > > > > > > > > > > > too.
> > > > > > > > > > > > > > We
> > > > > > > > > > > > > > > > > know
> > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > >> > > > the entire repo will continue
> > > working
> > > > > even
> > > > > > > > > after
> > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > building a
> > > > > > > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > > > > > > >> > > > subset of the changes. Doing
> > > partial
> > > > > or
> > > > > > > full
> > > > > > > > > > > builds
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > > > > > > >> > > > determined by the changes of a
> > PR.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Keep in mind that, even though
> > I'm
> > > > > > > proposing
> > > > > > > > > we
> > > > > > > > > > > > move a
> > > > > > > > > > > > > > > bunch
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > >> > > > additional stuff into
> > > `kie-tools`, I
> > > > > see
> > > > > > > this
> > > > > > > > > as a
> > > > > > > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools`
> > > would
> > > > > host
> > > > > > > some
> > > > > > > > > > > > > additional
> > > > > > > > > > > > > > > > stuff
> > > > > > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can
> > > release and
> > > > > > > > > continue
> > > > > > > > > > > > moving
> > > > > > > > > > > > > > > > > forward.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > As I mentioned on other
> places,
> > > > > > > `kie-tools`
> > > > > > > > > > > became a
> > > > > > > > > > > > > > > > polyglot
> > > > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > > > >> > > > out of necessity, and although
> > I'm
> > > > > really
> > > > > > > > > proud of
> > > > > > > > > > > > > what
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > > > > > > >> > > > there so far, I don't think
> > > > > `kie-tools`
> > > > > > > has a
> > > > > > > > > > > setup
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > > > > > > >> > > > for all the different nuances
> > that
> > > > > > > compose our
> > > > > > > > > > > > > > community.
> > > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo
> > > that
> > > > > does
> > > > > > > not
> > > > > > > > > > > follow
> > > > > > > > > > > > > > > > widespread
> > > > > > > > > > > > > > > > > > > >> > > > conventions will scare some
> > people
> > > > > away,
> > > > > > > and
> > > > > > > > > as
> > > > > > > > > > > much
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > we've
> > > > > > > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > > >> > > > make build instructions clear,
> > we
> > > > > can't
> > > > > > > > > always get
> > > > > > > > > > > > > past
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > > > > > > >> > > > some people have towards the
> > > > > "front-end"
> > > > > > > > > > > ecosystem.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > With all that said, I keep
> > > thinking
> > > > > this
> > > > > > > is
> > > > > > > > > the
> > > > > > > > > > > best
> > > > > > > > > > > > > > > course
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > > > > > > >> > > > for us right now. We keep most
> > of
> > > our
> > > > > > > stuff
> > > > > > > > > > > > unchanged,
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > >> > > > release, and we have a working
> > > setup
> > > > > that
> > > > > > > will
> > > > > > > > > > > suit
> > > > > > > > > > > > us
> > > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > >> > > > discuss and reach a conclusion
> > > > > regarding
> > > > > > > the
> > > > > > > > > > > future
> > > > > > > > > > > > of
> > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Let me paint a quick picture
> > here
> > > of
> > > > > what
> > > > > > > our
> > > > > > > > > code
> > > > > > > > > > > > > base
> > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > > > > > >> > > > like, repository-wise, if my
> > > proposal
> > > > > is
> > > > > > > > > accepted:
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > > > > > > >> > > > A
> incubator-kie-drools
> > > > > > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-optaplanner
> > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-kogito-docs
> > > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-benchmarks
> > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > >> > > > B
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > > >> > > > B
> incubator-kie-tools
> > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > >> > > > D
> > > > > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > >> > > > E
> incubator-kie-issues
> > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > incubator-kie-kogito-website
> > > > > > > > > > > > > > > > > > > >> > > > E
> > incubator-kie-website
> > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > incubator-kie-kogito-online
> > > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > * Category C becomes part of
> > > Category
> > > > > A,
> > > > > > > and
> > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > moves
> > > > > > > entirely
> > > > > > > > > inside
> > > > > > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > > > >> > > > * With
> > > `kogito-swf-{builder,devmode}`
> > > > > > > images
> > > > > > > > > and
> > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > > inside
> > > > > > > > > `kie-tools`,
> > > > > > > > > > > > there
> > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > > > > > > >> > > > anymore, as inside
> `kie-tools`,
> > > we can
> > > > > > > > > granularly
> > > > > > > > > > > > > build:
> > > > > > > > > > > > > > > > > > > >> > > > 1.
> > > > > > > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > > > >> > > > 2.
> > > > > packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > > > >> > > > 3.
> > packages/sonataflow-images
> > > > > > > (containing
> > > > > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > > > > > > >> > > > 4.
> > > packages/sonataflow-operator
> > > > > > > (contents
> > > > > > > > > from
> > > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > > > > > > >> > > > 5.
> > > packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > The second part of the
> proposal
> > > is the
> > > > > > > release
> > > > > > > > > > > > process
> > > > > > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > > > > > >> > > > assuming the structure above
> is
> > > what
> > > > > we
> > > > > > > have.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > 1. Define a timestamped
> SNAPSHOT
> > > to be
> > > > > > > used as
> > > > > > > > > > > > cutting
> > > > > > > > > > > > > > > point
> > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > > > > > > >> > > > 2. Update Category B repos to
> > > point to
> > > > > > > this
> > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > > >> > > > verify that everything is
> > working.
> > > > > > > > > > > > > > > > > > > >> > > > 3. At this point, with
> > everything
> > > > > > > working, we
> > > > > > > > > can
> > > > > > > > > > > > > branch
> > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the
> > > > > timestamped
> > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > tag,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > > > > > > >> > > > 4. All Category A and
> Category B
> > > repos
> > > > > > > update
> > > > > > > > > > > their
> > > > > > > > > > > > > > > versions
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x`
> > > branches.
> > > > > > > > > > > > > > > > > > > >> > > > 5. Update Category B repos to
> > > point to
> > > > > > > > > Category A
> > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > > > > > > >> > > > 6. At this point, we can vote
> on
> > > the
> > > > > > > release
> > > > > > > > > based
> > > > > > > > > > > > on
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > > > > > > >> > > > branches, given we don't
> expect
> > > any
> > > > > code
> > > > > > > > > changes
> > > > > > > > > > > > > > anymore.
> > > > > > > > > > > > > > > > > > > >> > > > 7. After voting passes, we're
> > > good to
> > > > > > > start
> > > > > > > > > the
> > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > > > > > >> > > > 8. Category A repos follow
> their
> > > > > > > > > manual/automated
> > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x`
> branch.
> > > Tags
> > > > > > > pushed
> > > > > > > > > to
> > > > > > > > > > > Git,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to their
> > > registries.
> > > > > > > > > > > > > > > > > > > >> > > > 9. We wait a little bit for
> > > Category A
> > > > > > > > > artifacts
> > > > > > > > > > > to
> > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > > > > > > >> > > > 10. Category B repos follow
> > their
> > > > > > > > > manual/automated
> > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x`
> branch.
> > > Tags
> > > > > > > pushed
> > > > > > > > > to
> > > > > > > > > > > Git,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to their
> > > registries.
> > > > > > > > > > > > > > > > > > > >> > > > 11. Category D repos are
> > ignored.
> > > > > > > > > > > > > > > > > > > >> > > > 12. Category E repos can be
> > > manually
> > > > > > > tagged
> > > > > > > > > with
> > > > > > > > > > > > > 10.0.0
> > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > More needs to be discussed if
> > > we're
> > > > > > > planning
> > > > > > > > > to
> > > > > > > > > > > > > maintain
> > > > > > > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > > > > > > >> > > > release streams in parallel,
> > but I
> > > > > guess
> > > > > > > it
> > > > > > > > > can
> > > > > > > > > > > wait
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm
> > > looking
> > > > > > > > > forward to
> > > > > > > > > > > > > > hearing
> > > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Of course, alternative
> solutions
> > > are
> > > > > > > possible.
> > > > > > > > > > > This
> > > > > > > > > > > > > > email,
> > > > > > > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > > > > > > >> > > > summarizes my view of how we
> > > should
> > > > > > > attack the
> > > > > > > > > > > > > problem,
> > > > > > > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > > > > > > >> > > > disruption, required effort,
> the
> > > > > release
> > > > > > > > > process
> > > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > > > > > > >> > > > Feel free to propose
> > alternatives.
> > > > > This is
> > > > > > > > > not a
> > > > > > > > > > > > > voting
> > > > > > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > > > > > > >> > > > For additional commands,
> e-mail:
> > > > > > > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Hi Tiago, Thanks for the detailed explanation
Actually, for tooling, where there is not strong dependency (as between
engine code in runtime and kie server api in drools), the fixed snapshot
mechanism will work pretty well, in my opinion.
On one side, an example that depends on devui will not fail to compile
because the snapshot is old. The contrary is also true, if we add a new
functionality in the server side that is going to be used by any tool, the
worst that might happen is that the functionality is not there in the old
snapshot, but it wont block tooling compilation (obviously if you need that
functionality to test a new UI feature, you will need the update snapshot,
but that's expected and I guess is also happening now, you need to wait for
the server artifact to be published on Maven)
Because of that loose dependency, tooling can be run, as it is, as an
almost completely separate project but also because of that, I feel it
might be easily integrated (except for CI changes, which are always
delicate) with the rest of the repos to achieve a single release number,
because, if all repos use the same snapshot, as far as there is one
snapshot, in the day by day experience everything will normally compile.
I think we agree that the natural place of tooling in the dependency chain
is after apps (service) and before images. With that in mind and if we
wholly embrace the consequence of being a single release, in my opinion, it
means that tooling become one more repo (no A no B category), which use a
fixed snapshot as the rest, and it is subject to the need to eventually
wait for the updated snapshot (or in case you cannot wait, a local full
build), in the unlikely case there is a change that blocks its local
compilation. The implication of this is that the development cycle that is
implicit in your proposal to use a "fixed snapshot" in category A repos no
longer apply.
This means no time to adjust, which can sound like an herexy, but, if there
is no need for a gap between drools and runtimes, why is there a need for a
gap between tooling and apps (services)? (I think we agree a Java API
dependency is stronger than a REST API) Do we have a real precedent that
justify that? I kind of feel that here we are converting an old habit into
an axiomatic need (probably because Im lacking context)
Now my proposal for CI, we do not really need a single stream right now. We
can keep the current kogito stream as it is, except for images, and
integrate tooling into the stream that is now used for the operator (the
assumption here is that a change in drools-runtimes hardly breaks the tools
and in any case that is already happening, so we do not lose anything)
On Wed, Mar 13, 2024 at 8:18 PM ricardo zanini fernandes <
ricardozanini@gmail.com> wrote:
> Hey Tiago, thanks for the insights, I appreciate it.
>
> Just one thing regarding building from kie-tools one module that images
> need to sync changes. That might happen, of course. If I see a problem in
> devui, I just report it in the tools repo, we work on the bug, and in the
> next image build we get the changes. By the nature of the operator/images,
> such changes won't impact our builds. What impact our builds are
> self-contained on those repos or work made in the engines, where we rely on
> Snapshots.
>
> I understand your concern and it's a valid point, but in practice, it's not
> what happens. We can live with the latest released version from npm
> packages during the dev phase without any problems. From the
> images/operator perspective, they are yet another package I need to install
> on my container. Like `cat` or `jq`.
>
> But we need to sit down and try to understand our boundaries and how to do
> integration tests based on them. For example, deploying a devmode workflow
> in Kubernetes and starting a workflow instance via the devui console.
>
> On Wed, Mar 13, 2024 at 3:54 PM Tiago Bento <tiagobentofernandes@gmail.com
> >
> wrote:
>
> > Francisco,
> >
> > I agree with you that both reasonings are not antagonistic, as an
> > antagonistic reasoning in this case would be one that doesn't work.
> > And I believe it is clear now that the initial proposal shared on this
> > email thread does work, but it is not the only possibility. From the
> > beginning I said there are alternatives, but I wanted to start the
> > conversation from my point of view, sharing what I think is best. We
> > have to acknowledge, though, IMHO, that the discussions we had thus
> > far cannot be understood as clearly as what was initially laid out,
> > given the lack of details/analysis and a clear execution plan.
> >
> > Let me elaborate on top of the 3-step plan you shared.
> >
> > 1)
> > No comment. This should be pretty simple to do.
> >
> > 2)
> > There is no global CI stream to be changed, we would have to create
> > one. And this has serious implications to our contribution model for
> > cross-repo PRs. As I described on the first email of this thread,
> > Category A repos are configured in several disjoint streams. Sending a
> > PR to `drools` and `kogito-runtimes` will work great, but sending a PR
> > to `drools` and `kogito-images`, or `drools` and `optaplanner` won't
> > verify that everything will continue working after the PRs are merged,
> > as our PR checks are not prepared to build this combination of repos
> > together. This is a problem, in my view, but I hardly contribute to
> > Category A repos, so I'm assuming things are working fine for those
> > who do. The proposal shared on the first email of this thread does not
> > change the contribution workflow for any repo of Apache KIE, and
> > everyone can continue contributing the way they're used to, except for
> > people contributing to the `kogito-swf-{builder,devmode}` images, and
> > to `kogito-serverless-operator`. On the other hand, having `kie-tools`
> > built in the middle of a new global CI stream, would span another
> > class of problem, which is very closely related to the third bullet
> > point of the plan you shared.
> >
> > 3)
> > Maven has a mechanism to achieve this pseudo-synchronicity between
> > multiple repositories. The mutable SNAPSHOT version, built nightly. It
> > is not perfect, though, as I'm sure many of us already experienced
> > pulling from the `main` branch of a single repo only to find out that
> > a PR ensemble had been merged a few moments prior, requiring us to
> > rebuild the entire stack, since our local SNAPSHOTs had become
> > out-of-date. That's what we used to have back in Business Central
> > (a.k.a. v7) days. Making a `git pull` on a single repo in this setup
> > potentially requires all repos to be pulled and rebuilt. I'm sure this
> > still happens sometimes when developing Category A projects.
> >
> > NPM packages don't have mutable SNAPSHOTs. Every published NPM package
> > is immutable, and it is really cumbersome and error-prone to integrate
> > downstream repos with upstream NPM-bound repos, as not having a
> > lockfile brings all sorts of security and stability problems. That's
> > why monorepos became so popular in the JavaScript ecosystem. This lack
> > of a mutable SNAPSHOT mechanism makes depending on NPM artifacts
> > coming from `kie-tools` really hard. The way I see it, moving repos
> > downstream of `kie-tools` will require everyone to build `kie-tools`
> > anyway, potentially on a daily basis, since it would've then become
> > part of the stack that needs to be built before `kogito-images` and
> > `kogito-serverless-operator`. More than that, since there would be no
> > way to determine what subset of packages of `kie-tools` would need to
> > be built to satisfy downstream references, everyone would have to do a
> > full build, or handpick individual packages of the monorepo to build.
> >
> > I hope I was able to offer more insight in the way I see things, along
> > with my take on using Maven SNAPSHOTs as the de-facto solution for a
> > poly-repo codebase. I don't think we can escape from the complexity of
> > our codebase and the nature of the technologies we use, only
> > accommodate it in the most comfortable place possible, if even there
> > is such a place :)
> >
> > Now, there are some things I'd like to say regarding the initial
> > proposal shared on this email thread.
> >
> > I understand you, and others, are concerned about moving stuff into
> > `kie-tools` for some reasons I could gather from your messages. I'll
> > try and list them here, along with my perspective on each of them.
> >
> > 1. Never being able to move them out of `kie-tools` again.
> > This is going to be as hard as it would be removing
> > `kn-plugin-workflow` from it now. So, as you and others mentioned this
> > possibility, I assume you understand it to be doable.
> >
> > 2. "Heterodoxizing" an orthodox repository
> > (`kogito-serverless-operator`), potentially harming external
> > contributions.
> > Agree with this point. `kie-tools` is one of a kind, built around
> > front-end tooling with some completely unique in-house apparatus. In
> > my experience, though, there are a multitude of factors that make
> > people want to contribute to an open source project. Conformance to
> > well-known widespread technologies and tools is just one of them.
> > Being open about it and writing material to smooth out those edges can
> > work pretty well. People do not contribute because a codebase is
> > "pure". People contribute because they care about the project. And I'm
> > always surprised by the lengths people go to when they want to get
> > involved.
> >
> > 3. Disruption to the contribution workflow of those contributing to
> > `kogito-swf-{builder,devmode}` images, and to
> > `kogito-serverless-operator`.
> > It is clear to me now that we can't unblock and release Apache KIE 10
> > without impacting anyone, but I hope the first part of this reply
> > sheds some light on this complicated matter.
> >
> > Anyway, that's my attempt to offer a different perspective to some of
> > the problems you expressed concern about, perhaps even making the
> > initial proposal shared on this email thread be seen with less
> > uncertainty.
> >
> > On Wed, Mar 13, 2024 at 11:40 AM Francisco Javier Tirado Sarti
> > <ft...@redhat.com> wrote:
> > >
> > > Tiago,
> > > Unfortunately, my plan is too conceptually simple to write more than I
> > > already wrote.
> > > 1) Move kn-plugin-workflow module to operator repo (this remove the
> > > dependency between tools and operator, breaking the loop)
> > > 2) Change CI global stream to execute tooling repo before operator repo
> > > (this seems to take 2 months unless Tristan helps and reduce the time
> to
> > 2
> > > weeks)
> > > 3) Optionally, and just as a consequence of that CI change, set
> > > 999-SNAPSHOT version to all poms in all repos (if current snapshot
> > numbers
> > > turns out to be a problem, in any case this is just search-replace)
> > >
> > > The current plan is:
> > > 1) Move everything depending on tools to tools repo, which includes
> > > operator code and examples.
> > > 2) Change CI of tooling repo to enforce dependencies between the
> existing
> > > modules there and the newly moved ones (this seems to take 3 weeks or
> > less)
> > >
> > > I think rather than asking for a more detailed alternative, what needs
> to
> > > be done is to refine the existing proposal with the feedback received.
> I
> > do
> > > not think both proposals are antagonistic. I think that, being now
> clear
> > we
> > > have the same overall goal (execute tooling before operator), it is
> just
> > a
> > > question of deciding between move more stuff to an already heterodox
> > repo,
> > > coming from repos not as heterodox, plus changing the repo CI to impose
> > > certain order between these modules or pull out the the operator stuff
> > from
> > > tool repo and put it inside the operator repo plus changing the CI
> > > handling repos to impose the desired order: first tooling and then
> > operator.
> > >
> > > On Wed, Mar 13, 2024 at 4:12 PM Tiago Bento <
> > tiagobentofernandes@gmail.com>
> > > wrote:
> > >
> > > > Francisco,
> > > >
> > > > 1) `kie-tools` is already a heterodox repo. The reason why I proposed
> > > > my proposal is because it is what I think is the best course of
> action
> > > > for our community right now. If you think there's a better way to do
> > > > it, I think everyone, including me, needs to see a proposal with a
> > > > clear execution plan with a comparable level of detail and analysis
> in
> > > > regards to disruption of the current state, the required effort, the
> > > > contribution workflow for cross-repo PRs, and the release process
> > > > itself. Otherwise, we risk having gaps that each person will fill in
> a
> > > > different way, and IMHO, that's where problems happen. +1 for
> examples
> > > > unification, btw :)
> > > >
> > > > 2) Ok, and +1 for no categorization.
> > > >
> > > > On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado Sarti
> > > > <ft...@redhat.com> wrote:
> > > > >
> > > > > 1) Ok, if that is the case, I do not get why your first proposal
> was
> > not
> > > > > the one I'm proposing and it is apparently not detailed enough. To
> > move
> > > > > kn-workflow from tooling to operator one and change the order in
> > which
> > > > the
> > > > > repos are being processed. Basically, the problem of the proposed
> > > > solution
> > > > > is that it kind of converts tooling repo into a pretty heterodox
> repo
> > > > > compared with runtimes, drools or operator one. Also once tooling
> is
> > not
> > > > a
> > > > > final repo in the overall chain, we can consider moving examples as
> > the
> > > > > final one and include tooling showcases there (rather than
> splitting
> > > > > examples into examples with tooling and examples without tooling).
> > > > > 2) I think this distinction between A and B is one between several
> > > > possible
> > > > > categorizations (not much, including no categorization at all) that
> > > > > deserves a separate discussion. I will open a separate thread for
> > that
> > > > > purpose, since we are not going to change that now and it is not
> > really
> > > > > part of the proposal.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
> > > > tiagobentofernandes@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Francisco,
> > > > > >
> > > > > > 1) That's what this thread is all about... You know I don't think
> > it's
> > > > > > ok. That's why I'm proposing the two images and the operator to
> > move
> > > > > > into the `kie-tools` repo, where we can more granularly control
> the
> > > > > > order things are built, thus removing the dependency cycle.
> > > > > >
> > > > > > 2) Not sure we understand the same thing by "freeze". My proposal
> > is
> > > > > > that we select a timestamped SNAPSHOT version from Category A
> > repos to
> > > > > > use as base for a release. We give Category B repos some time to
> > > > > > adjust, and then cut the release branches. This can happen
> anytime,
> > > > > > and no contributions would ever stop because of it. The
> development
> > > > > > branches can continue accepting PRs normally, even during the
> > release
> > > > > > process. Now, if what you're asking is why Category B repos refer
> > to
> > > > > > Category A repos via timestamped SNAPSHOTs, the answer is in my
> > first
> > > > > > email. See the paragraph starting with "An important note here is
> > that
> > > > > > Category B repositories...".
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti
> > > > > > <ft...@redhat.com> wrote:
> > > > > > >
> > > > > > > Tiago
> > > > > > > There are a couple of simple and straightforward questions
> that
> > I
> > > > > > > formulated, but since we both write a lot, it might have been
> > lost.
> > > > > > Please
> > > > > > > let me ask them again.
> > > > > > > 1) Do you think it is ok that tools repo is executed after
> > > > generation of
> > > > > > > docker images that are supposed to include those tools or the
> > > > operator
> > > > > > that
> > > > > > > is supposed to deploy such images?
> > > > > > That's what this thread is all about... You know I'm not ok with
> > it,
> > > > > > that's why I'm proposing the two images and the operator to move
> > into
> > > > > > the `kie-tools` repo, where we can more granularly control the
> > order
> > > > > > things are built and remove the dependency cycle.
> > > > > > > 2) Besides that, although not directly related with the current
> > > > proposal
> > > > > > we
> > > > > > > are discussing, I really think there are some restrictions
> taken
> > for
> > > > > > > granted that are arbitrary and difficult to sustain on strictly
> > > > technical
> > > > > > > arguments. For example, the need to freeze the rest of the
> > software
> > > > > > before
> > > > > > > tools are generated. Why? We have dependencies between repos
> that
> > > > are not
> > > > > > > handled that way: Apps depend on runtimes. Runtimes depend on
> > drools,
> > > > > > > Operator depend on runtimes,....and we are not freezing that
> > repos
> > > > since
> > > > > > we
> > > > > > > are all releasing at the same time. If we are all releasing at
> > the
> > > > same
> > > > > > > time, what's the rationale behind the freeze?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <
> > tiagobento@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Glad to see the interest this proposal has gotten, and it's
> > good to
> > > > > > > > see some alternatives being drafted here, although still
> > lacking
> > > > clear
> > > > > > > > definitions and analysis in regards to disruption, required
> > effort,
> > > > > > > > the release process itself, and history. Of course, lots of
> > details
> > > > > > > > and clarity on the execution part would be missing too.
> > > > > > > >
> > > > > > > > As of this moment, based on what I read here, I'm assuming
> that
> > > > > > > > everyone who participated so far doesn't see the initial
> > proposal
> > > > as
> > > > > > > > problematic in terms of feasibility, but some of you have a
> > > > preference
> > > > > > > > not to go with it, because it is "wrong", and apparently
> > because it
> > > > > > > > would "jeopardize the evolution of the project". Reading
> these
> > last
> > > > > > > > words made me a little sad, to be honest. But I can deal with
> > it :)
> > > > > > > >
> > > > > > > > Please let's try and keep the discussion as objective as
> > possible.
> > > > > > > > "Right" and "wrong" are too subjective for this kind of
> > > > conversation.
> > > > > > > >
> > > > > > > > Now, being practical, unless there are clear arguments based
> on
> > > > facts
> > > > > > > > and objective concepts that invalidate the initial proposal
> > shared
> > > > on
> > > > > > > > this email, it seems to me that it is currently the only
> viable
> > > > > > > > proposal we have for unblocking and releasing Apache KIE 10.
> Of
> > > > > > > > course, if we end up seeing an alternative proposal with
> enough
> > > > > > > > details and a clear execution plan, I think then we'll be in
> a
> > very
> > > > > > > > good position to choose from multiple options!
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <
> > alex@porcelli.me>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Francisco and Gabriele,
> > > > > > > > >
> > > > > > > > > I understand and acknowledge your desire to find the
> “right”
> > > > solution
> > > > > > > > > instead to work on a temporary “patch” - however without a
> > > > detailed
> > > > > > > > > proposal I don’t think we can properly evaluate the impact
> of
> > > > your
> > > > > > > > > suggestion.
> > > > > > > > >
> > > > > > > > > When I spoke with different SMEs that included tools and
> CI,
> > the
> > > > > > > > > guesstimate for making the necessary changes on CI and
> > codebase
> > > > to
> > > > > > > > > basically have images and operators in the end of the build
> > > > chain is
> > > > > > > > > something like 2 months of effort. Another impact that
> needs
> > to
> > > > be
> > > > > > > > > discussed is that KIE Tools repo had to be injected in the
> > > > middle of
> > > > > > all
> > > > > > > > > pipelines - forcing all PR checks and nightlies to build
> all
> > > > repos
> > > > > > (PR
> > > > > > > > > checks will likely take 12+ hours… I even heard that it
> > could be
> > > > > > even 24
> > > > > > > > > hours).
> > > > > > > > >
> > > > > > > > > Based on the input above, I think it’s quite risk to move
> in
> > such
> > > > > > > > direction
> > > > > > > > > without a more detailed plan… because 2 months could be
> > turned
> > > > > > easily in
> > > > > > > > 6!
> > > > > > > > > And this is exactly what happened when we guessed that
> > moving to
> > > > > > Apache
> > > > > > > > > would take no more than 3 months. But here we are.
> > > > > > > > >
> > > > > > > > > I really strongly suggest that we focus on a release that
> > could
> > > > be
> > > > > > > > > achievable in less than a month from now, and we - after
> > release
> > > > -
> > > > > > have a
> > > > > > > > > in depth discussion about the overall codebase and ci
> > > > organization.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Alex,
> > > > > > > > > > my suggestion is to move the building of all docker
> images,
> > > > from
> > > > > > > > whatever
> > > > > > > > > > repo (kogito-apps, kie-tools) in a different, downstream
> > repo,
> > > > to
> > > > > > be
> > > > > > > > > > invoked after all the others.
> > > > > > > > > > I'm not sure if this would solve all the issues, and
> since
> > I
> > > > could
> > > > > > not
> > > > > > > > > > enter in the details of all the involved code, my
> > suggestion
> > > > may
> > > > > > be too
> > > > > > > > > > naive.
> > > > > > > > > > Having spent almost all of the last year in CI, I may
> say
> > > > that, at
> > > > > > > > least
> > > > > > > > > > for the kie-tools repo, removing the image build step
> from
> > it
> > > > > > should
> > > > > > > > not be
> > > > > > > > > > too difficult (since it is an issue we already faced and
> > > > solved).
> > > > > > > > > > If, with "detailed proposal", you mean a complete list of
> > all
> > > > > > modules
> > > > > > > > to be
> > > > > > > > > > moved and dependency refactoring, of course I can not
> > provide
> > > > it
> > > > > > right
> > > > > > > > now.
> > > > > > > > > >
> > > > > > > > > > Anyway, I share the concern from Francisco: undoing
> > something
> > > > is
> > > > > > almost
> > > > > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier
> > > > Tirado
> > > > > > Sarti
> > > > > > > > <
> > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > >
> > > > > > > > > > > I do not think estimations should be the only driver to
> > make
> > > > a
> > > > > > > > decision,
> > > > > > > > > > > especially when the current proposal is conceptually
> > > > incompatible
> > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > > multi repo approach that is taken elsewhere in the
> > project.
> > > > > > > > > > > Given my knowledge of the CI it is nearly impossible
> for
> > me
> > > > to
> > > > > > give
> > > > > > > > a
> > > > > > > > > > fair
> > > > > > > > > > > estimate of how much it might take to achieve step 2)
> of
> > my
> > > > > > previous
> > > > > > > > > > e-mail
> > > > > > > > > > > . It might take a while or it might be pretty easy
> after
> > > > all, I
> > > > > > don't
> > > > > > > > > > > really know, but I think it will be a good idea if
> some
> > of
> > > > the
> > > > > > > > experts
> > > > > > > > > > on
> > > > > > > > > > > CI in the team (the ones that set up the pipeline,
> which
> > was
> > > > a
> > > > > > huge
> > > > > > > > > > > achievement) give an estimate, not me. Estimating how
> > much
> > > > it
> > > > > > takes
> > > > > > > > to
> > > > > > > > > > > merge two existing repos (without altering CI) is
> easier,
> > > > but it
> > > > > > > > does not
> > > > > > > > > > > mean we are doing the right thing.
> > > > > > > > > > > My main concern is that it will be very difficult for
> me
> > to
> > > > > > explain
> > > > > > > > to
> > > > > > > > > > > someone that arrives new to the team, that having
> > experts on
> > > > CI
> > > > > > on
> > > > > > > > the
> > > > > > > > > > > team, we decided to merge two repos (once merged, it
> > would be
> > > > > > rather
> > > > > > > > > > > difficult to unmerge) rather than fix the CI, because
> of
> > > > > > expediency.
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > > > > porcelli@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Francisco,
> > > > > > > > > > > >
> > > > > > > > > > > > Please take the time to make the more in depth
> analysis
> > > > needed
> > > > > > and
> > > > > > > > > > > provide
> > > > > > > > > > > > a more detailed plan… so we - as community- can
> > evaluate
> > > > the
> > > > > > size
> > > > > > > > of
> > > > > > > > > > the
> > > > > > > > > > > > effort. In the conceptual level you shared it’s near
> > > > > > impossible to
> > > > > > > > > > > estimate
> > > > > > > > > > > > the size of the effort and compare with the current
> > > > proposal.
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier
> Tirado
> > > > Sarti <
> > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > > > > 1) Remove all dependencies from tooling to images,
> > so
> > > > images
> > > > > > > > depend
> > > > > > > > > > on
> > > > > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > > > > 2) Then change CI to deal with tooling repo before
> > > > dealing
> > > > > > with
> > > > > > > > > > images
> > > > > > > > > > > > > repo.
> > > > > > > > > > > > > I understand that CI details are tricky and since
> > I'm not
> > > > > > > > familiar
> > > > > > > > > > with
> > > > > > > > > > > > CI
> > > > > > > > > > > > > in any way, I barely can make a low level design,
> > but we
> > > > do
> > > > > > not
> > > > > > > > need
> > > > > > > > > > to
> > > > > > > > > > > > fix
> > > > > > > > > > > > > everything, just achieve 2), a change of
> compilation
> > > > order.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > > > > > alex@porcelli.me
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > You may not like or understand why the current
> > state of
> > > > > > the CI
> > > > > > > > is
> > > > > > > > > > > like
> > > > > > > > > > > > > > that… actually has been in Red Hat and has been
> > > > replicated
> > > > > > in
> > > > > > > > > > Apache
> > > > > > > > > > > as
> > > > > > > > > > > > > > used to be….
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you disagree with the current plan, please
> > provide a
> > > > > > > > detailed
> > > > > > > > > > > > > > alternative so we, as community, can better
> > evaluate
> > > > the
> > > > > > pros
> > > > > > > > and
> > > > > > > > > > > cons
> > > > > > > > > > > > of
> > > > > > > > > > > > > > each proposal.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think it’s also fair to say that, post 10
> > release we
> > > > > > need to
> > > > > > > > > > have a
> > > > > > > > > > > > > much
> > > > > > > > > > > > > > in depth discussion about how our codebase is
> > > > organized,
> > > > > > it’s
> > > > > > > > clear
> > > > > > > > > > > > that
> > > > > > > > > > > > > > it’s not working.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi
> <
> > > > > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > > > > I also have the impression that the "images"
> (if
> > we
> > > > are
> > > > > > > > talking
> > > > > > > > > > of
> > > > > > > > > > > > > docker
> > > > > > > > > > > > > > > images) should be the very last one to be
> built,
> > in a
> > > > > > > > standalone
> > > > > > > > > > > > repo.
> > > > > > > > > > > > > > > That way, they may "combine" artifacts that are
> > > > built in
> > > > > > > > > > different
> > > > > > > > > > > > > repos,
> > > > > > > > > > > > > > > regardless of the order in which those are
> built.
> > > > > > > > > > > > > > > Moving them out of all the repos
> > > > (kogito-apps/kie-tools)
> > > > > > > > maybe
> > > > > > > > > > > could
> > > > > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > > > > (I also think there are some statements of
> > > > undisputable
> > > > > > needs
> > > > > > > > > > while
> > > > > > > > > > > > > they
> > > > > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > > > > Anyway, this latter point is for longer,
> > following,
> > > > > > > > discussion.)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23
> > Francisco
> > > > Javier
> > > > > > > > Tirado
> > > > > > > > > > > > Sarti
> > > > > > > > > > > > > <
> > > > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > > > > There are two assumptions that deserve
> further
> > > > > > discussion:
> > > > > > > > > > > > > > > > 1) That tool has to be the last to build.
> why?
> > it
> > > > does
> > > > > > not
> > > > > > > > have
> > > > > > > > > > > > more
> > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > to build final images after everything else
> has
> > > > been
> > > > > > > > built?-
> > > > > > > > > > > > > > > > 2) That the impact (in terms of effort now)
> on
> > > > fixing
> > > > > > CI is
> > > > > > > > > > > bigger
> > > > > > > > > > > > > than
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > impact (long term consequences) of
> > consolidating
> > > > two
> > > > > > > > unrelated
> > > > > > > > > > > > piece
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex
> Porcelli
> > <
> > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This was discussed as an alternative
> > solution,
> > > > > > however
> > > > > > > > it has
> > > > > > > > > > > > major
> > > > > > > > > > > > > > > > impact
> > > > > > > > > > > > > > > > > on CI and there’s also the fact Tool has
> been
> > > > always
> > > > > > the
> > > > > > > > last
> > > > > > > > > > > to
> > > > > > > > > > > > > > build
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > has no Snapshot published (actually in
> > JavaScript
> > > > > > world
> > > > > > > > there
> > > > > > > > > > > is
> > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So, based on our evaluation… the proposal
> > here
> > > > is the
> > > > > > > > least
> > > > > > > > > > > > > > disruptive
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco
> > Javier
> > > > > > Tirado
> > > > > > > > > > Sarti <
> > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > After kie-tools, sorry. I think we are
> not
> > > > > > embracing
> > > > > > > > the
> > > > > > > > > > fact
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > kogito-images depend on kie-tools,
> because
> > we
> > > > want
> > > > > > > > those
> > > > > > > > > > > images
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM
> Francisco
> > > > Javier
> > > > > > > > Tirado
> > > > > > > > > > > Sarti
> > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > > > > It can be an alternative solution to
> move
> > > > > > > > > > > kn-plugin-workflow
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > kogito-images (so there is not longer
> > > > dependency
> > > > > > from
> > > > > > > > > > tools
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > then build kogito-images after
> > kogito-tools?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM
> Enrique
> > > > Gonzalez
> > > > > > > > > > Martinez
> > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere
> > Fernandez
> > > > > > (apache)
> > > > > > > > <
> > > > > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >> > I say +1 in order to move forward
> with
> > > > the 10.
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex
> > > > Porcelli <
> > > > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> > > I spent the last day or so working
> > > > closely
> > > > > > with
> > > > > > > > > > Tiago,
> > > > > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > > > > >> > > options and getting deeper on the
> > > > impact and
> > > > > > > > > > > evaluating
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > > > > >> > > procedure steps required. I agree
> > with
> > > > the
> > > > > > > > proposal
> > > > > > > > > > as
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > most
> > > > > > > > > > > > > > > > > > >> > > viable option for unblocking the
> 10
> > > > release
> > > > > > in
> > > > > > > > the
> > > > > > > > > > > > > > reasonable
> > > > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM
> > Tiago
> > > > Bento
> > > > > > <
> > > > > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a
> tl;dr
> > this
> > > > > > time,
> > > > > > > > as
> > > > > > > > > > this
> > > > > > > > > > > > > > matter
> > > > > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > This email will take you < 20
> > minutes
> > > > to
> > > > > > read,
> > > > > > > > > > > > according
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > As you may have followed on a
> > separate
> > > > > > thread
> > > > > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > > > > >
> > > > > > > > > > >
> > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > > > > >> > > > many of us were working towards
> > > > removing a
> > > > > > > > > > circular
> > > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > > >> > > > currently present between
> > > > `kogito-apps`
> > > > > > and
> > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > As
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > >> > > > progressed towards a solution,
> we
> > kept
> > > > > > > > finding the
> > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > > > > > breakdown of
> > > > > > > > the
> > > > > > > > > > > > things
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Right now, even though we
> started
> > the
> > > > > > effort
> > > > > > > > to
> > > > > > > > > > move
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we
> > haven't
> > > > been
> > > > > > > > able to
> > > > > > > > > > > do
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > yet,
> > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to
> > Java
> > > > 17,
> > > > > > > > Maven
> > > > > > > > > > > 3.9.6,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito
> > Runtimes
> > > > > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > >> > > > effort was concluded this
> Monday,
> > with
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > >
> > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > > > > .
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > >> > > > |==> 02.
> > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > >> > > > L |
> > > > ==========================
> > > > > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > >> > > > |==> 07.
> > incubator-kie-tools
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > * As
> > > > `kie-tools`/extended-services
> > > > > > > > depends
> > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs
> > to
> > > > > > > > `kie-tools`,
> > > > > > > > > > we
> > > > > > > > > > > > > > would've
> > > > > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > >> > > > C |
> > =====================
> > > > > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > >> > > > E |==> 07.
> > incubator-kie-tools
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > depends
> > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > >> > > >
> > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > > > > depends
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > >> > > >
> > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > After moving the
> > `kogito-swf-devmode`
> > > > > > image to
> > > > > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > >> > > > 04.
> > > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > > >> > > > Y |
> > =====================
> > > > > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > >> > > > L |==> 07.
> > incubator-kie-tools
> > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > * As
> > > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > > depends
> > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > > > > >> > > > * and
> > > > `kogito-serverless-operator`
> > > > > > > > depends
> > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger
> > problem
> > > > > > than a
> > > > > > > > > > simple
> > > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > After multiple conversations
> with
> > a
> > > > lot of
> > > > > > > > people,
> > > > > > > > > > > > it's
> > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > >> > > > hard coming up with a simple
> > solution
> > > > that
> > > > > > > > makes
> > > > > > > > > > it
> > > > > > > > > > > > > > possible
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while
> > > > preserving
> > > > > > the
> > > > > > > > way
> > > > > > > > > > > > > everyone
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > >> > > > contributing to the multiple
> > > > repositories
> > > > > > we
> > > > > > > > have.
> > > > > > > > > > > > More
> > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > > > > >> > > > while making this assessment, I
> > found
> > > > more
> > > > > > > > > > problems
> > > > > > > > > > > > > that,
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > >> > > > perspective, block Apache KIE
> 10.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm
> > > > coming
> > > > > > > > forward
> > > > > > > > > > with
> > > > > > > > > > > > my
> > > > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > >> > > > the Apache KIE release process,
> > so we
> > > > can
> > > > > > use
> > > > > > > > > > > Apache's
> > > > > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth
> > debate
> > > > about
> > > > > > > > this
> > > > > > > > > > > really
> > > > > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > I'll lay out my entire
> perspective
> > > > about
> > > > > > the
> > > > > > > > > > current
> > > > > > > > > > > > > > > situation
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > > > > >> > > > codebase, as well as problems I
> > can
> > > > > > currently
> > > > > > > > see.
> > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > start
> > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > > > >> > > > analysis of the repositories and
> > their
> > > > > > > > purposes,
> > > > > > > > > > > point
> > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > >> > > > problems that I believe are
> > blocking
> > > > our
> > > > > > 10
> > > > > > > > > > release,
> > > > > > > > > > > > > > explain
> > > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > > >> > > > proposal and discuss some
> > > > consequences to
> > > > > > > > what I'm
> > > > > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO
> > > > (count:
> > > > > > 11)
> > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-pipelines @
> > > > `main`
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @
> > `main`
> > > > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-optaplanner-quickstarts @
> > > > > > > > `main`
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes
> @
> > > > `main`
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @
> > `main`
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples
> @
> > > > `main`
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @
> > `main`
> > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > incubator-kie-kogito-serverless-operator @
> > > > > > > > > > `main`
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @
> > `main`
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @
> > `main-kogito`
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-benchmarks
> > @
> > > > `main`
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @
> > `main`
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > > > > > >> > > > (Issues only, README should
> be
> > > > > > updated @
> > > > > > > > > > `main`.
> > > > > > > > > > > > > Same
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @
> > > > `main`
> > > > > > > > > > > > > > > > > > >> > > > (The Kogito website.
> Develop &
> > > > deploy
> > > > > > at
> > > > > > > > the
> > > > > > > > > > > > `main`
> > > > > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > > > > > >> > > > (The KIE website. Develop @
> > > > `main`.
> > > > > > Push @
> > > > > > > > > > > > `deploy`
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> > > > `gh-pages`
> > > > > > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > > > > > sandbox.kie.org
> > > > > > > > > > and
> > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-online-staging
> > > > @
> > > > > > `main`
> > > > > > > > > > > > > > > > > > >> > > > (Same as above, but for
> manual
> > > > sanity
> > > > > > > > checks
> > > > > > > > > > > > during
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > I grouped the repositories by
> > > > category,
> > > > > > and
> > > > > > > > listed
> > > > > > > > > > > > them
> > > > > > > > > > > > > > in a
> > > > > > > > > > > > > > > > > > >> > > > topological order. Keep in mind
> > that
> > > > when
> > > > > > > > > > flattening
> > > > > > > > > > > > > out a
> > > > > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > > > > >> > > > are multiple possibilities. For
> > > > example,
> > > > > > > > > > OptaPlanner
> > > > > > > > > > > > > > > could've
> > > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > >> > > > placed in any position after
> > Drools.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Category A repos are what I've
> > been
> > > > > > referring
> > > > > > > > to
> > > > > > > > > > as
> > > > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> > > > OptaPlanner
> > > > > > is
> > > > > > > > inside
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > >> > > > way these repositories reference
> > each
> > > > > > other
> > > > > > > > are
> > > > > > > > > > > > through
> > > > > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically,
> the
> > > > > > 999-SNAPSHOT
> > > > > > > > > > > > version.
> > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > > > > >> > > > is well-known to the team, and
> > > > although
> > > > > > > > flawed for
> > > > > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > > > > >> > > > and disruptive for people in
> many
> > > > > > different
> > > > > > > > time
> > > > > > > > > > > > zones,
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > > >> > > > very comfortable for everyone to
> > work
> > > > > > with, I
> > > > > > > > > > > assume.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Contributions made to Category A
> > have
> > > > some
> > > > > > > > > > dedicated
> > > > > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > > > >> > > > are, at least to some extent,
> > able to
> > > > > > build
> > > > > > > > > > > cross-repo
> > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > > >> > > > and verify that the codebase
> will
> > > > continue
> > > > > > > > working
> > > > > > > > > > > as
> > > > > > > > > > > > > > > expected
> > > > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > >> > > > they're all merged. From what I
> > could
> > > > > > gather,
> > > > > > > > > > there
> > > > > > > > > > > > are
> > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > >> > > > "sub-streams" currently
> > configured for
> > > > > > > > cross-repo
> > > > > > > > > > > PRs.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> > > > kogito-apps,
> > > > > > and
> > > > > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > > > > >> > > > - optaplanner, and
> > > > optaplanner-quickstarts
> > > > > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > This means that sending
> cross-repo
> > > > PRs to
> > > > > > any
> > > > > > > > > > > > > combination
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > >> > > > that are not part of the same
> > > > "sub-stream"
> > > > > > > > cannot
> > > > > > > > > > be
> > > > > > > > > > > > > > > verified
> > > > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > > > >> > > > merging, making our contribution
> > model
> > > > > > > > dependent
> > > > > > > > > > on
> > > > > > > > > > > > > > > individual
> > > > > > > > > > > > > > > > > > >> > > > contributors building stuff on
> > their
> > > > > > machines
> > > > > > > > to
> > > > > > > > > > > > verify
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > > >> > > > Note that I'm not that familiar
> > with
> > > > these
> > > > > > > > > > > pipelines,
> > > > > > > > > > > > so
> > > > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Category B repos are what I've
> > been
> > > > > > referring
> > > > > > > > to
> > > > > > > > > > as
> > > > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > > >> > > > stream. The first repo there is
> a
> > > > template
> > > > > > > > > > > repository
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > > > > >> > > > people starting projects from
> > scratch
> > > > on
> > > > > > KIE
> > > > > > > > > > > Sandbox,
> > > > > > > > > > > > > > > similar
> > > > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > >> > > > Maven archetype, if you will.
> The
> > > > other
> > > > > > one
> > > > > > > > is the
> > > > > > > > > > > KIE
> > > > > > > > > > > > > > Tools
> > > > > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm`
> > as its
> > > > > > build
> > > > > > > > > > system.
> > > > > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and
> > apps,
> > > > > > > > TypeScript
> > > > > > > > > > > > > libraries
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm
> > charts.
> > > > The
> > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > >> > > > configured to work with sparse
> > > > checkouts
> > > > > > and
> > > > > > > > can
> > > > > > > > > > do
> > > > > > > > > > > > > > partial
> > > > > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > > > > >> > > > Category B repos refer to
> > Category A
> > > > repos
> > > > > > > > through
> > > > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new
> > mechanism we
> > > > > > recently
> > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > >> > > > build and publish immutable,
> > > > persistent
> > > > > > > > artifacts
> > > > > > > > > > > > under
> > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > > > >> > > > following the
> > 999-YYYYMMDD-SNAPSHOT
> > > > > > format,
> > > > > > > > > > > published
> > > > > > > > > > > > > > weekly
> > > > > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped
> > SNAPSHOTs
> > > > are an
> > > > > > > > > > evolution
> > > > > > > > > > > > to
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > > >> > > > releases, as we're now targeting
> > one
> > > > > > release
> > > > > > > > for
> > > > > > > > > > all
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > > > >> > > > we can't have Kogito releases
> > anymore.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > An important note here is that
> > > > Category B
> > > > > > > > > > > repositories
> > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > >> > > > historically kept out of any
> > > > automations
> > > > > > we
> > > > > > > > used
> > > > > > > > > > to
> > > > > > > > > > > > > have,
> > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > > >> > > > when Kogito started and we had
> the
> > > > > > Business
> > > > > > > > > > Central
> > > > > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > > > > >> > > > still going on. For this reason,
> > > > Category
> > > > > > B
> > > > > > > > > > projects
> > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > > > > >> > > > their own automations, based on
> > GitHub
> > > > > > > > Actions.
> > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > > > > >> > > > always depended on Category A
> > repos
> > > > using
> > > > > > > > fixed
> > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > If
> > > > > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > > > > > SNAPSHOTs,
> > > > > > > > > > breaking
> > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > >> > > > Category A repositories would've
> > had
> > > > the
> > > > > > > > potential
> > > > > > > > > > > to
> > > > > > > > > > > > > > break
> > > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > > >> > > > silently, leaving Category B
> with
> > a
> > > > broken
> > > > > > > > > > > development
> > > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > >> > > > introducing unpleasant surprises
> > for
> > > > > > > > maintainers
> > > > > > > > > > of
> > > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > > > > >> > > > as historically Category A
> > > > contributors
> > > > > > were
> > > > > > > > not
> > > > > > > > > > > > > familiar
> > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Contributions made to Category B
> > > > repos go
> > > > > > > > through
> > > > > > > > > > a
> > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > > > > >> > > > workflow that builds the
> relevant
> > > > part of
> > > > > > the
> > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > >> > > > the changes introduced. Changes
> > made
> > > > to
> > > > > > the
> > > > > > > > > > pipeline
> > > > > > > > > > > > > > itself
> > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > > > > >> > > > picked up as part of PRs,
> > allowing us
> > > > to
> > > > > > do
> > > > > > > > things
> > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> > > > example.
> > > > > > More
> > > > > > > > > > > > > > importantly,
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > > > > >> > > > us to upgrade the repository to
> a
> > new
> > > > > > > > timestamped
> > > > > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > > >> > > > with the changes necessary to
> > make it
> > > > stay
> > > > > > > > green.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > This setup, however, makes it
> > > > impossible
> > > > > > to
> > > > > > > > have
> > > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > > >> > > > involving Category A and
> Category
> > B
> > > > > > > > > > simultaneously,
> > > > > > > > > > > > with
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Category C repos are kind of
> > floating
> > > > > > around,
> > > > > > > > and
> > > > > > > > > > > I'm
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > > >> > > > there's much activity going on
> > there.
> > > > > > > > Regardless,
> > > > > > > > > > as
> > > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of
> > our
> > > > > > release,
> > > > > > > > so I
> > > > > > > > > > > > > listed
> > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > > >> > > > to take them into consideration
> > too.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Category D is self explanatory.
> > > > There's
> > > > > > only
> > > > > > > > one
> > > > > > > > > > > repo
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > has
> > > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Category E are repos that do not
> > host
> > > > code
> > > > > > > > > > directly,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > > > > >> > > > organizational entities, or host
> > > > websites,
> > > > > > > > that
> > > > > > > > > > > > > currently
> > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > This lack of unification between
> > > > Category
> > > > > > A
> > > > > > > > and
> > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > is,
> > > > > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> > > > infamous
> > > > > > > > circular
> > > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`,
> > which
> > > > we
> > > > > > now
> > > > > > > > can
> > > > > > > > > > > > describe
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > > > > >> > > > dependency between Category A
> and
> > > > > > Category B.
> > > > > > > > The
> > > > > > > > > > > way
> > > > > > > > > > > > I
> > > > > > > > > > > > > > see
> > > > > > > > > > > > > > > > it,
> > > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > >> > > > had a single pipeline, building
> > > > everything
> > > > > > > > from
> > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've
> > never
> > > > > > been
> > > > > > > > > > > > introduced,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > >> > > > wouldn't be having this huge
> > problem
> > > > in
> > > > > > our
> > > > > > > > hands
> > > > > > > > > > > > right
> > > > > > > > > > > > > > now.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE
> > release
> > > > > > process
> > > > > > > > > > sees
> > > > > > > > > > > > this
> > > > > > > > > > > > > > > lack
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > >> > > > unification as a central
> problem,
> > not
> > > > > > only for
> > > > > > > > > > this
> > > > > > > > > > > > > > release
> > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > >> > > > particular, but for the
> community
> > as a
> > > > > > whole.
> > > > > > > > It
> > > > > > > > > > is
> > > > > > > > > > > my
> > > > > > > > > > > > > > > belief
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > >> > > > are all under the same roof, and
> > that
> > > > no
> > > > > > > > > > > contribution
> > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > >> > > > allowed to break any part of our
> > > > codebase.
> > > > > > > > With
> > > > > > > > > > the
> > > > > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > > > > > contributors
> > > > > > > > too,
> > > > > > > > > > > we
> > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > > > > >> > > > counting on "common sense" to
> > avoid
> > > > > > breaking
> > > > > > > > > > things.
> > > > > > > > > > > > > We're
> > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > > > > >> > > > after all, and it is our job to
> > have
> > > > > > > > mechanisms in
> > > > > > > > > > > > place
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > > >> > > > from unwillingly making
> mistakes.
> > > > > > Especially
> > > > > > > > when
> > > > > > > > > > > > these
> > > > > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > > > > >> > > > impact on parts of the codebase
> > that
> > > > we,
> > > > > > > > > > > individually,
> > > > > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @
> > `kogito-apps`
> > > > > > depending
> > > > > > > > on
> > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF
> images
> > @
> > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools`
> > > > depending on
> > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > > > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > P4. Multiple packages @
> > `kogito-apps`
> > > > > > > > depending on
> > > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > > > > > >> > > > * This module was removed from
> > the KIE
> > > > > > > > codebase
> > > > > > > > > > > here:
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > >
> > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > > > > > ,
> > > > > > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > > > > > >> > > > * This new repo depends on
> Kogito
> > and
> > > > > > > > OptaPlanner,
> > > > > > > > > > > > > > pointing
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > older
> > > > > > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > P5.
> > > > > > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > > > > > depending
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> > > > `2.15.3.Final`.
> > > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > P6. Category C repos are out of
> > date
> > > > and
> > > > > > not
> > > > > > > > part
> > > > > > > > > > of
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > > > > > >> > > > *
> incubator-kie-kogito-benchmarks:
> > > > > > (Current
> > > > > > > > > > version
> > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > > >> > > > depending on Kogito without a
> > specific
> > > > > > > > version,
> > > > > > > > > > only
> > > > > > > > > > > > by
> > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks:
> > (Current
> > > > > > version
> > > > > > > > is
> > > > > > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT
> > and
> > > > > > > > OptaPlanner
> > > > > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > P7.
> > > > > > `kie-tools`/packages/kn-plugin-workflow
> > > > > > > > has
> > > > > > > > > > its
> > > > > > > > > > > > E2E
> > > > > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > > > > > >> > > > upgrading to
> > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2
> have
> > the
> > > > same
> > > > > > > > > > solution,
> > > > > > > > > > > > as
> > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > > > > >> > > > suffer from the circular
> > dependency
> > > > > > between
> > > > > > > > > > > Category A
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > > > > > >> > > > As Category A and Category B are
> > both
> > > > > > streams
> > > > > > > > that
> > > > > > > > > > > > have
> > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > > >> > > > active, I see this as a blocker,
> > as
> > > > there
> > > > > > are
> > > > > > > > > > > > > > contributions
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > >> > > > cannot be done, given that
> > Category A
> > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal,
> > can be
> > > > > > > > understood
> > > > > > > > > > as
> > > > > > > > > > > > > > > technical
> > > > > > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > > > > > >> > > > Depending on unmaintained
> > projects is
> > > > > > > > something
> > > > > > > > > > > we'll
> > > > > > > > > > > > > > always
> > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as
> > it's
> > > > > > just a
> > > > > > > > > > matter
> > > > > > > > > > > of
> > > > > > > > > > > > > > > making
> > > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > P7 is an isolated problem that
> > won't
> > > > > > impact
> > > > > > > > the
> > > > > > > > > > > > > structure
> > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > > > > > >> > > > that we're talking about here,
> > but it
> > > > is a
> > > > > > > > > > > regression
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be
> ignored
> > for
> > > > > > Apache
> > > > > > > > KIE
> > > > > > > > > > 10,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only
> > > > problems
> > > > > > > > left to
> > > > > > > > > > > > > discuss
> > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > >> > > > P2, which can't be done without
> a
> > > > proper
> > > > > > > > proposal.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > I'll try to be very meticulous
> > here,
> > > > since
> > > > > > > > from my
> > > > > > > > > > > > > > > experience,
> > > > > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > > > > >> > > > little miscalculation can lead
> to
> > our
> > > > > > release
> > > > > > > > not
> > > > > > > > > > > > > working
> > > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > >> > > > end. To try and avoid that as
> > much as
> > > > > > > > possible,
> > > > > > > > > > and
> > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > >> > > > can to have a successful Apache
> > KIE 10
> > > > > > > > release,
> > > > > > > > > > bear
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > > me.
> > > > > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > > > > > >> > > > out a timeline of events that
> > need to
> > > > > > happen
> > > > > > > > in
> > > > > > > > > > > order
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > > > > > >> > > > to be published, with all
> > artifacts
> > > > > > ending up
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > > > right
> > > > > > > > > > > > > > > > > places,
> > > > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > > > >> > > > first, we need to solve problems
> > P1
> > > > and
> > > > > > P2.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > As you saw at the beginning of
> > this
> > > > email,
> > > > > > > > all the
> > > > > > > > > > > > > > attempts
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > made
> > > > > > > > > > > > > > > > > > >> > > > left us with the circular
> > dependency
> > > > > > showing
> > > > > > > > up
> > > > > > > > > > at a
> > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > > > > > >> > > > but something all these places
> > have in
> > > > > > common
> > > > > > > > is
> > > > > > > > > > > that
> > > > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > >> > > > after kogito-apps, and before to
> > > > Category
> > > > > > B.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > The first part of my proposal is
> > the
> > > > > > > > following:
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > S1. We keep the original plan of
> > > > moving
> > > > > > the
> > > > > > > > > > Quarkus
> > > > > > > > > > > > Dev
> > > > > > > > > > > > > > UIs
> > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`,
> > together
> > > > > > with
> > > > > > > > > > > Management
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Task
> > > > > > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > > >> > > > S2. We move the
> > `kogito-swf-devmode`
> > > > and
> > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > > > >> > > > from `kogito-images` to
> > `kie-tools`
> > > > too.
> > > > > > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > > > > > `kogito-serverless-operator`
> > > > > > > > > > > > repo
> > > > > > > > > > > > > > > > inside
> > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping
> > Git
> > > > > > history.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3
> together
> > > > solve
> > > > > > > > problems
> > > > > > > > > > P1
> > > > > > > > > > > > and
> > > > > > > > > > > > > > P2.
> > > > > > > > > > > > > > > Of
> > > > > > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > >
> https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > This doesn't come without
> > > > consequences, of
> > > > > > > > course,
> > > > > > > > > > > as
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > > > > > `kogito-swf-builder`
> > > > > > > > > > > images,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > would be
> > > > > > moving
> > > > > > > > from
> > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > >> > > > Category B. This move would make
> > them
> > > > > > have to
> > > > > > > > > > > > reference
> > > > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > > > >> > > > repos through timestamped
> > SNAPSHOTs.
> > > > Since
> > > > > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are
> > > > already
> > > > > > > > their own
> > > > > > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > > > > > >> > > > Category A, though,
> contributions
> > > > made in
> > > > > > a
> > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > fashion
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> > > > > > possible, now
> > > > > > > > > > via a
> > > > > > > > > > > > > > single
> > > > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs
> > between
> > > > > > Category
> > > > > > > > A and
> > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > > >> > > > continue not being possible,
> and a
> > > > 1-week
> > > > > > > > delay
> > > > > > > > > > > > between
> > > > > > > > > > > > > > > > merging
> > > > > > > > > > > > > > > > > > >> > > > something on Category A and
> using
> > it
> > > > on
> > > > > > > > Category B
> > > > > > > > > > > > will
> > > > > > > > > > > > > > > still
> > > > > > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > It's worth mentioning that
> > > > `kie-tools`,
> > > > > > > > however,
> > > > > > > > > > > does
> > > > > > > > > > > > > > allow
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > > > > > >> > > > checkouts and partial builds, so
> > > > working
> > > > > > with
> > > > > > > > a
> > > > > > > > > > > subset
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > > >> > > > is possible and encouraged.
> Making
> > > > changes
> > > > > > > > only to
> > > > > > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`,
> for
> > > > > > example,
> > > > > > > > will
> > > > > > > > > > > have
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can
> > see
> > > > here:
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > > >> > > > We're not compromising when
> > running
> > > > > > partial
> > > > > > > > builds
> > > > > > > > > > > > too.
> > > > > > > > > > > > > We
> > > > > > > > > > > > > > > > know
> > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > >> > > > the entire repo will continue
> > working
> > > > even
> > > > > > > > after
> > > > > > > > > > > only
> > > > > > > > > > > > > > > > building a
> > > > > > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > > > > > >> > > > subset of the changes. Doing
> > partial
> > > > or
> > > > > > full
> > > > > > > > > > builds
> > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > > > > > >> > > > determined by the changes of a
> PR.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Keep in mind that, even though
> I'm
> > > > > > proposing
> > > > > > > > we
> > > > > > > > > > > move a
> > > > > > > > > > > > > > bunch
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > >> > > > additional stuff into
> > `kie-tools`, I
> > > > see
> > > > > > this
> > > > > > > > as a
> > > > > > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools`
> > would
> > > > host
> > > > > > some
> > > > > > > > > > > > additional
> > > > > > > > > > > > > > > stuff
> > > > > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can
> > release and
> > > > > > > > continue
> > > > > > > > > > > moving
> > > > > > > > > > > > > > > > forward.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > As I mentioned on other places,
> > > > > > `kie-tools`
> > > > > > > > > > became a
> > > > > > > > > > > > > > > polyglot
> > > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > > >> > > > out of necessity, and although
> I'm
> > > > really
> > > > > > > > proud of
> > > > > > > > > > > > what
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > > > > > >> > > > there so far, I don't think
> > > > `kie-tools`
> > > > > > has a
> > > > > > > > > > setup
> > > > > > > > > > > > that
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > > > > > >> > > > for all the different nuances
> that
> > > > > > compose our
> > > > > > > > > > > > > community.
> > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo
> > that
> > > > does
> > > > > > not
> > > > > > > > > > follow
> > > > > > > > > > > > > > > widespread
> > > > > > > > > > > > > > > > > > >> > > > conventions will scare some
> people
> > > > away,
> > > > > > and
> > > > > > > > as
> > > > > > > > > > much
> > > > > > > > > > > > as
> > > > > > > > > > > > > > > we've
> > > > > > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > >> > > > make build instructions clear,
> we
> > > > can't
> > > > > > > > always get
> > > > > > > > > > > > past
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > > > > > >> > > > some people have towards the
> > > > "front-end"
> > > > > > > > > > ecosystem.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > With all that said, I keep
> > thinking
> > > > this
> > > > > > is
> > > > > > > > the
> > > > > > > > > > best
> > > > > > > > > > > > > > course
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > > > > > >> > > > for us right now. We keep most
> of
> > our
> > > > > > stuff
> > > > > > > > > > > unchanged,
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > >> > > > release, and we have a working
> > setup
> > > > that
> > > > > > will
> > > > > > > > > > suit
> > > > > > > > > > > us
> > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > >> > > > discuss and reach a conclusion
> > > > regarding
> > > > > > the
> > > > > > > > > > future
> > > > > > > > > > > of
> > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Let me paint a quick picture
> here
> > of
> > > > what
> > > > > > our
> > > > > > > > code
> > > > > > > > > > > > base
> > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > > > > >> > > > like, repository-wise, if my
> > proposal
> > > > is
> > > > > > > > accepted:
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-optaplanner
> > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-docs
> > > > > > > > > > > > > > > > > > >> > > > A
> > > > > > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-benchmarks
> > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > >> > > > B
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > >> > > > D
> > > > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > > > > > > >> > > > E
> > > > incubator-kie-kogito-website
> > > > > > > > > > > > > > > > > > >> > > > E
> incubator-kie-website
> > > > > > > > > > > > > > > > > > >> > > > E
> > > > incubator-kie-kogito-online
> > > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > * Category C becomes part of
> > Category
> > > > A,
> > > > > > and
> > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> moves
> > > > > > entirely
> > > > > > > > inside
> > > > > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > > >> > > > * With
> > `kogito-swf-{builder,devmode}`
> > > > > > images
> > > > > > > > and
> > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> > inside
> > > > > > > > `kie-tools`,
> > > > > > > > > > > there
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`,
> > we can
> > > > > > > > granularly
> > > > > > > > > > > > build:
> > > > > > > > > > > > > > > > > > >> > > > 1.
> > > > > > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > > >> > > > 2.
> > > > packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > > >> > > > 3.
> packages/sonataflow-images
> > > > > > (containing
> > > > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > > > > > >> > > > 4.
> > packages/sonataflow-operator
> > > > > > (contents
> > > > > > > > from
> > > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > > > > > >> > > > 5.
> > packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > The second part of the proposal
> > is the
> > > > > > release
> > > > > > > > > > > process
> > > > > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > > > > >> > > > assuming the structure above is
> > what
> > > > we
> > > > > > have.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT
> > to be
> > > > > > used as
> > > > > > > > > > > cutting
> > > > > > > > > > > > > > point
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > > > > > >> > > > 2. Update Category B repos to
> > point to
> > > > > > this
> > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > >> > > > verify that everything is
> working.
> > > > > > > > > > > > > > > > > > >> > > > 3. At this point, with
> everything
> > > > > > working, we
> > > > > > > > can
> > > > > > > > > > > > branch
> > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the
> > > > timestamped
> > > > > > > > SNAPSHOT
> > > > > > > > > > > > tag,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > > > > > >> > > > 4. All Category A and Category B
> > repos
> > > > > > update
> > > > > > > > > > their
> > > > > > > > > > > > > > versions
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x`
> > branches.
> > > > > > > > > > > > > > > > > > >> > > > 5. Update Category B repos to
> > point to
> > > > > > > > Category A
> > > > > > > > > > > > repos
> > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on
> > the
> > > > > > release
> > > > > > > > based
> > > > > > > > > > > on
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > > > > > >> > > > branches, given we don't expect
> > any
> > > > code
> > > > > > > > changes
> > > > > > > > > > > > > anymore.
> > > > > > > > > > > > > > > > > > >> > > > 7. After voting passes, we're
> > good to
> > > > > > start
> > > > > > > > the
> > > > > > > > > > > > release
> > > > > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > > > > > manual/automated
> > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch.
> > Tags
> > > > > > pushed
> > > > > > > > to
> > > > > > > > > > Git,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to their
> > registries.
> > > > > > > > > > > > > > > > > > >> > > > 9. We wait a little bit for
> > Category A
> > > > > > > > artifacts
> > > > > > > > > > to
> > > > > > > > > > > be
> > > > > > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > > > > > >> > > > 10. Category B repos follow
> their
> > > > > > > > manual/automated
> > > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch.
> > Tags
> > > > > > pushed
> > > > > > > > to
> > > > > > > > > > Git,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > > >> > > > artifacts pushed to their
> > registries.
> > > > > > > > > > > > > > > > > > >> > > > 11. Category D repos are
> ignored.
> > > > > > > > > > > > > > > > > > >> > > > 12. Category E repos can be
> > manually
> > > > > > tagged
> > > > > > > > with
> > > > > > > > > > > > 10.0.0
> > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > More needs to be discussed if
> > we're
> > > > > > planning
> > > > > > > > to
> > > > > > > > > > > > maintain
> > > > > > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > > > > > >> > > > release streams in parallel,
> but I
> > > > guess
> > > > > > it
> > > > > > > > can
> > > > > > > > > > wait
> > > > > > > > > > > > for
> > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm
> > looking
> > > > > > > > forward to
> > > > > > > > > > > > > hearing
> > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Of course, alternative solutions
> > are
> > > > > > possible.
> > > > > > > > > > This
> > > > > > > > > > > > > email,
> > > > > > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > > > > > >> > > > summarizes my view of how we
> > should
> > > > > > attack the
> > > > > > > > > > > > problem,
> > > > > > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > > > > > >> > > > disruption, required effort, the
> > > > release
> > > > > > > > process
> > > > > > > > > > > > itself,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > > > > > >> > > > Feel free to propose
> alternatives.
> > > > This is
> > > > > > > > not a
> > > > > > > > > > > > voting
> > > > > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by ricardo zanini fernandes <ri...@gmail.com>.
Hey Tiago, thanks for the insights, I appreciate it.
Just one thing regarding building from kie-tools one module that images
need to sync changes. That might happen, of course. If I see a problem in
devui, I just report it in the tools repo, we work on the bug, and in the
next image build we get the changes. By the nature of the operator/images,
such changes won't impact our builds. What impact our builds are
self-contained on those repos or work made in the engines, where we rely on
Snapshots.
I understand your concern and it's a valid point, but in practice, it's not
what happens. We can live with the latest released version from npm
packages during the dev phase without any problems. From the
images/operator perspective, they are yet another package I need to install
on my container. Like `cat` or `jq`.
But we need to sit down and try to understand our boundaries and how to do
integration tests based on them. For example, deploying a devmode workflow
in Kubernetes and starting a workflow instance via the devui console.
On Wed, Mar 13, 2024 at 3:54 PM Tiago Bento <ti...@gmail.com>
wrote:
> Francisco,
>
> I agree with you that both reasonings are not antagonistic, as an
> antagonistic reasoning in this case would be one that doesn't work.
> And I believe it is clear now that the initial proposal shared on this
> email thread does work, but it is not the only possibility. From the
> beginning I said there are alternatives, but I wanted to start the
> conversation from my point of view, sharing what I think is best. We
> have to acknowledge, though, IMHO, that the discussions we had thus
> far cannot be understood as clearly as what was initially laid out,
> given the lack of details/analysis and a clear execution plan.
>
> Let me elaborate on top of the 3-step plan you shared.
>
> 1)
> No comment. This should be pretty simple to do.
>
> 2)
> There is no global CI stream to be changed, we would have to create
> one. And this has serious implications to our contribution model for
> cross-repo PRs. As I described on the first email of this thread,
> Category A repos are configured in several disjoint streams. Sending a
> PR to `drools` and `kogito-runtimes` will work great, but sending a PR
> to `drools` and `kogito-images`, or `drools` and `optaplanner` won't
> verify that everything will continue working after the PRs are merged,
> as our PR checks are not prepared to build this combination of repos
> together. This is a problem, in my view, but I hardly contribute to
> Category A repos, so I'm assuming things are working fine for those
> who do. The proposal shared on the first email of this thread does not
> change the contribution workflow for any repo of Apache KIE, and
> everyone can continue contributing the way they're used to, except for
> people contributing to the `kogito-swf-{builder,devmode}` images, and
> to `kogito-serverless-operator`. On the other hand, having `kie-tools`
> built in the middle of a new global CI stream, would span another
> class of problem, which is very closely related to the third bullet
> point of the plan you shared.
>
> 3)
> Maven has a mechanism to achieve this pseudo-synchronicity between
> multiple repositories. The mutable SNAPSHOT version, built nightly. It
> is not perfect, though, as I'm sure many of us already experienced
> pulling from the `main` branch of a single repo only to find out that
> a PR ensemble had been merged a few moments prior, requiring us to
> rebuild the entire stack, since our local SNAPSHOTs had become
> out-of-date. That's what we used to have back in Business Central
> (a.k.a. v7) days. Making a `git pull` on a single repo in this setup
> potentially requires all repos to be pulled and rebuilt. I'm sure this
> still happens sometimes when developing Category A projects.
>
> NPM packages don't have mutable SNAPSHOTs. Every published NPM package
> is immutable, and it is really cumbersome and error-prone to integrate
> downstream repos with upstream NPM-bound repos, as not having a
> lockfile brings all sorts of security and stability problems. That's
> why monorepos became so popular in the JavaScript ecosystem. This lack
> of a mutable SNAPSHOT mechanism makes depending on NPM artifacts
> coming from `kie-tools` really hard. The way I see it, moving repos
> downstream of `kie-tools` will require everyone to build `kie-tools`
> anyway, potentially on a daily basis, since it would've then become
> part of the stack that needs to be built before `kogito-images` and
> `kogito-serverless-operator`. More than that, since there would be no
> way to determine what subset of packages of `kie-tools` would need to
> be built to satisfy downstream references, everyone would have to do a
> full build, or handpick individual packages of the monorepo to build.
>
> I hope I was able to offer more insight in the way I see things, along
> with my take on using Maven SNAPSHOTs as the de-facto solution for a
> poly-repo codebase. I don't think we can escape from the complexity of
> our codebase and the nature of the technologies we use, only
> accommodate it in the most comfortable place possible, if even there
> is such a place :)
>
> Now, there are some things I'd like to say regarding the initial
> proposal shared on this email thread.
>
> I understand you, and others, are concerned about moving stuff into
> `kie-tools` for some reasons I could gather from your messages. I'll
> try and list them here, along with my perspective on each of them.
>
> 1. Never being able to move them out of `kie-tools` again.
> This is going to be as hard as it would be removing
> `kn-plugin-workflow` from it now. So, as you and others mentioned this
> possibility, I assume you understand it to be doable.
>
> 2. "Heterodoxizing" an orthodox repository
> (`kogito-serverless-operator`), potentially harming external
> contributions.
> Agree with this point. `kie-tools` is one of a kind, built around
> front-end tooling with some completely unique in-house apparatus. In
> my experience, though, there are a multitude of factors that make
> people want to contribute to an open source project. Conformance to
> well-known widespread technologies and tools is just one of them.
> Being open about it and writing material to smooth out those edges can
> work pretty well. People do not contribute because a codebase is
> "pure". People contribute because they care about the project. And I'm
> always surprised by the lengths people go to when they want to get
> involved.
>
> 3. Disruption to the contribution workflow of those contributing to
> `kogito-swf-{builder,devmode}` images, and to
> `kogito-serverless-operator`.
> It is clear to me now that we can't unblock and release Apache KIE 10
> without impacting anyone, but I hope the first part of this reply
> sheds some light on this complicated matter.
>
> Anyway, that's my attempt to offer a different perspective to some of
> the problems you expressed concern about, perhaps even making the
> initial proposal shared on this email thread be seen with less
> uncertainty.
>
> On Wed, Mar 13, 2024 at 11:40 AM Francisco Javier Tirado Sarti
> <ft...@redhat.com> wrote:
> >
> > Tiago,
> > Unfortunately, my plan is too conceptually simple to write more than I
> > already wrote.
> > 1) Move kn-plugin-workflow module to operator repo (this remove the
> > dependency between tools and operator, breaking the loop)
> > 2) Change CI global stream to execute tooling repo before operator repo
> > (this seems to take 2 months unless Tristan helps and reduce the time to
> 2
> > weeks)
> > 3) Optionally, and just as a consequence of that CI change, set
> > 999-SNAPSHOT version to all poms in all repos (if current snapshot
> numbers
> > turns out to be a problem, in any case this is just search-replace)
> >
> > The current plan is:
> > 1) Move everything depending on tools to tools repo, which includes
> > operator code and examples.
> > 2) Change CI of tooling repo to enforce dependencies between the existing
> > modules there and the newly moved ones (this seems to take 3 weeks or
> less)
> >
> > I think rather than asking for a more detailed alternative, what needs to
> > be done is to refine the existing proposal with the feedback received. I
> do
> > not think both proposals are antagonistic. I think that, being now clear
> we
> > have the same overall goal (execute tooling before operator), it is just
> a
> > question of deciding between move more stuff to an already heterodox
> repo,
> > coming from repos not as heterodox, plus changing the repo CI to impose
> > certain order between these modules or pull out the the operator stuff
> from
> > tool repo and put it inside the operator repo plus changing the CI
> > handling repos to impose the desired order: first tooling and then
> operator.
> >
> > On Wed, Mar 13, 2024 at 4:12 PM Tiago Bento <
> tiagobentofernandes@gmail.com>
> > wrote:
> >
> > > Francisco,
> > >
> > > 1) `kie-tools` is already a heterodox repo. The reason why I proposed
> > > my proposal is because it is what I think is the best course of action
> > > for our community right now. If you think there's a better way to do
> > > it, I think everyone, including me, needs to see a proposal with a
> > > clear execution plan with a comparable level of detail and analysis in
> > > regards to disruption of the current state, the required effort, the
> > > contribution workflow for cross-repo PRs, and the release process
> > > itself. Otherwise, we risk having gaps that each person will fill in a
> > > different way, and IMHO, that's where problems happen. +1 for examples
> > > unification, btw :)
> > >
> > > 2) Ok, and +1 for no categorization.
> > >
> > > On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado Sarti
> > > <ft...@redhat.com> wrote:
> > > >
> > > > 1) Ok, if that is the case, I do not get why your first proposal was
> not
> > > > the one I'm proposing and it is apparently not detailed enough. To
> move
> > > > kn-workflow from tooling to operator one and change the order in
> which
> > > the
> > > > repos are being processed. Basically, the problem of the proposed
> > > solution
> > > > is that it kind of converts tooling repo into a pretty heterodox repo
> > > > compared with runtimes, drools or operator one. Also once tooling is
> not
> > > a
> > > > final repo in the overall chain, we can consider moving examples as
> the
> > > > final one and include tooling showcases there (rather than splitting
> > > > examples into examples with tooling and examples without tooling).
> > > > 2) I think this distinction between A and B is one between several
> > > possible
> > > > categorizations (not much, including no categorization at all) that
> > > > deserves a separate discussion. I will open a separate thread for
> that
> > > > purpose, since we are not going to change that now and it is not
> really
> > > > part of the proposal.
> > > >
> > > > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
> > > tiagobentofernandes@gmail.com>
> > > > wrote:
> > > >
> > > > > Francisco,
> > > > >
> > > > > 1) That's what this thread is all about... You know I don't think
> it's
> > > > > ok. That's why I'm proposing the two images and the operator to
> move
> > > > > into the `kie-tools` repo, where we can more granularly control the
> > > > > order things are built, thus removing the dependency cycle.
> > > > >
> > > > > 2) Not sure we understand the same thing by "freeze". My proposal
> is
> > > > > that we select a timestamped SNAPSHOT version from Category A
> repos to
> > > > > use as base for a release. We give Category B repos some time to
> > > > > adjust, and then cut the release branches. This can happen anytime,
> > > > > and no contributions would ever stop because of it. The development
> > > > > branches can continue accepting PRs normally, even during the
> release
> > > > > process. Now, if what you're asking is why Category B repos refer
> to
> > > > > Category A repos via timestamped SNAPSHOTs, the answer is in my
> first
> > > > > email. See the paragraph starting with "An important note here is
> that
> > > > > Category B repositories...".
> > > > >
> > > > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti
> > > > > <ft...@redhat.com> wrote:
> > > > > >
> > > > > > Tiago
> > > > > > There are a couple of simple and straightforward questions that
> I
> > > > > > formulated, but since we both write a lot, it might have been
> lost.
> > > > > Please
> > > > > > let me ask them again.
> > > > > > 1) Do you think it is ok that tools repo is executed after
> > > generation of
> > > > > > docker images that are supposed to include those tools or the
> > > operator
> > > > > that
> > > > > > is supposed to deploy such images?
> > > > > That's what this thread is all about... You know I'm not ok with
> it,
> > > > > that's why I'm proposing the two images and the operator to move
> into
> > > > > the `kie-tools` repo, where we can more granularly control the
> order
> > > > > things are built and remove the dependency cycle.
> > > > > > 2) Besides that, although not directly related with the current
> > > proposal
> > > > > we
> > > > > > are discussing, I really think there are some restrictions taken
> for
> > > > > > granted that are arbitrary and difficult to sustain on strictly
> > > technical
> > > > > > arguments. For example, the need to freeze the rest of the
> software
> > > > > before
> > > > > > tools are generated. Why? We have dependencies between repos that
> > > are not
> > > > > > handled that way: Apps depend on runtimes. Runtimes depend on
> drools,
> > > > > > Operator depend on runtimes,....and we are not freezing that
> repos
> > > since
> > > > > we
> > > > > > are all releasing at the same time. If we are all releasing at
> the
> > > same
> > > > > > time, what's the rationale behind the freeze?
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <
> tiagobento@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > > Glad to see the interest this proposal has gotten, and it's
> good to
> > > > > > > see some alternatives being drafted here, although still
> lacking
> > > clear
> > > > > > > definitions and analysis in regards to disruption, required
> effort,
> > > > > > > the release process itself, and history. Of course, lots of
> details
> > > > > > > and clarity on the execution part would be missing too.
> > > > > > >
> > > > > > > As of this moment, based on what I read here, I'm assuming that
> > > > > > > everyone who participated so far doesn't see the initial
> proposal
> > > as
> > > > > > > problematic in terms of feasibility, but some of you have a
> > > preference
> > > > > > > not to go with it, because it is "wrong", and apparently
> because it
> > > > > > > would "jeopardize the evolution of the project". Reading these
> last
> > > > > > > words made me a little sad, to be honest. But I can deal with
> it :)
> > > > > > >
> > > > > > > Please let's try and keep the discussion as objective as
> possible.
> > > > > > > "Right" and "wrong" are too subjective for this kind of
> > > conversation.
> > > > > > >
> > > > > > > Now, being practical, unless there are clear arguments based on
> > > facts
> > > > > > > and objective concepts that invalidate the initial proposal
> shared
> > > on
> > > > > > > this email, it seems to me that it is currently the only viable
> > > > > > > proposal we have for unblocking and releasing Apache KIE 10. Of
> > > > > > > course, if we end up seeing an alternative proposal with enough
> > > > > > > details and a clear execution plan, I think then we'll be in a
> very
> > > > > > > good position to choose from multiple options!
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <
> alex@porcelli.me>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Francisco and Gabriele,
> > > > > > > >
> > > > > > > > I understand and acknowledge your desire to find the “right”
> > > solution
> > > > > > > > instead to work on a temporary “patch” - however without a
> > > detailed
> > > > > > > > proposal I don’t think we can properly evaluate the impact of
> > > your
> > > > > > > > suggestion.
> > > > > > > >
> > > > > > > > When I spoke with different SMEs that included tools and CI,
> the
> > > > > > > > guesstimate for making the necessary changes on CI and
> codebase
> > > to
> > > > > > > > basically have images and operators in the end of the build
> > > chain is
> > > > > > > > something like 2 months of effort. Another impact that needs
> to
> > > be
> > > > > > > > discussed is that KIE Tools repo had to be injected in the
> > > middle of
> > > > > all
> > > > > > > > pipelines - forcing all PR checks and nightlies to build all
> > > repos
> > > > > (PR
> > > > > > > > checks will likely take 12+ hours… I even heard that it
> could be
> > > > > even 24
> > > > > > > > hours).
> > > > > > > >
> > > > > > > > Based on the input above, I think it’s quite risk to move in
> such
> > > > > > > direction
> > > > > > > > without a more detailed plan… because 2 months could be
> turned
> > > > > easily in
> > > > > > > 6!
> > > > > > > > And this is exactly what happened when we guessed that
> moving to
> > > > > Apache
> > > > > > > > would take no more than 3 months. But here we are.
> > > > > > > >
> > > > > > > > I really strongly suggest that we focus on a release that
> could
> > > be
> > > > > > > > achievable in less than a month from now, and we - after
> release
> > > -
> > > > > have a
> > > > > > > > in depth discussion about the overall codebase and ci
> > > organization.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Alex,
> > > > > > > > > my suggestion is to move the building of all docker images,
> > > from
> > > > > > > whatever
> > > > > > > > > repo (kogito-apps, kie-tools) in a different, downstream
> repo,
> > > to
> > > > > be
> > > > > > > > > invoked after all the others.
> > > > > > > > > I'm not sure if this would solve all the issues, and since
> I
> > > could
> > > > > not
> > > > > > > > > enter in the details of all the involved code, my
> suggestion
> > > may
> > > > > be too
> > > > > > > > > naive.
> > > > > > > > > Having spent almost all of the last year in CI, I may say
> > > that, at
> > > > > > > least
> > > > > > > > > for the kie-tools repo, removing the image build step from
> it
> > > > > should
> > > > > > > not be
> > > > > > > > > too difficult (since it is an issue we already faced and
> > > solved).
> > > > > > > > > If, with "detailed proposal", you mean a complete list of
> all
> > > > > modules
> > > > > > > to be
> > > > > > > > > moved and dependency refactoring, of course I can not
> provide
> > > it
> > > > > right
> > > > > > > now.
> > > > > > > > >
> > > > > > > > > Anyway, I share the concern from Francisco: undoing
> something
> > > is
> > > > > almost
> > > > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier
> > > Tirado
> > > > > Sarti
> > > > > > > <
> > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > >
> > > > > > > > > > I do not think estimations should be the only driver to
> make
> > > a
> > > > > > > decision,
> > > > > > > > > > especially when the current proposal is conceptually
> > > incompatible
> > > > > > > with
> > > > > > > > > the
> > > > > > > > > > multi repo approach that is taken elsewhere in the
> project.
> > > > > > > > > > Given my knowledge of the CI it is nearly impossible for
> me
> > > to
> > > > > give
> > > > > > > a
> > > > > > > > > fair
> > > > > > > > > > estimate of how much it might take to achieve step 2) of
> my
> > > > > previous
> > > > > > > > > e-mail
> > > > > > > > > > . It might take a while or it might be pretty easy after
> > > all, I
> > > > > don't
> > > > > > > > > > really know, but I think it will be a good idea if some
> of
> > > the
> > > > > > > experts
> > > > > > > > > on
> > > > > > > > > > CI in the team (the ones that set up the pipeline, which
> was
> > > a
> > > > > huge
> > > > > > > > > > achievement) give an estimate, not me. Estimating how
> much
> > > it
> > > > > takes
> > > > > > > to
> > > > > > > > > > merge two existing repos (without altering CI) is easier,
> > > but it
> > > > > > > does not
> > > > > > > > > > mean we are doing the right thing.
> > > > > > > > > > My main concern is that it will be very difficult for me
> to
> > > > > explain
> > > > > > > to
> > > > > > > > > > someone that arrives new to the team, that having
> experts on
> > > CI
> > > > > on
> > > > > > > the
> > > > > > > > > > team, we decided to merge two repos (once merged, it
> would be
> > > > > rather
> > > > > > > > > > difficult to unmerge) rather than fix the CI, because of
> > > > > expediency.
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > > > porcelli@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Francisco,
> > > > > > > > > > >
> > > > > > > > > > > Please take the time to make the more in depth analysis
> > > needed
> > > > > and
> > > > > > > > > > provide
> > > > > > > > > > > a more detailed plan… so we - as community- can
> evaluate
> > > the
> > > > > size
> > > > > > > of
> > > > > > > > > the
> > > > > > > > > > > effort. In the conceptual level you shared it’s near
> > > > > impossible to
> > > > > > > > > > estimate
> > > > > > > > > > > the size of the effort and compare with the current
> > > proposal.
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado
> > > Sarti <
> > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > > > 1) Remove all dependencies from tooling to images,
> so
> > > images
> > > > > > > depend
> > > > > > > > > on
> > > > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > > > 2) Then change CI to deal with tooling repo before
> > > dealing
> > > > > with
> > > > > > > > > images
> > > > > > > > > > > > repo.
> > > > > > > > > > > > I understand that CI details are tricky and since
> I'm not
> > > > > > > familiar
> > > > > > > > > with
> > > > > > > > > > > CI
> > > > > > > > > > > > in any way, I barely can make a low level design,
> but we
> > > do
> > > > > not
> > > > > > > need
> > > > > > > > > to
> > > > > > > > > > > fix
> > > > > > > > > > > > everything, just achieve 2), a change of compilation
> > > order.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > > > > alex@porcelli.me
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > > > >
> > > > > > > > > > > > > You may not like or understand why the current
> state of
> > > > > the CI
> > > > > > > is
> > > > > > > > > > like
> > > > > > > > > > > > > that… actually has been in Red Hat and has been
> > > replicated
> > > > > in
> > > > > > > > > Apache
> > > > > > > > > > as
> > > > > > > > > > > > > used to be….
> > > > > > > > > > > > >
> > > > > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you disagree with the current plan, please
> provide a
> > > > > > > detailed
> > > > > > > > > > > > > alternative so we, as community, can better
> evaluate
> > > the
> > > > > pros
> > > > > > > and
> > > > > > > > > > cons
> > > > > > > > > > > of
> > > > > > > > > > > > > each proposal.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think it’s also fair to say that, post 10
> release we
> > > > > need to
> > > > > > > > > have a
> > > > > > > > > > > > much
> > > > > > > > > > > > > in depth discussion about how our codebase is
> > > organized,
> > > > > it’s
> > > > > > > clear
> > > > > > > > > > > that
> > > > > > > > > > > > > it’s not working.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > > > I also have the impression that the "images" (if
> we
> > > are
> > > > > > > talking
> > > > > > > > > of
> > > > > > > > > > > > docker
> > > > > > > > > > > > > > images) should be the very last one to be built,
> in a
> > > > > > > standalone
> > > > > > > > > > > repo.
> > > > > > > > > > > > > > That way, they may "combine" artifacts that are
> > > built in
> > > > > > > > > different
> > > > > > > > > > > > repos,
> > > > > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > > > > Moving them out of all the repos
> > > (kogito-apps/kie-tools)
> > > > > > > maybe
> > > > > > > > > > could
> > > > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > > > (I also think there are some statements of
> > > undisputable
> > > > > needs
> > > > > > > > > while
> > > > > > > > > > > > they
> > > > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > > > Anyway, this latter point is for longer,
> following,
> > > > > > > discussion.)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23
> Francisco
> > > Javier
> > > > > > > Tirado
> > > > > > > > > > > Sarti
> > > > > > > > > > > > <
> > > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > > > There are two assumptions that deserve further
> > > > > discussion:
> > > > > > > > > > > > > > > 1) That tool has to be the last to build. why?
> it
> > > does
> > > > > not
> > > > > > > have
> > > > > > > > > > > more
> > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > to build final images after everything else has
> > > been
> > > > > > > built?-
> > > > > > > > > > > > > > > 2) That the impact (in terms of effort now) on
> > > fixing
> > > > > CI is
> > > > > > > > > > bigger
> > > > > > > > > > > > than
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > impact (long term consequences) of
> consolidating
> > > two
> > > > > > > unrelated
> > > > > > > > > > > piece
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli
> <
> > > > > > > > > alex@porcelli.me
> > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This was discussed as an alternative
> solution,
> > > > > however
> > > > > > > it has
> > > > > > > > > > > major
> > > > > > > > > > > > > > > impact
> > > > > > > > > > > > > > > > on CI and there’s also the fact Tool has been
> > > always
> > > > > the
> > > > > > > last
> > > > > > > > > > to
> > > > > > > > > > > > > build
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > has no Snapshot published (actually in
> JavaScript
> > > > > world
> > > > > > > there
> > > > > > > > > > is
> > > > > > > > > > > no
> > > > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So, based on our evaluation… the proposal
> here
> > > is the
> > > > > > > least
> > > > > > > > > > > > > disruptive
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco
> Javier
> > > > > Tirado
> > > > > > > > > Sarti <
> > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > > > > embracing
> > > > > > > the
> > > > > > > > > fact
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > kogito-images depend on kie-tools, because
> we
> > > want
> > > > > > > those
> > > > > > > > > > images
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco
> > > Javier
> > > > > > > Tirado
> > > > > > > > > > Sarti
> > > > > > > > > > > <
> > > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > > > > kn-plugin-workflow
> > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > kogito-images (so there is not longer
> > > dependency
> > > > > from
> > > > > > > > > tools
> > > > > > > > > > > to
> > > > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > then build kogito-images after
> kogito-tools?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique
> > > Gonzalez
> > > > > > > > > Martinez
> > > > > > > > > > <
> > > > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere
> Fernandez
> > > > > (apache)
> > > > > > > <
> > > > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> > I say +1 in order to move forward with
> > > the 10.
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex
> > > Porcelli <
> > > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> > > I spent the last day or so working
> > > closely
> > > > > with
> > > > > > > > > Tiago,
> > > > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > > > >> > > options and getting deeper on the
> > > impact and
> > > > > > > > > > evaluating
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > > > >> > > procedure steps required. I agree
> with
> > > the
> > > > > > > proposal
> > > > > > > > > as
> > > > > > > > > > > the
> > > > > > > > > > > > > > most
> > > > > > > > > > > > > > > > > >> > > viable option for unblocking the 10
> > > release
> > > > > in
> > > > > > > the
> > > > > > > > > > > > > reasonable
> > > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM
> Tiago
> > > Bento
> > > > > <
> > > > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr
> this
> > > > > time,
> > > > > > > as
> > > > > > > > > this
> > > > > > > > > > > > > matter
> > > > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > This email will take you < 20
> minutes
> > > to
> > > > > read,
> > > > > > > > > > > according
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > As you may have followed on a
> separate
> > > > > thread
> > > > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > > > >
> > > > > > > > > >
> > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > > > >> > > > many of us were working towards
> > > removing a
> > > > > > > > > circular
> > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > >> > > > currently present between
> > > `kogito-apps`
> > > > > and
> > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > As
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > >> > > > progressed towards a solution, we
> kept
> > > > > > > finding the
> > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > > > > breakdown of
> > > > > > > the
> > > > > > > > > > > things
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Right now, even though we started
> the
> > > > > effort
> > > > > > > to
> > > > > > > > > move
> > > > > > > > > > > the
> > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we
> haven't
> > > been
> > > > > > > able to
> > > > > > > > > > do
> > > > > > > > > > > it
> > > > > > > > > > > > > > yet,
> > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to
> Java
> > > 17,
> > > > > > > Maven
> > > > > > > > > > 3.9.6,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito
> Runtimes
> > > > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > >> > > > effort was concluded this Monday,
> with
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > >
> https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > > > .
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > >> > > > |==> 02.
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > >> > > > L |
> > > ==========================
> > > > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > >> > > > |==> 07.
> incubator-kie-tools
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > * As
> > > `kie-tools`/extended-services
> > > > > > > depends
> > > > > > > > > > on
> > > > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs
> to
> > > > > > > `kie-tools`,
> > > > > > > > > we
> > > > > > > > > > > > > would've
> > > > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > >> > > > C |
> =====================
> > > > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > >> > > > E |==> 07.
> incubator-kie-tools
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > * As
> > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > depends
> > > > > > > > > > on
> > > > > > > > > > > > > > > > > >> > > >
> `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > > > depends
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > >> > > >
> `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > After moving the
> `kogito-swf-devmode`
> > > > > image to
> > > > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > >> > > > 02.
> > > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > >> > > > 04.
> > > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > > >> > > > Y |
> =====================
> > > > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > >> > > > L |==> 07.
> incubator-kie-tools
> > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > * As
> > > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > > depends
> > > > > > > > > > on
> > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > > > >> > > > * and
> > > `kogito-serverless-operator`
> > > > > > > depends
> > > > > > > > > > on
> > > > > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger
> problem
> > > > > than a
> > > > > > > > > simple
> > > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > After multiple conversations with
> a
> > > lot of
> > > > > > > people,
> > > > > > > > > > > it's
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > >> > > > hard coming up with a simple
> solution
> > > that
> > > > > > > makes
> > > > > > > > > it
> > > > > > > > > > > > > possible
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while
> > > preserving
> > > > > the
> > > > > > > way
> > > > > > > > > > > > everyone
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >> > > > contributing to the multiple
> > > repositories
> > > > > we
> > > > > > > have.
> > > > > > > > > > > More
> > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > > > >> > > > while making this assessment, I
> found
> > > more
> > > > > > > > > problems
> > > > > > > > > > > > that,
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm
> > > coming
> > > > > > > forward
> > > > > > > > > with
> > > > > > > > > > > my
> > > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > >> > > > the Apache KIE release process,
> so we
> > > can
> > > > > use
> > > > > > > > > > Apache's
> > > > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth
> debate
> > > about
> > > > > > > this
> > > > > > > > > > really
> > > > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective
> > > about
> > > > > the
> > > > > > > > > current
> > > > > > > > > > > > > > situation
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > > > >> > > > codebase, as well as problems I
> can
> > > > > currently
> > > > > > > see.
> > > > > > > > > > > I'll
> > > > > > > > > > > > > > start
> > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > > >> > > > analysis of the repositories and
> their
> > > > > > > purposes,
> > > > > > > > > > point
> > > > > > > > > > > > out
> > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > >> > > > problems that I believe are
> blocking
> > > our
> > > > > 10
> > > > > > > > > release,
> > > > > > > > > > > > > explain
> > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > >> > > > proposal and discuss some
> > > consequences to
> > > > > > > what I'm
> > > > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO
> > > (count:
> > > > > 11)
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @
> > > `main`
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @
> `main`
> > > > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-optaplanner-quickstarts @
> > > > > > > `main`
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @
> > > `main`
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @
> `main`
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @
> > > `main`
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @
> `main`
> > > > > > > > > > > > > > > > > >> > > > -
> > > > > incubator-kie-kogito-serverless-operator @
> > > > > > > > > `main`
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @
> `main`
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @
> `main-kogito`
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > > > >> > > > -
> > > > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks
> @
> > > `main`
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @
> `main`
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > > > > updated @
> > > > > > > > > `main`.
> > > > > > > > > > > > Same
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @
> > > `main`
> > > > > > > > > > > > > > > > > >> > > > (The Kogito website. Develop &
> > > deploy
> > > > > at
> > > > > > > the
> > > > > > > > > > > `main`
> > > > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > > > > >> > > > (The KIE website. Develop @
> > > `main`.
> > > > > Push @
> > > > > > > > > > > `deploy`
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> > > `gh-pages`
> > > > > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > > > > sandbox.kie.org
> > > > > > > > > and
> > > > > > > > > > > KIE
> > > > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-online-staging
> > > @
> > > > > `main`
> > > > > > > > > > > > > > > > > >> > > > (Same as above, but for manual
> > > sanity
> > > > > > > checks
> > > > > > > > > > > during
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > I grouped the repositories by
> > > category,
> > > > > and
> > > > > > > listed
> > > > > > > > > > > them
> > > > > > > > > > > > > in a
> > > > > > > > > > > > > > > > > >> > > > topological order. Keep in mind
> that
> > > when
> > > > > > > > > flattening
> > > > > > > > > > > > out a
> > > > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > > > >> > > > are multiple possibilities. For
> > > example,
> > > > > > > > > OptaPlanner
> > > > > > > > > > > > > > could've
> > > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > >> > > > placed in any position after
> Drools.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Category A repos are what I've
> been
> > > > > referring
> > > > > > > to
> > > > > > > > > as
> > > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> > > OptaPlanner
> > > > > is
> > > > > > > inside
> > > > > > > > > > > that
> > > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > >> > > > way these repositories reference
> each
> > > > > other
> > > > > > > are
> > > > > > > > > > > through
> > > > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > > > > 999-SNAPSHOT
> > > > > > > > > > > version.
> > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > > > >> > > > is well-known to the team, and
> > > although
> > > > > > > flawed for
> > > > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > > > > different
> > > > > > > time
> > > > > > > > > > > zones,
> > > > > > > > > > > > it
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > >> > > > very comfortable for everyone to
> work
> > > > > with, I
> > > > > > > > > > assume.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Contributions made to Category A
> have
> > > some
> > > > > > > > > dedicated
> > > > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > > >> > > > are, at least to some extent,
> able to
> > > > > build
> > > > > > > > > > cross-repo
> > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > >> > > > and verify that the codebase will
> > > continue
> > > > > > > working
> > > > > > > > > > as
> > > > > > > > > > > > > > expected
> > > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > >> > > > they're all merged. From what I
> could
> > > > > gather,
> > > > > > > > > there
> > > > > > > > > > > are
> > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > >> > > > "sub-streams" currently
> configured for
> > > > > > > cross-repo
> > > > > > > > > > PRs.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> > > kogito-apps,
> > > > > and
> > > > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > > > >> > > > - optaplanner, and
> > > optaplanner-quickstarts
> > > > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > This means that sending cross-repo
> > > PRs to
> > > > > any
> > > > > > > > > > > > combination
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > >> > > > that are not part of the same
> > > "sub-stream"
> > > > > > > cannot
> > > > > > > > > be
> > > > > > > > > > > > > > verified
> > > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > > >> > > > merging, making our contribution
> model
> > > > > > > dependent
> > > > > > > > > on
> > > > > > > > > > > > > > individual
> > > > > > > > > > > > > > > > > >> > > > contributors building stuff on
> their
> > > > > machines
> > > > > > > to
> > > > > > > > > > > verify
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > >> > > > Note that I'm not that familiar
> with
> > > these
> > > > > > > > > > pipelines,
> > > > > > > > > > > so
> > > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Category B repos are what I've
> been
> > > > > referring
> > > > > > > to
> > > > > > > > > as
> > > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > > >> > > > stream. The first repo there is a
> > > template
> > > > > > > > > > repository
> > > > > > > > > > > > that
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > > > >> > > > people starting projects from
> scratch
> > > on
> > > > > KIE
> > > > > > > > > > Sandbox,
> > > > > > > > > > > > > > similar
> > > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The
> > > other
> > > > > one
> > > > > > > is the
> > > > > > > > > > KIE
> > > > > > > > > > > > > Tools
> > > > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm`
> as its
> > > > > build
> > > > > > > > > system.
> > > > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and
> apps,
> > > > > > > TypeScript
> > > > > > > > > > > > libraries
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm
> charts.
> > > The
> > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > >> > > > configured to work with sparse
> > > checkouts
> > > > > and
> > > > > > > can
> > > > > > > > > do
> > > > > > > > > > > > > partial
> > > > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > > > >> > > > Category B repos refer to
> Category A
> > > repos
> > > > > > > through
> > > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new
> mechanism we
> > > > > recently
> > > > > > > > > > > > introduced
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > >> > > > build and publish immutable,
> > > persistent
> > > > > > > artifacts
> > > > > > > > > > > under
> > > > > > > > > > > > a
> > > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > > >> > > > following the
> 999-YYYYMMDD-SNAPSHOT
> > > > > format,
> > > > > > > > > > published
> > > > > > > > > > > > > weekly
> > > > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped
> SNAPSHOTs
> > > are an
> > > > > > > > > evolution
> > > > > > > > > > > to
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > >> > > > releases, as we're now targeting
> one
> > > > > release
> > > > > > > for
> > > > > > > > > all
> > > > > > > > > > > of
> > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > > >> > > > we can't have Kogito releases
> anymore.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > An important note here is that
> > > Category B
> > > > > > > > > > repositories
> > > > > > > > > > > > > have
> > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > >> > > > historically kept out of any
> > > automations
> > > > > we
> > > > > > > used
> > > > > > > > > to
> > > > > > > > > > > > have,
> > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > > > > Business
> > > > > > > > > Central
> > > > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > > > >> > > > still going on. For this reason,
> > > Category
> > > > > B
> > > > > > > > > projects
> > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > > > >> > > > their own automations, based on
> GitHub
> > > > > > > Actions.
> > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > > > >> > > > always depended on Category A
> repos
> > > using
> > > > > > > fixed
> > > > > > > > > > > > versions.
> > > > > > > > > > > > > If
> > > > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > > > > SNAPSHOTs,
> > > > > > > > > breaking
> > > > > > > > > > > > > changes
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > >> > > > Category A repositories would've
> had
> > > the
> > > > > > > potential
> > > > > > > > > > to
> > > > > > > > > > > > > break
> > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > >> > > > silently, leaving Category B with
> a
> > > broken
> > > > > > > > > > development
> > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > >> > > > introducing unpleasant surprises
> for
> > > > > > > maintainers
> > > > > > > > > of
> > > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > > > >> > > > as historically Category A
> > > contributors
> > > > > were
> > > > > > > not
> > > > > > > > > > > > familiar
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Contributions made to Category B
> > > repos go
> > > > > > > through
> > > > > > > > > a
> > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > > > >> > > > workflow that builds the relevant
> > > part of
> > > > > the
> > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > >> > > > the changes introduced. Changes
> made
> > > to
> > > > > the
> > > > > > > > > pipeline
> > > > > > > > > > > > > itself
> > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > > > >> > > > picked up as part of PRs,
> allowing us
> > > to
> > > > > do
> > > > > > > things
> > > > > > > > > > > like
> > > > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> > > example.
> > > > > More
> > > > > > > > > > > > > importantly,
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > > > >> > > > us to upgrade the repository to a
> new
> > > > > > > timestamped
> > > > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > > >> > > > with the changes necessary to
> make it
> > > stay
> > > > > > > green.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > This setup, however, makes it
> > > impossible
> > > > > to
> > > > > > > have
> > > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > > >> > > > involving Category A and Category
> B
> > > > > > > > > simultaneously,
> > > > > > > > > > > with
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Category C repos are kind of
> floating
> > > > > around,
> > > > > > > and
> > > > > > > > > > I'm
> > > > > > > > > > > > not
> > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > >> > > > there's much activity going on
> there.
> > > > > > > Regardless,
> > > > > > > > > as
> > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of
> our
> > > > > release,
> > > > > > > so I
> > > > > > > > > > > > listed
> > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > >> > > > to take them into consideration
> too.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Category D is self explanatory.
> > > There's
> > > > > only
> > > > > > > one
> > > > > > > > > > repo
> > > > > > > > > > > > that
> > > > > > > > > > > > > > has
> > > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Category E are repos that do not
> host
> > > code
> > > > > > > > > directly,
> > > > > > > > > > > and
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > > > >> > > > organizational entities, or host
> > > websites,
> > > > > > > that
> > > > > > > > > > > > currently
> > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > This lack of unification between
> > > Category
> > > > > A
> > > > > > > and
> > > > > > > > > > > > Category B
> > > > > > > > > > > > > > is,
> > > > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> > > infamous
> > > > > > > circular
> > > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`,
> which
> > > we
> > > > > now
> > > > > > > can
> > > > > > > > > > > describe
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > > > >> > > > dependency between Category A and
> > > > > Category B.
> > > > > > > The
> > > > > > > > > > way
> > > > > > > > > > > I
> > > > > > > > > > > > > see
> > > > > > > > > > > > > > > it,
> > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > >> > > > had a single pipeline, building
> > > everything
> > > > > > > from
> > > > > > > > > > > `drools`
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've
> never
> > > > > been
> > > > > > > > > > > introduced,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > >> > > > wouldn't be having this huge
> problem
> > > in
> > > > > our
> > > > > > > hands
> > > > > > > > > > > right
> > > > > > > > > > > > > now.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE
> release
> > > > > process
> > > > > > > > > sees
> > > > > > > > > > > this
> > > > > > > > > > > > > > lack
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > >> > > > unification as a central problem,
> not
> > > > > only for
> > > > > > > > > this
> > > > > > > > > > > > > release
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > >> > > > particular, but for the community
> as a
> > > > > whole.
> > > > > > > It
> > > > > > > > > is
> > > > > > > > > > my
> > > > > > > > > > > > > > belief
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > >> > > > are all under the same roof, and
> that
> > > no
> > > > > > > > > > contribution
> > > > > > > > > > > > > should
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > >> > > > allowed to break any part of our
> > > codebase.
> > > > > > > With
> > > > > > > > > the
> > > > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > > > > contributors
> > > > > > > too,
> > > > > > > > > > we
> > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > > > >> > > > counting on "common sense" to
> avoid
> > > > > breaking
> > > > > > > > > things.
> > > > > > > > > > > > We're
> > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > > > >> > > > after all, and it is our job to
> have
> > > > > > > mechanisms in
> > > > > > > > > > > place
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> > > > > Especially
> > > > > > > when
> > > > > > > > > > > these
> > > > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > > > >> > > > impact on parts of the codebase
> that
> > > we,
> > > > > > > > > > individually,
> > > > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @
> `kogito-apps`
> > > > > depending
> > > > > > > on
> > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images
> @
> > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools`
> > > depending on
> > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > P4. Multiple packages @
> `kogito-apps`
> > > > > > > depending on
> > > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > > > > >> > > > * This module was removed from
> the KIE
> > > > > > > codebase
> > > > > > > > > > here:
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > >
> https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > > > > ,
> > > > > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito
> and
> > > > > > > OptaPlanner,
> > > > > > > > > > > > > pointing
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > older
> > > > > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > P5.
> > > > > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > > > > depending
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> > > `2.15.3.Final`.
> > > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > P6. Category C repos are out of
> date
> > > and
> > > > > not
> > > > > > > part
> > > > > > > > > of
> > > > > > > > > > > the
> > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> > > > > (Current
> > > > > > > > > version
> > > > > > > > > > is
> > > > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > >> > > > depending on Kogito without a
> specific
> > > > > > > version,
> > > > > > > > > only
> > > > > > > > > > > by
> > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks:
> (Current
> > > > > version
> > > > > > > is
> > > > > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT
> and
> > > > > > > OptaPlanner
> > > > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > P7.
> > > > > `kie-tools`/packages/kn-plugin-workflow
> > > > > > > has
> > > > > > > > > its
> > > > > > > > > > > E2E
> > > > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > > > > >> > > > upgrading to
> 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have
> the
> > > same
> > > > > > > > > solution,
> > > > > > > > > > > as
> > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > > > >> > > > suffer from the circular
> dependency
> > > > > between
> > > > > > > > > > Category A
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > > > > >> > > > As Category A and Category B are
> both
> > > > > streams
> > > > > > > that
> > > > > > > > > > > have
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > > >> > > > active, I see this as a blocker,
> as
> > > there
> > > > > are
> > > > > > > > > > > > > contributions
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > >> > > > cannot be done, given that
> Category A
> > > > > depends
> > > > > > > on
> > > > > > > > > > > > Category
> > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal,
> can be
> > > > > > > understood
> > > > > > > > > as
> > > > > > > > > > > > > > technical
> > > > > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > > > > >> > > > Depending on unmaintained
> projects is
> > > > > > > something
> > > > > > > > > > we'll
> > > > > > > > > > > > > always
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as
> it's
> > > > > just a
> > > > > > > > > matter
> > > > > > > > > > of
> > > > > > > > > > > > > > making
> > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > P7 is an isolated problem that
> won't
> > > > > impact
> > > > > > > the
> > > > > > > > > > > > structure
> > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > > > > >> > > > that we're talking about here,
> but it
> > > is a
> > > > > > > > > > regression
> > > > > > > > > > > we
> > > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored
> for
> > > > > Apache
> > > > > > > KIE
> > > > > > > > > 10,
> > > > > > > > > > > and
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only
> > > problems
> > > > > > > left to
> > > > > > > > > > > > discuss
> > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > >> > > > P2, which can't be done without a
> > > proper
> > > > > > > proposal.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > I'll try to be very meticulous
> here,
> > > since
> > > > > > > from my
> > > > > > > > > > > > > > experience,
> > > > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > > > >> > > > little miscalculation can lead to
> our
> > > > > release
> > > > > > > not
> > > > > > > > > > > > working
> > > > > > > > > > > > > > out
> > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > >> > > > end. To try and avoid that as
> much as
> > > > > > > possible,
> > > > > > > > > and
> > > > > > > > > > > make
> > > > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > >> > > > can to have a successful Apache
> KIE 10
> > > > > > > release,
> > > > > > > > > bear
> > > > > > > > > > > > with
> > > > > > > > > > > > > > me.
> > > > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > > > > >> > > > out a timeline of events that
> need to
> > > > > happen
> > > > > > > in
> > > > > > > > > > order
> > > > > > > > > > > > for
> > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > > > > >> > > > to be published, with all
> artifacts
> > > > > ending up
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > > right
> > > > > > > > > > > > > > > > places,
> > > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > > >> > > > first, we need to solve problems
> P1
> > > and
> > > > > P2.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > As you saw at the beginning of
> this
> > > email,
> > > > > > > all the
> > > > > > > > > > > > > attempts
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > made
> > > > > > > > > > > > > > > > > >> > > > left us with the circular
> dependency
> > > > > showing
> > > > > > > up
> > > > > > > > > at a
> > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > > > > >> > > > but something all these places
> have in
> > > > > common
> > > > > > > is
> > > > > > > > > > that
> > > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > >> > > > after kogito-apps, and before to
> > > Category
> > > > > B.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > The first part of my proposal is
> the
> > > > > > > following:
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > S1. We keep the original plan of
> > > moving
> > > > > the
> > > > > > > > > Quarkus
> > > > > > > > > > > Dev
> > > > > > > > > > > > > UIs
> > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`,
> together
> > > > > with
> > > > > > > > > > Management
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > Task
> > > > > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > >> > > > S2. We move the
> `kogito-swf-devmode`
> > > and
> > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > > >> > > > from `kogito-images` to
> `kie-tools`
> > > too.
> > > > > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > > > > `kogito-serverless-operator`
> > > > > > > > > > > repo
> > > > > > > > > > > > > > > inside
> > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping
> Git
> > > > > history.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together
> > > solve
> > > > > > > problems
> > > > > > > > > P1
> > > > > > > > > > > and
> > > > > > > > > > > > > P2.
> > > > > > > > > > > > > > Of
> > > > > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > This doesn't come without
> > > consequences, of
> > > > > > > course,
> > > > > > > > > > as
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > > > > `kogito-swf-builder`
> > > > > > > > > > images,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> would be
> > > > > moving
> > > > > > > from
> > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >> > > > Category B. This move would make
> them
> > > > > have to
> > > > > > > > > > > reference
> > > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > > >> > > > repos through timestamped
> SNAPSHOTs.
> > > Since
> > > > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are
> > > already
> > > > > > > their own
> > > > > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > > > > >> > > > Category A, though, contributions
> > > made in
> > > > > a
> > > > > > > > > > cross-repo
> > > > > > > > > > > > > > fashion
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> > > > > possible, now
> > > > > > > > > via a
> > > > > > > > > > > > > single
> > > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs
> between
> > > > > Category
> > > > > > > A and
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > > B
> > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > >> > > > continue not being possible, and a
> > > 1-week
> > > > > > > delay
> > > > > > > > > > > between
> > > > > > > > > > > > > > > merging
> > > > > > > > > > > > > > > > > >> > > > something on Category A and using
> it
> > > on
> > > > > > > Category B
> > > > > > > > > > > will
> > > > > > > > > > > > > > still
> > > > > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > It's worth mentioning that
> > > `kie-tools`,
> > > > > > > however,
> > > > > > > > > > does
> > > > > > > > > > > > > allow
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > > > > >> > > > checkouts and partial builds, so
> > > working
> > > > > with
> > > > > > > a
> > > > > > > > > > subset
> > > > > > > > > > > > of
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > >> > > > is possible and encouraged. Making
> > > changes
> > > > > > > only to
> > > > > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> > > > > example,
> > > > > > > will
> > > > > > > > > > have
> > > > > > > > > > > > the
> > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can
> see
> > > here:
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > > >> > > > We're not compromising when
> running
> > > > > partial
> > > > > > > builds
> > > > > > > > > > > too.
> > > > > > > > > > > > We
> > > > > > > > > > > > > > > know
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > >> > > > the entire repo will continue
> working
> > > even
> > > > > > > after
> > > > > > > > > > only
> > > > > > > > > > > > > > > building a
> > > > > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > > > > >> > > > subset of the changes. Doing
> partial
> > > or
> > > > > full
> > > > > > > > > builds
> > > > > > > > > > is
> > > > > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> > > > > proposing
> > > > > > > we
> > > > > > > > > > move a
> > > > > > > > > > > > > bunch
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > >> > > > additional stuff into
> `kie-tools`, I
> > > see
> > > > > this
> > > > > > > as a
> > > > > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools`
> would
> > > host
> > > > > some
> > > > > > > > > > > additional
> > > > > > > > > > > > > > stuff
> > > > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can
> release and
> > > > > > > continue
> > > > > > > > > > moving
> > > > > > > > > > > > > > > forward.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > As I mentioned on other places,
> > > > > `kie-tools`
> > > > > > > > > became a
> > > > > > > > > > > > > > polyglot
> > > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > > >> > > > out of necessity, and although I'm
> > > really
> > > > > > > proud of
> > > > > > > > > > > what
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > > > > >> > > > there so far, I don't think
> > > `kie-tools`
> > > > > has a
> > > > > > > > > setup
> > > > > > > > > > > that
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > > > > >> > > > for all the different nuances that
> > > > > compose our
> > > > > > > > > > > > community.
> > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo
> that
> > > does
> > > > > not
> > > > > > > > > follow
> > > > > > > > > > > > > > widespread
> > > > > > > > > > > > > > > > > >> > > > conventions will scare some people
> > > away,
> > > > > and
> > > > > > > as
> > > > > > > > > much
> > > > > > > > > > > as
> > > > > > > > > > > > > > we've
> > > > > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > >> > > > make build instructions clear, we
> > > can't
> > > > > > > always get
> > > > > > > > > > > past
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > > > > >> > > > some people have towards the
> > > "front-end"
> > > > > > > > > ecosystem.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > With all that said, I keep
> thinking
> > > this
> > > > > is
> > > > > > > the
> > > > > > > > > best
> > > > > > > > > > > > > course
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > > > > >> > > > for us right now. We keep most of
> our
> > > > > stuff
> > > > > > > > > > unchanged,
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > >> > > > release, and we have a working
> setup
> > > that
> > > > > will
> > > > > > > > > suit
> > > > > > > > > > us
> > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > >> > > > discuss and reach a conclusion
> > > regarding
> > > > > the
> > > > > > > > > future
> > > > > > > > > > of
> > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Let me paint a quick picture here
> of
> > > what
> > > > > our
> > > > > > > code
> > > > > > > > > > > base
> > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > > > >> > > > like, repository-wise, if my
> proposal
> > > is
> > > > > > > accepted:
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > > > > > >> > > > A
> incubator-kie-optaplanner
> > > > > > > > > > > > > > > > > >> > > > A
> > > > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-docs
> > > > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > > > > >> > > > A
> incubator-kie-benchmarks
> > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > >> > > > B
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > >> > > > D
> > > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > > > > > >> > > > E
> > > incubator-kie-kogito-website
> > > > > > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > > > > > >> > > > E
> > > incubator-kie-kogito-online
> > > > > > > > > > > > > > > > > >> > > > E
> > > > > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > * Category C becomes part of
> Category
> > > A,
> > > > > and
> > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> > > > > entirely
> > > > > > > inside
> > > > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > > >> > > > * With
> `kogito-swf-{builder,devmode}`
> > > > > images
> > > > > > > and
> > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`
> inside
> > > > > > > `kie-tools`,
> > > > > > > > > > there
> > > > > > > > > > > > are
> > > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`,
> we can
> > > > > > > granularly
> > > > > > > > > > > build:
> > > > > > > > > > > > > > > > > >> > > > 1.
> > > > > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > > >> > > > 2.
> > > packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> > > > > (containing
> > > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > > > > >> > > > 4.
> packages/sonataflow-operator
> > > > > (contents
> > > > > > > from
> > > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > > > > >> > > > 5.
> packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > The second part of the proposal
> is the
> > > > > release
> > > > > > > > > > process
> > > > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > > > >> > > > assuming the structure above is
> what
> > > we
> > > > > have.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT
> to be
> > > > > used as
> > > > > > > > > > cutting
> > > > > > > > > > > > > point
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > > > > >> > > > 2. Update Category B repos to
> point to
> > > > > this
> > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > > > > > >> > > > 3. At this point, with everything
> > > > > working, we
> > > > > > > can
> > > > > > > > > > > branch
> > > > > > > > > > > > > out
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the
> > > timestamped
> > > > > > > SNAPSHOT
> > > > > > > > > > > tag,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > > > > >> > > > 4. All Category A and Category B
> repos
> > > > > update
> > > > > > > > > their
> > > > > > > > > > > > > versions
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x`
> branches.
> > > > > > > > > > > > > > > > > >> > > > 5. Update Category B repos to
> point to
> > > > > > > Category A
> > > > > > > > > > > repos
> > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on
> the
> > > > > release
> > > > > > > based
> > > > > > > > > > on
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > > > > >> > > > branches, given we don't expect
> any
> > > code
> > > > > > > changes
> > > > > > > > > > > > anymore.
> > > > > > > > > > > > > > > > > >> > > > 7. After voting passes, we're
> good to
> > > > > start
> > > > > > > the
> > > > > > > > > > > release
> > > > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > > > > manual/automated
> > > > > > > > > > > > release
> > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch.
> Tags
> > > > > pushed
> > > > > > > to
> > > > > > > > > Git,
> > > > > > > > > > > and
> > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > >> > > > artifacts pushed to their
> registries.
> > > > > > > > > > > > > > > > > >> > > > 9. We wait a little bit for
> Category A
> > > > > > > artifacts
> > > > > > > > > to
> > > > > > > > > > be
> > > > > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > > > > manual/automated
> > > > > > > > > > > > release
> > > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch.
> Tags
> > > > > pushed
> > > > > > > to
> > > > > > > > > Git,
> > > > > > > > > > > and
> > > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > >> > > > artifacts pushed to their
> registries.
> > > > > > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > > > > > >> > > > 12. Category E repos can be
> manually
> > > > > tagged
> > > > > > > with
> > > > > > > > > > > 10.0.0
> > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > More needs to be discussed if
> we're
> > > > > planning
> > > > > > > to
> > > > > > > > > > > maintain
> > > > > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > > > > >> > > > release streams in parallel, but I
> > > guess
> > > > > it
> > > > > > > can
> > > > > > > > > wait
> > > > > > > > > > > for
> > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm
> looking
> > > > > > > forward to
> > > > > > > > > > > > hearing
> > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Of course, alternative solutions
> are
> > > > > possible.
> > > > > > > > > This
> > > > > > > > > > > > email,
> > > > > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > > > > >> > > > summarizes my view of how we
> should
> > > > > attack the
> > > > > > > > > > > problem,
> > > > > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > > > > >> > > > disruption, required effort, the
> > > release
> > > > > > > process
> > > > > > > > > > > itself,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > > > > >> > > > Feel free to propose alternatives.
> > > This is
> > > > > > > not a
> > > > > > > > > > > voting
> > > > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Tiago Bento <ti...@gmail.com>.
Francisco,
I agree with you that both reasonings are not antagonistic, as an
antagonistic reasoning in this case would be one that doesn't work.
And I believe it is clear now that the initial proposal shared on this
email thread does work, but it is not the only possibility. From the
beginning I said there are alternatives, but I wanted to start the
conversation from my point of view, sharing what I think is best. We
have to acknowledge, though, IMHO, that the discussions we had thus
far cannot be understood as clearly as what was initially laid out,
given the lack of details/analysis and a clear execution plan.
Let me elaborate on top of the 3-step plan you shared.
1)
No comment. This should be pretty simple to do.
2)
There is no global CI stream to be changed, we would have to create
one. And this has serious implications to our contribution model for
cross-repo PRs. As I described on the first email of this thread,
Category A repos are configured in several disjoint streams. Sending a
PR to `drools` and `kogito-runtimes` will work great, but sending a PR
to `drools` and `kogito-images`, or `drools` and `optaplanner` won't
verify that everything will continue working after the PRs are merged,
as our PR checks are not prepared to build this combination of repos
together. This is a problem, in my view, but I hardly contribute to
Category A repos, so I'm assuming things are working fine for those
who do. The proposal shared on the first email of this thread does not
change the contribution workflow for any repo of Apache KIE, and
everyone can continue contributing the way they're used to, except for
people contributing to the `kogito-swf-{builder,devmode}` images, and
to `kogito-serverless-operator`. On the other hand, having `kie-tools`
built in the middle of a new global CI stream, would span another
class of problem, which is very closely related to the third bullet
point of the plan you shared.
3)
Maven has a mechanism to achieve this pseudo-synchronicity between
multiple repositories. The mutable SNAPSHOT version, built nightly. It
is not perfect, though, as I'm sure many of us already experienced
pulling from the `main` branch of a single repo only to find out that
a PR ensemble had been merged a few moments prior, requiring us to
rebuild the entire stack, since our local SNAPSHOTs had become
out-of-date. That's what we used to have back in Business Central
(a.k.a. v7) days. Making a `git pull` on a single repo in this setup
potentially requires all repos to be pulled and rebuilt. I'm sure this
still happens sometimes when developing Category A projects.
NPM packages don't have mutable SNAPSHOTs. Every published NPM package
is immutable, and it is really cumbersome and error-prone to integrate
downstream repos with upstream NPM-bound repos, as not having a
lockfile brings all sorts of security and stability problems. That's
why monorepos became so popular in the JavaScript ecosystem. This lack
of a mutable SNAPSHOT mechanism makes depending on NPM artifacts
coming from `kie-tools` really hard. The way I see it, moving repos
downstream of `kie-tools` will require everyone to build `kie-tools`
anyway, potentially on a daily basis, since it would've then become
part of the stack that needs to be built before `kogito-images` and
`kogito-serverless-operator`. More than that, since there would be no
way to determine what subset of packages of `kie-tools` would need to
be built to satisfy downstream references, everyone would have to do a
full build, or handpick individual packages of the monorepo to build.
I hope I was able to offer more insight in the way I see things, along
with my take on using Maven SNAPSHOTs as the de-facto solution for a
poly-repo codebase. I don't think we can escape from the complexity of
our codebase and the nature of the technologies we use, only
accommodate it in the most comfortable place possible, if even there
is such a place :)
Now, there are some things I'd like to say regarding the initial
proposal shared on this email thread.
I understand you, and others, are concerned about moving stuff into
`kie-tools` for some reasons I could gather from your messages. I'll
try and list them here, along with my perspective on each of them.
1. Never being able to move them out of `kie-tools` again.
This is going to be as hard as it would be removing
`kn-plugin-workflow` from it now. So, as you and others mentioned this
possibility, I assume you understand it to be doable.
2. "Heterodoxizing" an orthodox repository
(`kogito-serverless-operator`), potentially harming external
contributions.
Agree with this point. `kie-tools` is one of a kind, built around
front-end tooling with some completely unique in-house apparatus. In
my experience, though, there are a multitude of factors that make
people want to contribute to an open source project. Conformance to
well-known widespread technologies and tools is just one of them.
Being open about it and writing material to smooth out those edges can
work pretty well. People do not contribute because a codebase is
"pure". People contribute because they care about the project. And I'm
always surprised by the lengths people go to when they want to get
involved.
3. Disruption to the contribution workflow of those contributing to
`kogito-swf-{builder,devmode}` images, and to
`kogito-serverless-operator`.
It is clear to me now that we can't unblock and release Apache KIE 10
without impacting anyone, but I hope the first part of this reply
sheds some light on this complicated matter.
Anyway, that's my attempt to offer a different perspective to some of
the problems you expressed concern about, perhaps even making the
initial proposal shared on this email thread be seen with less
uncertainty.
On Wed, Mar 13, 2024 at 11:40 AM Francisco Javier Tirado Sarti
<ft...@redhat.com> wrote:
>
> Tiago,
> Unfortunately, my plan is too conceptually simple to write more than I
> already wrote.
> 1) Move kn-plugin-workflow module to operator repo (this remove the
> dependency between tools and operator, breaking the loop)
> 2) Change CI global stream to execute tooling repo before operator repo
> (this seems to take 2 months unless Tristan helps and reduce the time to 2
> weeks)
> 3) Optionally, and just as a consequence of that CI change, set
> 999-SNAPSHOT version to all poms in all repos (if current snapshot numbers
> turns out to be a problem, in any case this is just search-replace)
>
> The current plan is:
> 1) Move everything depending on tools to tools repo, which includes
> operator code and examples.
> 2) Change CI of tooling repo to enforce dependencies between the existing
> modules there and the newly moved ones (this seems to take 3 weeks or less)
>
> I think rather than asking for a more detailed alternative, what needs to
> be done is to refine the existing proposal with the feedback received. I do
> not think both proposals are antagonistic. I think that, being now clear we
> have the same overall goal (execute tooling before operator), it is just a
> question of deciding between move more stuff to an already heterodox repo,
> coming from repos not as heterodox, plus changing the repo CI to impose
> certain order between these modules or pull out the the operator stuff from
> tool repo and put it inside the operator repo plus changing the CI
> handling repos to impose the desired order: first tooling and then operator.
>
> On Wed, Mar 13, 2024 at 4:12 PM Tiago Bento <ti...@gmail.com>
> wrote:
>
> > Francisco,
> >
> > 1) `kie-tools` is already a heterodox repo. The reason why I proposed
> > my proposal is because it is what I think is the best course of action
> > for our community right now. If you think there's a better way to do
> > it, I think everyone, including me, needs to see a proposal with a
> > clear execution plan with a comparable level of detail and analysis in
> > regards to disruption of the current state, the required effort, the
> > contribution workflow for cross-repo PRs, and the release process
> > itself. Otherwise, we risk having gaps that each person will fill in a
> > different way, and IMHO, that's where problems happen. +1 for examples
> > unification, btw :)
> >
> > 2) Ok, and +1 for no categorization.
> >
> > On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado Sarti
> > <ft...@redhat.com> wrote:
> > >
> > > 1) Ok, if that is the case, I do not get why your first proposal was not
> > > the one I'm proposing and it is apparently not detailed enough. To move
> > > kn-workflow from tooling to operator one and change the order in which
> > the
> > > repos are being processed. Basically, the problem of the proposed
> > solution
> > > is that it kind of converts tooling repo into a pretty heterodox repo
> > > compared with runtimes, drools or operator one. Also once tooling is not
> > a
> > > final repo in the overall chain, we can consider moving examples as the
> > > final one and include tooling showcases there (rather than splitting
> > > examples into examples with tooling and examples without tooling).
> > > 2) I think this distinction between A and B is one between several
> > possible
> > > categorizations (not much, including no categorization at all) that
> > > deserves a separate discussion. I will open a separate thread for that
> > > purpose, since we are not going to change that now and it is not really
> > > part of the proposal.
> > >
> > > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
> > tiagobentofernandes@gmail.com>
> > > wrote:
> > >
> > > > Francisco,
> > > >
> > > > 1) That's what this thread is all about... You know I don't think it's
> > > > ok. That's why I'm proposing the two images and the operator to move
> > > > into the `kie-tools` repo, where we can more granularly control the
> > > > order things are built, thus removing the dependency cycle.
> > > >
> > > > 2) Not sure we understand the same thing by "freeze". My proposal is
> > > > that we select a timestamped SNAPSHOT version from Category A repos to
> > > > use as base for a release. We give Category B repos some time to
> > > > adjust, and then cut the release branches. This can happen anytime,
> > > > and no contributions would ever stop because of it. The development
> > > > branches can continue accepting PRs normally, even during the release
> > > > process. Now, if what you're asking is why Category B repos refer to
> > > > Category A repos via timestamped SNAPSHOTs, the answer is in my first
> > > > email. See the paragraph starting with "An important note here is that
> > > > Category B repositories...".
> > > >
> > > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti
> > > > <ft...@redhat.com> wrote:
> > > > >
> > > > > Tiago
> > > > > There are a couple of simple and straightforward questions that I
> > > > > formulated, but since we both write a lot, it might have been lost.
> > > > Please
> > > > > let me ask them again.
> > > > > 1) Do you think it is ok that tools repo is executed after
> > generation of
> > > > > docker images that are supposed to include those tools or the
> > operator
> > > > that
> > > > > is supposed to deploy such images?
> > > > That's what this thread is all about... You know I'm not ok with it,
> > > > that's why I'm proposing the two images and the operator to move into
> > > > the `kie-tools` repo, where we can more granularly control the order
> > > > things are built and remove the dependency cycle.
> > > > > 2) Besides that, although not directly related with the current
> > proposal
> > > > we
> > > > > are discussing, I really think there are some restrictions taken for
> > > > > granted that are arbitrary and difficult to sustain on strictly
> > technical
> > > > > arguments. For example, the need to freeze the rest of the software
> > > > before
> > > > > tools are generated. Why? We have dependencies between repos that
> > are not
> > > > > handled that way: Apps depend on runtimes. Runtimes depend on drools,
> > > > > Operator depend on runtimes,....and we are not freezing that repos
> > since
> > > > we
> > > > > are all releasing at the same time. If we are all releasing at the
> > same
> > > > > time, what's the rationale behind the freeze?
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <ti...@apache.org>
> > > > wrote:
> > > > >
> > > > > > Glad to see the interest this proposal has gotten, and it's good to
> > > > > > see some alternatives being drafted here, although still lacking
> > clear
> > > > > > definitions and analysis in regards to disruption, required effort,
> > > > > > the release process itself, and history. Of course, lots of details
> > > > > > and clarity on the execution part would be missing too.
> > > > > >
> > > > > > As of this moment, based on what I read here, I'm assuming that
> > > > > > everyone who participated so far doesn't see the initial proposal
> > as
> > > > > > problematic in terms of feasibility, but some of you have a
> > preference
> > > > > > not to go with it, because it is "wrong", and apparently because it
> > > > > > would "jeopardize the evolution of the project". Reading these last
> > > > > > words made me a little sad, to be honest. But I can deal with it :)
> > > > > >
> > > > > > Please let's try and keep the discussion as objective as possible.
> > > > > > "Right" and "wrong" are too subjective for this kind of
> > conversation.
> > > > > >
> > > > > > Now, being practical, unless there are clear arguments based on
> > facts
> > > > > > and objective concepts that invalidate the initial proposal shared
> > on
> > > > > > this email, it seems to me that it is currently the only viable
> > > > > > proposal we have for unblocking and releasing Apache KIE 10. Of
> > > > > > course, if we end up seeing an alternative proposal with enough
> > > > > > details and a clear execution plan, I think then we'll be in a very
> > > > > > good position to choose from multiple options!
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <al...@porcelli.me>
> > > > wrote:
> > > > > > >
> > > > > > > Francisco and Gabriele,
> > > > > > >
> > > > > > > I understand and acknowledge your desire to find the “right”
> > solution
> > > > > > > instead to work on a temporary “patch” - however without a
> > detailed
> > > > > > > proposal I don’t think we can properly evaluate the impact of
> > your
> > > > > > > suggestion.
> > > > > > >
> > > > > > > When I spoke with different SMEs that included tools and CI, the
> > > > > > > guesstimate for making the necessary changes on CI and codebase
> > to
> > > > > > > basically have images and operators in the end of the build
> > chain is
> > > > > > > something like 2 months of effort. Another impact that needs to
> > be
> > > > > > > discussed is that KIE Tools repo had to be injected in the
> > middle of
> > > > all
> > > > > > > pipelines - forcing all PR checks and nightlies to build all
> > repos
> > > > (PR
> > > > > > > checks will likely take 12+ hours… I even heard that it could be
> > > > even 24
> > > > > > > hours).
> > > > > > >
> > > > > > > Based on the input above, I think it’s quite risk to move in such
> > > > > > direction
> > > > > > > without a more detailed plan… because 2 months could be turned
> > > > easily in
> > > > > > 6!
> > > > > > > And this is exactly what happened when we guessed that moving to
> > > > Apache
> > > > > > > would take no more than 3 months. But here we are.
> > > > > > >
> > > > > > > I really strongly suggest that we focus on a release that could
> > be
> > > > > > > achievable in less than a month from now, and we - after release
> > -
> > > > have a
> > > > > > > in depth discussion about the overall codebase and ci
> > organization.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > > gabriele.cardosi@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Alex,
> > > > > > > > my suggestion is to move the building of all docker images,
> > from
> > > > > > whatever
> > > > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo,
> > to
> > > > be
> > > > > > > > invoked after all the others.
> > > > > > > > I'm not sure if this would solve all the issues, and since I
> > could
> > > > not
> > > > > > > > enter in the details of all the involved code, my suggestion
> > may
> > > > be too
> > > > > > > > naive.
> > > > > > > > Having spent almost all of the last year in CI, I may say
> > that, at
> > > > > > least
> > > > > > > > for the kie-tools repo, removing the image build step from it
> > > > should
> > > > > > not be
> > > > > > > > too difficult (since it is an issue we already faced and
> > solved).
> > > > > > > > If, with "detailed proposal", you mean a complete list of all
> > > > modules
> > > > > > to be
> > > > > > > > moved and dependency refactoring, of course I can not provide
> > it
> > > > right
> > > > > > now.
> > > > > > > >
> > > > > > > > Anyway, I share the concern from Francisco: undoing something
> > is
> > > > almost
> > > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier
> > Tirado
> > > > Sarti
> > > > > > <
> > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > >
> > > > > > > > > I do not think estimations should be the only driver to make
> > a
> > > > > > decision,
> > > > > > > > > especially when the current proposal is conceptually
> > incompatible
> > > > > > with
> > > > > > > > the
> > > > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > > > Given my knowledge of the CI it is nearly impossible for me
> > to
> > > > give
> > > > > > a
> > > > > > > > fair
> > > > > > > > > estimate of how much it might take to achieve step 2) of my
> > > > previous
> > > > > > > > e-mail
> > > > > > > > > . It might take a while or it might be pretty easy after
> > all, I
> > > > don't
> > > > > > > > > really know, but I think it will be a good idea if some of
> > the
> > > > > > experts
> > > > > > > > on
> > > > > > > > > CI in the team (the ones that set up the pipeline, which was
> > a
> > > > huge
> > > > > > > > > achievement) give an estimate, not me. Estimating how much
> > it
> > > > takes
> > > > > > to
> > > > > > > > > merge two existing repos (without altering CI) is easier,
> > but it
> > > > > > does not
> > > > > > > > > mean we are doing the right thing.
> > > > > > > > > My main concern is that it will be very difficult for me to
> > > > explain
> > > > > > to
> > > > > > > > > someone that arrives new to the team, that having experts on
> > CI
> > > > on
> > > > > > the
> > > > > > > > > team, we decided to merge two repos (once merged, it would be
> > > > rather
> > > > > > > > > difficult to unmerge) rather than fix the CI, because of
> > > > expediency.
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > > porcelli@apache.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco,
> > > > > > > > > >
> > > > > > > > > > Please take the time to make the more in depth analysis
> > needed
> > > > and
> > > > > > > > > provide
> > > > > > > > > > a more detailed plan… so we - as community- can evaluate
> > the
> > > > size
> > > > > > of
> > > > > > > > the
> > > > > > > > > > effort. In the conceptual level you shared it’s near
> > > > impossible to
> > > > > > > > > estimate
> > > > > > > > > > the size of the effort and compare with the current
> > proposal.
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado
> > Sarti <
> > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > > 1) Remove all dependencies from tooling to images, so
> > images
> > > > > > depend
> > > > > > > > on
> > > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > > 2) Then change CI to deal with tooling repo before
> > dealing
> > > > with
> > > > > > > > images
> > > > > > > > > > > repo.
> > > > > > > > > > > I understand that CI details are tricky and since I'm not
> > > > > > familiar
> > > > > > > > with
> > > > > > > > > > CI
> > > > > > > > > > > in any way, I barely can make a low level design, but we
> > do
> > > > not
> > > > > > need
> > > > > > > > to
> > > > > > > > > > fix
> > > > > > > > > > > everything, just achieve 2), a change of compilation
> > order.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > > > alex@porcelli.me
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > > >
> > > > > > > > > > > > You may not like or understand why the current state of
> > > > the CI
> > > > > > is
> > > > > > > > > like
> > > > > > > > > > > > that… actually has been in Red Hat and has been
> > replicated
> > > > in
> > > > > > > > Apache
> > > > > > > > > as
> > > > > > > > > > > > used to be….
> > > > > > > > > > > >
> > > > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > > > >
> > > > > > > > > > > > If you disagree with the current plan, please provide a
> > > > > > detailed
> > > > > > > > > > > > alternative so we, as community, can better evaluate
> > the
> > > > pros
> > > > > > and
> > > > > > > > > cons
> > > > > > > > > > of
> > > > > > > > > > > > each proposal.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I think it’s also fair to say that, post 10 release we
> > > > need to
> > > > > > > > have a
> > > > > > > > > > > much
> > > > > > > > > > > > in depth discussion about how our codebase is
> > organized,
> > > > it’s
> > > > > > clear
> > > > > > > > > > that
> > > > > > > > > > > > it’s not working.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > > I also have the impression that the "images" (if we
> > are
> > > > > > talking
> > > > > > > > of
> > > > > > > > > > > docker
> > > > > > > > > > > > > images) should be the very last one to be built, in a
> > > > > > standalone
> > > > > > > > > > repo.
> > > > > > > > > > > > > That way, they may "combine" artifacts that are
> > built in
> > > > > > > > different
> > > > > > > > > > > repos,
> > > > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > > > Moving them out of all the repos
> > (kogito-apps/kie-tools)
> > > > > > maybe
> > > > > > > > > could
> > > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > > (I also think there are some statements of
> > undisputable
> > > > needs
> > > > > > > > while
> > > > > > > > > > > they
> > > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > > > discussion.)
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco
> > Javier
> > > > > > Tirado
> > > > > > > > > > Sarti
> > > > > > > > > > > <
> > > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > > There are two assumptions that deserve further
> > > > discussion:
> > > > > > > > > > > > > > 1) That tool has to be the last to build. why? it
> > does
> > > > not
> > > > > > have
> > > > > > > > > > more
> > > > > > > > > > > > > sense
> > > > > > > > > > > > > > to build final images after everything else has
> > been
> > > > > > built?-
> > > > > > > > > > > > > > 2) That the impact (in terms of effort now) on
> > fixing
> > > > CI is
> > > > > > > > > bigger
> > > > > > > > > > > than
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > impact (long term consequences) of consolidating
> > two
> > > > > > unrelated
> > > > > > > > > > piece
> > > > > > > > > > > of
> > > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > > > alex@porcelli.me
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This was discussed as an alternative solution,
> > > > however
> > > > > > it has
> > > > > > > > > > major
> > > > > > > > > > > > > > impact
> > > > > > > > > > > > > > > on CI and there’s also the fact Tool has been
> > always
> > > > the
> > > > > > last
> > > > > > > > > to
> > > > > > > > > > > > build
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> > > > world
> > > > > > there
> > > > > > > > > is
> > > > > > > > > > no
> > > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So, based on our evaluation… the proposal here
> > is the
> > > > > > least
> > > > > > > > > > > > disruptive
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> > > > Tirado
> > > > > > > > Sarti <
> > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > > > embracing
> > > > > > the
> > > > > > > > fact
> > > > > > > > > > > that
> > > > > > > > > > > > > > > > kogito-images depend on kie-tools, because we
> > want
> > > > > > those
> > > > > > > > > images
> > > > > > > > > > > to
> > > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco
> > Javier
> > > > > > Tirado
> > > > > > > > > Sarti
> > > > > > > > > > <
> > > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > > > kn-plugin-workflow
> > > > > > > > > > to
> > > > > > > > > > > > > > > > > kogito-images (so there is not longer
> > dependency
> > > > from
> > > > > > > > tools
> > > > > > > > > > to
> > > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique
> > Gonzalez
> > > > > > > > Martinez
> > > > > > > > > <
> > > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > > > (apache)
> > > > > > <
> > > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >> > I say +1 in order to move forward with
> > the 10.
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex
> > Porcelli <
> > > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> > > I spent the last day or so working
> > closely
> > > > with
> > > > > > > > Tiago,
> > > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > > >> > > options and getting deeper on the
> > impact and
> > > > > > > > > evaluating
> > > > > > > > > > > the
> > > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > > >> > > procedure steps required. I agree with
> > the
> > > > > > proposal
> > > > > > > > as
> > > > > > > > > > the
> > > > > > > > > > > > > most
> > > > > > > > > > > > > > > > >> > > viable option for unblocking the 10
> > release
> > > > in
> > > > > > the
> > > > > > > > > > > > reasonable
> > > > > > > > > > > > > > time
> > > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago
> > Bento
> > > > <
> > > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> > > > time,
> > > > > > as
> > > > > > > > this
> > > > > > > > > > > > matter
> > > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes
> > to
> > > > read,
> > > > > > > > > > according
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > > > thread
> > > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > > >
> > > > > > > > >
> > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > > >> > > > many of us were working towards
> > removing a
> > > > > > > > circular
> > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > >> > > > currently present between
> > `kogito-apps`
> > > > and
> > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > As
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > > > > > finding the
> > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > > > breakdown of
> > > > > > the
> > > > > > > > > > things
> > > > > > > > > > > > we
> > > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Right now, even though we started the
> > > > effort
> > > > > > to
> > > > > > > > move
> > > > > > > > > > the
> > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't
> > been
> > > > > > able to
> > > > > > > > > do
> > > > > > > > > > it
> > > > > > > > > > > > > yet,
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java
> > 17,
> > > > > > Maven
> > > > > > > > > 3.9.6,
> > > > > > > > > > > and
> > > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > > .
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > >> > > > |==> 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > >> > > > L |
> > ==========================
> > > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/extended-services
> > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > > > > `kie-tools`,
> > > > > > > > we
> > > > > > > > > > > > would've
> > > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > >> > > > 02.
> > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > * As
> > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > > >> > > > * and
> > > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > > depends
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> > > > image to
> > > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > 01.
> > > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > >> > > > 02.
> > > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > >> > > > 03.
> > > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > >> > > > 04.
> > > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > * As
> > > > `kie-tools`/kn-plugin-workflow
> > > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > > >> > > > * and
> > `kogito-serverless-operator`
> > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> > > > than a
> > > > > > > > simple
> > > > > > > > > > > > > circular
> > > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > After multiple conversations with a
> > lot of
> > > > > > people,
> > > > > > > > > > it's
> > > > > > > > > > > > been
> > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > >> > > > hard coming up with a simple solution
> > that
> > > > > > makes
> > > > > > > > it
> > > > > > > > > > > > possible
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while
> > preserving
> > > > the
> > > > > > way
> > > > > > > > > > > everyone
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > contributing to the multiple
> > repositories
> > > > we
> > > > > > have.
> > > > > > > > > > More
> > > > > > > > > > > > than
> > > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > > >> > > > while making this assessment, I found
> > more
> > > > > > > > problems
> > > > > > > > > > > that,
> > > > > > > > > > > > in
> > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm
> > coming
> > > > > > forward
> > > > > > > > with
> > > > > > > > > > my
> > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we
> > can
> > > > use
> > > > > > > > > Apache's
> > > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate
> > about
> > > > > > this
> > > > > > > > > really
> > > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective
> > about
> > > > the
> > > > > > > > current
> > > > > > > > > > > > > situation
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > > > currently
> > > > > > see.
> > > > > > > > > > I'll
> > > > > > > > > > > > > start
> > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > > > > purposes,
> > > > > > > > > point
> > > > > > > > > > > out
> > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > >> > > > problems that I believe are blocking
> > our
> > > > 10
> > > > > > > > release,
> > > > > > > > > > > > explain
> > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > > >> > > > proposal and discuss some
> > consequences to
> > > > > > what I'm
> > > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO
> > (count:
> > > > 11)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @
> > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > > > >> > > > -
> > incubator-kie-optaplanner-quickstarts @
> > > > > > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @
> > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @
> > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-kogito-serverless-operator @
> > > > > > > > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > > >> > > > -
> > > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @
> > `main`
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > > > updated @
> > > > > > > > `main`.
> > > > > > > > > > > Same
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @
> > `main`
> > > > > > > > > > > > > > > > >> > > > (The Kogito website. Develop &
> > deploy
> > > > at
> > > > > > the
> > > > > > > > > > `main`
> > > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > > > >> > > > (The KIE website. Develop @
> > `main`.
> > > > Push @
> > > > > > > > > > `deploy`
> > > > > > > > > > > to
> > > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> > `gh-pages`
> > > > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > > > sandbox.kie.org
> > > > > > > > and
> > > > > > > > > > KIE
> > > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging
> > @
> > > > `main`
> > > > > > > > > > > > > > > > >> > > > (Same as above, but for manual
> > sanity
> > > > > > checks
> > > > > > > > > > during
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > I grouped the repositories by
> > category,
> > > > and
> > > > > > listed
> > > > > > > > > > them
> > > > > > > > > > > > in a
> > > > > > > > > > > > > > > > >> > > > topological order. Keep in mind that
> > when
> > > > > > > > flattening
> > > > > > > > > > > out a
> > > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > > >> > > > are multiple possibilities. For
> > example,
> > > > > > > > OptaPlanner
> > > > > > > > > > > > > could've
> > > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > > > referring
> > > > > > to
> > > > > > > > as
> > > > > > > > > > > > `drools`
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> > OptaPlanner
> > > > is
> > > > > > inside
> > > > > > > > > > that
> > > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > >> > > > way these repositories reference each
> > > > other
> > > > > > are
> > > > > > > > > > through
> > > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > > > 999-SNAPSHOT
> > > > > > > > > > version.
> > > > > > > > > > > > This
> > > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > > >> > > > is well-known to the team, and
> > although
> > > > > > flawed for
> > > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > > > different
> > > > > > time
> > > > > > > > > > zones,
> > > > > > > > > > > it
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> > > > with, I
> > > > > > > > > assume.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Contributions made to Category A have
> > some
> > > > > > > > dedicated
> > > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> > > > build
> > > > > > > > > cross-repo
> > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > >> > > > and verify that the codebase will
> > continue
> > > > > > working
> > > > > > > > > as
> > > > > > > > > > > > > expected
> > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > > > gather,
> > > > > > > > there
> > > > > > > > > > are
> > > > > > > > > > > > some
> > > > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > > > cross-repo
> > > > > > > > > PRs.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> > kogito-apps,
> > > > and
> > > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > > >> > > > - optaplanner, and
> > optaplanner-quickstarts
> > > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > This means that sending cross-repo
> > PRs to
> > > > any
> > > > > > > > > > > combination
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > >> > > > that are not part of the same
> > "sub-stream"
> > > > > > cannot
> > > > > > > > be
> > > > > > > > > > > > > verified
> > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > > > > dependent
> > > > > > > > on
> > > > > > > > > > > > > individual
> > > > > > > > > > > > > > > > >> > > > contributors building stuff on their
> > > > machines
> > > > > > to
> > > > > > > > > > verify
> > > > > > > > > > > > that
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with
> > these
> > > > > > > > > pipelines,
> > > > > > > > > > so
> > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > > > referring
> > > > > > to
> > > > > > > > as
> > > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > > >> > > > stream. The first repo there is a
> > template
> > > > > > > > > repository
> > > > > > > > > > > that
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > > >> > > > people starting projects from scratch
> > on
> > > > KIE
> > > > > > > > > Sandbox,
> > > > > > > > > > > > > similar
> > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The
> > other
> > > > one
> > > > > > is the
> > > > > > > > > KIE
> > > > > > > > > > > > Tools
> > > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> > > > build
> > > > > > > > system.
> > > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > > > > TypeScript
> > > > > > > > > > > libraries
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts.
> > The
> > > > > > > > > `kie-tools`
> > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > >> > > > configured to work with sparse
> > checkouts
> > > > and
> > > > > > can
> > > > > > > > do
> > > > > > > > > > > > partial
> > > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > > >> > > > Category B repos refer to Category A
> > repos
> > > > > > through
> > > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > > > recently
> > > > > > > > > > > introduced
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > >> > > > build and publish immutable,
> > persistent
> > > > > > artifacts
> > > > > > > > > > under
> > > > > > > > > > > a
> > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> > > > format,
> > > > > > > > > published
> > > > > > > > > > > > weekly
> > > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs
> > are an
> > > > > > > > evolution
> > > > > > > > > > to
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > > > release
> > > > > > for
> > > > > > > > all
> > > > > > > > > > of
> > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > An important note here is that
> > Category B
> > > > > > > > > repositories
> > > > > > > > > > > > have
> > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > > >> > > > historically kept out of any
> > automations
> > > > we
> > > > > > used
> > > > > > > > to
> > > > > > > > > > > have,
> > > > > > > > > > > > > way
> > > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > > > Business
> > > > > > > > Central
> > > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > > >> > > > still going on. For this reason,
> > Category
> > > > B
> > > > > > > > projects
> > > > > > > > > > > have
> > > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > > > > Actions.
> > > > > > > > > > > Category B
> > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > > >> > > > always depended on Category A repos
> > using
> > > > > > fixed
> > > > > > > > > > > versions.
> > > > > > > > > > > > If
> > > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > > > SNAPSHOTs,
> > > > > > > > breaking
> > > > > > > > > > > > changes
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > Category A repositories would've had
> > the
> > > > > > potential
> > > > > > > > > to
> > > > > > > > > > > > break
> > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > >> > > > silently, leaving Category B with a
> > broken
> > > > > > > > > development
> > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > > > > maintainers
> > > > > > > > of
> > > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > > >> > > > as historically Category A
> > contributors
> > > > were
> > > > > > not
> > > > > > > > > > > familiar
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Contributions made to Category B
> > repos go
> > > > > > through
> > > > > > > > a
> > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > > >> > > > workflow that builds the relevant
> > part of
> > > > the
> > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > >> > > > the changes introduced. Changes made
> > to
> > > > the
> > > > > > > > pipeline
> > > > > > > > > > > > itself
> > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us
> > to
> > > > do
> > > > > > things
> > > > > > > > > > like
> > > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> > example.
> > > > More
> > > > > > > > > > > > importantly,
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > > > timestamped
> > > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > > >> > > > with the changes necessary to make it
> > stay
> > > > > > green.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > This setup, however, makes it
> > impossible
> > > > to
> > > > > > have
> > > > > > > > > > > > cross-repo
> > > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > > > simultaneously,
> > > > > > > > > > with
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > > > around,
> > > > > > and
> > > > > > > > > I'm
> > > > > > > > > > > not
> > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > > > Regardless,
> > > > > > > > as
> > > > > > > > > > > > they're
> > > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > > > release,
> > > > > > so I
> > > > > > > > > > > listed
> > > > > > > > > > > > > them
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Category D is self explanatory.
> > There's
> > > > only
> > > > > > one
> > > > > > > > > repo
> > > > > > > > > > > that
> > > > > > > > > > > > > has
> > > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Category E are repos that do not host
> > code
> > > > > > > > directly,
> > > > > > > > > > and
> > > > > > > > > > > > are
> > > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > > >> > > > organizational entities, or host
> > websites,
> > > > > > that
> > > > > > > > > > > currently
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > This lack of unification between
> > Category
> > > > A
> > > > > > and
> > > > > > > > > > > Category B
> > > > > > > > > > > > > is,
> > > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> > infamous
> > > > > > circular
> > > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which
> > we
> > > > now
> > > > > > can
> > > > > > > > > > describe
> > > > > > > > > > > > as
> > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > > >> > > > dependency between Category A and
> > > > Category B.
> > > > > > The
> > > > > > > > > way
> > > > > > > > > > I
> > > > > > > > > > > > see
> > > > > > > > > > > > > > it,
> > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > >> > > > had a single pipeline, building
> > everything
> > > > > > from
> > > > > > > > > > `drools`
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> > > > been
> > > > > > > > > > introduced,
> > > > > > > > > > > > and
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem
> > in
> > > > our
> > > > > > hands
> > > > > > > > > > right
> > > > > > > > > > > > now.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > > > process
> > > > > > > > sees
> > > > > > > > > > this
> > > > > > > > > > > > > lack
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > >> > > > unification as a central problem, not
> > > > only for
> > > > > > > > this
> > > > > > > > > > > > release
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > >> > > > particular, but for the community as a
> > > > whole.
> > > > > > It
> > > > > > > > is
> > > > > > > > > my
> > > > > > > > > > > > > belief
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > >> > > > are all under the same roof, and that
> > no
> > > > > > > > > contribution
> > > > > > > > > > > > should
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > >> > > > allowed to break any part of our
> > codebase.
> > > > > > With
> > > > > > > > the
> > > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > > > contributors
> > > > > > too,
> > > > > > > > > we
> > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> > > > breaking
> > > > > > > > things.
> > > > > > > > > > > We're
> > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > > > > mechanisms in
> > > > > > > > > > place
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> > > > Especially
> > > > > > when
> > > > > > > > > > these
> > > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > > >> > > > impact on parts of the codebase that
> > we,
> > > > > > > > > individually,
> > > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > > > depending
> > > > > > on
> > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > > > > `kogito-images`
> > > > > > > > > > > > > depending
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools`
> > depending on
> > > > > > > > > kiegroup's
> > > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > > > > depending on
> > > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > > > > codebase
> > > > > > > > > here:
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > > > ,
> > > > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > > > OptaPlanner,
> > > > > > > > > > > > pointing
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > older
> > > > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > P5.
> > > > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > > > depending
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> > `2.15.3.Final`.
> > > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > P6. Category C repos are out of date
> > and
> > > > not
> > > > > > part
> > > > > > > > of
> > > > > > > > > > the
> > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> > > > (Current
> > > > > > > > version
> > > > > > > > > is
> > > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > > > > version,
> > > > > > > > only
> > > > > > > > > > by
> > > > > > > > > > > > > using
> > > > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> > > > version
> > > > > > is
> > > > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > > > > OptaPlanner
> > > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > P7.
> > > > `kie-tools`/packages/kn-plugin-workflow
> > > > > > has
> > > > > > > > its
> > > > > > > > > > E2E
> > > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the
> > same
> > > > > > > > solution,
> > > > > > > > > > as
> > > > > > > > > > > > they
> > > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > > >> > > > suffer from the circular dependency
> > > > between
> > > > > > > > > Category A
> > > > > > > > > > > and
> > > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > > > >> > > > As Category A and Category B are both
> > > > streams
> > > > > > that
> > > > > > > > > > have
> > > > > > > > > > > > been
> > > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > > >> > > > active, I see this as a blocker, as
> > there
> > > > are
> > > > > > > > > > > > contributions
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> > > > depends
> > > > > > on
> > > > > > > > > > > Category
> > > > > > > > > > > > B
> > > > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > > > > understood
> > > > > > > > as
> > > > > > > > > > > > > technical
> > > > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > > > > something
> > > > > > > > > we'll
> > > > > > > > > > > > always
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> > > > just a
> > > > > > > > matter
> > > > > > > > > of
> > > > > > > > > > > > > making
> > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> > > > impact
> > > > > > the
> > > > > > > > > > > structure
> > > > > > > > > > > > or
> > > > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > > > >> > > > that we're talking about here, but it
> > is a
> > > > > > > > > regression
> > > > > > > > > > we
> > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> > > > Apache
> > > > > > KIE
> > > > > > > > 10,
> > > > > > > > > > and
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only
> > problems
> > > > > > left to
> > > > > > > > > > > discuss
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >> > > > P2, which can't be done without a
> > proper
> > > > > > proposal.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > I'll try to be very meticulous here,
> > since
> > > > > > from my
> > > > > > > > > > > > > experience,
> > > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> > > > release
> > > > > > not
> > > > > > > > > > > working
> > > > > > > > > > > > > out
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > > > > possible,
> > > > > > > > and
> > > > > > > > > > make
> > > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > > > > release,
> > > > > > > > bear
> > > > > > > > > > > with
> > > > > > > > > > > > > me.
> > > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > > > >> > > > out a timeline of events that need to
> > > > happen
> > > > > > in
> > > > > > > > > order
> > > > > > > > > > > for
> > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > > > >> > > > to be published, with all artifacts
> > > > ending up
> > > > > > in
> > > > > > > > the
> > > > > > > > > > > right
> > > > > > > > > > > > > > > places,
> > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > >> > > > first, we need to solve problems P1
> > and
> > > > P2.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > As you saw at the beginning of this
> > email,
> > > > > > all the
> > > > > > > > > > > > attempts
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > made
> > > > > > > > > > > > > > > > >> > > > left us with the circular dependency
> > > > showing
> > > > > > up
> > > > > > > > at a
> > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > > > >> > > > but something all these places have in
> > > > common
> > > > > > is
> > > > > > > > > that
> > > > > > > > > > > > > they're
> > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > >> > > > after kogito-apps, and before to
> > Category
> > > > B.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > > > > following:
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > S1. We keep the original plan of
> > moving
> > > > the
> > > > > > > > Quarkus
> > > > > > > > > > Dev
> > > > > > > > > > > > UIs
> > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> > > > with
> > > > > > > > > Management
> > > > > > > > > > > and
> > > > > > > > > > > > > > Task
> > > > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> > > > `kie-tools`.
> > > > > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode`
> > and
> > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools`
> > too.
> > > > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > > > `kogito-serverless-operator`
> > > > > > > > > > repo
> > > > > > > > > > > > > > inside
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> > > > history.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together
> > solve
> > > > > > problems
> > > > > > > > P1
> > > > > > > > > > and
> > > > > > > > > > > > P2.
> > > > > > > > > > > > > Of
> > > > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > > > >>
> > > > > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > This doesn't come without
> > consequences, of
> > > > > > course,
> > > > > > > > > as
> > > > > > > > > > > the
> > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > > > `kogito-swf-builder`
> > > > > > > > > images,
> > > > > > > > > > > and
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be
> > > > moving
> > > > > > from
> > > > > > > > > > > > Category A
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > Category B. This move would make them
> > > > have to
> > > > > > > > > > reference
> > > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs.
> > Since
> > > > > > > > > > > `kogito-images`
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are
> > already
> > > > > > their own
> > > > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > > > >> > > > Category A, though, contributions
> > made in
> > > > a
> > > > > > > > > cross-repo
> > > > > > > > > > > > > fashion
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> > > > possible, now
> > > > > > > > via a
> > > > > > > > > > > > single
> > > > > > > > > > > > > PR
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> > > > Category
> > > > > > A and
> > > > > > > > > > > > Category
> > > > > > > > > > > > > B
> > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > >> > > > continue not being possible, and a
> > 1-week
> > > > > > delay
> > > > > > > > > > between
> > > > > > > > > > > > > > merging
> > > > > > > > > > > > > > > > >> > > > something on Category A and using it
> > on
> > > > > > Category B
> > > > > > > > > > will
> > > > > > > > > > > > > still
> > > > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > It's worth mentioning that
> > `kie-tools`,
> > > > > > however,
> > > > > > > > > does
> > > > > > > > > > > > allow
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > > > >> > > > checkouts and partial builds, so
> > working
> > > > with
> > > > > > a
> > > > > > > > > subset
> > > > > > > > > > > of
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > >> > > > is possible and encouraged. Making
> > changes
> > > > > > only to
> > > > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> > > > example,
> > > > > > will
> > > > > > > > > have
> > > > > > > > > > > the
> > > > > > > > > > > > PR
> > > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see
> > here:
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > > >> > > > We're not compromising when running
> > > > partial
> > > > > > builds
> > > > > > > > > > too.
> > > > > > > > > > > We
> > > > > > > > > > > > > > know
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > >> > > > the entire repo will continue working
> > even
> > > > > > after
> > > > > > > > > only
> > > > > > > > > > > > > > building a
> > > > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > > > >> > > > subset of the changes. Doing partial
> > or
> > > > full
> > > > > > > > builds
> > > > > > > > > is
> > > > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> > > > proposing
> > > > > > we
> > > > > > > > > move a
> > > > > > > > > > > > bunch
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I
> > see
> > > > this
> > > > > > as a
> > > > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would
> > host
> > > > some
> > > > > > > > > > additional
> > > > > > > > > > > > > stuff
> > > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > > > > continue
> > > > > > > > > moving
> > > > > > > > > > > > > > forward.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > As I mentioned on other places,
> > > > `kie-tools`
> > > > > > > > became a
> > > > > > > > > > > > > polyglot
> > > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > > >> > > > out of necessity, and although I'm
> > really
> > > > > > proud of
> > > > > > > > > > what
> > > > > > > > > > > we
> > > > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > > > >> > > > there so far, I don't think
> > `kie-tools`
> > > > has a
> > > > > > > > setup
> > > > > > > > > > that
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > > > >> > > > for all the different nuances that
> > > > compose our
> > > > > > > > > > > community.
> > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that
> > does
> > > > not
> > > > > > > > follow
> > > > > > > > > > > > > widespread
> > > > > > > > > > > > > > > > >> > > > conventions will scare some people
> > away,
> > > > and
> > > > > > as
> > > > > > > > much
> > > > > > > > > > as
> > > > > > > > > > > > > we've
> > > > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > >> > > > make build instructions clear, we
> > can't
> > > > > > always get
> > > > > > > > > > past
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > > > >> > > > some people have towards the
> > "front-end"
> > > > > > > > ecosystem.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > With all that said, I keep thinking
> > this
> > > > is
> > > > > > the
> > > > > > > > best
> > > > > > > > > > > > course
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > > > >> > > > for us right now. We keep most of our
> > > > stuff
> > > > > > > > > unchanged,
> > > > > > > > > > > we
> > > > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > >> > > > release, and we have a working setup
> > that
> > > > will
> > > > > > > > suit
> > > > > > > > > us
> > > > > > > > > > > > well
> > > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > >> > > > discuss and reach a conclusion
> > regarding
> > > > the
> > > > > > > > future
> > > > > > > > > of
> > > > > > > > > > > our
> > > > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Let me paint a quick picture here of
> > what
> > > > our
> > > > > > code
> > > > > > > > > > base
> > > > > > > > > > > > > would
> > > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal
> > is
> > > > > > accepted:
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > > > > >> > > > A
> > > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-images
> > > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > >> > > > B
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > >> > > > D
> > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > > > > >> > > > E
> > incubator-kie-kogito-website
> > > > > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > > > > >> > > > E
> > incubator-kie-kogito-online
> > > > > > > > > > > > > > > > >> > > > E
> > > > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > * Category C becomes part of Category
> > A,
> > > > and
> > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> > > > entirely
> > > > > > inside
> > > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> > > > images
> > > > > > and
> > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > > > > `kie-tools`,
> > > > > > > > > there
> > > > > > > > > > > are
> > > > > > > > > > > > > no
> > > > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > > > > granularly
> > > > > > > > > > build:
> > > > > > > > > > > > > > > > >> > > > 1.
> > > > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > > >> > > > 2.
> > packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> > > > (containing
> > > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> > > > (contents
> > > > > > from
> > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > The second part of the proposal is the
> > > > release
> > > > > > > > > process
> > > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > > >> > > > assuming the structure above is what
> > we
> > > > have.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be
> > > > used as
> > > > > > > > > cutting
> > > > > > > > > > > > point
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to
> > > > this
> > > > > > > > > > timestamped
> > > > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > > > > >> > > > 3. At this point, with everything
> > > > working, we
> > > > > > can
> > > > > > > > > > branch
> > > > > > > > > > > > out
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the
> > timestamped
> > > > > > SNAPSHOT
> > > > > > > > > > tag,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> > > > update
> > > > > > > > their
> > > > > > > > > > > > versions
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > > > > Category A
> > > > > > > > > > repos
> > > > > > > > > > > > > using
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the
> > > > release
> > > > > > based
> > > > > > > > > on
> > > > > > > > > > > the
> > > > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > > > >> > > > branches, given we don't expect any
> > code
> > > > > > changes
> > > > > > > > > > > anymore.
> > > > > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to
> > > > start
> > > > > > the
> > > > > > > > > > release
> > > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > > > manual/automated
> > > > > > > > > > > release
> > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > > > pushed
> > > > > > to
> > > > > > > > Git,
> > > > > > > > > > and
> > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > > > > artifacts
> > > > > > > > to
> > > > > > > > > be
> > > > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > > > manual/automated
> > > > > > > > > > > release
> > > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > > > pushed
> > > > > > to
> > > > > > > > Git,
> > > > > > > > > > and
> > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > > > > >> > > > 12. Category E repos can be manually
> > > > tagged
> > > > > > with
> > > > > > > > > > 10.0.0
> > > > > > > > > > > > from
> > > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > More needs to be discussed if we're
> > > > planning
> > > > > > to
> > > > > > > > > > maintain
> > > > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > > > >> > > > release streams in parallel, but I
> > guess
> > > > it
> > > > > > can
> > > > > > > > wait
> > > > > > > > > > for
> > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> > > > > > forward to
> > > > > > > > > > > hearing
> > > > > > > > > > > > > back
> > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Of course, alternative solutions are
> > > > possible.
> > > > > > > > This
> > > > > > > > > > > email,
> > > > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > > > >> > > > summarizes my view of how we should
> > > > attack the
> > > > > > > > > > problem,
> > > > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > > > >> > > > disruption, required effort, the
> > release
> > > > > > process
> > > > > > > > > > itself,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > > > >> > > > Feel free to propose alternatives.
> > This is
> > > > > > not a
> > > > > > > > > > voting
> > > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Tiago,
Unfortunately, my plan is too conceptually simple to write more than I
already wrote.
1) Move kn-plugin-workflow module to operator repo (this remove the
dependency between tools and operator, breaking the loop)
2) Change CI global stream to execute tooling repo before operator repo
(this seems to take 2 months unless Tristan helps and reduce the time to 2
weeks)
3) Optionally, and just as a consequence of that CI change, set
999-SNAPSHOT version to all poms in all repos (if current snapshot numbers
turns out to be a problem, in any case this is just search-replace)
The current plan is:
1) Move everything depending on tools to tools repo, which includes
operator code and examples.
2) Change CI of tooling repo to enforce dependencies between the existing
modules there and the newly moved ones (this seems to take 3 weeks or less)
I think rather than asking for a more detailed alternative, what needs to
be done is to refine the existing proposal with the feedback received. I do
not think both proposals are antagonistic. I think that, being now clear we
have the same overall goal (execute tooling before operator), it is just a
question of deciding between move more stuff to an already heterodox repo,
coming from repos not as heterodox, plus changing the repo CI to impose
certain order between these modules or pull out the the operator stuff from
tool repo and put it inside the operator repo plus changing the CI
handling repos to impose the desired order: first tooling and then operator.
On Wed, Mar 13, 2024 at 4:12 PM Tiago Bento <ti...@gmail.com>
wrote:
> Francisco,
>
> 1) `kie-tools` is already a heterodox repo. The reason why I proposed
> my proposal is because it is what I think is the best course of action
> for our community right now. If you think there's a better way to do
> it, I think everyone, including me, needs to see a proposal with a
> clear execution plan with a comparable level of detail and analysis in
> regards to disruption of the current state, the required effort, the
> contribution workflow for cross-repo PRs, and the release process
> itself. Otherwise, we risk having gaps that each person will fill in a
> different way, and IMHO, that's where problems happen. +1 for examples
> unification, btw :)
>
> 2) Ok, and +1 for no categorization.
>
> On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado Sarti
> <ft...@redhat.com> wrote:
> >
> > 1) Ok, if that is the case, I do not get why your first proposal was not
> > the one I'm proposing and it is apparently not detailed enough. To move
> > kn-workflow from tooling to operator one and change the order in which
> the
> > repos are being processed. Basically, the problem of the proposed
> solution
> > is that it kind of converts tooling repo into a pretty heterodox repo
> > compared with runtimes, drools or operator one. Also once tooling is not
> a
> > final repo in the overall chain, we can consider moving examples as the
> > final one and include tooling showcases there (rather than splitting
> > examples into examples with tooling and examples without tooling).
> > 2) I think this distinction between A and B is one between several
> possible
> > categorizations (not much, including no categorization at all) that
> > deserves a separate discussion. I will open a separate thread for that
> > purpose, since we are not going to change that now and it is not really
> > part of the proposal.
> >
> > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
> tiagobentofernandes@gmail.com>
> > wrote:
> >
> > > Francisco,
> > >
> > > 1) That's what this thread is all about... You know I don't think it's
> > > ok. That's why I'm proposing the two images and the operator to move
> > > into the `kie-tools` repo, where we can more granularly control the
> > > order things are built, thus removing the dependency cycle.
> > >
> > > 2) Not sure we understand the same thing by "freeze". My proposal is
> > > that we select a timestamped SNAPSHOT version from Category A repos to
> > > use as base for a release. We give Category B repos some time to
> > > adjust, and then cut the release branches. This can happen anytime,
> > > and no contributions would ever stop because of it. The development
> > > branches can continue accepting PRs normally, even during the release
> > > process. Now, if what you're asking is why Category B repos refer to
> > > Category A repos via timestamped SNAPSHOTs, the answer is in my first
> > > email. See the paragraph starting with "An important note here is that
> > > Category B repositories...".
> > >
> > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti
> > > <ft...@redhat.com> wrote:
> > > >
> > > > Tiago
> > > > There are a couple of simple and straightforward questions that I
> > > > formulated, but since we both write a lot, it might have been lost.
> > > Please
> > > > let me ask them again.
> > > > 1) Do you think it is ok that tools repo is executed after
> generation of
> > > > docker images that are supposed to include those tools or the
> operator
> > > that
> > > > is supposed to deploy such images?
> > > That's what this thread is all about... You know I'm not ok with it,
> > > that's why I'm proposing the two images and the operator to move into
> > > the `kie-tools` repo, where we can more granularly control the order
> > > things are built and remove the dependency cycle.
> > > > 2) Besides that, although not directly related with the current
> proposal
> > > we
> > > > are discussing, I really think there are some restrictions taken for
> > > > granted that are arbitrary and difficult to sustain on strictly
> technical
> > > > arguments. For example, the need to freeze the rest of the software
> > > before
> > > > tools are generated. Why? We have dependencies between repos that
> are not
> > > > handled that way: Apps depend on runtimes. Runtimes depend on drools,
> > > > Operator depend on runtimes,....and we are not freezing that repos
> since
> > > we
> > > > are all releasing at the same time. If we are all releasing at the
> same
> > > > time, what's the rationale behind the freeze?
> > > >
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <ti...@apache.org>
> > > wrote:
> > > >
> > > > > Glad to see the interest this proposal has gotten, and it's good to
> > > > > see some alternatives being drafted here, although still lacking
> clear
> > > > > definitions and analysis in regards to disruption, required effort,
> > > > > the release process itself, and history. Of course, lots of details
> > > > > and clarity on the execution part would be missing too.
> > > > >
> > > > > As of this moment, based on what I read here, I'm assuming that
> > > > > everyone who participated so far doesn't see the initial proposal
> as
> > > > > problematic in terms of feasibility, but some of you have a
> preference
> > > > > not to go with it, because it is "wrong", and apparently because it
> > > > > would "jeopardize the evolution of the project". Reading these last
> > > > > words made me a little sad, to be honest. But I can deal with it :)
> > > > >
> > > > > Please let's try and keep the discussion as objective as possible.
> > > > > "Right" and "wrong" are too subjective for this kind of
> conversation.
> > > > >
> > > > > Now, being practical, unless there are clear arguments based on
> facts
> > > > > and objective concepts that invalidate the initial proposal shared
> on
> > > > > this email, it seems to me that it is currently the only viable
> > > > > proposal we have for unblocking and releasing Apache KIE 10. Of
> > > > > course, if we end up seeing an alternative proposal with enough
> > > > > details and a clear execution plan, I think then we'll be in a very
> > > > > good position to choose from multiple options!
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > > >
> > > > > > Francisco and Gabriele,
> > > > > >
> > > > > > I understand and acknowledge your desire to find the “right”
> solution
> > > > > > instead to work on a temporary “patch” - however without a
> detailed
> > > > > > proposal I don’t think we can properly evaluate the impact of
> your
> > > > > > suggestion.
> > > > > >
> > > > > > When I spoke with different SMEs that included tools and CI, the
> > > > > > guesstimate for making the necessary changes on CI and codebase
> to
> > > > > > basically have images and operators in the end of the build
> chain is
> > > > > > something like 2 months of effort. Another impact that needs to
> be
> > > > > > discussed is that KIE Tools repo had to be injected in the
> middle of
> > > all
> > > > > > pipelines - forcing all PR checks and nightlies to build all
> repos
> > > (PR
> > > > > > checks will likely take 12+ hours… I even heard that it could be
> > > even 24
> > > > > > hours).
> > > > > >
> > > > > > Based on the input above, I think it’s quite risk to move in such
> > > > > direction
> > > > > > without a more detailed plan… because 2 months could be turned
> > > easily in
> > > > > 6!
> > > > > > And this is exactly what happened when we guessed that moving to
> > > Apache
> > > > > > would take no more than 3 months. But here we are.
> > > > > >
> > > > > > I really strongly suggest that we focus on a release that could
> be
> > > > > > achievable in less than a month from now, and we - after release
> -
> > > have a
> > > > > > in depth discussion about the overall codebase and ci
> organization.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > gabriele.cardosi@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Alex,
> > > > > > > my suggestion is to move the building of all docker images,
> from
> > > > > whatever
> > > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo,
> to
> > > be
> > > > > > > invoked after all the others.
> > > > > > > I'm not sure if this would solve all the issues, and since I
> could
> > > not
> > > > > > > enter in the details of all the involved code, my suggestion
> may
> > > be too
> > > > > > > naive.
> > > > > > > Having spent almost all of the last year in CI, I may say
> that, at
> > > > > least
> > > > > > > for the kie-tools repo, removing the image build step from it
> > > should
> > > > > not be
> > > > > > > too difficult (since it is an issue we already faced and
> solved).
> > > > > > > If, with "detailed proposal", you mean a complete list of all
> > > modules
> > > > > to be
> > > > > > > moved and dependency refactoring, of course I can not provide
> it
> > > right
> > > > > now.
> > > > > > >
> > > > > > > Anyway, I share the concern from Francisco: undoing something
> is
> > > almost
> > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier
> Tirado
> > > Sarti
> > > > > <
> > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > >
> > > > > > > > I do not think estimations should be the only driver to make
> a
> > > > > decision,
> > > > > > > > especially when the current proposal is conceptually
> incompatible
> > > > > with
> > > > > > > the
> > > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > > Given my knowledge of the CI it is nearly impossible for me
> to
> > > give
> > > > > a
> > > > > > > fair
> > > > > > > > estimate of how much it might take to achieve step 2) of my
> > > previous
> > > > > > > e-mail
> > > > > > > > . It might take a while or it might be pretty easy after
> all, I
> > > don't
> > > > > > > > really know, but I think it will be a good idea if some of
> the
> > > > > experts
> > > > > > > on
> > > > > > > > CI in the team (the ones that set up the pipeline, which was
> a
> > > huge
> > > > > > > > achievement) give an estimate, not me. Estimating how much
> it
> > > takes
> > > > > to
> > > > > > > > merge two existing repos (without altering CI) is easier,
> but it
> > > > > does not
> > > > > > > > mean we are doing the right thing.
> > > > > > > > My main concern is that it will be very difficult for me to
> > > explain
> > > > > to
> > > > > > > > someone that arrives new to the team, that having experts on
> CI
> > > on
> > > > > the
> > > > > > > > team, we decided to merge two repos (once merged, it would be
> > > rather
> > > > > > > > difficult to unmerge) rather than fix the CI, because of
> > > expediency.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > porcelli@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco,
> > > > > > > > >
> > > > > > > > > Please take the time to make the more in depth analysis
> needed
> > > and
> > > > > > > > provide
> > > > > > > > > a more detailed plan… so we - as community- can evaluate
> the
> > > size
> > > > > of
> > > > > > > the
> > > > > > > > > effort. In the conceptual level you shared it’s near
> > > impossible to
> > > > > > > > estimate
> > > > > > > > > the size of the effort and compare with the current
> proposal.
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado
> Sarti <
> > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > 1) Remove all dependencies from tooling to images, so
> images
> > > > > depend
> > > > > > > on
> > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > 2) Then change CI to deal with tooling repo before
> dealing
> > > with
> > > > > > > images
> > > > > > > > > > repo.
> > > > > > > > > > I understand that CI details are tricky and since I'm not
> > > > > familiar
> > > > > > > with
> > > > > > > > > CI
> > > > > > > > > > in any way, I barely can make a low level design, but we
> do
> > > not
> > > > > need
> > > > > > > to
> > > > > > > > > fix
> > > > > > > > > > everything, just achieve 2), a change of compilation
> order.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > > alex@porcelli.me
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > >
> > > > > > > > > > > You may not like or understand why the current state of
> > > the CI
> > > > > is
> > > > > > > > like
> > > > > > > > > > > that… actually has been in Red Hat and has been
> replicated
> > > in
> > > > > > > Apache
> > > > > > > > as
> > > > > > > > > > > used to be….
> > > > > > > > > > >
> > > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > > >
> > > > > > > > > > > If you disagree with the current plan, please provide a
> > > > > detailed
> > > > > > > > > > > alternative so we, as community, can better evaluate
> the
> > > pros
> > > > > and
> > > > > > > > cons
> > > > > > > > > of
> > > > > > > > > > > each proposal.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I think it’s also fair to say that, post 10 release we
> > > need to
> > > > > > > have a
> > > > > > > > > > much
> > > > > > > > > > > in depth discussion about how our codebase is
> organized,
> > > it’s
> > > > > clear
> > > > > > > > > that
> > > > > > > > > > > it’s not working.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > I also have the impression that the "images" (if we
> are
> > > > > talking
> > > > > > > of
> > > > > > > > > > docker
> > > > > > > > > > > > images) should be the very last one to be built, in a
> > > > > standalone
> > > > > > > > > repo.
> > > > > > > > > > > > That way, they may "combine" artifacts that are
> built in
> > > > > > > different
> > > > > > > > > > repos,
> > > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > > Moving them out of all the repos
> (kogito-apps/kie-tools)
> > > > > maybe
> > > > > > > > could
> > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > (I also think there are some statements of
> undisputable
> > > needs
> > > > > > > while
> > > > > > > > > > they
> > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > > discussion.)
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco
> Javier
> > > > > Tirado
> > > > > > > > > Sarti
> > > > > > > > > > <
> > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > >
> > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > There are two assumptions that deserve further
> > > discussion:
> > > > > > > > > > > > > 1) That tool has to be the last to build. why? it
> does
> > > not
> > > > > have
> > > > > > > > > more
> > > > > > > > > > > > sense
> > > > > > > > > > > > > to build final images after everything else has
> been
> > > > > built?-
> > > > > > > > > > > > > 2) That the impact (in terms of effort now) on
> fixing
> > > CI is
> > > > > > > > bigger
> > > > > > > > > > than
> > > > > > > > > > > > the
> > > > > > > > > > > > > impact (long term consequences) of consolidating
> two
> > > > > unrelated
> > > > > > > > > piece
> > > > > > > > > > of
> > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > > alex@porcelli.me
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This was discussed as an alternative solution,
> > > however
> > > > > it has
> > > > > > > > > major
> > > > > > > > > > > > > impact
> > > > > > > > > > > > > > on CI and there’s also the fact Tool has been
> always
> > > the
> > > > > last
> > > > > > > > to
> > > > > > > > > > > build
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> > > world
> > > > > there
> > > > > > > > is
> > > > > > > > > no
> > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So, based on our evaluation… the proposal here
> is the
> > > > > least
> > > > > > > > > > > disruptive
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> > > Tirado
> > > > > > > Sarti <
> > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > > embracing
> > > > > the
> > > > > > > fact
> > > > > > > > > > that
> > > > > > > > > > > > > > > kogito-images depend on kie-tools, because we
> want
> > > > > those
> > > > > > > > images
> > > > > > > > > > to
> > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco
> Javier
> > > > > Tirado
> > > > > > > > Sarti
> > > > > > > > > <
> > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > > kn-plugin-workflow
> > > > > > > > > to
> > > > > > > > > > > > > > > > kogito-images (so there is not longer
> dependency
> > > from
> > > > > > > tools
> > > > > > > > > to
> > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique
> Gonzalez
> > > > > > > Martinez
> > > > > > > > <
> > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > > (apache)
> > > > > <
> > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> > I say +1 in order to move forward with
> the 10.
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex
> Porcelli <
> > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > I spent the last day or so working
> closely
> > > with
> > > > > > > Tiago,
> > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > >> > > options and getting deeper on the
> impact and
> > > > > > > > evaluating
> > > > > > > > > > the
> > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > >> > > procedure steps required. I agree with
> the
> > > > > proposal
> > > > > > > as
> > > > > > > > > the
> > > > > > > > > > > > most
> > > > > > > > > > > > > > > >> > > viable option for unblocking the 10
> release
> > > in
> > > > > the
> > > > > > > > > > > reasonable
> > > > > > > > > > > > > time
> > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago
> Bento
> > > <
> > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> > > time,
> > > > > as
> > > > > > > this
> > > > > > > > > > > matter
> > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes
> to
> > > read,
> > > > > > > > > according
> > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > > thread
> > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > >
> > > > > > > >
> https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > >> > > > many of us were working towards
> removing a
> > > > > > > circular
> > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > >> > > > currently present between
> `kogito-apps`
> > > and
> > > > > > > > > `kie-tools`.
> > > > > > > > > > > As
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > > > > finding the
> > > > > > > > > > > circular
> > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > > breakdown of
> > > > > the
> > > > > > > > > things
> > > > > > > > > > > we
> > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Right now, even though we started the
> > > effort
> > > > > to
> > > > > > > move
> > > > > > > > > the
> > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't
> been
> > > > > able to
> > > > > > > > do
> > > > > > > > > it
> > > > > > > > > > > > yet,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java
> 17,
> > > > > Maven
> > > > > > > > 3.9.6,
> > > > > > > > > > and
> > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > .
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > |==> 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > L |
> ==========================
> > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> `kie-tools`/extended-services
> > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > > > `kie-tools`,
> > > > > > > we
> > > > > > > > > > > would've
> > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > 02.
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > > `kie-tools`/kn-plugin-workflow
> > > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > >> > > > * and
> > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > depends
> > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> > > image to
> > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > 02.
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > 04.
> > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > > `kie-tools`/kn-plugin-workflow
> > > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > >> > > > * and
> `kogito-serverless-operator`
> > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> > > than a
> > > > > > > simple
> > > > > > > > > > > > circular
> > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After multiple conversations with a
> lot of
> > > > > people,
> > > > > > > > > it's
> > > > > > > > > > > been
> > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > >> > > > hard coming up with a simple solution
> that
> > > > > makes
> > > > > > > it
> > > > > > > > > > > possible
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while
> preserving
> > > the
> > > > > way
> > > > > > > > > > everyone
> > > > > > > > > > > is
> > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > contributing to the multiple
> repositories
> > > we
> > > > > have.
> > > > > > > > > More
> > > > > > > > > > > than
> > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > >> > > > while making this assessment, I found
> more
> > > > > > > problems
> > > > > > > > > > that,
> > > > > > > > > > > in
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm
> coming
> > > > > forward
> > > > > > > with
> > > > > > > > > my
> > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we
> can
> > > use
> > > > > > > > Apache's
> > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate
> about
> > > > > this
> > > > > > > > really
> > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective
> about
> > > the
> > > > > > > current
> > > > > > > > > > > > situation
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > > currently
> > > > > see.
> > > > > > > > > I'll
> > > > > > > > > > > > start
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > > > purposes,
> > > > > > > > point
> > > > > > > > > > out
> > > > > > > > > > > > > some
> > > > > > > > > > > > > > > >> > > > problems that I believe are blocking
> our
> > > 10
> > > > > > > release,
> > > > > > > > > > > explain
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > >> > > > proposal and discuss some
> consequences to
> > > > > what I'm
> > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO
> (count:
> > > 11)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > > >> > > > -
> incubator-kie-optaplanner-quickstarts @
> > > > > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-serverless-operator @
> > > > > > > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > > updated @
> > > > > > > `main`.
> > > > > > > > > > Same
> > > > > > > > > > > > for
> > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @
> `main`
> > > > > > > > > > > > > > > >> > > > (The Kogito website. Develop &
> deploy
> > > at
> > > > > the
> > > > > > > > > `main`
> > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > > >> > > > (The KIE website. Develop @
> `main`.
> > > Push @
> > > > > > > > > `deploy`
> > > > > > > > > > to
> > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> `gh-pages`
> > > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > > sandbox.kie.org
> > > > > > > and
> > > > > > > > > KIE
> > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging
> @
> > > `main`
> > > > > > > > > > > > > > > >> > > > (Same as above, but for manual
> sanity
> > > > > checks
> > > > > > > > > during
> > > > > > > > > > > the
> > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I grouped the repositories by
> category,
> > > and
> > > > > listed
> > > > > > > > > them
> > > > > > > > > > > in a
> > > > > > > > > > > > > > > >> > > > topological order. Keep in mind that
> when
> > > > > > > flattening
> > > > > > > > > > out a
> > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > >> > > > are multiple possibilities. For
> example,
> > > > > > > OptaPlanner
> > > > > > > > > > > > could've
> > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > > referring
> > > > > to
> > > > > > > as
> > > > > > > > > > > `drools`
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> OptaPlanner
> > > is
> > > > > inside
> > > > > > > > > that
> > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > way these repositories reference each
> > > other
> > > > > are
> > > > > > > > > through
> > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > > 999-SNAPSHOT
> > > > > > > > > version.
> > > > > > > > > > > This
> > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > >> > > > is well-known to the team, and
> although
> > > > > flawed for
> > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > > different
> > > > > time
> > > > > > > > > zones,
> > > > > > > > > > it
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> > > with, I
> > > > > > > > assume.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Contributions made to Category A have
> some
> > > > > > > dedicated
> > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> > > build
> > > > > > > > cross-repo
> > > > > > > > > > PRs
> > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > >> > > > and verify that the codebase will
> continue
> > > > > working
> > > > > > > > as
> > > > > > > > > > > > expected
> > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > > gather,
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > > some
> > > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > > cross-repo
> > > > > > > > PRs.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> kogito-apps,
> > > and
> > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > >> > > > - optaplanner, and
> optaplanner-quickstarts
> > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This means that sending cross-repo
> PRs to
> > > any
> > > > > > > > > > combination
> > > > > > > > > > > of
> > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > >> > > > that are not part of the same
> "sub-stream"
> > > > > cannot
> > > > > > > be
> > > > > > > > > > > > verified
> > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > > > dependent
> > > > > > > on
> > > > > > > > > > > > individual
> > > > > > > > > > > > > > > >> > > > contributors building stuff on their
> > > machines
> > > > > to
> > > > > > > > > verify
> > > > > > > > > > > that
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with
> these
> > > > > > > > pipelines,
> > > > > > > > > so
> > > > > > > > > > > > > please
> > > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > > referring
> > > > > to
> > > > > > > as
> > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > >> > > > stream. The first repo there is a
> template
> > > > > > > > repository
> > > > > > > > > > that
> > > > > > > > > > > > is
> > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > >> > > > people starting projects from scratch
> on
> > > KIE
> > > > > > > > Sandbox,
> > > > > > > > > > > > similar
> > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The
> other
> > > one
> > > > > is the
> > > > > > > > KIE
> > > > > > > > > > > Tools
> > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> > > build
> > > > > > > system.
> > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > > > TypeScript
> > > > > > > > > > libraries
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts.
> The
> > > > > > > > `kie-tools`
> > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > >> > > > configured to work with sparse
> checkouts
> > > and
> > > > > can
> > > > > > > do
> > > > > > > > > > > partial
> > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > >> > > > Category B repos refer to Category A
> repos
> > > > > through
> > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > > recently
> > > > > > > > > > introduced
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > >> > > > build and publish immutable,
> persistent
> > > > > artifacts
> > > > > > > > > under
> > > > > > > > > > a
> > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> > > format,
> > > > > > > > published
> > > > > > > > > > > weekly
> > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs
> are an
> > > > > > > evolution
> > > > > > > > > to
> > > > > > > > > > > the
> > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > > release
> > > > > for
> > > > > > > all
> > > > > > > > > of
> > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > An important note here is that
> Category B
> > > > > > > > repositories
> > > > > > > > > > > have
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > > >> > > > historically kept out of any
> automations
> > > we
> > > > > used
> > > > > > > to
> > > > > > > > > > have,
> > > > > > > > > > > > way
> > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > > Business
> > > > > > > Central
> > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > >> > > > still going on. For this reason,
> Category
> > > B
> > > > > > > projects
> > > > > > > > > > have
> > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > > > Actions.
> > > > > > > > > > Category B
> > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > >> > > > always depended on Category A repos
> using
> > > > > fixed
> > > > > > > > > > versions.
> > > > > > > > > > > If
> > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > > SNAPSHOTs,
> > > > > > > breaking
> > > > > > > > > > > changes
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > Category A repositories would've had
> the
> > > > > potential
> > > > > > > > to
> > > > > > > > > > > break
> > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > >> > > > silently, leaving Category B with a
> broken
> > > > > > > > development
> > > > > > > > > > > > stream,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > > > maintainers
> > > > > > > of
> > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > >> > > > as historically Category A
> contributors
> > > were
> > > > > not
> > > > > > > > > > familiar
> > > > > > > > > > > > with
> > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Contributions made to Category B
> repos go
> > > > > through
> > > > > > > a
> > > > > > > > > > GitHub
> > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > >> > > > workflow that builds the relevant
> part of
> > > the
> > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > >> > > > the changes introduced. Changes made
> to
> > > the
> > > > > > > pipeline
> > > > > > > > > > > itself
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us
> to
> > > do
> > > > > things
> > > > > > > > > like
> > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> example.
> > > More
> > > > > > > > > > > importantly,
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > > timestamped
> > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > >> > > > with the changes necessary to make it
> stay
> > > > > green.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This setup, however, makes it
> impossible
> > > to
> > > > > have
> > > > > > > > > > > cross-repo
> > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > > simultaneously,
> > > > > > > > > with
> > > > > > > > > > > the
> > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > > around,
> > > > > and
> > > > > > > > I'm
> > > > > > > > > > not
> > > > > > > > > > > > sure
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > > Regardless,
> > > > > > > as
> > > > > > > > > > > they're
> > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > > release,
> > > > > so I
> > > > > > > > > > listed
> > > > > > > > > > > > them
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category D is self explanatory.
> There's
> > > only
> > > > > one
> > > > > > > > repo
> > > > > > > > > > that
> > > > > > > > > > > > has
> > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category E are repos that do not host
> code
> > > > > > > directly,
> > > > > > > > > and
> > > > > > > > > > > are
> > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > >> > > > organizational entities, or host
> websites,
> > > > > that
> > > > > > > > > > currently
> > > > > > > > > > > > are
> > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This lack of unification between
> Category
> > > A
> > > > > and
> > > > > > > > > > Category B
> > > > > > > > > > > > is,
> > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> infamous
> > > > > circular
> > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which
> we
> > > now
> > > > > can
> > > > > > > > > describe
> > > > > > > > > > > as
> > > > > > > > > > > > a
> > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > >> > > > dependency between Category A and
> > > Category B.
> > > > > The
> > > > > > > > way
> > > > > > > > > I
> > > > > > > > > > > see
> > > > > > > > > > > > > it,
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > had a single pipeline, building
> everything
> > > > > from
> > > > > > > > > `drools`
> > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> > > been
> > > > > > > > > introduced,
> > > > > > > > > > > and
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem
> in
> > > our
> > > > > hands
> > > > > > > > > right
> > > > > > > > > > > now.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > > process
> > > > > > > sees
> > > > > > > > > this
> > > > > > > > > > > > lack
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > unification as a central problem, not
> > > only for
> > > > > > > this
> > > > > > > > > > > release
> > > > > > > > > > > > in
> > > > > > > > > > > > > > > >> > > > particular, but for the community as a
> > > whole.
> > > > > It
> > > > > > > is
> > > > > > > > my
> > > > > > > > > > > > belief
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > are all under the same roof, and that
> no
> > > > > > > > contribution
> > > > > > > > > > > should
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > >> > > > allowed to break any part of our
> codebase.
> > > > > With
> > > > > > > the
> > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > > contributors
> > > > > too,
> > > > > > > > we
> > > > > > > > > > > cannot
> > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> > > breaking
> > > > > > > things.
> > > > > > > > > > We're
> > > > > > > > > > > > all
> > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > > > mechanisms in
> > > > > > > > > place
> > > > > > > > > > > to
> > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> > > Especially
> > > > > when
> > > > > > > > > these
> > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > >> > > > impact on parts of the codebase that
> we,
> > > > > > > > individually,
> > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > > depending
> > > > > on
> > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > > > `kogito-images`
> > > > > > > > > > > > depending
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools`
> depending on
> > > > > > > > kiegroup's
> > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > > > depending on
> > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > > > codebase
> > > > > > > > here:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >
> > > > > > > > > >
> > > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > > ,
> > > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > > OptaPlanner,
> > > > > > > > > > > pointing
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > older
> > > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P5.
> > > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > > depending
> > > > > > > > > > > on
> > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> `2.15.3.Final`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P6. Category C repos are out of date
> and
> > > not
> > > > > part
> > > > > > > of
> > > > > > > > > the
> > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> > > (Current
> > > > > > > version
> > > > > > > > is
> > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > > > version,
> > > > > > > only
> > > > > > > > > by
> > > > > > > > > > > > using
> > > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> > > version
> > > > > is
> > > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > > > OptaPlanner
> > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P7.
> > > `kie-tools`/packages/kn-plugin-workflow
> > > > > has
> > > > > > > its
> > > > > > > > > E2E
> > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the
> same
> > > > > > > solution,
> > > > > > > > > as
> > > > > > > > > > > they
> > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > >> > > > suffer from the circular dependency
> > > between
> > > > > > > > Category A
> > > > > > > > > > and
> > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > > >> > > > As Category A and Category B are both
> > > streams
> > > > > that
> > > > > > > > > have
> > > > > > > > > > > been
> > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > >> > > > active, I see this as a blocker, as
> there
> > > are
> > > > > > > > > > > contributions
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> > > depends
> > > > > on
> > > > > > > > > > Category
> > > > > > > > > > > B
> > > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > > > understood
> > > > > > > as
> > > > > > > > > > > > technical
> > > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > > > something
> > > > > > > > we'll
> > > > > > > > > > > always
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> > > just a
> > > > > > > matter
> > > > > > > > of
> > > > > > > > > > > > making
> > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> > > impact
> > > > > the
> > > > > > > > > > structure
> > > > > > > > > > > or
> > > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > > >> > > > that we're talking about here, but it
> is a
> > > > > > > > regression
> > > > > > > > > we
> > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> > > Apache
> > > > > KIE
> > > > > > > 10,
> > > > > > > > > and
> > > > > > > > > > > > that
> > > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only
> problems
> > > > > left to
> > > > > > > > > > discuss
> > > > > > > > > > > > are
> > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > P2, which can't be done without a
> proper
> > > > > proposal.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I'll try to be very meticulous here,
> since
> > > > > from my
> > > > > > > > > > > > experience,
> > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> > > release
> > > > > not
> > > > > > > > > > working
> > > > > > > > > > > > out
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > > > possible,
> > > > > > > and
> > > > > > > > > make
> > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > > > release,
> > > > > > > bear
> > > > > > > > > > with
> > > > > > > > > > > > me.
> > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > > >> > > > out a timeline of events that need to
> > > happen
> > > > > in
> > > > > > > > order
> > > > > > > > > > for
> > > > > > > > > > > > our
> > > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > > >> > > > to be published, with all artifacts
> > > ending up
> > > > > in
> > > > > > > the
> > > > > > > > > > right
> > > > > > > > > > > > > > places,
> > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > >> > > > first, we need to solve problems P1
> and
> > > P2.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As you saw at the beginning of this
> email,
> > > > > all the
> > > > > > > > > > > attempts
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > made
> > > > > > > > > > > > > > > >> > > > left us with the circular dependency
> > > showing
> > > > > up
> > > > > > > at a
> > > > > > > > > > > > different
> > > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > > >> > > > but something all these places have in
> > > common
> > > > > is
> > > > > > > > that
> > > > > > > > > > > > they're
> > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > >> > > > after kogito-apps, and before to
> Category
> > > B.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > > > following:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > S1. We keep the original plan of
> moving
> > > the
> > > > > > > Quarkus
> > > > > > > > > Dev
> > > > > > > > > > > UIs
> > > > > > > > > > > > > from
> > > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> > > with
> > > > > > > > Management
> > > > > > > > > > and
> > > > > > > > > > > > > Task
> > > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> > > `kie-tools`.
> > > > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode`
> and
> > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools`
> too.
> > > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > > `kogito-serverless-operator`
> > > > > > > > > repo
> > > > > > > > > > > > > inside
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> > > history.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together
> solve
> > > > > problems
> > > > > > > P1
> > > > > > > > > and
> > > > > > > > > > > P2.
> > > > > > > > > > > > Of
> > > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > > >>
> > > > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This doesn't come without
> consequences, of
> > > > > course,
> > > > > > > > as
> > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > > `kogito-swf-builder`
> > > > > > > > images,
> > > > > > > > > > and
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be
> > > moving
> > > > > from
> > > > > > > > > > > Category A
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > Category B. This move would make them
> > > have to
> > > > > > > > > reference
> > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs.
> Since
> > > > > > > > > > `kogito-images`
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are
> already
> > > > > their own
> > > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > > >> > > > Category A, though, contributions
> made in
> > > a
> > > > > > > > cross-repo
> > > > > > > > > > > > fashion
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> > > possible, now
> > > > > > > via a
> > > > > > > > > > > single
> > > > > > > > > > > > PR
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> > > Category
> > > > > A and
> > > > > > > > > > > Category
> > > > > > > > > > > > B
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > >> > > > continue not being possible, and a
> 1-week
> > > > > delay
> > > > > > > > > between
> > > > > > > > > > > > > merging
> > > > > > > > > > > > > > > >> > > > something on Category A and using it
> on
> > > > > Category B
> > > > > > > > > will
> > > > > > > > > > > > still
> > > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > It's worth mentioning that
> `kie-tools`,
> > > > > however,
> > > > > > > > does
> > > > > > > > > > > allow
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > > >> > > > checkouts and partial builds, so
> working
> > > with
> > > > > a
> > > > > > > > subset
> > > > > > > > > > of
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > >> > > > is possible and encouraged. Making
> changes
> > > > > only to
> > > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> > > example,
> > > > > will
> > > > > > > > have
> > > > > > > > > > the
> > > > > > > > > > > PR
> > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see
> here:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > >> > > > We're not compromising when running
> > > partial
> > > > > builds
> > > > > > > > > too.
> > > > > > > > > > We
> > > > > > > > > > > > > know
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> > > > the entire repo will continue working
> even
> > > > > after
> > > > > > > > only
> > > > > > > > > > > > > building a
> > > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > > >> > > > subset of the changes. Doing partial
> or
> > > full
> > > > > > > builds
> > > > > > > > is
> > > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> > > proposing
> > > > > we
> > > > > > > > move a
> > > > > > > > > > > bunch
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I
> see
> > > this
> > > > > as a
> > > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would
> host
> > > some
> > > > > > > > > additional
> > > > > > > > > > > > stuff
> > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > > > continue
> > > > > > > > moving
> > > > > > > > > > > > > forward.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As I mentioned on other places,
> > > `kie-tools`
> > > > > > > became a
> > > > > > > > > > > > polyglot
> > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > >> > > > out of necessity, and although I'm
> really
> > > > > proud of
> > > > > > > > > what
> > > > > > > > > > we
> > > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > > >> > > > there so far, I don't think
> `kie-tools`
> > > has a
> > > > > > > setup
> > > > > > > > > that
> > > > > > > > > > > is
> > > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > > >> > > > for all the different nuances that
> > > compose our
> > > > > > > > > > community.
> > > > > > > > > > > > I'm
> > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that
> does
> > > not
> > > > > > > follow
> > > > > > > > > > > > widespread
> > > > > > > > > > > > > > > >> > > > conventions will scare some people
> away,
> > > and
> > > > > as
> > > > > > > much
> > > > > > > > > as
> > > > > > > > > > > > we've
> > > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > >> > > > make build instructions clear, we
> can't
> > > > > always get
> > > > > > > > > past
> > > > > > > > > > > the
> > > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > > >> > > > some people have towards the
> "front-end"
> > > > > > > ecosystem.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > With all that said, I keep thinking
> this
> > > is
> > > > > the
> > > > > > > best
> > > > > > > > > > > course
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > > >> > > > for us right now. We keep most of our
> > > stuff
> > > > > > > > unchanged,
> > > > > > > > > > we
> > > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > release, and we have a working setup
> that
> > > will
> > > > > > > suit
> > > > > > > > us
> > > > > > > > > > > well
> > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > discuss and reach a conclusion
> regarding
> > > the
> > > > > > > future
> > > > > > > > of
> > > > > > > > > > our
> > > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Let me paint a quick picture here of
> what
> > > our
> > > > > code
> > > > > > > > > base
> > > > > > > > > > > > would
> > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal
> is
> > > > > accepted:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > B
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > D
> incubator-kie-kogito-operator
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > > > >> > > > E
> incubator-kie-kogito-website
> > > > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > > > >> > > > E
> incubator-kie-kogito-online
> > > > > > > > > > > > > > > >> > > > E
> > > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * Category C becomes part of Category
> A,
> > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> > > entirely
> > > > > inside
> > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> > > images
> > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > > > `kie-tools`,
> > > > > > > > there
> > > > > > > > > > are
> > > > > > > > > > > > no
> > > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > > > granularly
> > > > > > > > > build:
> > > > > > > > > > > > > > > >> > > > 1.
> > > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > >> > > > 2.
> packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> > > (containing
> > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> > > (contents
> > > > > from
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The second part of the proposal is the
> > > release
> > > > > > > > process
> > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > >> > > > assuming the structure above is what
> we
> > > have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be
> > > used as
> > > > > > > > cutting
> > > > > > > > > > > point
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to
> > > this
> > > > > > > > > timestamped
> > > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > > > >> > > > 3. At this point, with everything
> > > working, we
> > > > > can
> > > > > > > > > branch
> > > > > > > > > > > out
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the
> timestamped
> > > > > SNAPSHOT
> > > > > > > > > tag,
> > > > > > > > > > > and
> > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> > > update
> > > > > > > their
> > > > > > > > > > > versions
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > > > Category A
> > > > > > > > > repos
> > > > > > > > > > > > using
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the
> > > release
> > > > > based
> > > > > > > > on
> > > > > > > > > > the
> > > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > > >> > > > branches, given we don't expect any
> code
> > > > > changes
> > > > > > > > > > anymore.
> > > > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to
> > > start
> > > > > the
> > > > > > > > > release
> > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > > manual/automated
> > > > > > > > > > release
> > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > > pushed
> > > > > to
> > > > > > > Git,
> > > > > > > > > and
> > > > > > > > > > > > built
> > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > > > artifacts
> > > > > > > to
> > > > > > > > be
> > > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > > manual/automated
> > > > > > > > > > release
> > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > > pushed
> > > > > to
> > > > > > > Git,
> > > > > > > > > and
> > > > > > > > > > > > built
> > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > > > >> > > > 12. Category E repos can be manually
> > > tagged
> > > > > with
> > > > > > > > > 10.0.0
> > > > > > > > > > > from
> > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > More needs to be discussed if we're
> > > planning
> > > > > to
> > > > > > > > > maintain
> > > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > > >> > > > release streams in parallel, but I
> guess
> > > it
> > > > > can
> > > > > > > wait
> > > > > > > > > for
> > > > > > > > > > > > after
> > > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> > > > > forward to
> > > > > > > > > > hearing
> > > > > > > > > > > > back
> > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Of course, alternative solutions are
> > > possible.
> > > > > > > This
> > > > > > > > > > email,
> > > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > > >> > > > summarizes my view of how we should
> > > attack the
> > > > > > > > > problem,
> > > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > > >> > > > disruption, required effort, the
> release
> > > > > process
> > > > > > > > > itself,
> > > > > > > > > > > and
> > > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > > >> > > > Feel free to propose alternatives.
> This is
> > > > > not a
> > > > > > > > > voting
> > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Tiago Bento <ti...@gmail.com>.
Francisco,
1) `kie-tools` is already a heterodox repo. The reason why I proposed
my proposal is because it is what I think is the best course of action
for our community right now. If you think there's a better way to do
it, I think everyone, including me, needs to see a proposal with a
clear execution plan with a comparable level of detail and analysis in
regards to disruption of the current state, the required effort, the
contribution workflow for cross-repo PRs, and the release process
itself. Otherwise, we risk having gaps that each person will fill in a
different way, and IMHO, that's where problems happen. +1 for examples
unification, btw :)
2) Ok, and +1 for no categorization.
On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado Sarti
<ft...@redhat.com> wrote:
>
> 1) Ok, if that is the case, I do not get why your first proposal was not
> the one I'm proposing and it is apparently not detailed enough. To move
> kn-workflow from tooling to operator one and change the order in which the
> repos are being processed. Basically, the problem of the proposed solution
> is that it kind of converts tooling repo into a pretty heterodox repo
> compared with runtimes, drools or operator one. Also once tooling is not a
> final repo in the overall chain, we can consider moving examples as the
> final one and include tooling showcases there (rather than splitting
> examples into examples with tooling and examples without tooling).
> 2) I think this distinction between A and B is one between several possible
> categorizations (not much, including no categorization at all) that
> deserves a separate discussion. I will open a separate thread for that
> purpose, since we are not going to change that now and it is not really
> part of the proposal.
>
> On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <ti...@gmail.com>
> wrote:
>
> > Francisco,
> >
> > 1) That's what this thread is all about... You know I don't think it's
> > ok. That's why I'm proposing the two images and the operator to move
> > into the `kie-tools` repo, where we can more granularly control the
> > order things are built, thus removing the dependency cycle.
> >
> > 2) Not sure we understand the same thing by "freeze". My proposal is
> > that we select a timestamped SNAPSHOT version from Category A repos to
> > use as base for a release. We give Category B repos some time to
> > adjust, and then cut the release branches. This can happen anytime,
> > and no contributions would ever stop because of it. The development
> > branches can continue accepting PRs normally, even during the release
> > process. Now, if what you're asking is why Category B repos refer to
> > Category A repos via timestamped SNAPSHOTs, the answer is in my first
> > email. See the paragraph starting with "An important note here is that
> > Category B repositories...".
> >
> > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti
> > <ft...@redhat.com> wrote:
> > >
> > > Tiago
> > > There are a couple of simple and straightforward questions that I
> > > formulated, but since we both write a lot, it might have been lost.
> > Please
> > > let me ask them again.
> > > 1) Do you think it is ok that tools repo is executed after generation of
> > > docker images that are supposed to include those tools or the operator
> > that
> > > is supposed to deploy such images?
> > That's what this thread is all about... You know I'm not ok with it,
> > that's why I'm proposing the two images and the operator to move into
> > the `kie-tools` repo, where we can more granularly control the order
> > things are built and remove the dependency cycle.
> > > 2) Besides that, although not directly related with the current proposal
> > we
> > > are discussing, I really think there are some restrictions taken for
> > > granted that are arbitrary and difficult to sustain on strictly technical
> > > arguments. For example, the need to freeze the rest of the software
> > before
> > > tools are generated. Why? We have dependencies between repos that are not
> > > handled that way: Apps depend on runtimes. Runtimes depend on drools,
> > > Operator depend on runtimes,....and we are not freezing that repos since
> > we
> > > are all releasing at the same time. If we are all releasing at the same
> > > time, what's the rationale behind the freeze?
> > >
> > >
> > >
> > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <ti...@apache.org>
> > wrote:
> > >
> > > > Glad to see the interest this proposal has gotten, and it's good to
> > > > see some alternatives being drafted here, although still lacking clear
> > > > definitions and analysis in regards to disruption, required effort,
> > > > the release process itself, and history. Of course, lots of details
> > > > and clarity on the execution part would be missing too.
> > > >
> > > > As of this moment, based on what I read here, I'm assuming that
> > > > everyone who participated so far doesn't see the initial proposal as
> > > > problematic in terms of feasibility, but some of you have a preference
> > > > not to go with it, because it is "wrong", and apparently because it
> > > > would "jeopardize the evolution of the project". Reading these last
> > > > words made me a little sad, to be honest. But I can deal with it :)
> > > >
> > > > Please let's try and keep the discussion as objective as possible.
> > > > "Right" and "wrong" are too subjective for this kind of conversation.
> > > >
> > > > Now, being practical, unless there are clear arguments based on facts
> > > > and objective concepts that invalidate the initial proposal shared on
> > > > this email, it seems to me that it is currently the only viable
> > > > proposal we have for unblocking and releasing Apache KIE 10. Of
> > > > course, if we end up seeing an alternative proposal with enough
> > > > details and a clear execution plan, I think then we'll be in a very
> > > > good position to choose from multiple options!
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <al...@porcelli.me>
> > wrote:
> > > > >
> > > > > Francisco and Gabriele,
> > > > >
> > > > > I understand and acknowledge your desire to find the “right” solution
> > > > > instead to work on a temporary “patch” - however without a detailed
> > > > > proposal I don’t think we can properly evaluate the impact of your
> > > > > suggestion.
> > > > >
> > > > > When I spoke with different SMEs that included tools and CI, the
> > > > > guesstimate for making the necessary changes on CI and codebase to
> > > > > basically have images and operators in the end of the build chain is
> > > > > something like 2 months of effort. Another impact that needs to be
> > > > > discussed is that KIE Tools repo had to be injected in the middle of
> > all
> > > > > pipelines - forcing all PR checks and nightlies to build all repos
> > (PR
> > > > > checks will likely take 12+ hours… I even heard that it could be
> > even 24
> > > > > hours).
> > > > >
> > > > > Based on the input above, I think it’s quite risk to move in such
> > > > direction
> > > > > without a more detailed plan… because 2 months could be turned
> > easily in
> > > > 6!
> > > > > And this is exactly what happened when we guessed that moving to
> > Apache
> > > > > would take no more than 3 months. But here we are.
> > > > >
> > > > > I really strongly suggest that we focus on a release that could be
> > > > > achievable in less than a month from now, and we - after release -
> > have a
> > > > > in depth discussion about the overall codebase and ci organization.
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > gabriele.cardosi@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Alex,
> > > > > > my suggestion is to move the building of all docker images, from
> > > > whatever
> > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to
> > be
> > > > > > invoked after all the others.
> > > > > > I'm not sure if this would solve all the issues, and since I could
> > not
> > > > > > enter in the details of all the involved code, my suggestion may
> > be too
> > > > > > naive.
> > > > > > Having spent almost all of the last year in CI, I may say that, at
> > > > least
> > > > > > for the kie-tools repo, removing the image build step from it
> > should
> > > > not be
> > > > > > too difficult (since it is an issue we already faced and solved).
> > > > > > If, with "detailed proposal", you mean a complete list of all
> > modules
> > > > to be
> > > > > > moved and dependency refactoring, of course I can not provide it
> > right
> > > > now.
> > > > > >
> > > > > > Anyway, I share the concern from Francisco: undoing something is
> > almost
> > > > > > always harder than doing it "rightly" from scratch...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado
> > Sarti
> > > > <
> > > > > > ftirados@redhat.com> ha scritto:
> > > > > >
> > > > > > > I do not think estimations should be the only driver to make a
> > > > decision,
> > > > > > > especially when the current proposal is conceptually incompatible
> > > > with
> > > > > > the
> > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > Given my knowledge of the CI it is nearly impossible for me to
> > give
> > > > a
> > > > > > fair
> > > > > > > estimate of how much it might take to achieve step 2) of my
> > previous
> > > > > > e-mail
> > > > > > > . It might take a while or it might be pretty easy after all, I
> > don't
> > > > > > > really know, but I think it will be a good idea if some of the
> > > > experts
> > > > > > on
> > > > > > > CI in the team (the ones that set up the pipeline, which was a
> > huge
> > > > > > > achievement) give an estimate, not me. Estimating how much it
> > takes
> > > > to
> > > > > > > merge two existing repos (without altering CI) is easier, but it
> > > > does not
> > > > > > > mean we are doing the right thing.
> > > > > > > My main concern is that it will be very difficult for me to
> > explain
> > > > to
> > > > > > > someone that arrives new to the team, that having experts on CI
> > on
> > > > the
> > > > > > > team, we decided to merge two repos (once merged, it would be
> > rather
> > > > > > > difficult to unmerge) rather than fix the CI, because of
> > expediency.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > porcelli@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Francisco,
> > > > > > > >
> > > > > > > > Please take the time to make the more in depth analysis needed
> > and
> > > > > > > provide
> > > > > > > > a more detailed plan… so we - as community- can evaluate the
> > size
> > > > of
> > > > > > the
> > > > > > > > effort. In the conceptual level you shared it’s near
> > impossible to
> > > > > > > estimate
> > > > > > > > the size of the effort and compare with the current proposal.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > >
> > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > 1) Remove all dependencies from tooling to images, so images
> > > > depend
> > > > > > on
> > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > 2) Then change CI to deal with tooling repo before dealing
> > with
> > > > > > images
> > > > > > > > > repo.
> > > > > > > > > I understand that CI details are tricky and since I'm not
> > > > familiar
> > > > > > with
> > > > > > > > CI
> > > > > > > > > in any way, I barely can make a low level design, but we do
> > not
> > > > need
> > > > > > to
> > > > > > > > fix
> > > > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > alex@porcelli.me
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > >
> > > > > > > > > > You may not like or understand why the current state of
> > the CI
> > > > is
> > > > > > > like
> > > > > > > > > > that… actually has been in Red Hat and has been replicated
> > in
> > > > > > Apache
> > > > > > > as
> > > > > > > > > > used to be….
> > > > > > > > > >
> > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > >
> > > > > > > > > > If you disagree with the current plan, please provide a
> > > > detailed
> > > > > > > > > > alternative so we, as community, can better evaluate the
> > pros
> > > > and
> > > > > > > cons
> > > > > > > > of
> > > > > > > > > > each proposal.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I think it’s also fair to say that, post 10 release we
> > need to
> > > > > > have a
> > > > > > > > > much
> > > > > > > > > > in depth discussion about how our codebase is organized,
> > it’s
> > > > clear
> > > > > > > > that
> > > > > > > > > > it’s not working.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > As Francisco said,
> > > > > > > > > > > I also have the impression that the "images" (if we are
> > > > talking
> > > > > > of
> > > > > > > > > docker
> > > > > > > > > > > images) should be the very last one to be built, in a
> > > > standalone
> > > > > > > > repo.
> > > > > > > > > > > That way, they may "combine" artifacts that are built in
> > > > > > different
> > > > > > > > > repos,
> > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> > > > maybe
> > > > > > > could
> > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > (I also think there are some statements of undisputable
> > needs
> > > > > > while
> > > > > > > > > they
> > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > discussion.)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > > > Tirado
> > > > > > > > Sarti
> > > > > > > > > <
> > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > >
> > > > > > > > > > > > Alex,
> > > > > > > > > > > > There are two assumptions that deserve further
> > discussion:
> > > > > > > > > > > > 1) That tool has to be the last to build. why? it does
> > not
> > > > have
> > > > > > > > more
> > > > > > > > > > > sense
> > > > > > > > > > > > to build final images after everything else has been
> > > > built?-
> > > > > > > > > > > > 2) That the impact (in terms of effort now) on fixing
> > CI is
> > > > > > > bigger
> > > > > > > > > than
> > > > > > > > > > > the
> > > > > > > > > > > > impact (long term consequences) of consolidating two
> > > > unrelated
> > > > > > > > piece
> > > > > > > > > of
> > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > alex@porcelli.me
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > >
> > > > > > > > > > > > > This was discussed as an alternative solution,
> > however
> > > > it has
> > > > > > > > major
> > > > > > > > > > > > impact
> > > > > > > > > > > > > on CI and there’s also the fact Tool has been always
> > the
> > > > last
> > > > > > > to
> > > > > > > > > > build
> > > > > > > > > > > > and
> > > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> > world
> > > > there
> > > > > > > is
> > > > > > > > no
> > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > >
> > > > > > > > > > > > > So, based on our evaluation… the proposal here is the
> > > > least
> > > > > > > > > > disruptive
> > > > > > > > > > > > and
> > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > _____________
> > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> > Tirado
> > > > > > Sarti <
> > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > embracing
> > > > the
> > > > > > fact
> > > > > > > > > that
> > > > > > > > > > > > > > kogito-images depend on kie-tools, because we want
> > > > those
> > > > > > > images
> > > > > > > > > to
> > > > > > > > > > > > > include
> > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > > > Tirado
> > > > > > > Sarti
> > > > > > > > <
> > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > kn-plugin-workflow
> > > > > > > > to
> > > > > > > > > > > > > > > kogito-images (so there is not longer dependency
> > from
> > > > > > tools
> > > > > > > > to
> > > > > > > > > > > > images)
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > > > > Martinez
> > > > > > > <
> > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > (apache)
> > > > <
> > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > > > > alex@porcelli.me
> > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > I spent the last day or so working closely
> > with
> > > > > > Tiago,
> > > > > > > > > > > exploring
> > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > > > > evaluating
> > > > > > > > > the
> > > > > > > > > > > > > overall
> > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > > proposal
> > > > > > as
> > > > > > > > the
> > > > > > > > > > > most
> > > > > > > > > > > > > > >> > > viable option for unblocking the 10 release
> > in
> > > > the
> > > > > > > > > > reasonable
> > > > > > > > > > > > time
> > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento
> > <
> > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> > time,
> > > > as
> > > > > > this
> > > > > > > > > > matter
> > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes to
> > read,
> > > > > > > > according
> > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > thread
> > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > >
> > > > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > >> > > > many of us were working towards removing a
> > > > > > circular
> > > > > > > > > > > dependency
> > > > > > > > > > > > > > >> > > > currently present between `kogito-apps`
> > and
> > > > > > > > `kie-tools`.
> > > > > > > > > > As
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > > > finding the
> > > > > > > > > > circular
> > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > breakdown of
> > > > the
> > > > > > > > things
> > > > > > > > > > we
> > > > > > > > > > > > did,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Right now, even though we started the
> > effort
> > > > to
> > > > > > move
> > > > > > > > the
> > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> > > > able to
> > > > > > > do
> > > > > > > > it
> > > > > > > > > > > yet,
> > > > > > > > > > > > as
> > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> > > > Maven
> > > > > > > 3.9.6,
> > > > > > > > > and
> > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > This
> > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > > >> > > >
> > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > .
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > C | 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > Y | 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > depend
> > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > > `kie-tools`,
> > > > > > we
> > > > > > > > > > would've
> > > > > > > > > > > > > had:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > C |==> 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/kn-plugin-workflow
> > > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > >> > > > * and
> > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > depends
> > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> > image to
> > > > > > > > > > `kie-tools`,
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/kn-plugin-workflow
> > > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> > than a
> > > > > > simple
> > > > > > > > > > > circular
> > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > > > people,
> > > > > > > > it's
> > > > > > > > > > been
> > > > > > > > > > > > > > really
> > > > > > > > > > > > > > >> > > > hard coming up with a simple solution that
> > > > makes
> > > > > > it
> > > > > > > > > > possible
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving
> > the
> > > > way
> > > > > > > > > everyone
> > > > > > > > > > is
> > > > > > > > > > > > > used
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > contributing to the multiple repositories
> > we
> > > > have.
> > > > > > > > More
> > > > > > > > > > than
> > > > > > > > > > > > > that,
> > > > > > > > > > > > > > >> > > > while making this assessment, I found more
> > > > > > problems
> > > > > > > > > that,
> > > > > > > > > > in
> > > > > > > > > > > > my
> > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > > > forward
> > > > > > with
> > > > > > > > my
> > > > > > > > > > > > proposal
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we can
> > use
> > > > > > > Apache's
> > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> > > > this
> > > > > > > really
> > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective about
> > the
> > > > > > current
> > > > > > > > > > > situation
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > currently
> > > > see.
> > > > > > > > I'll
> > > > > > > > > > > start
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > > purposes,
> > > > > > > point
> > > > > > > > > out
> > > > > > > > > > > > some
> > > > > > > > > > > > > > >> > > > problems that I believe are blocking our
> > 10
> > > > > > release,
> > > > > > > > > > explain
> > > > > > > > > > > > my
> > > > > > > > > > > > > > >> > > > proposal and discuss some consequences to
> > > > what I'm
> > > > > > > > > > > proposing.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count:
> > 11)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> > > > `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-serverless-operator @
> > > > > > `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > >> > > > -
> > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > `0.0.0`
> > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > updated @
> > > > > > `main`.
> > > > > > > > > Same
> > > > > > > > > > > for
> > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy
> > at
> > > > the
> > > > > > > > `main`
> > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`.
> > Push @
> > > > > > > > `deploy`
> > > > > > > > > to
> > > > > > > > > > > > > update
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > sandbox.kie.org
> > > > > > and
> > > > > > > > KIE
> > > > > > > > > > > Tools'
> > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @
> > `main`
> > > > > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> > > > checks
> > > > > > > > during
> > > > > > > > > > the
> > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I grouped the repositories by category,
> > and
> > > > listed
> > > > > > > > them
> > > > > > > > > > in a
> > > > > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > > > > flattening
> > > > > > > > > out a
> > > > > > > > > > > > tree,
> > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > > > OptaPlanner
> > > > > > > > > > > could've
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > referring
> > > > to
> > > > > > as
> > > > > > > > > > `drools`
> > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner
> > is
> > > > inside
> > > > > > > > that
> > > > > > > > > > > > stream,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > way these repositories reference each
> > other
> > > > are
> > > > > > > > through
> > > > > > > > > > > Maven
> > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > 999-SNAPSHOT
> > > > > > > > version.
> > > > > > > > > > This
> > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > >> > > > is well-known to the team, and although
> > > > flawed for
> > > > > > > > > > intra-day
> > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > different
> > > > time
> > > > > > > > zones,
> > > > > > > > > it
> > > > > > > > > > > is
> > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> > with, I
> > > > > > > assume.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > > > > dedicated
> > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> > build
> > > > > > > cross-repo
> > > > > > > > > PRs
> > > > > > > > > > > > > > together
> > > > > > > > > > > > > > >> > > > and verify that the codebase will continue
> > > > working
> > > > > > > as
> > > > > > > > > > > expected
> > > > > > > > > > > > > > after
> > > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > gather,
> > > > > > there
> > > > > > > > are
> > > > > > > > > > some
> > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > cross-repo
> > > > > > > PRs.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps,
> > and
> > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to
> > any
> > > > > > > > > combination
> > > > > > > > > > of
> > > > > > > > > > > > > repos
> > > > > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > > > cannot
> > > > > > be
> > > > > > > > > > > verified
> > > > > > > > > > > > > > before
> > > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > > dependent
> > > > > > on
> > > > > > > > > > > individual
> > > > > > > > > > > > > > >> > > > contributors building stuff on their
> > machines
> > > > to
> > > > > > > > verify
> > > > > > > > > > that
> > > > > > > > > > > > it
> > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > > > > pipelines,
> > > > > > > > so
> > > > > > > > > > > > please
> > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > referring
> > > > to
> > > > > > as
> > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > > > > repository
> > > > > > > > > that
> > > > > > > > > > > is
> > > > > > > > > > > > > used
> > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > >> > > > people starting projects from scratch on
> > KIE
> > > > > > > Sandbox,
> > > > > > > > > > > similar
> > > > > > > > > > > > > to a
> > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The other
> > one
> > > > is the
> > > > > > > KIE
> > > > > > > > > > Tools
> > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> > build
> > > > > > system.
> > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > > TypeScript
> > > > > > > > > libraries
> > > > > > > > > > > and
> > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > > > > `kie-tools`
> > > > > > > > > > > monorepo
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > >> > > > configured to work with sparse checkouts
> > and
> > > > can
> > > > > > do
> > > > > > > > > > partial
> > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > > > through
> > > > > > > > > > > timestamped
> > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > recently
> > > > > > > > > introduced
> > > > > > > > > > > that
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > > artifacts
> > > > > > > > under
> > > > > > > > > a
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> > format,
> > > > > > > published
> > > > > > > > > > weekly
> > > > > > > > > > > > > every
> > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > > > > evolution
> > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > release
> > > > for
> > > > > > all
> > > > > > > > of
> > > > > > > > > > > Apache
> > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > An important note here is that Category B
> > > > > > > repositories
> > > > > > > > > > have
> > > > > > > > > > > > been
> > > > > > > > > > > > > > >> > > > historically kept out of any automations
> > we
> > > > used
> > > > > > to
> > > > > > > > > have,
> > > > > > > > > > > way
> > > > > > > > > > > > > back
> > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > Business
> > > > > > Central
> > > > > > > > > > (a.k.a.
> > > > > > > > > > > > v7)
> > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > >> > > > still going on. For this reason, Category
> > B
> > > > > > projects
> > > > > > > > > have
> > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > > Actions.
> > > > > > > > > Category B
> > > > > > > > > > > > repos
> > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > >> > > > always depended on Category A repos using
> > > > fixed
> > > > > > > > > versions.
> > > > > > > > > > If
> > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > SNAPSHOTs,
> > > > > > breaking
> > > > > > > > > > changes
> > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > > potential
> > > > > > > to
> > > > > > > > > > break
> > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > > > > development
> > > > > > > > > > > stream,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > > maintainers
> > > > > > of
> > > > > > > > > > > Category B
> > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > >> > > > as historically Category A contributors
> > were
> > > > not
> > > > > > > > > familiar
> > > > > > > > > > > with
> > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > > > through
> > > > > > a
> > > > > > > > > GitHub
> > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > >> > > > workflow that builds the relevant part of
> > the
> > > > > > > > > `kie-tools`
> > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > >> > > > the changes introduced. Changes made to
> > the
> > > > > > pipeline
> > > > > > > > > > itself
> > > > > > > > > > > > are
> > > > > > > > > > > > > > also
> > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to
> > do
> > > > things
> > > > > > > > like
> > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > >> > > > bumping the Node.js version, for example.
> > More
> > > > > > > > > > importantly,
> > > > > > > > > > > it
> > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > timestamped
> > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > together
> > > > > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > > > green.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This setup, however, makes it impossible
> > to
> > > > have
> > > > > > > > > > cross-repo
> > > > > > > > > > > > PRs
> > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > simultaneously,
> > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > > > > > current
> > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > around,
> > > > and
> > > > > > > I'm
> > > > > > > > > not
> > > > > > > > > > > sure
> > > > > > > > > > > > > if
> > > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > Regardless,
> > > > > > as
> > > > > > > > > > they're
> > > > > > > > > > > > > part
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > release,
> > > > so I
> > > > > > > > > listed
> > > > > > > > > > > them
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category D is self explanatory. There's
> > only
> > > > one
> > > > > > > repo
> > > > > > > > > that
> > > > > > > > > > > has
> > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > > > > directly,
> > > > > > > > and
> > > > > > > > > > are
> > > > > > > > > > > > > > either
> > > > > > > > > > > > > > >> > > > organizational entities, or host websites,
> > > > that
> > > > > > > > > currently
> > > > > > > > > > > are
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This lack of unification between Category
> > A
> > > > and
> > > > > > > > > Category B
> > > > > > > > > > > is,
> > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > > > circular
> > > > > > > > > > > dependency
> > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we
> > now
> > > > can
> > > > > > > > describe
> > > > > > > > > > as
> > > > > > > > > > > a
> > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > >> > > > dependency between Category A and
> > Category B.
> > > > The
> > > > > > > way
> > > > > > > > I
> > > > > > > > > > see
> > > > > > > > > > > > it,
> > > > > > > > > > > > > if
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > had a single pipeline, building everything
> > > > from
> > > > > > > > `drools`
> > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> > been
> > > > > > > > introduced,
> > > > > > > > > > and
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem in
> > our
> > > > hands
> > > > > > > > right
> > > > > > > > > > now.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > process
> > > > > > sees
> > > > > > > > this
> > > > > > > > > > > lack
> > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > unification as a central problem, not
> > only for
> > > > > > this
> > > > > > > > > > release
> > > > > > > > > > > in
> > > > > > > > > > > > > > >> > > > particular, but for the community as a
> > whole.
> > > > It
> > > > > > is
> > > > > > > my
> > > > > > > > > > > belief
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > > > contribution
> > > > > > > > > > should
> > > > > > > > > > > > be
> > > > > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> > > > With
> > > > > > the
> > > > > > > > > > > increasing
> > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > contributors
> > > > too,
> > > > > > > we
> > > > > > > > > > cannot
> > > > > > > > > > > > > keep
> > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> > breaking
> > > > > > things.
> > > > > > > > > We're
> > > > > > > > > > > all
> > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > > mechanisms in
> > > > > > > > place
> > > > > > > > > > to
> > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> > Especially
> > > > when
> > > > > > > > these
> > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > > > individually,
> > > > > > > > > > > > probably
> > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > depending
> > > > on
> > > > > > > > > > kiegroup's
> > > > > > > > > > > > KIE
> > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > > `kogito-images`
> > > > > > > > > > > depending
> > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > > > > kiegroup's
> > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > `7.59.0.Final`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > > depending on
> > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > > codebase
> > > > > > > here:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >
> > > > > > > > >
> > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > ,
> > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > OptaPlanner,
> > > > > > > > > > pointing
> > > > > > > > > > > to
> > > > > > > > > > > > > > older
> > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P5.
> > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > depending
> > > > > > > > > > on
> > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P6. Category C repos are out of date and
> > not
> > > > part
> > > > > > of
> > > > > > > > the
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > > A
> > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> > (Current
> > > > > > version
> > > > > > > is
> > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > > version,
> > > > > > only
> > > > > > > > by
> > > > > > > > > > > using
> > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> > version
> > > > is
> > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > > OptaPlanner
> > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P7.
> > `kie-tools`/packages/kn-plugin-workflow
> > > > has
> > > > > > its
> > > > > > > > E2E
> > > > > > > > > > > > disabled
> > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > > > > solution,
> > > > > > > > as
> > > > > > > > > > they
> > > > > > > > > > > > > both
> > > > > > > > > > > > > > >> > > > suffer from the circular dependency
> > between
> > > > > > > Category A
> > > > > > > > > and
> > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > >> > > > As Category A and Category B are both
> > streams
> > > > that
> > > > > > > > have
> > > > > > > > > > been
> > > > > > > > > > > > > > really
> > > > > > > > > > > > > > >> > > > active, I see this as a blocker, as there
> > are
> > > > > > > > > > contributions
> > > > > > > > > > > > that
> > > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> > depends
> > > > on
> > > > > > > > > Category
> > > > > > > > > > B
> > > > > > > > > > > > > with a
> > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > > understood
> > > > > > as
> > > > > > > > > > > technical
> > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > > something
> > > > > > > we'll
> > > > > > > > > > always
> > > > > > > > > > > > be
> > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> > just a
> > > > > > matter
> > > > > > > of
> > > > > > > > > > > making
> > > > > > > > > > > > > them
> > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> > impact
> > > > the
> > > > > > > > > structure
> > > > > > > > > > or
> > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > > > > regression
> > > > > > > > we
> > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> > Apache
> > > > KIE
> > > > > > 10,
> > > > > > > > and
> > > > > > > > > > > that
> > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems
> > > > left to
> > > > > > > > > discuss
> > > > > > > > > > > are
> > > > > > > > > > > > P1
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > > > proposal.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> > > > from my
> > > > > > > > > > > experience,
> > > > > > > > > > > > > any
> > > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> > release
> > > > not
> > > > > > > > > working
> > > > > > > > > > > out
> > > > > > > > > > > > in
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > > possible,
> > > > > > and
> > > > > > > > make
> > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > > release,
> > > > > > bear
> > > > > > > > > with
> > > > > > > > > > > me.
> > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > >> > > > out a timeline of events that need to
> > happen
> > > > in
> > > > > > > order
> > > > > > > > > for
> > > > > > > > > > > our
> > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > >> > > > to be published, with all artifacts
> > ending up
> > > > in
> > > > > > the
> > > > > > > > > right
> > > > > > > > > > > > > places,
> > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > >> > > > first, we need to solve problems P1 and
> > P2.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As you saw at the beginning of this email,
> > > > all the
> > > > > > > > > > attempts
> > > > > > > > > > > we
> > > > > > > > > > > > > > made
> > > > > > > > > > > > > > >> > > > left us with the circular dependency
> > showing
> > > > up
> > > > > > at a
> > > > > > > > > > > different
> > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > >> > > > but something all these places have in
> > common
> > > > is
> > > > > > > that
> > > > > > > > > > > they're
> > > > > > > > > > > > > all
> > > > > > > > > > > > > > >> > > > after kogito-apps, and before to Category
> > B.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > > following:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > S1. We keep the original plan of moving
> > the
> > > > > > Quarkus
> > > > > > > > Dev
> > > > > > > > > > UIs
> > > > > > > > > > > > from
> > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> > with
> > > > > > > Management
> > > > > > > > > and
> > > > > > > > > > > > Task
> > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> > `kie-tools`.
> > > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > images
> > > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > `kogito-serverless-operator`
> > > > > > > > repo
> > > > > > > > > > > > inside
> > > > > > > > > > > > > a
> > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> > history.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> > > > problems
> > > > > > P1
> > > > > > > > and
> > > > > > > > > > P2.
> > > > > > > > > > > Of
> > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > >>
> > > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This doesn't come without consequences, of
> > > > course,
> > > > > > > as
> > > > > > > > > the
> > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > `kogito-swf-builder`
> > > > > > > images,
> > > > > > > > > and
> > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be
> > moving
> > > > from
> > > > > > > > > > Category A
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > Category B. This move would make them
> > have to
> > > > > > > > reference
> > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > > > > `kogito-images`
> > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are already
> > > > their own
> > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > >> > > > Category A, though, contributions made in
> > a
> > > > > > > cross-repo
> > > > > > > > > > > fashion
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> > possible, now
> > > > > > via a
> > > > > > > > > > single
> > > > > > > > > > > PR
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> > Category
> > > > A and
> > > > > > > > > > Category
> > > > > > > > > > > B
> > > > > > > > > > > > > will
> > > > > > > > > > > > > > >> > > > continue not being possible, and a 1-week
> > > > delay
> > > > > > > > between
> > > > > > > > > > > > merging
> > > > > > > > > > > > > > >> > > > something on Category A and using it on
> > > > Category B
> > > > > > > > will
> > > > > > > > > > > still
> > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> > > > however,
> > > > > > > does
> > > > > > > > > > allow
> > > > > > > > > > > > for
> > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > >> > > > checkouts and partial builds, so working
> > with
> > > > a
> > > > > > > subset
> > > > > > > > > of
> > > > > > > > > > > the
> > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > >> > > > is possible and encouraged. Making changes
> > > > only to
> > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> > example,
> > > > will
> > > > > > > have
> > > > > > > > > the
> > > > > > > > > > PR
> > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > >> > > > We're not compromising when running
> > partial
> > > > builds
> > > > > > > > too.
> > > > > > > > > We
> > > > > > > > > > > > know
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > >> > > > the entire repo will continue working even
> > > > after
> > > > > > > only
> > > > > > > > > > > > building a
> > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > >> > > > subset of the changes. Doing partial or
> > full
> > > > > > builds
> > > > > > > is
> > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> > proposing
> > > > we
> > > > > > > move a
> > > > > > > > > > bunch
> > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see
> > this
> > > > as a
> > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host
> > some
> > > > > > > > additional
> > > > > > > > > > > stuff
> > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > > continue
> > > > > > > moving
> > > > > > > > > > > > forward.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As I mentioned on other places,
> > `kie-tools`
> > > > > > became a
> > > > > > > > > > > polyglot
> > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > >> > > > out of necessity, and although I'm really
> > > > proud of
> > > > > > > > what
> > > > > > > > > we
> > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > >> > > > there so far, I don't think `kie-tools`
> > has a
> > > > > > setup
> > > > > > > > that
> > > > > > > > > > is
> > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > >> > > > for all the different nuances that
> > compose our
> > > > > > > > > community.
> > > > > > > > > > > I'm
> > > > > > > > > > > > > well
> > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that does
> > not
> > > > > > follow
> > > > > > > > > > > widespread
> > > > > > > > > > > > > > >> > > > conventions will scare some people away,
> > and
> > > > as
> > > > > > much
> > > > > > > > as
> > > > > > > > > > > we've
> > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > >> > > > make build instructions clear, we can't
> > > > always get
> > > > > > > > past
> > > > > > > > > > the
> > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > > > > ecosystem.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > With all that said, I keep thinking this
> > is
> > > > the
> > > > > > best
> > > > > > > > > > course
> > > > > > > > > > > of
> > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > >> > > > for us right now. We keep most of our
> > stuff
> > > > > > > unchanged,
> > > > > > > > > we
> > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > release, and we have a working setup that
> > will
> > > > > > suit
> > > > > > > us
> > > > > > > > > > well
> > > > > > > > > > > > > while
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > discuss and reach a conclusion regarding
> > the
> > > > > > future
> > > > > > > of
> > > > > > > > > our
> > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Let me paint a quick picture here of what
> > our
> > > > code
> > > > > > > > base
> > > > > > > > > > > would
> > > > > > > > > > > > > look
> > > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > > > accepted:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > B
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > > > > >> > > > E
> > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * Category C becomes part of Category A,
> > and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> > entirely
> > > > inside
> > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> > images
> > > > and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > > `kie-tools`,
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > > no
> > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > > granularly
> > > > > > > > build:
> > > > > > > > > > > > > > >> > > > 1.
> > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> > (containing
> > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> > (contents
> > > > from
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The second part of the proposal is the
> > release
> > > > > > > process
> > > > > > > > > > > itself,
> > > > > > > > > > > > > > >> > > > assuming the structure above is what we
> > have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be
> > used as
> > > > > > > cutting
> > > > > > > > > > point
> > > > > > > > > > > > for
> > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to
> > this
> > > > > > > > timestamped
> > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > > >> > > > 3. At this point, with everything
> > working, we
> > > > can
> > > > > > > > branch
> > > > > > > > > > out
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> > > > SNAPSHOT
> > > > > > > > tag,
> > > > > > > > > > and
> > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> > update
> > > > > > their
> > > > > > > > > > versions
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > > Category A
> > > > > > > > repos
> > > > > > > > > > > using
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the
> > release
> > > > based
> > > > > > > on
> > > > > > > > > the
> > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > >> > > > branches, given we don't expect any code
> > > > changes
> > > > > > > > > anymore.
> > > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to
> > start
> > > > the
> > > > > > > > release
> > > > > > > > > > > > process.
> > > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > manual/automated
> > > > > > > > > release
> > > > > > > > > > > > > process,
> > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > pushed
> > > > to
> > > > > > Git,
> > > > > > > > and
> > > > > > > > > > > built
> > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > > artifacts
> > > > > > to
> > > > > > > be
> > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > manual/automated
> > > > > > > > > release
> > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > pushed
> > > > to
> > > > > > Git,
> > > > > > > > and
> > > > > > > > > > > built
> > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > > >> > > > 12. Category E repos can be manually
> > tagged
> > > > with
> > > > > > > > 10.0.0
> > > > > > > > > > from
> > > > > > > > > > > > > their
> > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > More needs to be discussed if we're
> > planning
> > > > to
> > > > > > > > maintain
> > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > >> > > > release streams in parallel, but I guess
> > it
> > > > can
> > > > > > wait
> > > > > > > > for
> > > > > > > > > > > after
> > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> > > > forward to
> > > > > > > > > hearing
> > > > > > > > > > > back
> > > > > > > > > > > > > > from
> > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Of course, alternative solutions are
> > possible.
> > > > > > This
> > > > > > > > > email,
> > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > >> > > > summarizes my view of how we should
> > attack the
> > > > > > > > problem,
> > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > >> > > > disruption, required effort, the release
> > > > process
> > > > > > > > itself,
> > > > > > > > > > and
> > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > >> > > > Feel free to propose alternatives. This is
> > > > not a
> > > > > > > > voting
> > > > > > > > > > > > thread.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Yes, I agree,
I think we should try to achieve this (it is pretty schematic view that
only correspond tangentially with real repo name):
examples->operator->images->tools->app(services)->runtimes(kogito-api)->drools(kie-api)
What we will have once the current proposal is implemented will be: tools
(including examples that use tools, operator, image generator, somehow
organized using the repo ci)->examples(without
tools)->app(services)->runtimes(kogito-api)->drools(kie-api)
Again, as far as there is clear direction, for the whole team, to try to
achieve the first picture, I guess we can try, because of time constraints,
to release with the second one (if it really take just 3 weeks to make it
work), although I really find it difficult to justify if someone from
community complains (specially because community is waiting something
consistent after such a long time).
On Wed, Mar 13, 2024 at 3:55 PM Gabriele Cardosi <ga...@gmail.com>
wrote:
> I have the impression there are still two different POV.
> On one side, I agree that we should try to make the release ASAP. But we
> should also consider that if we release something that may create problems
> to the community itself, just for the rush of it, then the community would
> be much more disappointed.
> On the other side, I think the concern is to keep transforming a temporary
> solution, that was not the only possible one, to the only possible one,
> i.e. that kie-tools become the central point of delivery, with a
> Frankenstein effect whose consequences in long term are hard to imagine.
> So, maybe if we can make a sort of agreement that everything would be
> revisited "after the release", with a sort of "task force" that analyzes
> everything from scratch, and that includes all the ones that are involved
> by it, we could break this deadlock.
> WDYT ?
>
> Il giorno mer 13 mar 2024 alle ore 15:41 Francisco Javier Tirado Sarti <
> ftirados@redhat.com> ha scritto:
>
> > 1) Ok, if that is the case, I do not get why your first proposal was not
> > the one I'm proposing and it is apparently not detailed enough. To move
> > kn-workflow from tooling to operator one and change the order in which
> the
> > repos are being processed. Basically, the problem of the proposed
> solution
> > is that it kind of converts tooling repo into a pretty heterodox repo
> > compared with runtimes, drools or operator one. Also once tooling is not
> a
> > final repo in the overall chain, we can consider moving examples as the
> > final one and include tooling showcases there (rather than splitting
> > examples into examples with tooling and examples without tooling).
> > 2) I think this distinction between A and B is one between several
> possible
> > categorizations (not much, including no categorization at all) that
> > deserves a separate discussion. I will open a separate thread for that
> > purpose, since we are not going to change that now and it is not really
> > part of the proposal.
> >
> > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
> tiagobentofernandes@gmail.com
> > >
> > wrote:
> >
> > > Francisco,
> > >
> > > 1) That's what this thread is all about... You know I don't think it's
> > > ok. That's why I'm proposing the two images and the operator to move
> > > into the `kie-tools` repo, where we can more granularly control the
> > > order things are built, thus removing the dependency cycle.
> > >
> > > 2) Not sure we understand the same thing by "freeze". My proposal is
> > > that we select a timestamped SNAPSHOT version from Category A repos to
> > > use as base for a release. We give Category B repos some time to
> > > adjust, and then cut the release branches. This can happen anytime,
> > > and no contributions would ever stop because of it. The development
> > > branches can continue accepting PRs normally, even during the release
> > > process. Now, if what you're asking is why Category B repos refer to
> > > Category A repos via timestamped SNAPSHOTs, the answer is in my first
> > > email. See the paragraph starting with "An important note here is that
> > > Category B repositories...".
> > >
> > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti
> > > <ft...@redhat.com> wrote:
> > > >
> > > > Tiago
> > > > There are a couple of simple and straightforward questions that I
> > > > formulated, but since we both write a lot, it might have been lost.
> > > Please
> > > > let me ask them again.
> > > > 1) Do you think it is ok that tools repo is executed after generation
> > of
> > > > docker images that are supposed to include those tools or the
> operator
> > > that
> > > > is supposed to deploy such images?
> > > That's what this thread is all about... You know I'm not ok with it,
> > > that's why I'm proposing the two images and the operator to move into
> > > the `kie-tools` repo, where we can more granularly control the order
> > > things are built and remove the dependency cycle.
> > > > 2) Besides that, although not directly related with the current
> > proposal
> > > we
> > > > are discussing, I really think there are some restrictions taken for
> > > > granted that are arbitrary and difficult to sustain on strictly
> > technical
> > > > arguments. For example, the need to freeze the rest of the software
> > > before
> > > > tools are generated. Why? We have dependencies between repos that are
> > not
> > > > handled that way: Apps depend on runtimes. Runtimes depend on drools,
> > > > Operator depend on runtimes,....and we are not freezing that repos
> > since
> > > we
> > > > are all releasing at the same time. If we are all releasing at the
> same
> > > > time, what's the rationale behind the freeze?
> > > >
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <ti...@apache.org>
> > > wrote:
> > > >
> > > > > Glad to see the interest this proposal has gotten, and it's good to
> > > > > see some alternatives being drafted here, although still lacking
> > clear
> > > > > definitions and analysis in regards to disruption, required effort,
> > > > > the release process itself, and history. Of course, lots of details
> > > > > and clarity on the execution part would be missing too.
> > > > >
> > > > > As of this moment, based on what I read here, I'm assuming that
> > > > > everyone who participated so far doesn't see the initial proposal
> as
> > > > > problematic in terms of feasibility, but some of you have a
> > preference
> > > > > not to go with it, because it is "wrong", and apparently because it
> > > > > would "jeopardize the evolution of the project". Reading these last
> > > > > words made me a little sad, to be honest. But I can deal with it :)
> > > > >
> > > > > Please let's try and keep the discussion as objective as possible.
> > > > > "Right" and "wrong" are too subjective for this kind of
> conversation.
> > > > >
> > > > > Now, being practical, unless there are clear arguments based on
> facts
> > > > > and objective concepts that invalidate the initial proposal shared
> on
> > > > > this email, it seems to me that it is currently the only viable
> > > > > proposal we have for unblocking and releasing Apache KIE 10. Of
> > > > > course, if we end up seeing an alternative proposal with enough
> > > > > details and a clear execution plan, I think then we'll be in a very
> > > > > good position to choose from multiple options!
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > > >
> > > > > > Francisco and Gabriele,
> > > > > >
> > > > > > I understand and acknowledge your desire to find the “right”
> > solution
> > > > > > instead to work on a temporary “patch” - however without a
> detailed
> > > > > > proposal I don’t think we can properly evaluate the impact of
> your
> > > > > > suggestion.
> > > > > >
> > > > > > When I spoke with different SMEs that included tools and CI, the
> > > > > > guesstimate for making the necessary changes on CI and codebase
> to
> > > > > > basically have images and operators in the end of the build chain
> > is
> > > > > > something like 2 months of effort. Another impact that needs to
> be
> > > > > > discussed is that KIE Tools repo had to be injected in the middle
> > of
> > > all
> > > > > > pipelines - forcing all PR checks and nightlies to build all
> repos
> > > (PR
> > > > > > checks will likely take 12+ hours… I even heard that it could be
> > > even 24
> > > > > > hours).
> > > > > >
> > > > > > Based on the input above, I think it’s quite risk to move in such
> > > > > direction
> > > > > > without a more detailed plan… because 2 months could be turned
> > > easily in
> > > > > 6!
> > > > > > And this is exactly what happened when we guessed that moving to
> > > Apache
> > > > > > would take no more than 3 months. But here we are.
> > > > > >
> > > > > > I really strongly suggest that we focus on a release that could
> be
> > > > > > achievable in less than a month from now, and we - after release
> -
> > > have a
> > > > > > in depth discussion about the overall codebase and ci
> organization.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > gabriele.cardosi@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Alex,
> > > > > > > my suggestion is to move the building of all docker images,
> from
> > > > > whatever
> > > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo,
> to
> > > be
> > > > > > > invoked after all the others.
> > > > > > > I'm not sure if this would solve all the issues, and since I
> > could
> > > not
> > > > > > > enter in the details of all the involved code, my suggestion
> may
> > > be too
> > > > > > > naive.
> > > > > > > Having spent almost all of the last year in CI, I may say
> that,
> > at
> > > > > least
> > > > > > > for the kie-tools repo, removing the image build step from it
> > > should
> > > > > not be
> > > > > > > too difficult (since it is an issue we already faced and
> solved).
> > > > > > > If, with "detailed proposal", you mean a complete list of all
> > > modules
> > > > > to be
> > > > > > > moved and dependency refactoring, of course I can not provide
> it
> > > right
> > > > > now.
> > > > > > >
> > > > > > > Anyway, I share the concern from Francisco: undoing something
> is
> > > almost
> > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier
> Tirado
> > > Sarti
> > > > > <
> > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > >
> > > > > > > > I do not think estimations should be the only driver to make
> a
> > > > > decision,
> > > > > > > > especially when the current proposal is conceptually
> > incompatible
> > > > > with
> > > > > > > the
> > > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > > Given my knowledge of the CI it is nearly impossible for me
> to
> > > give
> > > > > a
> > > > > > > fair
> > > > > > > > estimate of how much it might take to achieve step 2) of my
> > > previous
> > > > > > > e-mail
> > > > > > > > . It might take a while or it might be pretty easy after
> all, I
> > > don't
> > > > > > > > really know, but I think it will be a good idea if some of
> the
> > > > > experts
> > > > > > > on
> > > > > > > > CI in the team (the ones that set up the pipeline, which was
> a
> > > huge
> > > > > > > > achievement) give an estimate, not me. Estimating how much
> it
> > > takes
> > > > > to
> > > > > > > > merge two existing repos (without altering CI) is easier, but
> > it
> > > > > does not
> > > > > > > > mean we are doing the right thing.
> > > > > > > > My main concern is that it will be very difficult for me to
> > > explain
> > > > > to
> > > > > > > > someone that arrives new to the team, that having experts on
> CI
> > > on
> > > > > the
> > > > > > > > team, we decided to merge two repos (once merged, it would be
> > > rather
> > > > > > > > difficult to unmerge) rather than fix the CI, because of
> > > expediency.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > porcelli@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco,
> > > > > > > > >
> > > > > > > > > Please take the time to make the more in depth analysis
> > needed
> > > and
> > > > > > > > provide
> > > > > > > > > a more detailed plan… so we - as community- can evaluate
> the
> > > size
> > > > > of
> > > > > > > the
> > > > > > > > > effort. In the conceptual level you shared it’s near
> > > impossible to
> > > > > > > > estimate
> > > > > > > > > the size of the effort and compare with the current
> proposal.
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado
> > Sarti <
> > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > 1) Remove all dependencies from tooling to images, so
> > images
> > > > > depend
> > > > > > > on
> > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > 2) Then change CI to deal with tooling repo before
> dealing
> > > with
> > > > > > > images
> > > > > > > > > > repo.
> > > > > > > > > > I understand that CI details are tricky and since I'm not
> > > > > familiar
> > > > > > > with
> > > > > > > > > CI
> > > > > > > > > > in any way, I barely can make a low level design, but we
> do
> > > not
> > > > > need
> > > > > > > to
> > > > > > > > > fix
> > > > > > > > > > everything, just achieve 2), a change of compilation
> order.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > > alex@porcelli.me
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > >
> > > > > > > > > > > You may not like or understand why the current state of
> > > the CI
> > > > > is
> > > > > > > > like
> > > > > > > > > > > that… actually has been in Red Hat and has been
> > replicated
> > > in
> > > > > > > Apache
> > > > > > > > as
> > > > > > > > > > > used to be….
> > > > > > > > > > >
> > > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > > >
> > > > > > > > > > > If you disagree with the current plan, please provide a
> > > > > detailed
> > > > > > > > > > > alternative so we, as community, can better evaluate
> the
> > > pros
> > > > > and
> > > > > > > > cons
> > > > > > > > > of
> > > > > > > > > > > each proposal.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I think it’s also fair to say that, post 10 release we
> > > need to
> > > > > > > have a
> > > > > > > > > > much
> > > > > > > > > > > in depth discussion about how our codebase is
> organized,
> > > it’s
> > > > > clear
> > > > > > > > > that
> > > > > > > > > > > it’s not working.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > I also have the impression that the "images" (if we
> are
> > > > > talking
> > > > > > > of
> > > > > > > > > > docker
> > > > > > > > > > > > images) should be the very last one to be built, in a
> > > > > standalone
> > > > > > > > > repo.
> > > > > > > > > > > > That way, they may "combine" artifacts that are built
> > in
> > > > > > > different
> > > > > > > > > > repos,
> > > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > > Moving them out of all the repos
> > (kogito-apps/kie-tools)
> > > > > maybe
> > > > > > > > could
> > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > (I also think there are some statements of
> undisputable
> > > needs
> > > > > > > while
> > > > > > > > > > they
> > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > > discussion.)
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco
> > Javier
> > > > > Tirado
> > > > > > > > > Sarti
> > > > > > > > > > <
> > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > >
> > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > There are two assumptions that deserve further
> > > discussion:
> > > > > > > > > > > > > 1) That tool has to be the last to build. why? it
> > does
> > > not
> > > > > have
> > > > > > > > > more
> > > > > > > > > > > > sense
> > > > > > > > > > > > > to build final images after everything else has
> been
> > > > > built?-
> > > > > > > > > > > > > 2) That the impact (in terms of effort now) on
> fixing
> > > CI is
> > > > > > > > bigger
> > > > > > > > > > than
> > > > > > > > > > > > the
> > > > > > > > > > > > > impact (long term consequences) of consolidating
> two
> > > > > unrelated
> > > > > > > > > piece
> > > > > > > > > > of
> > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > > alex@porcelli.me
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This was discussed as an alternative solution,
> > > however
> > > > > it has
> > > > > > > > > major
> > > > > > > > > > > > > impact
> > > > > > > > > > > > > > on CI and there’s also the fact Tool has been
> > always
> > > the
> > > > > last
> > > > > > > > to
> > > > > > > > > > > build
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> > > world
> > > > > there
> > > > > > > > is
> > > > > > > > > no
> > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So, based on our evaluation… the proposal here is
> > the
> > > > > least
> > > > > > > > > > > disruptive
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> > > Tirado
> > > > > > > Sarti <
> > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > > embracing
> > > > > the
> > > > > > > fact
> > > > > > > > > > that
> > > > > > > > > > > > > > > kogito-images depend on kie-tools, because we
> > want
> > > > > those
> > > > > > > > images
> > > > > > > > > > to
> > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco
> Javier
> > > > > Tirado
> > > > > > > > Sarti
> > > > > > > > > <
> > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > > kn-plugin-workflow
> > > > > > > > > to
> > > > > > > > > > > > > > > > kogito-images (so there is not longer
> > dependency
> > > from
> > > > > > > tools
> > > > > > > > > to
> > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique
> > Gonzalez
> > > > > > > Martinez
> > > > > > > > <
> > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > > (apache)
> > > > > <
> > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> > I say +1 in order to move forward with the
> > 10.
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex
> Porcelli
> > <
> > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > I spent the last day or so working
> closely
> > > with
> > > > > > > Tiago,
> > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > >> > > options and getting deeper on the impact
> > and
> > > > > > > > evaluating
> > > > > > > > > > the
> > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > >> > > procedure steps required. I agree with
> the
> > > > > proposal
> > > > > > > as
> > > > > > > > > the
> > > > > > > > > > > > most
> > > > > > > > > > > > > > > >> > > viable option for unblocking the 10
> > release
> > > in
> > > > > the
> > > > > > > > > > > reasonable
> > > > > > > > > > > > > time
> > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago
> > Bento
> > > <
> > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> > > time,
> > > > > as
> > > > > > > this
> > > > > > > > > > > matter
> > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes
> to
> > > read,
> > > > > > > > > according
> > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > > thread
> > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > >
> > > > > > > >
> > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > >> > > > many of us were working towards
> > removing a
> > > > > > > circular
> > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > >> > > > currently present between
> `kogito-apps`
> > > and
> > > > > > > > > `kie-tools`.
> > > > > > > > > > > As
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > > > > finding the
> > > > > > > > > > > circular
> > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > > breakdown of
> > > > > the
> > > > > > > > > things
> > > > > > > > > > > we
> > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Right now, even though we started the
> > > effort
> > > > > to
> > > > > > > move
> > > > > > > > > the
> > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't
> > been
> > > > > able to
> > > > > > > > do
> > > > > > > > > it
> > > > > > > > > > > > yet,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java
> > 17,
> > > > > Maven
> > > > > > > > 3.9.6,
> > > > > > > > > > and
> > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > .
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > |==> 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > L |
> > ==========================
> > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/extended-services
> > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > > > `kie-tools`,
> > > > > > > we
> > > > > > > > > > > would've
> > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > 02.
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > > `kie-tools`/kn-plugin-workflow
> > > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > >> > > > * and
> > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > depends
> > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> > > image to
> > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > 02.
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > 04.
> > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > > `kie-tools`/kn-plugin-workflow
> > > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > >> > > > * and
> > `kogito-serverless-operator`
> > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> > > than a
> > > > > > > simple
> > > > > > > > > > > > circular
> > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After multiple conversations with a
> lot
> > of
> > > > > people,
> > > > > > > > > it's
> > > > > > > > > > > been
> > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > >> > > > hard coming up with a simple solution
> > that
> > > > > makes
> > > > > > > it
> > > > > > > > > > > possible
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while
> preserving
> > > the
> > > > > way
> > > > > > > > > > everyone
> > > > > > > > > > > is
> > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > contributing to the multiple
> > repositories
> > > we
> > > > > have.
> > > > > > > > > More
> > > > > > > > > > > than
> > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > >> > > > while making this assessment, I found
> > more
> > > > > > > problems
> > > > > > > > > > that,
> > > > > > > > > > > in
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm
> coming
> > > > > forward
> > > > > > > with
> > > > > > > > > my
> > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we
> > can
> > > use
> > > > > > > > Apache's
> > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate
> > about
> > > > > this
> > > > > > > > really
> > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective
> about
> > > the
> > > > > > > current
> > > > > > > > > > > > situation
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > > currently
> > > > > see.
> > > > > > > > > I'll
> > > > > > > > > > > > start
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > > > purposes,
> > > > > > > > point
> > > > > > > > > > out
> > > > > > > > > > > > > some
> > > > > > > > > > > > > > > >> > > > problems that I believe are blocking
> our
> > > 10
> > > > > > > release,
> > > > > > > > > > > explain
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > >> > > > proposal and discuss some consequences
> > to
> > > > > what I'm
> > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO
> (count:
> > > 11)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @
> > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > > >> > > > -
> incubator-kie-optaplanner-quickstarts
> > @
> > > > > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-serverless-operator @
> > > > > > > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @
> > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > > updated @
> > > > > > > `main`.
> > > > > > > > > > Same
> > > > > > > > > > > > for
> > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @
> `main`
> > > > > > > > > > > > > > > >> > > > (The Kogito website. Develop &
> > deploy
> > > at
> > > > > the
> > > > > > > > > `main`
> > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > > >> > > > (The KIE website. Develop @
> `main`.
> > > Push @
> > > > > > > > > `deploy`
> > > > > > > > > > to
> > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> > `gh-pages`
> > > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > > sandbox.kie.org
> > > > > > > and
> > > > > > > > > KIE
> > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging
> @
> > > `main`
> > > > > > > > > > > > > > > >> > > > (Same as above, but for manual
> > sanity
> > > > > checks
> > > > > > > > > during
> > > > > > > > > > > the
> > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I grouped the repositories by
> category,
> > > and
> > > > > listed
> > > > > > > > > them
> > > > > > > > > > > in a
> > > > > > > > > > > > > > > >> > > > topological order. Keep in mind that
> > when
> > > > > > > flattening
> > > > > > > > > > out a
> > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > >> > > > are multiple possibilities. For
> example,
> > > > > > > OptaPlanner
> > > > > > > > > > > > could've
> > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > > referring
> > > > > to
> > > > > > > as
> > > > > > > > > > > `drools`
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> OptaPlanner
> > > is
> > > > > inside
> > > > > > > > > that
> > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > way these repositories reference each
> > > other
> > > > > are
> > > > > > > > > through
> > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > > 999-SNAPSHOT
> > > > > > > > > version.
> > > > > > > > > > > This
> > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > >> > > > is well-known to the team, and
> although
> > > > > flawed for
> > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > > different
> > > > > time
> > > > > > > > > zones,
> > > > > > > > > > it
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> > > with, I
> > > > > > > > assume.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Contributions made to Category A have
> > some
> > > > > > > dedicated
> > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> > > build
> > > > > > > > cross-repo
> > > > > > > > > > PRs
> > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > >> > > > and verify that the codebase will
> > continue
> > > > > working
> > > > > > > > as
> > > > > > > > > > > > expected
> > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > > gather,
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > > some
> > > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > > cross-repo
> > > > > > > > PRs.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> kogito-apps,
> > > and
> > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > >> > > > - optaplanner, and
> > optaplanner-quickstarts
> > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs
> > to
> > > any
> > > > > > > > > > combination
> > > > > > > > > > > of
> > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > >> > > > that are not part of the same
> > "sub-stream"
> > > > > cannot
> > > > > > > be
> > > > > > > > > > > > verified
> > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > > > dependent
> > > > > > > on
> > > > > > > > > > > > individual
> > > > > > > > > > > > > > > >> > > > contributors building stuff on their
> > > machines
> > > > > to
> > > > > > > > > verify
> > > > > > > > > > > that
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with
> > these
> > > > > > > > pipelines,
> > > > > > > > > so
> > > > > > > > > > > > > please
> > > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > > referring
> > > > > to
> > > > > > > as
> > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > >> > > > stream. The first repo there is a
> > template
> > > > > > > > repository
> > > > > > > > > > that
> > > > > > > > > > > > is
> > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > >> > > > people starting projects from scratch
> on
> > > KIE
> > > > > > > > Sandbox,
> > > > > > > > > > > > similar
> > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The
> other
> > > one
> > > > > is the
> > > > > > > > KIE
> > > > > > > > > > > Tools
> > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> > > build
> > > > > > > system.
> > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > > > TypeScript
> > > > > > > > > > libraries
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts.
> > The
> > > > > > > > `kie-tools`
> > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > >> > > > configured to work with sparse
> checkouts
> > > and
> > > > > can
> > > > > > > do
> > > > > > > > > > > partial
> > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > >> > > > Category B repos refer to Category A
> > repos
> > > > > through
> > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > > recently
> > > > > > > > > > introduced
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > >> > > > build and publish immutable,
> persistent
> > > > > artifacts
> > > > > > > > > under
> > > > > > > > > > a
> > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> > > format,
> > > > > > > > published
> > > > > > > > > > > weekly
> > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs
> are
> > an
> > > > > > > evolution
> > > > > > > > > to
> > > > > > > > > > > the
> > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > > release
> > > > > for
> > > > > > > all
> > > > > > > > > of
> > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > An important note here is that
> Category
> > B
> > > > > > > > repositories
> > > > > > > > > > > have
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > > >> > > > historically kept out of any
> automations
> > > we
> > > > > used
> > > > > > > to
> > > > > > > > > > have,
> > > > > > > > > > > > way
> > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > > Business
> > > > > > > Central
> > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > >> > > > still going on. For this reason,
> > Category
> > > B
> > > > > > > projects
> > > > > > > > > > have
> > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > > > Actions.
> > > > > > > > > > Category B
> > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > >> > > > always depended on Category A repos
> > using
> > > > > fixed
> > > > > > > > > > versions.
> > > > > > > > > > > If
> > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > > SNAPSHOTs,
> > > > > > > breaking
> > > > > > > > > > > changes
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > Category A repositories would've had
> the
> > > > > potential
> > > > > > > > to
> > > > > > > > > > > break
> > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > >> > > > silently, leaving Category B with a
> > broken
> > > > > > > > development
> > > > > > > > > > > > stream,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > > > maintainers
> > > > > > > of
> > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > >> > > > as historically Category A
> contributors
> > > were
> > > > > not
> > > > > > > > > > familiar
> > > > > > > > > > > > with
> > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Contributions made to Category B repos
> > go
> > > > > through
> > > > > > > a
> > > > > > > > > > GitHub
> > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > >> > > > workflow that builds the relevant part
> > of
> > > the
> > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > >> > > > the changes introduced. Changes made
> to
> > > the
> > > > > > > pipeline
> > > > > > > > > > > itself
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us
> to
> > > do
> > > > > things
> > > > > > > > > like
> > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> > example.
> > > More
> > > > > > > > > > > importantly,
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > > timestamped
> > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > >> > > > with the changes necessary to make it
> > stay
> > > > > green.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This setup, however, makes it
> impossible
> > > to
> > > > > have
> > > > > > > > > > > cross-repo
> > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > > simultaneously,
> > > > > > > > > with
> > > > > > > > > > > the
> > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > > around,
> > > > > and
> > > > > > > > I'm
> > > > > > > > > > not
> > > > > > > > > > > > sure
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > > Regardless,
> > > > > > > as
> > > > > > > > > > > they're
> > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > > release,
> > > > > so I
> > > > > > > > > > listed
> > > > > > > > > > > > them
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category D is self explanatory.
> There's
> > > only
> > > > > one
> > > > > > > > repo
> > > > > > > > > > that
> > > > > > > > > > > > has
> > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category E are repos that do not host
> > code
> > > > > > > directly,
> > > > > > > > > and
> > > > > > > > > > > are
> > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > >> > > > organizational entities, or host
> > websites,
> > > > > that
> > > > > > > > > > currently
> > > > > > > > > > > > are
> > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This lack of unification between
> > Category
> > > A
> > > > > and
> > > > > > > > > > Category B
> > > > > > > > > > > > is,
> > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> > infamous
> > > > > circular
> > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which
> we
> > > now
> > > > > can
> > > > > > > > > describe
> > > > > > > > > > > as
> > > > > > > > > > > > a
> > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > >> > > > dependency between Category A and
> > > Category B.
> > > > > The
> > > > > > > > way
> > > > > > > > > I
> > > > > > > > > > > see
> > > > > > > > > > > > > it,
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > had a single pipeline, building
> > everything
> > > > > from
> > > > > > > > > `drools`
> > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> > > been
> > > > > > > > > introduced,
> > > > > > > > > > > and
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem
> in
> > > our
> > > > > hands
> > > > > > > > > right
> > > > > > > > > > > now.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > > process
> > > > > > > sees
> > > > > > > > > this
> > > > > > > > > > > > lack
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > unification as a central problem, not
> > > only for
> > > > > > > this
> > > > > > > > > > > release
> > > > > > > > > > > > in
> > > > > > > > > > > > > > > >> > > > particular, but for the community as a
> > > whole.
> > > > > It
> > > > > > > is
> > > > > > > > my
> > > > > > > > > > > > belief
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > are all under the same roof, and that
> no
> > > > > > > > contribution
> > > > > > > > > > > should
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > >> > > > allowed to break any part of our
> > codebase.
> > > > > With
> > > > > > > the
> > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > > contributors
> > > > > too,
> > > > > > > > we
> > > > > > > > > > > cannot
> > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> > > breaking
> > > > > > > things.
> > > > > > > > > > We're
> > > > > > > > > > > > all
> > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > > > mechanisms in
> > > > > > > > > place
> > > > > > > > > > > to
> > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> > > Especially
> > > > > when
> > > > > > > > > these
> > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > >> > > > impact on parts of the codebase that
> we,
> > > > > > > > individually,
> > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > > depending
> > > > > on
> > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > > > `kogito-images`
> > > > > > > > > > > > depending
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools`
> depending
> > on
> > > > > > > > kiegroup's
> > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > > > depending on
> > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > > > codebase
> > > > > > > > here:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >
> > > > > > > > > >
> > > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > > ,
> > > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > > OptaPlanner,
> > > > > > > > > > > pointing
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > older
> > > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P5.
> > > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > > depending
> > > > > > > > > > > on
> > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> > `2.15.3.Final`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P6. Category C repos are out of date
> and
> > > not
> > > > > part
> > > > > > > of
> > > > > > > > > the
> > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> > > (Current
> > > > > > > version
> > > > > > > > is
> > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > > > version,
> > > > > > > only
> > > > > > > > > by
> > > > > > > > > > > > using
> > > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> > > version
> > > > > is
> > > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > > > OptaPlanner
> > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P7.
> > > `kie-tools`/packages/kn-plugin-workflow
> > > > > has
> > > > > > > its
> > > > > > > > > E2E
> > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the
> > same
> > > > > > > solution,
> > > > > > > > > as
> > > > > > > > > > > they
> > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > >> > > > suffer from the circular dependency
> > > between
> > > > > > > > Category A
> > > > > > > > > > and
> > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > > >> > > > As Category A and Category B are both
> > > streams
> > > > > that
> > > > > > > > > have
> > > > > > > > > > > been
> > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > >> > > > active, I see this as a blocker, as
> > there
> > > are
> > > > > > > > > > > contributions
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> > > depends
> > > > > on
> > > > > > > > > > Category
> > > > > > > > > > > B
> > > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > > > understood
> > > > > > > as
> > > > > > > > > > > > technical
> > > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > > > something
> > > > > > > > we'll
> > > > > > > > > > > always
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> > > just a
> > > > > > > matter
> > > > > > > > of
> > > > > > > > > > > > making
> > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> > > impact
> > > > > the
> > > > > > > > > > structure
> > > > > > > > > > > or
> > > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > > >> > > > that we're talking about here, but it
> > is a
> > > > > > > > regression
> > > > > > > > > we
> > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> > > Apache
> > > > > KIE
> > > > > > > 10,
> > > > > > > > > and
> > > > > > > > > > > > that
> > > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only
> > problems
> > > > > left to
> > > > > > > > > > discuss
> > > > > > > > > > > > are
> > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > P2, which can't be done without a
> proper
> > > > > proposal.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I'll try to be very meticulous here,
> > since
> > > > > from my
> > > > > > > > > > > > experience,
> > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> > > release
> > > > > not
> > > > > > > > > > working
> > > > > > > > > > > > out
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > > > possible,
> > > > > > > and
> > > > > > > > > make
> > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > > > release,
> > > > > > > bear
> > > > > > > > > > with
> > > > > > > > > > > > me.
> > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > > >> > > > out a timeline of events that need to
> > > happen
> > > > > in
> > > > > > > > order
> > > > > > > > > > for
> > > > > > > > > > > > our
> > > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > > >> > > > to be published, with all artifacts
> > > ending up
> > > > > in
> > > > > > > the
> > > > > > > > > > right
> > > > > > > > > > > > > > places,
> > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > >> > > > first, we need to solve problems P1
> and
> > > P2.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As you saw at the beginning of this
> > email,
> > > > > all the
> > > > > > > > > > > attempts
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > made
> > > > > > > > > > > > > > > >> > > > left us with the circular dependency
> > > showing
> > > > > up
> > > > > > > at a
> > > > > > > > > > > > different
> > > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > > >> > > > but something all these places have in
> > > common
> > > > > is
> > > > > > > > that
> > > > > > > > > > > > they're
> > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > >> > > > after kogito-apps, and before to
> > Category
> > > B.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > > > following:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > S1. We keep the original plan of
> moving
> > > the
> > > > > > > Quarkus
> > > > > > > > > Dev
> > > > > > > > > > > UIs
> > > > > > > > > > > > > from
> > > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> > > with
> > > > > > > > Management
> > > > > > > > > > and
> > > > > > > > > > > > > Task
> > > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> > > `kie-tools`.
> > > > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode`
> and
> > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools`
> too.
> > > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > > `kogito-serverless-operator`
> > > > > > > > > repo
> > > > > > > > > > > > > inside
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> > > history.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together
> solve
> > > > > problems
> > > > > > > P1
> > > > > > > > > and
> > > > > > > > > > > P2.
> > > > > > > > > > > > Of
> > > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > > >>
> > > > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This doesn't come without
> consequences,
> > of
> > > > > course,
> > > > > > > > as
> > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > > `kogito-swf-builder`
> > > > > > > > images,
> > > > > > > > > > and
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be
> > > moving
> > > > > from
> > > > > > > > > > > Category A
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > Category B. This move would make them
> > > have to
> > > > > > > > > reference
> > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs.
> > Since
> > > > > > > > > > `kogito-images`
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are
> already
> > > > > their own
> > > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > > >> > > > Category A, though, contributions made
> > in
> > > a
> > > > > > > > cross-repo
> > > > > > > > > > > > fashion
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> > > possible, now
> > > > > > > via a
> > > > > > > > > > > single
> > > > > > > > > > > > PR
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> > > Category
> > > > > A and
> > > > > > > > > > > Category
> > > > > > > > > > > > B
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > >> > > > continue not being possible, and a
> > 1-week
> > > > > delay
> > > > > > > > > between
> > > > > > > > > > > > > merging
> > > > > > > > > > > > > > > >> > > > something on Category A and using it
> on
> > > > > Category B
> > > > > > > > > will
> > > > > > > > > > > > still
> > > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > It's worth mentioning that
> `kie-tools`,
> > > > > however,
> > > > > > > > does
> > > > > > > > > > > allow
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > > >> > > > checkouts and partial builds, so
> working
> > > with
> > > > > a
> > > > > > > > subset
> > > > > > > > > > of
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > >> > > > is possible and encouraged. Making
> > changes
> > > > > only to
> > > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> > > example,
> > > > > will
> > > > > > > > have
> > > > > > > > > > the
> > > > > > > > > > > PR
> > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see
> > here:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > >> > > > We're not compromising when running
> > > partial
> > > > > builds
> > > > > > > > > too.
> > > > > > > > > > We
> > > > > > > > > > > > > know
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> > > > the entire repo will continue working
> > even
> > > > > after
> > > > > > > > only
> > > > > > > > > > > > > building a
> > > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > > >> > > > subset of the changes. Doing partial
> or
> > > full
> > > > > > > builds
> > > > > > > > is
> > > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> > > proposing
> > > > > we
> > > > > > > > move a
> > > > > > > > > > > bunch
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I
> see
> > > this
> > > > > as a
> > > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would
> host
> > > some
> > > > > > > > > additional
> > > > > > > > > > > > stuff
> > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > > > continue
> > > > > > > > moving
> > > > > > > > > > > > > forward.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As I mentioned on other places,
> > > `kie-tools`
> > > > > > > became a
> > > > > > > > > > > > polyglot
> > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > >> > > > out of necessity, and although I'm
> > really
> > > > > proud of
> > > > > > > > > what
> > > > > > > > > > we
> > > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > > >> > > > there so far, I don't think
> `kie-tools`
> > > has a
> > > > > > > setup
> > > > > > > > > that
> > > > > > > > > > > is
> > > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > > >> > > > for all the different nuances that
> > > compose our
> > > > > > > > > > community.
> > > > > > > > > > > > I'm
> > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that
> does
> > > not
> > > > > > > follow
> > > > > > > > > > > > widespread
> > > > > > > > > > > > > > > >> > > > conventions will scare some people
> away,
> > > and
> > > > > as
> > > > > > > much
> > > > > > > > > as
> > > > > > > > > > > > we've
> > > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > >> > > > make build instructions clear, we
> can't
> > > > > always get
> > > > > > > > > past
> > > > > > > > > > > the
> > > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > > >> > > > some people have towards the
> "front-end"
> > > > > > > ecosystem.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > With all that said, I keep thinking
> this
> > > is
> > > > > the
> > > > > > > best
> > > > > > > > > > > course
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > > >> > > > for us right now. We keep most of our
> > > stuff
> > > > > > > > unchanged,
> > > > > > > > > > we
> > > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > release, and we have a working setup
> > that
> > > will
> > > > > > > suit
> > > > > > > > us
> > > > > > > > > > > well
> > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > discuss and reach a conclusion
> regarding
> > > the
> > > > > > > future
> > > > > > > > of
> > > > > > > > > > our
> > > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Let me paint a quick picture here of
> > what
> > > our
> > > > > code
> > > > > > > > > base
> > > > > > > > > > > > would
> > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal
> is
> > > > > accepted:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > B
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > D
> > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > > > >> > > > E
> incubator-kie-kogito-website
> > > > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > > > >> > > > E
> incubator-kie-kogito-online
> > > > > > > > > > > > > > > >> > > > E
> > > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * Category C becomes part of Category
> A,
> > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> > > entirely
> > > > > inside
> > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> > > images
> > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > > > `kie-tools`,
> > > > > > > > there
> > > > > > > > > > are
> > > > > > > > > > > > no
> > > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > > > granularly
> > > > > > > > > build:
> > > > > > > > > > > > > > > >> > > > 1.
> > > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > >> > > > 2.
> packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> > > (containing
> > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> > > (contents
> > > > > from
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The second part of the proposal is the
> > > release
> > > > > > > > process
> > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > >> > > > assuming the structure above is what
> we
> > > have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be
> > > used as
> > > > > > > > cutting
> > > > > > > > > > > point
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to
> > > this
> > > > > > > > > timestamped
> > > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > > > >> > > > 3. At this point, with everything
> > > working, we
> > > > > can
> > > > > > > > > branch
> > > > > > > > > > > out
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the
> > timestamped
> > > > > SNAPSHOT
> > > > > > > > > tag,
> > > > > > > > > > > and
> > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> > > update
> > > > > > > their
> > > > > > > > > > > versions
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > > > Category A
> > > > > > > > > repos
> > > > > > > > > > > > using
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the
> > > release
> > > > > based
> > > > > > > > on
> > > > > > > > > > the
> > > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > > >> > > > branches, given we don't expect any
> code
> > > > > changes
> > > > > > > > > > anymore.
> > > > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to
> > > start
> > > > > the
> > > > > > > > > release
> > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > > manual/automated
> > > > > > > > > > release
> > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > > pushed
> > > > > to
> > > > > > > Git,
> > > > > > > > > and
> > > > > > > > > > > > built
> > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > > > artifacts
> > > > > > > to
> > > > > > > > be
> > > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > > manual/automated
> > > > > > > > > > release
> > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > > pushed
> > > > > to
> > > > > > > Git,
> > > > > > > > > and
> > > > > > > > > > > > built
> > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > > > >> > > > 12. Category E repos can be manually
> > > tagged
> > > > > with
> > > > > > > > > 10.0.0
> > > > > > > > > > > from
> > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > More needs to be discussed if we're
> > > planning
> > > > > to
> > > > > > > > > maintain
> > > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > > >> > > > release streams in parallel, but I
> guess
> > > it
> > > > > can
> > > > > > > wait
> > > > > > > > > for
> > > > > > > > > > > > after
> > > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> > > > > forward to
> > > > > > > > > > hearing
> > > > > > > > > > > > back
> > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Of course, alternative solutions are
> > > possible.
> > > > > > > This
> > > > > > > > > > email,
> > > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > > >> > > > summarizes my view of how we should
> > > attack the
> > > > > > > > > problem,
> > > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > > >> > > > disruption, required effort, the
> release
> > > > > process
> > > > > > > > > itself,
> > > > > > > > > > > and
> > > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > > >> > > > Feel free to propose alternatives.
> This
> > is
> > > > > not a
> > > > > > > > > voting
> > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by ricardo zanini fernandes <ri...@gmail.com>.
That's my proposal too, Gabriele. I really want to release, but I don't
want to jeopardize contributions and our cloud efforts. Copying the code
over to kie-tools, we release, keep the PRs coming in the repos they are
today and after the release, we sit down and restructure. If we merge, I
doubt we will fix anything after that.
I think the problem is waaaaay deeper since we don't have boundaries among
our initiatives and projects. And that is reflected in our codebase and
infra.
Another problem is that CI is yet another project/piece of software and
that must be treated as this. We must have people engaged on that nearly
100% of the time, improving, making it better, reliable, and robust. It's
not a one-way thing that you create once and leave it there.
On Wed, Mar 13, 2024 at 11:54 AM Gabriele Cardosi <
gabriele.cardosi@gmail.com> wrote:
> I have the impression there are still two different POV.
> On one side, I agree that we should try to make the release ASAP. But we
> should also consider that if we release something that may create problems
> to the community itself, just for the rush of it, then the community would
> be much more disappointed.
> On the other side, I think the concern is to keep transforming a temporary
> solution, that was not the only possible one, to the only possible one,
> i.e. that kie-tools become the central point of delivery, with a
> Frankenstein effect whose consequences in long term are hard to imagine.
> So, maybe if we can make a sort of agreement that everything would be
> revisited "after the release", with a sort of "task force" that analyzes
> everything from scratch, and that includes all the ones that are involved
> by it, we could break this deadlock.
> WDYT ?
>
> Il giorno mer 13 mar 2024 alle ore 15:41 Francisco Javier Tirado Sarti <
> ftirados@redhat.com> ha scritto:
>
> > 1) Ok, if that is the case, I do not get why your first proposal was not
> > the one I'm proposing and it is apparently not detailed enough. To move
> > kn-workflow from tooling to operator one and change the order in which
> the
> > repos are being processed. Basically, the problem of the proposed
> solution
> > is that it kind of converts tooling repo into a pretty heterodox repo
> > compared with runtimes, drools or operator one. Also once tooling is not
> a
> > final repo in the overall chain, we can consider moving examples as the
> > final one and include tooling showcases there (rather than splitting
> > examples into examples with tooling and examples without tooling).
> > 2) I think this distinction between A and B is one between several
> possible
> > categorizations (not much, including no categorization at all) that
> > deserves a separate discussion. I will open a separate thread for that
> > purpose, since we are not going to change that now and it is not really
> > part of the proposal.
> >
> > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <
> tiagobentofernandes@gmail.com
> > >
> > wrote:
> >
> > > Francisco,
> > >
> > > 1) That's what this thread is all about... You know I don't think it's
> > > ok. That's why I'm proposing the two images and the operator to move
> > > into the `kie-tools` repo, where we can more granularly control the
> > > order things are built, thus removing the dependency cycle.
> > >
> > > 2) Not sure we understand the same thing by "freeze". My proposal is
> > > that we select a timestamped SNAPSHOT version from Category A repos to
> > > use as base for a release. We give Category B repos some time to
> > > adjust, and then cut the release branches. This can happen anytime,
> > > and no contributions would ever stop because of it. The development
> > > branches can continue accepting PRs normally, even during the release
> > > process. Now, if what you're asking is why Category B repos refer to
> > > Category A repos via timestamped SNAPSHOTs, the answer is in my first
> > > email. See the paragraph starting with "An important note here is that
> > > Category B repositories...".
> > >
> > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti
> > > <ft...@redhat.com> wrote:
> > > >
> > > > Tiago
> > > > There are a couple of simple and straightforward questions that I
> > > > formulated, but since we both write a lot, it might have been lost.
> > > Please
> > > > let me ask them again.
> > > > 1) Do you think it is ok that tools repo is executed after generation
> > of
> > > > docker images that are supposed to include those tools or the
> operator
> > > that
> > > > is supposed to deploy such images?
> > > That's what this thread is all about... You know I'm not ok with it,
> > > that's why I'm proposing the two images and the operator to move into
> > > the `kie-tools` repo, where we can more granularly control the order
> > > things are built and remove the dependency cycle.
> > > > 2) Besides that, although not directly related with the current
> > proposal
> > > we
> > > > are discussing, I really think there are some restrictions taken for
> > > > granted that are arbitrary and difficult to sustain on strictly
> > technical
> > > > arguments. For example, the need to freeze the rest of the software
> > > before
> > > > tools are generated. Why? We have dependencies between repos that are
> > not
> > > > handled that way: Apps depend on runtimes. Runtimes depend on drools,
> > > > Operator depend on runtimes,....and we are not freezing that repos
> > since
> > > we
> > > > are all releasing at the same time. If we are all releasing at the
> same
> > > > time, what's the rationale behind the freeze?
> > > >
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <ti...@apache.org>
> > > wrote:
> > > >
> > > > > Glad to see the interest this proposal has gotten, and it's good to
> > > > > see some alternatives being drafted here, although still lacking
> > clear
> > > > > definitions and analysis in regards to disruption, required effort,
> > > > > the release process itself, and history. Of course, lots of details
> > > > > and clarity on the execution part would be missing too.
> > > > >
> > > > > As of this moment, based on what I read here, I'm assuming that
> > > > > everyone who participated so far doesn't see the initial proposal
> as
> > > > > problematic in terms of feasibility, but some of you have a
> > preference
> > > > > not to go with it, because it is "wrong", and apparently because it
> > > > > would "jeopardize the evolution of the project". Reading these last
> > > > > words made me a little sad, to be honest. But I can deal with it :)
> > > > >
> > > > > Please let's try and keep the discussion as objective as possible.
> > > > > "Right" and "wrong" are too subjective for this kind of
> conversation.
> > > > >
> > > > > Now, being practical, unless there are clear arguments based on
> facts
> > > > > and objective concepts that invalidate the initial proposal shared
> on
> > > > > this email, it seems to me that it is currently the only viable
> > > > > proposal we have for unblocking and releasing Apache KIE 10. Of
> > > > > course, if we end up seeing an alternative proposal with enough
> > > > > details and a clear execution plan, I think then we'll be in a very
> > > > > good position to choose from multiple options!
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > > >
> > > > > > Francisco and Gabriele,
> > > > > >
> > > > > > I understand and acknowledge your desire to find the “right”
> > solution
> > > > > > instead to work on a temporary “patch” - however without a
> detailed
> > > > > > proposal I don’t think we can properly evaluate the impact of
> your
> > > > > > suggestion.
> > > > > >
> > > > > > When I spoke with different SMEs that included tools and CI, the
> > > > > > guesstimate for making the necessary changes on CI and codebase
> to
> > > > > > basically have images and operators in the end of the build chain
> > is
> > > > > > something like 2 months of effort. Another impact that needs to
> be
> > > > > > discussed is that KIE Tools repo had to be injected in the middle
> > of
> > > all
> > > > > > pipelines - forcing all PR checks and nightlies to build all
> repos
> > > (PR
> > > > > > checks will likely take 12+ hours… I even heard that it could be
> > > even 24
> > > > > > hours).
> > > > > >
> > > > > > Based on the input above, I think it’s quite risk to move in such
> > > > > direction
> > > > > > without a more detailed plan… because 2 months could be turned
> > > easily in
> > > > > 6!
> > > > > > And this is exactly what happened when we guessed that moving to
> > > Apache
> > > > > > would take no more than 3 months. But here we are.
> > > > > >
> > > > > > I really strongly suggest that we focus on a release that could
> be
> > > > > > achievable in less than a month from now, and we - after release
> -
> > > have a
> > > > > > in depth discussion about the overall codebase and ci
> organization.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > > gabriele.cardosi@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Alex,
> > > > > > > my suggestion is to move the building of all docker images,
> from
> > > > > whatever
> > > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo,
> to
> > > be
> > > > > > > invoked after all the others.
> > > > > > > I'm not sure if this would solve all the issues, and since I
> > could
> > > not
> > > > > > > enter in the details of all the involved code, my suggestion
> may
> > > be too
> > > > > > > naive.
> > > > > > > Having spent almost all of the last year in CI, I may say
> that,
> > at
> > > > > least
> > > > > > > for the kie-tools repo, removing the image build step from it
> > > should
> > > > > not be
> > > > > > > too difficult (since it is an issue we already faced and
> solved).
> > > > > > > If, with "detailed proposal", you mean a complete list of all
> > > modules
> > > > > to be
> > > > > > > moved and dependency refactoring, of course I can not provide
> it
> > > right
> > > > > now.
> > > > > > >
> > > > > > > Anyway, I share the concern from Francisco: undoing something
> is
> > > almost
> > > > > > > always harder than doing it "rightly" from scratch...
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier
> Tirado
> > > Sarti
> > > > > <
> > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > >
> > > > > > > > I do not think estimations should be the only driver to make
> a
> > > > > decision,
> > > > > > > > especially when the current proposal is conceptually
> > incompatible
> > > > > with
> > > > > > > the
> > > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > > Given my knowledge of the CI it is nearly impossible for me
> to
> > > give
> > > > > a
> > > > > > > fair
> > > > > > > > estimate of how much it might take to achieve step 2) of my
> > > previous
> > > > > > > e-mail
> > > > > > > > . It might take a while or it might be pretty easy after
> all, I
> > > don't
> > > > > > > > really know, but I think it will be a good idea if some of
> the
> > > > > experts
> > > > > > > on
> > > > > > > > CI in the team (the ones that set up the pipeline, which was
> a
> > > huge
> > > > > > > > achievement) give an estimate, not me. Estimating how much
> it
> > > takes
> > > > > to
> > > > > > > > merge two existing repos (without altering CI) is easier, but
> > it
> > > > > does not
> > > > > > > > mean we are doing the right thing.
> > > > > > > > My main concern is that it will be very difficult for me to
> > > explain
> > > > > to
> > > > > > > > someone that arrives new to the team, that having experts on
> CI
> > > on
> > > > > the
> > > > > > > > team, we decided to merge two repos (once merged, it would be
> > > rather
> > > > > > > > difficult to unmerge) rather than fix the CI, because of
> > > expediency.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > > porcelli@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco,
> > > > > > > > >
> > > > > > > > > Please take the time to make the more in depth analysis
> > needed
> > > and
> > > > > > > > provide
> > > > > > > > > a more detailed plan… so we - as community- can evaluate
> the
> > > size
> > > > > of
> > > > > > > the
> > > > > > > > > effort. In the conceptual level you shared it’s near
> > > impossible to
> > > > > > > > estimate
> > > > > > > > > the size of the effort and compare with the current
> proposal.
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado
> > Sarti <
> > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > > 1) Remove all dependencies from tooling to images, so
> > images
> > > > > depend
> > > > > > > on
> > > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > > 2) Then change CI to deal with tooling repo before
> dealing
> > > with
> > > > > > > images
> > > > > > > > > > repo.
> > > > > > > > > > I understand that CI details are tricky and since I'm not
> > > > > familiar
> > > > > > > with
> > > > > > > > > CI
> > > > > > > > > > in any way, I barely can make a low level design, but we
> do
> > > not
> > > > > need
> > > > > > > to
> > > > > > > > > fix
> > > > > > > > > > everything, just achieve 2), a change of compilation
> order.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > > alex@porcelli.me
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > > >
> > > > > > > > > > > You may not like or understand why the current state of
> > > the CI
> > > > > is
> > > > > > > > like
> > > > > > > > > > > that… actually has been in Red Hat and has been
> > replicated
> > > in
> > > > > > > Apache
> > > > > > > > as
> > > > > > > > > > > used to be….
> > > > > > > > > > >
> > > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > > >
> > > > > > > > > > > If you disagree with the current plan, please provide a
> > > > > detailed
> > > > > > > > > > > alternative so we, as community, can better evaluate
> the
> > > pros
> > > > > and
> > > > > > > > cons
> > > > > > > > > of
> > > > > > > > > > > each proposal.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I think it’s also fair to say that, post 10 release we
> > > need to
> > > > > > > have a
> > > > > > > > > > much
> > > > > > > > > > > in depth discussion about how our codebase is
> organized,
> > > it’s
> > > > > clear
> > > > > > > > > that
> > > > > > > > > > > it’s not working.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > As Francisco said,
> > > > > > > > > > > > I also have the impression that the "images" (if we
> are
> > > > > talking
> > > > > > > of
> > > > > > > > > > docker
> > > > > > > > > > > > images) should be the very last one to be built, in a
> > > > > standalone
> > > > > > > > > repo.
> > > > > > > > > > > > That way, they may "combine" artifacts that are built
> > in
> > > > > > > different
> > > > > > > > > > repos,
> > > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > > Moving them out of all the repos
> > (kogito-apps/kie-tools)
> > > > > maybe
> > > > > > > > could
> > > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > > (I also think there are some statements of
> undisputable
> > > needs
> > > > > > > while
> > > > > > > > > > they
> > > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > > discussion.)
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco
> > Javier
> > > > > Tirado
> > > > > > > > > Sarti
> > > > > > > > > > <
> > > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > > >
> > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > There are two assumptions that deserve further
> > > discussion:
> > > > > > > > > > > > > 1) That tool has to be the last to build. why? it
> > does
> > > not
> > > > > have
> > > > > > > > > more
> > > > > > > > > > > > sense
> > > > > > > > > > > > > to build final images after everything else has
> been
> > > > > built?-
> > > > > > > > > > > > > 2) That the impact (in terms of effort now) on
> fixing
> > > CI is
> > > > > > > > bigger
> > > > > > > > > > than
> > > > > > > > > > > > the
> > > > > > > > > > > > > impact (long term consequences) of consolidating
> two
> > > > > unrelated
> > > > > > > > > piece
> > > > > > > > > > of
> > > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > > alex@porcelli.me
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This was discussed as an alternative solution,
> > > however
> > > > > it has
> > > > > > > > > major
> > > > > > > > > > > > > impact
> > > > > > > > > > > > > > on CI and there’s also the fact Tool has been
> > always
> > > the
> > > > > last
> > > > > > > > to
> > > > > > > > > > > build
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> > > world
> > > > > there
> > > > > > > > is
> > > > > > > > > no
> > > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So, based on our evaluation… the proposal here is
> > the
> > > > > least
> > > > > > > > > > > disruptive
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > _____________
> > > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> > > Tirado
> > > > > > > Sarti <
> > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > > embracing
> > > > > the
> > > > > > > fact
> > > > > > > > > > that
> > > > > > > > > > > > > > > kogito-images depend on kie-tools, because we
> > want
> > > > > those
> > > > > > > > images
> > > > > > > > > > to
> > > > > > > > > > > > > > include
> > > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco
> Javier
> > > > > Tirado
> > > > > > > > Sarti
> > > > > > > > > <
> > > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > > kn-plugin-workflow
> > > > > > > > > to
> > > > > > > > > > > > > > > > kogito-images (so there is not longer
> > dependency
> > > from
> > > > > > > tools
> > > > > > > > > to
> > > > > > > > > > > > > images)
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique
> > Gonzalez
> > > > > > > Martinez
> > > > > > > > <
> > > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > > (apache)
> > > > > <
> > > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> > I say +1 in order to move forward with the
> > 10.
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex
> Porcelli
> > <
> > > > > > > > > > alex@porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > I spent the last day or so working
> closely
> > > with
> > > > > > > Tiago,
> > > > > > > > > > > > exploring
> > > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > > >> > > options and getting deeper on the impact
> > and
> > > > > > > > evaluating
> > > > > > > > > > the
> > > > > > > > > > > > > > overall
> > > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > > >> > > procedure steps required. I agree with
> the
> > > > > proposal
> > > > > > > as
> > > > > > > > > the
> > > > > > > > > > > > most
> > > > > > > > > > > > > > > >> > > viable option for unblocking the 10
> > release
> > > in
> > > > > the
> > > > > > > > > > > reasonable
> > > > > > > > > > > > > time
> > > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago
> > Bento
> > > <
> > > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> > > time,
> > > > > as
> > > > > > > this
> > > > > > > > > > > matter
> > > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes
> to
> > > read,
> > > > > > > > > according
> > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > > thread
> > > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > > >
> > > > > > > >
> > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > > >> > > > many of us were working towards
> > removing a
> > > > > > > circular
> > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > >> > > > currently present between
> `kogito-apps`
> > > and
> > > > > > > > > `kie-tools`.
> > > > > > > > > > > As
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > > > > finding the
> > > > > > > > > > > circular
> > > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > > breakdown of
> > > > > the
> > > > > > > > > things
> > > > > > > > > > > we
> > > > > > > > > > > > > did,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Right now, even though we started the
> > > effort
> > > > > to
> > > > > > > move
> > > > > > > > > the
> > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't
> > been
> > > > > able to
> > > > > > > > do
> > > > > > > > > it
> > > > > > > > > > > > yet,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java
> > 17,
> > > > > Maven
> > > > > > > > 3.9.6,
> > > > > > > > > > and
> > > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > > .
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > |==> 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > C | 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > Y | 04.
> > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > L |
> > ==========================
> > > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/extended-services
> > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > > depend
> > > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > > > `kie-tools`,
> > > > > > > we
> > > > > > > > > > > would've
> > > > > > > > > > > > > > had:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > 02.
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > C |==> 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > > `kie-tools`/kn-plugin-workflow
> > > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > > >> > > > * and
> > > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > > depends
> > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> > > image to
> > > > > > > > > > > `kie-tools`,
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 01.
> > > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > 02.
> > > incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > 03.
> > > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > 04.
> > > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * As
> > > `kie-tools`/kn-plugin-workflow
> > > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > > >> > > > * and
> > `kogito-serverless-operator`
> > > > > depends
> > > > > > > > on
> > > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> > > than a
> > > > > > > simple
> > > > > > > > > > > > circular
> > > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > After multiple conversations with a
> lot
> > of
> > > > > people,
> > > > > > > > > it's
> > > > > > > > > > > been
> > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > >> > > > hard coming up with a simple solution
> > that
> > > > > makes
> > > > > > > it
> > > > > > > > > > > possible
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while
> preserving
> > > the
> > > > > way
> > > > > > > > > > everyone
> > > > > > > > > > > is
> > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > contributing to the multiple
> > repositories
> > > we
> > > > > have.
> > > > > > > > > More
> > > > > > > > > > > than
> > > > > > > > > > > > > > that,
> > > > > > > > > > > > > > > >> > > > while making this assessment, I found
> > more
> > > > > > > problems
> > > > > > > > > > that,
> > > > > > > > > > > in
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm
> coming
> > > > > forward
> > > > > > > with
> > > > > > > > > my
> > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we
> > can
> > > use
> > > > > > > > Apache's
> > > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate
> > about
> > > > > this
> > > > > > > > really
> > > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective
> about
> > > the
> > > > > > > current
> > > > > > > > > > > > situation
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > > currently
> > > > > see.
> > > > > > > > > I'll
> > > > > > > > > > > > start
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > > > purposes,
> > > > > > > > point
> > > > > > > > > > out
> > > > > > > > > > > > > some
> > > > > > > > > > > > > > > >> > > > problems that I believe are blocking
> our
> > > 10
> > > > > > > release,
> > > > > > > > > > > explain
> > > > > > > > > > > > > my
> > > > > > > > > > > > > > > >> > > > proposal and discuss some consequences
> > to
> > > > > what I'm
> > > > > > > > > > > > proposing.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO
> (count:
> > > 11)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @
> > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > > >> > > > -
> incubator-kie-optaplanner-quickstarts
> > @
> > > > > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @
> `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-kogito-serverless-operator @
> > > > > > > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > > >> > > > -
> > > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > > `0.0.0`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @
> > `main`
> > > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > > updated @
> > > > > > > `main`.
> > > > > > > > > > Same
> > > > > > > > > > > > for
> > > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @
> `main`
> > > > > > > > > > > > > > > >> > > > (The Kogito website. Develop &
> > deploy
> > > at
> > > > > the
> > > > > > > > > `main`
> > > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > > >> > > > (The KIE website. Develop @
> `main`.
> > > Push @
> > > > > > > > > `deploy`
> > > > > > > > > > to
> > > > > > > > > > > > > > update
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> > `gh-pages`
> > > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > > sandbox.kie.org
> > > > > > > and
> > > > > > > > > KIE
> > > > > > > > > > > > Tools'
> > > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging
> @
> > > `main`
> > > > > > > > > > > > > > > >> > > > (Same as above, but for manual
> > sanity
> > > > > checks
> > > > > > > > > during
> > > > > > > > > > > the
> > > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I grouped the repositories by
> category,
> > > and
> > > > > listed
> > > > > > > > > them
> > > > > > > > > > > in a
> > > > > > > > > > > > > > > >> > > > topological order. Keep in mind that
> > when
> > > > > > > flattening
> > > > > > > > > > out a
> > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > > >> > > > are multiple possibilities. For
> example,
> > > > > > > OptaPlanner
> > > > > > > > > > > > could've
> > > > > > > > > > > > > > been
> > > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > > referring
> > > > > to
> > > > > > > as
> > > > > > > > > > > `drools`
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course
> OptaPlanner
> > > is
> > > > > inside
> > > > > > > > > that
> > > > > > > > > > > > > stream,
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > way these repositories reference each
> > > other
> > > > > are
> > > > > > > > > through
> > > > > > > > > > > > Maven
> > > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > > 999-SNAPSHOT
> > > > > > > > > version.
> > > > > > > > > > > This
> > > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > > >> > > > is well-known to the team, and
> although
> > > > > flawed for
> > > > > > > > > > > intra-day
> > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > > different
> > > > > time
> > > > > > > > > zones,
> > > > > > > > > > it
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> > > with, I
> > > > > > > > assume.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Contributions made to Category A have
> > some
> > > > > > > dedicated
> > > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> > > build
> > > > > > > > cross-repo
> > > > > > > > > > PRs
> > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > >> > > > and verify that the codebase will
> > continue
> > > > > working
> > > > > > > > as
> > > > > > > > > > > > expected
> > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > > gather,
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > > some
> > > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > > cross-repo
> > > > > > > > PRs.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes,
> kogito-apps,
> > > and
> > > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > > >> > > > - optaplanner, and
> > optaplanner-quickstarts
> > > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > > kogito-serverless-operator
> > > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs
> > to
> > > any
> > > > > > > > > > combination
> > > > > > > > > > > of
> > > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > >> > > > that are not part of the same
> > "sub-stream"
> > > > > cannot
> > > > > > > be
> > > > > > > > > > > > verified
> > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > > > dependent
> > > > > > > on
> > > > > > > > > > > > individual
> > > > > > > > > > > > > > > >> > > > contributors building stuff on their
> > > machines
> > > > > to
> > > > > > > > > verify
> > > > > > > > > > > that
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with
> > these
> > > > > > > > pipelines,
> > > > > > > > > so
> > > > > > > > > > > > > please
> > > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > > referring
> > > > > to
> > > > > > > as
> > > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > > >> > > > stream. The first repo there is a
> > template
> > > > > > > > repository
> > > > > > > > > > that
> > > > > > > > > > > > is
> > > > > > > > > > > > > > used
> > > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > > >> > > > people starting projects from scratch
> on
> > > KIE
> > > > > > > > Sandbox,
> > > > > > > > > > > > similar
> > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The
> other
> > > one
> > > > > is the
> > > > > > > > KIE
> > > > > > > > > > > Tools
> > > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> > > build
> > > > > > > system.
> > > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > > > TypeScript
> > > > > > > > > > libraries
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts.
> > The
> > > > > > > > `kie-tools`
> > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > >> > > > configured to work with sparse
> checkouts
> > > and
> > > > > can
> > > > > > > do
> > > > > > > > > > > partial
> > > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > > >> > > > Category B repos refer to Category A
> > repos
> > > > > through
> > > > > > > > > > > > timestamped
> > > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > > recently
> > > > > > > > > > introduced
> > > > > > > > > > > > that
> > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > >> > > > build and publish immutable,
> persistent
> > > > > artifacts
> > > > > > > > > under
> > > > > > > > > > a
> > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> > > format,
> > > > > > > > published
> > > > > > > > > > > weekly
> > > > > > > > > > > > > > every
> > > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs
> are
> > an
> > > > > > > evolution
> > > > > > > > > to
> > > > > > > > > > > the
> > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > > release
> > > > > for
> > > > > > > all
> > > > > > > > > of
> > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > An important note here is that
> Category
> > B
> > > > > > > > repositories
> > > > > > > > > > > have
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > > >> > > > historically kept out of any
> automations
> > > we
> > > > > used
> > > > > > > to
> > > > > > > > > > have,
> > > > > > > > > > > > way
> > > > > > > > > > > > > > back
> > > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > > Business
> > > > > > > Central
> > > > > > > > > > > (a.k.a.
> > > > > > > > > > > > > v7)
> > > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > > >> > > > still going on. For this reason,
> > Category
> > > B
> > > > > > > projects
> > > > > > > > > > have
> > > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > > > Actions.
> > > > > > > > > > Category B
> > > > > > > > > > > > > repos
> > > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > > >> > > > always depended on Category A repos
> > using
> > > > > fixed
> > > > > > > > > > versions.
> > > > > > > > > > > If
> > > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > > SNAPSHOTs,
> > > > > > > breaking
> > > > > > > > > > > changes
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > Category A repositories would've had
> the
> > > > > potential
> > > > > > > > to
> > > > > > > > > > > break
> > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > >> > > > silently, leaving Category B with a
> > broken
> > > > > > > > development
> > > > > > > > > > > > stream,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > > > maintainers
> > > > > > > of
> > > > > > > > > > > > Category B
> > > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > > >> > > > as historically Category A
> contributors
> > > were
> > > > > not
> > > > > > > > > > familiar
> > > > > > > > > > > > with
> > > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Contributions made to Category B repos
> > go
> > > > > through
> > > > > > > a
> > > > > > > > > > GitHub
> > > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > > >> > > > workflow that builds the relevant part
> > of
> > > the
> > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > >> > > > the changes introduced. Changes made
> to
> > > the
> > > > > > > pipeline
> > > > > > > > > > > itself
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us
> to
> > > do
> > > > > things
> > > > > > > > > like
> > > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> > example.
> > > More
> > > > > > > > > > > importantly,
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > > timestamped
> > > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > > together
> > > > > > > > > > > > > > > >> > > > with the changes necessary to make it
> > stay
> > > > > green.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This setup, however, makes it
> impossible
> > > to
> > > > > have
> > > > > > > > > > > cross-repo
> > > > > > > > > > > > > PRs
> > > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > > simultaneously,
> > > > > > > > > with
> > > > > > > > > > > the
> > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > > around,
> > > > > and
> > > > > > > > I'm
> > > > > > > > > > not
> > > > > > > > > > > > sure
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > > Regardless,
> > > > > > > as
> > > > > > > > > > > they're
> > > > > > > > > > > > > > part
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > > release,
> > > > > so I
> > > > > > > > > > listed
> > > > > > > > > > > > them
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category D is self explanatory.
> There's
> > > only
> > > > > one
> > > > > > > > repo
> > > > > > > > > > that
> > > > > > > > > > > > has
> > > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Category E are repos that do not host
> > code
> > > > > > > directly,
> > > > > > > > > and
> > > > > > > > > > > are
> > > > > > > > > > > > > > > either
> > > > > > > > > > > > > > > >> > > > organizational entities, or host
> > websites,
> > > > > that
> > > > > > > > > > currently
> > > > > > > > > > > > are
> > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This lack of unification between
> > Category
> > > A
> > > > > and
> > > > > > > > > > Category B
> > > > > > > > > > > > is,
> > > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> > infamous
> > > > > circular
> > > > > > > > > > > > dependency
> > > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which
> we
> > > now
> > > > > can
> > > > > > > > > describe
> > > > > > > > > > > as
> > > > > > > > > > > > a
> > > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > > >> > > > dependency between Category A and
> > > Category B.
> > > > > The
> > > > > > > > way
> > > > > > > > > I
> > > > > > > > > > > see
> > > > > > > > > > > > > it,
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > had a single pipeline, building
> > everything
> > > > > from
> > > > > > > > > `drools`
> > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> > > been
> > > > > > > > > introduced,
> > > > > > > > > > > and
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem
> in
> > > our
> > > > > hands
> > > > > > > > > right
> > > > > > > > > > > now.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > > process
> > > > > > > sees
> > > > > > > > > this
> > > > > > > > > > > > lack
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > unification as a central problem, not
> > > only for
> > > > > > > this
> > > > > > > > > > > release
> > > > > > > > > > > > in
> > > > > > > > > > > > > > > >> > > > particular, but for the community as a
> > > whole.
> > > > > It
> > > > > > > is
> > > > > > > > my
> > > > > > > > > > > > belief
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > are all under the same roof, and that
> no
> > > > > > > > contribution
> > > > > > > > > > > should
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > >> > > > allowed to break any part of our
> > codebase.
> > > > > With
> > > > > > > the
> > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > > contributors
> > > > > too,
> > > > > > > > we
> > > > > > > > > > > cannot
> > > > > > > > > > > > > > keep
> > > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> > > breaking
> > > > > > > things.
> > > > > > > > > > We're
> > > > > > > > > > > > all
> > > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > > > mechanisms in
> > > > > > > > > place
> > > > > > > > > > > to
> > > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> > > Especially
> > > > > when
> > > > > > > > > these
> > > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > > >> > > > impact on parts of the codebase that
> we,
> > > > > > > > individually,
> > > > > > > > > > > > > probably
> > > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > > depending
> > > > > on
> > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > > > `kogito-images`
> > > > > > > > > > > > depending
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools`
> depending
> > on
> > > > > > > > kiegroup's
> > > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > > `7.59.0.Final`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > > > depending on
> > > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > > > codebase
> > > > > > > > here:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >
> > > > > > > > > >
> > > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > > ,
> > > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > > OptaPlanner,
> > > > > > > > > > > pointing
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > older
> > > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P5.
> > > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > > depending
> > > > > > > > > > > on
> > > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> > `2.15.3.Final`.
> > > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P6. Category C repos are out of date
> and
> > > not
> > > > > part
> > > > > > > of
> > > > > > > > > the
> > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> > > (Current
> > > > > > > version
> > > > > > > > is
> > > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > > > version,
> > > > > > > only
> > > > > > > > > by
> > > > > > > > > > > > using
> > > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> > > version
> > > > > is
> > > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > > > OptaPlanner
> > > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P7.
> > > `kie-tools`/packages/kn-plugin-workflow
> > > > > has
> > > > > > > its
> > > > > > > > > E2E
> > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the
> > same
> > > > > > > solution,
> > > > > > > > > as
> > > > > > > > > > > they
> > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > >> > > > suffer from the circular dependency
> > > between
> > > > > > > > Category A
> > > > > > > > > > and
> > > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > > >> > > > As Category A and Category B are both
> > > streams
> > > > > that
> > > > > > > > > have
> > > > > > > > > > > been
> > > > > > > > > > > > > > > really
> > > > > > > > > > > > > > > >> > > > active, I see this as a blocker, as
> > there
> > > are
> > > > > > > > > > > contributions
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> > > depends
> > > > > on
> > > > > > > > > > Category
> > > > > > > > > > > B
> > > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > > > understood
> > > > > > > as
> > > > > > > > > > > > technical
> > > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > > > something
> > > > > > > > we'll
> > > > > > > > > > > always
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> > > just a
> > > > > > > matter
> > > > > > > > of
> > > > > > > > > > > > making
> > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> > > impact
> > > > > the
> > > > > > > > > > structure
> > > > > > > > > > > or
> > > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > > >> > > > that we're talking about here, but it
> > is a
> > > > > > > > regression
> > > > > > > > > we
> > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> > > Apache
> > > > > KIE
> > > > > > > 10,
> > > > > > > > > and
> > > > > > > > > > > > that
> > > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only
> > problems
> > > > > left to
> > > > > > > > > > discuss
> > > > > > > > > > > > are
> > > > > > > > > > > > > P1
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > P2, which can't be done without a
> proper
> > > > > proposal.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > I'll try to be very meticulous here,
> > since
> > > > > from my
> > > > > > > > > > > > experience,
> > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> > > release
> > > > > not
> > > > > > > > > > working
> > > > > > > > > > > > out
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > > > possible,
> > > > > > > and
> > > > > > > > > make
> > > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > > > release,
> > > > > > > bear
> > > > > > > > > > with
> > > > > > > > > > > > me.
> > > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > > >> > > > out a timeline of events that need to
> > > happen
> > > > > in
> > > > > > > > order
> > > > > > > > > > for
> > > > > > > > > > > > our
> > > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > > >> > > > to be published, with all artifacts
> > > ending up
> > > > > in
> > > > > > > the
> > > > > > > > > > right
> > > > > > > > > > > > > > places,
> > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > >> > > > first, we need to solve problems P1
> and
> > > P2.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As you saw at the beginning of this
> > email,
> > > > > all the
> > > > > > > > > > > attempts
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > made
> > > > > > > > > > > > > > > >> > > > left us with the circular dependency
> > > showing
> > > > > up
> > > > > > > at a
> > > > > > > > > > > > different
> > > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > > >> > > > but something all these places have in
> > > common
> > > > > is
> > > > > > > > that
> > > > > > > > > > > > they're
> > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > >> > > > after kogito-apps, and before to
> > Category
> > > B.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > > > following:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > S1. We keep the original plan of
> moving
> > > the
> > > > > > > Quarkus
> > > > > > > > > Dev
> > > > > > > > > > > UIs
> > > > > > > > > > > > > from
> > > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> > > with
> > > > > > > > Management
> > > > > > > > > > and
> > > > > > > > > > > > > Task
> > > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> > > `kie-tools`.
> > > > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode`
> and
> > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools`
> too.
> > > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > > `kogito-serverless-operator`
> > > > > > > > > repo
> > > > > > > > > > > > > inside
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> > > history.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together
> solve
> > > > > problems
> > > > > > > P1
> > > > > > > > > and
> > > > > > > > > > > P2.
> > > > > > > > > > > > Of
> > > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > > >>
> > > > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > This doesn't come without
> consequences,
> > of
> > > > > course,
> > > > > > > > as
> > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > > `kogito-swf-builder`
> > > > > > > > images,
> > > > > > > > > > and
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be
> > > moving
> > > > > from
> > > > > > > > > > > Category A
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > Category B. This move would make them
> > > have to
> > > > > > > > > reference
> > > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs.
> > Since
> > > > > > > > > > `kogito-images`
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are
> already
> > > > > their own
> > > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > > >> > > > Category A, though, contributions made
> > in
> > > a
> > > > > > > > cross-repo
> > > > > > > > > > > > fashion
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> > > possible, now
> > > > > > > via a
> > > > > > > > > > > single
> > > > > > > > > > > > PR
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> > > Category
> > > > > A and
> > > > > > > > > > > Category
> > > > > > > > > > > > B
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > >> > > > continue not being possible, and a
> > 1-week
> > > > > delay
> > > > > > > > > between
> > > > > > > > > > > > > merging
> > > > > > > > > > > > > > > >> > > > something on Category A and using it
> on
> > > > > Category B
> > > > > > > > > will
> > > > > > > > > > > > still
> > > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > It's worth mentioning that
> `kie-tools`,
> > > > > however,
> > > > > > > > does
> > > > > > > > > > > allow
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > > >> > > > checkouts and partial builds, so
> working
> > > with
> > > > > a
> > > > > > > > subset
> > > > > > > > > > of
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > >> > > > is possible and encouraged. Making
> > changes
> > > > > only to
> > > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> > > example,
> > > > > will
> > > > > > > > have
> > > > > > > > > > the
> > > > > > > > > > > PR
> > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see
> > here:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > > >> > > > We're not compromising when running
> > > partial
> > > > > builds
> > > > > > > > > too.
> > > > > > > > > > We
> > > > > > > > > > > > > know
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > >> > > > the entire repo will continue working
> > even
> > > > > after
> > > > > > > > only
> > > > > > > > > > > > > building a
> > > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > > >> > > > subset of the changes. Doing partial
> or
> > > full
> > > > > > > builds
> > > > > > > > is
> > > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> > > proposing
> > > > > we
> > > > > > > > move a
> > > > > > > > > > > bunch
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I
> see
> > > this
> > > > > as a
> > > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would
> host
> > > some
> > > > > > > > > additional
> > > > > > > > > > > > stuff
> > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > > > continue
> > > > > > > > moving
> > > > > > > > > > > > > forward.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > As I mentioned on other places,
> > > `kie-tools`
> > > > > > > became a
> > > > > > > > > > > > polyglot
> > > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > > >> > > > out of necessity, and although I'm
> > really
> > > > > proud of
> > > > > > > > > what
> > > > > > > > > > we
> > > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > > >> > > > there so far, I don't think
> `kie-tools`
> > > has a
> > > > > > > setup
> > > > > > > > > that
> > > > > > > > > > > is
> > > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > > >> > > > for all the different nuances that
> > > compose our
> > > > > > > > > > community.
> > > > > > > > > > > > I'm
> > > > > > > > > > > > > > well
> > > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that
> does
> > > not
> > > > > > > follow
> > > > > > > > > > > > widespread
> > > > > > > > > > > > > > > >> > > > conventions will scare some people
> away,
> > > and
> > > > > as
> > > > > > > much
> > > > > > > > > as
> > > > > > > > > > > > we've
> > > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > >> > > > make build instructions clear, we
> can't
> > > > > always get
> > > > > > > > > past
> > > > > > > > > > > the
> > > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > > >> > > > some people have towards the
> "front-end"
> > > > > > > ecosystem.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > With all that said, I keep thinking
> this
> > > is
> > > > > the
> > > > > > > best
> > > > > > > > > > > course
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > > >> > > > for us right now. We keep most of our
> > > stuff
> > > > > > > > unchanged,
> > > > > > > > > > we
> > > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> > > > release, and we have a working setup
> > that
> > > will
> > > > > > > suit
> > > > > > > > us
> > > > > > > > > > > well
> > > > > > > > > > > > > > while
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > >> > > > discuss and reach a conclusion
> regarding
> > > the
> > > > > > > future
> > > > > > > > of
> > > > > > > > > > our
> > > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Let me paint a quick picture here of
> > what
> > > our
> > > > > code
> > > > > > > > > base
> > > > > > > > > > > > would
> > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal
> is
> > > > > accepted:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > > > >> > > > A
> > > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-examples
> > > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-images
> > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > > > >> > > > A
> > > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > B
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > D
> > incubator-kie-kogito-operator
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > > > >> > > > E
> incubator-kie-kogito-website
> > > > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > > > >> > > > E
> incubator-kie-kogito-online
> > > > > > > > > > > > > > > >> > > > E
> > > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > * Category C becomes part of Category
> A,
> > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> > > entirely
> > > > > inside
> > > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> > > images
> > > > > and
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > > > `kie-tools`,
> > > > > > > > there
> > > > > > > > > > are
> > > > > > > > > > > > no
> > > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > > > granularly
> > > > > > > > > build:
> > > > > > > > > > > > > > > >> > > > 1.
> > > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > > >> > > > 2.
> packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> > > (containing
> > > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> > > (contents
> > > > > from
> > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > The second part of the proposal is the
> > > release
> > > > > > > > process
> > > > > > > > > > > > itself,
> > > > > > > > > > > > > > > >> > > > assuming the structure above is what
> we
> > > have.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be
> > > used as
> > > > > > > > cutting
> > > > > > > > > > > point
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to
> > > this
> > > > > > > > > timestamped
> > > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > > > >> > > > 3. At this point, with everything
> > > working, we
> > > > > can
> > > > > > > > > branch
> > > > > > > > > > > out
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the
> > timestamped
> > > > > SNAPSHOT
> > > > > > > > > tag,
> > > > > > > > > > > and
> > > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> > > update
> > > > > > > their
> > > > > > > > > > > versions
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > > > Category A
> > > > > > > > > repos
> > > > > > > > > > > > using
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the
> > > release
> > > > > based
> > > > > > > > on
> > > > > > > > > > the
> > > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > > >> > > > branches, given we don't expect any
> code
> > > > > changes
> > > > > > > > > > anymore.
> > > > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to
> > > start
> > > > > the
> > > > > > > > > release
> > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > > manual/automated
> > > > > > > > > > release
> > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > > pushed
> > > > > to
> > > > > > > Git,
> > > > > > > > > and
> > > > > > > > > > > > built
> > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > > > artifacts
> > > > > > > to
> > > > > > > > be
> > > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > > manual/automated
> > > > > > > > > > release
> > > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > > pushed
> > > > > to
> > > > > > > Git,
> > > > > > > > > and
> > > > > > > > > > > > built
> > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > > > >> > > > 12. Category E repos can be manually
> > > tagged
> > > > > with
> > > > > > > > > 10.0.0
> > > > > > > > > > > from
> > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > More needs to be discussed if we're
> > > planning
> > > > > to
> > > > > > > > > maintain
> > > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > > >> > > > release streams in parallel, but I
> guess
> > > it
> > > > > can
> > > > > > > wait
> > > > > > > > > for
> > > > > > > > > > > > after
> > > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> > > > > forward to
> > > > > > > > > > hearing
> > > > > > > > > > > > back
> > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Of course, alternative solutions are
> > > possible.
> > > > > > > This
> > > > > > > > > > email,
> > > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > > >> > > > summarizes my view of how we should
> > > attack the
> > > > > > > > > problem,
> > > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > > >> > > > disruption, required effort, the
> release
> > > > > process
> > > > > > > > > itself,
> > > > > > > > > > > and
> > > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > > >> > > > Feel free to propose alternatives.
> This
> > is
> > > > > not a
> > > > > > > > > voting
> > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Gabriele Cardosi <ga...@gmail.com>.
I have the impression there are still two different POV.
On one side, I agree that we should try to make the release ASAP. But we
should also consider that if we release something that may create problems
to the community itself, just for the rush of it, then the community would
be much more disappointed.
On the other side, I think the concern is to keep transforming a temporary
solution, that was not the only possible one, to the only possible one,
i.e. that kie-tools become the central point of delivery, with a
Frankenstein effect whose consequences in long term are hard to imagine.
So, maybe if we can make a sort of agreement that everything would be
revisited "after the release", with a sort of "task force" that analyzes
everything from scratch, and that includes all the ones that are involved
by it, we could break this deadlock.
WDYT ?
Il giorno mer 13 mar 2024 alle ore 15:41 Francisco Javier Tirado Sarti <
ftirados@redhat.com> ha scritto:
> 1) Ok, if that is the case, I do not get why your first proposal was not
> the one I'm proposing and it is apparently not detailed enough. To move
> kn-workflow from tooling to operator one and change the order in which the
> repos are being processed. Basically, the problem of the proposed solution
> is that it kind of converts tooling repo into a pretty heterodox repo
> compared with runtimes, drools or operator one. Also once tooling is not a
> final repo in the overall chain, we can consider moving examples as the
> final one and include tooling showcases there (rather than splitting
> examples into examples with tooling and examples without tooling).
> 2) I think this distinction between A and B is one between several possible
> categorizations (not much, including no categorization at all) that
> deserves a separate discussion. I will open a separate thread for that
> purpose, since we are not going to change that now and it is not really
> part of the proposal.
>
> On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <tiagobentofernandes@gmail.com
> >
> wrote:
>
> > Francisco,
> >
> > 1) That's what this thread is all about... You know I don't think it's
> > ok. That's why I'm proposing the two images and the operator to move
> > into the `kie-tools` repo, where we can more granularly control the
> > order things are built, thus removing the dependency cycle.
> >
> > 2) Not sure we understand the same thing by "freeze". My proposal is
> > that we select a timestamped SNAPSHOT version from Category A repos to
> > use as base for a release. We give Category B repos some time to
> > adjust, and then cut the release branches. This can happen anytime,
> > and no contributions would ever stop because of it. The development
> > branches can continue accepting PRs normally, even during the release
> > process. Now, if what you're asking is why Category B repos refer to
> > Category A repos via timestamped SNAPSHOTs, the answer is in my first
> > email. See the paragraph starting with "An important note here is that
> > Category B repositories...".
> >
> > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti
> > <ft...@redhat.com> wrote:
> > >
> > > Tiago
> > > There are a couple of simple and straightforward questions that I
> > > formulated, but since we both write a lot, it might have been lost.
> > Please
> > > let me ask them again.
> > > 1) Do you think it is ok that tools repo is executed after generation
> of
> > > docker images that are supposed to include those tools or the operator
> > that
> > > is supposed to deploy such images?
> > That's what this thread is all about... You know I'm not ok with it,
> > that's why I'm proposing the two images and the operator to move into
> > the `kie-tools` repo, where we can more granularly control the order
> > things are built and remove the dependency cycle.
> > > 2) Besides that, although not directly related with the current
> proposal
> > we
> > > are discussing, I really think there are some restrictions taken for
> > > granted that are arbitrary and difficult to sustain on strictly
> technical
> > > arguments. For example, the need to freeze the rest of the software
> > before
> > > tools are generated. Why? We have dependencies between repos that are
> not
> > > handled that way: Apps depend on runtimes. Runtimes depend on drools,
> > > Operator depend on runtimes,....and we are not freezing that repos
> since
> > we
> > > are all releasing at the same time. If we are all releasing at the same
> > > time, what's the rationale behind the freeze?
> > >
> > >
> > >
> > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <ti...@apache.org>
> > wrote:
> > >
> > > > Glad to see the interest this proposal has gotten, and it's good to
> > > > see some alternatives being drafted here, although still lacking
> clear
> > > > definitions and analysis in regards to disruption, required effort,
> > > > the release process itself, and history. Of course, lots of details
> > > > and clarity on the execution part would be missing too.
> > > >
> > > > As of this moment, based on what I read here, I'm assuming that
> > > > everyone who participated so far doesn't see the initial proposal as
> > > > problematic in terms of feasibility, but some of you have a
> preference
> > > > not to go with it, because it is "wrong", and apparently because it
> > > > would "jeopardize the evolution of the project". Reading these last
> > > > words made me a little sad, to be honest. But I can deal with it :)
> > > >
> > > > Please let's try and keep the discussion as objective as possible.
> > > > "Right" and "wrong" are too subjective for this kind of conversation.
> > > >
> > > > Now, being practical, unless there are clear arguments based on facts
> > > > and objective concepts that invalidate the initial proposal shared on
> > > > this email, it seems to me that it is currently the only viable
> > > > proposal we have for unblocking and releasing Apache KIE 10. Of
> > > > course, if we end up seeing an alternative proposal with enough
> > > > details and a clear execution plan, I think then we'll be in a very
> > > > good position to choose from multiple options!
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <al...@porcelli.me>
> > wrote:
> > > > >
> > > > > Francisco and Gabriele,
> > > > >
> > > > > I understand and acknowledge your desire to find the “right”
> solution
> > > > > instead to work on a temporary “patch” - however without a detailed
> > > > > proposal I don’t think we can properly evaluate the impact of your
> > > > > suggestion.
> > > > >
> > > > > When I spoke with different SMEs that included tools and CI, the
> > > > > guesstimate for making the necessary changes on CI and codebase to
> > > > > basically have images and operators in the end of the build chain
> is
> > > > > something like 2 months of effort. Another impact that needs to be
> > > > > discussed is that KIE Tools repo had to be injected in the middle
> of
> > all
> > > > > pipelines - forcing all PR checks and nightlies to build all repos
> > (PR
> > > > > checks will likely take 12+ hours… I even heard that it could be
> > even 24
> > > > > hours).
> > > > >
> > > > > Based on the input above, I think it’s quite risk to move in such
> > > > direction
> > > > > without a more detailed plan… because 2 months could be turned
> > easily in
> > > > 6!
> > > > > And this is exactly what happened when we guessed that moving to
> > Apache
> > > > > would take no more than 3 months. But here we are.
> > > > >
> > > > > I really strongly suggest that we focus on a release that could be
> > > > > achievable in less than a month from now, and we - after release -
> > have a
> > > > > in depth discussion about the overall codebase and ci organization.
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > > gabriele.cardosi@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Alex,
> > > > > > my suggestion is to move the building of all docker images, from
> > > > whatever
> > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to
> > be
> > > > > > invoked after all the others.
> > > > > > I'm not sure if this would solve all the issues, and since I
> could
> > not
> > > > > > enter in the details of all the involved code, my suggestion may
> > be too
> > > > > > naive.
> > > > > > Having spent almost all of the last year in CI, I may say that,
> at
> > > > least
> > > > > > for the kie-tools repo, removing the image build step from it
> > should
> > > > not be
> > > > > > too difficult (since it is an issue we already faced and solved).
> > > > > > If, with "detailed proposal", you mean a complete list of all
> > modules
> > > > to be
> > > > > > moved and dependency refactoring, of course I can not provide it
> > right
> > > > now.
> > > > > >
> > > > > > Anyway, I share the concern from Francisco: undoing something is
> > almost
> > > > > > always harder than doing it "rightly" from scratch...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado
> > Sarti
> > > > <
> > > > > > ftirados@redhat.com> ha scritto:
> > > > > >
> > > > > > > I do not think estimations should be the only driver to make a
> > > > decision,
> > > > > > > especially when the current proposal is conceptually
> incompatible
> > > > with
> > > > > > the
> > > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > > Given my knowledge of the CI it is nearly impossible for me to
> > give
> > > > a
> > > > > > fair
> > > > > > > estimate of how much it might take to achieve step 2) of my
> > previous
> > > > > > e-mail
> > > > > > > . It might take a while or it might be pretty easy after all, I
> > don't
> > > > > > > really know, but I think it will be a good idea if some of the
> > > > experts
> > > > > > on
> > > > > > > CI in the team (the ones that set up the pipeline, which was a
> > huge
> > > > > > > achievement) give an estimate, not me. Estimating how much it
> > takes
> > > > to
> > > > > > > merge two existing repos (without altering CI) is easier, but
> it
> > > > does not
> > > > > > > mean we are doing the right thing.
> > > > > > > My main concern is that it will be very difficult for me to
> > explain
> > > > to
> > > > > > > someone that arrives new to the team, that having experts on CI
> > on
> > > > the
> > > > > > > team, we decided to merge two repos (once merged, it would be
> > rather
> > > > > > > difficult to unmerge) rather than fix the CI, because of
> > expediency.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> > porcelli@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Francisco,
> > > > > > > >
> > > > > > > > Please take the time to make the more in depth analysis
> needed
> > and
> > > > > > > provide
> > > > > > > > a more detailed plan… so we - as community- can evaluate the
> > size
> > > > of
> > > > > > the
> > > > > > > > effort. In the conceptual level you shared it’s near
> > impossible to
> > > > > > > estimate
> > > > > > > > the size of the effort and compare with the current proposal.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado
> Sarti <
> > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > >
> > > > > > > > > I think I already did a high level proposal.
> > > > > > > > > 1) Remove all dependencies from tooling to images, so
> images
> > > > depend
> > > > > > on
> > > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > > 2) Then change CI to deal with tooling repo before dealing
> > with
> > > > > > images
> > > > > > > > > repo.
> > > > > > > > > I understand that CI details are tricky and since I'm not
> > > > familiar
> > > > > > with
> > > > > > > > CI
> > > > > > > > > in any way, I barely can make a low level design, but we do
> > not
> > > > need
> > > > > > to
> > > > > > > > fix
> > > > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> > alex@porcelli.me
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco and Grabriele,
> > > > > > > > > >
> > > > > > > > > > You may not like or understand why the current state of
> > the CI
> > > > is
> > > > > > > like
> > > > > > > > > > that… actually has been in Red Hat and has been
> replicated
> > in
> > > > > > Apache
> > > > > > > as
> > > > > > > > > > used to be….
> > > > > > > > > >
> > > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > > >
> > > > > > > > > > If you disagree with the current plan, please provide a
> > > > detailed
> > > > > > > > > > alternative so we, as community, can better evaluate the
> > pros
> > > > and
> > > > > > > cons
> > > > > > > > of
> > > > > > > > > > each proposal.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I think it’s also fair to say that, post 10 release we
> > need to
> > > > > > have a
> > > > > > > > > much
> > > > > > > > > > in depth discussion about how our codebase is organized,
> > it’s
> > > > clear
> > > > > > > > that
> > > > > > > > > > it’s not working.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > As Francisco said,
> > > > > > > > > > > I also have the impression that the "images" (if we are
> > > > talking
> > > > > > of
> > > > > > > > > docker
> > > > > > > > > > > images) should be the very last one to be built, in a
> > > > standalone
> > > > > > > > repo.
> > > > > > > > > > > That way, they may "combine" artifacts that are built
> in
> > > > > > different
> > > > > > > > > repos,
> > > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > > Moving them out of all the repos
> (kogito-apps/kie-tools)
> > > > maybe
> > > > > > > could
> > > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > > (I also think there are some statements of undisputable
> > needs
> > > > > > while
> > > > > > > > > they
> > > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > > Anyway, this latter point is for longer, following,
> > > > discussion.)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco
> Javier
> > > > Tirado
> > > > > > > > Sarti
> > > > > > > > > <
> > > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > > >
> > > > > > > > > > > > Alex,
> > > > > > > > > > > > There are two assumptions that deserve further
> > discussion:
> > > > > > > > > > > > 1) That tool has to be the last to build. why? it
> does
> > not
> > > > have
> > > > > > > > more
> > > > > > > > > > > sense
> > > > > > > > > > > > to build final images after everything else has been
> > > > built?-
> > > > > > > > > > > > 2) That the impact (in terms of effort now) on fixing
> > CI is
> > > > > > > bigger
> > > > > > > > > than
> > > > > > > > > > > the
> > > > > > > > > > > > impact (long term consequences) of consolidating two
> > > > unrelated
> > > > > > > > piece
> > > > > > > > > of
> > > > > > > > > > > > software within the same repository.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > > alex@porcelli.me
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Francisco,
> > > > > > > > > > > > >
> > > > > > > > > > > > > This was discussed as an alternative solution,
> > however
> > > > it has
> > > > > > > > major
> > > > > > > > > > > > impact
> > > > > > > > > > > > > on CI and there’s also the fact Tool has been
> always
> > the
> > > > last
> > > > > > > to
> > > > > > > > > > build
> > > > > > > > > > > > and
> > > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> > world
> > > > there
> > > > > > > is
> > > > > > > > no
> > > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > > >
> > > > > > > > > > > > > So, based on our evaluation… the proposal here is
> the
> > > > least
> > > > > > > > > > disruptive
> > > > > > > > > > > > and
> > > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > _____________
> > > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> > Tirado
> > > > > > Sarti <
> > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> > embracing
> > > > the
> > > > > > fact
> > > > > > > > > that
> > > > > > > > > > > > > > kogito-images depend on kie-tools, because we
> want
> > > > those
> > > > > > > images
> > > > > > > > > to
> > > > > > > > > > > > > include
> > > > > > > > > > > > > > tools.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > > > Tirado
> > > > > > > Sarti
> > > > > > > > <
> > > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > > kn-plugin-workflow
> > > > > > > > to
> > > > > > > > > > > > > > > kogito-images (so there is not longer
> dependency
> > from
> > > > > > tools
> > > > > > > > to
> > > > > > > > > > > > images)
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique
> Gonzalez
> > > > > > Martinez
> > > > > > > <
> > > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> > (apache)
> > > > <
> > > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> > I say +1 in order to move forward with the
> 10.
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli
> <
> > > > > > > > > alex@porcelli.me
> > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > I spent the last day or so working closely
> > with
> > > > > > Tiago,
> > > > > > > > > > > exploring
> > > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > > >> > > options and getting deeper on the impact
> and
> > > > > > > evaluating
> > > > > > > > > the
> > > > > > > > > > > > > overall
> > > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > > proposal
> > > > > > as
> > > > > > > > the
> > > > > > > > > > > most
> > > > > > > > > > > > > > >> > > viable option for unblocking the 10
> release
> > in
> > > > the
> > > > > > > > > > reasonable
> > > > > > > > > > > > time
> > > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago
> Bento
> > <
> > > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> > time,
> > > > as
> > > > > > this
> > > > > > > > > > matter
> > > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes to
> > read,
> > > > > > > > according
> > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As you may have followed on a separate
> > thread
> > > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > > >
> > > > > > >
> https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > > ),
> > > > > > > > > > > > > > >> > > > many of us were working towards
> removing a
> > > > > > circular
> > > > > > > > > > > dependency
> > > > > > > > > > > > > > >> > > > currently present between `kogito-apps`
> > and
> > > > > > > > `kie-tools`.
> > > > > > > > > > As
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > > > finding the
> > > > > > > > > > circular
> > > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> > breakdown of
> > > > the
> > > > > > > > things
> > > > > > > > > > we
> > > > > > > > > > > > did,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Right now, even though we started the
> > effort
> > > > to
> > > > > > move
> > > > > > > > the
> > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > Dev
> > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't
> been
> > > > able to
> > > > > > > do
> > > > > > > > it
> > > > > > > > > > > yet,
> > > > > > > > > > > > as
> > > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java
> 17,
> > > > Maven
> > > > > > > 3.9.6,
> > > > > > > > > and
> > > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > This
> > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > > >> > > >
> > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > > .
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > |==> 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > C | 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > Y | 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > L |
> ==========================
> > > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> `kie-tools`/extended-services
> > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > > >> > > > * and
> > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > > depend
> > > > > > > > > > > > > > >> on
> > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > > `kie-tools`,
> > > > > > we
> > > > > > > > > > would've
> > > > > > > > > > > > > had:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > C |==> 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/kn-plugin-workflow
> > > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > > >> > > > * and
> > > > `kogito-images`/kogito-swf-devmode
> > > > > > > > depends
> > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> > image to
> > > > > > > > > > `kie-tools`,
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 01.
> > > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > 02.
> > incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > 03.
> > > > incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > 04.
> > > > incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * As
> > `kie-tools`/kn-plugin-workflow
> > > > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > > >> > > > * and
> `kogito-serverless-operator`
> > > > depends
> > > > > > > on
> > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> > than a
> > > > > > simple
> > > > > > > > > > > circular
> > > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > After multiple conversations with a lot
> of
> > > > people,
> > > > > > > > it's
> > > > > > > > > > been
> > > > > > > > > > > > > > really
> > > > > > > > > > > > > > >> > > > hard coming up with a simple solution
> that
> > > > makes
> > > > > > it
> > > > > > > > > > possible
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> build
> > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving
> > the
> > > > way
> > > > > > > > > everyone
> > > > > > > > > > is
> > > > > > > > > > > > > used
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > contributing to the multiple
> repositories
> > we
> > > > have.
> > > > > > > > More
> > > > > > > > > > than
> > > > > > > > > > > > > that,
> > > > > > > > > > > > > > >> > > > while making this assessment, I found
> more
> > > > > > problems
> > > > > > > > > that,
> > > > > > > > > > in
> > > > > > > > > > > > my
> > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > > > forward
> > > > > > with
> > > > > > > > my
> > > > > > > > > > > > proposal
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we
> can
> > use
> > > > > > > Apache's
> > > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate
> about
> > > > this
> > > > > > > really
> > > > > > > > > > > > > complicated
> > > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective about
> > the
> > > > > > current
> > > > > > > > > > > situation
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > >> our
> > > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> > currently
> > > > see.
> > > > > > > > I'll
> > > > > > > > > > > start
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > > purposes,
> > > > > > > point
> > > > > > > > > out
> > > > > > > > > > > > some
> > > > > > > > > > > > > > >> > > > problems that I believe are blocking our
> > 10
> > > > > > release,
> > > > > > > > > > explain
> > > > > > > > > > > > my
> > > > > > > > > > > > > > >> > > > proposal and discuss some consequences
> to
> > > > what I'm
> > > > > > > > > > > proposing.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count:
> > 11)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @
> `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts
> @
> > > > `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > > >> > > > -
> > incubator-kie-kogito-serverless-operator @
> > > > > > `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > > >> > > > -
> > incubator-kie-sandbox-quarkus-accelerator @
> > > > > > > `0.0.0`
> > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @
> `main`
> > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > > >> > > > (Issues only, README should be
> > updated @
> > > > > > `main`.
> > > > > > > > > Same
> > > > > > > > > > > for
> > > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > > > >> > > > (The Kogito website. Develop &
> deploy
> > at
> > > > the
> > > > > > > > `main`
> > > > > > > > > > > > branch.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`.
> > Push @
> > > > > > > > `deploy`
> > > > > > > > > to
> > > > > > > > > > > > > update
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @
> `gh-pages`
> > > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > > sandbox.kie.org
> > > > > > and
> > > > > > > > KIE
> > > > > > > > > > > Tools'
> > > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @
> > `main`
> > > > > > > > > > > > > > >> > > > (Same as above, but for manual
> sanity
> > > > checks
> > > > > > > > during
> > > > > > > > > > the
> > > > > > > > > > > > > > staging
> > > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I grouped the repositories by category,
> > and
> > > > listed
> > > > > > > > them
> > > > > > > > > > in a
> > > > > > > > > > > > > > >> > > > topological order. Keep in mind that
> when
> > > > > > flattening
> > > > > > > > > out a
> > > > > > > > > > > > tree,
> > > > > > > > > > > > > > >> there
> > > > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > > > OptaPlanner
> > > > > > > > > > > could've
> > > > > > > > > > > > > been
> > > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category A repos are what I've been
> > referring
> > > > to
> > > > > > as
> > > > > > > > > > `drools`
> > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner
> > is
> > > > inside
> > > > > > > > that
> > > > > > > > > > > > stream,
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > way these repositories reference each
> > other
> > > > are
> > > > > > > > through
> > > > > > > > > > > Maven
> > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> > 999-SNAPSHOT
> > > > > > > > version.
> > > > > > > > > > This
> > > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > > >> > > > is well-known to the team, and although
> > > > flawed for
> > > > > > > > > > intra-day
> > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > >> > > > and disruptive for people in many
> > different
> > > > time
> > > > > > > > zones,
> > > > > > > > > it
> > > > > > > > > > > is
> > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> > with, I
> > > > > > > assume.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Contributions made to Category A have
> some
> > > > > > dedicated
> > > > > > > > > > > > pipelines,
> > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> > build
> > > > > > > cross-repo
> > > > > > > > > PRs
> > > > > > > > > > > > > > together
> > > > > > > > > > > > > > >> > > > and verify that the codebase will
> continue
> > > > working
> > > > > > > as
> > > > > > > > > > > expected
> > > > > > > > > > > > > > after
> > > > > > > > > > > > > > >> > > > they're all merged. From what I could
> > gather,
> > > > > > there
> > > > > > > > are
> > > > > > > > > > some
> > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > > cross-repo
> > > > > > > PRs.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps,
> > and
> > > > > > > > > > kogito-examples
> > > > > > > > > > > > > > >> > > > - optaplanner, and
> optaplanner-quickstarts
> > > > > > > > > > > > > > >> > > > - kogito-images, and
> > > > kogito-serverless-operator
> > > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs
> to
> > any
> > > > > > > > > combination
> > > > > > > > > > of
> > > > > > > > > > > > > repos
> > > > > > > > > > > > > > >> > > > that are not part of the same
> "sub-stream"
> > > > cannot
> > > > > > be
> > > > > > > > > > > verified
> > > > > > > > > > > > > > before
> > > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > > dependent
> > > > > > on
> > > > > > > > > > > individual
> > > > > > > > > > > > > > >> > > > contributors building stuff on their
> > machines
> > > > to
> > > > > > > > verify
> > > > > > > > > > that
> > > > > > > > > > > > it
> > > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with
> these
> > > > > > > pipelines,
> > > > > > > > so
> > > > > > > > > > > > please
> > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category B repos are what I've been
> > referring
> > > > to
> > > > > > as
> > > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > > >> > > > stream. The first repo there is a
> template
> > > > > > > repository
> > > > > > > > > that
> > > > > > > > > > > is
> > > > > > > > > > > > > used
> > > > > > > > > > > > > > >> by
> > > > > > > > > > > > > > >> > > > people starting projects from scratch on
> > KIE
> > > > > > > Sandbox,
> > > > > > > > > > > similar
> > > > > > > > > > > > > to a
> > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The other
> > one
> > > > is the
> > > > > > > KIE
> > > > > > > > > > Tools
> > > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> > build
> > > > > > system.
> > > > > > > > > > > > Currently,
> > > > > > > > > > > > > > KIE
> > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > > TypeScript
> > > > > > > > > libraries
> > > > > > > > > > > and
> > > > > > > > > > > > > > apps,
> > > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts.
> The
> > > > > > > `kie-tools`
> > > > > > > > > > > monorepo
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > >> > > > configured to work with sparse checkouts
> > and
> > > > can
> > > > > > do
> > > > > > > > > > partial
> > > > > > > > > > > > > > builds.
> > > > > > > > > > > > > > >> > > > Category B repos refer to Category A
> repos
> > > > through
> > > > > > > > > > > timestamped
> > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> > recently
> > > > > > > > > introduced
> > > > > > > > > > > that
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > > artifacts
> > > > > > > > under
> > > > > > > > > a
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> > format,
> > > > > > > published
> > > > > > > > > > weekly
> > > > > > > > > > > > > every
> > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are
> an
> > > > > > evolution
> > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> > release
> > > > for
> > > > > > all
> > > > > > > > of
> > > > > > > > > > > Apache
> > > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > An important note here is that Category
> B
> > > > > > > repositories
> > > > > > > > > > have
> > > > > > > > > > > > been
> > > > > > > > > > > > > > >> > > > historically kept out of any automations
> > we
> > > > used
> > > > > > to
> > > > > > > > > have,
> > > > > > > > > > > way
> > > > > > > > > > > > > back
> > > > > > > > > > > > > > >> > > > when Kogito started and we had the
> > Business
> > > > > > Central
> > > > > > > > > > (a.k.a.
> > > > > > > > > > > > v7)
> > > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > > >> > > > still going on. For this reason,
> Category
> > B
> > > > > > projects
> > > > > > > > > have
> > > > > > > > > > > > > > developed
> > > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > > Actions.
> > > > > > > > > Category B
> > > > > > > > > > > > repos
> > > > > > > > > > > > > > >> have
> > > > > > > > > > > > > > >> > > > always depended on Category A repos
> using
> > > > fixed
> > > > > > > > > versions.
> > > > > > > > > > If
> > > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> > SNAPSHOTs,
> > > > > > breaking
> > > > > > > > > > changes
> > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > > potential
> > > > > > > to
> > > > > > > > > > break
> > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > >> > > > silently, leaving Category B with a
> broken
> > > > > > > development
> > > > > > > > > > > stream,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > > maintainers
> > > > > > of
> > > > > > > > > > > Category B
> > > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > > >> > > > as historically Category A contributors
> > were
> > > > not
> > > > > > > > > familiar
> > > > > > > > > > > with
> > > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Contributions made to Category B repos
> go
> > > > through
> > > > > > a
> > > > > > > > > GitHub
> > > > > > > > > > > > > Actions
> > > > > > > > > > > > > > >> > > > workflow that builds the relevant part
> of
> > the
> > > > > > > > > `kie-tools`
> > > > > > > > > > > > > monorepo
> > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > >> > > > the changes introduced. Changes made to
> > the
> > > > > > pipeline
> > > > > > > > > > itself
> > > > > > > > > > > > are
> > > > > > > > > > > > > > also
> > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to
> > do
> > > > things
> > > > > > > > like
> > > > > > > > > > > > > atomically
> > > > > > > > > > > > > > >> > > > bumping the Node.js version, for
> example.
> > More
> > > > > > > > > > importantly,
> > > > > > > > > > > it
> > > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > > timestamped
> > > > > > > > > SNAPSHOT
> > > > > > > > > > > > > > together
> > > > > > > > > > > > > > >> > > > with the changes necessary to make it
> stay
> > > > green.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This setup, however, makes it impossible
> > to
> > > > have
> > > > > > > > > > cross-repo
> > > > > > > > > > > > PRs
> > > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > > simultaneously,
> > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > > > > > current
> > > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> > around,
> > > > and
> > > > > > > I'm
> > > > > > > > > not
> > > > > > > > > > > sure
> > > > > > > > > > > > > if
> > > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > > Regardless,
> > > > > > as
> > > > > > > > > > they're
> > > > > > > > > > > > > part
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> > release,
> > > > so I
> > > > > > > > > listed
> > > > > > > > > > > them
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category D is self explanatory. There's
> > only
> > > > one
> > > > > > > repo
> > > > > > > > > that
> > > > > > > > > > > has
> > > > > > > > > > > > > > >> already
> > > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Category E are repos that do not host
> code
> > > > > > directly,
> > > > > > > > and
> > > > > > > > > > are
> > > > > > > > > > > > > > either
> > > > > > > > > > > > > > >> > > > organizational entities, or host
> websites,
> > > > that
> > > > > > > > > currently
> > > > > > > > > > > are
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > >> part
> > > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This lack of unification between
> Category
> > A
> > > > and
> > > > > > > > > Category B
> > > > > > > > > > > is,
> > > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > > >> > > > what allowed us to introduce the
> infamous
> > > > circular
> > > > > > > > > > > dependency
> > > > > > > > > > > > > > >> between
> > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we
> > now
> > > > can
> > > > > > > > describe
> > > > > > > > > > as
> > > > > > > > > > > a
> > > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > > >> > > > dependency between Category A and
> > Category B.
> > > > The
> > > > > > > way
> > > > > > > > I
> > > > > > > > > > see
> > > > > > > > > > > > it,
> > > > > > > > > > > > > if
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > had a single pipeline, building
> everything
> > > > from
> > > > > > > > `drools`
> > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> > been
> > > > > > > > introduced,
> > > > > > > > > > and
> > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem in
> > our
> > > > hands
> > > > > > > > right
> > > > > > > > > > now.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> > process
> > > > > > sees
> > > > > > > > this
> > > > > > > > > > > lack
> > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > unification as a central problem, not
> > only for
> > > > > > this
> > > > > > > > > > release
> > > > > > > > > > > in
> > > > > > > > > > > > > > >> > > > particular, but for the community as a
> > whole.
> > > > It
> > > > > > is
> > > > > > > my
> > > > > > > > > > > belief
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > > > contribution
> > > > > > > > > > should
> > > > > > > > > > > > be
> > > > > > > > > > > > > > >> > > > allowed to break any part of our
> codebase.
> > > > With
> > > > > > the
> > > > > > > > > > > increasing
> > > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > > >> > > > of code, and hopefully number of
> > contributors
> > > > too,
> > > > > > > we
> > > > > > > > > > cannot
> > > > > > > > > > > > > keep
> > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> > breaking
> > > > > > things.
> > > > > > > > > We're
> > > > > > > > > > > all
> > > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > > mechanisms in
> > > > > > > > place
> > > > > > > > > > to
> > > > > > > > > > > > > > prevent
> > > > > > > > > > > > > > >> us
> > > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> > Especially
> > > > when
> > > > > > > > these
> > > > > > > > > > > > mistakes
> > > > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > > > individually,
> > > > > > > > > > > > probably
> > > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> > depending
> > > > on
> > > > > > > > > > kiegroup's
> > > > > > > > > > > > KIE
> > > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > > `kogito-images`
> > > > > > > > > > > depending
> > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending
> on
> > > > > > > kiegroup's
> > > > > > > > > > > `lienzo`
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > > `7.59.0.Final`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > > depending on
> > > > > > > > > > > kiegroup's
> > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > > codebase
> > > > > > > here:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >
> > > > > > > > >
> > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > > ,
> > > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > > OptaPlanner,
> > > > > > > > > > pointing
> > > > > > > > > > > to
> > > > > > > > > > > > > > older
> > > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P5.
> > > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > > depending
> > > > > > > > > > on
> > > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus
> `2.15.3.Final`.
> > > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P6. Category C repos are out of date and
> > not
> > > > part
> > > > > > of
> > > > > > > > the
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > > A
> > > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> > (Current
> > > > > > version
> > > > > > > is
> > > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > > version,
> > > > > > only
> > > > > > > > by
> > > > > > > > > > > using
> > > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> > version
> > > > is
> > > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > > OptaPlanner
> > > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P7.
> > `kie-tools`/packages/kn-plugin-workflow
> > > > has
> > > > > > its
> > > > > > > > E2E
> > > > > > > > > > > > disabled
> > > > > > > > > > > > > > >> after
> > > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the
> same
> > > > > > solution,
> > > > > > > > as
> > > > > > > > > > they
> > > > > > > > > > > > > both
> > > > > > > > > > > > > > >> > > > suffer from the circular dependency
> > between
> > > > > > > Category A
> > > > > > > > > and
> > > > > > > > > > > > > > Category
> > > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > > >> > > > As Category A and Category B are both
> > streams
> > > > that
> > > > > > > > have
> > > > > > > > > > been
> > > > > > > > > > > > > > really
> > > > > > > > > > > > > > >> > > > active, I see this as a blocker, as
> there
> > are
> > > > > > > > > > contributions
> > > > > > > > > > > > that
> > > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> > depends
> > > > on
> > > > > > > > > Category
> > > > > > > > > > B
> > > > > > > > > > > > > with a
> > > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > > understood
> > > > > > as
> > > > > > > > > > > technical
> > > > > > > > > > > > > > debt.
> > > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > > something
> > > > > > > we'll
> > > > > > > > > > always
> > > > > > > > > > > > be
> > > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> > just a
> > > > > > matter
> > > > > > > of
> > > > > > > > > > > making
> > > > > > > > > > > > > them
> > > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> > impact
> > > > the
> > > > > > > > > structure
> > > > > > > > > > or
> > > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > > >> > > > that we're talking about here, but it
> is a
> > > > > > > regression
> > > > > > > > we
> > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> > Apache
> > > > KIE
> > > > > > 10,
> > > > > > > > and
> > > > > > > > > > > that
> > > > > > > > > > > > > P5,
> > > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only
> problems
> > > > left to
> > > > > > > > > discuss
> > > > > > > > > > > are
> > > > > > > > > > > > P1
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > > > proposal.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I'll try to be very meticulous here,
> since
> > > > from my
> > > > > > > > > > > experience,
> > > > > > > > > > > > > any
> > > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> > release
> > > > not
> > > > > > > > > working
> > > > > > > > > > > out
> > > > > > > > > > > > in
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > > possible,
> > > > > > and
> > > > > > > > make
> > > > > > > > > > > > > > everything
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > > release,
> > > > > > bear
> > > > > > > > > with
> > > > > > > > > > > me.
> > > > > > > > > > > > > I'll
> > > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > > >> > > > out a timeline of events that need to
> > happen
> > > > in
> > > > > > > order
> > > > > > > > > for
> > > > > > > > > > > our
> > > > > > > > > > > > > > >> release
> > > > > > > > > > > > > > >> > > > to be published, with all artifacts
> > ending up
> > > > in
> > > > > > the
> > > > > > > > > right
> > > > > > > > > > > > > places,
> > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > >> > > > first, we need to solve problems P1 and
> > P2.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As you saw at the beginning of this
> email,
> > > > all the
> > > > > > > > > > attempts
> > > > > > > > > > > we
> > > > > > > > > > > > > > made
> > > > > > > > > > > > > > >> > > > left us with the circular dependency
> > showing
> > > > up
> > > > > > at a
> > > > > > > > > > > different
> > > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > > >> > > > but something all these places have in
> > common
> > > > is
> > > > > > > that
> > > > > > > > > > > they're
> > > > > > > > > > > > > all
> > > > > > > > > > > > > > >> > > > after kogito-apps, and before to
> Category
> > B.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > > following:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > S1. We keep the original plan of moving
> > the
> > > > > > Quarkus
> > > > > > > > Dev
> > > > > > > > > > UIs
> > > > > > > > > > > > from
> > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> > with
> > > > > > > Management
> > > > > > > > > and
> > > > > > > > > > > > Task
> > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> > `kie-tools`.
> > > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > images
> > > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > > `kogito-serverless-operator`
> > > > > > > > repo
> > > > > > > > > > > > inside
> > > > > > > > > > > > > a
> > > > > > > > > > > > > > >> new
> > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> > history.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> > > > problems
> > > > > > P1
> > > > > > > > and
> > > > > > > > > > P2.
> > > > > > > > > > > Of
> > > > > > > > > > > > > > >> course
> > > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > > >>
> > > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > This doesn't come without consequences,
> of
> > > > course,
> > > > > > > as
> > > > > > > > > the
> > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> > `kogito-swf-builder`
> > > > > > > images,
> > > > > > > > > and
> > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be
> > moving
> > > > from
> > > > > > > > > > Category A
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > Category B. This move would make them
> > have to
> > > > > > > > reference
> > > > > > > > > > > > > Category A
> > > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs.
> Since
> > > > > > > > > `kogito-images`
> > > > > > > > > > > and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are already
> > > > their own
> > > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > > >> > > > Category A, though, contributions made
> in
> > a
> > > > > > > cross-repo
> > > > > > > > > > > fashion
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> this
> > > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> > possible, now
> > > > > > via a
> > > > > > > > > > single
> > > > > > > > > > > PR
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> > Category
> > > > A and
> > > > > > > > > > Category
> > > > > > > > > > > B
> > > > > > > > > > > > > will
> > > > > > > > > > > > > > >> > > > continue not being possible, and a
> 1-week
> > > > delay
> > > > > > > > between
> > > > > > > > > > > > merging
> > > > > > > > > > > > > > >> > > > something on Category A and using it on
> > > > Category B
> > > > > > > > will
> > > > > > > > > > > still
> > > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> > > > however,
> > > > > > > does
> > > > > > > > > > allow
> > > > > > > > > > > > for
> > > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > > >> > > > checkouts and partial builds, so working
> > with
> > > > a
> > > > > > > subset
> > > > > > > > > of
> > > > > > > > > > > the
> > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > >> > > > is possible and encouraged. Making
> changes
> > > > only to
> > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> > example,
> > > > will
> > > > > > > have
> > > > > > > > > the
> > > > > > > > > > PR
> > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see
> here:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > > >> > > > We're not compromising when running
> > partial
> > > > builds
> > > > > > > > too.
> > > > > > > > > We
> > > > > > > > > > > > know
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > >> > > > the entire repo will continue working
> even
> > > > after
> > > > > > > only
> > > > > > > > > > > > building a
> > > > > > > > > > > > > > >> small
> > > > > > > > > > > > > > >> > > > subset of the changes. Doing partial or
> > full
> > > > > > builds
> > > > > > > is
> > > > > > > > > > > > > > automatically
> > > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> > proposing
> > > > we
> > > > > > > move a
> > > > > > > > > > bunch
> > > > > > > > > > > > of
> > > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see
> > this
> > > > as a
> > > > > > > > > > TEMPORARY
> > > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host
> > some
> > > > > > > > additional
> > > > > > > > > > > stuff
> > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > > continue
> > > > > > > moving
> > > > > > > > > > > > forward.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > As I mentioned on other places,
> > `kie-tools`
> > > > > > became a
> > > > > > > > > > > polyglot
> > > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > > >> > > > out of necessity, and although I'm
> really
> > > > proud of
> > > > > > > > what
> > > > > > > > > we
> > > > > > > > > > > > > > achieved
> > > > > > > > > > > > > > >> > > > there so far, I don't think `kie-tools`
> > has a
> > > > > > setup
> > > > > > > > that
> > > > > > > > > > is
> > > > > > > > > > > > > > suitable
> > > > > > > > > > > > > > >> > > > for all the different nuances that
> > compose our
> > > > > > > > > community.
> > > > > > > > > > > I'm
> > > > > > > > > > > > > well
> > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that does
> > not
> > > > > > follow
> > > > > > > > > > > widespread
> > > > > > > > > > > > > > >> > > > conventions will scare some people away,
> > and
> > > > as
> > > > > > much
> > > > > > > > as
> > > > > > > > > > > we've
> > > > > > > > > > > > > > tried
> > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > >> > > > make build instructions clear, we can't
> > > > always get
> > > > > > > > past
> > > > > > > > > > the
> > > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > > > > ecosystem.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > With all that said, I keep thinking this
> > is
> > > > the
> > > > > > best
> > > > > > > > > > course
> > > > > > > > > > > of
> > > > > > > > > > > > > > >> action
> > > > > > > > > > > > > > >> > > > for us right now. We keep most of our
> > stuff
> > > > > > > unchanged,
> > > > > > > > > we
> > > > > > > > > > > > > unblock
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> > > > release, and we have a working setup
> that
> > will
> > > > > > suit
> > > > > > > us
> > > > > > > > > > well
> > > > > > > > > > > > > while
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > >> > > > discuss and reach a conclusion regarding
> > the
> > > > > > future
> > > > > > > of
> > > > > > > > > our
> > > > > > > > > > > > > > codebase
> > > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Let me paint a quick picture here of
> what
> > our
> > > > code
> > > > > > > > base
> > > > > > > > > > > would
> > > > > > > > > > > > > look
> > > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > > > accepted:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-pipelines
> > > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > > >> > > > A
> > > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-runtimes
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-examples
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > > >> > > > A
> > incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > B
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > D
> incubator-kie-kogito-operator
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > > > > >> > > > E
> > > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > * Category C becomes part of Category A,
> > and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> > entirely
> > > > inside
> > > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> > images
> > > > and
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > > `kie-tools`,
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > > no
> > > > > > > > > > > > > > cycles
> > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > > granularly
> > > > > > > > build:
> > > > > > > > > > > > > > >> > > > 1.
> > packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> > (containing
> > > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> > (contents
> > > > from
> > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > The second part of the proposal is the
> > release
> > > > > > > process
> > > > > > > > > > > itself,
> > > > > > > > > > > > > > >> > > > assuming the structure above is what we
> > have.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be
> > used as
> > > > > > > cutting
> > > > > > > > > > point
> > > > > > > > > > > > for
> > > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to
> > this
> > > > > > > > timestamped
> > > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > > >> > > > 3. At this point, with everything
> > working, we
> > > > can
> > > > > > > > branch
> > > > > > > > > > out
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the
> timestamped
> > > > SNAPSHOT
> > > > > > > > tag,
> > > > > > > > > > and
> > > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> > update
> > > > > > their
> > > > > > > > > > versions
> > > > > > > > > > > > to
> > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > > Category A
> > > > > > > > repos
> > > > > > > > > > > using
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the
> > release
> > > > based
> > > > > > > on
> > > > > > > > > the
> > > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > > >> > > > branches, given we don't expect any code
> > > > changes
> > > > > > > > > anymore.
> > > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to
> > start
> > > > the
> > > > > > > > release
> > > > > > > > > > > > process.
> > > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > > manual/automated
> > > > > > > > > release
> > > > > > > > > > > > > process,
> > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > pushed
> > > > to
> > > > > > Git,
> > > > > > > > and
> > > > > > > > > > > built
> > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > > artifacts
> > > > > > to
> > > > > > > be
> > > > > > > > > > > > > propagated
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > > manual/automated
> > > > > > > > > release
> > > > > > > > > > > > > > process,
> > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> > pushed
> > > > to
> > > > > > Git,
> > > > > > > > and
> > > > > > > > > > > built
> > > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > > >> > > > 12. Category E repos can be manually
> > tagged
> > > > with
> > > > > > > > 10.0.0
> > > > > > > > > > from
> > > > > > > > > > > > > their
> > > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > More needs to be discussed if we're
> > planning
> > > > to
> > > > > > > > maintain
> > > > > > > > > > > > > multiple
> > > > > > > > > > > > > > >> > > > release streams in parallel, but I guess
> > it
> > > > can
> > > > > > wait
> > > > > > > > for
> > > > > > > > > > > after
> > > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> > > > forward to
> > > > > > > > > hearing
> > > > > > > > > > > back
> > > > > > > > > > > > > > from
> > > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Of course, alternative solutions are
> > possible.
> > > > > > This
> > > > > > > > > email,
> > > > > > > > > > > > > > however,
> > > > > > > > > > > > > > >> > > > summarizes my view of how we should
> > attack the
> > > > > > > > problem,
> > > > > > > > > > > > > > considering
> > > > > > > > > > > > > > >> > > > disruption, required effort, the release
> > > > process
> > > > > > > > itself,
> > > > > > > > > > and
> > > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > > >> > > > Feel free to propose alternatives. This
> is
> > > > not a
> > > > > > > > voting
> > > > > > > > > > > > thread.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
1) Ok, if that is the case, I do not get why your first proposal was not
the one I'm proposing and it is apparently not detailed enough. To move
kn-workflow from tooling to operator one and change the order in which the
repos are being processed. Basically, the problem of the proposed solution
is that it kind of converts tooling repo into a pretty heterodox repo
compared with runtimes, drools or operator one. Also once tooling is not a
final repo in the overall chain, we can consider moving examples as the
final one and include tooling showcases there (rather than splitting
examples into examples with tooling and examples without tooling).
2) I think this distinction between A and B is one between several possible
categorizations (not much, including no categorization at all) that
deserves a separate discussion. I will open a separate thread for that
purpose, since we are not going to change that now and it is not really
part of the proposal.
On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento <ti...@gmail.com>
wrote:
> Francisco,
>
> 1) That's what this thread is all about... You know I don't think it's
> ok. That's why I'm proposing the two images and the operator to move
> into the `kie-tools` repo, where we can more granularly control the
> order things are built, thus removing the dependency cycle.
>
> 2) Not sure we understand the same thing by "freeze". My proposal is
> that we select a timestamped SNAPSHOT version from Category A repos to
> use as base for a release. We give Category B repos some time to
> adjust, and then cut the release branches. This can happen anytime,
> and no contributions would ever stop because of it. The development
> branches can continue accepting PRs normally, even during the release
> process. Now, if what you're asking is why Category B repos refer to
> Category A repos via timestamped SNAPSHOTs, the answer is in my first
> email. See the paragraph starting with "An important note here is that
> Category B repositories...".
>
> On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti
> <ft...@redhat.com> wrote:
> >
> > Tiago
> > There are a couple of simple and straightforward questions that I
> > formulated, but since we both write a lot, it might have been lost.
> Please
> > let me ask them again.
> > 1) Do you think it is ok that tools repo is executed after generation of
> > docker images that are supposed to include those tools or the operator
> that
> > is supposed to deploy such images?
> That's what this thread is all about... You know I'm not ok with it,
> that's why I'm proposing the two images and the operator to move into
> the `kie-tools` repo, where we can more granularly control the order
> things are built and remove the dependency cycle.
> > 2) Besides that, although not directly related with the current proposal
> we
> > are discussing, I really think there are some restrictions taken for
> > granted that are arbitrary and difficult to sustain on strictly technical
> > arguments. For example, the need to freeze the rest of the software
> before
> > tools are generated. Why? We have dependencies between repos that are not
> > handled that way: Apps depend on runtimes. Runtimes depend on drools,
> > Operator depend on runtimes,....and we are not freezing that repos since
> we
> > are all releasing at the same time. If we are all releasing at the same
> > time, what's the rationale behind the freeze?
> >
> >
> >
> > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <ti...@apache.org>
> wrote:
> >
> > > Glad to see the interest this proposal has gotten, and it's good to
> > > see some alternatives being drafted here, although still lacking clear
> > > definitions and analysis in regards to disruption, required effort,
> > > the release process itself, and history. Of course, lots of details
> > > and clarity on the execution part would be missing too.
> > >
> > > As of this moment, based on what I read here, I'm assuming that
> > > everyone who participated so far doesn't see the initial proposal as
> > > problematic in terms of feasibility, but some of you have a preference
> > > not to go with it, because it is "wrong", and apparently because it
> > > would "jeopardize the evolution of the project". Reading these last
> > > words made me a little sad, to be honest. But I can deal with it :)
> > >
> > > Please let's try and keep the discussion as objective as possible.
> > > "Right" and "wrong" are too subjective for this kind of conversation.
> > >
> > > Now, being practical, unless there are clear arguments based on facts
> > > and objective concepts that invalidate the initial proposal shared on
> > > this email, it seems to me that it is currently the only viable
> > > proposal we have for unblocking and releasing Apache KIE 10. Of
> > > course, if we end up seeing an alternative proposal with enough
> > > details and a clear execution plan, I think then we'll be in a very
> > > good position to choose from multiple options!
> > >
> > >
> > > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <al...@porcelli.me>
> wrote:
> > > >
> > > > Francisco and Gabriele,
> > > >
> > > > I understand and acknowledge your desire to find the “right” solution
> > > > instead to work on a temporary “patch” - however without a detailed
> > > > proposal I don’t think we can properly evaluate the impact of your
> > > > suggestion.
> > > >
> > > > When I spoke with different SMEs that included tools and CI, the
> > > > guesstimate for making the necessary changes on CI and codebase to
> > > > basically have images and operators in the end of the build chain is
> > > > something like 2 months of effort. Another impact that needs to be
> > > > discussed is that KIE Tools repo had to be injected in the middle of
> all
> > > > pipelines - forcing all PR checks and nightlies to build all repos
> (PR
> > > > checks will likely take 12+ hours… I even heard that it could be
> even 24
> > > > hours).
> > > >
> > > > Based on the input above, I think it’s quite risk to move in such
> > > direction
> > > > without a more detailed plan… because 2 months could be turned
> easily in
> > > 6!
> > > > And this is exactly what happened when we guessed that moving to
> Apache
> > > > would take no more than 3 months. But here we are.
> > > >
> > > > I really strongly suggest that we focus on a release that could be
> > > > achievable in less than a month from now, and we - after release -
> have a
> > > > in depth discussion about the overall codebase and ci organization.
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > > gabriele.cardosi@gmail.com>
> > > > wrote:
> > > >
> > > > > Alex,
> > > > > my suggestion is to move the building of all docker images, from
> > > whatever
> > > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to
> be
> > > > > invoked after all the others.
> > > > > I'm not sure if this would solve all the issues, and since I could
> not
> > > > > enter in the details of all the involved code, my suggestion may
> be too
> > > > > naive.
> > > > > Having spent almost all of the last year in CI, I may say that, at
> > > least
> > > > > for the kie-tools repo, removing the image build step from it
> should
> > > not be
> > > > > too difficult (since it is an issue we already faced and solved).
> > > > > If, with "detailed proposal", you mean a complete list of all
> modules
> > > to be
> > > > > moved and dependency refactoring, of course I can not provide it
> right
> > > now.
> > > > >
> > > > > Anyway, I share the concern from Francisco: undoing something is
> almost
> > > > > always harder than doing it "rightly" from scratch...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado
> Sarti
> > > <
> > > > > ftirados@redhat.com> ha scritto:
> > > > >
> > > > > > I do not think estimations should be the only driver to make a
> > > decision,
> > > > > > especially when the current proposal is conceptually incompatible
> > > with
> > > > > the
> > > > > > multi repo approach that is taken elsewhere in the project.
> > > > > > Given my knowledge of the CI it is nearly impossible for me to
> give
> > > a
> > > > > fair
> > > > > > estimate of how much it might take to achieve step 2) of my
> previous
> > > > > e-mail
> > > > > > . It might take a while or it might be pretty easy after all, I
> don't
> > > > > > really know, but I think it will be a good idea if some of the
> > > experts
> > > > > on
> > > > > > CI in the team (the ones that set up the pipeline, which was a
> huge
> > > > > > achievement) give an estimate, not me. Estimating how much it
> takes
> > > to
> > > > > > merge two existing repos (without altering CI) is easier, but it
> > > does not
> > > > > > mean we are doing the right thing.
> > > > > > My main concern is that it will be very difficult for me to
> explain
> > > to
> > > > > > someone that arrives new to the team, that having experts on CI
> on
> > > the
> > > > > > team, we decided to merge two repos (once merged, it would be
> rather
> > > > > > difficult to unmerge) rather than fix the CI, because of
> expediency.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <
> porcelli@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Francisco,
> > > > > > >
> > > > > > > Please take the time to make the more in depth analysis needed
> and
> > > > > > provide
> > > > > > > a more detailed plan… so we - as community- can evaluate the
> size
> > > of
> > > > > the
> > > > > > > effort. In the conceptual level you shared it’s near
> impossible to
> > > > > > estimate
> > > > > > > the size of the effort and compare with the current proposal.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > > > ftirados@redhat.com> wrote:
> > > > > > >
> > > > > > > > I think I already did a high level proposal.
> > > > > > > > 1) Remove all dependencies from tooling to images, so images
> > > depend
> > > > > on
> > > > > > > > tooling but tooling does not depend on images.
> > > > > > > > 2) Then change CI to deal with tooling repo before dealing
> with
> > > > > images
> > > > > > > > repo.
> > > > > > > > I understand that CI details are tricky and since I'm not
> > > familiar
> > > > > with
> > > > > > > CI
> > > > > > > > in any way, I barely can make a low level design, but we do
> not
> > > need
> > > > > to
> > > > > > > fix
> > > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <
> alex@porcelli.me
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco and Grabriele,
> > > > > > > > >
> > > > > > > > > You may not like or understand why the current state of
> the CI
> > > is
> > > > > > like
> > > > > > > > > that… actually has been in Red Hat and has been replicated
> in
> > > > > Apache
> > > > > > as
> > > > > > > > > used to be….
> > > > > > > > >
> > > > > > > > > But the fact is that this is the current reality.
> > > > > > > > >
> > > > > > > > > If you disagree with the current plan, please provide a
> > > detailed
> > > > > > > > > alternative so we, as community, can better evaluate the
> pros
> > > and
> > > > > > cons
> > > > > > > of
> > > > > > > > > each proposal.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think it’s also fair to say that, post 10 release we
> need to
> > > > > have a
> > > > > > > > much
> > > > > > > > > in depth discussion about how our codebase is organized,
> it’s
> > > clear
> > > > > > > that
> > > > > > > > > it’s not working.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > As Francisco said,
> > > > > > > > > > I also have the impression that the "images" (if we are
> > > talking
> > > > > of
> > > > > > > > docker
> > > > > > > > > > images) should be the very last one to be built, in a
> > > standalone
> > > > > > > repo.
> > > > > > > > > > That way, they may "combine" artifacts that are built in
> > > > > different
> > > > > > > > repos,
> > > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> > > maybe
> > > > > > could
> > > > > > > > > > simplify the situation a bit.
> > > > > > > > > > (I also think there are some statements of undisputable
> needs
> > > > > while
> > > > > > > > they
> > > > > > > > > > are, actually, just technical choices.
> > > > > > > > > > Anyway, this latter point is for longer, following,
> > > discussion.)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > > Tirado
> > > > > > > Sarti
> > > > > > > > <
> > > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > > >
> > > > > > > > > > > Alex,
> > > > > > > > > > > There are two assumptions that deserve further
> discussion:
> > > > > > > > > > > 1) That tool has to be the last to build. why? it does
> not
> > > have
> > > > > > > more
> > > > > > > > > > sense
> > > > > > > > > > > to build final images after everything else has been
> > > built?-
> > > > > > > > > > > 2) That the impact (in terms of effort now) on fixing
> CI is
> > > > > > bigger
> > > > > > > > than
> > > > > > > > > > the
> > > > > > > > > > > impact (long term consequences) of consolidating two
> > > unrelated
> > > > > > > piece
> > > > > > > > of
> > > > > > > > > > > software within the same repository.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > > alex@porcelli.me
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Francisco,
> > > > > > > > > > > >
> > > > > > > > > > > > This was discussed as an alternative solution,
> however
> > > it has
> > > > > > > major
> > > > > > > > > > > impact
> > > > > > > > > > > > on CI and there’s also the fact Tool has been always
> the
> > > last
> > > > > > to
> > > > > > > > > build
> > > > > > > > > > > and
> > > > > > > > > > > > has no Snapshot published (actually in JavaScript
> world
> > > there
> > > > > > is
> > > > > > > no
> > > > > > > > > > > > snapshot concept).
> > > > > > > > > > > >
> > > > > > > > > > > > So, based on our evaluation… the proposal here is the
> > > least
> > > > > > > > > disruptive
> > > > > > > > > > > and
> > > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > _____________
> > > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > > http://porcelli.me
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier
> Tirado
> > > > > Sarti <
> > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > After kie-tools, sorry. I think we are not
> embracing
> > > the
> > > > > fact
> > > > > > > > that
> > > > > > > > > > > > > kogito-images depend on kie-tools, because we want
> > > those
> > > > > > images
> > > > > > > > to
> > > > > > > > > > > > include
> > > > > > > > > > > > > tools.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > > Tirado
> > > > > > Sarti
> > > > > > > <
> > > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > > It can be an alternative solution to move
> > > > > > kn-plugin-workflow
> > > > > > > to
> > > > > > > > > > > > > > kogito-images (so there is not longer dependency
> from
> > > > > tools
> > > > > > > to
> > > > > > > > > > > images)
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > > > Martinez
> > > > > > <
> > > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez
> (apache)
> > > <
> > > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > > > alex@porcelli.me
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > I spent the last day or so working closely
> with
> > > > > Tiago,
> > > > > > > > > > exploring
> > > > > > > > > > > > > >> > different
> > > > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > > > evaluating
> > > > > > > > the
> > > > > > > > > > > > overall
> > > > > > > > > > > > > >> > release
> > > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > > proposal
> > > > > as
> > > > > > > the
> > > > > > > > > > most
> > > > > > > > > > > > > >> > > viable option for unblocking the 10 release
> in
> > > the
> > > > > > > > > reasonable
> > > > > > > > > > > time
> > > > > > > > > > > > > >> frame.
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento
> <
> > > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this
> time,
> > > as
> > > > > this
> > > > > > > > > matter
> > > > > > > > > > > > > >> requires a
> > > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This email will take you < 20 minutes to
> read,
> > > > > > > according
> > > > > > > > > to
> > > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As you may have followed on a separate
> thread
> > > > > > > > > > > > > >> > > > (
> > > > > > > > > > > >
> > > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > > ),
> > > > > > > > > > > > > >> > > > many of us were working towards removing a
> > > > > circular
> > > > > > > > > > dependency
> > > > > > > > > > > > > >> > > > currently present between `kogito-apps`
> and
> > > > > > > `kie-tools`.
> > > > > > > > > As
> > > > > > > > > > we
> > > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > > finding the
> > > > > > > > > circular
> > > > > > > > > > > > > >> dependency
> > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a
> breakdown of
> > > the
> > > > > > > things
> > > > > > > > > we
> > > > > > > > > > > did,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Right now, even though we started the
> effort
> > > to
> > > > > move
> > > > > > > the
> > > > > > > > > > > Quarkus
> > > > > > > > > > > > > Dev
> > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> > > able to
> > > > > > do
> > > > > > > it
> > > > > > > > > > yet,
> > > > > > > > > > > as
> > > > > > > > > > > > > >> we've
> > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> > > Maven
> > > > > > 3.9.6,
> > > > > > > > and
> > > > > > > > > > > > Quarkus
> > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > > This
> > > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > > >> > > >
> > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > > .
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > C | 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > Y | 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > > >> > > > * and
> > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > > depend
> > > > > > > > > > > > > >> on
> > > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > > `kie-tools`,
> > > > > we
> > > > > > > > > would've
> > > > > > > > > > > > had:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > C |==> 04.
> incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As
> `kie-tools`/kn-plugin-workflow
> > > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > > >> > > > * and
> > > `kogito-images`/kogito-swf-devmode
> > > > > > > depends
> > > > > > > > > on
> > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode`
> image to
> > > > > > > > > `kie-tools`,
> > > > > > > > > > we
> > > > > > > > > > > > > >> would've
> > > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 01.
> > > incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > 02.
> incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > 03.
> > > incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > 04.
> > > incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * As
> `kie-tools`/kn-plugin-workflow
> > > > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > > depends
> > > > > > on
> > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem
> than a
> > > > > simple
> > > > > > > > > > circular
> > > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > > people,
> > > > > > > it's
> > > > > > > > > been
> > > > > > > > > > > > > really
> > > > > > > > > > > > > >> > > > hard coming up with a simple solution that
> > > makes
> > > > > it
> > > > > > > > > possible
> > > > > > > > > > > to
> > > > > > > > > > > > > >> build
> > > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving
> the
> > > way
> > > > > > > > everyone
> > > > > > > > > is
> > > > > > > > > > > > used
> > > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > contributing to the multiple repositories
> we
> > > have.
> > > > > > > More
> > > > > > > > > than
> > > > > > > > > > > > that,
> > > > > > > > > > > > > >> > > > while making this assessment, I found more
> > > > > problems
> > > > > > > > that,
> > > > > > > > > in
> > > > > > > > > > > my
> > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > > forward
> > > > > with
> > > > > > > my
> > > > > > > > > > > proposal
> > > > > > > > > > > > > for
> > > > > > > > > > > > > >> > > > the Apache KIE release process, so we can
> use
> > > > > > Apache's
> > > > > > > > > > > > mechanisms
> > > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> > > this
> > > > > > really
> > > > > > > > > > > > complicated
> > > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I'll lay out my entire perspective about
> the
> > > > > current
> > > > > > > > > > situation
> > > > > > > > > > > > of
> > > > > > > > > > > > > >> our
> > > > > > > > > > > > > >> > > > codebase, as well as problems I can
> currently
> > > see.
> > > > > > > I'll
> > > > > > > > > > start
> > > > > > > > > > > > with
> > > > > > > > > > > > > >> an
> > > > > > > > > > > > > >> > > > analysis of the repositories and their
> > > purposes,
> > > > > > point
> > > > > > > > out
> > > > > > > > > > > some
> > > > > > > > > > > > > >> > > > problems that I believe are blocking our
> 10
> > > > > release,
> > > > > > > > > explain
> > > > > > > > > > > my
> > > > > > > > > > > > > >> > > > proposal and discuss some consequences to
> > > what I'm
> > > > > > > > > > proposing.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count:
> 11)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> > > `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > > >> > > > -
> incubator-kie-kogito-serverless-operator @
> > > > > `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > > >> > > > -
> incubator-kie-sandbox-quarkus-accelerator @
> > > > > > `0.0.0`
> > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > > >> > > > (Issues only, README should be
> updated @
> > > > > `main`.
> > > > > > > > Same
> > > > > > > > > > for
> > > > > > > > > > > > > GitHub
> > > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy
> at
> > > the
> > > > > > > `main`
> > > > > > > > > > > branch.)
> > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`.
> Push @
> > > > > > > `deploy`
> > > > > > > > to
> > > > > > > > > > > > update
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > > > >> > > > (GitHub pages used to host
> > > sandbox.kie.org
> > > > > and
> > > > > > > KIE
> > > > > > > > > > Tools'
> > > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @
> `main`
> > > > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> > > checks
> > > > > > > during
> > > > > > > > > the
> > > > > > > > > > > > > staging
> > > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I grouped the repositories by category,
> and
> > > listed
> > > > > > > them
> > > > > > > > > in a
> > > > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > > > flattening
> > > > > > > > out a
> > > > > > > > > > > tree,
> > > > > > > > > > > > > >> there
> > > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > > OptaPlanner
> > > > > > > > > > could've
> > > > > > > > > > > > been
> > > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category A repos are what I've been
> referring
> > > to
> > > > > as
> > > > > > > > > `drools`
> > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner
> is
> > > inside
> > > > > > > that
> > > > > > > > > > > stream,
> > > > > > > > > > > > as
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > way these repositories reference each
> other
> > > are
> > > > > > > through
> > > > > > > > > > Maven
> > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the
> 999-SNAPSHOT
> > > > > > > version.
> > > > > > > > > This
> > > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > > >> > > > is well-known to the team, and although
> > > flawed for
> > > > > > > > > intra-day
> > > > > > > > > > > > > builds
> > > > > > > > > > > > > >> > > > and disruptive for people in many
> different
> > > time
> > > > > > > zones,
> > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > > > > >> already
> > > > > > > > > > > > > >> > > > very comfortable for everyone to work
> with, I
> > > > > > assume.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > > > dedicated
> > > > > > > > > > > pipelines,
> > > > > > > > > > > > > >> which
> > > > > > > > > > > > > >> > > > are, at least to some extent, able to
> build
> > > > > > cross-repo
> > > > > > > > PRs
> > > > > > > > > > > > > together
> > > > > > > > > > > > > >> > > > and verify that the codebase will continue
> > > working
> > > > > > as
> > > > > > > > > > expected
> > > > > > > > > > > > > after
> > > > > > > > > > > > > >> > > > they're all merged. From what I could
> gather,
> > > > > there
> > > > > > > are
> > > > > > > > > some
> > > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > > cross-repo
> > > > > > PRs.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps,
> and
> > > > > > > > > kogito-examples
> > > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > > > >> > > > - kogito-images, and
> > > kogito-serverless-operator
> > > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to
> any
> > > > > > > > combination
> > > > > > > > > of
> > > > > > > > > > > > repos
> > > > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > > cannot
> > > > > be
> > > > > > > > > > verified
> > > > > > > > > > > > > before
> > > > > > > > > > > > > >> > > > merging, making our contribution model
> > > dependent
> > > > > on
> > > > > > > > > > individual
> > > > > > > > > > > > > >> > > > contributors building stuff on their
> machines
> > > to
> > > > > > > verify
> > > > > > > > > that
> > > > > > > > > > > it
> > > > > > > > > > > > > >> works.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > > > pipelines,
> > > > > > > so
> > > > > > > > > > > please
> > > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category B repos are what I've been
> referring
> > > to
> > > > > as
> > > > > > > > > > > `kie-tools`
> > > > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > > > repository
> > > > > > > > that
> > > > > > > > > > is
> > > > > > > > > > > > used
> > > > > > > > > > > > > >> by
> > > > > > > > > > > > > >> > > > people starting projects from scratch on
> KIE
> > > > > > Sandbox,
> > > > > > > > > > similar
> > > > > > > > > > > > to a
> > > > > > > > > > > > > >> > > > Maven archetype, if you will. The other
> one
> > > is the
> > > > > > KIE
> > > > > > > > > Tools
> > > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its
> build
> > > > > system.
> > > > > > > > > > > Currently,
> > > > > > > > > > > > > KIE
> > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > > TypeScript
> > > > > > > > libraries
> > > > > > > > > > and
> > > > > > > > > > > > > apps,
> > > > > > > > > > > > > >> Go
> > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > > > `kie-tools`
> > > > > > > > > > monorepo
> > > > > > > > > > > > is
> > > > > > > > > > > > > >> > > > configured to work with sparse checkouts
> and
> > > can
> > > > > do
> > > > > > > > > partial
> > > > > > > > > > > > > builds.
> > > > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > > through
> > > > > > > > > > timestamped
> > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we
> recently
> > > > > > > > introduced
> > > > > > > > > > that
> > > > > > > > > > > > > will
> > > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > > artifacts
> > > > > > > under
> > > > > > > > a
> > > > > > > > > > > > version
> > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT
> format,
> > > > > > published
> > > > > > > > > weekly
> > > > > > > > > > > > every
> > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > > > evolution
> > > > > > > to
> > > > > > > > > the
> > > > > > > > > > > > Kogito
> > > > > > > > > > > > > >> > > > releases, as we're now targeting one
> release
> > > for
> > > > > all
> > > > > > > of
> > > > > > > > > > Apache
> > > > > > > > > > > > > KIE,
> > > > > > > > > > > > > >> so
> > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > An important note here is that Category B
> > > > > > repositories
> > > > > > > > > have
> > > > > > > > > > > been
> > > > > > > > > > > > > >> > > > historically kept out of any automations
> we
> > > used
> > > > > to
> > > > > > > > have,
> > > > > > > > > > way
> > > > > > > > > > > > back
> > > > > > > > > > > > > >> > > > when Kogito started and we had the
> Business
> > > > > Central
> > > > > > > > > (a.k.a.
> > > > > > > > > > > v7)
> > > > > > > > > > > > > >> stream
> > > > > > > > > > > > > >> > > > still going on. For this reason, Category
> B
> > > > > projects
> > > > > > > > have
> > > > > > > > > > > > > developed
> > > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > > Actions.
> > > > > > > > Category B
> > > > > > > > > > > repos
> > > > > > > > > > > > > >> have
> > > > > > > > > > > > > >> > > > always depended on Category A repos using
> > > fixed
> > > > > > > > versions.
> > > > > > > > > If
> > > > > > > > > > > > > >> Category
> > > > > > > > > > > > > >> > > > B repos have had adopted mutable
> SNAPSHOTs,
> > > > > breaking
> > > > > > > > > changes
> > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > Category A repositories would've had the
> > > potential
> > > > > > to
> > > > > > > > > break
> > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > > > development
> > > > > > > > > > stream,
> > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > > maintainers
> > > > > of
> > > > > > > > > > Category B
> > > > > > > > > > > > > >> repos,
> > > > > > > > > > > > > >> > > > as historically Category A contributors
> were
> > > not
> > > > > > > > familiar
> > > > > > > > > > with
> > > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > > through
> > > > > a
> > > > > > > > GitHub
> > > > > > > > > > > > Actions
> > > > > > > > > > > > > >> > > > workflow that builds the relevant part of
> the
> > > > > > > > `kie-tools`
> > > > > > > > > > > > monorepo
> > > > > > > > > > > > > >> for
> > > > > > > > > > > > > >> > > > the changes introduced. Changes made to
> the
> > > > > pipeline
> > > > > > > > > itself
> > > > > > > > > > > are
> > > > > > > > > > > > > also
> > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to
> do
> > > things
> > > > > > > like
> > > > > > > > > > > > atomically
> > > > > > > > > > > > > >> > > > bumping the Node.js version, for example.
> More
> > > > > > > > > importantly,
> > > > > > > > > > it
> > > > > > > > > > > > > >> allows
> > > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > > timestamped
> > > > > > > > SNAPSHOT
> > > > > > > > > > > > > together
> > > > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > > green.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This setup, however, makes it impossible
> to
> > > have
> > > > > > > > > cross-repo
> > > > > > > > > > > PRs
> > > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > > simultaneously,
> > > > > > > with
> > > > > > > > > the
> > > > > > > > > > > > > current
> > > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category C repos are kind of floating
> around,
> > > and
> > > > > > I'm
> > > > > > > > not
> > > > > > > > > > sure
> > > > > > > > > > > > if
> > > > > > > > > > > > > >> > > > there's much activity going on there.
> > > Regardless,
> > > > > as
> > > > > > > > > they're
> > > > > > > > > > > > part
> > > > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our
> release,
> > > so I
> > > > > > > > listed
> > > > > > > > > > them
> > > > > > > > > > > > for
> > > > > > > > > > > > > >> us
> > > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category D is self explanatory. There's
> only
> > > one
> > > > > > repo
> > > > > > > > that
> > > > > > > > > > has
> > > > > > > > > > > > > >> already
> > > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > > > directly,
> > > > > > > and
> > > > > > > > > are
> > > > > > > > > > > > > either
> > > > > > > > > > > > > >> > > > organizational entities, or host websites,
> > > that
> > > > > > > > currently
> > > > > > > > > > are
> > > > > > > > > > > > not
> > > > > > > > > > > > > >> part
> > > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This lack of unification between Category
> A
> > > and
> > > > > > > > Category B
> > > > > > > > > > is,
> > > > > > > > > > > > > IMHO,
> > > > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > > circular
> > > > > > > > > > dependency
> > > > > > > > > > > > > >> between
> > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we
> now
> > > can
> > > > > > > describe
> > > > > > > > > as
> > > > > > > > > > a
> > > > > > > > > > > > > >> circular
> > > > > > > > > > > > > >> > > > dependency between Category A and
> Category B.
> > > The
> > > > > > way
> > > > > > > I
> > > > > > > > > see
> > > > > > > > > > > it,
> > > > > > > > > > > > if
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > had a single pipeline, building everything
> > > from
> > > > > > > `drools`
> > > > > > > > > to
> > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never
> been
> > > > > > > introduced,
> > > > > > > > > and
> > > > > > > > > > we
> > > > > > > > > > > > > >> > > > wouldn't be having this huge problem in
> our
> > > hands
> > > > > > > right
> > > > > > > > > now.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release
> process
> > > > > sees
> > > > > > > this
> > > > > > > > > > lack
> > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > unification as a central problem, not
> only for
> > > > > this
> > > > > > > > > release
> > > > > > > > > > in
> > > > > > > > > > > > > >> > > > particular, but for the community as a
> whole.
> > > It
> > > > > is
> > > > > > my
> > > > > > > > > > belief
> > > > > > > > > > > > that
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > > contribution
> > > > > > > > > should
> > > > > > > > > > > be
> > > > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> > > With
> > > > > the
> > > > > > > > > > increasing
> > > > > > > > > > > > > >> volume
> > > > > > > > > > > > > >> > > > of code, and hopefully number of
> contributors
> > > too,
> > > > > > we
> > > > > > > > > cannot
> > > > > > > > > > > > keep
> > > > > > > > > > > > > >> > > > counting on "common sense" to avoid
> breaking
> > > > > things.
> > > > > > > > We're
> > > > > > > > > > all
> > > > > > > > > > > > > >> humans
> > > > > > > > > > > > > >> > > > after all, and it is our job to have
> > > mechanisms in
> > > > > > > place
> > > > > > > > > to
> > > > > > > > > > > > > prevent
> > > > > > > > > > > > > >> us
> > > > > > > > > > > > > >> > > > from unwillingly making mistakes.
> Especially
> > > when
> > > > > > > these
> > > > > > > > > > > mistakes
> > > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > > individually,
> > > > > > > > > > > probably
> > > > > > > > > > > > > >> can't
> > > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps`
> depending
> > > on
> > > > > > > > > kiegroup's
> > > > > > > > > > > KIE
> > > > > > > > > > > > > >> Tools
> > > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > > `kogito-images`
> > > > > > > > > > depending
> > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > > > kiegroup's
> > > > > > > > > > `lienzo`
> > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > > `7.59.0.Final`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > > depending on
> > > > > > > > > > kiegroup's
> > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > > codebase
> > > > > > here:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >
> > > > > > > >
> > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > > ,
> > > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > > OptaPlanner,
> > > > > > > > > pointing
> > > > > > > > > > to
> > > > > > > > > > > > > older
> > > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P5.
> > > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > > depending
> > > > > > > > > on
> > > > > > > > > > > > > Kogito
> > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P6. Category C repos are out of date and
> not
> > > part
> > > > > of
> > > > > > > the
> > > > > > > > > > > > Category
> > > > > > > > > > > > > A
> > > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks:
> (Current
> > > > > version
> > > > > > is
> > > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > > version,
> > > > > only
> > > > > > > by
> > > > > > > > > > using
> > > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current
> version
> > > is
> > > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > > OptaPlanner
> > > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P7.
> `kie-tools`/packages/kn-plugin-workflow
> > > has
> > > > > its
> > > > > > > E2E
> > > > > > > > > > > disabled
> > > > > > > > > > > > > >> after
> > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > > > solution,
> > > > > > > as
> > > > > > > > > they
> > > > > > > > > > > > both
> > > > > > > > > > > > > >> > > > suffer from the circular dependency
> between
> > > > > > Category A
> > > > > > > > and
> > > > > > > > > > > > > Category
> > > > > > > > > > > > > >> B.
> > > > > > > > > > > > > >> > > > As Category A and Category B are both
> streams
> > > that
> > > > > > > have
> > > > > > > > > been
> > > > > > > > > > > > > really
> > > > > > > > > > > > > >> > > > active, I see this as a blocker, as there
> are
> > > > > > > > > contributions
> > > > > > > > > > > that
> > > > > > > > > > > > > >> > > > cannot be done, given that Category A
> depends
> > > on
> > > > > > > > Category
> > > > > > > > > B
> > > > > > > > > > > > with a
> > > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > > understood
> > > > > as
> > > > > > > > > > technical
> > > > > > > > > > > > > debt.
> > > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > > something
> > > > > > we'll
> > > > > > > > > always
> > > > > > > > > > > be
> > > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's
> just a
> > > > > matter
> > > > > > of
> > > > > > > > > > making
> > > > > > > > > > > > them
> > > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't
> impact
> > > the
> > > > > > > > structure
> > > > > > > > > or
> > > > > > > > > > > > > >> anything
> > > > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > > > regression
> > > > > > > we
> > > > > > > > > > > > > introduced
> > > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for
> Apache
> > > KIE
> > > > > 10,
> > > > > > > and
> > > > > > > > > > that
> > > > > > > > > > > > P5,
> > > > > > > > > > > > > >> P6,
> > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems
> > > left to
> > > > > > > > discuss
> > > > > > > > > > are
> > > > > > > > > > > P1
> > > > > > > > > > > > > and
> > > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > > proposal.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> > > from my
> > > > > > > > > > experience,
> > > > > > > > > > > > any
> > > > > > > > > > > > > >> > > > little miscalculation can lead to our
> release
> > > not
> > > > > > > > working
> > > > > > > > > > out
> > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > > possible,
> > > > > and
> > > > > > > make
> > > > > > > > > > > > > everything
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > > release,
> > > > > bear
> > > > > > > > with
> > > > > > > > > > me.
> > > > > > > > > > > > I'll
> > > > > > > > > > > > > >> lay
> > > > > > > > > > > > > >> > > > out a timeline of events that need to
> happen
> > > in
> > > > > > order
> > > > > > > > for
> > > > > > > > > > our
> > > > > > > > > > > > > >> release
> > > > > > > > > > > > > >> > > > to be published, with all artifacts
> ending up
> > > in
> > > > > the
> > > > > > > > right
> > > > > > > > > > > > places,
> > > > > > > > > > > > > >> but
> > > > > > > > > > > > > >> > > > first, we need to solve problems P1 and
> P2.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As you saw at the beginning of this email,
> > > all the
> > > > > > > > > attempts
> > > > > > > > > > we
> > > > > > > > > > > > > made
> > > > > > > > > > > > > >> > > > left us with the circular dependency
> showing
> > > up
> > > > > at a
> > > > > > > > > > different
> > > > > > > > > > > > > >> place,
> > > > > > > > > > > > > >> > > > but something all these places have in
> common
> > > is
> > > > > > that
> > > > > > > > > > they're
> > > > > > > > > > > > all
> > > > > > > > > > > > > >> > > > after kogito-apps, and before to Category
> B.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The first part of my proposal is the
> > > following:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > S1. We keep the original plan of moving
> the
> > > > > Quarkus
> > > > > > > Dev
> > > > > > > > > UIs
> > > > > > > > > > > from
> > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together
> with
> > > > > > Management
> > > > > > > > and
> > > > > > > > > > > Task
> > > > > > > > > > > > > >> > > > consoles from `kogito-images` to
> `kie-tools`.
> > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > images
> > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > > >> > > > S3. We move the entire
> > > > > `kogito-serverless-operator`
> > > > > > > repo
> > > > > > > > > > > inside
> > > > > > > > > > > > a
> > > > > > > > > > > > > >> new
> > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git
> history.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> > > problems
> > > > > P1
> > > > > > > and
> > > > > > > > > P2.
> > > > > > > > > > Of
> > > > > > > > > > > > > >> course
> > > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > > >>
> > > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > This doesn't come without consequences, of
> > > course,
> > > > > > as
> > > > > > > > the
> > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and
> `kogito-swf-builder`
> > > > > > images,
> > > > > > > > and
> > > > > > > > > > the
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be
> moving
> > > from
> > > > > > > > > Category A
> > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > Category B. This move would make them
> have to
> > > > > > > reference
> > > > > > > > > > > > Category A
> > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > > > `kogito-images`
> > > > > > > > > > and
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are already
> > > their own
> > > > > > > > > > > "sub-stream"
> > > > > > > > > > > > > >> inside
> > > > > > > > > > > > > >> > > > Category A, though, contributions made in
> a
> > > > > > cross-repo
> > > > > > > > > > fashion
> > > > > > > > > > > > to
> > > > > > > > > > > > > >> this
> > > > > > > > > > > > > >> > > > "sub-stream" will continue being
> possible, now
> > > > > via a
> > > > > > > > > single
> > > > > > > > > > PR
> > > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between
> Category
> > > A and
> > > > > > > > > Category
> > > > > > > > > > B
> > > > > > > > > > > > will
> > > > > > > > > > > > > >> > > > continue not being possible, and a 1-week
> > > delay
> > > > > > > between
> > > > > > > > > > > merging
> > > > > > > > > > > > > >> > > > something on Category A and using it on
> > > Category B
> > > > > > > will
> > > > > > > > > > still
> > > > > > > > > > > > > >> happen.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> > > however,
> > > > > > does
> > > > > > > > > allow
> > > > > > > > > > > for
> > > > > > > > > > > > > >> sparse
> > > > > > > > > > > > > >> > > > checkouts and partial builds, so working
> with
> > > a
> > > > > > subset
> > > > > > > > of
> > > > > > > > > > the
> > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > >> > > > is possible and encouraged. Making changes
> > > only to
> > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for
> example,
> > > will
> > > > > > have
> > > > > > > > the
> > > > > > > > > PR
> > > > > > > > > > > > > checks
> > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > > >> > > > We're not compromising when running
> partial
> > > builds
> > > > > > > too.
> > > > > > > > We
> > > > > > > > > > > know
> > > > > > > > > > > > > that
> > > > > > > > > > > > > >> > > > the entire repo will continue working even
> > > after
> > > > > > only
> > > > > > > > > > > building a
> > > > > > > > > > > > > >> small
> > > > > > > > > > > > > >> > > > subset of the changes. Doing partial or
> full
> > > > > builds
> > > > > > is
> > > > > > > > > > > > > automatically
> > > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm
> proposing
> > > we
> > > > > > move a
> > > > > > > > > bunch
> > > > > > > > > > > of
> > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see
> this
> > > as a
> > > > > > > > > TEMPORARY
> > > > > > > > > > > > > >> solution
> > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host
> some
> > > > > > > additional
> > > > > > > > > > stuff
> > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > > continue
> > > > > > moving
> > > > > > > > > > > forward.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > As I mentioned on other places,
> `kie-tools`
> > > > > became a
> > > > > > > > > > polyglot
> > > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > > >> > > > out of necessity, and although I'm really
> > > proud of
> > > > > > > what
> > > > > > > > we
> > > > > > > > > > > > > achieved
> > > > > > > > > > > > > >> > > > there so far, I don't think `kie-tools`
> has a
> > > > > setup
> > > > > > > that
> > > > > > > > > is
> > > > > > > > > > > > > suitable
> > > > > > > > > > > > > >> > > > for all the different nuances that
> compose our
> > > > > > > > community.
> > > > > > > > > > I'm
> > > > > > > > > > > > well
> > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that does
> not
> > > > > follow
> > > > > > > > > > widespread
> > > > > > > > > > > > > >> > > > conventions will scare some people away,
> and
> > > as
> > > > > much
> > > > > > > as
> > > > > > > > > > we've
> > > > > > > > > > > > > tried
> > > > > > > > > > > > > >> to
> > > > > > > > > > > > > >> > > > make build instructions clear, we can't
> > > always get
> > > > > > > past
> > > > > > > > > the
> > > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > > > ecosystem.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > With all that said, I keep thinking this
> is
> > > the
> > > > > best
> > > > > > > > > course
> > > > > > > > > > of
> > > > > > > > > > > > > >> action
> > > > > > > > > > > > > >> > > > for us right now. We keep most of our
> stuff
> > > > > > unchanged,
> > > > > > > > we
> > > > > > > > > > > > unblock
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> > > > release, and we have a working setup that
> will
> > > > > suit
> > > > > > us
> > > > > > > > > well
> > > > > > > > > > > > while
> > > > > > > > > > > > > we
> > > > > > > > > > > > > >> > > > discuss and reach a conclusion regarding
> the
> > > > > future
> > > > > > of
> > > > > > > > our
> > > > > > > > > > > > > codebase
> > > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Let me paint a quick picture here of what
> our
> > > code
> > > > > > > base
> > > > > > > > > > would
> > > > > > > > > > > > look
> > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > > accepted:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > > >> > > > A
> > > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > > >> > > > A
> incubator-kie-kogito-benchmarks
> > > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > B
> > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > > > >> > > > E
> > > incubator-kie-kogito-online-staging
> > > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > * Category C becomes part of Category A,
> and
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves
> entirely
> > > inside
> > > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}`
> images
> > > and
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > > `kie-tools`,
> > > > > > there
> > > > > > > > are
> > > > > > > > > > no
> > > > > > > > > > > > > cycles
> > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > > granularly
> > > > > > > build:
> > > > > > > > > > > > > >> > > > 1.
> packages/sonataflow-deployment-webapp
> > > > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images
> (containing
> > > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > > >> and
> > > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator
> (contents
> > > from
> > > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > The second part of the proposal is the
> release
> > > > > > process
> > > > > > > > > > itself,
> > > > > > > > > > > > > >> > > > assuming the structure above is what we
> have.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be
> used as
> > > > > > cutting
> > > > > > > > > point
> > > > > > > > > > > for
> > > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to
> this
> > > > > > > timestamped
> > > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > > >> and
> > > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > > >> > > > 3. At this point, with everything
> working, we
> > > can
> > > > > > > branch
> > > > > > > > > out
> > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> > > SNAPSHOT
> > > > > > > tag,
> > > > > > > > > and
> > > > > > > > > > > > > >> Category B
> > > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos
> update
> > > > > their
> > > > > > > > > versions
> > > > > > > > > > > to
> > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > > Category A
> > > > > > > repos
> > > > > > > > > > using
> > > > > > > > > > > > the
> > > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the
> release
> > > based
> > > > > > on
> > > > > > > > the
> > > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > > >> > > > branches, given we don't expect any code
> > > changes
> > > > > > > > anymore.
> > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to
> start
> > > the
> > > > > > > release
> > > > > > > > > > > process.
> > > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > > manual/automated
> > > > > > > > release
> > > > > > > > > > > > process,
> > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> pushed
> > > to
> > > > > Git,
> > > > > > > and
> > > > > > > > > > built
> > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > > artifacts
> > > > > to
> > > > > > be
> > > > > > > > > > > > propagated
> > > > > > > > > > > > > on
> > > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > > manual/automated
> > > > > > > > release
> > > > > > > > > > > > > process,
> > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags
> pushed
> > > to
> > > > > Git,
> > > > > > > and
> > > > > > > > > > built
> > > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > > >> > > > 12. Category E repos can be manually
> tagged
> > > with
> > > > > > > 10.0.0
> > > > > > > > > from
> > > > > > > > > > > > their
> > > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > More needs to be discussed if we're
> planning
> > > to
> > > > > > > maintain
> > > > > > > > > > > > multiple
> > > > > > > > > > > > > >> > > > release streams in parallel, but I guess
> it
> > > can
> > > > > wait
> > > > > > > for
> > > > > > > > > > after
> > > > > > > > > > > > > >> Apache
> > > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> > > forward to
> > > > > > > > hearing
> > > > > > > > > > back
> > > > > > > > > > > > > from
> > > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Of course, alternative solutions are
> possible.
> > > > > This
> > > > > > > > email,
> > > > > > > > > > > > > however,
> > > > > > > > > > > > > >> > > > summarizes my view of how we should
> attack the
> > > > > > > problem,
> > > > > > > > > > > > > considering
> > > > > > > > > > > > > >> > > > disruption, required effort, the release
> > > process
> > > > > > > itself,
> > > > > > > > > and
> > > > > > > > > > > > > >> history.
> > > > > > > > > > > > > >> > > > Feel free to propose alternatives. This is
> > > not a
> > > > > > > voting
> > > > > > > > > > > thread.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Tiago Bento <ti...@gmail.com>.
Francisco,
1) That's what this thread is all about... You know I don't think it's
ok. That's why I'm proposing the two images and the operator to move
into the `kie-tools` repo, where we can more granularly control the
order things are built, thus removing the dependency cycle.
2) Not sure we understand the same thing by "freeze". My proposal is
that we select a timestamped SNAPSHOT version from Category A repos to
use as base for a release. We give Category B repos some time to
adjust, and then cut the release branches. This can happen anytime,
and no contributions would ever stop because of it. The development
branches can continue accepting PRs normally, even during the release
process. Now, if what you're asking is why Category B repos refer to
Category A repos via timestamped SNAPSHOTs, the answer is in my first
email. See the paragraph starting with "An important note here is that
Category B repositories...".
On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti
<ft...@redhat.com> wrote:
>
> Tiago
> There are a couple of simple and straightforward questions that I
> formulated, but since we both write a lot, it might have been lost. Please
> let me ask them again.
> 1) Do you think it is ok that tools repo is executed after generation of
> docker images that are supposed to include those tools or the operator that
> is supposed to deploy such images?
That's what this thread is all about... You know I'm not ok with it,
that's why I'm proposing the two images and the operator to move into
the `kie-tools` repo, where we can more granularly control the order
things are built and remove the dependency cycle.
> 2) Besides that, although not directly related with the current proposal we
> are discussing, I really think there are some restrictions taken for
> granted that are arbitrary and difficult to sustain on strictly technical
> arguments. For example, the need to freeze the rest of the software before
> tools are generated. Why? We have dependencies between repos that are not
> handled that way: Apps depend on runtimes. Runtimes depend on drools,
> Operator depend on runtimes,....and we are not freezing that repos since we
> are all releasing at the same time. If we are all releasing at the same
> time, what's the rationale behind the freeze?
>
>
>
> On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <ti...@apache.org> wrote:
>
> > Glad to see the interest this proposal has gotten, and it's good to
> > see some alternatives being drafted here, although still lacking clear
> > definitions and analysis in regards to disruption, required effort,
> > the release process itself, and history. Of course, lots of details
> > and clarity on the execution part would be missing too.
> >
> > As of this moment, based on what I read here, I'm assuming that
> > everyone who participated so far doesn't see the initial proposal as
> > problematic in terms of feasibility, but some of you have a preference
> > not to go with it, because it is "wrong", and apparently because it
> > would "jeopardize the evolution of the project". Reading these last
> > words made me a little sad, to be honest. But I can deal with it :)
> >
> > Please let's try and keep the discussion as objective as possible.
> > "Right" and "wrong" are too subjective for this kind of conversation.
> >
> > Now, being practical, unless there are clear arguments based on facts
> > and objective concepts that invalidate the initial proposal shared on
> > this email, it seems to me that it is currently the only viable
> > proposal we have for unblocking and releasing Apache KIE 10. Of
> > course, if we end up seeing an alternative proposal with enough
> > details and a clear execution plan, I think then we'll be in a very
> > good position to choose from multiple options!
> >
> >
> > On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <al...@porcelli.me> wrote:
> > >
> > > Francisco and Gabriele,
> > >
> > > I understand and acknowledge your desire to find the “right” solution
> > > instead to work on a temporary “patch” - however without a detailed
> > > proposal I don’t think we can properly evaluate the impact of your
> > > suggestion.
> > >
> > > When I spoke with different SMEs that included tools and CI, the
> > > guesstimate for making the necessary changes on CI and codebase to
> > > basically have images and operators in the end of the build chain is
> > > something like 2 months of effort. Another impact that needs to be
> > > discussed is that KIE Tools repo had to be injected in the middle of all
> > > pipelines - forcing all PR checks and nightlies to build all repos (PR
> > > checks will likely take 12+ hours… I even heard that it could be even 24
> > > hours).
> > >
> > > Based on the input above, I think it’s quite risk to move in such
> > direction
> > > without a more detailed plan… because 2 months could be turned easily in
> > 6!
> > > And this is exactly what happened when we guessed that moving to Apache
> > > would take no more than 3 months. But here we are.
> > >
> > > I really strongly suggest that we focus on a release that could be
> > > achievable in less than a month from now, and we - after release - have a
> > > in depth discussion about the overall codebase and ci organization.
> > >
> > >
> > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> > gabriele.cardosi@gmail.com>
> > > wrote:
> > >
> > > > Alex,
> > > > my suggestion is to move the building of all docker images, from
> > whatever
> > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > > > invoked after all the others.
> > > > I'm not sure if this would solve all the issues, and since I could not
> > > > enter in the details of all the involved code, my suggestion may be too
> > > > naive.
> > > > Having spent almost all of the last year in CI, I may say that, at
> > least
> > > > for the kie-tools repo, removing the image build step from it should
> > not be
> > > > too difficult (since it is an issue we already faced and solved).
> > > > If, with "detailed proposal", you mean a complete list of all modules
> > to be
> > > > moved and dependency refactoring, of course I can not provide it right
> > now.
> > > >
> > > > Anyway, I share the concern from Francisco: undoing something is almost
> > > > always harder than doing it "rightly" from scratch...
> > > >
> > > >
> > > >
> > > >
> > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti
> > <
> > > > ftirados@redhat.com> ha scritto:
> > > >
> > > > > I do not think estimations should be the only driver to make a
> > decision,
> > > > > especially when the current proposal is conceptually incompatible
> > with
> > > > the
> > > > > multi repo approach that is taken elsewhere in the project.
> > > > > Given my knowledge of the CI it is nearly impossible for me to give
> > a
> > > > fair
> > > > > estimate of how much it might take to achieve step 2) of my previous
> > > > e-mail
> > > > > . It might take a while or it might be pretty easy after all, I don't
> > > > > really know, but I think it will be a good idea if some of the
> > experts
> > > > on
> > > > > CI in the team (the ones that set up the pipeline, which was a huge
> > > > > achievement) give an estimate, not me. Estimating how much it takes
> > to
> > > > > merge two existing repos (without altering CI) is easier, but it
> > does not
> > > > > mean we are doing the right thing.
> > > > > My main concern is that it will be very difficult for me to explain
> > to
> > > > > someone that arrives new to the team, that having experts on CI on
> > the
> > > > > team, we decided to merge two repos (once merged, it would be rather
> > > > > difficult to unmerge) rather than fix the CI, because of expediency.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Francisco,
> > > > > >
> > > > > > Please take the time to make the more in depth analysis needed and
> > > > > provide
> > > > > > a more detailed plan… so we - as community- can evaluate the size
> > of
> > > > the
> > > > > > effort. In the conceptual level you shared it’s near impossible to
> > > > > estimate
> > > > > > the size of the effort and compare with the current proposal.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > > ftirados@redhat.com> wrote:
> > > > > >
> > > > > > > I think I already did a high level proposal.
> > > > > > > 1) Remove all dependencies from tooling to images, so images
> > depend
> > > > on
> > > > > > > tooling but tooling does not depend on images.
> > > > > > > 2) Then change CI to deal with tooling repo before dealing with
> > > > images
> > > > > > > repo.
> > > > > > > I understand that CI details are tricky and since I'm not
> > familiar
> > > > with
> > > > > > CI
> > > > > > > in any way, I barely can make a low level design, but we do not
> > need
> > > > to
> > > > > > fix
> > > > > > > everything, just achieve 2), a change of compilation order.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <alex@porcelli.me
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Francisco and Grabriele,
> > > > > > > >
> > > > > > > > You may not like or understand why the current state of the CI
> > is
> > > > > like
> > > > > > > > that… actually has been in Red Hat and has been replicated in
> > > > Apache
> > > > > as
> > > > > > > > used to be….
> > > > > > > >
> > > > > > > > But the fact is that this is the current reality.
> > > > > > > >
> > > > > > > > If you disagree with the current plan, please provide a
> > detailed
> > > > > > > > alternative so we, as community, can better evaluate the pros
> > and
> > > > > cons
> > > > > > of
> > > > > > > > each proposal.
> > > > > > > >
> > > > > > > >
> > > > > > > > I think it’s also fair to say that, post 10 release we need to
> > > > have a
> > > > > > > much
> > > > > > > > in depth discussion about how our codebase is organized, it’s
> > clear
> > > > > > that
> > > > > > > > it’s not working.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > As Francisco said,
> > > > > > > > > I also have the impression that the "images" (if we are
> > talking
> > > > of
> > > > > > > docker
> > > > > > > > > images) should be the very last one to be built, in a
> > standalone
> > > > > > repo.
> > > > > > > > > That way, they may "combine" artifacts that are built in
> > > > different
> > > > > > > repos,
> > > > > > > > > regardless of the order in which those are built.
> > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> > maybe
> > > > > could
> > > > > > > > > simplify the situation a bit.
> > > > > > > > > (I also think there are some statements of undisputable needs
> > > > while
> > > > > > > they
> > > > > > > > > are, actually, just technical choices.
> > > > > > > > > Anyway, this latter point is for longer, following,
> > discussion.)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> > Tirado
> > > > > > Sarti
> > > > > > > <
> > > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > > >
> > > > > > > > > > Alex,
> > > > > > > > > > There are two assumptions that deserve further discussion:
> > > > > > > > > > 1) That tool has to be the last to build. why? it does not
> > have
> > > > > > more
> > > > > > > > > sense
> > > > > > > > > > to build final images after everything else has been
> > built?-
> > > > > > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> > > > > bigger
> > > > > > > than
> > > > > > > > > the
> > > > > > > > > > impact (long term consequences) of consolidating two
> > unrelated
> > > > > > piece
> > > > > > > of
> > > > > > > > > > software within the same repository.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > > alex@porcelli.me
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Francisco,
> > > > > > > > > > >
> > > > > > > > > > > This was discussed as an alternative solution, however
> > it has
> > > > > > major
> > > > > > > > > > impact
> > > > > > > > > > > on CI and there’s also the fact Tool has been always the
> > last
> > > > > to
> > > > > > > > build
> > > > > > > > > > and
> > > > > > > > > > > has no Snapshot published (actually in JavaScript world
> > there
> > > > > is
> > > > > > no
> > > > > > > > > > > snapshot concept).
> > > > > > > > > > >
> > > > > > > > > > > So, based on our evaluation… the proposal here is the
> > least
> > > > > > > > disruptive
> > > > > > > > > > and
> > > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > _____________
> > > > > > > > > > > Alex Porcelli
> > > > > > > > > > > http://porcelli.me
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > > > Sarti <
> > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > After kie-tools, sorry. I think we are not embracing
> > the
> > > > fact
> > > > > > > that
> > > > > > > > > > > > kogito-images depend on kie-tools, because we want
> > those
> > > > > images
> > > > > > > to
> > > > > > > > > > > include
> > > > > > > > > > > > tools.
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> > Tirado
> > > > > Sarti
> > > > > > <
> > > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > > It can be an alternative solution to move
> > > > > kn-plugin-workflow
> > > > > > to
> > > > > > > > > > > > > kogito-images (so there is not longer dependency from
> > > > tools
> > > > > > to
> > > > > > > > > > images)
> > > > > > > > > > > > and
> > > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > > Martinez
> > > > > <
> > > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache)
> > <
> > > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > > >> escribió:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > > alex@porcelli.me
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > > +1
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > I spent the last day or so working closely with
> > > > Tiago,
> > > > > > > > > exploring
> > > > > > > > > > > > >> > different
> > > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > > evaluating
> > > > > > > the
> > > > > > > > > > > overall
> > > > > > > > > > > > >> > release
> > > > > > > > > > > > >> > > procedure steps required. I agree with the
> > proposal
> > > > as
> > > > > > the
> > > > > > > > > most
> > > > > > > > > > > > >> > > viable option for unblocking the 10 release in
> > the
> > > > > > > > reasonable
> > > > > > > > > > time
> > > > > > > > > > > > >> frame.
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time,
> > as
> > > > this
> > > > > > > > matter
> > > > > > > > > > > > >> requires a
> > > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > > > > > according
> > > > > > > > to
> > > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > > > > > >> > > > (
> > > > > > > > > > >
> > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > > ),
> > > > > > > > > > > > >> > > > many of us were working towards removing a
> > > > circular
> > > > > > > > > dependency
> > > > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > > > `kie-tools`.
> > > > > > > > As
> > > > > > > > > we
> > > > > > > > > > > > >> > > > progressed towards a solution, we kept
> > finding the
> > > > > > > > circular
> > > > > > > > > > > > >> dependency
> > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of
> > the
> > > > > > things
> > > > > > > > we
> > > > > > > > > > did,
> > > > > > > > > > > > and
> > > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Right now, even though we started the effort
> > to
> > > > move
> > > > > > the
> > > > > > > > > > Quarkus
> > > > > > > > > > > > Dev
> > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> > able to
> > > > > do
> > > > > > it
> > > > > > > > > yet,
> > > > > > > > > > as
> > > > > > > > > > > > >> we've
> > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> > Maven
> > > > > 3.9.6,
> > > > > > > and
> > > > > > > > > > > Quarkus
> > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > > This
> > > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > > >> > > >
> > > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > > .
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > C | 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > Y | 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > C | 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > > >> > > > E | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > > >> > > > * and
> > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > > depend
> > > > > > > > > > > > >> on
> > > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> > `kie-tools`,
> > > > we
> > > > > > > > would've
> > > > > > > > > > > had:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > Y | 05.
> > > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > > >> > > > L | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > > >> > > > * and
> > `kogito-images`/kogito-swf-devmode
> > > > > > depends
> > > > > > > > on
> > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > > > > > `kie-tools`,
> > > > > > > > > we
> > > > > > > > > > > > >> would've
> > > > > > > > > > > > >> > > > had:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 01.
> > incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > 03.
> > incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > 04.
> > incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > C |==> 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > > >> > > > C | 06.
> > > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > > >> > > > E
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> > depends
> > > > > on
> > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem than a
> > > > simple
> > > > > > > > > circular
> > > > > > > > > > > > >> > dependency.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > After multiple conversations with a lot of
> > people,
> > > > > > it's
> > > > > > > > been
> > > > > > > > > > > > really
> > > > > > > > > > > > >> > > > hard coming up with a simple solution that
> > makes
> > > > it
> > > > > > > > possible
> > > > > > > > > > to
> > > > > > > > > > > > >> build
> > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving the
> > way
> > > > > > > everyone
> > > > > > > > is
> > > > > > > > > > > used
> > > > > > > > > > > > to
> > > > > > > > > > > > >> > > > contributing to the multiple repositories we
> > have.
> > > > > > More
> > > > > > > > than
> > > > > > > > > > > that,
> > > > > > > > > > > > >> > > > while making this assessment, I found more
> > > > problems
> > > > > > > that,
> > > > > > > > in
> > > > > > > > > > my
> > > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> > forward
> > > > with
> > > > > > my
> > > > > > > > > > proposal
> > > > > > > > > > > > for
> > > > > > > > > > > > >> > > > the Apache KIE release process, so we can use
> > > > > Apache's
> > > > > > > > > > > mechanisms
> > > > > > > > > > > > to
> > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> > this
> > > > > really
> > > > > > > > > > > complicated
> > > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > > > current
> > > > > > > > > situation
> > > > > > > > > > > of
> > > > > > > > > > > > >> our
> > > > > > > > > > > > >> > > > codebase, as well as problems I can currently
> > see.
> > > > > > I'll
> > > > > > > > > start
> > > > > > > > > > > with
> > > > > > > > > > > > >> an
> > > > > > > > > > > > >> > > > analysis of the repositories and their
> > purposes,
> > > > > point
> > > > > > > out
> > > > > > > > > > some
> > > > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > > > release,
> > > > > > > > explain
> > > > > > > > > > my
> > > > > > > > > > > > >> > > > proposal and discuss some consequences to
> > what I'm
> > > > > > > > > proposing.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> > `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > > > `main`
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> > > > > `0.0.0`
> > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > > >> > > > (Issues only, README should be updated @
> > > > `main`.
> > > > > > > Same
> > > > > > > > > for
> > > > > > > > > > > > GitHub
> > > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy at
> > the
> > > > > > `main`
> > > > > > > > > > branch.)
> > > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > > > > > `deploy`
> > > > > > > to
> > > > > > > > > > > update
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > > >> > > > (GitHub pages used to host
> > sandbox.kie.org
> > > > and
> > > > > > KIE
> > > > > > > > > Tools'
> > > > > > > > > > > > >> Chrome
> > > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> > checks
> > > > > > during
> > > > > > > > the
> > > > > > > > > > > > staging
> > > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I grouped the repositories by category, and
> > listed
> > > > > > them
> > > > > > > > in a
> > > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > > flattening
> > > > > > > out a
> > > > > > > > > > tree,
> > > > > > > > > > > > >> there
> > > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > > OptaPlanner
> > > > > > > > > could've
> > > > > > > > > > > been
> > > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category A repos are what I've been referring
> > to
> > > > as
> > > > > > > > `drools`
> > > > > > > > > > and
> > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is
> > inside
> > > > > > that
> > > > > > > > > > stream,
> > > > > > > > > > > as
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> > > > way these repositories reference each other
> > are
> > > > > > through
> > > > > > > > > Maven
> > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > > > > > version.
> > > > > > > > This
> > > > > > > > > > > > >> mechanism
> > > > > > > > > > > > >> > > > is well-known to the team, and although
> > flawed for
> > > > > > > > intra-day
> > > > > > > > > > > > builds
> > > > > > > > > > > > >> > > > and disruptive for people in many different
> > time
> > > > > > zones,
> > > > > > > it
> > > > > > > > > is
> > > > > > > > > > > > >> already
> > > > > > > > > > > > >> > > > very comfortable for everyone to work with, I
> > > > > assume.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > > dedicated
> > > > > > > > > > pipelines,
> > > > > > > > > > > > >> which
> > > > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > > > cross-repo
> > > > > > > PRs
> > > > > > > > > > > > together
> > > > > > > > > > > > >> > > > and verify that the codebase will continue
> > working
> > > > > as
> > > > > > > > > expected
> > > > > > > > > > > > after
> > > > > > > > > > > > >> > > > they're all merged. From what I could gather,
> > > > there
> > > > > > are
> > > > > > > > some
> > > > > > > > > > > > >> > > > "sub-streams" currently configured for
> > cross-repo
> > > > > PRs.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > > > kogito-examples
> > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > > >> > > > - kogito-images, and
> > kogito-serverless-operator
> > > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > > > > > combination
> > > > > > > > of
> > > > > > > > > > > repos
> > > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> > cannot
> > > > be
> > > > > > > > > verified
> > > > > > > > > > > > before
> > > > > > > > > > > > >> > > > merging, making our contribution model
> > dependent
> > > > on
> > > > > > > > > individual
> > > > > > > > > > > > >> > > > contributors building stuff on their machines
> > to
> > > > > > verify
> > > > > > > > that
> > > > > > > > > > it
> > > > > > > > > > > > >> works.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > > >> > > > ,
> > > > > > > > > > > > >> > > > and
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > > pipelines,
> > > > > > so
> > > > > > > > > > please
> > > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category B repos are what I've been referring
> > to
> > > > as
> > > > > > > > > > `kie-tools`
> > > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > > repository
> > > > > > > that
> > > > > > > > > is
> > > > > > > > > > > used
> > > > > > > > > > > > >> by
> > > > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > > > Sandbox,
> > > > > > > > > similar
> > > > > > > > > > > to a
> > > > > > > > > > > > >> > > > Maven archetype, if you will. The other one
> > is the
> > > > > KIE
> > > > > > > > Tools
> > > > > > > > > > > > >> monorepo,
> > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > > > system.
> > > > > > > > > > Currently,
> > > > > > > > > > > > KIE
> > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> > TypeScript
> > > > > > > libraries
> > > > > > > > > and
> > > > > > > > > > > > apps,
> > > > > > > > > > > > >> Go
> > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > > `kie-tools`
> > > > > > > > > monorepo
> > > > > > > > > > > is
> > > > > > > > > > > > >> > > > configured to work with sparse checkouts and
> > can
> > > > do
> > > > > > > > partial
> > > > > > > > > > > > builds.
> > > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> > through
> > > > > > > > > timestamped
> > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > > > > > introduced
> > > > > > > > > that
> > > > > > > > > > > > will
> > > > > > > > > > > > >> > > > build and publish immutable, persistent
> > artifacts
> > > > > > under
> > > > > > > a
> > > > > > > > > > > version
> > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > > > published
> > > > > > > > weekly
> > > > > > > > > > > every
> > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > > evolution
> > > > > > to
> > > > > > > > the
> > > > > > > > > > > Kogito
> > > > > > > > > > > > >> > > > releases, as we're now targeting one release
> > for
> > > > all
> > > > > > of
> > > > > > > > > Apache
> > > > > > > > > > > > KIE,
> > > > > > > > > > > > >> so
> > > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > An important note here is that Category B
> > > > > repositories
> > > > > > > > have
> > > > > > > > > > been
> > > > > > > > > > > > >> > > > historically kept out of any automations we
> > used
> > > > to
> > > > > > > have,
> > > > > > > > > way
> > > > > > > > > > > back
> > > > > > > > > > > > >> > > > when Kogito started and we had the Business
> > > > Central
> > > > > > > > (a.k.a.
> > > > > > > > > > v7)
> > > > > > > > > > > > >> stream
> > > > > > > > > > > > >> > > > still going on. For this reason, Category B
> > > > projects
> > > > > > > have
> > > > > > > > > > > > developed
> > > > > > > > > > > > >> > > > their own automations, based on GitHub
> > Actions.
> > > > > > > Category B
> > > > > > > > > > repos
> > > > > > > > > > > > >> have
> > > > > > > > > > > > >> > > > always depended on Category A repos using
> > fixed
> > > > > > > versions.
> > > > > > > > If
> > > > > > > > > > > > >> Category
> > > > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > > > breaking
> > > > > > > > changes
> > > > > > > > > > on
> > > > > > > > > > > > >> > > > Category A repositories would've had the
> > potential
> > > > > to
> > > > > > > > break
> > > > > > > > > > > > >> Category B
> > > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > > development
> > > > > > > > > stream,
> > > > > > > > > > > and
> > > > > > > > > > > > >> > > > introducing unpleasant surprises for
> > maintainers
> > > > of
> > > > > > > > > Category B
> > > > > > > > > > > > >> repos,
> > > > > > > > > > > > >> > > > as historically Category A contributors were
> > not
> > > > > > > familiar
> > > > > > > > > with
> > > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Contributions made to Category B repos go
> > through
> > > > a
> > > > > > > GitHub
> > > > > > > > > > > Actions
> > > > > > > > > > > > >> > > > workflow that builds the relevant part of the
> > > > > > > `kie-tools`
> > > > > > > > > > > monorepo
> > > > > > > > > > > > >> for
> > > > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > > > pipeline
> > > > > > > > itself
> > > > > > > > > > are
> > > > > > > > > > > > also
> > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do
> > things
> > > > > > like
> > > > > > > > > > > atomically
> > > > > > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > > > > > importantly,
> > > > > > > > > it
> > > > > > > > > > > > >> allows
> > > > > > > > > > > > >> > > > us to upgrade the repository to a new
> > timestamped
> > > > > > > SNAPSHOT
> > > > > > > > > > > > together
> > > > > > > > > > > > >> > > > with the changes necessary to make it stay
> > green.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This setup, however, makes it impossible to
> > have
> > > > > > > > cross-repo
> > > > > > > > > > PRs
> > > > > > > > > > > > >> > > > involving Category A and Category B
> > > > simultaneously,
> > > > > > with
> > > > > > > > the
> > > > > > > > > > > > current
> > > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category C repos are kind of floating around,
> > and
> > > > > I'm
> > > > > > > not
> > > > > > > > > sure
> > > > > > > > > > > if
> > > > > > > > > > > > >> > > > there's much activity going on there.
> > Regardless,
> > > > as
> > > > > > > > they're
> > > > > > > > > > > part
> > > > > > > > > > > > of
> > > > > > > > > > > > >> > > > Apache KIE, they will be part of our release,
> > so I
> > > > > > > listed
> > > > > > > > > them
> > > > > > > > > > > for
> > > > > > > > > > > > >> us
> > > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category D is self explanatory. There's only
> > one
> > > > > repo
> > > > > > > that
> > > > > > > > > has
> > > > > > > > > > > > >> already
> > > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > > directly,
> > > > > > and
> > > > > > > > are
> > > > > > > > > > > > either
> > > > > > > > > > > > >> > > > organizational entities, or host websites,
> > that
> > > > > > > currently
> > > > > > > > > are
> > > > > > > > > > > not
> > > > > > > > > > > > >> part
> > > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This lack of unification between Category A
> > and
> > > > > > > Category B
> > > > > > > > > is,
> > > > > > > > > > > > IMHO,
> > > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> > circular
> > > > > > > > > dependency
> > > > > > > > > > > > >> between
> > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now
> > can
> > > > > > describe
> > > > > > > > as
> > > > > > > > > a
> > > > > > > > > > > > >> circular
> > > > > > > > > > > > >> > > > dependency between Category A and Category B.
> > The
> > > > > way
> > > > > > I
> > > > > > > > see
> > > > > > > > > > it,
> > > > > > > > > > > if
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > had a single pipeline, building everything
> > from
> > > > > > `drools`
> > > > > > > > to
> > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > > > introduced,
> > > > > > > > and
> > > > > > > > > we
> > > > > > > > > > > > >> > > > wouldn't be having this huge problem in our
> > hands
> > > > > > right
> > > > > > > > now.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > My proposal for the Apache KIE release process
> > > > sees
> > > > > > this
> > > > > > > > > lack
> > > > > > > > > > of
> > > > > > > > > > > > >> > > > unification as a central problem, not only for
> > > > this
> > > > > > > > release
> > > > > > > > > in
> > > > > > > > > > > > >> > > > particular, but for the community as a whole.
> > It
> > > > is
> > > > > my
> > > > > > > > > belief
> > > > > > > > > > > that
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > > contribution
> > > > > > > > should
> > > > > > > > > > be
> > > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> > With
> > > > the
> > > > > > > > > increasing
> > > > > > > > > > > > >> volume
> > > > > > > > > > > > >> > > > of code, and hopefully number of contributors
> > too,
> > > > > we
> > > > > > > > cannot
> > > > > > > > > > > keep
> > > > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > > > things.
> > > > > > > We're
> > > > > > > > > all
> > > > > > > > > > > > >> humans
> > > > > > > > > > > > >> > > > after all, and it is our job to have
> > mechanisms in
> > > > > > place
> > > > > > > > to
> > > > > > > > > > > > prevent
> > > > > > > > > > > > >> us
> > > > > > > > > > > > >> > > > from unwillingly making mistakes. Especially
> > when
> > > > > > these
> > > > > > > > > > mistakes
> > > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > > individually,
> > > > > > > > > > probably
> > > > > > > > > > > > >> can't
> > > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending
> > on
> > > > > > > > kiegroup's
> > > > > > > > > > KIE
> > > > > > > > > > > > >> Tools
> > > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > > `kogito-images`
> > > > > > > > > depending
> > > > > > > > > > on
> > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > > kiegroup's
> > > > > > > > > `lienzo`
> > > > > > > > > > > and
> > > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> > `7.59.0.Final`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> > depending on
> > > > > > > > > kiegroup's
> > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > > >> > > > * This module was removed from the KIE
> > codebase
> > > > > here:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > >
> > > > > > >
> > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > > ,
> > > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> > OptaPlanner,
> > > > > > > > pointing
> > > > > > > > > to
> > > > > > > > > > > > older
> > > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P5.
> > `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > > depending
> > > > > > > > on
> > > > > > > > > > > > Kogito
> > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > > >> > > > See:
> > > > > > > > > > > > >> > > > -
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P6. Category C repos are out of date and not
> > part
> > > > of
> > > > > > the
> > > > > > > > > > > Category
> > > > > > > > > > > > A
> > > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > > > version
> > > > > is
> > > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > > >> > > > depending on Kogito without a specific
> > version,
> > > > only
> > > > > > by
> > > > > > > > > using
> > > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version
> > is
> > > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> > OptaPlanner
> > > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow
> > has
> > > > its
> > > > > > E2E
> > > > > > > > > > disabled
> > > > > > > > > > > > >> after
> > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > > solution,
> > > > > > as
> > > > > > > > they
> > > > > > > > > > > both
> > > > > > > > > > > > >> > > > suffer from the circular dependency between
> > > > > Category A
> > > > > > > and
> > > > > > > > > > > > Category
> > > > > > > > > > > > >> B.
> > > > > > > > > > > > >> > > > As Category A and Category B are both streams
> > that
> > > > > > have
> > > > > > > > been
> > > > > > > > > > > > really
> > > > > > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > > > > > contributions
> > > > > > > > > > that
> > > > > > > > > > > > >> > > > cannot be done, given that Category A depends
> > on
> > > > > > > Category
> > > > > > > > B
> > > > > > > > > > > with a
> > > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> > understood
> > > > as
> > > > > > > > > technical
> > > > > > > > > > > > debt.
> > > > > > > > > > > > >> > > > Depending on unmaintained projects is
> > something
> > > > > we'll
> > > > > > > > always
> > > > > > > > > > be
> > > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > > > matter
> > > > > of
> > > > > > > > > making
> > > > > > > > > > > them
> > > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > P7 is an isolated problem that won't impact
> > the
> > > > > > > structure
> > > > > > > > or
> > > > > > > > > > > > >> anything
> > > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > > regression
> > > > > > we
> > > > > > > > > > > > introduced
> > > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache
> > KIE
> > > > 10,
> > > > > > and
> > > > > > > > > that
> > > > > > > > > > > P5,
> > > > > > > > > > > > >> P6,
> > > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems
> > left to
> > > > > > > discuss
> > > > > > > > > are
> > > > > > > > > > P1
> > > > > > > > > > > > and
> > > > > > > > > > > > >> > > > P2, which can't be done without a proper
> > proposal.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> > from my
> > > > > > > > > experience,
> > > > > > > > > > > any
> > > > > > > > > > > > >> > > > little miscalculation can lead to our release
> > not
> > > > > > > working
> > > > > > > > > out
> > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > >> > > > end. To try and avoid that as much as
> > possible,
> > > > and
> > > > > > make
> > > > > > > > > > > > everything
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> > release,
> > > > bear
> > > > > > > with
> > > > > > > > > me.
> > > > > > > > > > > I'll
> > > > > > > > > > > > >> lay
> > > > > > > > > > > > >> > > > out a timeline of events that need to happen
> > in
> > > > > order
> > > > > > > for
> > > > > > > > > our
> > > > > > > > > > > > >> release
> > > > > > > > > > > > >> > > > to be published, with all artifacts ending up
> > in
> > > > the
> > > > > > > right
> > > > > > > > > > > places,
> > > > > > > > > > > > >> but
> > > > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > As you saw at the beginning of this email,
> > all the
> > > > > > > > attempts
> > > > > > > > > we
> > > > > > > > > > > > made
> > > > > > > > > > > > >> > > > left us with the circular dependency showing
> > up
> > > > at a
> > > > > > > > > different
> > > > > > > > > > > > >> place,
> > > > > > > > > > > > >> > > > but something all these places have in common
> > is
> > > > > that
> > > > > > > > > they're
> > > > > > > > > > > all
> > > > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > The first part of my proposal is the
> > following:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > > > Quarkus
> > > > > > Dev
> > > > > > > > UIs
> > > > > > > > > > from
> > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > > > Management
> > > > > > > and
> > > > > > > > > > Task
> > > > > > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > images
> > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > > >> > > > S3. We move the entire
> > > > `kogito-serverless-operator`
> > > > > > repo
> > > > > > > > > > inside
> > > > > > > > > > > a
> > > > > > > > > > > > >> new
> > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> > problems
> > > > P1
> > > > > > and
> > > > > > > > P2.
> > > > > > > > > Of
> > > > > > > > > > > > >> course
> > > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > > >>
> > > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > This doesn't come without consequences, of
> > course,
> > > > > as
> > > > > > > the
> > > > > > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> > > > > images,
> > > > > > > and
> > > > > > > > > the
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be moving
> > from
> > > > > > > > Category A
> > > > > > > > > > to
> > > > > > > > > > > > >> > > > Category B. This move would make them have to
> > > > > > reference
> > > > > > > > > > > Category A
> > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > > `kogito-images`
> > > > > > > > > and
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` are already
> > their own
> > > > > > > > > > "sub-stream"
> > > > > > > > > > > > >> inside
> > > > > > > > > > > > >> > > > Category A, though, contributions made in a
> > > > > cross-repo
> > > > > > > > > fashion
> > > > > > > > > > > to
> > > > > > > > > > > > >> this
> > > > > > > > > > > > >> > > > "sub-stream" will continue being possible, now
> > > > via a
> > > > > > > > single
> > > > > > > > > PR
> > > > > > > > > > > to
> > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category
> > A and
> > > > > > > > Category
> > > > > > > > > B
> > > > > > > > > > > will
> > > > > > > > > > > > >> > > > continue not being possible, and a 1-week
> > delay
> > > > > > between
> > > > > > > > > > merging
> > > > > > > > > > > > >> > > > something on Category A and using it on
> > Category B
> > > > > > will
> > > > > > > > > still
> > > > > > > > > > > > >> happen.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> > however,
> > > > > does
> > > > > > > > allow
> > > > > > > > > > for
> > > > > > > > > > > > >> sparse
> > > > > > > > > > > > >> > > > checkouts and partial builds, so working with
> > a
> > > > > subset
> > > > > > > of
> > > > > > > > > the
> > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > >> > > > is possible and encouraged. Making changes
> > only to
> > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example,
> > will
> > > > > have
> > > > > > > the
> > > > > > > > PR
> > > > > > > > > > > > checks
> > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > > >> > > > .
> > > > > > > > > > > > >> > > > We're not compromising when running partial
> > builds
> > > > > > too.
> > > > > > > We
> > > > > > > > > > know
> > > > > > > > > > > > that
> > > > > > > > > > > > >> > > > the entire repo will continue working even
> > after
> > > > > only
> > > > > > > > > > building a
> > > > > > > > > > > > >> small
> > > > > > > > > > > > >> > > > subset of the changes. Doing partial or full
> > > > builds
> > > > > is
> > > > > > > > > > > > automatically
> > > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Keep in mind that, even though I'm proposing
> > we
> > > > > move a
> > > > > > > > bunch
> > > > > > > > > > of
> > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see this
> > as a
> > > > > > > > TEMPORARY
> > > > > > > > > > > > >> solution
> > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > > > > > additional
> > > > > > > > > stuff
> > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> > continue
> > > > > moving
> > > > > > > > > > forward.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> > > > became a
> > > > > > > > > polyglot
> > > > > > > > > > > > >> monorepo
> > > > > > > > > > > > >> > > > out of necessity, and although I'm really
> > proud of
> > > > > > what
> > > > > > > we
> > > > > > > > > > > > achieved
> > > > > > > > > > > > >> > > > there so far, I don't think `kie-tools` has a
> > > > setup
> > > > > > that
> > > > > > > > is
> > > > > > > > > > > > suitable
> > > > > > > > > > > > >> > > > for all the different nuances that compose our
> > > > > > > community.
> > > > > > > > > I'm
> > > > > > > > > > > well
> > > > > > > > > > > > >> > > > aware that a polyglot monorepo that does not
> > > > follow
> > > > > > > > > widespread
> > > > > > > > > > > > >> > > > conventions will scare some people away, and
> > as
> > > > much
> > > > > > as
> > > > > > > > > we've
> > > > > > > > > > > > tried
> > > > > > > > > > > > >> to
> > > > > > > > > > > > >> > > > make build instructions clear, we can't
> > always get
> > > > > > past
> > > > > > > > the
> > > > > > > > > > > > >> prejudice
> > > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > > ecosystem.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > With all that said, I keep thinking this is
> > the
> > > > best
> > > > > > > > course
> > > > > > > > > of
> > > > > > > > > > > > >> action
> > > > > > > > > > > > >> > > > for us right now. We keep most of our stuff
> > > > > unchanged,
> > > > > > > we
> > > > > > > > > > > unblock
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> > > > release, and we have a working setup that will
> > > > suit
> > > > > us
> > > > > > > > well
> > > > > > > > > > > while
> > > > > > > > > > > > we
> > > > > > > > > > > > >> > > > discuss and reach a conclusion regarding the
> > > > future
> > > > > of
> > > > > > > our
> > > > > > > > > > > > codebase
> > > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Let me paint a quick picture here of what our
> > code
> > > > > > base
> > > > > > > > > would
> > > > > > > > > > > look
> > > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> > accepted:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > > >> > > > A
> > incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > B
> > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > > >> > > > E
> > incubator-kie-kogito-online-staging
> > > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves entirely
> > inside
> > > > > > > > > > `kie-tools`.
> > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images
> > and
> > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> > `kie-tools`,
> > > > > there
> > > > > > > are
> > > > > > > > > no
> > > > > > > > > > > > cycles
> > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> > granularly
> > > > > > build:
> > > > > > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > > >> and
> > > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator (contents
> > from
> > > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > The second part of the proposal is the release
> > > > > process
> > > > > > > > > itself,
> > > > > > > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as
> > > > > cutting
> > > > > > > > point
> > > > > > > > > > for
> > > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > > >> > > > 2. Update Category B repos to point to this
> > > > > > timestamped
> > > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > > >> and
> > > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > > >> > > > 3. At this point, with everything working, we
> > can
> > > > > > branch
> > > > > > > > out
> > > > > > > > > > to
> > > > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> > SNAPSHOT
> > > > > > tag,
> > > > > > > > and
> > > > > > > > > > > > >> Category B
> > > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > > >> > > > 4. All Category A and Category B repos update
> > > > their
> > > > > > > > versions
> > > > > > > > > > to
> > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> > Category A
> > > > > > repos
> > > > > > > > > using
> > > > > > > > > > > the
> > > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > > >> > > > 6. At this point, we can vote on the release
> > based
> > > > > on
> > > > > > > the
> > > > > > > > > > > `10.0.x`
> > > > > > > > > > > > >> > > > branches, given we don't expect any code
> > changes
> > > > > > > anymore.
> > > > > > > > > > > > >> > > > 7. After voting passes, we're good to start
> > the
> > > > > > release
> > > > > > > > > > process.
> > > > > > > > > > > > >> > > > 8. Category A repos follow their
> > manual/automated
> > > > > > > release
> > > > > > > > > > > process,
> > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed
> > to
> > > > Git,
> > > > > > and
> > > > > > > > > built
> > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> > artifacts
> > > > to
> > > > > be
> > > > > > > > > > > propagated
> > > > > > > > > > > > on
> > > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > > >> > > > 10. Category B repos follow their
> > manual/automated
> > > > > > > release
> > > > > > > > > > > > process,
> > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed
> > to
> > > > Git,
> > > > > > and
> > > > > > > > > built
> > > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > > >> > > > 12. Category E repos can be manually tagged
> > with
> > > > > > 10.0.0
> > > > > > > > from
> > > > > > > > > > > their
> > > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > More needs to be discussed if we're planning
> > to
> > > > > > maintain
> > > > > > > > > > > multiple
> > > > > > > > > > > > >> > > > release streams in parallel, but I guess it
> > can
> > > > wait
> > > > > > for
> > > > > > > > > after
> > > > > > > > > > > > >> Apache
> > > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> > forward to
> > > > > > > hearing
> > > > > > > > > back
> > > > > > > > > > > > from
> > > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Of course, alternative solutions are possible.
> > > > This
> > > > > > > email,
> > > > > > > > > > > > however,
> > > > > > > > > > > > >> > > > summarizes my view of how we should attack the
> > > > > > problem,
> > > > > > > > > > > > considering
> > > > > > > > > > > > >> > > > disruption, required effort, the release
> > process
> > > > > > itself,
> > > > > > > > and
> > > > > > > > > > > > >> history.
> > > > > > > > > > > > >> > > > Feel free to propose alternatives. This is
> > not a
> > > > > > voting
> > > > > > > > > > thread.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >>
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > > dev-help@kie.apache.org
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Tiago
There are a couple of simple and straightforward questions that I
formulated, but since we both write a lot, it might have been lost. Please
let me ask them again.
1) Do you think it is ok that tools repo is executed after generation of
docker images that are supposed to include those tools or the operator that
is supposed to deploy such images?
2) Besides that, although not directly related with the current proposal we
are discussing, I really think there are some restrictions taken for
granted that are arbitrary and difficult to sustain on strictly technical
arguments. For example, the need to freeze the rest of the software before
tools are generated. Why? We have dependencies between repos that are not
handled that way: Apps depend on runtimes. Runtimes depend on drools,
Operator depend on runtimes,....and we are not freezing that repos since we
are all releasing at the same time. If we are all releasing at the same
time, what's the rationale behind the freeze?
On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <ti...@apache.org> wrote:
> Glad to see the interest this proposal has gotten, and it's good to
> see some alternatives being drafted here, although still lacking clear
> definitions and analysis in regards to disruption, required effort,
> the release process itself, and history. Of course, lots of details
> and clarity on the execution part would be missing too.
>
> As of this moment, based on what I read here, I'm assuming that
> everyone who participated so far doesn't see the initial proposal as
> problematic in terms of feasibility, but some of you have a preference
> not to go with it, because it is "wrong", and apparently because it
> would "jeopardize the evolution of the project". Reading these last
> words made me a little sad, to be honest. But I can deal with it :)
>
> Please let's try and keep the discussion as objective as possible.
> "Right" and "wrong" are too subjective for this kind of conversation.
>
> Now, being practical, unless there are clear arguments based on facts
> and objective concepts that invalidate the initial proposal shared on
> this email, it seems to me that it is currently the only viable
> proposal we have for unblocking and releasing Apache KIE 10. Of
> course, if we end up seeing an alternative proposal with enough
> details and a clear execution plan, I think then we'll be in a very
> good position to choose from multiple options!
>
>
> On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > Francisco and Gabriele,
> >
> > I understand and acknowledge your desire to find the “right” solution
> > instead to work on a temporary “patch” - however without a detailed
> > proposal I don’t think we can properly evaluate the impact of your
> > suggestion.
> >
> > When I spoke with different SMEs that included tools and CI, the
> > guesstimate for making the necessary changes on CI and codebase to
> > basically have images and operators in the end of the build chain is
> > something like 2 months of effort. Another impact that needs to be
> > discussed is that KIE Tools repo had to be injected in the middle of all
> > pipelines - forcing all PR checks and nightlies to build all repos (PR
> > checks will likely take 12+ hours… I even heard that it could be even 24
> > hours).
> >
> > Based on the input above, I think it’s quite risk to move in such
> direction
> > without a more detailed plan… because 2 months could be turned easily in
> 6!
> > And this is exactly what happened when we guessed that moving to Apache
> > would take no more than 3 months. But here we are.
> >
> > I really strongly suggest that we focus on a release that could be
> > achievable in less than a month from now, and we - after release - have a
> > in depth discussion about the overall codebase and ci organization.
> >
> >
> > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <
> gabriele.cardosi@gmail.com>
> > wrote:
> >
> > > Alex,
> > > my suggestion is to move the building of all docker images, from
> whatever
> > > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > > invoked after all the others.
> > > I'm not sure if this would solve all the issues, and since I could not
> > > enter in the details of all the involved code, my suggestion may be too
> > > naive.
> > > Having spent almost all of the last year in CI, I may say that, at
> least
> > > for the kie-tools repo, removing the image build step from it should
> not be
> > > too difficult (since it is an issue we already faced and solved).
> > > If, with "detailed proposal", you mean a complete list of all modules
> to be
> > > moved and dependency refactoring, of course I can not provide it right
> now.
> > >
> > > Anyway, I share the concern from Francisco: undoing something is almost
> > > always harder than doing it "rightly" from scratch...
> > >
> > >
> > >
> > >
> > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti
> <
> > > ftirados@redhat.com> ha scritto:
> > >
> > > > I do not think estimations should be the only driver to make a
> decision,
> > > > especially when the current proposal is conceptually incompatible
> with
> > > the
> > > > multi repo approach that is taken elsewhere in the project.
> > > > Given my knowledge of the CI it is nearly impossible for me to give
> a
> > > fair
> > > > estimate of how much it might take to achieve step 2) of my previous
> > > e-mail
> > > > . It might take a while or it might be pretty easy after all, I don't
> > > > really know, but I think it will be a good idea if some of the
> experts
> > > on
> > > > CI in the team (the ones that set up the pipeline, which was a huge
> > > > achievement) give an estimate, not me. Estimating how much it takes
> to
> > > > merge two existing repos (without altering CI) is easier, but it
> does not
> > > > mean we are doing the right thing.
> > > > My main concern is that it will be very difficult for me to explain
> to
> > > > someone that arrives new to the team, that having experts on CI on
> the
> > > > team, we decided to merge two repos (once merged, it would be rather
> > > > difficult to unmerge) rather than fix the CI, because of expediency.
> > > >
> > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> > > > wrote:
> > > >
> > > > > Francisco,
> > > > >
> > > > > Please take the time to make the more in depth analysis needed and
> > > > provide
> > > > > a more detailed plan… so we - as community- can evaluate the size
> of
> > > the
> > > > > effort. In the conceptual level you shared it’s near impossible to
> > > > estimate
> > > > > the size of the effort and compare with the current proposal.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > > ftirados@redhat.com> wrote:
> > > > >
> > > > > > I think I already did a high level proposal.
> > > > > > 1) Remove all dependencies from tooling to images, so images
> depend
> > > on
> > > > > > tooling but tooling does not depend on images.
> > > > > > 2) Then change CI to deal with tooling repo before dealing with
> > > images
> > > > > > repo.
> > > > > > I understand that CI details are tricky and since I'm not
> familiar
> > > with
> > > > > CI
> > > > > > in any way, I barely can make a low level design, but we do not
> need
> > > to
> > > > > fix
> > > > > > everything, just achieve 2), a change of compilation order.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <alex@porcelli.me
> >
> > > > wrote:
> > > > > >
> > > > > > > Francisco and Grabriele,
> > > > > > >
> > > > > > > You may not like or understand why the current state of the CI
> is
> > > > like
> > > > > > > that… actually has been in Red Hat and has been replicated in
> > > Apache
> > > > as
> > > > > > > used to be….
> > > > > > >
> > > > > > > But the fact is that this is the current reality.
> > > > > > >
> > > > > > > If you disagree with the current plan, please provide a
> detailed
> > > > > > > alternative so we, as community, can better evaluate the pros
> and
> > > > cons
> > > > > of
> > > > > > > each proposal.
> > > > > > >
> > > > > > >
> > > > > > > I think it’s also fair to say that, post 10 release we need to
> > > have a
> > > > > > much
> > > > > > > in depth discussion about how our codebase is organized, it’s
> clear
> > > > > that
> > > > > > > it’s not working.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > As Francisco said,
> > > > > > > > I also have the impression that the "images" (if we are
> talking
> > > of
> > > > > > docker
> > > > > > > > images) should be the very last one to be built, in a
> standalone
> > > > > repo.
> > > > > > > > That way, they may "combine" artifacts that are built in
> > > different
> > > > > > repos,
> > > > > > > > regardless of the order in which those are built.
> > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools)
> maybe
> > > > could
> > > > > > > > simplify the situation a bit.
> > > > > > > > (I also think there are some statements of undisputable needs
> > > while
> > > > > > they
> > > > > > > > are, actually, just technical choices.
> > > > > > > > Anyway, this latter point is for longer, following,
> discussion.)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier
> Tirado
> > > > > Sarti
> > > > > > <
> > > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > > >
> > > > > > > > > Alex,
> > > > > > > > > There are two assumptions that deserve further discussion:
> > > > > > > > > 1) That tool has to be the last to build. why? it does not
> have
> > > > > more
> > > > > > > > sense
> > > > > > > > > to build final images after everything else has been
> built?-
> > > > > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> > > > bigger
> > > > > > than
> > > > > > > > the
> > > > > > > > > impact (long term consequences) of consolidating two
> unrelated
> > > > > piece
> > > > > > of
> > > > > > > > > software within the same repository.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > > alex@porcelli.me
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Francisco,
> > > > > > > > > >
> > > > > > > > > > This was discussed as an alternative solution, however
> it has
> > > > > major
> > > > > > > > > impact
> > > > > > > > > > on CI and there’s also the fact Tool has been always the
> last
> > > > to
> > > > > > > build
> > > > > > > > > and
> > > > > > > > > > has no Snapshot published (actually in JavaScript world
> there
> > > > is
> > > > > no
> > > > > > > > > > snapshot concept).
> > > > > > > > > >
> > > > > > > > > > So, based on our evaluation… the proposal here is the
> least
> > > > > > > disruptive
> > > > > > > > > and
> > > > > > > > > > will take less time to unblock the release.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > _____________
> > > > > > > > > > Alex Porcelli
> > > > > > > > > > http://porcelli.me
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > > Sarti <
> > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > After kie-tools, sorry. I think we are not embracing
> the
> > > fact
> > > > > > that
> > > > > > > > > > > kogito-images depend on kie-tools, because we want
> those
> > > > images
> > > > > > to
> > > > > > > > > > include
> > > > > > > > > > > tools.
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier
> Tirado
> > > > Sarti
> > > > > <
> > > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > > It can be an alternative solution to move
> > > > kn-plugin-workflow
> > > > > to
> > > > > > > > > > > > kogito-images (so there is not longer dependency from
> > > tools
> > > > > to
> > > > > > > > > images)
> > > > > > > > > > > and
> > > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > > Martinez
> > > > <
> > > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > > >>
> > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache)
> <
> > > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > > >> escribió:
> > > > > > > > > > > >>
> > > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > > alex@porcelli.me
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > > +1
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > I spent the last day or so working closely with
> > > Tiago,
> > > > > > > > exploring
> > > > > > > > > > > >> > different
> > > > > > > > > > > >> > > options and getting deeper on the impact and
> > > > evaluating
> > > > > > the
> > > > > > > > > > overall
> > > > > > > > > > > >> > release
> > > > > > > > > > > >> > > procedure steps required. I agree with the
> proposal
> > > as
> > > > > the
> > > > > > > > most
> > > > > > > > > > > >> > > viable option for unblocking the 10 release in
> the
> > > > > > > reasonable
> > > > > > > > > time
> > > > > > > > > > > >> frame.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > > >> > wrote:
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time,
> as
> > > this
> > > > > > > matter
> > > > > > > > > > > >> requires a
> > > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > > > > according
> > > > > > > to
> > > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > > > > >> > > > (
> > > > > > > > > >
> > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > > ),
> > > > > > > > > > > >> > > > many of us were working towards removing a
> > > circular
> > > > > > > > dependency
> > > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > > `kie-tools`.
> > > > > > > As
> > > > > > > > we
> > > > > > > > > > > >> > > > progressed towards a solution, we kept
> finding the
> > > > > > > circular
> > > > > > > > > > > >> dependency
> > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of
> the
> > > > > things
> > > > > > > we
> > > > > > > > > did,
> > > > > > > > > > > and
> > > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Right now, even though we started the effort
> to
> > > move
> > > > > the
> > > > > > > > > Quarkus
> > > > > > > > > > > Dev
> > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been
> able to
> > > > do
> > > > > it
> > > > > > > > yet,
> > > > > > > > > as
> > > > > > > > > > > >> we've
> > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17,
> Maven
> > > > 3.9.6,
> > > > > > and
> > > > > > > > > > Quarkus
> > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > > This
> > > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > > >> > > >
> > > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > > .
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > C | 03.
> incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > Y | 04.
> incubator-kie-kogito-images
> > > > > > > > > > > >> > > > C | 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > > >> > > > E | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/extended-services
> depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > > >> > > > * and
> > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > > depend
> > > > > > > > > > > >> on
> > > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to
> `kie-tools`,
> > > we
> > > > > > > would've
> > > > > > > > > > had:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > 03.
> incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > > >> > > > Y | 05.
> > > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > > >> > > > L | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > > >> > > > * and
> `kogito-images`/kogito-swf-devmode
> > > > > depends
> > > > > > > on
> > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > > > > `kie-tools`,
> > > > > > > > we
> > > > > > > > > > > >> would've
> > > > > > > > > > > >> > > > had:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 01.
> incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > 03.
> incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > 04.
> incubator-kie-kogito-images
> > > > > > > > > > > >> > > > C |==> 05.
> > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > > >> > > > C | 06.
> > > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > > >> > > > E
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > > depends
> > > > on
> > > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > > >> > > > * and `kogito-serverless-operator`
> depends
> > > > on
> > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Clearly, we have a much bigger problem than a
> > > simple
> > > > > > > > circular
> > > > > > > > > > > >> > dependency.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > After multiple conversations with a lot of
> people,
> > > > > it's
> > > > > > > been
> > > > > > > > > > > really
> > > > > > > > > > > >> > > > hard coming up with a simple solution that
> makes
> > > it
> > > > > > > possible
> > > > > > > > > to
> > > > > > > > > > > >> build
> > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving the
> way
> > > > > > everyone
> > > > > > > is
> > > > > > > > > > used
> > > > > > > > > > > to
> > > > > > > > > > > >> > > > contributing to the multiple repositories we
> have.
> > > > > More
> > > > > > > than
> > > > > > > > > > that,
> > > > > > > > > > > >> > > > while making this assessment, I found more
> > > problems
> > > > > > that,
> > > > > > > in
> > > > > > > > > my
> > > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > In light of that difficulty, I'm coming
> forward
> > > with
> > > > > my
> > > > > > > > > proposal
> > > > > > > > > > > for
> > > > > > > > > > > >> > > > the Apache KIE release process, so we can use
> > > > Apache's
> > > > > > > > > > mechanisms
> > > > > > > > > > > to
> > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about
> this
> > > > really
> > > > > > > > > > complicated
> > > > > > > > > > > >> > > > matter.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > > current
> > > > > > > > situation
> > > > > > > > > > of
> > > > > > > > > > > >> our
> > > > > > > > > > > >> > > > codebase, as well as problems I can currently
> see.
> > > > > I'll
> > > > > > > > start
> > > > > > > > > > with
> > > > > > > > > > > >> an
> > > > > > > > > > > >> > > > analysis of the repositories and their
> purposes,
> > > > point
> > > > > > out
> > > > > > > > > some
> > > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > > release,
> > > > > > > explain
> > > > > > > > > my
> > > > > > > > > > > >> > > > proposal and discuss some consequences to
> what I'm
> > > > > > > > proposing.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @
> `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > > `main`
> > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> > > > `0.0.0`
> > > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > > >> > > > (Issues only, README should be updated @
> > > `main`.
> > > > > > Same
> > > > > > > > for
> > > > > > > > > > > GitHub
> > > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy at
> the
> > > > > `main`
> > > > > > > > > branch.)
> > > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > > > > `deploy`
> > > > > > to
> > > > > > > > > > update
> > > > > > > > > > > >> the
> > > > > > > > > > > >> > > > website.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > > >> > > > (GitHub pages used to host
> sandbox.kie.org
> > > and
> > > > > KIE
> > > > > > > > Tools'
> > > > > > > > > > > >> Chrome
> > > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > > > > >> > > > (Same as above, but for manual sanity
> checks
> > > > > during
> > > > > > > the
> > > > > > > > > > > staging
> > > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I grouped the repositories by category, and
> listed
> > > > > them
> > > > > > > in a
> > > > > > > > > > > >> > > > topological order. Keep in mind that when
> > > flattening
> > > > > > out a
> > > > > > > > > tree,
> > > > > > > > > > > >> there
> > > > > > > > > > > >> > > > are multiple possibilities. For example,
> > > OptaPlanner
> > > > > > > > could've
> > > > > > > > > > been
> > > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category A repos are what I've been referring
> to
> > > as
> > > > > > > `drools`
> > > > > > > > > and
> > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is
> inside
> > > > > that
> > > > > > > > > stream,
> > > > > > > > > > as
> > > > > > > > > > > >> the
> > > > > > > > > > > >> > > > way these repositories reference each other
> are
> > > > > through
> > > > > > > > Maven
> > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > > > > version.
> > > > > > > This
> > > > > > > > > > > >> mechanism
> > > > > > > > > > > >> > > > is well-known to the team, and although
> flawed for
> > > > > > > intra-day
> > > > > > > > > > > builds
> > > > > > > > > > > >> > > > and disruptive for people in many different
> time
> > > > > zones,
> > > > > > it
> > > > > > > > is
> > > > > > > > > > > >> already
> > > > > > > > > > > >> > > > very comfortable for everyone to work with, I
> > > > assume.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Contributions made to Category A have some
> > > dedicated
> > > > > > > > > pipelines,
> > > > > > > > > > > >> which
> > > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > > cross-repo
> > > > > > PRs
> > > > > > > > > > > together
> > > > > > > > > > > >> > > > and verify that the codebase will continue
> working
> > > > as
> > > > > > > > expected
> > > > > > > > > > > after
> > > > > > > > > > > >> > > > they're all merged. From what I could gather,
> > > there
> > > > > are
> > > > > > > some
> > > > > > > > > > > >> > > > "sub-streams" currently configured for
> cross-repo
> > > > PRs.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > > kogito-examples
> > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > > >> > > > - kogito-images, and
> kogito-serverless-operator
> > > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > > > > combination
> > > > > > > of
> > > > > > > > > > repos
> > > > > > > > > > > >> > > > that are not part of the same "sub-stream"
> cannot
> > > be
> > > > > > > > verified
> > > > > > > > > > > before
> > > > > > > > > > > >> > > > merging, making our contribution model
> dependent
> > > on
> > > > > > > > individual
> > > > > > > > > > > >> > > > contributors building stuff on their machines
> to
> > > > > verify
> > > > > > > that
> > > > > > > > > it
> > > > > > > > > > > >> works.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > > >> > > > ,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > > >> > > > ,
> > > > > > > > > > > >> > > > and
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > > >> > > > .
> > > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > > pipelines,
> > > > > so
> > > > > > > > > please
> > > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category B repos are what I've been referring
> to
> > > as
> > > > > > > > > `kie-tools`
> > > > > > > > > > > >> > > > stream. The first repo there is a template
> > > > repository
> > > > > > that
> > > > > > > > is
> > > > > > > > > > used
> > > > > > > > > > > >> by
> > > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > > Sandbox,
> > > > > > > > similar
> > > > > > > > > > to a
> > > > > > > > > > > >> > > > Maven archetype, if you will. The other one
> is the
> > > > KIE
> > > > > > > Tools
> > > > > > > > > > > >> monorepo,
> > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > > system.
> > > > > > > > > Currently,
> > > > > > > > > > > KIE
> > > > > > > > > > > >> > > > Tools hosts Java libraries and apps,
> TypeScript
> > > > > > libraries
> > > > > > > > and
> > > > > > > > > > > apps,
> > > > > > > > > > > >> Go
> > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > > `kie-tools`
> > > > > > > > monorepo
> > > > > > > > > > is
> > > > > > > > > > > >> > > > configured to work with sparse checkouts and
> can
> > > do
> > > > > > > partial
> > > > > > > > > > > builds.
> > > > > > > > > > > >> > > > Category B repos refer to Category A repos
> through
> > > > > > > > timestamped
> > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > > > > introduced
> > > > > > > > that
> > > > > > > > > > > will
> > > > > > > > > > > >> > > > build and publish immutable, persistent
> artifacts
> > > > > under
> > > > > > a
> > > > > > > > > > version
> > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > > published
> > > > > > > weekly
> > > > > > > > > > every
> > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > > evolution
> > > > > to
> > > > > > > the
> > > > > > > > > > Kogito
> > > > > > > > > > > >> > > > releases, as we're now targeting one release
> for
> > > all
> > > > > of
> > > > > > > > Apache
> > > > > > > > > > > KIE,
> > > > > > > > > > > >> so
> > > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > An important note here is that Category B
> > > > repositories
> > > > > > > have
> > > > > > > > > been
> > > > > > > > > > > >> > > > historically kept out of any automations we
> used
> > > to
> > > > > > have,
> > > > > > > > way
> > > > > > > > > > back
> > > > > > > > > > > >> > > > when Kogito started and we had the Business
> > > Central
> > > > > > > (a.k.a.
> > > > > > > > > v7)
> > > > > > > > > > > >> stream
> > > > > > > > > > > >> > > > still going on. For this reason, Category B
> > > projects
> > > > > > have
> > > > > > > > > > > developed
> > > > > > > > > > > >> > > > their own automations, based on GitHub
> Actions.
> > > > > > Category B
> > > > > > > > > repos
> > > > > > > > > > > >> have
> > > > > > > > > > > >> > > > always depended on Category A repos using
> fixed
> > > > > > versions.
> > > > > > > If
> > > > > > > > > > > >> Category
> > > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > > breaking
> > > > > > > changes
> > > > > > > > > on
> > > > > > > > > > > >> > > > Category A repositories would've had the
> potential
> > > > to
> > > > > > > break
> > > > > > > > > > > >> Category B
> > > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > > development
> > > > > > > > stream,
> > > > > > > > > > and
> > > > > > > > > > > >> > > > introducing unpleasant surprises for
> maintainers
> > > of
> > > > > > > > Category B
> > > > > > > > > > > >> repos,
> > > > > > > > > > > >> > > > as historically Category A contributors were
> not
> > > > > > familiar
> > > > > > > > with
> > > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Contributions made to Category B repos go
> through
> > > a
> > > > > > GitHub
> > > > > > > > > > Actions
> > > > > > > > > > > >> > > > workflow that builds the relevant part of the
> > > > > > `kie-tools`
> > > > > > > > > > monorepo
> > > > > > > > > > > >> for
> > > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > > pipeline
> > > > > > > itself
> > > > > > > > > are
> > > > > > > > > > > also
> > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do
> things
> > > > > like
> > > > > > > > > > atomically
> > > > > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > > > > importantly,
> > > > > > > > it
> > > > > > > > > > > >> allows
> > > > > > > > > > > >> > > > us to upgrade the repository to a new
> timestamped
> > > > > > SNAPSHOT
> > > > > > > > > > > together
> > > > > > > > > > > >> > > > with the changes necessary to make it stay
> green.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This setup, however, makes it impossible to
> have
> > > > > > > cross-repo
> > > > > > > > > PRs
> > > > > > > > > > > >> > > > involving Category A and Category B
> > > simultaneously,
> > > > > with
> > > > > > > the
> > > > > > > > > > > current
> > > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category C repos are kind of floating around,
> and
> > > > I'm
> > > > > > not
> > > > > > > > sure
> > > > > > > > > > if
> > > > > > > > > > > >> > > > there's much activity going on there.
> Regardless,
> > > as
> > > > > > > they're
> > > > > > > > > > part
> > > > > > > > > > > of
> > > > > > > > > > > >> > > > Apache KIE, they will be part of our release,
> so I
> > > > > > listed
> > > > > > > > them
> > > > > > > > > > for
> > > > > > > > > > > >> us
> > > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category D is self explanatory. There's only
> one
> > > > repo
> > > > > > that
> > > > > > > > has
> > > > > > > > > > > >> already
> > > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Category E are repos that do not host code
> > > directly,
> > > > > and
> > > > > > > are
> > > > > > > > > > > either
> > > > > > > > > > > >> > > > organizational entities, or host websites,
> that
> > > > > > currently
> > > > > > > > are
> > > > > > > > > > not
> > > > > > > > > > > >> part
> > > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This lack of unification between Category A
> and
> > > > > > Category B
> > > > > > > > is,
> > > > > > > > > > > IMHO,
> > > > > > > > > > > >> > > > what allowed us to introduce the infamous
> circular
> > > > > > > > dependency
> > > > > > > > > > > >> between
> > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now
> can
> > > > > describe
> > > > > > > as
> > > > > > > > a
> > > > > > > > > > > >> circular
> > > > > > > > > > > >> > > > dependency between Category A and Category B.
> The
> > > > way
> > > > > I
> > > > > > > see
> > > > > > > > > it,
> > > > > > > > > > if
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > had a single pipeline, building everything
> from
> > > > > `drools`
> > > > > > > to
> > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > > introduced,
> > > > > > > and
> > > > > > > > we
> > > > > > > > > > > >> > > > wouldn't be having this huge problem in our
> hands
> > > > > right
> > > > > > > now.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > My proposal for the Apache KIE release process
> > > sees
> > > > > this
> > > > > > > > lack
> > > > > > > > > of
> > > > > > > > > > > >> > > > unification as a central problem, not only for
> > > this
> > > > > > > release
> > > > > > > > in
> > > > > > > > > > > >> > > > particular, but for the community as a whole.
> It
> > > is
> > > > my
> > > > > > > > belief
> > > > > > > > > > that
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > are all under the same roof, and that no
> > > > contribution
> > > > > > > should
> > > > > > > > > be
> > > > > > > > > > > >> > > > allowed to break any part of our codebase.
> With
> > > the
> > > > > > > > increasing
> > > > > > > > > > > >> volume
> > > > > > > > > > > >> > > > of code, and hopefully number of contributors
> too,
> > > > we
> > > > > > > cannot
> > > > > > > > > > keep
> > > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > > things.
> > > > > > We're
> > > > > > > > all
> > > > > > > > > > > >> humans
> > > > > > > > > > > >> > > > after all, and it is our job to have
> mechanisms in
> > > > > place
> > > > > > > to
> > > > > > > > > > > prevent
> > > > > > > > > > > >> us
> > > > > > > > > > > >> > > > from unwillingly making mistakes. Especially
> when
> > > > > these
> > > > > > > > > mistakes
> > > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > > individually,
> > > > > > > > > probably
> > > > > > > > > > > >> can't
> > > > > > > > > > > >> > > > fix.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending
> on
> > > > > > > kiegroup's
> > > > > > > > > KIE
> > > > > > > > > > > >> Tools
> > > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > > `kogito-images`
> > > > > > > > depending
> > > > > > > > > on
> > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > > kiegroup's
> > > > > > > > `lienzo`
> > > > > > > > > > and
> > > > > > > > > > > >> > > > `kie-soup` artifacts at version
> `7.59.0.Final`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps`
> depending on
> > > > > > > > kiegroup's
> > > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > > >> > > > * This module was removed from the KIE
> codebase
> > > > here:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > > >> > > >
> > > > > > > > > > >
> > > > > >
> https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > > ,
> > > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > > >> > > > * This new repo depends on Kogito and
> OptaPlanner,
> > > > > > > pointing
> > > > > > > > to
> > > > > > > > > > > older
> > > > > > > > > > > >> > > > versions.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P5.
> `incubator-kie-sandbox-quarkus-accelerator`
> > > > > > depending
> > > > > > > on
> > > > > > > > > > > Kogito
> > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > > >> > > > See:
> > > > > > > > > > > >> > > > -
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P6. Category C repos are out of date and not
> part
> > > of
> > > > > the
> > > > > > > > > > Category
> > > > > > > > > > > A
> > > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > > version
> > > > is
> > > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > > >> > > > depending on Kogito without a specific
> version,
> > > only
> > > > > by
> > > > > > > > using
> > > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version
> is
> > > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and
> OptaPlanner
> > > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow
> has
> > > its
> > > > > E2E
> > > > > > > > > disabled
> > > > > > > > > > > >> after
> > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > > solution,
> > > > > as
> > > > > > > they
> > > > > > > > > > both
> > > > > > > > > > > >> > > > suffer from the circular dependency between
> > > > Category A
> > > > > > and
> > > > > > > > > > > Category
> > > > > > > > > > > >> B.
> > > > > > > > > > > >> > > > As Category A and Category B are both streams
> that
> > > > > have
> > > > > > > been
> > > > > > > > > > > really
> > > > > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > > > > contributions
> > > > > > > > > that
> > > > > > > > > > > >> > > > cannot be done, given that Category A depends
> on
> > > > > > Category
> > > > > > > B
> > > > > > > > > > with a
> > > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be
> understood
> > > as
> > > > > > > > technical
> > > > > > > > > > > debt.
> > > > > > > > > > > >> > > > Depending on unmaintained projects is
> something
> > > > we'll
> > > > > > > always
> > > > > > > > > be
> > > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > > matter
> > > > of
> > > > > > > > making
> > > > > > > > > > them
> > > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > P7 is an isolated problem that won't impact
> the
> > > > > > structure
> > > > > > > or
> > > > > > > > > > > >> anything
> > > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > > regression
> > > > > we
> > > > > > > > > > > introduced
> > > > > > > > > > > >> > > > recently.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache
> KIE
> > > 10,
> > > > > and
> > > > > > > > that
> > > > > > > > > > P5,
> > > > > > > > > > > >> P6,
> > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems
> left to
> > > > > > discuss
> > > > > > > > are
> > > > > > > > > P1
> > > > > > > > > > > and
> > > > > > > > > > > >> > > > P2, which can't be done without a proper
> proposal.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I'll try to be very meticulous here, since
> from my
> > > > > > > > experience,
> > > > > > > > > > any
> > > > > > > > > > > >> > > > little miscalculation can lead to our release
> not
> > > > > > working
> > > > > > > > out
> > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > >> > > > end. To try and avoid that as much as
> possible,
> > > and
> > > > > make
> > > > > > > > > > > everything
> > > > > > > > > > > >> we
> > > > > > > > > > > >> > > > can to have a successful Apache KIE 10
> release,
> > > bear
> > > > > > with
> > > > > > > > me.
> > > > > > > > > > I'll
> > > > > > > > > > > >> lay
> > > > > > > > > > > >> > > > out a timeline of events that need to happen
> in
> > > > order
> > > > > > for
> > > > > > > > our
> > > > > > > > > > > >> release
> > > > > > > > > > > >> > > > to be published, with all artifacts ending up
> in
> > > the
> > > > > > right
> > > > > > > > > > places,
> > > > > > > > > > > >> but
> > > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As you saw at the beginning of this email,
> all the
> > > > > > > attempts
> > > > > > > > we
> > > > > > > > > > > made
> > > > > > > > > > > >> > > > left us with the circular dependency showing
> up
> > > at a
> > > > > > > > different
> > > > > > > > > > > >> place,
> > > > > > > > > > > >> > > > but something all these places have in common
> is
> > > > that
> > > > > > > > they're
> > > > > > > > > > all
> > > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > The first part of my proposal is the
> following:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > > Quarkus
> > > > > Dev
> > > > > > > UIs
> > > > > > > > > from
> > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > > Management
> > > > > > and
> > > > > > > > > Task
> > > > > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > images
> > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > > >> > > > S3. We move the entire
> > > `kogito-serverless-operator`
> > > > > repo
> > > > > > > > > inside
> > > > > > > > > > a
> > > > > > > > > > > >> new
> > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve
> problems
> > > P1
> > > > > and
> > > > > > > P2.
> > > > > > > > Of
> > > > > > > > > > > >> course
> > > > > > > > > > > >> > > > the rest of
> > > > > > > > > > > >>
> > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > This doesn't come without consequences, of
> course,
> > > > as
> > > > > > the
> > > > > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> > > > images,
> > > > > > and
> > > > > > > > the
> > > > > > > > > > > >> > > > `kogito-serverless-operator` would be moving
> from
> > > > > > > Category A
> > > > > > > > > to
> > > > > > > > > > > >> > > > Category B. This move would make them have to
> > > > > reference
> > > > > > > > > > Category A
> > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > > `kogito-images`
> > > > > > > > and
> > > > > > > > > > > >> > > > `kogito-serverless-operator` are already
> their own
> > > > > > > > > "sub-stream"
> > > > > > > > > > > >> inside
> > > > > > > > > > > >> > > > Category A, though, contributions made in a
> > > > cross-repo
> > > > > > > > fashion
> > > > > > > > > > to
> > > > > > > > > > > >> this
> > > > > > > > > > > >> > > > "sub-stream" will continue being possible, now
> > > via a
> > > > > > > single
> > > > > > > > PR
> > > > > > > > > > to
> > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category
> A and
> > > > > > > Category
> > > > > > > > B
> > > > > > > > > > will
> > > > > > > > > > > >> > > > continue not being possible, and a 1-week
> delay
> > > > > between
> > > > > > > > > merging
> > > > > > > > > > > >> > > > something on Category A and using it on
> Category B
> > > > > will
> > > > > > > > still
> > > > > > > > > > > >> happen.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`,
> however,
> > > > does
> > > > > > > allow
> > > > > > > > > for
> > > > > > > > > > > >> sparse
> > > > > > > > > > > >> > > > checkouts and partial builds, so working with
> a
> > > > subset
> > > > > > of
> > > > > > > > the
> > > > > > > > > > > >> monorepo
> > > > > > > > > > > >> > > > is possible and encouraged. Making changes
> only to
> > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example,
> will
> > > > have
> > > > > > the
> > > > > > > PR
> > > > > > > > > > > checks
> > > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > > >> > > > .
> > > > > > > > > > > >> > > > We're not compromising when running partial
> builds
> > > > > too.
> > > > > > We
> > > > > > > > > know
> > > > > > > > > > > that
> > > > > > > > > > > >> > > > the entire repo will continue working even
> after
> > > > only
> > > > > > > > > building a
> > > > > > > > > > > >> small
> > > > > > > > > > > >> > > > subset of the changes. Doing partial or full
> > > builds
> > > > is
> > > > > > > > > > > automatically
> > > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Keep in mind that, even though I'm proposing
> we
> > > > move a
> > > > > > > bunch
> > > > > > > > > of
> > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see this
> as a
> > > > > > > TEMPORARY
> > > > > > > > > > > >> solution
> > > > > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > > > > additional
> > > > > > > > stuff
> > > > > > > > > > > >> > > > TEMPORARILY so that we can release and
> continue
> > > > moving
> > > > > > > > > forward.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> > > became a
> > > > > > > > polyglot
> > > > > > > > > > > >> monorepo
> > > > > > > > > > > >> > > > out of necessity, and although I'm really
> proud of
> > > > > what
> > > > > > we
> > > > > > > > > > > achieved
> > > > > > > > > > > >> > > > there so far, I don't think `kie-tools` has a
> > > setup
> > > > > that
> > > > > > > is
> > > > > > > > > > > suitable
> > > > > > > > > > > >> > > > for all the different nuances that compose our
> > > > > > community.
> > > > > > > > I'm
> > > > > > > > > > well
> > > > > > > > > > > >> > > > aware that a polyglot monorepo that does not
> > > follow
> > > > > > > > widespread
> > > > > > > > > > > >> > > > conventions will scare some people away, and
> as
> > > much
> > > > > as
> > > > > > > > we've
> > > > > > > > > > > tried
> > > > > > > > > > > >> to
> > > > > > > > > > > >> > > > make build instructions clear, we can't
> always get
> > > > > past
> > > > > > > the
> > > > > > > > > > > >> prejudice
> > > > > > > > > > > >> > > > some people have towards the "front-end"
> > > ecosystem.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > With all that said, I keep thinking this is
> the
> > > best
> > > > > > > course
> > > > > > > > of
> > > > > > > > > > > >> action
> > > > > > > > > > > >> > > > for us right now. We keep most of our stuff
> > > > unchanged,
> > > > > > we
> > > > > > > > > > unblock
> > > > > > > > > > > >> the
> > > > > > > > > > > >> > > > release, and we have a working setup that will
> > > suit
> > > > us
> > > > > > > well
> > > > > > > > > > while
> > > > > > > > > > > we
> > > > > > > > > > > >> > > > discuss and reach a conclusion regarding the
> > > future
> > > > of
> > > > > > our
> > > > > > > > > > > codebase
> > > > > > > > > > > >> > > > structure.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Let me paint a quick picture here of what our
> code
> > > > > base
> > > > > > > > would
> > > > > > > > > > look
> > > > > > > > > > > >> > > > like, repository-wise, if my proposal is
> accepted:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > > >> > > > A
> incubator-kie-optaplanner-quickstarts
> > > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > B
> > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > > >> > > > E
> incubator-kie-kogito-online-staging
> > > > > > > > > > > >> > > > =====================
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > > > > >> > > > `kogito-serverless-operator` moves entirely
> inside
> > > > > > > > > `kie-tools`.
> > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images
> and
> > > > > > > > > > > >> > > > `kogito-serverless-operator` inside
> `kie-tools`,
> > > > there
> > > > > > are
> > > > > > > > no
> > > > > > > > > > > cycles
> > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can
> granularly
> > > > > build:
> > > > > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > > >> and
> > > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > > >> > > > 4. packages/sonataflow-operator (contents
> from
> > > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > The second part of the proposal is the release
> > > > process
> > > > > > > > itself,
> > > > > > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as
> > > > cutting
> > > > > > > point
> > > > > > > > > for
> > > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > > >> > > > 2. Update Category B repos to point to this
> > > > > timestamped
> > > > > > > > > > SNAPSHOT,
> > > > > > > > > > > >> and
> > > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > > >> > > > 3. At this point, with everything working, we
> can
> > > > > branch
> > > > > > > out
> > > > > > > > > to
> > > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped
> SNAPSHOT
> > > > > tag,
> > > > > > > and
> > > > > > > > > > > >> Category B
> > > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > > >> > > > 4. All Category A and Category B repos update
> > > their
> > > > > > > versions
> > > > > > > > > to
> > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > > >> > > > 5. Update Category B repos to point to
> Category A
> > > > > repos
> > > > > > > > using
> > > > > > > > > > the
> > > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > > >> > > > 6. At this point, we can vote on the release
> based
> > > > on
> > > > > > the
> > > > > > > > > > `10.0.x`
> > > > > > > > > > > >> > > > branches, given we don't expect any code
> changes
> > > > > > anymore.
> > > > > > > > > > > >> > > > 7. After voting passes, we're good to start
> the
> > > > > release
> > > > > > > > > process.
> > > > > > > > > > > >> > > > 8. Category A repos follow their
> manual/automated
> > > > > > release
> > > > > > > > > > process,
> > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed
> to
> > > Git,
> > > > > and
> > > > > > > > built
> > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > >> > > > 9. We wait a little bit for Category A
> artifacts
> > > to
> > > > be
> > > > > > > > > > propagated
> > > > > > > > > > > on
> > > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > > >> > > > 10. Category B repos follow their
> manual/automated
> > > > > > release
> > > > > > > > > > > process,
> > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed
> to
> > > Git,
> > > > > and
> > > > > > > > built
> > > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > > >> > > > 12. Category E repos can be manually tagged
> with
> > > > > 10.0.0
> > > > > > > from
> > > > > > > > > > their
> > > > > > > > > > > >> > > > default branches.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > More needs to be discussed if we're planning
> to
> > > > > maintain
> > > > > > > > > > multiple
> > > > > > > > > > > >> > > > release streams in parallel, but I guess it
> can
> > > wait
> > > > > for
> > > > > > > > after
> > > > > > > > > > > >> Apache
> > > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Thank you for reading, and I'm looking
> forward to
> > > > > > hearing
> > > > > > > > back
> > > > > > > > > > > from
> > > > > > > > > > > >> > > > everyone.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Of course, alternative solutions are possible.
> > > This
> > > > > > email,
> > > > > > > > > > > however,
> > > > > > > > > > > >> > > > summarizes my view of how we should attack the
> > > > > problem,
> > > > > > > > > > > considering
> > > > > > > > > > > >> > > > disruption, required effort, the release
> process
> > > > > itself,
> > > > > > > and
> > > > > > > > > > > >> history.
> > > > > > > > > > > >> > > > Feel free to propose alternatives. This is
> not a
> > > > > voting
> > > > > > > > > thread.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Regards,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >>
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > > dev-help@kie.apache.org
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Tiago Bento <ti...@apache.org>.
Glad to see the interest this proposal has gotten, and it's good to
see some alternatives being drafted here, although still lacking clear
definitions and analysis in regards to disruption, required effort,
the release process itself, and history. Of course, lots of details
and clarity on the execution part would be missing too.
As of this moment, based on what I read here, I'm assuming that
everyone who participated so far doesn't see the initial proposal as
problematic in terms of feasibility, but some of you have a preference
not to go with it, because it is "wrong", and apparently because it
would "jeopardize the evolution of the project". Reading these last
words made me a little sad, to be honest. But I can deal with it :)
Please let's try and keep the discussion as objective as possible.
"Right" and "wrong" are too subjective for this kind of conversation.
Now, being practical, unless there are clear arguments based on facts
and objective concepts that invalidate the initial proposal shared on
this email, it seems to me that it is currently the only viable
proposal we have for unblocking and releasing Apache KIE 10. Of
course, if we end up seeing an alternative proposal with enough
details and a clear execution plan, I think then we'll be in a very
good position to choose from multiple options!
On Wed, Mar 13, 2024 at 8:36 AM Alex Porcelli <al...@porcelli.me> wrote:
>
> Francisco and Gabriele,
>
> I understand and acknowledge your desire to find the “right” solution
> instead to work on a temporary “patch” - however without a detailed
> proposal I don’t think we can properly evaluate the impact of your
> suggestion.
>
> When I spoke with different SMEs that included tools and CI, the
> guesstimate for making the necessary changes on CI and codebase to
> basically have images and operators in the end of the build chain is
> something like 2 months of effort. Another impact that needs to be
> discussed is that KIE Tools repo had to be injected in the middle of all
> pipelines - forcing all PR checks and nightlies to build all repos (PR
> checks will likely take 12+ hours… I even heard that it could be even 24
> hours).
>
> Based on the input above, I think it’s quite risk to move in such direction
> without a more detailed plan… because 2 months could be turned easily in 6!
> And this is exactly what happened when we guessed that moving to Apache
> would take no more than 3 months. But here we are.
>
> I really strongly suggest that we focus on a release that could be
> achievable in less than a month from now, and we - after release - have a
> in depth discussion about the overall codebase and ci organization.
>
>
> On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <ga...@gmail.com>
> wrote:
>
> > Alex,
> > my suggestion is to move the building of all docker images, from whatever
> > repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> > invoked after all the others.
> > I'm not sure if this would solve all the issues, and since I could not
> > enter in the details of all the involved code, my suggestion may be too
> > naive.
> > Having spent almost all of the last year in CI, I may say that, at least
> > for the kie-tools repo, removing the image build step from it should not be
> > too difficult (since it is an issue we already faced and solved).
> > If, with "detailed proposal", you mean a complete list of all modules to be
> > moved and dependency refactoring, of course I can not provide it right now.
> >
> > Anyway, I share the concern from Francisco: undoing something is almost
> > always harder than doing it "rightly" from scratch...
> >
> >
> >
> >
> > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti <
> > ftirados@redhat.com> ha scritto:
> >
> > > I do not think estimations should be the only driver to make a decision,
> > > especially when the current proposal is conceptually incompatible with
> > the
> > > multi repo approach that is taken elsewhere in the project.
> > > Given my knowledge of the CI it is nearly impossible for me to give a
> > fair
> > > estimate of how much it might take to achieve step 2) of my previous
> > e-mail
> > > . It might take a while or it might be pretty easy after all, I don't
> > > really know, but I think it will be a good idea if some of the experts
> > on
> > > CI in the team (the ones that set up the pipeline, which was a huge
> > > achievement) give an estimate, not me. Estimating how much it takes to
> > > merge two existing repos (without altering CI) is easier, but it does not
> > > mean we are doing the right thing.
> > > My main concern is that it will be very difficult for me to explain to
> > > someone that arrives new to the team, that having experts on CI on the
> > > team, we decided to merge two repos (once merged, it would be rather
> > > difficult to unmerge) rather than fix the CI, because of expediency.
> > >
> > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> > > wrote:
> > >
> > > > Francisco,
> > > >
> > > > Please take the time to make the more in depth analysis needed and
> > > provide
> > > > a more detailed plan… so we - as community- can evaluate the size of
> > the
> > > > effort. In the conceptual level you shared it’s near impossible to
> > > estimate
> > > > the size of the effort and compare with the current proposal.
> > > >
> > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > > ftirados@redhat.com> wrote:
> > > >
> > > > > I think I already did a high level proposal.
> > > > > 1) Remove all dependencies from tooling to images, so images depend
> > on
> > > > > tooling but tooling does not depend on images.
> > > > > 2) Then change CI to deal with tooling repo before dealing with
> > images
> > > > > repo.
> > > > > I understand that CI details are tricky and since I'm not familiar
> > with
> > > > CI
> > > > > in any way, I barely can make a low level design, but we do not need
> > to
> > > > fix
> > > > > everything, just achieve 2), a change of compilation order.
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > >
> > > > > > Francisco and Grabriele,
> > > > > >
> > > > > > You may not like or understand why the current state of the CI is
> > > like
> > > > > > that… actually has been in Red Hat and has been replicated in
> > Apache
> > > as
> > > > > > used to be….
> > > > > >
> > > > > > But the fact is that this is the current reality.
> > > > > >
> > > > > > If you disagree with the current plan, please provide a detailed
> > > > > > alternative so we, as community, can better evaluate the pros and
> > > cons
> > > > of
> > > > > > each proposal.
> > > > > >
> > > > > >
> > > > > > I think it’s also fair to say that, post 10 release we need to
> > have a
> > > > > much
> > > > > > in depth discussion about how our codebase is organized, it’s clear
> > > > that
> > > > > > it’s not working.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > > gabriele.cardosi@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > As Francisco said,
> > > > > > > I also have the impression that the "images" (if we are talking
> > of
> > > > > docker
> > > > > > > images) should be the very last one to be built, in a standalone
> > > > repo.
> > > > > > > That way, they may "combine" artifacts that are built in
> > different
> > > > > repos,
> > > > > > > regardless of the order in which those are built.
> > > > > > > Moving them out of all the repos (kogito-apps/kie-tools) maybe
> > > could
> > > > > > > simplify the situation a bit.
> > > > > > > (I also think there are some statements of undisputable needs
> > while
> > > > > they
> > > > > > > are, actually, just technical choices.
> > > > > > > Anyway, this latter point is for longer, following, discussion.)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier Tirado
> > > > Sarti
> > > > > <
> > > > > > > ftirados@redhat.com> ha scritto:
> > > > > > >
> > > > > > > > Alex,
> > > > > > > > There are two assumptions that deserve further discussion:
> > > > > > > > 1) That tool has to be the last to build. why? it does not have
> > > > more
> > > > > > > sense
> > > > > > > > to build final images after everything else has been built?-
> > > > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> > > bigger
> > > > > than
> > > > > > > the
> > > > > > > > impact (long term consequences) of consolidating two unrelated
> > > > piece
> > > > > of
> > > > > > > > software within the same repository.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> > alex@porcelli.me
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Francisco,
> > > > > > > > >
> > > > > > > > > This was discussed as an alternative solution, however it has
> > > > major
> > > > > > > > impact
> > > > > > > > > on CI and there’s also the fact Tool has been always the last
> > > to
> > > > > > build
> > > > > > > > and
> > > > > > > > > has no Snapshot published (actually in JavaScript world there
> > > is
> > > > no
> > > > > > > > > snapshot concept).
> > > > > > > > >
> > > > > > > > > So, based on our evaluation… the proposal here is the least
> > > > > > disruptive
> > > > > > > > and
> > > > > > > > > will take less time to unblock the release.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > _____________
> > > > > > > > > Alex Porcelli
> > > > > > > > > http://porcelli.me
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> > Sarti <
> > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > > After kie-tools, sorry. I think we are not embracing the
> > fact
> > > > > that
> > > > > > > > > > kogito-images depend on kie-tools, because we want those
> > > images
> > > > > to
> > > > > > > > > include
> > > > > > > > > > tools.
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado
> > > Sarti
> > > > <
> > > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Tiago,
> > > > > > > > > > > It can be an alternative solution to move
> > > kn-plugin-workflow
> > > > to
> > > > > > > > > > > kogito-images (so there is not longer dependency from
> > tools
> > > > to
> > > > > > > > images)
> > > > > > > > > > and
> > > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> > Martinez
> > > <
> > > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > >> +1 to unblock release
> > > > > > > > > > >>
> > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > > > > > > > > > pefernan@apache.org>
> > > > > > > > > > >> escribió:
> > > > > > > > > > >>
> > > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > > alex@porcelli.me
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > > +1
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I spent the last day or so working closely with
> > Tiago,
> > > > > > > exploring
> > > > > > > > > > >> > different
> > > > > > > > > > >> > > options and getting deeper on the impact and
> > > evaluating
> > > > > the
> > > > > > > > > overall
> > > > > > > > > > >> > release
> > > > > > > > > > >> > > procedure steps required. I agree with the proposal
> > as
> > > > the
> > > > > > > most
> > > > > > > > > > >> > > viable option for unblocking the 10 release in the
> > > > > > reasonable
> > > > > > > > time
> > > > > > > > > > >> frame.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > > tiagobento@apache.org>
> > > > > > > > > > >> > wrote:
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time, as
> > this
> > > > > > matter
> > > > > > > > > > >> requires a
> > > > > > > > > > >> > > > lot of context.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > > > according
> > > > > > to
> > > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > > > >> > > > (
> > > > > > > > >
> > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > > ),
> > > > > > > > > > >> > > > many of us were working towards removing a
> > circular
> > > > > > > dependency
> > > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > > `kie-tools`.
> > > > > > As
> > > > > > > we
> > > > > > > > > > >> > > > progressed towards a solution, we kept finding the
> > > > > > circular
> > > > > > > > > > >> dependency
> > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of the
> > > > things
> > > > > > we
> > > > > > > > did,
> > > > > > > > > > and
> > > > > > > > > > >> > > > the results we had.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Right now, even though we started the effort to
> > move
> > > > the
> > > > > > > > Quarkus
> > > > > > > > > > Dev
> > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been able to
> > > do
> > > > it
> > > > > > > yet,
> > > > > > > > as
> > > > > > > > > > >> we've
> > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17, Maven
> > > 3.9.6,
> > > > > and
> > > > > > > > > Quarkus
> > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > > This
> > > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > > >> > > >
> > > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > > .
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > > >> > > > C | 03. incubator-kie-kogito-examples
> > > > > > > > > > >> > > > Y | 04. incubator-kie-kogito-images
> > > > > > > > > > >> > > > C | 05.
> > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > >> > > > L | ==========================
> > > > > > > > > > >> > > > E | 06.
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * As `kie-tools`/extended-services depends
> > > on
> > > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > > >> > > > * and
> > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > > depend
> > > > > > > > > > >> on
> > > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`,
> > we
> > > > > > would've
> > > > > > > > > had:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > > >> > > > Y | 05.
> > > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > >> > > > C | =====================
> > > > > > > > > > >> > > > L | 06.
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > depends
> > > on
> > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > > >> > > > * and `kogito-images`/kogito-swf-devmode
> > > > depends
> > > > > > on
> > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > > > `kie-tools`,
> > > > > > > we
> > > > > > > > > > >> would've
> > > > > > > > > > >> > > > had:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > > > > > > >> > > > 04. incubator-kie-kogito-images
> > > > > > > > > > >> > > > C |==> 05.
> > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > > >> > > > Y | =====================
> > > > > > > > > > >> > > > C | 06.
> > > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > > >> > > > E
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> > depends
> > > on
> > > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > > >> > > > * and `kogito-serverless-operator` depends
> > > on
> > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Clearly, we have a much bigger problem than a
> > simple
> > > > > > > circular
> > > > > > > > > > >> > dependency.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > After multiple conversations with a lot of people,
> > > > it's
> > > > > > been
> > > > > > > > > > really
> > > > > > > > > > >> > > > hard coming up with a simple solution that makes
> > it
> > > > > > possible
> > > > > > > > to
> > > > > > > > > > >> build
> > > > > > > > > > >> > > > Apache KIE in one shot, while preserving the way
> > > > > everyone
> > > > > > is
> > > > > > > > > used
> > > > > > > > > > to
> > > > > > > > > > >> > > > contributing to the multiple repositories we have.
> > > > More
> > > > > > than
> > > > > > > > > that,
> > > > > > > > > > >> > > > while making this assessment, I found more
> > problems
> > > > > that,
> > > > > > in
> > > > > > > > my
> > > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > In light of that difficulty, I'm coming forward
> > with
> > > > my
> > > > > > > > proposal
> > > > > > > > > > for
> > > > > > > > > > >> > > > the Apache KIE release process, so we can use
> > > Apache's
> > > > > > > > > mechanisms
> > > > > > > > > > to
> > > > > > > > > > >> > > > have a slower-paced, in-depth debate about this
> > > really
> > > > > > > > > complicated
> > > > > > > > > > >> > > > matter.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I'll lay out my entire perspective about the
> > current
> > > > > > > situation
> > > > > > > > > of
> > > > > > > > > > >> our
> > > > > > > > > > >> > > > codebase, as well as problems I can currently see.
> > > > I'll
> > > > > > > start
> > > > > > > > > with
> > > > > > > > > > >> an
> > > > > > > > > > >> > > > analysis of the repositories and their purposes,
> > > point
> > > > > out
> > > > > > > > some
> > > > > > > > > > >> > > > problems that I believe are blocking our 10
> > release,
> > > > > > explain
> > > > > > > > my
> > > > > > > > > > >> > > > proposal and discuss some consequences to what I'm
> > > > > > > proposing.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Let's begin.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> > `main`
> > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> > > `0.0.0`
> > > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > > >> > > > (Issues only, README should be updated @
> > `main`.
> > > > > Same
> > > > > > > for
> > > > > > > > > > GitHub
> > > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > > >> > > > (The Kogito website. Develop & deploy at the
> > > > `main`
> > > > > > > > branch.)
> > > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > > > `deploy`
> > > > > to
> > > > > > > > > update
> > > > > > > > > > >> the
> > > > > > > > > > >> > > > website.)
> > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > > >> > > > (GitHub pages used to host sandbox.kie.org
> > and
> > > > KIE
> > > > > > > Tools'
> > > > > > > > > > >> Chrome
> > > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > > > >> > > > (Same as above, but for manual sanity checks
> > > > during
> > > > > > the
> > > > > > > > > > staging
> > > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I grouped the repositories by category, and listed
> > > > them
> > > > > > in a
> > > > > > > > > > >> > > > topological order. Keep in mind that when
> > flattening
> > > > > out a
> > > > > > > > tree,
> > > > > > > > > > >> there
> > > > > > > > > > >> > > > are multiple possibilities. For example,
> > OptaPlanner
> > > > > > > could've
> > > > > > > > > been
> > > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category A repos are what I've been referring to
> > as
> > > > > > `drools`
> > > > > > > > and
> > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is inside
> > > > that
> > > > > > > > stream,
> > > > > > > > > as
> > > > > > > > > > >> the
> > > > > > > > > > >> > > > way these repositories reference each other are
> > > > through
> > > > > > > Maven
> > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > > > version.
> > > > > > This
> > > > > > > > > > >> mechanism
> > > > > > > > > > >> > > > is well-known to the team, and although flawed for
> > > > > > intra-day
> > > > > > > > > > builds
> > > > > > > > > > >> > > > and disruptive for people in many different time
> > > > zones,
> > > > > it
> > > > > > > is
> > > > > > > > > > >> already
> > > > > > > > > > >> > > > very comfortable for everyone to work with, I
> > > assume.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Contributions made to Category A have some
> > dedicated
> > > > > > > > pipelines,
> > > > > > > > > > >> which
> > > > > > > > > > >> > > > are, at least to some extent, able to build
> > > cross-repo
> > > > > PRs
> > > > > > > > > > together
> > > > > > > > > > >> > > > and verify that the codebase will continue working
> > > as
> > > > > > > expected
> > > > > > > > > > after
> > > > > > > > > > >> > > > they're all merged. From what I could gather,
> > there
> > > > are
> > > > > > some
> > > > > > > > > > >> > > > "sub-streams" currently configured for cross-repo
> > > PRs.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > > kogito-examples
> > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > > >> > > > - kogito-images, and kogito-serverless-operator
> > > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > > >> > > > - kie-docs
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > > > combination
> > > > > > of
> > > > > > > > > repos
> > > > > > > > > > >> > > > that are not part of the same "sub-stream" cannot
> > be
> > > > > > > verified
> > > > > > > > > > before
> > > > > > > > > > >> > > > merging, making our contribution model dependent
> > on
> > > > > > > individual
> > > > > > > > > > >> > > > contributors building stuff on their machines to
> > > > verify
> > > > > > that
> > > > > > > > it
> > > > > > > > > > >> works.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > > >> > > > ,
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > > >> > > > ,
> > > > > > > > > > >> > > > and
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > > >> > > > .
> > > > > > > > > > >> > > > Note that I'm not that familiar with these
> > > pipelines,
> > > > so
> > > > > > > > please
> > > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category B repos are what I've been referring to
> > as
> > > > > > > > `kie-tools`
> > > > > > > > > > >> > > > stream. The first repo there is a template
> > > repository
> > > > > that
> > > > > > > is
> > > > > > > > > used
> > > > > > > > > > >> by
> > > > > > > > > > >> > > > people starting projects from scratch on KIE
> > > Sandbox,
> > > > > > > similar
> > > > > > > > > to a
> > > > > > > > > > >> > > > Maven archetype, if you will. The other one is the
> > > KIE
> > > > > > Tools
> > > > > > > > > > >> monorepo,
> > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> > system.
> > > > > > > > Currently,
> > > > > > > > > > KIE
> > > > > > > > > > >> > > > Tools hosts Java libraries and apps, TypeScript
> > > > > libraries
> > > > > > > and
> > > > > > > > > > apps,
> > > > > > > > > > >> Go
> > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > > `kie-tools`
> > > > > > > monorepo
> > > > > > > > > is
> > > > > > > > > > >> > > > configured to work with sparse checkouts and can
> > do
> > > > > > partial
> > > > > > > > > > builds.
> > > > > > > > > > >> > > > Category B repos refer to Category A repos through
> > > > > > > timestamped
> > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > > > introduced
> > > > > > > that
> > > > > > > > > > will
> > > > > > > > > > >> > > > build and publish immutable, persistent artifacts
> > > > under
> > > > > a
> > > > > > > > > version
> > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > > published
> > > > > > weekly
> > > > > > > > > every
> > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> > evolution
> > > > to
> > > > > > the
> > > > > > > > > Kogito
> > > > > > > > > > >> > > > releases, as we're now targeting one release for
> > all
> > > > of
> > > > > > > Apache
> > > > > > > > > > KIE,
> > > > > > > > > > >> so
> > > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > An important note here is that Category B
> > > repositories
> > > > > > have
> > > > > > > > been
> > > > > > > > > > >> > > > historically kept out of any automations we used
> > to
> > > > > have,
> > > > > > > way
> > > > > > > > > back
> > > > > > > > > > >> > > > when Kogito started and we had the Business
> > Central
> > > > > > (a.k.a.
> > > > > > > > v7)
> > > > > > > > > > >> stream
> > > > > > > > > > >> > > > still going on. For this reason, Category B
> > projects
> > > > > have
> > > > > > > > > > developed
> > > > > > > > > > >> > > > their own automations, based on GitHub Actions.
> > > > > Category B
> > > > > > > > repos
> > > > > > > > > > >> have
> > > > > > > > > > >> > > > always depended on Category A repos using fixed
> > > > > versions.
> > > > > > If
> > > > > > > > > > >> Category
> > > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> > breaking
> > > > > > changes
> > > > > > > > on
> > > > > > > > > > >> > > > Category A repositories would've had the potential
> > > to
> > > > > > break
> > > > > > > > > > >> Category B
> > > > > > > > > > >> > > > silently, leaving Category B with a broken
> > > development
> > > > > > > stream,
> > > > > > > > > and
> > > > > > > > > > >> > > > introducing unpleasant surprises for maintainers
> > of
> > > > > > > Category B
> > > > > > > > > > >> repos,
> > > > > > > > > > >> > > > as historically Category A contributors were not
> > > > > familiar
> > > > > > > with
> > > > > > > > > > >> > > > Category B repos.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Contributions made to Category B repos go through
> > a
> > > > > GitHub
> > > > > > > > > Actions
> > > > > > > > > > >> > > > workflow that builds the relevant part of the
> > > > > `kie-tools`
> > > > > > > > > monorepo
> > > > > > > > > > >> for
> > > > > > > > > > >> > > > the changes introduced. Changes made to the
> > pipeline
> > > > > > itself
> > > > > > > > are
> > > > > > > > > > also
> > > > > > > > > > >> > > > picked up as part of PRs, allowing us to do things
> > > > like
> > > > > > > > > atomically
> > > > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > > > importantly,
> > > > > > > it
> > > > > > > > > > >> allows
> > > > > > > > > > >> > > > us to upgrade the repository to a new timestamped
> > > > > SNAPSHOT
> > > > > > > > > > together
> > > > > > > > > > >> > > > with the changes necessary to make it stay green.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This setup, however, makes it impossible to have
> > > > > > cross-repo
> > > > > > > > PRs
> > > > > > > > > > >> > > > involving Category A and Category B
> > simultaneously,
> > > > with
> > > > > > the
> > > > > > > > > > current
> > > > > > > > > > >> > > > automations we have.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category C repos are kind of floating around, and
> > > I'm
> > > > > not
> > > > > > > sure
> > > > > > > > > if
> > > > > > > > > > >> > > > there's much activity going on there. Regardless,
> > as
> > > > > > they're
> > > > > > > > > part
> > > > > > > > > > of
> > > > > > > > > > >> > > > Apache KIE, they will be part of our release, so I
> > > > > listed
> > > > > > > them
> > > > > > > > > for
> > > > > > > > > > >> us
> > > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category D is self explanatory. There's only one
> > > repo
> > > > > that
> > > > > > > has
> > > > > > > > > > >> already
> > > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Category E are repos that do not host code
> > directly,
> > > > and
> > > > > > are
> > > > > > > > > > either
> > > > > > > > > > >> > > > organizational entities, or host websites, that
> > > > > currently
> > > > > > > are
> > > > > > > > > not
> > > > > > > > > > >> part
> > > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This lack of unification between Category A and
> > > > > Category B
> > > > > > > is,
> > > > > > > > > > IMHO,
> > > > > > > > > > >> > > > what allowed us to introduce the infamous circular
> > > > > > > dependency
> > > > > > > > > > >> between
> > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now can
> > > > describe
> > > > > > as
> > > > > > > a
> > > > > > > > > > >> circular
> > > > > > > > > > >> > > > dependency between Category A and Category B. The
> > > way
> > > > I
> > > > > > see
> > > > > > > > it,
> > > > > > > > > if
> > > > > > > > > > >> we
> > > > > > > > > > >> > > > had a single pipeline, building everything from
> > > > `drools`
> > > > > > to
> > > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > > introduced,
> > > > > > and
> > > > > > > we
> > > > > > > > > > >> > > > wouldn't be having this huge problem in our hands
> > > > right
> > > > > > now.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > My proposal for the Apache KIE release process
> > sees
> > > > this
> > > > > > > lack
> > > > > > > > of
> > > > > > > > > > >> > > > unification as a central problem, not only for
> > this
> > > > > > release
> > > > > > > in
> > > > > > > > > > >> > > > particular, but for the community as a whole. It
> > is
> > > my
> > > > > > > belief
> > > > > > > > > that
> > > > > > > > > > >> we
> > > > > > > > > > >> > > > are all under the same roof, and that no
> > > contribution
> > > > > > should
> > > > > > > > be
> > > > > > > > > > >> > > > allowed to break any part of our codebase. With
> > the
> > > > > > > increasing
> > > > > > > > > > >> volume
> > > > > > > > > > >> > > > of code, and hopefully number of contributors too,
> > > we
> > > > > > cannot
> > > > > > > > > keep
> > > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> > things.
> > > > > We're
> > > > > > > all
> > > > > > > > > > >> humans
> > > > > > > > > > >> > > > after all, and it is our job to have mechanisms in
> > > > place
> > > > > > to
> > > > > > > > > > prevent
> > > > > > > > > > >> us
> > > > > > > > > > >> > > > from unwillingly making mistakes. Especially when
> > > > these
> > > > > > > > mistakes
> > > > > > > > > > >> > > > impact on parts of the codebase that we,
> > > individually,
> > > > > > > > probably
> > > > > > > > > > >> can't
> > > > > > > > > > >> > > > fix.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on
> > > > > > kiegroup's
> > > > > > > > KIE
> > > > > > > > > > >> Tools
> > > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> > `kogito-images`
> > > > > > > depending
> > > > > > > > on
> > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > > kiegroup's
> > > > > > > `lienzo`
> > > > > > > > > and
> > > > > > > > > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps` depending on
> > > > > > > kiegroup's
> > > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > > >> > > > * This module was removed from the KIE codebase
> > > here:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > > >> > > > and now lives on
> > > > > > > > > > >> > > >
> > > > > > > > > >
> > > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > > ,
> > > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > > >> > > > * This new repo depends on Kogito and OptaPlanner,
> > > > > > pointing
> > > > > > > to
> > > > > > > > > > older
> > > > > > > > > > >> > > > versions.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator`
> > > > > depending
> > > > > > on
> > > > > > > > > > Kogito
> > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > > >> > > > See:
> > > > > > > > > > >> > > > -
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P6. Category C repos are out of date and not part
> > of
> > > > the
> > > > > > > > > Category
> > > > > > > > > > A
> > > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> > version
> > > is
> > > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > > >> > > > depending on Kogito without a specific version,
> > only
> > > > by
> > > > > > > using
> > > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version is
> > > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> > > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has
> > its
> > > > E2E
> > > > > > > > disabled
> > > > > > > > > > >> after
> > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> > solution,
> > > > as
> > > > > > they
> > > > > > > > > both
> > > > > > > > > > >> > > > suffer from the circular dependency between
> > > Category A
> > > > > and
> > > > > > > > > > Category
> > > > > > > > > > >> B.
> > > > > > > > > > >> > > > As Category A and Category B are both streams that
> > > > have
> > > > > > been
> > > > > > > > > > really
> > > > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > > > contributions
> > > > > > > > that
> > > > > > > > > > >> > > > cannot be done, given that Category A depends on
> > > > > Category
> > > > > > B
> > > > > > > > > with a
> > > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P3 and P4, although not ideal, can be understood
> > as
> > > > > > > technical
> > > > > > > > > > debt.
> > > > > > > > > > >> > > > Depending on unmaintained projects is something
> > > we'll
> > > > > > always
> > > > > > > > be
> > > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> > matter
> > > of
> > > > > > > making
> > > > > > > > > them
> > > > > > > > > > >> > > > part of the play.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > P7 is an isolated problem that won't impact the
> > > > > structure
> > > > > > or
> > > > > > > > > > >> anything
> > > > > > > > > > >> > > > that we're talking about here, but it is a
> > > regression
> > > > we
> > > > > > > > > > introduced
> > > > > > > > > > >> > > > recently.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE
> > 10,
> > > > and
> > > > > > > that
> > > > > > > > > P5,
> > > > > > > > > > >> P6,
> > > > > > > > > > >> > > > and P7 have easy fixes, the only problems left to
> > > > > discuss
> > > > > > > are
> > > > > > > > P1
> > > > > > > > > > and
> > > > > > > > > > >> > > > P2, which can't be done without a proper proposal.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I'll try to be very meticulous here, since from my
> > > > > > > experience,
> > > > > > > > > any
> > > > > > > > > > >> > > > little miscalculation can lead to our release not
> > > > > working
> > > > > > > out
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > >> > > > end. To try and avoid that as much as possible,
> > and
> > > > make
> > > > > > > > > > everything
> > > > > > > > > > >> we
> > > > > > > > > > >> > > > can to have a successful Apache KIE 10 release,
> > bear
> > > > > with
> > > > > > > me.
> > > > > > > > > I'll
> > > > > > > > > > >> lay
> > > > > > > > > > >> > > > out a timeline of events that need to happen in
> > > order
> > > > > for
> > > > > > > our
> > > > > > > > > > >> release
> > > > > > > > > > >> > > > to be published, with all artifacts ending up in
> > the
> > > > > right
> > > > > > > > > places,
> > > > > > > > > > >> but
> > > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > As you saw at the beginning of this email, all the
> > > > > > attempts
> > > > > > > we
> > > > > > > > > > made
> > > > > > > > > > >> > > > left us with the circular dependency showing up
> > at a
> > > > > > > different
> > > > > > > > > > >> place,
> > > > > > > > > > >> > > > but something all these places have in common is
> > > that
> > > > > > > they're
> > > > > > > > > all
> > > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > The first part of my proposal is the following:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > S1. We keep the original plan of moving the
> > Quarkus
> > > > Dev
> > > > > > UIs
> > > > > > > > from
> > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > > Management
> > > > > and
> > > > > > > > Task
> > > > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > > `kogito-swf-builder`
> > > > > > > > > > images
> > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > > >> > > > S3. We move the entire
> > `kogito-serverless-operator`
> > > > repo
> > > > > > > > inside
> > > > > > > > > a
> > > > > > > > > > >> new
> > > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve problems
> > P1
> > > > and
> > > > > > P2.
> > > > > > > Of
> > > > > > > > > > >> course
> > > > > > > > > > >> > > > the rest of
> > > > > > > > > > >>
> > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > > >> > > > would still be done too.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > This doesn't come without consequences, of course,
> > > as
> > > > > the
> > > > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> > > images,
> > > > > and
> > > > > > > the
> > > > > > > > > > >> > > > `kogito-serverless-operator` would be moving from
> > > > > > Category A
> > > > > > > > to
> > > > > > > > > > >> > > > Category B. This move would make them have to
> > > > reference
> > > > > > > > > Category A
> > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > > `kogito-images`
> > > > > > > and
> > > > > > > > > > >> > > > `kogito-serverless-operator` are already their own
> > > > > > > > "sub-stream"
> > > > > > > > > > >> inside
> > > > > > > > > > >> > > > Category A, though, contributions made in a
> > > cross-repo
> > > > > > > fashion
> > > > > > > > > to
> > > > > > > > > > >> this
> > > > > > > > > > >> > > > "sub-stream" will continue being possible, now
> > via a
> > > > > > single
> > > > > > > PR
> > > > > > > > > to
> > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A and
> > > > > > Category
> > > > > > > B
> > > > > > > > > will
> > > > > > > > > > >> > > > continue not being possible, and a 1-week delay
> > > > between
> > > > > > > > merging
> > > > > > > > > > >> > > > something on Category A and using it on Category B
> > > > will
> > > > > > > still
> > > > > > > > > > >> happen.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > It's worth mentioning that `kie-tools`, however,
> > > does
> > > > > > allow
> > > > > > > > for
> > > > > > > > > > >> sparse
> > > > > > > > > > >> > > > checkouts and partial builds, so working with a
> > > subset
> > > > > of
> > > > > > > the
> > > > > > > > > > >> monorepo
> > > > > > > > > > >> > > > is possible and encouraged. Making changes only to
> > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example, will
> > > have
> > > > > the
> > > > > > PR
> > > > > > > > > > checks
> > > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > > >> > > > .
> > > > > > > > > > >> > > > We're not compromising when running partial builds
> > > > too.
> > > > > We
> > > > > > > > know
> > > > > > > > > > that
> > > > > > > > > > >> > > > the entire repo will continue working even after
> > > only
> > > > > > > > building a
> > > > > > > > > > >> small
> > > > > > > > > > >> > > > subset of the changes. Doing partial or full
> > builds
> > > is
> > > > > > > > > > automatically
> > > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Keep in mind that, even though I'm proposing we
> > > move a
> > > > > > bunch
> > > > > > > > of
> > > > > > > > > > >> > > > additional stuff into `kie-tools`, I see this as a
> > > > > > TEMPORARY
> > > > > > > > > > >> solution
> > > > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > > > additional
> > > > > > > stuff
> > > > > > > > > > >> > > > TEMPORARILY so that we can release and continue
> > > moving
> > > > > > > > forward.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> > became a
> > > > > > > polyglot
> > > > > > > > > > >> monorepo
> > > > > > > > > > >> > > > out of necessity, and although I'm really proud of
> > > > what
> > > > > we
> > > > > > > > > > achieved
> > > > > > > > > > >> > > > there so far, I don't think `kie-tools` has a
> > setup
> > > > that
> > > > > > is
> > > > > > > > > > suitable
> > > > > > > > > > >> > > > for all the different nuances that compose our
> > > > > community.
> > > > > > > I'm
> > > > > > > > > well
> > > > > > > > > > >> > > > aware that a polyglot monorepo that does not
> > follow
> > > > > > > widespread
> > > > > > > > > > >> > > > conventions will scare some people away, and as
> > much
> > > > as
> > > > > > > we've
> > > > > > > > > > tried
> > > > > > > > > > >> to
> > > > > > > > > > >> > > > make build instructions clear, we can't always get
> > > > past
> > > > > > the
> > > > > > > > > > >> prejudice
> > > > > > > > > > >> > > > some people have towards the "front-end"
> > ecosystem.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > With all that said, I keep thinking this is the
> > best
> > > > > > course
> > > > > > > of
> > > > > > > > > > >> action
> > > > > > > > > > >> > > > for us right now. We keep most of our stuff
> > > unchanged,
> > > > > we
> > > > > > > > > unblock
> > > > > > > > > > >> the
> > > > > > > > > > >> > > > release, and we have a working setup that will
> > suit
> > > us
> > > > > > well
> > > > > > > > > while
> > > > > > > > > > we
> > > > > > > > > > >> > > > discuss and reach a conclusion regarding the
> > future
> > > of
> > > > > our
> > > > > > > > > > codebase
> > > > > > > > > > >> > > > structure.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Let me paint a quick picture here of what our code
> > > > base
> > > > > > > would
> > > > > > > > > look
> > > > > > > > > > >> > > > like, repository-wise, if my proposal is accepted:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > > >> > > > A incubator-kie-optaplanner-quickstarts
> > > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > B
> > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > > >> > > > E incubator-kie-kogito-online-staging
> > > > > > > > > > >> > > > =====================
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > > > >> > > > `kogito-serverless-operator` moves entirely inside
> > > > > > > > `kie-tools`.
> > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > > > > > > > >> > > > `kogito-serverless-operator` inside `kie-tools`,
> > > there
> > > > > are
> > > > > > > no
> > > > > > > > > > cycles
> > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can granularly
> > > > build:
> > > > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > > > > `kogito-swf-builder`
> > > > > > > > > > >> and
> > > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > > >> > > > 4. packages/sonataflow-operator (contents from
> > > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > > >> > > > but renamed)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > The second part of the proposal is the release
> > > process
> > > > > > > itself,
> > > > > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Here it is:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as
> > > cutting
> > > > > > point
> > > > > > > > for
> > > > > > > > > > >> > > > Category A repos.
> > > > > > > > > > >> > > > 2. Update Category B repos to point to this
> > > > timestamped
> > > > > > > > > SNAPSHOT,
> > > > > > > > > > >> and
> > > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > > >> > > > 3. At this point, with everything working, we can
> > > > branch
> > > > > > out
> > > > > > > > to
> > > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped SNAPSHOT
> > > > tag,
> > > > > > and
> > > > > > > > > > >> Category B
> > > > > > > > > > >> > > > from `main`.
> > > > > > > > > > >> > > > 4. All Category A and Category B repos update
> > their
> > > > > > versions
> > > > > > > > to
> > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > > >> > > > 5. Update Category B repos to point to Category A
> > > > repos
> > > > > > > using
> > > > > > > > > the
> > > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > > >> > > > 6. At this point, we can vote on the release based
> > > on
> > > > > the
> > > > > > > > > `10.0.x`
> > > > > > > > > > >> > > > branches, given we don't expect any code changes
> > > > > anymore.
> > > > > > > > > > >> > > > 7. After voting passes, we're good to start the
> > > > release
> > > > > > > > process.
> > > > > > > > > > >> > > > 8. Category A repos follow their manual/automated
> > > > > release
> > > > > > > > > process,
> > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to
> > Git,
> > > > and
> > > > > > > built
> > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > >> > > > 9. We wait a little bit for Category A artifacts
> > to
> > > be
> > > > > > > > > propagated
> > > > > > > > > > on
> > > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > > >> > > > 10. Category B repos follow their manual/automated
> > > > > release
> > > > > > > > > > process,
> > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to
> > Git,
> > > > and
> > > > > > > built
> > > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > > >> > > > 12. Category E repos can be manually tagged with
> > > > 10.0.0
> > > > > > from
> > > > > > > > > their
> > > > > > > > > > >> > > > default branches.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > More needs to be discussed if we're planning to
> > > > maintain
> > > > > > > > > multiple
> > > > > > > > > > >> > > > release streams in parallel, but I guess it can
> > wait
> > > > for
> > > > > > > after
> > > > > > > > > > >> Apache
> > > > > > > > > > >> > > > KIE 10.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Thank you for reading, and I'm looking forward to
> > > > > hearing
> > > > > > > back
> > > > > > > > > > from
> > > > > > > > > > >> > > > everyone.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Of course, alternative solutions are possible.
> > This
> > > > > email,
> > > > > > > > > > however,
> > > > > > > > > > >> > > > summarizes my view of how we should attack the
> > > > problem,
> > > > > > > > > > considering
> > > > > > > > > > >> > > > disruption, required effort, the release process
> > > > itself,
> > > > > > and
> > > > > > > > > > >> history.
> > > > > > > > > > >> > > > Feel free to propose alternatives. This is not a
> > > > voting
> > > > > > > > thread.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Regards,
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >>
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > > dev-unsubscribe@kie.apache.org
> > > > > > > > > > >> > > > For additional commands, e-mail:
> > > > > dev-help@kie.apache.org
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <al...@porcelli.me>.
Francisco and Gabriele,
I understand and acknowledge your desire to find the “right” solution
instead to work on a temporary “patch” - however without a detailed
proposal I don’t think we can properly evaluate the impact of your
suggestion.
When I spoke with different SMEs that included tools and CI, the
guesstimate for making the necessary changes on CI and codebase to
basically have images and operators in the end of the build chain is
something like 2 months of effort. Another impact that needs to be
discussed is that KIE Tools repo had to be injected in the middle of all
pipelines - forcing all PR checks and nightlies to build all repos (PR
checks will likely take 12+ hours… I even heard that it could be even 24
hours).
Based on the input above, I think it’s quite risk to move in such direction
without a more detailed plan… because 2 months could be turned easily in 6!
And this is exactly what happened when we guessed that moving to Apache
would take no more than 3 months. But here we are.
I really strongly suggest that we focus on a release that could be
achievable in less than a month from now, and we - after release - have a
in depth discussion about the overall codebase and ci organization.
On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi <ga...@gmail.com>
wrote:
> Alex,
> my suggestion is to move the building of all docker images, from whatever
> repo (kogito-apps, kie-tools) in a different, downstream repo, to be
> invoked after all the others.
> I'm not sure if this would solve all the issues, and since I could not
> enter in the details of all the involved code, my suggestion may be too
> naive.
> Having spent almost all of the last year in CI, I may say that, at least
> for the kie-tools repo, removing the image build step from it should not be
> too difficult (since it is an issue we already faced and solved).
> If, with "detailed proposal", you mean a complete list of all modules to be
> moved and dependency refactoring, of course I can not provide it right now.
>
> Anyway, I share the concern from Francisco: undoing something is almost
> always harder than doing it "rightly" from scratch...
>
>
>
>
> Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti <
> ftirados@redhat.com> ha scritto:
>
> > I do not think estimations should be the only driver to make a decision,
> > especially when the current proposal is conceptually incompatible with
> the
> > multi repo approach that is taken elsewhere in the project.
> > Given my knowledge of the CI it is nearly impossible for me to give a
> fair
> > estimate of how much it might take to achieve step 2) of my previous
> e-mail
> > . It might take a while or it might be pretty easy after all, I don't
> > really know, but I think it will be a good idea if some of the experts
> on
> > CI in the team (the ones that set up the pipeline, which was a huge
> > achievement) give an estimate, not me. Estimating how much it takes to
> > merge two existing repos (without altering CI) is easier, but it does not
> > mean we are doing the right thing.
> > My main concern is that it will be very difficult for me to explain to
> > someone that arrives new to the team, that having experts on CI on the
> > team, we decided to merge two repos (once merged, it would be rather
> > difficult to unmerge) rather than fix the CI, because of expediency.
> >
> > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> > wrote:
> >
> > > Francisco,
> > >
> > > Please take the time to make the more in depth analysis needed and
> > provide
> > > a more detailed plan… so we - as community- can evaluate the size of
> the
> > > effort. In the conceptual level you shared it’s near impossible to
> > estimate
> > > the size of the effort and compare with the current proposal.
> > >
> > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > > ftirados@redhat.com> wrote:
> > >
> > > > I think I already did a high level proposal.
> > > > 1) Remove all dependencies from tooling to images, so images depend
> on
> > > > tooling but tooling does not depend on images.
> > > > 2) Then change CI to deal with tooling repo before dealing with
> images
> > > > repo.
> > > > I understand that CI details are tricky and since I'm not familiar
> with
> > > CI
> > > > in any way, I barely can make a low level design, but we do not need
> to
> > > fix
> > > > everything, just achieve 2), a change of compilation order.
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <al...@porcelli.me>
> > wrote:
> > > >
> > > > > Francisco and Grabriele,
> > > > >
> > > > > You may not like or understand why the current state of the CI is
> > like
> > > > > that… actually has been in Red Hat and has been replicated in
> Apache
> > as
> > > > > used to be….
> > > > >
> > > > > But the fact is that this is the current reality.
> > > > >
> > > > > If you disagree with the current plan, please provide a detailed
> > > > > alternative so we, as community, can better evaluate the pros and
> > cons
> > > of
> > > > > each proposal.
> > > > >
> > > > >
> > > > > I think it’s also fair to say that, post 10 release we need to
> have a
> > > > much
> > > > > in depth discussion about how our codebase is organized, it’s clear
> > > that
> > > > > it’s not working.
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > > gabriele.cardosi@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > As Francisco said,
> > > > > > I also have the impression that the "images" (if we are talking
> of
> > > > docker
> > > > > > images) should be the very last one to be built, in a standalone
> > > repo.
> > > > > > That way, they may "combine" artifacts that are built in
> different
> > > > repos,
> > > > > > regardless of the order in which those are built.
> > > > > > Moving them out of all the repos (kogito-apps/kie-tools) maybe
> > could
> > > > > > simplify the situation a bit.
> > > > > > (I also think there are some statements of undisputable needs
> while
> > > > they
> > > > > > are, actually, just technical choices.
> > > > > > Anyway, this latter point is for longer, following, discussion.)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier Tirado
> > > Sarti
> > > > <
> > > > > > ftirados@redhat.com> ha scritto:
> > > > > >
> > > > > > > Alex,
> > > > > > > There are two assumptions that deserve further discussion:
> > > > > > > 1) That tool has to be the last to build. why? it does not have
> > > more
> > > > > > sense
> > > > > > > to build final images after everything else has been built?-
> > > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> > bigger
> > > > than
> > > > > > the
> > > > > > > impact (long term consequences) of consolidating two unrelated
> > > piece
> > > > of
> > > > > > > software within the same repository.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <
> alex@porcelli.me
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Francisco,
> > > > > > > >
> > > > > > > > This was discussed as an alternative solution, however it has
> > > major
> > > > > > > impact
> > > > > > > > on CI and there’s also the fact Tool has been always the last
> > to
> > > > > build
> > > > > > > and
> > > > > > > > has no Snapshot published (actually in JavaScript world there
> > is
> > > no
> > > > > > > > snapshot concept).
> > > > > > > >
> > > > > > > > So, based on our evaluation… the proposal here is the least
> > > > > disruptive
> > > > > > > and
> > > > > > > > will take less time to unblock the release.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > _____________
> > > > > > > > Alex Porcelli
> > > > > > > > http://porcelli.me
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado
> Sarti <
> > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > >
> > > > > > > > > After kie-tools, sorry. I think we are not embracing the
> fact
> > > > that
> > > > > > > > > kogito-images depend on kie-tools, because we want those
> > images
> > > > to
> > > > > > > > include
> > > > > > > > > tools.
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado
> > Sarti
> > > <
> > > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > > >
> > > > > > > > > > Hi Tiago,
> > > > > > > > > > It can be an alternative solution to move
> > kn-plugin-workflow
> > > to
> > > > > > > > > > kogito-images (so there is not longer dependency from
> tools
> > > to
> > > > > > > images)
> > > > > > > > > and
> > > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > > >
> > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez
> Martinez
> > <
> > > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > > >
> > > > > > > > > >> +1 to unblock release
> > > > > > > > > >>
> > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > > > > > > > > pefernan@apache.org>
> > > > > > > > > >> escribió:
> > > > > > > > > >>
> > > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > > >> >
> > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > > alex@porcelli.me
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > > +1
> > > > > > > > > >> > >
> > > > > > > > > >> > > I spent the last day or so working closely with
> Tiago,
> > > > > > exploring
> > > > > > > > > >> > different
> > > > > > > > > >> > > options and getting deeper on the impact and
> > evaluating
> > > > the
> > > > > > > > overall
> > > > > > > > > >> > release
> > > > > > > > > >> > > procedure steps required. I agree with the proposal
> as
> > > the
> > > > > > most
> > > > > > > > > >> > > viable option for unblocking the 10 release in the
> > > > > reasonable
> > > > > > > time
> > > > > > > > > >> frame.
> > > > > > > > > >> > >
> > > > > > > > > >> > >
> > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > > tiagobento@apache.org>
> > > > > > > > > >> > wrote:
> > > > > > > > > >> > >
> > > > > > > > > >> > > > Hi everyone,
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time, as
> this
> > > > > matter
> > > > > > > > > >> requires a
> > > > > > > > > >> > > > lot of context.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > > according
> > > > > to
> > > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > > >> > > > (
> > > > > > > >
> > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > > ),
> > > > > > > > > >> > > > many of us were working towards removing a
> circular
> > > > > > dependency
> > > > > > > > > >> > > > currently present between `kogito-apps` and
> > > `kie-tools`.
> > > > > As
> > > > > > we
> > > > > > > > > >> > > > progressed towards a solution, we kept finding the
> > > > > circular
> > > > > > > > > >> dependency
> > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of the
> > > things
> > > > > we
> > > > > > > did,
> > > > > > > > > and
> > > > > > > > > >> > > > the results we had.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Right now, even though we started the effort to
> move
> > > the
> > > > > > > Quarkus
> > > > > > > > > Dev
> > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been able to
> > do
> > > it
> > > > > > yet,
> > > > > > > as
> > > > > > > > > >> we've
> > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17, Maven
> > 3.9.6,
> > > > and
> > > > > > > > Quarkus
> > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > > 999-20240218-SNAPSHOT.
> > > > > > > > This
> > > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > > >> > > >
> > > https://github.com/apache/incubator-kie-tools/pull/2136
> > > > .
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > > >> > > > C | 03. incubator-kie-kogito-examples
> > > > > > > > > >> > > > Y | 04. incubator-kie-kogito-images
> > > > > > > > > >> > > > C | 05.
> > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > >> > > > L | ==========================
> > > > > > > > > >> > > > E | 06.
> > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > * As `kie-tools`/extended-services depends
> > on
> > > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > > >> > > > * and
> > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > > depend
> > > > > > > > > >> on
> > > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`,
> we
> > > > > would've
> > > > > > > > had:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > > >> > > > Y | 05.
> > > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > >> > > > C | =====================
> > > > > > > > > >> > > > L | 06.
> > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> depends
> > on
> > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > > >> > > > * and `kogito-images`/kogito-swf-devmode
> > > depends
> > > > > on
> > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > > `kie-tools`,
> > > > > > we
> > > > > > > > > >> would've
> > > > > > > > > >> > > > had:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > > > > > >> > > > 04. incubator-kie-kogito-images
> > > > > > > > > >> > > > C |==> 05.
> > > > incubator-kie-kogito-serverless-operator
> > > > > > > > > >> > > > Y | =====================
> > > > > > > > > >> > > > C | 06.
> > > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > > >> > > > E
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow
> depends
> > on
> > > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > > >> > > > * and `kogito-serverless-operator` depends
> > on
> > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Clearly, we have a much bigger problem than a
> simple
> > > > > > circular
> > > > > > > > > >> > dependency.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > After multiple conversations with a lot of people,
> > > it's
> > > > > been
> > > > > > > > > really
> > > > > > > > > >> > > > hard coming up with a simple solution that makes
> it
> > > > > possible
> > > > > > > to
> > > > > > > > > >> build
> > > > > > > > > >> > > > Apache KIE in one shot, while preserving the way
> > > > everyone
> > > > > is
> > > > > > > > used
> > > > > > > > > to
> > > > > > > > > >> > > > contributing to the multiple repositories we have.
> > > More
> > > > > than
> > > > > > > > that,
> > > > > > > > > >> > > > while making this assessment, I found more
> problems
> > > > that,
> > > > > in
> > > > > > > my
> > > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > In light of that difficulty, I'm coming forward
> with
> > > my
> > > > > > > proposal
> > > > > > > > > for
> > > > > > > > > >> > > > the Apache KIE release process, so we can use
> > Apache's
> > > > > > > > mechanisms
> > > > > > > > > to
> > > > > > > > > >> > > > have a slower-paced, in-depth debate about this
> > really
> > > > > > > > complicated
> > > > > > > > > >> > > > matter.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > I'll lay out my entire perspective about the
> current
> > > > > > situation
> > > > > > > > of
> > > > > > > > > >> our
> > > > > > > > > >> > > > codebase, as well as problems I can currently see.
> > > I'll
> > > > > > start
> > > > > > > > with
> > > > > > > > > >> an
> > > > > > > > > >> > > > analysis of the repositories and their purposes,
> > point
> > > > out
> > > > > > > some
> > > > > > > > > >> > > > problems that I believe are blocking our 10
> release,
> > > > > explain
> > > > > > > my
> > > > > > > > > >> > > > proposal and discuss some consequences to what I'm
> > > > > > proposing.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Let's begin.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @
> `main`
> > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> > `0.0.0`
> > > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > > >> > > > (Issues only, README should be updated @
> `main`.
> > > > Same
> > > > > > for
> > > > > > > > > GitHub
> > > > > > > > > >> > > > Actions workflows.)
> > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > > >> > > > (The Kogito website. Develop & deploy at the
> > > `main`
> > > > > > > branch.)
> > > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > > `deploy`
> > > > to
> > > > > > > > update
> > > > > > > > > >> the
> > > > > > > > > >> > > > website.)
> > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > > >> > > > (GitHub pages used to host sandbox.kie.org
> and
> > > KIE
> > > > > > Tools'
> > > > > > > > > >> Chrome
> > > > > > > > > >> > > > Extension assets.)
> > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > > >> > > > (Same as above, but for manual sanity checks
> > > during
> > > > > the
> > > > > > > > > staging
> > > > > > > > > >> > > > phase of a release.)
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > I grouped the repositories by category, and listed
> > > them
> > > > > in a
> > > > > > > > > >> > > > topological order. Keep in mind that when
> flattening
> > > > out a
> > > > > > > tree,
> > > > > > > > > >> there
> > > > > > > > > >> > > > are multiple possibilities. For example,
> OptaPlanner
> > > > > > could've
> > > > > > > > been
> > > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Category A repos are what I've been referring to
> as
> > > > > `drools`
> > > > > > > and
> > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is inside
> > > that
> > > > > > > stream,
> > > > > > > > as
> > > > > > > > > >> the
> > > > > > > > > >> > > > way these repositories reference each other are
> > > through
> > > > > > Maven
> > > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > > version.
> > > > > This
> > > > > > > > > >> mechanism
> > > > > > > > > >> > > > is well-known to the team, and although flawed for
> > > > > intra-day
> > > > > > > > > builds
> > > > > > > > > >> > > > and disruptive for people in many different time
> > > zones,
> > > > it
> > > > > > is
> > > > > > > > > >> already
> > > > > > > > > >> > > > very comfortable for everyone to work with, I
> > assume.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Contributions made to Category A have some
> dedicated
> > > > > > > pipelines,
> > > > > > > > > >> which
> > > > > > > > > >> > > > are, at least to some extent, able to build
> > cross-repo
> > > > PRs
> > > > > > > > > together
> > > > > > > > > >> > > > and verify that the codebase will continue working
> > as
> > > > > > expected
> > > > > > > > > after
> > > > > > > > > >> > > > they're all merged. From what I could gather,
> there
> > > are
> > > > > some
> > > > > > > > > >> > > > "sub-streams" currently configured for cross-repo
> > PRs.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > > kogito-examples
> > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > > >> > > > - kogito-images, and kogito-serverless-operator
> > > > > > > > > >> > > > - kogito-docs
> > > > > > > > > >> > > > - kie-docs
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > > combination
> > > > > of
> > > > > > > > repos
> > > > > > > > > >> > > > that are not part of the same "sub-stream" cannot
> be
> > > > > > verified
> > > > > > > > > before
> > > > > > > > > >> > > > merging, making our contribution model dependent
> on
> > > > > > individual
> > > > > > > > > >> > > > contributors building stuff on their machines to
> > > verify
> > > > > that
> > > > > > > it
> > > > > > > > > >> works.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > I based this analysis on
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > > >> > > > ,
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > > >> > > > ,
> > > > > > > > > >> > > > and
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > > >> > > > .
> > > > > > > > > >> > > > Note that I'm not that familiar with these
> > pipelines,
> > > so
> > > > > > > please
> > > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Category B repos are what I've been referring to
> as
> > > > > > > `kie-tools`
> > > > > > > > > >> > > > stream. The first repo there is a template
> > repository
> > > > that
> > > > > > is
> > > > > > > > used
> > > > > > > > > >> by
> > > > > > > > > >> > > > people starting projects from scratch on KIE
> > Sandbox,
> > > > > > similar
> > > > > > > > to a
> > > > > > > > > >> > > > Maven archetype, if you will. The other one is the
> > KIE
> > > > > Tools
> > > > > > > > > >> monorepo,
> > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build
> system.
> > > > > > > Currently,
> > > > > > > > > KIE
> > > > > > > > > >> > > > Tools hosts Java libraries and apps, TypeScript
> > > > libraries
> > > > > > and
> > > > > > > > > apps,
> > > > > > > > > >> Go
> > > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> > `kie-tools`
> > > > > > monorepo
> > > > > > > > is
> > > > > > > > > >> > > > configured to work with sparse checkouts and can
> do
> > > > > partial
> > > > > > > > > builds.
> > > > > > > > > >> > > > Category B repos refer to Category A repos through
> > > > > > timestamped
> > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > > introduced
> > > > > > that
> > > > > > > > > will
> > > > > > > > > >> > > > build and publish immutable, persistent artifacts
> > > under
> > > > a
> > > > > > > > version
> > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> > published
> > > > > weekly
> > > > > > > > every
> > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an
> evolution
> > > to
> > > > > the
> > > > > > > > Kogito
> > > > > > > > > >> > > > releases, as we're now targeting one release for
> all
> > > of
> > > > > > Apache
> > > > > > > > > KIE,
> > > > > > > > > >> so
> > > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > An important note here is that Category B
> > repositories
> > > > > have
> > > > > > > been
> > > > > > > > > >> > > > historically kept out of any automations we used
> to
> > > > have,
> > > > > > way
> > > > > > > > back
> > > > > > > > > >> > > > when Kogito started and we had the Business
> Central
> > > > > (a.k.a.
> > > > > > > v7)
> > > > > > > > > >> stream
> > > > > > > > > >> > > > still going on. For this reason, Category B
> projects
> > > > have
> > > > > > > > > developed
> > > > > > > > > >> > > > their own automations, based on GitHub Actions.
> > > > Category B
> > > > > > > repos
> > > > > > > > > >> have
> > > > > > > > > >> > > > always depended on Category A repos using fixed
> > > > versions.
> > > > > If
> > > > > > > > > >> Category
> > > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs,
> breaking
> > > > > changes
> > > > > > > on
> > > > > > > > > >> > > > Category A repositories would've had the potential
> > to
> > > > > break
> > > > > > > > > >> Category B
> > > > > > > > > >> > > > silently, leaving Category B with a broken
> > development
> > > > > > stream,
> > > > > > > > and
> > > > > > > > > >> > > > introducing unpleasant surprises for maintainers
> of
> > > > > > Category B
> > > > > > > > > >> repos,
> > > > > > > > > >> > > > as historically Category A contributors were not
> > > > familiar
> > > > > > with
> > > > > > > > > >> > > > Category B repos.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Contributions made to Category B repos go through
> a
> > > > GitHub
> > > > > > > > Actions
> > > > > > > > > >> > > > workflow that builds the relevant part of the
> > > > `kie-tools`
> > > > > > > > monorepo
> > > > > > > > > >> for
> > > > > > > > > >> > > > the changes introduced. Changes made to the
> pipeline
> > > > > itself
> > > > > > > are
> > > > > > > > > also
> > > > > > > > > >> > > > picked up as part of PRs, allowing us to do things
> > > like
> > > > > > > > atomically
> > > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > > importantly,
> > > > > > it
> > > > > > > > > >> allows
> > > > > > > > > >> > > > us to upgrade the repository to a new timestamped
> > > > SNAPSHOT
> > > > > > > > > together
> > > > > > > > > >> > > > with the changes necessary to make it stay green.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > This setup, however, makes it impossible to have
> > > > > cross-repo
> > > > > > > PRs
> > > > > > > > > >> > > > involving Category A and Category B
> simultaneously,
> > > with
> > > > > the
> > > > > > > > > current
> > > > > > > > > >> > > > automations we have.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Category C repos are kind of floating around, and
> > I'm
> > > > not
> > > > > > sure
> > > > > > > > if
> > > > > > > > > >> > > > there's much activity going on there. Regardless,
> as
> > > > > they're
> > > > > > > > part
> > > > > > > > > of
> > > > > > > > > >> > > > Apache KIE, they will be part of our release, so I
> > > > listed
> > > > > > them
> > > > > > > > for
> > > > > > > > > >> us
> > > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Category D is self explanatory. There's only one
> > repo
> > > > that
> > > > > > has
> > > > > > > > > >> already
> > > > > > > > > >> > > > been marked for being archived.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Category E are repos that do not host code
> directly,
> > > and
> > > > > are
> > > > > > > > > either
> > > > > > > > > >> > > > organizational entities, or host websites, that
> > > > currently
> > > > > > are
> > > > > > > > not
> > > > > > > > > >> part
> > > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > This lack of unification between Category A and
> > > > Category B
> > > > > > is,
> > > > > > > > > IMHO,
> > > > > > > > > >> > > > what allowed us to introduce the infamous circular
> > > > > > dependency
> > > > > > > > > >> between
> > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now can
> > > describe
> > > > > as
> > > > > > a
> > > > > > > > > >> circular
> > > > > > > > > >> > > > dependency between Category A and Category B. The
> > way
> > > I
> > > > > see
> > > > > > > it,
> > > > > > > > if
> > > > > > > > > >> we
> > > > > > > > > >> > > > had a single pipeline, building everything from
> > > `drools`
> > > > > to
> > > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > > introduced,
> > > > > and
> > > > > > we
> > > > > > > > > >> > > > wouldn't be having this huge problem in our hands
> > > right
> > > > > now.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > My proposal for the Apache KIE release process
> sees
> > > this
> > > > > > lack
> > > > > > > of
> > > > > > > > > >> > > > unification as a central problem, not only for
> this
> > > > > release
> > > > > > in
> > > > > > > > > >> > > > particular, but for the community as a whole. It
> is
> > my
> > > > > > belief
> > > > > > > > that
> > > > > > > > > >> we
> > > > > > > > > >> > > > are all under the same roof, and that no
> > contribution
> > > > > should
> > > > > > > be
> > > > > > > > > >> > > > allowed to break any part of our codebase. With
> the
> > > > > > increasing
> > > > > > > > > >> volume
> > > > > > > > > >> > > > of code, and hopefully number of contributors too,
> > we
> > > > > cannot
> > > > > > > > keep
> > > > > > > > > >> > > > counting on "common sense" to avoid breaking
> things.
> > > > We're
> > > > > > all
> > > > > > > > > >> humans
> > > > > > > > > >> > > > after all, and it is our job to have mechanisms in
> > > place
> > > > > to
> > > > > > > > > prevent
> > > > > > > > > >> us
> > > > > > > > > >> > > > from unwillingly making mistakes. Especially when
> > > these
> > > > > > > mistakes
> > > > > > > > > >> > > > impact on parts of the codebase that we,
> > individually,
> > > > > > > probably
> > > > > > > > > >> can't
> > > > > > > > > >> > > > fix.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on
> > > > > kiegroup's
> > > > > > > KIE
> > > > > > > > > >> Tools
> > > > > > > > > >> > > > `0.32.0`.
> > > > > > > > > >> > > > See:
> > > > > > > > > >> > > > -
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > P2. PR open for Kogito SWF images @
> `kogito-images`
> > > > > > depending
> > > > > > > on
> > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > > >> > > > See:
> > > > > > > > > >> > > > -
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> > kiegroup's
> > > > > > `lienzo`
> > > > > > > > and
> > > > > > > > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > > > > > > >> > > > See:
> > > > > > > > > >> > > > -
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > > >> > > > -
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps` depending on
> > > > > > kiegroup's
> > > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > > >> > > > * This module was removed from the KIE codebase
> > here:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > > >> > > > and now lives on
> > > > > > > > > >> > > >
> > > > > > > > >
> > > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > > ,
> > > > > > > > > >> > > > under a different GAV.
> > > > > > > > > >> > > > * This new repo depends on Kogito and OptaPlanner,
> > > > > pointing
> > > > > > to
> > > > > > > > > older
> > > > > > > > > >> > > > versions.
> > > > > > > > > >> > > > See:
> > > > > > > > > >> > > > -
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > > >> > > > -
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator`
> > > > depending
> > > > > on
> > > > > > > > > Kogito
> > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > > >> > > > See:
> > > > > > > > > >> > > > -
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > P6. Category C repos are out of date and not part
> of
> > > the
> > > > > > > > Category
> > > > > > > > > A
> > > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current
> version
> > is
> > > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > > >> > > > depending on Kogito without a specific version,
> only
> > > by
> > > > > > using
> > > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version is
> > > > > > > `1.0-SNAPSHOT`,
> > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> > > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has
> its
> > > E2E
> > > > > > > disabled
> > > > > > > > > >> after
> > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > In my perspective, P1 and P2 have the same
> solution,
> > > as
> > > > > they
> > > > > > > > both
> > > > > > > > > >> > > > suffer from the circular dependency between
> > Category A
> > > > and
> > > > > > > > > Category
> > > > > > > > > >> B.
> > > > > > > > > >> > > > As Category A and Category B are both streams that
> > > have
> > > > > been
> > > > > > > > > really
> > > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > > contributions
> > > > > > > that
> > > > > > > > > >> > > > cannot be done, given that Category A depends on
> > > > Category
> > > > > B
> > > > > > > > with a
> > > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > P3 and P4, although not ideal, can be understood
> as
> > > > > > technical
> > > > > > > > > debt.
> > > > > > > > > >> > > > Depending on unmaintained projects is something
> > we'll
> > > > > always
> > > > > > > be
> > > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a
> matter
> > of
> > > > > > making
> > > > > > > > them
> > > > > > > > > >> > > > part of the play.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > P7 is an isolated problem that won't impact the
> > > > structure
> > > > > or
> > > > > > > > > >> anything
> > > > > > > > > >> > > > that we're talking about here, but it is a
> > regression
> > > we
> > > > > > > > > introduced
> > > > > > > > > >> > > > recently.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE
> 10,
> > > and
> > > > > > that
> > > > > > > > P5,
> > > > > > > > > >> P6,
> > > > > > > > > >> > > > and P7 have easy fixes, the only problems left to
> > > > discuss
> > > > > > are
> > > > > > > P1
> > > > > > > > > and
> > > > > > > > > >> > > > P2, which can't be done without a proper proposal.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > I'll try to be very meticulous here, since from my
> > > > > > experience,
> > > > > > > > any
> > > > > > > > > >> > > > little miscalculation can lead to our release not
> > > > working
> > > > > > out
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > >> > > > end. To try and avoid that as much as possible,
> and
> > > make
> > > > > > > > > everything
> > > > > > > > > >> we
> > > > > > > > > >> > > > can to have a successful Apache KIE 10 release,
> bear
> > > > with
> > > > > > me.
> > > > > > > > I'll
> > > > > > > > > >> lay
> > > > > > > > > >> > > > out a timeline of events that need to happen in
> > order
> > > > for
> > > > > > our
> > > > > > > > > >> release
> > > > > > > > > >> > > > to be published, with all artifacts ending up in
> the
> > > > right
> > > > > > > > places,
> > > > > > > > > >> but
> > > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > As you saw at the beginning of this email, all the
> > > > > attempts
> > > > > > we
> > > > > > > > > made
> > > > > > > > > >> > > > left us with the circular dependency showing up
> at a
> > > > > > different
> > > > > > > > > >> place,
> > > > > > > > > >> > > > but something all these places have in common is
> > that
> > > > > > they're
> > > > > > > > all
> > > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > The first part of my proposal is the following:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > S1. We keep the original plan of moving the
> Quarkus
> > > Dev
> > > > > UIs
> > > > > > > from
> > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> > Management
> > > > and
> > > > > > > Task
> > > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > > `kogito-swf-builder`
> > > > > > > > > images
> > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > > >> > > > S3. We move the entire
> `kogito-serverless-operator`
> > > repo
> > > > > > > inside
> > > > > > > > a
> > > > > > > > > >> new
> > > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve problems
> P1
> > > and
> > > > > P2.
> > > > > > Of
> > > > > > > > > >> course
> > > > > > > > > >> > > > the rest of
> > > > > > > > > >>
> https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > > >> > > > would still be done too.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > This doesn't come without consequences, of course,
> > as
> > > > the
> > > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> > images,
> > > > and
> > > > > > the
> > > > > > > > > >> > > > `kogito-serverless-operator` would be moving from
> > > > > Category A
> > > > > > > to
> > > > > > > > > >> > > > Category B. This move would make them have to
> > > reference
> > > > > > > > Category A
> > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > > `kogito-images`
> > > > > > and
> > > > > > > > > >> > > > `kogito-serverless-operator` are already their own
> > > > > > > "sub-stream"
> > > > > > > > > >> inside
> > > > > > > > > >> > > > Category A, though, contributions made in a
> > cross-repo
> > > > > > fashion
> > > > > > > > to
> > > > > > > > > >> this
> > > > > > > > > >> > > > "sub-stream" will continue being possible, now
> via a
> > > > > single
> > > > > > PR
> > > > > > > > to
> > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A and
> > > > > Category
> > > > > > B
> > > > > > > > will
> > > > > > > > > >> > > > continue not being possible, and a 1-week delay
> > > between
> > > > > > > merging
> > > > > > > > > >> > > > something on Category A and using it on Category B
> > > will
> > > > > > still
> > > > > > > > > >> happen.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > It's worth mentioning that `kie-tools`, however,
> > does
> > > > > allow
> > > > > > > for
> > > > > > > > > >> sparse
> > > > > > > > > >> > > > checkouts and partial builds, so working with a
> > subset
> > > > of
> > > > > > the
> > > > > > > > > >> monorepo
> > > > > > > > > >> > > > is possible and encouraged. Making changes only to
> > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example, will
> > have
> > > > the
> > > > > PR
> > > > > > > > > checks
> > > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > > >> > > > .
> > > > > > > > > >> > > > We're not compromising when running partial builds
> > > too.
> > > > We
> > > > > > > know
> > > > > > > > > that
> > > > > > > > > >> > > > the entire repo will continue working even after
> > only
> > > > > > > building a
> > > > > > > > > >> small
> > > > > > > > > >> > > > subset of the changes. Doing partial or full
> builds
> > is
> > > > > > > > > automatically
> > > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Keep in mind that, even though I'm proposing we
> > move a
> > > > > bunch
> > > > > > > of
> > > > > > > > > >> > > > additional stuff into `kie-tools`, I see this as a
> > > > > TEMPORARY
> > > > > > > > > >> solution
> > > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > > additional
> > > > > > stuff
> > > > > > > > > >> > > > TEMPORARILY so that we can release and continue
> > moving
> > > > > > > forward.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > As I mentioned on other places, `kie-tools`
> became a
> > > > > > polyglot
> > > > > > > > > >> monorepo
> > > > > > > > > >> > > > out of necessity, and although I'm really proud of
> > > what
> > > > we
> > > > > > > > > achieved
> > > > > > > > > >> > > > there so far, I don't think `kie-tools` has a
> setup
> > > that
> > > > > is
> > > > > > > > > suitable
> > > > > > > > > >> > > > for all the different nuances that compose our
> > > > community.
> > > > > > I'm
> > > > > > > > well
> > > > > > > > > >> > > > aware that a polyglot monorepo that does not
> follow
> > > > > > widespread
> > > > > > > > > >> > > > conventions will scare some people away, and as
> much
> > > as
> > > > > > we've
> > > > > > > > > tried
> > > > > > > > > >> to
> > > > > > > > > >> > > > make build instructions clear, we can't always get
> > > past
> > > > > the
> > > > > > > > > >> prejudice
> > > > > > > > > >> > > > some people have towards the "front-end"
> ecosystem.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > With all that said, I keep thinking this is the
> best
> > > > > course
> > > > > > of
> > > > > > > > > >> action
> > > > > > > > > >> > > > for us right now. We keep most of our stuff
> > unchanged,
> > > > we
> > > > > > > > unblock
> > > > > > > > > >> the
> > > > > > > > > >> > > > release, and we have a working setup that will
> suit
> > us
> > > > > well
> > > > > > > > while
> > > > > > > > > we
> > > > > > > > > >> > > > discuss and reach a conclusion regarding the
> future
> > of
> > > > our
> > > > > > > > > codebase
> > > > > > > > > >> > > > structure.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Let me paint a quick picture here of what our code
> > > base
> > > > > > would
> > > > > > > > look
> > > > > > > > > >> > > > like, repository-wise, if my proposal is accepted:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > > >> > > > =====================
> > > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > > >> > > > A incubator-kie-optaplanner-quickstarts
> > > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > > >> > > > =====================
> > > > > > > > > >> > > > B
> > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > > >> > > > =====================
> > > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > > >> > > > =====================
> > > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > > >> > > > E incubator-kie-kogito-online-staging
> > > > > > > > > >> > > > =====================
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > > >> > > > `kogito-serverless-operator` moves entirely inside
> > > > > > > `kie-tools`.
> > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > > > > > > >> > > > `kogito-serverless-operator` inside `kie-tools`,
> > there
> > > > are
> > > > > > no
> > > > > > > > > cycles
> > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can granularly
> > > build:
> > > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > > > `kogito-swf-builder`
> > > > > > > > > >> and
> > > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > > >> > > > 4. packages/sonataflow-operator (contents from
> > > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > > >> > > > but renamed)
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > The second part of the proposal is the release
> > process
> > > > > > itself,
> > > > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Here it is:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as
> > cutting
> > > > > point
> > > > > > > for
> > > > > > > > > >> > > > Category A repos.
> > > > > > > > > >> > > > 2. Update Category B repos to point to this
> > > timestamped
> > > > > > > > SNAPSHOT,
> > > > > > > > > >> and
> > > > > > > > > >> > > > verify that everything is working.
> > > > > > > > > >> > > > 3. At this point, with everything working, we can
> > > branch
> > > > > out
> > > > > > > to
> > > > > > > > > >> > > > `10.0.x`. Category A from the timestamped SNAPSHOT
> > > tag,
> > > > > and
> > > > > > > > > >> Category B
> > > > > > > > > >> > > > from `main`.
> > > > > > > > > >> > > > 4. All Category A and Category B repos update
> their
> > > > > versions
> > > > > > > to
> > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > > >> > > > 5. Update Category B repos to point to Category A
> > > repos
> > > > > > using
> > > > > > > > the
> > > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > > >> > > > 6. At this point, we can vote on the release based
> > on
> > > > the
> > > > > > > > `10.0.x`
> > > > > > > > > >> > > > branches, given we don't expect any code changes
> > > > anymore.
> > > > > > > > > >> > > > 7. After voting passes, we're good to start the
> > > release
> > > > > > > process.
> > > > > > > > > >> > > > 8. Category A repos follow their manual/automated
> > > > release
> > > > > > > > process,
> > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to
> Git,
> > > and
> > > > > > built
> > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > >> > > > 9. We wait a little bit for Category A artifacts
> to
> > be
> > > > > > > > propagated
> > > > > > > > > on
> > > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > > >> > > > 10. Category B repos follow their manual/automated
> > > > release
> > > > > > > > > process,
> > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to
> Git,
> > > and
> > > > > > built
> > > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > > >> > > > 12. Category E repos can be manually tagged with
> > > 10.0.0
> > > > > from
> > > > > > > > their
> > > > > > > > > >> > > > default branches.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > More needs to be discussed if we're planning to
> > > maintain
> > > > > > > > multiple
> > > > > > > > > >> > > > release streams in parallel, but I guess it can
> wait
> > > for
> > > > > > after
> > > > > > > > > >> Apache
> > > > > > > > > >> > > > KIE 10.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Thank you for reading, and I'm looking forward to
> > > > hearing
> > > > > > back
> > > > > > > > > from
> > > > > > > > > >> > > > everyone.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Of course, alternative solutions are possible.
> This
> > > > email,
> > > > > > > > > however,
> > > > > > > > > >> > > > summarizes my view of how we should attack the
> > > problem,
> > > > > > > > > considering
> > > > > > > > > >> > > > disruption, required effort, the release process
> > > itself,
> > > > > and
> > > > > > > > > >> history.
> > > > > > > > > >> > > > Feel free to propose alternatives. This is not a
> > > voting
> > > > > > > thread.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Regards,
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Tiago Bento
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >>
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > >> > > > To unsubscribe, e-mail:
> > > dev-unsubscribe@kie.apache.org
> > > > > > > > > >> > > > For additional commands, e-mail:
> > > > dev-help@kie.apache.org
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Gabriele Cardosi <ga...@gmail.com>.
Alex,
my suggestion is to move the building of all docker images, from whatever
repo (kogito-apps, kie-tools) in a different, downstream repo, to be
invoked after all the others.
I'm not sure if this would solve all the issues, and since I could not
enter in the details of all the involved code, my suggestion may be too
naive.
Having spent almost all of the last year in CI, I may say that, at least
for the kie-tools repo, removing the image build step from it should not be
too difficult (since it is an issue we already faced and solved).
If, with "detailed proposal", you mean a complete list of all modules to be
moved and dependency refactoring, of course I can not provide it right now.
Anyway, I share the concern from Francisco: undoing something is almost
always harder than doing it "rightly" from scratch...
Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado Sarti <
ftirados@redhat.com> ha scritto:
> I do not think estimations should be the only driver to make a decision,
> especially when the current proposal is conceptually incompatible with the
> multi repo approach that is taken elsewhere in the project.
> Given my knowledge of the CI it is nearly impossible for me to give a fair
> estimate of how much it might take to achieve step 2) of my previous e-mail
> . It might take a while or it might be pretty easy after all, I don't
> really know, but I think it will be a good idea if some of the experts on
> CI in the team (the ones that set up the pipeline, which was a huge
> achievement) give an estimate, not me. Estimating how much it takes to
> merge two existing repos (without altering CI) is easier, but it does not
> mean we are doing the right thing.
> My main concern is that it will be very difficult for me to explain to
> someone that arrives new to the team, that having experts on CI on the
> team, we decided to merge two repos (once merged, it would be rather
> difficult to unmerge) rather than fix the CI, because of expediency.
>
> On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org>
> wrote:
>
> > Francisco,
> >
> > Please take the time to make the more in depth analysis needed and
> provide
> > a more detailed plan… so we - as community- can evaluate the size of the
> > effort. In the conceptual level you shared it’s near impossible to
> estimate
> > the size of the effort and compare with the current proposal.
> >
> > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> > ftirados@redhat.com> wrote:
> >
> > > I think I already did a high level proposal.
> > > 1) Remove all dependencies from tooling to images, so images depend on
> > > tooling but tooling does not depend on images.
> > > 2) Then change CI to deal with tooling repo before dealing with images
> > > repo.
> > > I understand that CI details are tricky and since I'm not familiar with
> > CI
> > > in any way, I barely can make a low level design, but we do not need to
> > fix
> > > everything, just achieve 2), a change of compilation order.
> > >
> > >
> > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <al...@porcelli.me>
> wrote:
> > >
> > > > Francisco and Grabriele,
> > > >
> > > > You may not like or understand why the current state of the CI is
> like
> > > > that… actually has been in Red Hat and has been replicated in Apache
> as
> > > > used to be….
> > > >
> > > > But the fact is that this is the current reality.
> > > >
> > > > If you disagree with the current plan, please provide a detailed
> > > > alternative so we, as community, can better evaluate the pros and
> cons
> > of
> > > > each proposal.
> > > >
> > > >
> > > > I think it’s also fair to say that, post 10 release we need to have a
> > > much
> > > > in depth discussion about how our codebase is organized, it’s clear
> > that
> > > > it’s not working.
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > > gabriele.cardosi@gmail.com>
> > > > wrote:
> > > >
> > > > > As Francisco said,
> > > > > I also have the impression that the "images" (if we are talking of
> > > docker
> > > > > images) should be the very last one to be built, in a standalone
> > repo.
> > > > > That way, they may "combine" artifacts that are built in different
> > > repos,
> > > > > regardless of the order in which those are built.
> > > > > Moving them out of all the repos (kogito-apps/kie-tools) maybe
> could
> > > > > simplify the situation a bit.
> > > > > (I also think there are some statements of undisputable needs while
> > > they
> > > > > are, actually, just technical choices.
> > > > > Anyway, this latter point is for longer, following, discussion.)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier Tirado
> > Sarti
> > > <
> > > > > ftirados@redhat.com> ha scritto:
> > > > >
> > > > > > Alex,
> > > > > > There are two assumptions that deserve further discussion:
> > > > > > 1) That tool has to be the last to build. why? it does not have
> > more
> > > > > sense
> > > > > > to build final images after everything else has been built?-
> > > > > > 2) That the impact (in terms of effort now) on fixing CI is
> bigger
> > > than
> > > > > the
> > > > > > impact (long term consequences) of consolidating two unrelated
> > piece
> > > of
> > > > > > software within the same repository.
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <alex@porcelli.me
> >
> > > > wrote:
> > > > > >
> > > > > > > Francisco,
> > > > > > >
> > > > > > > This was discussed as an alternative solution, however it has
> > major
> > > > > > impact
> > > > > > > on CI and there’s also the fact Tool has been always the last
> to
> > > > build
> > > > > > and
> > > > > > > has no Snapshot published (actually in JavaScript world there
> is
> > no
> > > > > > > snapshot concept).
> > > > > > >
> > > > > > > So, based on our evaluation… the proposal here is the least
> > > > disruptive
> > > > > > and
> > > > > > > will take less time to unblock the release.
> > > > > > >
> > > > > > > Regards,
> > > > > > > _____________
> > > > > > > Alex Porcelli
> > > > > > > http://porcelli.me
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado Sarti <
> > > > > > > ftirados@redhat.com> wrote:
> > > > > > >
> > > > > > > > After kie-tools, sorry. I think we are not embracing the fact
> > > that
> > > > > > > > kogito-images depend on kie-tools, because we want those
> images
> > > to
> > > > > > > include
> > > > > > > > tools.
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado
> Sarti
> > <
> > > > > > > > ftirados@redhat.com> wrote:
> > > > > > > >
> > > > > > > > > Hi Tiago,
> > > > > > > > > It can be an alternative solution to move
> kn-plugin-workflow
> > to
> > > > > > > > > kogito-images (so there is not longer dependency from tools
> > to
> > > > > > images)
> > > > > > > > and
> > > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > > >
> > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez
> <
> > > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > > >
> > > > > > > > >> +1 to unblock release
> > > > > > > > >>
> > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > > > > > > > pefernan@apache.org>
> > > > > > > > >> escribió:
> > > > > > > > >>
> > > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > > >> >
> > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > > alex@porcelli.me
> > > > >
> > > > > > > wrote:
> > > > > > > > >> >
> > > > > > > > >> > > +1
> > > > > > > > >> > >
> > > > > > > > >> > > I spent the last day or so working closely with Tiago,
> > > > > exploring
> > > > > > > > >> > different
> > > > > > > > >> > > options and getting deeper on the impact and
> evaluating
> > > the
> > > > > > > overall
> > > > > > > > >> > release
> > > > > > > > >> > > procedure steps required. I agree with the proposal as
> > the
> > > > > most
> > > > > > > > >> > > viable option for unblocking the 10 release in the
> > > > reasonable
> > > > > > time
> > > > > > > > >> frame.
> > > > > > > > >> > >
> > > > > > > > >> > >
> > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > > tiagobento@apache.org>
> > > > > > > > >> > wrote:
> > > > > > > > >> > >
> > > > > > > > >> > > > Hi everyone,
> > > > > > > > >> > > >
> > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time, as this
> > > > matter
> > > > > > > > >> requires a
> > > > > > > > >> > > > lot of context.
> > > > > > > > >> > > >
> > > > > > > > >> > > > This email will take you < 20 minutes to read,
> > according
> > > > to
> > > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > > >> > > >
> > > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > > >> > > > (
> > > > > > >
> https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > > ),
> > > > > > > > >> > > > many of us were working towards removing a circular
> > > > > dependency
> > > > > > > > >> > > > currently present between `kogito-apps` and
> > `kie-tools`.
> > > > As
> > > > > we
> > > > > > > > >> > > > progressed towards a solution, we kept finding the
> > > > circular
> > > > > > > > >> dependency
> > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of the
> > things
> > > > we
> > > > > > did,
> > > > > > > > and
> > > > > > > > >> > > > the results we had.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Right now, even though we started the effort to move
> > the
> > > > > > Quarkus
> > > > > > > > Dev
> > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been able to
> do
> > it
> > > > > yet,
> > > > > > as
> > > > > > > > >> we've
> > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17, Maven
> 3.9.6,
> > > and
> > > > > > > Quarkus
> > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > > 999-20240218-SNAPSHOT.
> > > > > > > This
> > > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > > >> > > >
> > https://github.com/apache/incubator-kie-tools/pull/2136
> > > .
> > > > > > > > >> > > >
> > > > > > > > >> > > > The current scenario we have is:
> > > > > > > > >> > > >
> > > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > > >> > > > C | 03. incubator-kie-kogito-examples
> > > > > > > > >> > > > Y | 04. incubator-kie-kogito-images
> > > > > > > > >> > > > C | 05.
> > > > incubator-kie-kogito-serverless-operator
> > > > > > > > >> > > > L | ==========================
> > > > > > > > >> > > > E | 06.
> > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > * As `kie-tools`/extended-services depends
> on
> > > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > > >> > > > * and
> > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > > depend
> > > > > > > > >> on
> > > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`, we
> > > > would've
> > > > > > > had:
> > > > > > > > >> > > >
> > > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > > >> > > > Y | 05.
> > > > incubator-kie-kogito-serverless-operator
> > > > > > > > >> > > > C | =====================
> > > > > > > > >> > > > L | 06.
> > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > > >> > > >
> > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends
> on
> > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > > >> > > > * and `kogito-images`/kogito-swf-devmode
> > depends
> > > > on
> > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > > `kie-tools`,
> > > > > we
> > > > > > > > >> would've
> > > > > > > > >> > > > had:
> > > > > > > > >> > > >
> > > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > > > > >> > > > 04. incubator-kie-kogito-images
> > > > > > > > >> > > > C |==> 05.
> > > incubator-kie-kogito-serverless-operator
> > > > > > > > >> > > > Y | =====================
> > > > > > > > >> > > > C | 06.
> > > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > > >> > > > E
> > > > > > > > >> > > >
> > > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends
> on
> > > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > > >> > > > * and `kogito-serverless-operator` depends
> on
> > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > Clearly, we have a much bigger problem than a simple
> > > > > circular
> > > > > > > > >> > dependency.
> > > > > > > > >> > > >
> > > > > > > > >> > > > After multiple conversations with a lot of people,
> > it's
> > > > been
> > > > > > > > really
> > > > > > > > >> > > > hard coming up with a simple solution that makes it
> > > > possible
> > > > > > to
> > > > > > > > >> build
> > > > > > > > >> > > > Apache KIE in one shot, while preserving the way
> > > everyone
> > > > is
> > > > > > > used
> > > > > > > > to
> > > > > > > > >> > > > contributing to the multiple repositories we have.
> > More
> > > > than
> > > > > > > that,
> > > > > > > > >> > > > while making this assessment, I found more problems
> > > that,
> > > > in
> > > > > > my
> > > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > > >> > > >
> > > > > > > > >> > > > In light of that difficulty, I'm coming forward with
> > my
> > > > > > proposal
> > > > > > > > for
> > > > > > > > >> > > > the Apache KIE release process, so we can use
> Apache's
> > > > > > > mechanisms
> > > > > > > > to
> > > > > > > > >> > > > have a slower-paced, in-depth debate about this
> really
> > > > > > > complicated
> > > > > > > > >> > > > matter.
> > > > > > > > >> > > >
> > > > > > > > >> > > > I'll lay out my entire perspective about the current
> > > > > situation
> > > > > > > of
> > > > > > > > >> our
> > > > > > > > >> > > > codebase, as well as problems I can currently see.
> > I'll
> > > > > start
> > > > > > > with
> > > > > > > > >> an
> > > > > > > > >> > > > analysis of the repositories and their purposes,
> point
> > > out
> > > > > > some
> > > > > > > > >> > > > problems that I believe are blocking our 10 release,
> > > > explain
> > > > > > my
> > > > > > > > >> > > > proposal and discuss some consequences to what I'm
> > > > > proposing.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Let's begin.
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > > >> > > >
> > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @ `main`
> > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > > >> > > >
> > > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @
> `0.0.0`
> > > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > > >> > > >
> > > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > > >> > > >
> > > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > > >> > > >
> > > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > > >> > > > (Issues only, README should be updated @ `main`.
> > > Same
> > > > > for
> > > > > > > > GitHub
> > > > > > > > >> > > > Actions workflows.)
> > > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > > >> > > > (The Kogito website. Develop & deploy at the
> > `main`
> > > > > > branch.)
> > > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> > `deploy`
> > > to
> > > > > > > update
> > > > > > > > >> the
> > > > > > > > >> > > > website.)
> > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > > >> > > > (GitHub pages used to host sandbox.kie.org and
> > KIE
> > > > > Tools'
> > > > > > > > >> Chrome
> > > > > > > > >> > > > Extension assets.)
> > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > > >> > > > (Same as above, but for manual sanity checks
> > during
> > > > the
> > > > > > > > staging
> > > > > > > > >> > > > phase of a release.)
> > > > > > > > >> > > >
> > > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > > >> > > >
> > > > > > > > >> > > > I grouped the repositories by category, and listed
> > them
> > > > in a
> > > > > > > > >> > > > topological order. Keep in mind that when flattening
> > > out a
> > > > > > tree,
> > > > > > > > >> there
> > > > > > > > >> > > > are multiple possibilities. For example, OptaPlanner
> > > > > could've
> > > > > > > been
> > > > > > > > >> > > > placed in any position after Drools.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Category A repos are what I've been referring to as
> > > > `drools`
> > > > > > and
> > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is inside
> > that
> > > > > > stream,
> > > > > > > as
> > > > > > > > >> the
> > > > > > > > >> > > > way these repositories reference each other are
> > through
> > > > > Maven
> > > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> > version.
> > > > This
> > > > > > > > >> mechanism
> > > > > > > > >> > > > is well-known to the team, and although flawed for
> > > > intra-day
> > > > > > > > builds
> > > > > > > > >> > > > and disruptive for people in many different time
> > zones,
> > > it
> > > > > is
> > > > > > > > >> already
> > > > > > > > >> > > > very comfortable for everyone to work with, I
> assume.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Contributions made to Category A have some dedicated
> > > > > > pipelines,
> > > > > > > > >> which
> > > > > > > > >> > > > are, at least to some extent, able to build
> cross-repo
> > > PRs
> > > > > > > > together
> > > > > > > > >> > > > and verify that the codebase will continue working
> as
> > > > > expected
> > > > > > > > after
> > > > > > > > >> > > > they're all merged. From what I could gather, there
> > are
> > > > some
> > > > > > > > >> > > > "sub-streams" currently configured for cross-repo
> PRs.
> > > > > > > > >> > > >
> > > > > > > > >> > > > - kogito-pipelines
> > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > > kogito-examples
> > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > > >> > > > - kogito-images, and kogito-serverless-operator
> > > > > > > > >> > > > - kogito-docs
> > > > > > > > >> > > > - kie-docs
> > > > > > > > >> > > >
> > > > > > > > >> > > > This means that sending cross-repo PRs to any
> > > combination
> > > > of
> > > > > > > repos
> > > > > > > > >> > > > that are not part of the same "sub-stream" cannot be
> > > > > verified
> > > > > > > > before
> > > > > > > > >> > > > merging, making our contribution model dependent on
> > > > > individual
> > > > > > > > >> > > > contributors building stuff on their machines to
> > verify
> > > > that
> > > > > > it
> > > > > > > > >> works.
> > > > > > > > >> > > >
> > > > > > > > >> > > > I based this analysis on
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > > >> > > > ,
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > > >> > > > ,
> > > > > > > > >> > > > and
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > > >> > > > .
> > > > > > > > >> > > > Note that I'm not that familiar with these
> pipelines,
> > so
> > > > > > please
> > > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Category B repos are what I've been referring to as
> > > > > > `kie-tools`
> > > > > > > > >> > > > stream. The first repo there is a template
> repository
> > > that
> > > > > is
> > > > > > > used
> > > > > > > > >> by
> > > > > > > > >> > > > people starting projects from scratch on KIE
> Sandbox,
> > > > > similar
> > > > > > > to a
> > > > > > > > >> > > > Maven archetype, if you will. The other one is the
> KIE
> > > > Tools
> > > > > > > > >> monorepo,
> > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build system.
> > > > > > Currently,
> > > > > > > > KIE
> > > > > > > > >> > > > Tools hosts Java libraries and apps, TypeScript
> > > libraries
> > > > > and
> > > > > > > > apps,
> > > > > > > > >> Go
> > > > > > > > >> > > > apps, Docker images, and Helm charts. The
> `kie-tools`
> > > > > monorepo
> > > > > > > is
> > > > > > > > >> > > > configured to work with sparse checkouts and can do
> > > > partial
> > > > > > > > builds.
> > > > > > > > >> > > > Category B repos refer to Category A repos through
> > > > > timestamped
> > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > > introduced
> > > > > that
> > > > > > > > will
> > > > > > > > >> > > > build and publish immutable, persistent artifacts
> > under
> > > a
> > > > > > > version
> > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format,
> published
> > > > weekly
> > > > > > > every
> > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an evolution
> > to
> > > > the
> > > > > > > Kogito
> > > > > > > > >> > > > releases, as we're now targeting one release for all
> > of
> > > > > Apache
> > > > > > > > KIE,
> > > > > > > > >> so
> > > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > > >> > > >
> > > > > > > > >> > > > An important note here is that Category B
> repositories
> > > > have
> > > > > > been
> > > > > > > > >> > > > historically kept out of any automations we used to
> > > have,
> > > > > way
> > > > > > > back
> > > > > > > > >> > > > when Kogito started and we had the Business Central
> > > > (a.k.a.
> > > > > > v7)
> > > > > > > > >> stream
> > > > > > > > >> > > > still going on. For this reason, Category B projects
> > > have
> > > > > > > > developed
> > > > > > > > >> > > > their own automations, based on GitHub Actions.
> > > Category B
> > > > > > repos
> > > > > > > > >> have
> > > > > > > > >> > > > always depended on Category A repos using fixed
> > > versions.
> > > > If
> > > > > > > > >> Category
> > > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs, breaking
> > > > changes
> > > > > > on
> > > > > > > > >> > > > Category A repositories would've had the potential
> to
> > > > break
> > > > > > > > >> Category B
> > > > > > > > >> > > > silently, leaving Category B with a broken
> development
> > > > > stream,
> > > > > > > and
> > > > > > > > >> > > > introducing unpleasant surprises for maintainers of
> > > > > Category B
> > > > > > > > >> repos,
> > > > > > > > >> > > > as historically Category A contributors were not
> > > familiar
> > > > > with
> > > > > > > > >> > > > Category B repos.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Contributions made to Category B repos go through a
> > > GitHub
> > > > > > > Actions
> > > > > > > > >> > > > workflow that builds the relevant part of the
> > > `kie-tools`
> > > > > > > monorepo
> > > > > > > > >> for
> > > > > > > > >> > > > the changes introduced. Changes made to the pipeline
> > > > itself
> > > > > > are
> > > > > > > > also
> > > > > > > > >> > > > picked up as part of PRs, allowing us to do things
> > like
> > > > > > > atomically
> > > > > > > > >> > > > bumping the Node.js version, for example. More
> > > > importantly,
> > > > > it
> > > > > > > > >> allows
> > > > > > > > >> > > > us to upgrade the repository to a new timestamped
> > > SNAPSHOT
> > > > > > > > together
> > > > > > > > >> > > > with the changes necessary to make it stay green.
> > > > > > > > >> > > >
> > > > > > > > >> > > > This setup, however, makes it impossible to have
> > > > cross-repo
> > > > > > PRs
> > > > > > > > >> > > > involving Category A and Category B simultaneously,
> > with
> > > > the
> > > > > > > > current
> > > > > > > > >> > > > automations we have.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Category C repos are kind of floating around, and
> I'm
> > > not
> > > > > sure
> > > > > > > if
> > > > > > > > >> > > > there's much activity going on there. Regardless, as
> > > > they're
> > > > > > > part
> > > > > > > > of
> > > > > > > > >> > > > Apache KIE, they will be part of our release, so I
> > > listed
> > > > > them
> > > > > > > for
> > > > > > > > >> us
> > > > > > > > >> > > > to take them into consideration too.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Category D is self explanatory. There's only one
> repo
> > > that
> > > > > has
> > > > > > > > >> already
> > > > > > > > >> > > > been marked for being archived.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Category E are repos that do not host code directly,
> > and
> > > > are
> > > > > > > > either
> > > > > > > > >> > > > organizational entities, or host websites, that
> > > currently
> > > > > are
> > > > > > > not
> > > > > > > > >> part
> > > > > > > > >> > > > of any pipelines we have.
> > > > > > > > >> > > >
> > > > > > > > >> > > > This lack of unification between Category A and
> > > Category B
> > > > > is,
> > > > > > > > IMHO,
> > > > > > > > >> > > > what allowed us to introduce the infamous circular
> > > > > dependency
> > > > > > > > >> between
> > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now can
> > describe
> > > > as
> > > > > a
> > > > > > > > >> circular
> > > > > > > > >> > > > dependency between Category A and Category B. The
> way
> > I
> > > > see
> > > > > > it,
> > > > > > > if
> > > > > > > > >> we
> > > > > > > > >> > > > had a single pipeline, building everything from
> > `drools`
> > > > to
> > > > > > > > >> > > > `kie-tools`, such flaws would've never been
> > introduced,
> > > > and
> > > > > we
> > > > > > > > >> > > > wouldn't be having this huge problem in our hands
> > right
> > > > now.
> > > > > > > > >> > > >
> > > > > > > > >> > > > My proposal for the Apache KIE release process sees
> > this
> > > > > lack
> > > > > > of
> > > > > > > > >> > > > unification as a central problem, not only for this
> > > > release
> > > > > in
> > > > > > > > >> > > > particular, but for the community as a whole. It is
> my
> > > > > belief
> > > > > > > that
> > > > > > > > >> we
> > > > > > > > >> > > > are all under the same roof, and that no
> contribution
> > > > should
> > > > > > be
> > > > > > > > >> > > > allowed to break any part of our codebase. With the
> > > > > increasing
> > > > > > > > >> volume
> > > > > > > > >> > > > of code, and hopefully number of contributors too,
> we
> > > > cannot
> > > > > > > keep
> > > > > > > > >> > > > counting on "common sense" to avoid breaking things.
> > > We're
> > > > > all
> > > > > > > > >> humans
> > > > > > > > >> > > > after all, and it is our job to have mechanisms in
> > place
> > > > to
> > > > > > > > prevent
> > > > > > > > >> us
> > > > > > > > >> > > > from unwillingly making mistakes. Especially when
> > these
> > > > > > mistakes
> > > > > > > > >> > > > impact on parts of the codebase that we,
> individually,
> > > > > > probably
> > > > > > > > >> can't
> > > > > > > > >> > > > fix.
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > > >> > > >
> > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on
> > > > kiegroup's
> > > > > > KIE
> > > > > > > > >> Tools
> > > > > > > > >> > > > `0.32.0`.
> > > > > > > > >> > > > See:
> > > > > > > > >> > > > -
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > P2. PR open for Kogito SWF images @ `kogito-images`
> > > > > depending
> > > > > > on
> > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > > >> > > > See:
> > > > > > > > >> > > > -
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on
> kiegroup's
> > > > > `lienzo`
> > > > > > > and
> > > > > > > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > > > > > >> > > > See:
> > > > > > > > >> > > > -
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > > >> > > > -
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps` depending on
> > > > > kiegroup's
> > > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > > >> > > > * This module was removed from the KIE codebase
> here:
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > > >> > > > and now lives on
> > > > > > > > >> > > >
> > > > > > > >
> > > https://github.com/trustyai-explainability/trustyai-explainability
> > > > ,
> > > > > > > > >> > > > under a different GAV.
> > > > > > > > >> > > > * This new repo depends on Kogito and OptaPlanner,
> > > > pointing
> > > > > to
> > > > > > > > older
> > > > > > > > >> > > > versions.
> > > > > > > > >> > > > See:
> > > > > > > > >> > > > -
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > > >> > > > -
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator`
> > > depending
> > > > on
> > > > > > > > Kogito
> > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > > >> > > > See:
> > > > > > > > >> > > > -
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > P6. Category C repos are out of date and not part of
> > the
> > > > > > > Category
> > > > > > > > A
> > > > > > > > >> > > > CI/Release pipelines.
> > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current version
> is
> > > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > > >> > > > depending on Kogito without a specific version, only
> > by
> > > > > using
> > > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > > >> > > > * incubator-kie-benchmarks: (Current version is
> > > > > > `1.0-SNAPSHOT`,
> > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> > > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its
> > E2E
> > > > > > disabled
> > > > > > > > >> after
> > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > In my perspective, P1 and P2 have the same solution,
> > as
> > > > they
> > > > > > > both
> > > > > > > > >> > > > suffer from the circular dependency between
> Category A
> > > and
> > > > > > > > Category
> > > > > > > > >> B.
> > > > > > > > >> > > > As Category A and Category B are both streams that
> > have
> > > > been
> > > > > > > > really
> > > > > > > > >> > > > active, I see this as a blocker, as there are
> > > > contributions
> > > > > > that
> > > > > > > > >> > > > cannot be done, given that Category A depends on
> > > Category
> > > > B
> > > > > > > with a
> > > > > > > > >> > > > dephasing of 1 release.
> > > > > > > > >> > > >
> > > > > > > > >> > > > P3 and P4, although not ideal, can be understood as
> > > > > technical
> > > > > > > > debt.
> > > > > > > > >> > > > Depending on unmaintained projects is something
> we'll
> > > > always
> > > > > > be
> > > > > > > > >> > > > susceptible to, given time.
> > > > > > > > >> > > >
> > > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a matter
> of
> > > > > making
> > > > > > > them
> > > > > > > > >> > > > part of the play.
> > > > > > > > >> > > >
> > > > > > > > >> > > > P7 is an isolated problem that won't impact the
> > > structure
> > > > or
> > > > > > > > >> anything
> > > > > > > > >> > > > that we're talking about here, but it is a
> regression
> > we
> > > > > > > > introduced
> > > > > > > > >> > > > recently.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE 10,
> > and
> > > > > that
> > > > > > > P5,
> > > > > > > > >> P6,
> > > > > > > > >> > > > and P7 have easy fixes, the only problems left to
> > > discuss
> > > > > are
> > > > > > P1
> > > > > > > > and
> > > > > > > > >> > > > P2, which can't be done without a proper proposal.
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > # THE PROPOSAL
> > > > > > > > >> > > >
> > > > > > > > >> > > > I'll try to be very meticulous here, since from my
> > > > > experience,
> > > > > > > any
> > > > > > > > >> > > > little miscalculation can lead to our release not
> > > working
> > > > > out
> > > > > > in
> > > > > > > > the
> > > > > > > > >> > > > end. To try and avoid that as much as possible, and
> > make
> > > > > > > > everything
> > > > > > > > >> we
> > > > > > > > >> > > > can to have a successful Apache KIE 10 release, bear
> > > with
> > > > > me.
> > > > > > > I'll
> > > > > > > > >> lay
> > > > > > > > >> > > > out a timeline of events that need to happen in
> order
> > > for
> > > > > our
> > > > > > > > >> release
> > > > > > > > >> > > > to be published, with all artifacts ending up in the
> > > right
> > > > > > > places,
> > > > > > > > >> but
> > > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > > >> > > >
> > > > > > > > >> > > > As you saw at the beginning of this email, all the
> > > > attempts
> > > > > we
> > > > > > > > made
> > > > > > > > >> > > > left us with the circular dependency showing up at a
> > > > > different
> > > > > > > > >> place,
> > > > > > > > >> > > > but something all these places have in common is
> that
> > > > > they're
> > > > > > > all
> > > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > > >> > > >
> > > > > > > > >> > > > The first part of my proposal is the following:
> > > > > > > > >> > > >
> > > > > > > > >> > > > S1. We keep the original plan of moving the Quarkus
> > Dev
> > > > UIs
> > > > > > from
> > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with
> Management
> > > and
> > > > > > Task
> > > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > > `kogito-swf-builder`
> > > > > > > > images
> > > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > > >> > > > S3. We move the entire `kogito-serverless-operator`
> > repo
> > > > > > inside
> > > > > > > a
> > > > > > > > >> new
> > > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Solutions S1, S2, and S3 together solve problems P1
> > and
> > > > P2.
> > > > > Of
> > > > > > > > >> course
> > > > > > > > >> > > > the rest of
> > > > > > > > >> https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > > >> > > > would still be done too.
> > > > > > > > >> > > >
> > > > > > > > >> > > > This doesn't come without consequences, of course,
> as
> > > the
> > > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder`
> images,
> > > and
> > > > > the
> > > > > > > > >> > > > `kogito-serverless-operator` would be moving from
> > > > Category A
> > > > > > to
> > > > > > > > >> > > > Category B. This move would make them have to
> > reference
> > > > > > > Category A
> > > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > > `kogito-images`
> > > > > and
> > > > > > > > >> > > > `kogito-serverless-operator` are already their own
> > > > > > "sub-stream"
> > > > > > > > >> inside
> > > > > > > > >> > > > Category A, though, contributions made in a
> cross-repo
> > > > > fashion
> > > > > > > to
> > > > > > > > >> this
> > > > > > > > >> > > > "sub-stream" will continue being possible, now via a
> > > > single
> > > > > PR
> > > > > > > to
> > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A and
> > > > Category
> > > > > B
> > > > > > > will
> > > > > > > > >> > > > continue not being possible, and a 1-week delay
> > between
> > > > > > merging
> > > > > > > > >> > > > something on Category A and using it on Category B
> > will
> > > > > still
> > > > > > > > >> happen.
> > > > > > > > >> > > >
> > > > > > > > >> > > > It's worth mentioning that `kie-tools`, however,
> does
> > > > allow
> > > > > > for
> > > > > > > > >> sparse
> > > > > > > > >> > > > checkouts and partial builds, so working with a
> subset
> > > of
> > > > > the
> > > > > > > > >> monorepo
> > > > > > > > >> > > > is possible and encouraged. Making changes only to
> > > > > > > > >> > > > `packages/kn-plugin-workflow`, for example, will
> have
> > > the
> > > > PR
> > > > > > > > checks
> > > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > > >> > > > .
> > > > > > > > >> > > > We're not compromising when running partial builds
> > too.
> > > We
> > > > > > know
> > > > > > > > that
> > > > > > > > >> > > > the entire repo will continue working even after
> only
> > > > > > building a
> > > > > > > > >> small
> > > > > > > > >> > > > subset of the changes. Doing partial or full builds
> is
> > > > > > > > automatically
> > > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Keep in mind that, even though I'm proposing we
> move a
> > > > bunch
> > > > > > of
> > > > > > > > >> > > > additional stuff into `kie-tools`, I see this as a
> > > > TEMPORARY
> > > > > > > > >> solution
> > > > > > > > >> > > > for our codebase. `kie-tools` would host some
> > additional
> > > > > stuff
> > > > > > > > >> > > > TEMPORARILY so that we can release and continue
> moving
> > > > > > forward.
> > > > > > > > >> > > >
> > > > > > > > >> > > > As I mentioned on other places, `kie-tools` became a
> > > > > polyglot
> > > > > > > > >> monorepo
> > > > > > > > >> > > > out of necessity, and although I'm really proud of
> > what
> > > we
> > > > > > > > achieved
> > > > > > > > >> > > > there so far, I don't think `kie-tools` has a setup
> > that
> > > > is
> > > > > > > > suitable
> > > > > > > > >> > > > for all the different nuances that compose our
> > > community.
> > > > > I'm
> > > > > > > well
> > > > > > > > >> > > > aware that a polyglot monorepo that does not follow
> > > > > widespread
> > > > > > > > >> > > > conventions will scare some people away, and as much
> > as
> > > > > we've
> > > > > > > > tried
> > > > > > > > >> to
> > > > > > > > >> > > > make build instructions clear, we can't always get
> > past
> > > > the
> > > > > > > > >> prejudice
> > > > > > > > >> > > > some people have towards the "front-end" ecosystem.
> > > > > > > > >> > > >
> > > > > > > > >> > > > With all that said, I keep thinking this is the best
> > > > course
> > > > > of
> > > > > > > > >> action
> > > > > > > > >> > > > for us right now. We keep most of our stuff
> unchanged,
> > > we
> > > > > > > unblock
> > > > > > > > >> the
> > > > > > > > >> > > > release, and we have a working setup that will suit
> us
> > > > well
> > > > > > > while
> > > > > > > > we
> > > > > > > > >> > > > discuss and reach a conclusion regarding the future
> of
> > > our
> > > > > > > > codebase
> > > > > > > > >> > > > structure.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Let me paint a quick picture here of what our code
> > base
> > > > > would
> > > > > > > look
> > > > > > > > >> > > > like, repository-wise, if my proposal is accepted:
> > > > > > > > >> > > >
> > > > > > > > >> > > > CATEGORY REPO
> > > > > > > > >> > > > =====================
> > > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > > >> > > > A incubator-kie-drools
> > > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > > >> > > > A incubator-kie-optaplanner-quickstarts
> > > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > > >> > > > A incubator-kie-docs
> > > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > > >> > > > =====================
> > > > > > > > >> > > > B
> incubator-kie-sandbox-quarkus-accelerator
> > > > > > > > >> > > > B incubator-kie-tools
> > > > > > > > >> > > > =====================
> > > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > > >> > > > =====================
> > > > > > > > >> > > > E incubator-kie-issues
> > > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > > >> > > > E incubator-kie-website
> > > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > > >> > > > E incubator-kie-kogito-online-staging
> > > > > > > > >> > > > =====================
> > > > > > > > >> > > >
> > > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > > >> > > > `kogito-serverless-operator` moves entirely inside
> > > > > > `kie-tools`.
> > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > > > > > >> > > > `kogito-serverless-operator` inside `kie-tools`,
> there
> > > are
> > > > > no
> > > > > > > > cycles
> > > > > > > > >> > > > anymore, as inside `kie-tools`, we can granularly
> > build:
> > > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > > `kogito-swf-builder`
> > > > > > > > >> and
> > > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > > >> > > > 4. packages/sonataflow-operator (contents from
> > > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > > >> > > > but renamed)
> > > > > > > > >> > > >
> > > > > > > > >> > > > The second part of the proposal is the release
> process
> > > > > itself,
> > > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Here it is:
> > > > > > > > >> > > >
> > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as
> cutting
> > > > point
> > > > > > for
> > > > > > > > >> > > > Category A repos.
> > > > > > > > >> > > > 2. Update Category B repos to point to this
> > timestamped
> > > > > > > SNAPSHOT,
> > > > > > > > >> and
> > > > > > > > >> > > > verify that everything is working.
> > > > > > > > >> > > > 3. At this point, with everything working, we can
> > branch
> > > > out
> > > > > > to
> > > > > > > > >> > > > `10.0.x`. Category A from the timestamped SNAPSHOT
> > tag,
> > > > and
> > > > > > > > >> Category B
> > > > > > > > >> > > > from `main`.
> > > > > > > > >> > > > 4. All Category A and Category B repos update their
> > > > versions
> > > > > > to
> > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > > >> > > > 5. Update Category B repos to point to Category A
> > repos
> > > > > using
> > > > > > > the
> > > > > > > > >> > > > 10.0.0 version.
> > > > > > > > >> > > > 6. At this point, we can vote on the release based
> on
> > > the
> > > > > > > `10.0.x`
> > > > > > > > >> > > > branches, given we don't expect any code changes
> > > anymore.
> > > > > > > > >> > > > 7. After voting passes, we're good to start the
> > release
> > > > > > process.
> > > > > > > > >> > > > 8. Category A repos follow their manual/automated
> > > release
> > > > > > > process,
> > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git,
> > and
> > > > > built
> > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > >> > > > 9. We wait a little bit for Category A artifacts to
> be
> > > > > > > propagated
> > > > > > > > on
> > > > > > > > >> > > > registries. ~1 day.
> > > > > > > > >> > > > 10. Category B repos follow their manual/automated
> > > release
> > > > > > > > process,
> > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git,
> > and
> > > > > built
> > > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > > >> > > > 12. Category E repos can be manually tagged with
> > 10.0.0
> > > > from
> > > > > > > their
> > > > > > > > >> > > > default branches.
> > > > > > > > >> > > >
> > > > > > > > >> > > > More needs to be discussed if we're planning to
> > maintain
> > > > > > > multiple
> > > > > > > > >> > > > release streams in parallel, but I guess it can wait
> > for
> > > > > after
> > > > > > > > >> Apache
> > > > > > > > >> > > > KIE 10.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Thank you for reading, and I'm looking forward to
> > > hearing
> > > > > back
> > > > > > > > from
> > > > > > > > >> > > > everyone.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Of course, alternative solutions are possible. This
> > > email,
> > > > > > > > however,
> > > > > > > > >> > > > summarizes my view of how we should attack the
> > problem,
> > > > > > > > considering
> > > > > > > > >> > > > disruption, required effort, the release process
> > itself,
> > > > and
> > > > > > > > >> history.
> > > > > > > > >> > > > Feel free to propose alternatives. This is not a
> > voting
> > > > > > thread.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Regards,
> > > > > > > > >> > > >
> > > > > > > > >> > > > Tiago Bento
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >>
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > >> > > > To unsubscribe, e-mail:
> > dev-unsubscribe@kie.apache.org
> > > > > > > > >> > > > For additional commands, e-mail:
> > > dev-help@kie.apache.org
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <po...@apache.org>.
On the bright side, I’m really happy to see the sudden high interest on CI!
Something that we’ve been highlighting the need of hands since we moved to
Apache.
On Wed, Mar 13, 2024 at 7:29 AM Alex Porcelli <po...@apache.org> wrote:
> Francisco,
>
> Please take the time to make the more in depth analysis needed and provide
> a more detailed plan… so we - as community- can evaluate the size of the
> effort. In the conceptual level you shared it’s near impossible to estimate
> the size of the effort and compare with the current proposal.
>
> On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> ftirados@redhat.com> wrote:
>
>> I think I already did a high level proposal.
>> 1) Remove all dependencies from tooling to images, so images depend on
>> tooling but tooling does not depend on images.
>> 2) Then change CI to deal with tooling repo before dealing with images
>> repo.
>> I understand that CI details are tricky and since I'm not familiar with CI
>> in any way, I barely can make a low level design, but we do not need to
>> fix
>> everything, just achieve 2), a change of compilation order.
>>
>>
>> On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <al...@porcelli.me> wrote:
>>
>> > Francisco and Grabriele,
>> >
>> > You may not like or understand why the current state of the CI is like
>> > that… actually has been in Red Hat and has been replicated in Apache as
>> > used to be….
>> >
>> > But the fact is that this is the current reality.
>> >
>> > If you disagree with the current plan, please provide a detailed
>> > alternative so we, as community, can better evaluate the pros and cons
>> of
>> > each proposal.
>> >
>> >
>> > I think it’s also fair to say that, post 10 release we need to have a
>> much
>> > in depth discussion about how our codebase is organized, it’s clear that
>> > it’s not working.
>> >
>> >
>> > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
>> > gabriele.cardosi@gmail.com>
>> > wrote:
>> >
>> > > As Francisco said,
>> > > I also have the impression that the "images" (if we are talking of
>> docker
>> > > images) should be the very last one to be built, in a standalone repo.
>> > > That way, they may "combine" artifacts that are built in different
>> repos,
>> > > regardless of the order in which those are built.
>> > > Moving them out of all the repos (kogito-apps/kie-tools) maybe could
>> > > simplify the situation a bit.
>> > > (I also think there are some statements of undisputable needs while
>> they
>> > > are, actually, just technical choices.
>> > > Anyway, this latter point is for longer, following, discussion.)
>> > >
>> > >
>> > >
>> > >
>> > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier Tirado
>> Sarti <
>> > > ftirados@redhat.com> ha scritto:
>> > >
>> > > > Alex,
>> > > > There are two assumptions that deserve further discussion:
>> > > > 1) That tool has to be the last to build. why? it does not have more
>> > > sense
>> > > > to build final images after everything else has been built?-
>> > > > 2) That the impact (in terms of effort now) on fixing CI is bigger
>> than
>> > > the
>> > > > impact (long term consequences) of consolidating two unrelated
>> piece of
>> > > > software within the same repository.
>> > > >
>> > > >
>> > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <al...@porcelli.me>
>> > wrote:
>> > > >
>> > > > > Francisco,
>> > > > >
>> > > > > This was discussed as an alternative solution, however it has
>> major
>> > > > impact
>> > > > > on CI and there’s also the fact Tool has been always the last to
>> > build
>> > > > and
>> > > > > has no Snapshot published (actually in JavaScript world there is
>> no
>> > > > > snapshot concept).
>> > > > >
>> > > > > So, based on our evaluation… the proposal here is the least
>> > disruptive
>> > > > and
>> > > > > will take less time to unblock the release.
>> > > > >
>> > > > > Regards,
>> > > > > _____________
>> > > > > Alex Porcelli
>> > > > > http://porcelli.me
>> > > > >
>> > > > >
>> > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado Sarti <
>> > > > > ftirados@redhat.com> wrote:
>> > > > >
>> > > > > > After kie-tools, sorry. I think we are not embracing the fact
>> that
>> > > > > > kogito-images depend on kie-tools, because we want those images
>> to
>> > > > > include
>> > > > > > tools.
>> > > > > >
>> > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado Sarti <
>> > > > > > ftirados@redhat.com> wrote:
>> > > > > >
>> > > > > > > Hi Tiago,
>> > > > > > > It can be an alternative solution to move kn-plugin-workflow
>> to
>> > > > > > > kogito-images (so there is not longer dependency from tools to
>> > > > images)
>> > > > > > and
>> > > > > > > then build kogito-images after kogito-tools?
>> > > > > > >
>> > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez <
>> > > > > > > egonzalez@apache.org> wrote:
>> > > > > > >
>> > > > > > >> +1 to unblock release
>> > > > > > >>
>> > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
>> > > > > > pefernan@apache.org>
>> > > > > > >> escribió:
>> > > > > > >>
>> > > > > > >> > I say +1 in order to move forward with the 10.
>> > > > > > >> >
>> > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
>> alex@porcelli.me
>> > >
>> > > > > wrote:
>> > > > > > >> >
>> > > > > > >> > > +1
>> > > > > > >> > >
>> > > > > > >> > > I spent the last day or so working closely with Tiago,
>> > > exploring
>> > > > > > >> > different
>> > > > > > >> > > options and getting deeper on the impact and evaluating
>> the
>> > > > > overall
>> > > > > > >> > release
>> > > > > > >> > > procedure steps required. I agree with the proposal as
>> the
>> > > most
>> > > > > > >> > > viable option for unblocking the 10 release in the
>> > reasonable
>> > > > time
>> > > > > > >> frame.
>> > > > > > >> > >
>> > > > > > >> > >
>> > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
>> > > > > tiagobento@apache.org>
>> > > > > > >> > wrote:
>> > > > > > >> > >
>> > > > > > >> > > > Hi everyone,
>> > > > > > >> > > >
>> > > > > > >> > > > Unfortunately, I can't do a tl;dr this time, as this
>> > matter
>> > > > > > >> requires a
>> > > > > > >> > > > lot of context.
>> > > > > > >> > > >
>> > > > > > >> > > > This email will take you < 20 minutes to read,
>> according
>> > to
>> > > > > > >> > > > https://thereadtime.com/.
>> > > > > > >> > > >
>> > > > > > >> > > > As you may have followed on a separate thread
>> > > > > > >> > > > (
>> > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
>> > > > > > ),
>> > > > > > >> > > > many of us were working towards removing a circular
>> > > dependency
>> > > > > > >> > > > currently present between `kogito-apps` and
>> `kie-tools`.
>> > As
>> > > we
>> > > > > > >> > > > progressed towards a solution, we kept finding the
>> > circular
>> > > > > > >> dependency
>> > > > > > >> > > > pop up somewhere else. I'll do a breakdown of the
>> things
>> > we
>> > > > did,
>> > > > > > and
>> > > > > > >> > > > the results we had.
>> > > > > > >> > > >
>> > > > > > >> > > > Right now, even though we started the effort to move
>> the
>> > > > Quarkus
>> > > > > > Dev
>> > > > > > >> > > > UI modules to `kie-tools`, we haven't been able to do
>> it
>> > > yet,
>> > > > as
>> > > > > > >> we've
>> > > > > > >> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6,
>> and
>> > > > > Quarkus
>> > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
>> > > 999-20240218-SNAPSHOT.
>> > > > > This
>> > > > > > >> > > > effort was concluded this Monday, with
>> > > > > > >> > > >
>> https://github.com/apache/incubator-kie-tools/pull/2136.
>> > > > > > >> > > >
>> > > > > > >> > > > The current scenario we have is:
>> > > > > > >> > > >
>> > > > > > >> > > > 01. incubator-kie-kogito-runtimes
>> > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
>> > > > > > >> > > > C | 03. incubator-kie-kogito-examples
>> > > > > > >> > > > Y | 04. incubator-kie-kogito-images
>> > > > > > >> > > > C | 05.
>> > incubator-kie-kogito-serverless-operator
>> > > > > > >> > > > L | ==========================
>> > > > > > >> > > > E | 06.
>> > > incubator-kie-sandbox-quarkus-accelerator
>> > > > > > >> > > > |==> 07. incubator-kie-tools
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > * As `kie-tools`/extended-services depends on
>> > > > > > >> > > > `kogito-apps`/jitexecutor;
>> > > > > > >> > > > * and
>> > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
>> > > > > depend
>> > > > > > >> on
>> > > > > > >> > > > `kie-tools`/{many packages}
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`, we
>> > would've
>> > > > > had:
>> > > > > > >> > > >
>> > > > > > >> > > > 01. incubator-kie-kogito-runtimes
>> > > > > > >> > > > 02. incubator-kie-kogito-apps
>> > > > > > >> > > > 03. incubator-kie-kogito-examples
>> > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
>> > > > > > >> > > > Y | 05.
>> > incubator-kie-kogito-serverless-operator
>> > > > > > >> > > > C | =====================
>> > > > > > >> > > > L | 06.
>> > > incubator-kie-sandbox-quarkus-accelerator
>> > > > > > >> > > > E |==> 07. incubator-kie-tools
>> > > > > > >> > > >
>> > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
>> > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
>> > > > > > >> > > > * and `kogito-images`/kogito-swf-devmode
>> depends
>> > on
>> > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > After moving the `kogito-swf-devmode` image to
>> > `kie-tools`,
>> > > we
>> > > > > > >> would've
>> > > > > > >> > > > had:
>> > > > > > >> > > >
>> > > > > > >> > > > 01. incubator-kie-kogito-runtimes
>> > > > > > >> > > > 02. incubator-kie-kogito-apps
>> > > > > > >> > > > 03. incubator-kie-kogito-examples
>> > > > > > >> > > > 04. incubator-kie-kogito-images
>> > > > > > >> > > > C |==> 05.
>> incubator-kie-kogito-serverless-operator
>> > > > > > >> > > > Y | =====================
>> > > > > > >> > > > C | 06.
>> > > incubator-kie-sandbox-quarkus-accelerator
>> > > > > > >> > > > L |==> 07. incubator-kie-tools
>> > > > > > >> > > > E
>> > > > > > >> > > >
>> > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
>> > > > > > >> > > > `kogito-serverless-operator`;
>> > > > > > >> > > > * and `kogito-serverless-operator` depends on
>> > > > > > >> > > > `kie-tools`/kogito-swf-devmode
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > Clearly, we have a much bigger problem than a simple
>> > > circular
>> > > > > > >> > dependency.
>> > > > > > >> > > >
>> > > > > > >> > > > After multiple conversations with a lot of people, it's
>> > been
>> > > > > > really
>> > > > > > >> > > > hard coming up with a simple solution that makes it
>> > possible
>> > > > to
>> > > > > > >> build
>> > > > > > >> > > > Apache KIE in one shot, while preserving the way
>> everyone
>> > is
>> > > > > used
>> > > > > > to
>> > > > > > >> > > > contributing to the multiple repositories we have. More
>> > than
>> > > > > that,
>> > > > > > >> > > > while making this assessment, I found more problems
>> that,
>> > in
>> > > > my
>> > > > > > >> > > > perspective, block Apache KIE 10.
>> > > > > > >> > > >
>> > > > > > >> > > > In light of that difficulty, I'm coming forward with my
>> > > > proposal
>> > > > > > for
>> > > > > > >> > > > the Apache KIE release process, so we can use Apache's
>> > > > > mechanisms
>> > > > > > to
>> > > > > > >> > > > have a slower-paced, in-depth debate about this really
>> > > > > complicated
>> > > > > > >> > > > matter.
>> > > > > > >> > > >
>> > > > > > >> > > > I'll lay out my entire perspective about the current
>> > > situation
>> > > > > of
>> > > > > > >> our
>> > > > > > >> > > > codebase, as well as problems I can currently see. I'll
>> > > start
>> > > > > with
>> > > > > > >> an
>> > > > > > >> > > > analysis of the repositories and their purposes, point
>> out
>> > > > some
>> > > > > > >> > > > problems that I believe are blocking our 10 release,
>> > explain
>> > > > my
>> > > > > > >> > > > proposal and discuss some consequences to what I'm
>> > > proposing.
>> > > > > > >> > > >
>> > > > > > >> > > > Let's begin.
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > # THE APACHE KIE REPOS
>> > > > > > >> > > >
>> > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
>> > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
>> > > > > > >> > > > - incubator-kie-drools @ `main`
>> > > > > > >> > > > - incubator-kie-optaplanner @ `main`
>> > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
>> > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
>> > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
>> > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
>> > > > > > >> > > > - incubator-kie-kogito-images @ `main`
>> > > > > > >> > > > - incubator-kie-kogito-serverless-operator @ `main`
>> > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
>> > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
>> > > > > > >> > > >
>> > > > > > >> > > > B. TOOLS (count: 2)
>> > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
>> > > > > > >> > > > - incubator-kie-tools @ `main`
>> > > > > > >> > > >
>> > > > > > >> > > > C. BENCHMARKS (count: 2)
>> > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
>> > > > > > >> > > > - incubator-kie-benchmarks @ `main`
>> > > > > > >> > > >
>> > > > > > >> > > > D. ARCHIVED (count: 1)
>> > > > > > >> > > > - incubator-kie-kogito-operator
>> > > > > > >> > > >
>> > > > > > >> > > > E. "NON-CODE" (count: 5)
>> > > > > > >> > > > - incubator-kie-issues @ `main`
>> > > > > > >> > > > (Issues only, README should be updated @ `main`.
>> Same
>> > > for
>> > > > > > GitHub
>> > > > > > >> > > > Actions workflows.)
>> > > > > > >> > > > - incubator-kie-kogito-website @ `main`
>> > > > > > >> > > > (The Kogito website. Develop & deploy at the `main`
>> > > > branch.)
>> > > > > > >> > > > - incubator-kie-website @ `main`
>> > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
>> `deploy` to
>> > > > > update
>> > > > > > >> the
>> > > > > > >> > > > website.)
>> > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
>> > > > > > >> > > > (GitHub pages used to host sandbox.kie.org and KIE
>> > > Tools'
>> > > > > > >> Chrome
>> > > > > > >> > > > Extension assets.)
>> > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
>> > > > > > >> > > > (Same as above, but for manual sanity checks during
>> > the
>> > > > > > staging
>> > > > > > >> > > > phase of a release.)
>> > > > > > >> > > >
>> > > > > > >> > > > TOTAL (count: 21)
>> > > > > > >> > > >
>> > > > > > >> > > > I grouped the repositories by category, and listed them
>> > in a
>> > > > > > >> > > > topological order. Keep in mind that when flattening
>> out a
>> > > > tree,
>> > > > > > >> there
>> > > > > > >> > > > are multiple possibilities. For example, OptaPlanner
>> > > could've
>> > > > > been
>> > > > > > >> > > > placed in any position after Drools.
>> > > > > > >> > > >
>> > > > > > >> > > > Category A repos are what I've been referring to as
>> > `drools`
>> > > > and
>> > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is inside that
>> > > > stream,
>> > > > > as
>> > > > > > >> the
>> > > > > > >> > > > way these repositories reference each other are through
>> > > Maven
>> > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version.
>> > This
>> > > > > > >> mechanism
>> > > > > > >> > > > is well-known to the team, and although flawed for
>> > intra-day
>> > > > > > builds
>> > > > > > >> > > > and disruptive for people in many different time
>> zones, it
>> > > is
>> > > > > > >> already
>> > > > > > >> > > > very comfortable for everyone to work with, I assume.
>> > > > > > >> > > >
>> > > > > > >> > > > Contributions made to Category A have some dedicated
>> > > > pipelines,
>> > > > > > >> which
>> > > > > > >> > > > are, at least to some extent, able to build cross-repo
>> PRs
>> > > > > > together
>> > > > > > >> > > > and verify that the codebase will continue working as
>> > > expected
>> > > > > > after
>> > > > > > >> > > > they're all merged. From what I could gather, there are
>> > some
>> > > > > > >> > > > "sub-streams" currently configured for cross-repo PRs.
>> > > > > > >> > > >
>> > > > > > >> > > > - kogito-pipelines
>> > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
>> > kogito-examples
>> > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
>> > > > > > >> > > > - kogito-images, and kogito-serverless-operator
>> > > > > > >> > > > - kogito-docs
>> > > > > > >> > > > - kie-docs
>> > > > > > >> > > >
>> > > > > > >> > > > This means that sending cross-repo PRs to any
>> combination
>> > of
>> > > > > repos
>> > > > > > >> > > > that are not part of the same "sub-stream" cannot be
>> > > verified
>> > > > > > before
>> > > > > > >> > > > merging, making our contribution model dependent on
>> > > individual
>> > > > > > >> > > > contributors building stuff on their machines to verify
>> > that
>> > > > it
>> > > > > > >> works.
>> > > > > > >> > > >
>> > > > > > >> > > > I based this analysis on
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
>> > > > > > >> > > > ,
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
>> > > > > > >> > > > ,
>> > > > > > >> > > > and
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
>> > > > > > >> > > > .
>> > > > > > >> > > > Note that I'm not that familiar with these pipelines,
>> so
>> > > > please
>> > > > > > >> > > > someone correct me if I'm wrong.
>> > > > > > >> > > >
>> > > > > > >> > > > Category B repos are what I've been referring to as
>> > > > `kie-tools`
>> > > > > > >> > > > stream. The first repo there is a template repository
>> that
>> > > is
>> > > > > used
>> > > > > > >> by
>> > > > > > >> > > > people starting projects from scratch on KIE Sandbox,
>> > > similar
>> > > > > to a
>> > > > > > >> > > > Maven archetype, if you will. The other one is the KIE
>> > Tools
>> > > > > > >> monorepo,
>> > > > > > >> > > > a polyglot monorepo with `pnpm` as its build system.
>> > > > Currently,
>> > > > > > KIE
>> > > > > > >> > > > Tools hosts Java libraries and apps, TypeScript
>> libraries
>> > > and
>> > > > > > apps,
>> > > > > > >> Go
>> > > > > > >> > > > apps, Docker images, and Helm charts. The `kie-tools`
>> > > monorepo
>> > > > > is
>> > > > > > >> > > > configured to work with sparse checkouts and can do
>> > partial
>> > > > > > builds.
>> > > > > > >> > > > Category B repos refer to Category A repos through
>> > > timestamped
>> > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
>> introduced
>> > > that
>> > > > > > will
>> > > > > > >> > > > build and publish immutable, persistent artifacts
>> under a
>> > > > > version
>> > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format, published
>> > weekly
>> > > > > every
>> > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an evolution to
>> > the
>> > > > > Kogito
>> > > > > > >> > > > releases, as we're now targeting one release for all of
>> > > Apache
>> > > > > > KIE,
>> > > > > > >> so
>> > > > > > >> > > > we can't have Kogito releases anymore.
>> > > > > > >> > > >
>> > > > > > >> > > > An important note here is that Category B repositories
>> > have
>> > > > been
>> > > > > > >> > > > historically kept out of any automations we used to
>> have,
>> > > way
>> > > > > back
>> > > > > > >> > > > when Kogito started and we had the Business Central
>> > (a.k.a.
>> > > > v7)
>> > > > > > >> stream
>> > > > > > >> > > > still going on. For this reason, Category B projects
>> have
>> > > > > > developed
>> > > > > > >> > > > their own automations, based on GitHub Actions.
>> Category B
>> > > > repos
>> > > > > > >> have
>> > > > > > >> > > > always depended on Category A repos using fixed
>> versions.
>> > If
>> > > > > > >> Category
>> > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs, breaking
>> > changes
>> > > > on
>> > > > > > >> > > > Category A repositories would've had the potential to
>> > break
>> > > > > > >> Category B
>> > > > > > >> > > > silently, leaving Category B with a broken development
>> > > stream,
>> > > > > and
>> > > > > > >> > > > introducing unpleasant surprises for maintainers of
>> > > Category B
>> > > > > > >> repos,
>> > > > > > >> > > > as historically Category A contributors were not
>> familiar
>> > > with
>> > > > > > >> > > > Category B repos.
>> > > > > > >> > > >
>> > > > > > >> > > > Contributions made to Category B repos go through a
>> GitHub
>> > > > > Actions
>> > > > > > >> > > > workflow that builds the relevant part of the
>> `kie-tools`
>> > > > > monorepo
>> > > > > > >> for
>> > > > > > >> > > > the changes introduced. Changes made to the pipeline
>> > itself
>> > > > are
>> > > > > > also
>> > > > > > >> > > > picked up as part of PRs, allowing us to do things like
>> > > > > atomically
>> > > > > > >> > > > bumping the Node.js version, for example. More
>> > importantly,
>> > > it
>> > > > > > >> allows
>> > > > > > >> > > > us to upgrade the repository to a new timestamped
>> SNAPSHOT
>> > > > > > together
>> > > > > > >> > > > with the changes necessary to make it stay green.
>> > > > > > >> > > >
>> > > > > > >> > > > This setup, however, makes it impossible to have
>> > cross-repo
>> > > > PRs
>> > > > > > >> > > > involving Category A and Category B simultaneously,
>> with
>> > the
>> > > > > > current
>> > > > > > >> > > > automations we have.
>> > > > > > >> > > >
>> > > > > > >> > > > Category C repos are kind of floating around, and I'm
>> not
>> > > sure
>> > > > > if
>> > > > > > >> > > > there's much activity going on there. Regardless, as
>> > they're
>> > > > > part
>> > > > > > of
>> > > > > > >> > > > Apache KIE, they will be part of our release, so I
>> listed
>> > > them
>> > > > > for
>> > > > > > >> us
>> > > > > > >> > > > to take them into consideration too.
>> > > > > > >> > > >
>> > > > > > >> > > > Category D is self explanatory. There's only one repo
>> that
>> > > has
>> > > > > > >> already
>> > > > > > >> > > > been marked for being archived.
>> > > > > > >> > > >
>> > > > > > >> > > > Category E are repos that do not host code directly,
>> and
>> > are
>> > > > > > either
>> > > > > > >> > > > organizational entities, or host websites, that
>> currently
>> > > are
>> > > > > not
>> > > > > > >> part
>> > > > > > >> > > > of any pipelines we have.
>> > > > > > >> > > >
>> > > > > > >> > > > This lack of unification between Category A and
>> Category B
>> > > is,
>> > > > > > IMHO,
>> > > > > > >> > > > what allowed us to introduce the infamous circular
>> > > dependency
>> > > > > > >> between
>> > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now can
>> describe
>> > as
>> > > a
>> > > > > > >> circular
>> > > > > > >> > > > dependency between Category A and Category B. The way I
>> > see
>> > > > it,
>> > > > > if
>> > > > > > >> we
>> > > > > > >> > > > had a single pipeline, building everything from
>> `drools`
>> > to
>> > > > > > >> > > > `kie-tools`, such flaws would've never been introduced,
>> > and
>> > > we
>> > > > > > >> > > > wouldn't be having this huge problem in our hands right
>> > now.
>> > > > > > >> > > >
>> > > > > > >> > > > My proposal for the Apache KIE release process sees
>> this
>> > > lack
>> > > > of
>> > > > > > >> > > > unification as a central problem, not only for this
>> > release
>> > > in
>> > > > > > >> > > > particular, but for the community as a whole. It is my
>> > > belief
>> > > > > that
>> > > > > > >> we
>> > > > > > >> > > > are all under the same roof, and that no contribution
>> > should
>> > > > be
>> > > > > > >> > > > allowed to break any part of our codebase. With the
>> > > increasing
>> > > > > > >> volume
>> > > > > > >> > > > of code, and hopefully number of contributors too, we
>> > cannot
>> > > > > keep
>> > > > > > >> > > > counting on "common sense" to avoid breaking things.
>> We're
>> > > all
>> > > > > > >> humans
>> > > > > > >> > > > after all, and it is our job to have mechanisms in
>> place
>> > to
>> > > > > > prevent
>> > > > > > >> us
>> > > > > > >> > > > from unwillingly making mistakes. Especially when these
>> > > > mistakes
>> > > > > > >> > > > impact on parts of the codebase that we, individually,
>> > > > probably
>> > > > > > >> can't
>> > > > > > >> > > > fix.
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
>> > > > > > >> > > >
>> > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on
>> > kiegroup's
>> > > > KIE
>> > > > > > >> Tools
>> > > > > > >> > > > `0.32.0`.
>> > > > > > >> > > > See:
>> > > > > > >> > > > -
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > P2. PR open for Kogito SWF images @ `kogito-images`
>> > > depending
>> > > > on
>> > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
>> > > > > > >> > > > See:
>> > > > > > >> > > > -
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's
>> > > `lienzo`
>> > > > > and
>> > > > > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
>> > > > > > >> > > > See:
>> > > > > > >> > > > -
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
>> > > > > > >> > > > -
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > P4. Multiple packages @ `kogito-apps` depending on
>> > > kiegroup's
>> > > > > > >> > > > Explainability `1.22.1.Final`.
>> > > > > > >> > > > * This module was removed from the KIE codebase here:
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
>> > > > > > >> > > > and now lives on
>> > > > > > >> > > >
>> > > > > >
>> https://github.com/trustyai-explainability/trustyai-explainability
>> > ,
>> > > > > > >> > > > under a different GAV.
>> > > > > > >> > > > * This new repo depends on Kogito and OptaPlanner,
>> > pointing
>> > > to
>> > > > > > older
>> > > > > > >> > > > versions.
>> > > > > > >> > > > See:
>> > > > > > >> > > > -
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
>> > > > > > >> > > > -
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator`
>> depending
>> > on
>> > > > > > Kogito
>> > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
>> > > > > > >> > > > See:
>> > > > > > >> > > > -
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > P6. Category C repos are out of date and not part of
>> the
>> > > > > Category
>> > > > > > A
>> > > > > > >> > > > CI/Release pipelines.
>> > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current version is
>> > > > > > >> `2.0-SNAPSHOT`,
>> > > > > > >> > > > depending on Kogito without a specific version, only by
>> > > using
>> > > > > > >> > > > `http://localhost:8080`)
>> > > > > > >> > > > * incubator-kie-benchmarks: (Current version is
>> > > > `1.0-SNAPSHOT`,
>> > > > > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
>> > > > > `8.45.0-SNAPSHOT`)
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E
>> > > > disabled
>> > > > > > >> after
>> > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > In my perspective, P1 and P2 have the same solution, as
>> > they
>> > > > > both
>> > > > > > >> > > > suffer from the circular dependency between Category A
>> and
>> > > > > > Category
>> > > > > > >> B.
>> > > > > > >> > > > As Category A and Category B are both streams that have
>> > been
>> > > > > > really
>> > > > > > >> > > > active, I see this as a blocker, as there are
>> > contributions
>> > > > that
>> > > > > > >> > > > cannot be done, given that Category A depends on
>> Category
>> > B
>> > > > > with a
>> > > > > > >> > > > dephasing of 1 release.
>> > > > > > >> > > >
>> > > > > > >> > > > P3 and P4, although not ideal, can be understood as
>> > > technical
>> > > > > > debt.
>> > > > > > >> > > > Depending on unmaintained projects is something we'll
>> > always
>> > > > be
>> > > > > > >> > > > susceptible to, given time.
>> > > > > > >> > > >
>> > > > > > >> > > > P5 and P6 are easily fixable, as it's just a matter of
>> > > making
>> > > > > them
>> > > > > > >> > > > part of the play.
>> > > > > > >> > > >
>> > > > > > >> > > > P7 is an isolated problem that won't impact the
>> structure
>> > or
>> > > > > > >> anything
>> > > > > > >> > > > that we're talking about here, but it is a regression
>> we
>> > > > > > introduced
>> > > > > > >> > > > recently.
>> > > > > > >> > > >
>> > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE 10,
>> and
>> > > that
>> > > > > P5,
>> > > > > > >> P6,
>> > > > > > >> > > > and P7 have easy fixes, the only problems left to
>> discuss
>> > > are
>> > > > P1
>> > > > > > and
>> > > > > > >> > > > P2, which can't be done without a proper proposal.
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > > > # THE PROPOSAL
>> > > > > > >> > > >
>> > > > > > >> > > > I'll try to be very meticulous here, since from my
>> > > experience,
>> > > > > any
>> > > > > > >> > > > little miscalculation can lead to our release not
>> working
>> > > out
>> > > > in
>> > > > > > the
>> > > > > > >> > > > end. To try and avoid that as much as possible, and
>> make
>> > > > > > everything
>> > > > > > >> we
>> > > > > > >> > > > can to have a successful Apache KIE 10 release, bear
>> with
>> > > me.
>> > > > > I'll
>> > > > > > >> lay
>> > > > > > >> > > > out a timeline of events that need to happen in order
>> for
>> > > our
>> > > > > > >> release
>> > > > > > >> > > > to be published, with all artifacts ending up in the
>> right
>> > > > > places,
>> > > > > > >> but
>> > > > > > >> > > > first, we need to solve problems P1 and P2.
>> > > > > > >> > > >
>> > > > > > >> > > > As you saw at the beginning of this email, all the
>> > attempts
>> > > we
>> > > > > > made
>> > > > > > >> > > > left us with the circular dependency showing up at a
>> > > different
>> > > > > > >> place,
>> > > > > > >> > > > but something all these places have in common is that
>> > > they're
>> > > > > all
>> > > > > > >> > > > after kogito-apps, and before to Category B.
>> > > > > > >> > > >
>> > > > > > >> > > > The first part of my proposal is the following:
>> > > > > > >> > > >
>> > > > > > >> > > > S1. We keep the original plan of moving the Quarkus Dev
>> > UIs
>> > > > from
>> > > > > > >> > > > `kogito-apps` to `kie-tools`, together with Management
>> and
>> > > > Task
>> > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
>> > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
>> > > `kogito-swf-builder`
>> > > > > > images
>> > > > > > >> > > > from `kogito-images` to `kie-tools` too.
>> > > > > > >> > > > S3. We move the entire `kogito-serverless-operator`
>> repo
>> > > > inside
>> > > > > a
>> > > > > > >> new
>> > > > > > >> > > > package on `kie-tools`, keeping Git history.
>> > > > > > >> > > >
>> > > > > > >> > > > Solutions S1, S2, and S3 together solve problems P1 and
>> > P2.
>> > > Of
>> > > > > > >> course
>> > > > > > >> > > > the rest of
>> > > > > > >> https://github.com/apache/incubator-kie-issues/issues/967
>> > > > > > >> > > > would still be done too.
>> > > > > > >> > > >
>> > > > > > >> > > > This doesn't come without consequences, of course, as
>> the
>> > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder` images,
>> and
>> > > the
>> > > > > > >> > > > `kogito-serverless-operator` would be moving from
>> > Category A
>> > > > to
>> > > > > > >> > > > Category B. This move would make them have to reference
>> > > > > Category A
>> > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
>> `kogito-images`
>> > > and
>> > > > > > >> > > > `kogito-serverless-operator` are already their own
>> > > > "sub-stream"
>> > > > > > >> inside
>> > > > > > >> > > > Category A, though, contributions made in a cross-repo
>> > > fashion
>> > > > > to
>> > > > > > >> this
>> > > > > > >> > > > "sub-stream" will continue being possible, now via a
>> > single
>> > > PR
>> > > > > to
>> > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A and
>> > Category
>> > > B
>> > > > > will
>> > > > > > >> > > > continue not being possible, and a 1-week delay between
>> > > > merging
>> > > > > > >> > > > something on Category A and using it on Category B will
>> > > still
>> > > > > > >> happen.
>> > > > > > >> > > >
>> > > > > > >> > > > It's worth mentioning that `kie-tools`, however, does
>> > allow
>> > > > for
>> > > > > > >> sparse
>> > > > > > >> > > > checkouts and partial builds, so working with a subset
>> of
>> > > the
>> > > > > > >> monorepo
>> > > > > > >> > > > is possible and encouraged. Making changes only to
>> > > > > > >> > > > `packages/kn-plugin-workflow`, for example, will have
>> the
>> > PR
>> > > > > > checks
>> > > > > > >> > > > run in < 10 minutes, as you can see here:
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
>> > > > > > >> > > > .
>> > > > > > >> > > > We're not compromising when running partial builds
>> too. We
>> > > > know
>> > > > > > that
>> > > > > > >> > > > the entire repo will continue working even after only
>> > > > building a
>> > > > > > >> small
>> > > > > > >> > > > subset of the changes. Doing partial or full builds is
>> > > > > > automatically
>> > > > > > >> > > > determined by the changes of a PR.
>> > > > > > >> > > >
>> > > > > > >> > > > Keep in mind that, even though I'm proposing we move a
>> > bunch
>> > > > of
>> > > > > > >> > > > additional stuff into `kie-tools`, I see this as a
>> > TEMPORARY
>> > > > > > >> solution
>> > > > > > >> > > > for our codebase. `kie-tools` would host some
>> additional
>> > > stuff
>> > > > > > >> > > > TEMPORARILY so that we can release and continue moving
>> > > > forward.
>> > > > > > >> > > >
>> > > > > > >> > > > As I mentioned on other places, `kie-tools` became a
>> > > polyglot
>> > > > > > >> monorepo
>> > > > > > >> > > > out of necessity, and although I'm really proud of
>> what we
>> > > > > > achieved
>> > > > > > >> > > > there so far, I don't think `kie-tools` has a setup
>> that
>> > is
>> > > > > > suitable
>> > > > > > >> > > > for all the different nuances that compose our
>> community.
>> > > I'm
>> > > > > well
>> > > > > > >> > > > aware that a polyglot monorepo that does not follow
>> > > widespread
>> > > > > > >> > > > conventions will scare some people away, and as much as
>> > > we've
>> > > > > > tried
>> > > > > > >> to
>> > > > > > >> > > > make build instructions clear, we can't always get past
>> > the
>> > > > > > >> prejudice
>> > > > > > >> > > > some people have towards the "front-end" ecosystem.
>> > > > > > >> > > >
>> > > > > > >> > > > With all that said, I keep thinking this is the best
>> > course
>> > > of
>> > > > > > >> action
>> > > > > > >> > > > for us right now. We keep most of our stuff unchanged,
>> we
>> > > > > unblock
>> > > > > > >> the
>> > > > > > >> > > > release, and we have a working setup that will suit us
>> > well
>> > > > > while
>> > > > > > we
>> > > > > > >> > > > discuss and reach a conclusion regarding the future of
>> our
>> > > > > > codebase
>> > > > > > >> > > > structure.
>> > > > > > >> > > >
>> > > > > > >> > > > Let me paint a quick picture here of what our code base
>> > > would
>> > > > > look
>> > > > > > >> > > > like, repository-wise, if my proposal is accepted:
>> > > > > > >> > > >
>> > > > > > >> > > > CATEGORY REPO
>> > > > > > >> > > > =====================
>> > > > > > >> > > > A incubator-kie-kogito-pipelines
>> > > > > > >> > > > A incubator-kie-drools
>> > > > > > >> > > > A incubator-kie-optaplanner
>> > > > > > >> > > > A incubator-kie-optaplanner-quickstarts
>> > > > > > >> > > > A incubator-kie-kogito-runtimes
>> > > > > > >> > > > A incubator-kie-kogito-apps
>> > > > > > >> > > > A incubator-kie-kogito-examples
>> > > > > > >> > > > A incubator-kie-kogito-images
>> > > > > > >> > > > A incubator-kie-kogito-docs
>> > > > > > >> > > > A incubator-kie-kogito-benchmarks
>> > > > > > >> > > > A incubator-kie-docs
>> > > > > > >> > > > A incubator-kie-benchmarks
>> > > > > > >> > > > =====================
>> > > > > > >> > > > B incubator-kie-sandbox-quarkus-accelerator
>> > > > > > >> > > > B incubator-kie-tools
>> > > > > > >> > > > =====================
>> > > > > > >> > > > D incubator-kie-kogito-operator
>> > > > > > >> > > > =====================
>> > > > > > >> > > > E incubator-kie-issues
>> > > > > > >> > > > E incubator-kie-kogito-website
>> > > > > > >> > > > E incubator-kie-website
>> > > > > > >> > > > E incubator-kie-kogito-online
>> > > > > > >> > > > E incubator-kie-kogito-online-staging
>> > > > > > >> > > > =====================
>> > > > > > >> > > >
>> > > > > > >> > > > * Category C becomes part of Category A, and
>> > > > > > >> > > > `kogito-serverless-operator` moves entirely inside
>> > > > `kie-tools`.
>> > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images and
>> > > > > > >> > > > `kogito-serverless-operator` inside `kie-tools`, there
>> are
>> > > no
>> > > > > > cycles
>> > > > > > >> > > > anymore, as inside `kie-tools`, we can granularly
>> build:
>> > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
>> > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
>> > > > > > >> > > > 3. packages/sonataflow-images (containing
>> > > > > `kogito-swf-builder`
>> > > > > > >> and
>> > > > > > >> > > > `kogito-swf-devmode`)
>> > > > > > >> > > > 4. packages/sonataflow-operator (contents from
>> > > > > > >> > > > `kogito-serverless-operator`)
>> > > > > > >> > > > 5. packages/kn-plugin-sonataflow
>> > > > > > (`packages/kn-plugin-workflow`,
>> > > > > > >> > > > but renamed)
>> > > > > > >> > > >
>> > > > > > >> > > > The second part of the proposal is the release process
>> > > itself,
>> > > > > > >> > > > assuming the structure above is what we have.
>> > > > > > >> > > >
>> > > > > > >> > > > Here it is:
>> > > > > > >> > > >
>> > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as cutting
>> > point
>> > > > for
>> > > > > > >> > > > Category A repos.
>> > > > > > >> > > > 2. Update Category B repos to point to this timestamped
>> > > > > SNAPSHOT,
>> > > > > > >> and
>> > > > > > >> > > > verify that everything is working.
>> > > > > > >> > > > 3. At this point, with everything working, we can
>> branch
>> > out
>> > > > to
>> > > > > > >> > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag,
>> > and
>> > > > > > >> Category B
>> > > > > > >> > > > from `main`.
>> > > > > > >> > > > 4. All Category A and Category B repos update their
>> > versions
>> > > > to
>> > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
>> > > > > > >> > > > 5. Update Category B repos to point to Category A repos
>> > > using
>> > > > > the
>> > > > > > >> > > > 10.0.0 version.
>> > > > > > >> > > > 6. At this point, we can vote on the release based on
>> the
>> > > > > `10.0.x`
>> > > > > > >> > > > branches, given we don't expect any code changes
>> anymore.
>> > > > > > >> > > > 7. After voting passes, we're good to start the release
>> > > > process.
>> > > > > > >> > > > 8. Category A repos follow their manual/automated
>> release
>> > > > > process,
>> > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git,
>> and
>> > > built
>> > > > > > >> > > > artifacts pushed to their registries.
>> > > > > > >> > > > 9. We wait a little bit for Category A artifacts to be
>> > > > > propagated
>> > > > > > on
>> > > > > > >> > > > registries. ~1 day.
>> > > > > > >> > > > 10. Category B repos follow their manual/automated
>> release
>> > > > > > process,
>> > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git,
>> and
>> > > built
>> > > > > > >> > > > artifacts pushed to their registries.
>> > > > > > >> > > > 11. Category D repos are ignored.
>> > > > > > >> > > > 12. Category E repos can be manually tagged with 10.0.0
>> > from
>> > > > > their
>> > > > > > >> > > > default branches.
>> > > > > > >> > > >
>> > > > > > >> > > > More needs to be discussed if we're planning to
>> maintain
>> > > > > multiple
>> > > > > > >> > > > release streams in parallel, but I guess it can wait
>> for
>> > > after
>> > > > > > >> Apache
>> > > > > > >> > > > KIE 10.
>> > > > > > >> > > >
>> > > > > > >> > > > Thank you for reading, and I'm looking forward to
>> hearing
>> > > back
>> > > > > > from
>> > > > > > >> > > > everyone.
>> > > > > > >> > > >
>> > > > > > >> > > > Of course, alternative solutions are possible. This
>> email,
>> > > > > > however,
>> > > > > > >> > > > summarizes my view of how we should attack the problem,
>> > > > > > considering
>> > > > > > >> > > > disruption, required effort, the release process
>> itself,
>> > and
>> > > > > > >> history.
>> > > > > > >> > > > Feel free to propose alternatives. This is not a voting
>> > > > thread.
>> > > > > > >> > > >
>> > > > > > >> > > > Regards,
>> > > > > > >> > > >
>> > > > > > >> > > > Tiago Bento
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >>
>> > > >
>> ---------------------------------------------------------------------
>> > > > > > >> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
>> > > > > > >> > > > For additional commands, e-mail:
>> dev-help@kie.apache.org
>> > > > > > >> > > >
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
I do not think estimations should be the only driver to make a decision,
especially when the current proposal is conceptually incompatible with the
multi repo approach that is taken elsewhere in the project.
Given my knowledge of the CI it is nearly impossible for me to give a fair
estimate of how much it might take to achieve step 2) of my previous e-mail
. It might take a while or it might be pretty easy after all, I don't
really know, but I think it will be a good idea if some of the experts on
CI in the team (the ones that set up the pipeline, which was a huge
achievement) give an estimate, not me. Estimating how much it takes to
merge two existing repos (without altering CI) is easier, but it does not
mean we are doing the right thing.
My main concern is that it will be very difficult for me to explain to
someone that arrives new to the team, that having experts on CI on the
team, we decided to merge two repos (once merged, it would be rather
difficult to unmerge) rather than fix the CI, because of expediency.
On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli <po...@apache.org> wrote:
> Francisco,
>
> Please take the time to make the more in depth analysis needed and provide
> a more detailed plan… so we - as community- can evaluate the size of the
> effort. In the conceptual level you shared it’s near impossible to estimate
> the size of the effort and compare with the current proposal.
>
> On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
> ftirados@redhat.com> wrote:
>
> > I think I already did a high level proposal.
> > 1) Remove all dependencies from tooling to images, so images depend on
> > tooling but tooling does not depend on images.
> > 2) Then change CI to deal with tooling repo before dealing with images
> > repo.
> > I understand that CI details are tricky and since I'm not familiar with
> CI
> > in any way, I barely can make a low level design, but we do not need to
> fix
> > everything, just achieve 2), a change of compilation order.
> >
> >
> > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > Francisco and Grabriele,
> > >
> > > You may not like or understand why the current state of the CI is like
> > > that… actually has been in Red Hat and has been replicated in Apache as
> > > used to be….
> > >
> > > But the fact is that this is the current reality.
> > >
> > > If you disagree with the current plan, please provide a detailed
> > > alternative so we, as community, can better evaluate the pros and cons
> of
> > > each proposal.
> > >
> > >
> > > I think it’s also fair to say that, post 10 release we need to have a
> > much
> > > in depth discussion about how our codebase is organized, it’s clear
> that
> > > it’s not working.
> > >
> > >
> > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > > gabriele.cardosi@gmail.com>
> > > wrote:
> > >
> > > > As Francisco said,
> > > > I also have the impression that the "images" (if we are talking of
> > docker
> > > > images) should be the very last one to be built, in a standalone
> repo.
> > > > That way, they may "combine" artifacts that are built in different
> > repos,
> > > > regardless of the order in which those are built.
> > > > Moving them out of all the repos (kogito-apps/kie-tools) maybe could
> > > > simplify the situation a bit.
> > > > (I also think there are some statements of undisputable needs while
> > they
> > > > are, actually, just technical choices.
> > > > Anyway, this latter point is for longer, following, discussion.)
> > > >
> > > >
> > > >
> > > >
> > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier Tirado
> Sarti
> > <
> > > > ftirados@redhat.com> ha scritto:
> > > >
> > > > > Alex,
> > > > > There are two assumptions that deserve further discussion:
> > > > > 1) That tool has to be the last to build. why? it does not have
> more
> > > > sense
> > > > > to build final images after everything else has been built?-
> > > > > 2) That the impact (in terms of effort now) on fixing CI is bigger
> > than
> > > > the
> > > > > impact (long term consequences) of consolidating two unrelated
> piece
> > of
> > > > > software within the same repository.
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > >
> > > > > > Francisco,
> > > > > >
> > > > > > This was discussed as an alternative solution, however it has
> major
> > > > > impact
> > > > > > on CI and there’s also the fact Tool has been always the last to
> > > build
> > > > > and
> > > > > > has no Snapshot published (actually in JavaScript world there is
> no
> > > > > > snapshot concept).
> > > > > >
> > > > > > So, based on our evaluation… the proposal here is the least
> > > disruptive
> > > > > and
> > > > > > will take less time to unblock the release.
> > > > > >
> > > > > > Regards,
> > > > > > _____________
> > > > > > Alex Porcelli
> > > > > > http://porcelli.me
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado Sarti <
> > > > > > ftirados@redhat.com> wrote:
> > > > > >
> > > > > > > After kie-tools, sorry. I think we are not embracing the fact
> > that
> > > > > > > kogito-images depend on kie-tools, because we want those images
> > to
> > > > > > include
> > > > > > > tools.
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado Sarti
> <
> > > > > > > ftirados@redhat.com> wrote:
> > > > > > >
> > > > > > > > Hi Tiago,
> > > > > > > > It can be an alternative solution to move kn-plugin-workflow
> to
> > > > > > > > kogito-images (so there is not longer dependency from tools
> to
> > > > > images)
> > > > > > > and
> > > > > > > > then build kogito-images after kogito-tools?
> > > > > > > >
> > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez <
> > > > > > > > egonzalez@apache.org> wrote:
> > > > > > > >
> > > > > > > >> +1 to unblock release
> > > > > > > >>
> > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > > > > > > pefernan@apache.org>
> > > > > > > >> escribió:
> > > > > > > >>
> > > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > > >> >
> > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> > alex@porcelli.me
> > > >
> > > > > > wrote:
> > > > > > > >> >
> > > > > > > >> > > +1
> > > > > > > >> > >
> > > > > > > >> > > I spent the last day or so working closely with Tiago,
> > > > exploring
> > > > > > > >> > different
> > > > > > > >> > > options and getting deeper on the impact and evaluating
> > the
> > > > > > overall
> > > > > > > >> > release
> > > > > > > >> > > procedure steps required. I agree with the proposal as
> the
> > > > most
> > > > > > > >> > > viable option for unblocking the 10 release in the
> > > reasonable
> > > > > time
> > > > > > > >> frame.
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > > tiagobento@apache.org>
> > > > > > > >> > wrote:
> > > > > > > >> > >
> > > > > > > >> > > > Hi everyone,
> > > > > > > >> > > >
> > > > > > > >> > > > Unfortunately, I can't do a tl;dr this time, as this
> > > matter
> > > > > > > >> requires a
> > > > > > > >> > > > lot of context.
> > > > > > > >> > > >
> > > > > > > >> > > > This email will take you < 20 minutes to read,
> according
> > > to
> > > > > > > >> > > > https://thereadtime.com/.
> > > > > > > >> > > >
> > > > > > > >> > > > As you may have followed on a separate thread
> > > > > > > >> > > > (
> > > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > > ),
> > > > > > > >> > > > many of us were working towards removing a circular
> > > > dependency
> > > > > > > >> > > > currently present between `kogito-apps` and
> `kie-tools`.
> > > As
> > > > we
> > > > > > > >> > > > progressed towards a solution, we kept finding the
> > > circular
> > > > > > > >> dependency
> > > > > > > >> > > > pop up somewhere else. I'll do a breakdown of the
> things
> > > we
> > > > > did,
> > > > > > > and
> > > > > > > >> > > > the results we had.
> > > > > > > >> > > >
> > > > > > > >> > > > Right now, even though we started the effort to move
> the
> > > > > Quarkus
> > > > > > > Dev
> > > > > > > >> > > > UI modules to `kie-tools`, we haven't been able to do
> it
> > > > yet,
> > > > > as
> > > > > > > >> we've
> > > > > > > >> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6,
> > and
> > > > > > Quarkus
> > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > > 999-20240218-SNAPSHOT.
> > > > > > This
> > > > > > > >> > > > effort was concluded this Monday, with
> > > > > > > >> > > >
> https://github.com/apache/incubator-kie-tools/pull/2136
> > .
> > > > > > > >> > > >
> > > > > > > >> > > > The current scenario we have is:
> > > > > > > >> > > >
> > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > > >> > > > C | 03. incubator-kie-kogito-examples
> > > > > > > >> > > > Y | 04. incubator-kie-kogito-images
> > > > > > > >> > > > C | 05.
> > > incubator-kie-kogito-serverless-operator
> > > > > > > >> > > > L | ==========================
> > > > > > > >> > > > E | 06.
> > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > * As `kie-tools`/extended-services depends on
> > > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > > >> > > > * and
> > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > > depend
> > > > > > > >> on
> > > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`, we
> > > would've
> > > > > > had:
> > > > > > > >> > > >
> > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > > >> > > > Y | 05.
> > > incubator-kie-kogito-serverless-operator
> > > > > > > >> > > > C | =====================
> > > > > > > >> > > > L | 06.
> > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > > >> > > >
> > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > > >> > > > * and `kogito-images`/kogito-swf-devmode
> depends
> > > on
> > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > > `kie-tools`,
> > > > we
> > > > > > > >> would've
> > > > > > > >> > > > had:
> > > > > > > >> > > >
> > > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > > > >> > > > 04. incubator-kie-kogito-images
> > > > > > > >> > > > C |==> 05.
> > incubator-kie-kogito-serverless-operator
> > > > > > > >> > > > Y | =====================
> > > > > > > >> > > > C | 06.
> > > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > > >> > > > E
> > > > > > > >> > > >
> > > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > > >> > > > * and `kogito-serverless-operator` depends on
> > > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > Clearly, we have a much bigger problem than a simple
> > > > circular
> > > > > > > >> > dependency.
> > > > > > > >> > > >
> > > > > > > >> > > > After multiple conversations with a lot of people,
> it's
> > > been
> > > > > > > really
> > > > > > > >> > > > hard coming up with a simple solution that makes it
> > > possible
> > > > > to
> > > > > > > >> build
> > > > > > > >> > > > Apache KIE in one shot, while preserving the way
> > everyone
> > > is
> > > > > > used
> > > > > > > to
> > > > > > > >> > > > contributing to the multiple repositories we have.
> More
> > > than
> > > > > > that,
> > > > > > > >> > > > while making this assessment, I found more problems
> > that,
> > > in
> > > > > my
> > > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > > >> > > >
> > > > > > > >> > > > In light of that difficulty, I'm coming forward with
> my
> > > > > proposal
> > > > > > > for
> > > > > > > >> > > > the Apache KIE release process, so we can use Apache's
> > > > > > mechanisms
> > > > > > > to
> > > > > > > >> > > > have a slower-paced, in-depth debate about this really
> > > > > > complicated
> > > > > > > >> > > > matter.
> > > > > > > >> > > >
> > > > > > > >> > > > I'll lay out my entire perspective about the current
> > > > situation
> > > > > > of
> > > > > > > >> our
> > > > > > > >> > > > codebase, as well as problems I can currently see.
> I'll
> > > > start
> > > > > > with
> > > > > > > >> an
> > > > > > > >> > > > analysis of the repositories and their purposes, point
> > out
> > > > > some
> > > > > > > >> > > > problems that I believe are blocking our 10 release,
> > > explain
> > > > > my
> > > > > > > >> > > > proposal and discuss some consequences to what I'm
> > > > proposing.
> > > > > > > >> > > >
> > > > > > > >> > > > Let's begin.
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > > >> > > >
> > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > > >> > > > - incubator-kie-kogito-serverless-operator @ `main`
> > > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > > >> > > >
> > > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > > >> > > >
> > > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > > >> > > >
> > > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > > >> > > >
> > > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > > >> > > > (Issues only, README should be updated @ `main`.
> > Same
> > > > for
> > > > > > > GitHub
> > > > > > > >> > > > Actions workflows.)
> > > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > > >> > > > (The Kogito website. Develop & deploy at the
> `main`
> > > > > branch.)
> > > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > > >> > > > (The KIE website. Develop @ `main`. Push @
> `deploy`
> > to
> > > > > > update
> > > > > > > >> the
> > > > > > > >> > > > website.)
> > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > > >> > > > (GitHub pages used to host sandbox.kie.org and
> KIE
> > > > Tools'
> > > > > > > >> Chrome
> > > > > > > >> > > > Extension assets.)
> > > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > > >> > > > (Same as above, but for manual sanity checks
> during
> > > the
> > > > > > > staging
> > > > > > > >> > > > phase of a release.)
> > > > > > > >> > > >
> > > > > > > >> > > > TOTAL (count: 21)
> > > > > > > >> > > >
> > > > > > > >> > > > I grouped the repositories by category, and listed
> them
> > > in a
> > > > > > > >> > > > topological order. Keep in mind that when flattening
> > out a
> > > > > tree,
> > > > > > > >> there
> > > > > > > >> > > > are multiple possibilities. For example, OptaPlanner
> > > > could've
> > > > > > been
> > > > > > > >> > > > placed in any position after Drools.
> > > > > > > >> > > >
> > > > > > > >> > > > Category A repos are what I've been referring to as
> > > `drools`
> > > > > and
> > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is inside
> that
> > > > > stream,
> > > > > > as
> > > > > > > >> the
> > > > > > > >> > > > way these repositories reference each other are
> through
> > > > Maven
> > > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT
> version.
> > > This
> > > > > > > >> mechanism
> > > > > > > >> > > > is well-known to the team, and although flawed for
> > > intra-day
> > > > > > > builds
> > > > > > > >> > > > and disruptive for people in many different time
> zones,
> > it
> > > > is
> > > > > > > >> already
> > > > > > > >> > > > very comfortable for everyone to work with, I assume.
> > > > > > > >> > > >
> > > > > > > >> > > > Contributions made to Category A have some dedicated
> > > > > pipelines,
> > > > > > > >> which
> > > > > > > >> > > > are, at least to some extent, able to build cross-repo
> > PRs
> > > > > > > together
> > > > > > > >> > > > and verify that the codebase will continue working as
> > > > expected
> > > > > > > after
> > > > > > > >> > > > they're all merged. From what I could gather, there
> are
> > > some
> > > > > > > >> > > > "sub-streams" currently configured for cross-repo PRs.
> > > > > > > >> > > >
> > > > > > > >> > > > - kogito-pipelines
> > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > > kogito-examples
> > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > > >> > > > - kogito-images, and kogito-serverless-operator
> > > > > > > >> > > > - kogito-docs
> > > > > > > >> > > > - kie-docs
> > > > > > > >> > > >
> > > > > > > >> > > > This means that sending cross-repo PRs to any
> > combination
> > > of
> > > > > > repos
> > > > > > > >> > > > that are not part of the same "sub-stream" cannot be
> > > > verified
> > > > > > > before
> > > > > > > >> > > > merging, making our contribution model dependent on
> > > > individual
> > > > > > > >> > > > contributors building stuff on their machines to
> verify
> > > that
> > > > > it
> > > > > > > >> works.
> > > > > > > >> > > >
> > > > > > > >> > > > I based this analysis on
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > > >> > > > ,
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > > >> > > > ,
> > > > > > > >> > > > and
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > > >> > > > .
> > > > > > > >> > > > Note that I'm not that familiar with these pipelines,
> so
> > > > > please
> > > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > > >> > > >
> > > > > > > >> > > > Category B repos are what I've been referring to as
> > > > > `kie-tools`
> > > > > > > >> > > > stream. The first repo there is a template repository
> > that
> > > > is
> > > > > > used
> > > > > > > >> by
> > > > > > > >> > > > people starting projects from scratch on KIE Sandbox,
> > > > similar
> > > > > > to a
> > > > > > > >> > > > Maven archetype, if you will. The other one is the KIE
> > > Tools
> > > > > > > >> monorepo,
> > > > > > > >> > > > a polyglot monorepo with `pnpm` as its build system.
> > > > > Currently,
> > > > > > > KIE
> > > > > > > >> > > > Tools hosts Java libraries and apps, TypeScript
> > libraries
> > > > and
> > > > > > > apps,
> > > > > > > >> Go
> > > > > > > >> > > > apps, Docker images, and Helm charts. The `kie-tools`
> > > > monorepo
> > > > > > is
> > > > > > > >> > > > configured to work with sparse checkouts and can do
> > > partial
> > > > > > > builds.
> > > > > > > >> > > > Category B repos refer to Category A repos through
> > > > timestamped
> > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> > introduced
> > > > that
> > > > > > > will
> > > > > > > >> > > > build and publish immutable, persistent artifacts
> under
> > a
> > > > > > version
> > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format, published
> > > weekly
> > > > > > every
> > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an evolution
> to
> > > the
> > > > > > Kogito
> > > > > > > >> > > > releases, as we're now targeting one release for all
> of
> > > > Apache
> > > > > > > KIE,
> > > > > > > >> so
> > > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > > >> > > >
> > > > > > > >> > > > An important note here is that Category B repositories
> > > have
> > > > > been
> > > > > > > >> > > > historically kept out of any automations we used to
> > have,
> > > > way
> > > > > > back
> > > > > > > >> > > > when Kogito started and we had the Business Central
> > > (a.k.a.
> > > > > v7)
> > > > > > > >> stream
> > > > > > > >> > > > still going on. For this reason, Category B projects
> > have
> > > > > > > developed
> > > > > > > >> > > > their own automations, based on GitHub Actions.
> > Category B
> > > > > repos
> > > > > > > >> have
> > > > > > > >> > > > always depended on Category A repos using fixed
> > versions.
> > > If
> > > > > > > >> Category
> > > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs, breaking
> > > changes
> > > > > on
> > > > > > > >> > > > Category A repositories would've had the potential to
> > > break
> > > > > > > >> Category B
> > > > > > > >> > > > silently, leaving Category B with a broken development
> > > > stream,
> > > > > > and
> > > > > > > >> > > > introducing unpleasant surprises for maintainers of
> > > > Category B
> > > > > > > >> repos,
> > > > > > > >> > > > as historically Category A contributors were not
> > familiar
> > > > with
> > > > > > > >> > > > Category B repos.
> > > > > > > >> > > >
> > > > > > > >> > > > Contributions made to Category B repos go through a
> > GitHub
> > > > > > Actions
> > > > > > > >> > > > workflow that builds the relevant part of the
> > `kie-tools`
> > > > > > monorepo
> > > > > > > >> for
> > > > > > > >> > > > the changes introduced. Changes made to the pipeline
> > > itself
> > > > > are
> > > > > > > also
> > > > > > > >> > > > picked up as part of PRs, allowing us to do things
> like
> > > > > > atomically
> > > > > > > >> > > > bumping the Node.js version, for example. More
> > > importantly,
> > > > it
> > > > > > > >> allows
> > > > > > > >> > > > us to upgrade the repository to a new timestamped
> > SNAPSHOT
> > > > > > > together
> > > > > > > >> > > > with the changes necessary to make it stay green.
> > > > > > > >> > > >
> > > > > > > >> > > > This setup, however, makes it impossible to have
> > > cross-repo
> > > > > PRs
> > > > > > > >> > > > involving Category A and Category B simultaneously,
> with
> > > the
> > > > > > > current
> > > > > > > >> > > > automations we have.
> > > > > > > >> > > >
> > > > > > > >> > > > Category C repos are kind of floating around, and I'm
> > not
> > > > sure
> > > > > > if
> > > > > > > >> > > > there's much activity going on there. Regardless, as
> > > they're
> > > > > > part
> > > > > > > of
> > > > > > > >> > > > Apache KIE, they will be part of our release, so I
> > listed
> > > > them
> > > > > > for
> > > > > > > >> us
> > > > > > > >> > > > to take them into consideration too.
> > > > > > > >> > > >
> > > > > > > >> > > > Category D is self explanatory. There's only one repo
> > that
> > > > has
> > > > > > > >> already
> > > > > > > >> > > > been marked for being archived.
> > > > > > > >> > > >
> > > > > > > >> > > > Category E are repos that do not host code directly,
> and
> > > are
> > > > > > > either
> > > > > > > >> > > > organizational entities, or host websites, that
> > currently
> > > > are
> > > > > > not
> > > > > > > >> part
> > > > > > > >> > > > of any pipelines we have.
> > > > > > > >> > > >
> > > > > > > >> > > > This lack of unification between Category A and
> > Category B
> > > > is,
> > > > > > > IMHO,
> > > > > > > >> > > > what allowed us to introduce the infamous circular
> > > > dependency
> > > > > > > >> between
> > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now can
> describe
> > > as
> > > > a
> > > > > > > >> circular
> > > > > > > >> > > > dependency between Category A and Category B. The way
> I
> > > see
> > > > > it,
> > > > > > if
> > > > > > > >> we
> > > > > > > >> > > > had a single pipeline, building everything from
> `drools`
> > > to
> > > > > > > >> > > > `kie-tools`, such flaws would've never been
> introduced,
> > > and
> > > > we
> > > > > > > >> > > > wouldn't be having this huge problem in our hands
> right
> > > now.
> > > > > > > >> > > >
> > > > > > > >> > > > My proposal for the Apache KIE release process sees
> this
> > > > lack
> > > > > of
> > > > > > > >> > > > unification as a central problem, not only for this
> > > release
> > > > in
> > > > > > > >> > > > particular, but for the community as a whole. It is my
> > > > belief
> > > > > > that
> > > > > > > >> we
> > > > > > > >> > > > are all under the same roof, and that no contribution
> > > should
> > > > > be
> > > > > > > >> > > > allowed to break any part of our codebase. With the
> > > > increasing
> > > > > > > >> volume
> > > > > > > >> > > > of code, and hopefully number of contributors too, we
> > > cannot
> > > > > > keep
> > > > > > > >> > > > counting on "common sense" to avoid breaking things.
> > We're
> > > > all
> > > > > > > >> humans
> > > > > > > >> > > > after all, and it is our job to have mechanisms in
> place
> > > to
> > > > > > > prevent
> > > > > > > >> us
> > > > > > > >> > > > from unwillingly making mistakes. Especially when
> these
> > > > > mistakes
> > > > > > > >> > > > impact on parts of the codebase that we, individually,
> > > > > probably
> > > > > > > >> can't
> > > > > > > >> > > > fix.
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > > >> > > >
> > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on
> > > kiegroup's
> > > > > KIE
> > > > > > > >> Tools
> > > > > > > >> > > > `0.32.0`.
> > > > > > > >> > > > See:
> > > > > > > >> > > > -
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > P2. PR open for Kogito SWF images @ `kogito-images`
> > > > depending
> > > > > on
> > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > > >> > > > See:
> > > > > > > >> > > > -
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's
> > > > `lienzo`
> > > > > > and
> > > > > > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > > > > >> > > > See:
> > > > > > > >> > > > -
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > > >> > > > -
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > P4. Multiple packages @ `kogito-apps` depending on
> > > > kiegroup's
> > > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > > >> > > > * This module was removed from the KIE codebase here:
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > > >> > > > and now lives on
> > > > > > > >> > > >
> > > > > > >
> > https://github.com/trustyai-explainability/trustyai-explainability
> > > ,
> > > > > > > >> > > > under a different GAV.
> > > > > > > >> > > > * This new repo depends on Kogito and OptaPlanner,
> > > pointing
> > > > to
> > > > > > > older
> > > > > > > >> > > > versions.
> > > > > > > >> > > > See:
> > > > > > > >> > > > -
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > > >> > > > -
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator`
> > depending
> > > on
> > > > > > > Kogito
> > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > > >> > > > See:
> > > > > > > >> > > > -
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > P6. Category C repos are out of date and not part of
> the
> > > > > > Category
> > > > > > > A
> > > > > > > >> > > > CI/Release pipelines.
> > > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current version is
> > > > > > > >> `2.0-SNAPSHOT`,
> > > > > > > >> > > > depending on Kogito without a specific version, only
> by
> > > > using
> > > > > > > >> > > > `http://localhost:8080`)
> > > > > > > >> > > > * incubator-kie-benchmarks: (Current version is
> > > > > `1.0-SNAPSHOT`,
> > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> > > > > > `8.45.0-SNAPSHOT`)
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its
> E2E
> > > > > disabled
> > > > > > > >> after
> > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > In my perspective, P1 and P2 have the same solution,
> as
> > > they
> > > > > > both
> > > > > > > >> > > > suffer from the circular dependency between Category A
> > and
> > > > > > > Category
> > > > > > > >> B.
> > > > > > > >> > > > As Category A and Category B are both streams that
> have
> > > been
> > > > > > > really
> > > > > > > >> > > > active, I see this as a blocker, as there are
> > > contributions
> > > > > that
> > > > > > > >> > > > cannot be done, given that Category A depends on
> > Category
> > > B
> > > > > > with a
> > > > > > > >> > > > dephasing of 1 release.
> > > > > > > >> > > >
> > > > > > > >> > > > P3 and P4, although not ideal, can be understood as
> > > > technical
> > > > > > > debt.
> > > > > > > >> > > > Depending on unmaintained projects is something we'll
> > > always
> > > > > be
> > > > > > > >> > > > susceptible to, given time.
> > > > > > > >> > > >
> > > > > > > >> > > > P5 and P6 are easily fixable, as it's just a matter of
> > > > making
> > > > > > them
> > > > > > > >> > > > part of the play.
> > > > > > > >> > > >
> > > > > > > >> > > > P7 is an isolated problem that won't impact the
> > structure
> > > or
> > > > > > > >> anything
> > > > > > > >> > > > that we're talking about here, but it is a regression
> we
> > > > > > > introduced
> > > > > > > >> > > > recently.
> > > > > > > >> > > >
> > > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE 10,
> and
> > > > that
> > > > > > P5,
> > > > > > > >> P6,
> > > > > > > >> > > > and P7 have easy fixes, the only problems left to
> > discuss
> > > > are
> > > > > P1
> > > > > > > and
> > > > > > > >> > > > P2, which can't be done without a proper proposal.
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > # THE PROPOSAL
> > > > > > > >> > > >
> > > > > > > >> > > > I'll try to be very meticulous here, since from my
> > > > experience,
> > > > > > any
> > > > > > > >> > > > little miscalculation can lead to our release not
> > working
> > > > out
> > > > > in
> > > > > > > the
> > > > > > > >> > > > end. To try and avoid that as much as possible, and
> make
> > > > > > > everything
> > > > > > > >> we
> > > > > > > >> > > > can to have a successful Apache KIE 10 release, bear
> > with
> > > > me.
> > > > > > I'll
> > > > > > > >> lay
> > > > > > > >> > > > out a timeline of events that need to happen in order
> > for
> > > > our
> > > > > > > >> release
> > > > > > > >> > > > to be published, with all artifacts ending up in the
> > right
> > > > > > places,
> > > > > > > >> but
> > > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > > >> > > >
> > > > > > > >> > > > As you saw at the beginning of this email, all the
> > > attempts
> > > > we
> > > > > > > made
> > > > > > > >> > > > left us with the circular dependency showing up at a
> > > > different
> > > > > > > >> place,
> > > > > > > >> > > > but something all these places have in common is that
> > > > they're
> > > > > > all
> > > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > > >> > > >
> > > > > > > >> > > > The first part of my proposal is the following:
> > > > > > > >> > > >
> > > > > > > >> > > > S1. We keep the original plan of moving the Quarkus
> Dev
> > > UIs
> > > > > from
> > > > > > > >> > > > `kogito-apps` to `kie-tools`, together with Management
> > and
> > > > > Task
> > > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > > `kogito-swf-builder`
> > > > > > > images
> > > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > > >> > > > S3. We move the entire `kogito-serverless-operator`
> repo
> > > > > inside
> > > > > > a
> > > > > > > >> new
> > > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > > >> > > >
> > > > > > > >> > > > Solutions S1, S2, and S3 together solve problems P1
> and
> > > P2.
> > > > Of
> > > > > > > >> course
> > > > > > > >> > > > the rest of
> > > > > > > >> https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > > >> > > > would still be done too.
> > > > > > > >> > > >
> > > > > > > >> > > > This doesn't come without consequences, of course, as
> > the
> > > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder` images,
> > and
> > > > the
> > > > > > > >> > > > `kogito-serverless-operator` would be moving from
> > > Category A
> > > > > to
> > > > > > > >> > > > Category B. This move would make them have to
> reference
> > > > > > Category A
> > > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> > `kogito-images`
> > > > and
> > > > > > > >> > > > `kogito-serverless-operator` are already their own
> > > > > "sub-stream"
> > > > > > > >> inside
> > > > > > > >> > > > Category A, though, contributions made in a cross-repo
> > > > fashion
> > > > > > to
> > > > > > > >> this
> > > > > > > >> > > > "sub-stream" will continue being possible, now via a
> > > single
> > > > PR
> > > > > > to
> > > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A and
> > > Category
> > > > B
> > > > > > will
> > > > > > > >> > > > continue not being possible, and a 1-week delay
> between
> > > > > merging
> > > > > > > >> > > > something on Category A and using it on Category B
> will
> > > > still
> > > > > > > >> happen.
> > > > > > > >> > > >
> > > > > > > >> > > > It's worth mentioning that `kie-tools`, however, does
> > > allow
> > > > > for
> > > > > > > >> sparse
> > > > > > > >> > > > checkouts and partial builds, so working with a subset
> > of
> > > > the
> > > > > > > >> monorepo
> > > > > > > >> > > > is possible and encouraged. Making changes only to
> > > > > > > >> > > > `packages/kn-plugin-workflow`, for example, will have
> > the
> > > PR
> > > > > > > checks
> > > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > > >> > > > .
> > > > > > > >> > > > We're not compromising when running partial builds
> too.
> > We
> > > > > know
> > > > > > > that
> > > > > > > >> > > > the entire repo will continue working even after only
> > > > > building a
> > > > > > > >> small
> > > > > > > >> > > > subset of the changes. Doing partial or full builds is
> > > > > > > automatically
> > > > > > > >> > > > determined by the changes of a PR.
> > > > > > > >> > > >
> > > > > > > >> > > > Keep in mind that, even though I'm proposing we move a
> > > bunch
> > > > > of
> > > > > > > >> > > > additional stuff into `kie-tools`, I see this as a
> > > TEMPORARY
> > > > > > > >> solution
> > > > > > > >> > > > for our codebase. `kie-tools` would host some
> additional
> > > > stuff
> > > > > > > >> > > > TEMPORARILY so that we can release and continue moving
> > > > > forward.
> > > > > > > >> > > >
> > > > > > > >> > > > As I mentioned on other places, `kie-tools` became a
> > > > polyglot
> > > > > > > >> monorepo
> > > > > > > >> > > > out of necessity, and although I'm really proud of
> what
> > we
> > > > > > > achieved
> > > > > > > >> > > > there so far, I don't think `kie-tools` has a setup
> that
> > > is
> > > > > > > suitable
> > > > > > > >> > > > for all the different nuances that compose our
> > community.
> > > > I'm
> > > > > > well
> > > > > > > >> > > > aware that a polyglot monorepo that does not follow
> > > > widespread
> > > > > > > >> > > > conventions will scare some people away, and as much
> as
> > > > we've
> > > > > > > tried
> > > > > > > >> to
> > > > > > > >> > > > make build instructions clear, we can't always get
> past
> > > the
> > > > > > > >> prejudice
> > > > > > > >> > > > some people have towards the "front-end" ecosystem.
> > > > > > > >> > > >
> > > > > > > >> > > > With all that said, I keep thinking this is the best
> > > course
> > > > of
> > > > > > > >> action
> > > > > > > >> > > > for us right now. We keep most of our stuff unchanged,
> > we
> > > > > > unblock
> > > > > > > >> the
> > > > > > > >> > > > release, and we have a working setup that will suit us
> > > well
> > > > > > while
> > > > > > > we
> > > > > > > >> > > > discuss and reach a conclusion regarding the future of
> > our
> > > > > > > codebase
> > > > > > > >> > > > structure.
> > > > > > > >> > > >
> > > > > > > >> > > > Let me paint a quick picture here of what our code
> base
> > > > would
> > > > > > look
> > > > > > > >> > > > like, repository-wise, if my proposal is accepted:
> > > > > > > >> > > >
> > > > > > > >> > > > CATEGORY REPO
> > > > > > > >> > > > =====================
> > > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > > >> > > > A incubator-kie-drools
> > > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > > >> > > > A incubator-kie-optaplanner-quickstarts
> > > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > > >> > > > A incubator-kie-docs
> > > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > > >> > > > =====================
> > > > > > > >> > > > B incubator-kie-sandbox-quarkus-accelerator
> > > > > > > >> > > > B incubator-kie-tools
> > > > > > > >> > > > =====================
> > > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > > >> > > > =====================
> > > > > > > >> > > > E incubator-kie-issues
> > > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > > >> > > > E incubator-kie-website
> > > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > > >> > > > E incubator-kie-kogito-online-staging
> > > > > > > >> > > > =====================
> > > > > > > >> > > >
> > > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > > >> > > > `kogito-serverless-operator` moves entirely inside
> > > > > `kie-tools`.
> > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > > > > >> > > > `kogito-serverless-operator` inside `kie-tools`, there
> > are
> > > > no
> > > > > > > cycles
> > > > > > > >> > > > anymore, as inside `kie-tools`, we can granularly
> build:
> > > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > > `kogito-swf-builder`
> > > > > > > >> and
> > > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > > >> > > > 4. packages/sonataflow-operator (contents from
> > > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > > (`packages/kn-plugin-workflow`,
> > > > > > > >> > > > but renamed)
> > > > > > > >> > > >
> > > > > > > >> > > > The second part of the proposal is the release process
> > > > itself,
> > > > > > > >> > > > assuming the structure above is what we have.
> > > > > > > >> > > >
> > > > > > > >> > > > Here it is:
> > > > > > > >> > > >
> > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as cutting
> > > point
> > > > > for
> > > > > > > >> > > > Category A repos.
> > > > > > > >> > > > 2. Update Category B repos to point to this
> timestamped
> > > > > > SNAPSHOT,
> > > > > > > >> and
> > > > > > > >> > > > verify that everything is working.
> > > > > > > >> > > > 3. At this point, with everything working, we can
> branch
> > > out
> > > > > to
> > > > > > > >> > > > `10.0.x`. Category A from the timestamped SNAPSHOT
> tag,
> > > and
> > > > > > > >> Category B
> > > > > > > >> > > > from `main`.
> > > > > > > >> > > > 4. All Category A and Category B repos update their
> > > versions
> > > > > to
> > > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > > >> > > > 5. Update Category B repos to point to Category A
> repos
> > > > using
> > > > > > the
> > > > > > > >> > > > 10.0.0 version.
> > > > > > > >> > > > 6. At this point, we can vote on the release based on
> > the
> > > > > > `10.0.x`
> > > > > > > >> > > > branches, given we don't expect any code changes
> > anymore.
> > > > > > > >> > > > 7. After voting passes, we're good to start the
> release
> > > > > process.
> > > > > > > >> > > > 8. Category A repos follow their manual/automated
> > release
> > > > > > process,
> > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git,
> and
> > > > built
> > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > >> > > > 9. We wait a little bit for Category A artifacts to be
> > > > > > propagated
> > > > > > > on
> > > > > > > >> > > > registries. ~1 day.
> > > > > > > >> > > > 10. Category B repos follow their manual/automated
> > release
> > > > > > > process,
> > > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git,
> and
> > > > built
> > > > > > > >> > > > artifacts pushed to their registries.
> > > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > > >> > > > 12. Category E repos can be manually tagged with
> 10.0.0
> > > from
> > > > > > their
> > > > > > > >> > > > default branches.
> > > > > > > >> > > >
> > > > > > > >> > > > More needs to be discussed if we're planning to
> maintain
> > > > > > multiple
> > > > > > > >> > > > release streams in parallel, but I guess it can wait
> for
> > > > after
> > > > > > > >> Apache
> > > > > > > >> > > > KIE 10.
> > > > > > > >> > > >
> > > > > > > >> > > > Thank you for reading, and I'm looking forward to
> > hearing
> > > > back
> > > > > > > from
> > > > > > > >> > > > everyone.
> > > > > > > >> > > >
> > > > > > > >> > > > Of course, alternative solutions are possible. This
> > email,
> > > > > > > however,
> > > > > > > >> > > > summarizes my view of how we should attack the
> problem,
> > > > > > > considering
> > > > > > > >> > > > disruption, required effort, the release process
> itself,
> > > and
> > > > > > > >> history.
> > > > > > > >> > > > Feel free to propose alternatives. This is not a
> voting
> > > > > thread.
> > > > > > > >> > > >
> > > > > > > >> > > > Regards,
> > > > > > > >> > > >
> > > > > > > >> > > > Tiago Bento
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >>
> > > > >
> ---------------------------------------------------------------------
> > > > > > > >> > > > To unsubscribe, e-mail:
> dev-unsubscribe@kie.apache.org
> > > > > > > >> > > > For additional commands, e-mail:
> > dev-help@kie.apache.org
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <po...@apache.org>.
Francisco,
Please take the time to make the more in depth analysis needed and provide
a more detailed plan… so we - as community- can evaluate the size of the
effort. In the conceptual level you shared it’s near impossible to estimate
the size of the effort and compare with the current proposal.
On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti <
ftirados@redhat.com> wrote:
> I think I already did a high level proposal.
> 1) Remove all dependencies from tooling to images, so images depend on
> tooling but tooling does not depend on images.
> 2) Then change CI to deal with tooling repo before dealing with images
> repo.
> I understand that CI details are tricky and since I'm not familiar with CI
> in any way, I barely can make a low level design, but we do not need to fix
> everything, just achieve 2), a change of compilation order.
>
>
> On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <al...@porcelli.me> wrote:
>
> > Francisco and Grabriele,
> >
> > You may not like or understand why the current state of the CI is like
> > that… actually has been in Red Hat and has been replicated in Apache as
> > used to be….
> >
> > But the fact is that this is the current reality.
> >
> > If you disagree with the current plan, please provide a detailed
> > alternative so we, as community, can better evaluate the pros and cons of
> > each proposal.
> >
> >
> > I think it’s also fair to say that, post 10 release we need to have a
> much
> > in depth discussion about how our codebase is organized, it’s clear that
> > it’s not working.
> >
> >
> > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> > gabriele.cardosi@gmail.com>
> > wrote:
> >
> > > As Francisco said,
> > > I also have the impression that the "images" (if we are talking of
> docker
> > > images) should be the very last one to be built, in a standalone repo.
> > > That way, they may "combine" artifacts that are built in different
> repos,
> > > regardless of the order in which those are built.
> > > Moving them out of all the repos (kogito-apps/kie-tools) maybe could
> > > simplify the situation a bit.
> > > (I also think there are some statements of undisputable needs while
> they
> > > are, actually, just technical choices.
> > > Anyway, this latter point is for longer, following, discussion.)
> > >
> > >
> > >
> > >
> > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier Tirado Sarti
> <
> > > ftirados@redhat.com> ha scritto:
> > >
> > > > Alex,
> > > > There are two assumptions that deserve further discussion:
> > > > 1) That tool has to be the last to build. why? it does not have more
> > > sense
> > > > to build final images after everything else has been built?-
> > > > 2) That the impact (in terms of effort now) on fixing CI is bigger
> than
> > > the
> > > > impact (long term consequences) of consolidating two unrelated piece
> of
> > > > software within the same repository.
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <al...@porcelli.me>
> > wrote:
> > > >
> > > > > Francisco,
> > > > >
> > > > > This was discussed as an alternative solution, however it has major
> > > > impact
> > > > > on CI and there’s also the fact Tool has been always the last to
> > build
> > > > and
> > > > > has no Snapshot published (actually in JavaScript world there is no
> > > > > snapshot concept).
> > > > >
> > > > > So, based on our evaluation… the proposal here is the least
> > disruptive
> > > > and
> > > > > will take less time to unblock the release.
> > > > >
> > > > > Regards,
> > > > > _____________
> > > > > Alex Porcelli
> > > > > http://porcelli.me
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado Sarti <
> > > > > ftirados@redhat.com> wrote:
> > > > >
> > > > > > After kie-tools, sorry. I think we are not embracing the fact
> that
> > > > > > kogito-images depend on kie-tools, because we want those images
> to
> > > > > include
> > > > > > tools.
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado Sarti <
> > > > > > ftirados@redhat.com> wrote:
> > > > > >
> > > > > > > Hi Tiago,
> > > > > > > It can be an alternative solution to move kn-plugin-workflow to
> > > > > > > kogito-images (so there is not longer dependency from tools to
> > > > images)
> > > > > > and
> > > > > > > then build kogito-images after kogito-tools?
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez <
> > > > > > > egonzalez@apache.org> wrote:
> > > > > > >
> > > > > > >> +1 to unblock release
> > > > > > >>
> > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > > > > > pefernan@apache.org>
> > > > > > >> escribió:
> > > > > > >>
> > > > > > >> > I say +1 in order to move forward with the 10.
> > > > > > >> >
> > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <
> alex@porcelli.me
> > >
> > > > > wrote:
> > > > > > >> >
> > > > > > >> > > +1
> > > > > > >> > >
> > > > > > >> > > I spent the last day or so working closely with Tiago,
> > > exploring
> > > > > > >> > different
> > > > > > >> > > options and getting deeper on the impact and evaluating
> the
> > > > > overall
> > > > > > >> > release
> > > > > > >> > > procedure steps required. I agree with the proposal as the
> > > most
> > > > > > >> > > viable option for unblocking the 10 release in the
> > reasonable
> > > > time
> > > > > > >> frame.
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > > tiagobento@apache.org>
> > > > > > >> > wrote:
> > > > > > >> > >
> > > > > > >> > > > Hi everyone,
> > > > > > >> > > >
> > > > > > >> > > > Unfortunately, I can't do a tl;dr this time, as this
> > matter
> > > > > > >> requires a
> > > > > > >> > > > lot of context.
> > > > > > >> > > >
> > > > > > >> > > > This email will take you < 20 minutes to read, according
> > to
> > > > > > >> > > > https://thereadtime.com/.
> > > > > > >> > > >
> > > > > > >> > > > As you may have followed on a separate thread
> > > > > > >> > > > (
> > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > > ),
> > > > > > >> > > > many of us were working towards removing a circular
> > > dependency
> > > > > > >> > > > currently present between `kogito-apps` and `kie-tools`.
> > As
> > > we
> > > > > > >> > > > progressed towards a solution, we kept finding the
> > circular
> > > > > > >> dependency
> > > > > > >> > > > pop up somewhere else. I'll do a breakdown of the things
> > we
> > > > did,
> > > > > > and
> > > > > > >> > > > the results we had.
> > > > > > >> > > >
> > > > > > >> > > > Right now, even though we started the effort to move the
> > > > Quarkus
> > > > > > Dev
> > > > > > >> > > > UI modules to `kie-tools`, we haven't been able to do it
> > > yet,
> > > > as
> > > > > > >> we've
> > > > > > >> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6,
> and
> > > > > Quarkus
> > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > > 999-20240218-SNAPSHOT.
> > > > > This
> > > > > > >> > > > effort was concluded this Monday, with
> > > > > > >> > > > https://github.com/apache/incubator-kie-tools/pull/2136
> .
> > > > > > >> > > >
> > > > > > >> > > > The current scenario we have is:
> > > > > > >> > > >
> > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > > >> > > > C | 03. incubator-kie-kogito-examples
> > > > > > >> > > > Y | 04. incubator-kie-kogito-images
> > > > > > >> > > > C | 05.
> > incubator-kie-kogito-serverless-operator
> > > > > > >> > > > L | ==========================
> > > > > > >> > > > E | 06.
> > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > * As `kie-tools`/extended-services depends on
> > > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > > >> > > > * and
> > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > > depend
> > > > > > >> on
> > > > > > >> > > > `kie-tools`/{many packages}
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`, we
> > would've
> > > > > had:
> > > > > > >> > > >
> > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > > >> > > > Y | 05.
> > incubator-kie-kogito-serverless-operator
> > > > > > >> > > > C | =====================
> > > > > > >> > > > L | 06.
> > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > > >> > > >
> > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > > >> > > > * and `kogito-images`/kogito-swf-devmode depends
> > on
> > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > After moving the `kogito-swf-devmode` image to
> > `kie-tools`,
> > > we
> > > > > > >> would've
> > > > > > >> > > > had:
> > > > > > >> > > >
> > > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > > >> > > > 04. incubator-kie-kogito-images
> > > > > > >> > > > C |==> 05.
> incubator-kie-kogito-serverless-operator
> > > > > > >> > > > Y | =====================
> > > > > > >> > > > C | 06.
> > > incubator-kie-sandbox-quarkus-accelerator
> > > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > > >> > > > E
> > > > > > >> > > >
> > > > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > > > >> > > > `kogito-serverless-operator`;
> > > > > > >> > > > * and `kogito-serverless-operator` depends on
> > > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > Clearly, we have a much bigger problem than a simple
> > > circular
> > > > > > >> > dependency.
> > > > > > >> > > >
> > > > > > >> > > > After multiple conversations with a lot of people, it's
> > been
> > > > > > really
> > > > > > >> > > > hard coming up with a simple solution that makes it
> > possible
> > > > to
> > > > > > >> build
> > > > > > >> > > > Apache KIE in one shot, while preserving the way
> everyone
> > is
> > > > > used
> > > > > > to
> > > > > > >> > > > contributing to the multiple repositories we have. More
> > than
> > > > > that,
> > > > > > >> > > > while making this assessment, I found more problems
> that,
> > in
> > > > my
> > > > > > >> > > > perspective, block Apache KIE 10.
> > > > > > >> > > >
> > > > > > >> > > > In light of that difficulty, I'm coming forward with my
> > > > proposal
> > > > > > for
> > > > > > >> > > > the Apache KIE release process, so we can use Apache's
> > > > > mechanisms
> > > > > > to
> > > > > > >> > > > have a slower-paced, in-depth debate about this really
> > > > > complicated
> > > > > > >> > > > matter.
> > > > > > >> > > >
> > > > > > >> > > > I'll lay out my entire perspective about the current
> > > situation
> > > > > of
> > > > > > >> our
> > > > > > >> > > > codebase, as well as problems I can currently see. I'll
> > > start
> > > > > with
> > > > > > >> an
> > > > > > >> > > > analysis of the repositories and their purposes, point
> out
> > > > some
> > > > > > >> > > > problems that I believe are blocking our 10 release,
> > explain
> > > > my
> > > > > > >> > > > proposal and discuss some consequences to what I'm
> > > proposing.
> > > > > > >> > > >
> > > > > > >> > > > Let's begin.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > # THE APACHE KIE REPOS
> > > > > > >> > > >
> > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > > >> > > > - incubator-kie-kogito-serverless-operator @ `main`
> > > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > > >> > > >
> > > > > > >> > > > B. TOOLS (count: 2)
> > > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > > >> > > >
> > > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > > >> > > >
> > > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > > >> > > > - incubator-kie-kogito-operator
> > > > > > >> > > >
> > > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > > >> > > > (Issues only, README should be updated @ `main`.
> Same
> > > for
> > > > > > GitHub
> > > > > > >> > > > Actions workflows.)
> > > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > > >> > > > (The Kogito website. Develop & deploy at the `main`
> > > > branch.)
> > > > > > >> > > > - incubator-kie-website @ `main`
> > > > > > >> > > > (The KIE website. Develop @ `main`. Push @ `deploy`
> to
> > > > > update
> > > > > > >> the
> > > > > > >> > > > website.)
> > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > >> > > > (GitHub pages used to host sandbox.kie.org and KIE
> > > Tools'
> > > > > > >> Chrome
> > > > > > >> > > > Extension assets.)
> > > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > >> > > > (Same as above, but for manual sanity checks during
> > the
> > > > > > staging
> > > > > > >> > > > phase of a release.)
> > > > > > >> > > >
> > > > > > >> > > > TOTAL (count: 21)
> > > > > > >> > > >
> > > > > > >> > > > I grouped the repositories by category, and listed them
> > in a
> > > > > > >> > > > topological order. Keep in mind that when flattening
> out a
> > > > tree,
> > > > > > >> there
> > > > > > >> > > > are multiple possibilities. For example, OptaPlanner
> > > could've
> > > > > been
> > > > > > >> > > > placed in any position after Drools.
> > > > > > >> > > >
> > > > > > >> > > > Category A repos are what I've been referring to as
> > `drools`
> > > > and
> > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is inside that
> > > > stream,
> > > > > as
> > > > > > >> the
> > > > > > >> > > > way these repositories reference each other are through
> > > Maven
> > > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version.
> > This
> > > > > > >> mechanism
> > > > > > >> > > > is well-known to the team, and although flawed for
> > intra-day
> > > > > > builds
> > > > > > >> > > > and disruptive for people in many different time zones,
> it
> > > is
> > > > > > >> already
> > > > > > >> > > > very comfortable for everyone to work with, I assume.
> > > > > > >> > > >
> > > > > > >> > > > Contributions made to Category A have some dedicated
> > > > pipelines,
> > > > > > >> which
> > > > > > >> > > > are, at least to some extent, able to build cross-repo
> PRs
> > > > > > together
> > > > > > >> > > > and verify that the codebase will continue working as
> > > expected
> > > > > > after
> > > > > > >> > > > they're all merged. From what I could gather, there are
> > some
> > > > > > >> > > > "sub-streams" currently configured for cross-repo PRs.
> > > > > > >> > > >
> > > > > > >> > > > - kogito-pipelines
> > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> > kogito-examples
> > > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > > >> > > > - kogito-images, and kogito-serverless-operator
> > > > > > >> > > > - kogito-docs
> > > > > > >> > > > - kie-docs
> > > > > > >> > > >
> > > > > > >> > > > This means that sending cross-repo PRs to any
> combination
> > of
> > > > > repos
> > > > > > >> > > > that are not part of the same "sub-stream" cannot be
> > > verified
> > > > > > before
> > > > > > >> > > > merging, making our contribution model dependent on
> > > individual
> > > > > > >> > > > contributors building stuff on their machines to verify
> > that
> > > > it
> > > > > > >> works.
> > > > > > >> > > >
> > > > > > >> > > > I based this analysis on
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > >> > > > ,
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > >> > > > ,
> > > > > > >> > > > and
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > >> > > > .
> > > > > > >> > > > Note that I'm not that familiar with these pipelines, so
> > > > please
> > > > > > >> > > > someone correct me if I'm wrong.
> > > > > > >> > > >
> > > > > > >> > > > Category B repos are what I've been referring to as
> > > > `kie-tools`
> > > > > > >> > > > stream. The first repo there is a template repository
> that
> > > is
> > > > > used
> > > > > > >> by
> > > > > > >> > > > people starting projects from scratch on KIE Sandbox,
> > > similar
> > > > > to a
> > > > > > >> > > > Maven archetype, if you will. The other one is the KIE
> > Tools
> > > > > > >> monorepo,
> > > > > > >> > > > a polyglot monorepo with `pnpm` as its build system.
> > > > Currently,
> > > > > > KIE
> > > > > > >> > > > Tools hosts Java libraries and apps, TypeScript
> libraries
> > > and
> > > > > > apps,
> > > > > > >> Go
> > > > > > >> > > > apps, Docker images, and Helm charts. The `kie-tools`
> > > monorepo
> > > > > is
> > > > > > >> > > > configured to work with sparse checkouts and can do
> > partial
> > > > > > builds.
> > > > > > >> > > > Category B repos refer to Category A repos through
> > > timestamped
> > > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently
> introduced
> > > that
> > > > > > will
> > > > > > >> > > > build and publish immutable, persistent artifacts under
> a
> > > > > version
> > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format, published
> > weekly
> > > > > every
> > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an evolution to
> > the
> > > > > Kogito
> > > > > > >> > > > releases, as we're now targeting one release for all of
> > > Apache
> > > > > > KIE,
> > > > > > >> so
> > > > > > >> > > > we can't have Kogito releases anymore.
> > > > > > >> > > >
> > > > > > >> > > > An important note here is that Category B repositories
> > have
> > > > been
> > > > > > >> > > > historically kept out of any automations we used to
> have,
> > > way
> > > > > back
> > > > > > >> > > > when Kogito started and we had the Business Central
> > (a.k.a.
> > > > v7)
> > > > > > >> stream
> > > > > > >> > > > still going on. For this reason, Category B projects
> have
> > > > > > developed
> > > > > > >> > > > their own automations, based on GitHub Actions.
> Category B
> > > > repos
> > > > > > >> have
> > > > > > >> > > > always depended on Category A repos using fixed
> versions.
> > If
> > > > > > >> Category
> > > > > > >> > > > B repos have had adopted mutable SNAPSHOTs, breaking
> > changes
> > > > on
> > > > > > >> > > > Category A repositories would've had the potential to
> > break
> > > > > > >> Category B
> > > > > > >> > > > silently, leaving Category B with a broken development
> > > stream,
> > > > > and
> > > > > > >> > > > introducing unpleasant surprises for maintainers of
> > > Category B
> > > > > > >> repos,
> > > > > > >> > > > as historically Category A contributors were not
> familiar
> > > with
> > > > > > >> > > > Category B repos.
> > > > > > >> > > >
> > > > > > >> > > > Contributions made to Category B repos go through a
> GitHub
> > > > > Actions
> > > > > > >> > > > workflow that builds the relevant part of the
> `kie-tools`
> > > > > monorepo
> > > > > > >> for
> > > > > > >> > > > the changes introduced. Changes made to the pipeline
> > itself
> > > > are
> > > > > > also
> > > > > > >> > > > picked up as part of PRs, allowing us to do things like
> > > > > atomically
> > > > > > >> > > > bumping the Node.js version, for example. More
> > importantly,
> > > it
> > > > > > >> allows
> > > > > > >> > > > us to upgrade the repository to a new timestamped
> SNAPSHOT
> > > > > > together
> > > > > > >> > > > with the changes necessary to make it stay green.
> > > > > > >> > > >
> > > > > > >> > > > This setup, however, makes it impossible to have
> > cross-repo
> > > > PRs
> > > > > > >> > > > involving Category A and Category B simultaneously, with
> > the
> > > > > > current
> > > > > > >> > > > automations we have.
> > > > > > >> > > >
> > > > > > >> > > > Category C repos are kind of floating around, and I'm
> not
> > > sure
> > > > > if
> > > > > > >> > > > there's much activity going on there. Regardless, as
> > they're
> > > > > part
> > > > > > of
> > > > > > >> > > > Apache KIE, they will be part of our release, so I
> listed
> > > them
> > > > > for
> > > > > > >> us
> > > > > > >> > > > to take them into consideration too.
> > > > > > >> > > >
> > > > > > >> > > > Category D is self explanatory. There's only one repo
> that
> > > has
> > > > > > >> already
> > > > > > >> > > > been marked for being archived.
> > > > > > >> > > >
> > > > > > >> > > > Category E are repos that do not host code directly, and
> > are
> > > > > > either
> > > > > > >> > > > organizational entities, or host websites, that
> currently
> > > are
> > > > > not
> > > > > > >> part
> > > > > > >> > > > of any pipelines we have.
> > > > > > >> > > >
> > > > > > >> > > > This lack of unification between Category A and
> Category B
> > > is,
> > > > > > IMHO,
> > > > > > >> > > > what allowed us to introduce the infamous circular
> > > dependency
> > > > > > >> between
> > > > > > >> > > > `kie-tools` and `kogito-apps`, which we now can describe
> > as
> > > a
> > > > > > >> circular
> > > > > > >> > > > dependency between Category A and Category B. The way I
> > see
> > > > it,
> > > > > if
> > > > > > >> we
> > > > > > >> > > > had a single pipeline, building everything from `drools`
> > to
> > > > > > >> > > > `kie-tools`, such flaws would've never been introduced,
> > and
> > > we
> > > > > > >> > > > wouldn't be having this huge problem in our hands right
> > now.
> > > > > > >> > > >
> > > > > > >> > > > My proposal for the Apache KIE release process sees this
> > > lack
> > > > of
> > > > > > >> > > > unification as a central problem, not only for this
> > release
> > > in
> > > > > > >> > > > particular, but for the community as a whole. It is my
> > > belief
> > > > > that
> > > > > > >> we
> > > > > > >> > > > are all under the same roof, and that no contribution
> > should
> > > > be
> > > > > > >> > > > allowed to break any part of our codebase. With the
> > > increasing
> > > > > > >> volume
> > > > > > >> > > > of code, and hopefully number of contributors too, we
> > cannot
> > > > > keep
> > > > > > >> > > > counting on "common sense" to avoid breaking things.
> We're
> > > all
> > > > > > >> humans
> > > > > > >> > > > after all, and it is our job to have mechanisms in place
> > to
> > > > > > prevent
> > > > > > >> us
> > > > > > >> > > > from unwillingly making mistakes. Especially when these
> > > > mistakes
> > > > > > >> > > > impact on parts of the codebase that we, individually,
> > > > probably
> > > > > > >> can't
> > > > > > >> > > > fix.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > > >> > > >
> > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on
> > kiegroup's
> > > > KIE
> > > > > > >> Tools
> > > > > > >> > > > `0.32.0`.
> > > > > > >> > > > See:
> > > > > > >> > > > -
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > P2. PR open for Kogito SWF images @ `kogito-images`
> > > depending
> > > > on
> > > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > >> > > > See:
> > > > > > >> > > > -
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's
> > > `lienzo`
> > > > > and
> > > > > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > > > >> > > > See:
> > > > > > >> > > > -
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > >> > > > -
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > P4. Multiple packages @ `kogito-apps` depending on
> > > kiegroup's
> > > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > > >> > > > * This module was removed from the KIE codebase here:
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > >> > > > and now lives on
> > > > > > >> > > >
> > > > > >
> https://github.com/trustyai-explainability/trustyai-explainability
> > ,
> > > > > > >> > > > under a different GAV.
> > > > > > >> > > > * This new repo depends on Kogito and OptaPlanner,
> > pointing
> > > to
> > > > > > older
> > > > > > >> > > > versions.
> > > > > > >> > > > See:
> > > > > > >> > > > -
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > >> > > > -
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator`
> depending
> > on
> > > > > > Kogito
> > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > >> > > > See:
> > > > > > >> > > > -
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > P6. Category C repos are out of date and not part of the
> > > > > Category
> > > > > > A
> > > > > > >> > > > CI/Release pipelines.
> > > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current version is
> > > > > > >> `2.0-SNAPSHOT`,
> > > > > > >> > > > depending on Kogito without a specific version, only by
> > > using
> > > > > > >> > > > `http://localhost:8080`)
> > > > > > >> > > > * incubator-kie-benchmarks: (Current version is
> > > > `1.0-SNAPSHOT`,
> > > > > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> > > > > `8.45.0-SNAPSHOT`)
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E
> > > > disabled
> > > > > > >> after
> > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > In my perspective, P1 and P2 have the same solution, as
> > they
> > > > > both
> > > > > > >> > > > suffer from the circular dependency between Category A
> and
> > > > > > Category
> > > > > > >> B.
> > > > > > >> > > > As Category A and Category B are both streams that have
> > been
> > > > > > really
> > > > > > >> > > > active, I see this as a blocker, as there are
> > contributions
> > > > that
> > > > > > >> > > > cannot be done, given that Category A depends on
> Category
> > B
> > > > > with a
> > > > > > >> > > > dephasing of 1 release.
> > > > > > >> > > >
> > > > > > >> > > > P3 and P4, although not ideal, can be understood as
> > > technical
> > > > > > debt.
> > > > > > >> > > > Depending on unmaintained projects is something we'll
> > always
> > > > be
> > > > > > >> > > > susceptible to, given time.
> > > > > > >> > > >
> > > > > > >> > > > P5 and P6 are easily fixable, as it's just a matter of
> > > making
> > > > > them
> > > > > > >> > > > part of the play.
> > > > > > >> > > >
> > > > > > >> > > > P7 is an isolated problem that won't impact the
> structure
> > or
> > > > > > >> anything
> > > > > > >> > > > that we're talking about here, but it is a regression we
> > > > > > introduced
> > > > > > >> > > > recently.
> > > > > > >> > > >
> > > > > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and
> > > that
> > > > > P5,
> > > > > > >> P6,
> > > > > > >> > > > and P7 have easy fixes, the only problems left to
> discuss
> > > are
> > > > P1
> > > > > > and
> > > > > > >> > > > P2, which can't be done without a proper proposal.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > # THE PROPOSAL
> > > > > > >> > > >
> > > > > > >> > > > I'll try to be very meticulous here, since from my
> > > experience,
> > > > > any
> > > > > > >> > > > little miscalculation can lead to our release not
> working
> > > out
> > > > in
> > > > > > the
> > > > > > >> > > > end. To try and avoid that as much as possible, and make
> > > > > > everything
> > > > > > >> we
> > > > > > >> > > > can to have a successful Apache KIE 10 release, bear
> with
> > > me.
> > > > > I'll
> > > > > > >> lay
> > > > > > >> > > > out a timeline of events that need to happen in order
> for
> > > our
> > > > > > >> release
> > > > > > >> > > > to be published, with all artifacts ending up in the
> right
> > > > > places,
> > > > > > >> but
> > > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > > >> > > >
> > > > > > >> > > > As you saw at the beginning of this email, all the
> > attempts
> > > we
> > > > > > made
> > > > > > >> > > > left us with the circular dependency showing up at a
> > > different
> > > > > > >> place,
> > > > > > >> > > > but something all these places have in common is that
> > > they're
> > > > > all
> > > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > > >> > > >
> > > > > > >> > > > The first part of my proposal is the following:
> > > > > > >> > > >
> > > > > > >> > > > S1. We keep the original plan of moving the Quarkus Dev
> > UIs
> > > > from
> > > > > > >> > > > `kogito-apps` to `kie-tools`, together with Management
> and
> > > > Task
> > > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > > `kogito-swf-builder`
> > > > > > images
> > > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > > >> > > > S3. We move the entire `kogito-serverless-operator` repo
> > > > inside
> > > > > a
> > > > > > >> new
> > > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > > >> > > >
> > > > > > >> > > > Solutions S1, S2, and S3 together solve problems P1 and
> > P2.
> > > Of
> > > > > > >> course
> > > > > > >> > > > the rest of
> > > > > > >> https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > >> > > > would still be done too.
> > > > > > >> > > >
> > > > > > >> > > > This doesn't come without consequences, of course, as
> the
> > > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder` images,
> and
> > > the
> > > > > > >> > > > `kogito-serverless-operator` would be moving from
> > Category A
> > > > to
> > > > > > >> > > > Category B. This move would make them have to reference
> > > > > Category A
> > > > > > >> > > > repos through timestamped SNAPSHOTs. Since
> `kogito-images`
> > > and
> > > > > > >> > > > `kogito-serverless-operator` are already their own
> > > > "sub-stream"
> > > > > > >> inside
> > > > > > >> > > > Category A, though, contributions made in a cross-repo
> > > fashion
> > > > > to
> > > > > > >> this
> > > > > > >> > > > "sub-stream" will continue being possible, now via a
> > single
> > > PR
> > > > > to
> > > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A and
> > Category
> > > B
> > > > > will
> > > > > > >> > > > continue not being possible, and a 1-week delay between
> > > > merging
> > > > > > >> > > > something on Category A and using it on Category B will
> > > still
> > > > > > >> happen.
> > > > > > >> > > >
> > > > > > >> > > > It's worth mentioning that `kie-tools`, however, does
> > allow
> > > > for
> > > > > > >> sparse
> > > > > > >> > > > checkouts and partial builds, so working with a subset
> of
> > > the
> > > > > > >> monorepo
> > > > > > >> > > > is possible and encouraged. Making changes only to
> > > > > > >> > > > `packages/kn-plugin-workflow`, for example, will have
> the
> > PR
> > > > > > checks
> > > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > >> > > > .
> > > > > > >> > > > We're not compromising when running partial builds too.
> We
> > > > know
> > > > > > that
> > > > > > >> > > > the entire repo will continue working even after only
> > > > building a
> > > > > > >> small
> > > > > > >> > > > subset of the changes. Doing partial or full builds is
> > > > > > automatically
> > > > > > >> > > > determined by the changes of a PR.
> > > > > > >> > > >
> > > > > > >> > > > Keep in mind that, even though I'm proposing we move a
> > bunch
> > > > of
> > > > > > >> > > > additional stuff into `kie-tools`, I see this as a
> > TEMPORARY
> > > > > > >> solution
> > > > > > >> > > > for our codebase. `kie-tools` would host some additional
> > > stuff
> > > > > > >> > > > TEMPORARILY so that we can release and continue moving
> > > > forward.
> > > > > > >> > > >
> > > > > > >> > > > As I mentioned on other places, `kie-tools` became a
> > > polyglot
> > > > > > >> monorepo
> > > > > > >> > > > out of necessity, and although I'm really proud of what
> we
> > > > > > achieved
> > > > > > >> > > > there so far, I don't think `kie-tools` has a setup that
> > is
> > > > > > suitable
> > > > > > >> > > > for all the different nuances that compose our
> community.
> > > I'm
> > > > > well
> > > > > > >> > > > aware that a polyglot monorepo that does not follow
> > > widespread
> > > > > > >> > > > conventions will scare some people away, and as much as
> > > we've
> > > > > > tried
> > > > > > >> to
> > > > > > >> > > > make build instructions clear, we can't always get past
> > the
> > > > > > >> prejudice
> > > > > > >> > > > some people have towards the "front-end" ecosystem.
> > > > > > >> > > >
> > > > > > >> > > > With all that said, I keep thinking this is the best
> > course
> > > of
> > > > > > >> action
> > > > > > >> > > > for us right now. We keep most of our stuff unchanged,
> we
> > > > > unblock
> > > > > > >> the
> > > > > > >> > > > release, and we have a working setup that will suit us
> > well
> > > > > while
> > > > > > we
> > > > > > >> > > > discuss and reach a conclusion regarding the future of
> our
> > > > > > codebase
> > > > > > >> > > > structure.
> > > > > > >> > > >
> > > > > > >> > > > Let me paint a quick picture here of what our code base
> > > would
> > > > > look
> > > > > > >> > > > like, repository-wise, if my proposal is accepted:
> > > > > > >> > > >
> > > > > > >> > > > CATEGORY REPO
> > > > > > >> > > > =====================
> > > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > > >> > > > A incubator-kie-drools
> > > > > > >> > > > A incubator-kie-optaplanner
> > > > > > >> > > > A incubator-kie-optaplanner-quickstarts
> > > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > > >> > > > A incubator-kie-kogito-apps
> > > > > > >> > > > A incubator-kie-kogito-examples
> > > > > > >> > > > A incubator-kie-kogito-images
> > > > > > >> > > > A incubator-kie-kogito-docs
> > > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > > >> > > > A incubator-kie-docs
> > > > > > >> > > > A incubator-kie-benchmarks
> > > > > > >> > > > =====================
> > > > > > >> > > > B incubator-kie-sandbox-quarkus-accelerator
> > > > > > >> > > > B incubator-kie-tools
> > > > > > >> > > > =====================
> > > > > > >> > > > D incubator-kie-kogito-operator
> > > > > > >> > > > =====================
> > > > > > >> > > > E incubator-kie-issues
> > > > > > >> > > > E incubator-kie-kogito-website
> > > > > > >> > > > E incubator-kie-website
> > > > > > >> > > > E incubator-kie-kogito-online
> > > > > > >> > > > E incubator-kie-kogito-online-staging
> > > > > > >> > > > =====================
> > > > > > >> > > >
> > > > > > >> > > > * Category C becomes part of Category A, and
> > > > > > >> > > > `kogito-serverless-operator` moves entirely inside
> > > > `kie-tools`.
> > > > > > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > > > >> > > > `kogito-serverless-operator` inside `kie-tools`, there
> are
> > > no
> > > > > > cycles
> > > > > > >> > > > anymore, as inside `kie-tools`, we can granularly build:
> > > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > > `kogito-swf-builder`
> > > > > > >> and
> > > > > > >> > > > `kogito-swf-devmode`)
> > > > > > >> > > > 4. packages/sonataflow-operator (contents from
> > > > > > >> > > > `kogito-serverless-operator`)
> > > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > > (`packages/kn-plugin-workflow`,
> > > > > > >> > > > but renamed)
> > > > > > >> > > >
> > > > > > >> > > > The second part of the proposal is the release process
> > > itself,
> > > > > > >> > > > assuming the structure above is what we have.
> > > > > > >> > > >
> > > > > > >> > > > Here it is:
> > > > > > >> > > >
> > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as cutting
> > point
> > > > for
> > > > > > >> > > > Category A repos.
> > > > > > >> > > > 2. Update Category B repos to point to this timestamped
> > > > > SNAPSHOT,
> > > > > > >> and
> > > > > > >> > > > verify that everything is working.
> > > > > > >> > > > 3. At this point, with everything working, we can branch
> > out
> > > > to
> > > > > > >> > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag,
> > and
> > > > > > >> Category B
> > > > > > >> > > > from `main`.
> > > > > > >> > > > 4. All Category A and Category B repos update their
> > versions
> > > > to
> > > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > > >> > > > 5. Update Category B repos to point to Category A repos
> > > using
> > > > > the
> > > > > > >> > > > 10.0.0 version.
> > > > > > >> > > > 6. At this point, we can vote on the release based on
> the
> > > > > `10.0.x`
> > > > > > >> > > > branches, given we don't expect any code changes
> anymore.
> > > > > > >> > > > 7. After voting passes, we're good to start the release
> > > > process.
> > > > > > >> > > > 8. Category A repos follow their manual/automated
> release
> > > > > process,
> > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and
> > > built
> > > > > > >> > > > artifacts pushed to their registries.
> > > > > > >> > > > 9. We wait a little bit for Category A artifacts to be
> > > > > propagated
> > > > > > on
> > > > > > >> > > > registries. ~1 day.
> > > > > > >> > > > 10. Category B repos follow their manual/automated
> release
> > > > > > process,
> > > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and
> > > built
> > > > > > >> > > > artifacts pushed to their registries.
> > > > > > >> > > > 11. Category D repos are ignored.
> > > > > > >> > > > 12. Category E repos can be manually tagged with 10.0.0
> > from
> > > > > their
> > > > > > >> > > > default branches.
> > > > > > >> > > >
> > > > > > >> > > > More needs to be discussed if we're planning to maintain
> > > > > multiple
> > > > > > >> > > > release streams in parallel, but I guess it can wait for
> > > after
> > > > > > >> Apache
> > > > > > >> > > > KIE 10.
> > > > > > >> > > >
> > > > > > >> > > > Thank you for reading, and I'm looking forward to
> hearing
> > > back
> > > > > > from
> > > > > > >> > > > everyone.
> > > > > > >> > > >
> > > > > > >> > > > Of course, alternative solutions are possible. This
> email,
> > > > > > however,
> > > > > > >> > > > summarizes my view of how we should attack the problem,
> > > > > > considering
> > > > > > >> > > > disruption, required effort, the release process itself,
> > and
> > > > > > >> history.
> > > > > > >> > > > Feel free to propose alternatives. This is not a voting
> > > > thread.
> > > > > > >> > > >
> > > > > > >> > > > Regards,
> > > > > > >> > > >
> > > > > > >> > > > Tiago Bento
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >>
> > > > ---------------------------------------------------------------------
> > > > > > >> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > >> > > > For additional commands, e-mail:
> dev-help@kie.apache.org
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
I think I already did a high level proposal.
1) Remove all dependencies from tooling to images, so images depend on
tooling but tooling does not depend on images.
2) Then change CI to deal with tooling repo before dealing with images
repo.
I understand that CI details are tricky and since I'm not familiar with CI
in any way, I barely can make a low level design, but we do not need to fix
everything, just achieve 2), a change of compilation order.
On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli <al...@porcelli.me> wrote:
> Francisco and Grabriele,
>
> You may not like or understand why the current state of the CI is like
> that… actually has been in Red Hat and has been replicated in Apache as
> used to be….
>
> But the fact is that this is the current reality.
>
> If you disagree with the current plan, please provide a detailed
> alternative so we, as community, can better evaluate the pros and cons of
> each proposal.
>
>
> I think it’s also fair to say that, post 10 release we need to have a much
> in depth discussion about how our codebase is organized, it’s clear that
> it’s not working.
>
>
> On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <
> gabriele.cardosi@gmail.com>
> wrote:
>
> > As Francisco said,
> > I also have the impression that the "images" (if we are talking of docker
> > images) should be the very last one to be built, in a standalone repo.
> > That way, they may "combine" artifacts that are built in different repos,
> > regardless of the order in which those are built.
> > Moving them out of all the repos (kogito-apps/kie-tools) maybe could
> > simplify the situation a bit.
> > (I also think there are some statements of undisputable needs while they
> > are, actually, just technical choices.
> > Anyway, this latter point is for longer, following, discussion.)
> >
> >
> >
> >
> > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier Tirado Sarti <
> > ftirados@redhat.com> ha scritto:
> >
> > > Alex,
> > > There are two assumptions that deserve further discussion:
> > > 1) That tool has to be the last to build. why? it does not have more
> > sense
> > > to build final images after everything else has been built?-
> > > 2) That the impact (in terms of effort now) on fixing CI is bigger than
> > the
> > > impact (long term consequences) of consolidating two unrelated piece of
> > > software within the same repository.
> > >
> > >
> > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <al...@porcelli.me>
> wrote:
> > >
> > > > Francisco,
> > > >
> > > > This was discussed as an alternative solution, however it has major
> > > impact
> > > > on CI and there’s also the fact Tool has been always the last to
> build
> > > and
> > > > has no Snapshot published (actually in JavaScript world there is no
> > > > snapshot concept).
> > > >
> > > > So, based on our evaluation… the proposal here is the least
> disruptive
> > > and
> > > > will take less time to unblock the release.
> > > >
> > > > Regards,
> > > > _____________
> > > > Alex Porcelli
> > > > http://porcelli.me
> > > >
> > > >
> > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado Sarti <
> > > > ftirados@redhat.com> wrote:
> > > >
> > > > > After kie-tools, sorry. I think we are not embracing the fact that
> > > > > kogito-images depend on kie-tools, because we want those images to
> > > > include
> > > > > tools.
> > > > >
> > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado Sarti <
> > > > > ftirados@redhat.com> wrote:
> > > > >
> > > > > > Hi Tiago,
> > > > > > It can be an alternative solution to move kn-plugin-workflow to
> > > > > > kogito-images (so there is not longer dependency from tools to
> > > images)
> > > > > and
> > > > > > then build kogito-images after kogito-tools?
> > > > > >
> > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez <
> > > > > > egonzalez@apache.org> wrote:
> > > > > >
> > > > > >> +1 to unblock release
> > > > > >>
> > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > > > > pefernan@apache.org>
> > > > > >> escribió:
> > > > > >>
> > > > > >> > I say +1 in order to move forward with the 10.
> > > > > >> >
> > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <alex@porcelli.me
> >
> > > > wrote:
> > > > > >> >
> > > > > >> > > +1
> > > > > >> > >
> > > > > >> > > I spent the last day or so working closely with Tiago,
> > exploring
> > > > > >> > different
> > > > > >> > > options and getting deeper on the impact and evaluating the
> > > > overall
> > > > > >> > release
> > > > > >> > > procedure steps required. I agree with the proposal as the
> > most
> > > > > >> > > viable option for unblocking the 10 release in the
> reasonable
> > > time
> > > > > >> frame.
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > > tiagobento@apache.org>
> > > > > >> > wrote:
> > > > > >> > >
> > > > > >> > > > Hi everyone,
> > > > > >> > > >
> > > > > >> > > > Unfortunately, I can't do a tl;dr this time, as this
> matter
> > > > > >> requires a
> > > > > >> > > > lot of context.
> > > > > >> > > >
> > > > > >> > > > This email will take you < 20 minutes to read, according
> to
> > > > > >> > > > https://thereadtime.com/.
> > > > > >> > > >
> > > > > >> > > > As you may have followed on a separate thread
> > > > > >> > > > (
> > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > > ),
> > > > > >> > > > many of us were working towards removing a circular
> > dependency
> > > > > >> > > > currently present between `kogito-apps` and `kie-tools`.
> As
> > we
> > > > > >> > > > progressed towards a solution, we kept finding the
> circular
> > > > > >> dependency
> > > > > >> > > > pop up somewhere else. I'll do a breakdown of the things
> we
> > > did,
> > > > > and
> > > > > >> > > > the results we had.
> > > > > >> > > >
> > > > > >> > > > Right now, even though we started the effort to move the
> > > Quarkus
> > > > > Dev
> > > > > >> > > > UI modules to `kie-tools`, we haven't been able to do it
> > yet,
> > > as
> > > > > >> we've
> > > > > >> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and
> > > > Quarkus
> > > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> > 999-20240218-SNAPSHOT.
> > > > This
> > > > > >> > > > effort was concluded this Monday, with
> > > > > >> > > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > > > > >> > > >
> > > > > >> > > > The current scenario we have is:
> > > > > >> > > >
> > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > > >> > > > C | 03. incubator-kie-kogito-examples
> > > > > >> > > > Y | 04. incubator-kie-kogito-images
> > > > > >> > > > C | 05.
> incubator-kie-kogito-serverless-operator
> > > > > >> > > > L | ==========================
> > > > > >> > > > E | 06.
> > incubator-kie-sandbox-quarkus-accelerator
> > > > > >> > > > |==> 07. incubator-kie-tools
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > * As `kie-tools`/extended-services depends on
> > > > > >> > > > `kogito-apps`/jitexecutor;
> > > > > >> > > > * and
> `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > > depend
> > > > > >> on
> > > > > >> > > > `kie-tools`/{many packages}
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`, we
> would've
> > > > had:
> > > > > >> > > >
> > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > > >> > > > Y | 05.
> incubator-kie-kogito-serverless-operator
> > > > > >> > > > C | =====================
> > > > > >> > > > L | 06.
> > incubator-kie-sandbox-quarkus-accelerator
> > > > > >> > > > E |==> 07. incubator-kie-tools
> > > > > >> > > >
> > > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > > >> > > > * and `kogito-images`/kogito-swf-devmode depends
> on
> > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > After moving the `kogito-swf-devmode` image to
> `kie-tools`,
> > we
> > > > > >> would've
> > > > > >> > > > had:
> > > > > >> > > >
> > > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > > >> > > > 02. incubator-kie-kogito-apps
> > > > > >> > > > 03. incubator-kie-kogito-examples
> > > > > >> > > > 04. incubator-kie-kogito-images
> > > > > >> > > > C |==> 05. incubator-kie-kogito-serverless-operator
> > > > > >> > > > Y | =====================
> > > > > >> > > > C | 06.
> > incubator-kie-sandbox-quarkus-accelerator
> > > > > >> > > > L |==> 07. incubator-kie-tools
> > > > > >> > > > E
> > > > > >> > > >
> > > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > > >> > > > `kogito-serverless-operator`;
> > > > > >> > > > * and `kogito-serverless-operator` depends on
> > > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > Clearly, we have a much bigger problem than a simple
> > circular
> > > > > >> > dependency.
> > > > > >> > > >
> > > > > >> > > > After multiple conversations with a lot of people, it's
> been
> > > > > really
> > > > > >> > > > hard coming up with a simple solution that makes it
> possible
> > > to
> > > > > >> build
> > > > > >> > > > Apache KIE in one shot, while preserving the way everyone
> is
> > > > used
> > > > > to
> > > > > >> > > > contributing to the multiple repositories we have. More
> than
> > > > that,
> > > > > >> > > > while making this assessment, I found more problems that,
> in
> > > my
> > > > > >> > > > perspective, block Apache KIE 10.
> > > > > >> > > >
> > > > > >> > > > In light of that difficulty, I'm coming forward with my
> > > proposal
> > > > > for
> > > > > >> > > > the Apache KIE release process, so we can use Apache's
> > > > mechanisms
> > > > > to
> > > > > >> > > > have a slower-paced, in-depth debate about this really
> > > > complicated
> > > > > >> > > > matter.
> > > > > >> > > >
> > > > > >> > > > I'll lay out my entire perspective about the current
> > situation
> > > > of
> > > > > >> our
> > > > > >> > > > codebase, as well as problems I can currently see. I'll
> > start
> > > > with
> > > > > >> an
> > > > > >> > > > analysis of the repositories and their purposes, point out
> > > some
> > > > > >> > > > problems that I believe are blocking our 10 release,
> explain
> > > my
> > > > > >> > > > proposal and discuss some consequences to what I'm
> > proposing.
> > > > > >> > > >
> > > > > >> > > > Let's begin.
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > # THE APACHE KIE REPOS
> > > > > >> > > >
> > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > >> > > > - incubator-kie-drools @ `main`
> > > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > > >> > > > - incubator-kie-kogito-serverless-operator @ `main`
> > > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > > >> > > >
> > > > > >> > > > B. TOOLS (count: 2)
> > > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > > > >> > > > - incubator-kie-tools @ `main`
> > > > > >> > > >
> > > > > >> > > > C. BENCHMARKS (count: 2)
> > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > > >> > > >
> > > > > >> > > > D. ARCHIVED (count: 1)
> > > > > >> > > > - incubator-kie-kogito-operator
> > > > > >> > > >
> > > > > >> > > > E. "NON-CODE" (count: 5)
> > > > > >> > > > - incubator-kie-issues @ `main`
> > > > > >> > > > (Issues only, README should be updated @ `main`. Same
> > for
> > > > > GitHub
> > > > > >> > > > Actions workflows.)
> > > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > > >> > > > (The Kogito website. Develop & deploy at the `main`
> > > branch.)
> > > > > >> > > > - incubator-kie-website @ `main`
> > > > > >> > > > (The KIE website. Develop @ `main`. Push @ `deploy` to
> > > > update
> > > > > >> the
> > > > > >> > > > website.)
> > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > >> > > > (GitHub pages used to host sandbox.kie.org and KIE
> > Tools'
> > > > > >> Chrome
> > > > > >> > > > Extension assets.)
> > > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > >> > > > (Same as above, but for manual sanity checks during
> the
> > > > > staging
> > > > > >> > > > phase of a release.)
> > > > > >> > > >
> > > > > >> > > > TOTAL (count: 21)
> > > > > >> > > >
> > > > > >> > > > I grouped the repositories by category, and listed them
> in a
> > > > > >> > > > topological order. Keep in mind that when flattening out a
> > > tree,
> > > > > >> there
> > > > > >> > > > are multiple possibilities. For example, OptaPlanner
> > could've
> > > > been
> > > > > >> > > > placed in any position after Drools.
> > > > > >> > > >
> > > > > >> > > > Category A repos are what I've been referring to as
> `drools`
> > > and
> > > > > >> > > > `kogito-*` stream. Of course OptaPlanner is inside that
> > > stream,
> > > > as
> > > > > >> the
> > > > > >> > > > way these repositories reference each other are through
> > Maven
> > > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version.
> This
> > > > > >> mechanism
> > > > > >> > > > is well-known to the team, and although flawed for
> intra-day
> > > > > builds
> > > > > >> > > > and disruptive for people in many different time zones, it
> > is
> > > > > >> already
> > > > > >> > > > very comfortable for everyone to work with, I assume.
> > > > > >> > > >
> > > > > >> > > > Contributions made to Category A have some dedicated
> > > pipelines,
> > > > > >> which
> > > > > >> > > > are, at least to some extent, able to build cross-repo PRs
> > > > > together
> > > > > >> > > > and verify that the codebase will continue working as
> > expected
> > > > > after
> > > > > >> > > > they're all merged. From what I could gather, there are
> some
> > > > > >> > > > "sub-streams" currently configured for cross-repo PRs.
> > > > > >> > > >
> > > > > >> > > > - kogito-pipelines
> > > > > >> > > > - drools, kogito-runtimes, kogito-apps, and
> kogito-examples
> > > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > > >> > > > - kogito-images, and kogito-serverless-operator
> > > > > >> > > > - kogito-docs
> > > > > >> > > > - kie-docs
> > > > > >> > > >
> > > > > >> > > > This means that sending cross-repo PRs to any combination
> of
> > > > repos
> > > > > >> > > > that are not part of the same "sub-stream" cannot be
> > verified
> > > > > before
> > > > > >> > > > merging, making our contribution model dependent on
> > individual
> > > > > >> > > > contributors building stuff on their machines to verify
> that
> > > it
> > > > > >> works.
> > > > > >> > > >
> > > > > >> > > > I based this analysis on
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > >> > > > ,
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > >> > > > ,
> > > > > >> > > > and
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > >> > > > .
> > > > > >> > > > Note that I'm not that familiar with these pipelines, so
> > > please
> > > > > >> > > > someone correct me if I'm wrong.
> > > > > >> > > >
> > > > > >> > > > Category B repos are what I've been referring to as
> > > `kie-tools`
> > > > > >> > > > stream. The first repo there is a template repository that
> > is
> > > > used
> > > > > >> by
> > > > > >> > > > people starting projects from scratch on KIE Sandbox,
> > similar
> > > > to a
> > > > > >> > > > Maven archetype, if you will. The other one is the KIE
> Tools
> > > > > >> monorepo,
> > > > > >> > > > a polyglot monorepo with `pnpm` as its build system.
> > > Currently,
> > > > > KIE
> > > > > >> > > > Tools hosts Java libraries and apps, TypeScript libraries
> > and
> > > > > apps,
> > > > > >> Go
> > > > > >> > > > apps, Docker images, and Helm charts. The `kie-tools`
> > monorepo
> > > > is
> > > > > >> > > > configured to work with sparse checkouts and can do
> partial
> > > > > builds.
> > > > > >> > > > Category B repos refer to Category A repos through
> > timestamped
> > > > > >> > > > SNAPSHOTs. This is a new mechanism we recently introduced
> > that
> > > > > will
> > > > > >> > > > build and publish immutable, persistent artifacts under a
> > > > version
> > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format, published
> weekly
> > > > every
> > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an evolution to
> the
> > > > Kogito
> > > > > >> > > > releases, as we're now targeting one release for all of
> > Apache
> > > > > KIE,
> > > > > >> so
> > > > > >> > > > we can't have Kogito releases anymore.
> > > > > >> > > >
> > > > > >> > > > An important note here is that Category B repositories
> have
> > > been
> > > > > >> > > > historically kept out of any automations we used to have,
> > way
> > > > back
> > > > > >> > > > when Kogito started and we had the Business Central
> (a.k.a.
> > > v7)
> > > > > >> stream
> > > > > >> > > > still going on. For this reason, Category B projects have
> > > > > developed
> > > > > >> > > > their own automations, based on GitHub Actions. Category B
> > > repos
> > > > > >> have
> > > > > >> > > > always depended on Category A repos using fixed versions.
> If
> > > > > >> Category
> > > > > >> > > > B repos have had adopted mutable SNAPSHOTs, breaking
> changes
> > > on
> > > > > >> > > > Category A repositories would've had the potential to
> break
> > > > > >> Category B
> > > > > >> > > > silently, leaving Category B with a broken development
> > stream,
> > > > and
> > > > > >> > > > introducing unpleasant surprises for maintainers of
> > Category B
> > > > > >> repos,
> > > > > >> > > > as historically Category A contributors were not familiar
> > with
> > > > > >> > > > Category B repos.
> > > > > >> > > >
> > > > > >> > > > Contributions made to Category B repos go through a GitHub
> > > > Actions
> > > > > >> > > > workflow that builds the relevant part of the `kie-tools`
> > > > monorepo
> > > > > >> for
> > > > > >> > > > the changes introduced. Changes made to the pipeline
> itself
> > > are
> > > > > also
> > > > > >> > > > picked up as part of PRs, allowing us to do things like
> > > > atomically
> > > > > >> > > > bumping the Node.js version, for example. More
> importantly,
> > it
> > > > > >> allows
> > > > > >> > > > us to upgrade the repository to a new timestamped SNAPSHOT
> > > > > together
> > > > > >> > > > with the changes necessary to make it stay green.
> > > > > >> > > >
> > > > > >> > > > This setup, however, makes it impossible to have
> cross-repo
> > > PRs
> > > > > >> > > > involving Category A and Category B simultaneously, with
> the
> > > > > current
> > > > > >> > > > automations we have.
> > > > > >> > > >
> > > > > >> > > > Category C repos are kind of floating around, and I'm not
> > sure
> > > > if
> > > > > >> > > > there's much activity going on there. Regardless, as
> they're
> > > > part
> > > > > of
> > > > > >> > > > Apache KIE, they will be part of our release, so I listed
> > them
> > > > for
> > > > > >> us
> > > > > >> > > > to take them into consideration too.
> > > > > >> > > >
> > > > > >> > > > Category D is self explanatory. There's only one repo that
> > has
> > > > > >> already
> > > > > >> > > > been marked for being archived.
> > > > > >> > > >
> > > > > >> > > > Category E are repos that do not host code directly, and
> are
> > > > > either
> > > > > >> > > > organizational entities, or host websites, that currently
> > are
> > > > not
> > > > > >> part
> > > > > >> > > > of any pipelines we have.
> > > > > >> > > >
> > > > > >> > > > This lack of unification between Category A and Category B
> > is,
> > > > > IMHO,
> > > > > >> > > > what allowed us to introduce the infamous circular
> > dependency
> > > > > >> between
> > > > > >> > > > `kie-tools` and `kogito-apps`, which we now can describe
> as
> > a
> > > > > >> circular
> > > > > >> > > > dependency between Category A and Category B. The way I
> see
> > > it,
> > > > if
> > > > > >> we
> > > > > >> > > > had a single pipeline, building everything from `drools`
> to
> > > > > >> > > > `kie-tools`, such flaws would've never been introduced,
> and
> > we
> > > > > >> > > > wouldn't be having this huge problem in our hands right
> now.
> > > > > >> > > >
> > > > > >> > > > My proposal for the Apache KIE release process sees this
> > lack
> > > of
> > > > > >> > > > unification as a central problem, not only for this
> release
> > in
> > > > > >> > > > particular, but for the community as a whole. It is my
> > belief
> > > > that
> > > > > >> we
> > > > > >> > > > are all under the same roof, and that no contribution
> should
> > > be
> > > > > >> > > > allowed to break any part of our codebase. With the
> > increasing
> > > > > >> volume
> > > > > >> > > > of code, and hopefully number of contributors too, we
> cannot
> > > > keep
> > > > > >> > > > counting on "common sense" to avoid breaking things. We're
> > all
> > > > > >> humans
> > > > > >> > > > after all, and it is our job to have mechanisms in place
> to
> > > > > prevent
> > > > > >> us
> > > > > >> > > > from unwillingly making mistakes. Especially when these
> > > mistakes
> > > > > >> > > > impact on parts of the codebase that we, individually,
> > > probably
> > > > > >> can't
> > > > > >> > > > fix.
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > >> > > >
> > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on
> kiegroup's
> > > KIE
> > > > > >> Tools
> > > > > >> > > > `0.32.0`.
> > > > > >> > > > See:
> > > > > >> > > > -
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > P2. PR open for Kogito SWF images @ `kogito-images`
> > depending
> > > on
> > > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > > >> > > > See:
> > > > > >> > > > -
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's
> > `lienzo`
> > > > and
> > > > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > > >> > > > See:
> > > > > >> > > > -
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > >> > > > -
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > P4. Multiple packages @ `kogito-apps` depending on
> > kiegroup's
> > > > > >> > > > Explainability `1.22.1.Final`.
> > > > > >> > > > * This module was removed from the KIE codebase here:
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > >> > > > and now lives on
> > > > > >> > > >
> > > > > https://github.com/trustyai-explainability/trustyai-explainability
> ,
> > > > > >> > > > under a different GAV.
> > > > > >> > > > * This new repo depends on Kogito and OptaPlanner,
> pointing
> > to
> > > > > older
> > > > > >> > > > versions.
> > > > > >> > > > See:
> > > > > >> > > > -
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > >> > > > -
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending
> on
> > > > > Kogito
> > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > >> > > > See:
> > > > > >> > > > -
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > P6. Category C repos are out of date and not part of the
> > > > Category
> > > > > A
> > > > > >> > > > CI/Release pipelines.
> > > > > >> > > > * incubator-kie-kogito-benchmarks: (Current version is
> > > > > >> `2.0-SNAPSHOT`,
> > > > > >> > > > depending on Kogito without a specific version, only by
> > using
> > > > > >> > > > `http://localhost:8080`)
> > > > > >> > > > * incubator-kie-benchmarks: (Current version is
> > > `1.0-SNAPSHOT`,
> > > > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> > > > `8.45.0-SNAPSHOT`)
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E
> > > disabled
> > > > > >> after
> > > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > In my perspective, P1 and P2 have the same solution, as
> they
> > > > both
> > > > > >> > > > suffer from the circular dependency between Category A and
> > > > > Category
> > > > > >> B.
> > > > > >> > > > As Category A and Category B are both streams that have
> been
> > > > > really
> > > > > >> > > > active, I see this as a blocker, as there are
> contributions
> > > that
> > > > > >> > > > cannot be done, given that Category A depends on Category
> B
> > > > with a
> > > > > >> > > > dephasing of 1 release.
> > > > > >> > > >
> > > > > >> > > > P3 and P4, although not ideal, can be understood as
> > technical
> > > > > debt.
> > > > > >> > > > Depending on unmaintained projects is something we'll
> always
> > > be
> > > > > >> > > > susceptible to, given time.
> > > > > >> > > >
> > > > > >> > > > P5 and P6 are easily fixable, as it's just a matter of
> > making
> > > > them
> > > > > >> > > > part of the play.
> > > > > >> > > >
> > > > > >> > > > P7 is an isolated problem that won't impact the structure
> or
> > > > > >> anything
> > > > > >> > > > that we're talking about here, but it is a regression we
> > > > > introduced
> > > > > >> > > > recently.
> > > > > >> > > >
> > > > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and
> > that
> > > > P5,
> > > > > >> P6,
> > > > > >> > > > and P7 have easy fixes, the only problems left to discuss
> > are
> > > P1
> > > > > and
> > > > > >> > > > P2, which can't be done without a proper proposal.
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > # THE PROPOSAL
> > > > > >> > > >
> > > > > >> > > > I'll try to be very meticulous here, since from my
> > experience,
> > > > any
> > > > > >> > > > little miscalculation can lead to our release not working
> > out
> > > in
> > > > > the
> > > > > >> > > > end. To try and avoid that as much as possible, and make
> > > > > everything
> > > > > >> we
> > > > > >> > > > can to have a successful Apache KIE 10 release, bear with
> > me.
> > > > I'll
> > > > > >> lay
> > > > > >> > > > out a timeline of events that need to happen in order for
> > our
> > > > > >> release
> > > > > >> > > > to be published, with all artifacts ending up in the right
> > > > places,
> > > > > >> but
> > > > > >> > > > first, we need to solve problems P1 and P2.
> > > > > >> > > >
> > > > > >> > > > As you saw at the beginning of this email, all the
> attempts
> > we
> > > > > made
> > > > > >> > > > left us with the circular dependency showing up at a
> > different
> > > > > >> place,
> > > > > >> > > > but something all these places have in common is that
> > they're
> > > > all
> > > > > >> > > > after kogito-apps, and before to Category B.
> > > > > >> > > >
> > > > > >> > > > The first part of my proposal is the following:
> > > > > >> > > >
> > > > > >> > > > S1. We keep the original plan of moving the Quarkus Dev
> UIs
> > > from
> > > > > >> > > > `kogito-apps` to `kie-tools`, together with Management and
> > > Task
> > > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > > >> > > > S2. We move the `kogito-swf-devmode` and
> > `kogito-swf-builder`
> > > > > images
> > > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > > >> > > > S3. We move the entire `kogito-serverless-operator` repo
> > > inside
> > > > a
> > > > > >> new
> > > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > > >> > > >
> > > > > >> > > > Solutions S1, S2, and S3 together solve problems P1 and
> P2.
> > Of
> > > > > >> course
> > > > > >> > > > the rest of
> > > > > >> https://github.com/apache/incubator-kie-issues/issues/967
> > > > > >> > > > would still be done too.
> > > > > >> > > >
> > > > > >> > > > This doesn't come without consequences, of course, as the
> > > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder` images, and
> > the
> > > > > >> > > > `kogito-serverless-operator` would be moving from
> Category A
> > > to
> > > > > >> > > > Category B. This move would make them have to reference
> > > > Category A
> > > > > >> > > > repos through timestamped SNAPSHOTs. Since `kogito-images`
> > and
> > > > > >> > > > `kogito-serverless-operator` are already their own
> > > "sub-stream"
> > > > > >> inside
> > > > > >> > > > Category A, though, contributions made in a cross-repo
> > fashion
> > > > to
> > > > > >> this
> > > > > >> > > > "sub-stream" will continue being possible, now via a
> single
> > PR
> > > > to
> > > > > >> > > > `kie-tools`. Cross-repo PRs between Category A and
> Category
> > B
> > > > will
> > > > > >> > > > continue not being possible, and a 1-week delay between
> > > merging
> > > > > >> > > > something on Category A and using it on Category B will
> > still
> > > > > >> happen.
> > > > > >> > > >
> > > > > >> > > > It's worth mentioning that `kie-tools`, however, does
> allow
> > > for
> > > > > >> sparse
> > > > > >> > > > checkouts and partial builds, so working with a subset of
> > the
> > > > > >> monorepo
> > > > > >> > > > is possible and encouraged. Making changes only to
> > > > > >> > > > `packages/kn-plugin-workflow`, for example, will have the
> PR
> > > > > checks
> > > > > >> > > > run in < 10 minutes, as you can see here:
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > >> > > > .
> > > > > >> > > > We're not compromising when running partial builds too. We
> > > know
> > > > > that
> > > > > >> > > > the entire repo will continue working even after only
> > > building a
> > > > > >> small
> > > > > >> > > > subset of the changes. Doing partial or full builds is
> > > > > automatically
> > > > > >> > > > determined by the changes of a PR.
> > > > > >> > > >
> > > > > >> > > > Keep in mind that, even though I'm proposing we move a
> bunch
> > > of
> > > > > >> > > > additional stuff into `kie-tools`, I see this as a
> TEMPORARY
> > > > > >> solution
> > > > > >> > > > for our codebase. `kie-tools` would host some additional
> > stuff
> > > > > >> > > > TEMPORARILY so that we can release and continue moving
> > > forward.
> > > > > >> > > >
> > > > > >> > > > As I mentioned on other places, `kie-tools` became a
> > polyglot
> > > > > >> monorepo
> > > > > >> > > > out of necessity, and although I'm really proud of what we
> > > > > achieved
> > > > > >> > > > there so far, I don't think `kie-tools` has a setup that
> is
> > > > > suitable
> > > > > >> > > > for all the different nuances that compose our community.
> > I'm
> > > > well
> > > > > >> > > > aware that a polyglot monorepo that does not follow
> > widespread
> > > > > >> > > > conventions will scare some people away, and as much as
> > we've
> > > > > tried
> > > > > >> to
> > > > > >> > > > make build instructions clear, we can't always get past
> the
> > > > > >> prejudice
> > > > > >> > > > some people have towards the "front-end" ecosystem.
> > > > > >> > > >
> > > > > >> > > > With all that said, I keep thinking this is the best
> course
> > of
> > > > > >> action
> > > > > >> > > > for us right now. We keep most of our stuff unchanged, we
> > > > unblock
> > > > > >> the
> > > > > >> > > > release, and we have a working setup that will suit us
> well
> > > > while
> > > > > we
> > > > > >> > > > discuss and reach a conclusion regarding the future of our
> > > > > codebase
> > > > > >> > > > structure.
> > > > > >> > > >
> > > > > >> > > > Let me paint a quick picture here of what our code base
> > would
> > > > look
> > > > > >> > > > like, repository-wise, if my proposal is accepted:
> > > > > >> > > >
> > > > > >> > > > CATEGORY REPO
> > > > > >> > > > =====================
> > > > > >> > > > A incubator-kie-kogito-pipelines
> > > > > >> > > > A incubator-kie-drools
> > > > > >> > > > A incubator-kie-optaplanner
> > > > > >> > > > A incubator-kie-optaplanner-quickstarts
> > > > > >> > > > A incubator-kie-kogito-runtimes
> > > > > >> > > > A incubator-kie-kogito-apps
> > > > > >> > > > A incubator-kie-kogito-examples
> > > > > >> > > > A incubator-kie-kogito-images
> > > > > >> > > > A incubator-kie-kogito-docs
> > > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > > >> > > > A incubator-kie-docs
> > > > > >> > > > A incubator-kie-benchmarks
> > > > > >> > > > =====================
> > > > > >> > > > B incubator-kie-sandbox-quarkus-accelerator
> > > > > >> > > > B incubator-kie-tools
> > > > > >> > > > =====================
> > > > > >> > > > D incubator-kie-kogito-operator
> > > > > >> > > > =====================
> > > > > >> > > > E incubator-kie-issues
> > > > > >> > > > E incubator-kie-kogito-website
> > > > > >> > > > E incubator-kie-website
> > > > > >> > > > E incubator-kie-kogito-online
> > > > > >> > > > E incubator-kie-kogito-online-staging
> > > > > >> > > > =====================
> > > > > >> > > >
> > > > > >> > > > * Category C becomes part of Category A, and
> > > > > >> > > > `kogito-serverless-operator` moves entirely inside
> > > `kie-tools`.
> > > > > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > > >> > > > `kogito-serverless-operator` inside `kie-tools`, there are
> > no
> > > > > cycles
> > > > > >> > > > anymore, as inside `kie-tools`, we can granularly build:
> > > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > > >> > > > 3. packages/sonataflow-images (containing
> > > > `kogito-swf-builder`
> > > > > >> and
> > > > > >> > > > `kogito-swf-devmode`)
> > > > > >> > > > 4. packages/sonataflow-operator (contents from
> > > > > >> > > > `kogito-serverless-operator`)
> > > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > > (`packages/kn-plugin-workflow`,
> > > > > >> > > > but renamed)
> > > > > >> > > >
> > > > > >> > > > The second part of the proposal is the release process
> > itself,
> > > > > >> > > > assuming the structure above is what we have.
> > > > > >> > > >
> > > > > >> > > > Here it is:
> > > > > >> > > >
> > > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as cutting
> point
> > > for
> > > > > >> > > > Category A repos.
> > > > > >> > > > 2. Update Category B repos to point to this timestamped
> > > > SNAPSHOT,
> > > > > >> and
> > > > > >> > > > verify that everything is working.
> > > > > >> > > > 3. At this point, with everything working, we can branch
> out
> > > to
> > > > > >> > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag,
> and
> > > > > >> Category B
> > > > > >> > > > from `main`.
> > > > > >> > > > 4. All Category A and Category B repos update their
> versions
> > > to
> > > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > > >> > > > 5. Update Category B repos to point to Category A repos
> > using
> > > > the
> > > > > >> > > > 10.0.0 version.
> > > > > >> > > > 6. At this point, we can vote on the release based on the
> > > > `10.0.x`
> > > > > >> > > > branches, given we don't expect any code changes anymore.
> > > > > >> > > > 7. After voting passes, we're good to start the release
> > > process.
> > > > > >> > > > 8. Category A repos follow their manual/automated release
> > > > process,
> > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and
> > built
> > > > > >> > > > artifacts pushed to their registries.
> > > > > >> > > > 9. We wait a little bit for Category A artifacts to be
> > > > propagated
> > > > > on
> > > > > >> > > > registries. ~1 day.
> > > > > >> > > > 10. Category B repos follow their manual/automated release
> > > > > process,
> > > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and
> > built
> > > > > >> > > > artifacts pushed to their registries.
> > > > > >> > > > 11. Category D repos are ignored.
> > > > > >> > > > 12. Category E repos can be manually tagged with 10.0.0
> from
> > > > their
> > > > > >> > > > default branches.
> > > > > >> > > >
> > > > > >> > > > More needs to be discussed if we're planning to maintain
> > > > multiple
> > > > > >> > > > release streams in parallel, but I guess it can wait for
> > after
> > > > > >> Apache
> > > > > >> > > > KIE 10.
> > > > > >> > > >
> > > > > >> > > > Thank you for reading, and I'm looking forward to hearing
> > back
> > > > > from
> > > > > >> > > > everyone.
> > > > > >> > > >
> > > > > >> > > > Of course, alternative solutions are possible. This email,
> > > > > however,
> > > > > >> > > > summarizes my view of how we should attack the problem,
> > > > > considering
> > > > > >> > > > disruption, required effort, the release process itself,
> and
> > > > > >> history.
> > > > > >> > > > Feel free to propose alternatives. This is not a voting
> > > thread.
> > > > > >> > > >
> > > > > >> > > > Regards,
> > > > > >> > > >
> > > > > >> > > > Tiago Bento
> > > > > >> > > >
> > > > > >> > > >
> > > > > >>
> > > ---------------------------------------------------------------------
> > > > > >> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > >> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <al...@porcelli.me>.
Francisco and Grabriele,
You may not like or understand why the current state of the CI is like
that… actually has been in Red Hat and has been replicated in Apache as
used to be….
But the fact is that this is the current reality.
If you disagree with the current plan, please provide a detailed
alternative so we, as community, can better evaluate the pros and cons of
each proposal.
I think it’s also fair to say that, post 10 release we need to have a much
in depth discussion about how our codebase is organized, it’s clear that
it’s not working.
On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi <ga...@gmail.com>
wrote:
> As Francisco said,
> I also have the impression that the "images" (if we are talking of docker
> images) should be the very last one to be built, in a standalone repo.
> That way, they may "combine" artifacts that are built in different repos,
> regardless of the order in which those are built.
> Moving them out of all the repos (kogito-apps/kie-tools) maybe could
> simplify the situation a bit.
> (I also think there are some statements of undisputable needs while they
> are, actually, just technical choices.
> Anyway, this latter point is for longer, following, discussion.)
>
>
>
>
> Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier Tirado Sarti <
> ftirados@redhat.com> ha scritto:
>
> > Alex,
> > There are two assumptions that deserve further discussion:
> > 1) That tool has to be the last to build. why? it does not have more
> sense
> > to build final images after everything else has been built?-
> > 2) That the impact (in terms of effort now) on fixing CI is bigger than
> the
> > impact (long term consequences) of consolidating two unrelated piece of
> > software within the same repository.
> >
> >
> > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > Francisco,
> > >
> > > This was discussed as an alternative solution, however it has major
> > impact
> > > on CI and there’s also the fact Tool has been always the last to build
> > and
> > > has no Snapshot published (actually in JavaScript world there is no
> > > snapshot concept).
> > >
> > > So, based on our evaluation… the proposal here is the least disruptive
> > and
> > > will take less time to unblock the release.
> > >
> > > Regards,
> > > _____________
> > > Alex Porcelli
> > > http://porcelli.me
> > >
> > >
> > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado Sarti <
> > > ftirados@redhat.com> wrote:
> > >
> > > > After kie-tools, sorry. I think we are not embracing the fact that
> > > > kogito-images depend on kie-tools, because we want those images to
> > > include
> > > > tools.
> > > >
> > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado Sarti <
> > > > ftirados@redhat.com> wrote:
> > > >
> > > > > Hi Tiago,
> > > > > It can be an alternative solution to move kn-plugin-workflow to
> > > > > kogito-images (so there is not longer dependency from tools to
> > images)
> > > > and
> > > > > then build kogito-images after kogito-tools?
> > > > >
> > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez <
> > > > > egonzalez@apache.org> wrote:
> > > > >
> > > > >> +1 to unblock release
> > > > >>
> > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > > > pefernan@apache.org>
> > > > >> escribió:
> > > > >>
> > > > >> > I say +1 in order to move forward with the 10.
> > > > >> >
> > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > >> >
> > > > >> > > +1
> > > > >> > >
> > > > >> > > I spent the last day or so working closely with Tiago,
> exploring
> > > > >> > different
> > > > >> > > options and getting deeper on the impact and evaluating the
> > > overall
> > > > >> > release
> > > > >> > > procedure steps required. I agree with the proposal as the
> most
> > > > >> > > viable option for unblocking the 10 release in the reasonable
> > time
> > > > >> frame.
> > > > >> > >
> > > > >> > >
> > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > > tiagobento@apache.org>
> > > > >> > wrote:
> > > > >> > >
> > > > >> > > > Hi everyone,
> > > > >> > > >
> > > > >> > > > Unfortunately, I can't do a tl;dr this time, as this matter
> > > > >> requires a
> > > > >> > > > lot of context.
> > > > >> > > >
> > > > >> > > > This email will take you < 20 minutes to read, according to
> > > > >> > > > https://thereadtime.com/.
> > > > >> > > >
> > > > >> > > > As you may have followed on a separate thread
> > > > >> > > > (
> > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > > ),
> > > > >> > > > many of us were working towards removing a circular
> dependency
> > > > >> > > > currently present between `kogito-apps` and `kie-tools`. As
> we
> > > > >> > > > progressed towards a solution, we kept finding the circular
> > > > >> dependency
> > > > >> > > > pop up somewhere else. I'll do a breakdown of the things we
> > did,
> > > > and
> > > > >> > > > the results we had.
> > > > >> > > >
> > > > >> > > > Right now, even though we started the effort to move the
> > Quarkus
> > > > Dev
> > > > >> > > > UI modules to `kie-tools`, we haven't been able to do it
> yet,
> > as
> > > > >> we've
> > > > >> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and
> > > Quarkus
> > > > >> > > > 3.2.9, compatible with Kogito Runtimes
> 999-20240218-SNAPSHOT.
> > > This
> > > > >> > > > effort was concluded this Monday, with
> > > > >> > > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > > > >> > > >
> > > > >> > > > The current scenario we have is:
> > > > >> > > >
> > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > > >> > > > C | 03. incubator-kie-kogito-examples
> > > > >> > > > Y | 04. incubator-kie-kogito-images
> > > > >> > > > C | 05. incubator-kie-kogito-serverless-operator
> > > > >> > > > L | ==========================
> > > > >> > > > E | 06.
> incubator-kie-sandbox-quarkus-accelerator
> > > > >> > > > |==> 07. incubator-kie-tools
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > * As `kie-tools`/extended-services depends on
> > > > >> > > > `kogito-apps`/jitexecutor;
> > > > >> > > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > > depend
> > > > >> on
> > > > >> > > > `kie-tools`/{many packages}
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`, we would've
> > > had:
> > > > >> > > >
> > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > >> > > > 02. incubator-kie-kogito-apps
> > > > >> > > > 03. incubator-kie-kogito-examples
> > > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > > >> > > > Y | 05. incubator-kie-kogito-serverless-operator
> > > > >> > > > C | =====================
> > > > >> > > > L | 06.
> incubator-kie-sandbox-quarkus-accelerator
> > > > >> > > > E |==> 07. incubator-kie-tools
> > > > >> > > >
> > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > > >> > > > * and `kogito-images`/kogito-swf-devmode depends on
> > > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > After moving the `kogito-swf-devmode` image to `kie-tools`,
> we
> > > > >> would've
> > > > >> > > > had:
> > > > >> > > >
> > > > >> > > > 01. incubator-kie-kogito-runtimes
> > > > >> > > > 02. incubator-kie-kogito-apps
> > > > >> > > > 03. incubator-kie-kogito-examples
> > > > >> > > > 04. incubator-kie-kogito-images
> > > > >> > > > C |==> 05. incubator-kie-kogito-serverless-operator
> > > > >> > > > Y | =====================
> > > > >> > > > C | 06.
> incubator-kie-sandbox-quarkus-accelerator
> > > > >> > > > L |==> 07. incubator-kie-tools
> > > > >> > > > E
> > > > >> > > >
> > > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > >> > > > `kogito-serverless-operator`;
> > > > >> > > > * and `kogito-serverless-operator` depends on
> > > > >> > > > `kie-tools`/kogito-swf-devmode
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > Clearly, we have a much bigger problem than a simple
> circular
> > > > >> > dependency.
> > > > >> > > >
> > > > >> > > > After multiple conversations with a lot of people, it's been
> > > > really
> > > > >> > > > hard coming up with a simple solution that makes it possible
> > to
> > > > >> build
> > > > >> > > > Apache KIE in one shot, while preserving the way everyone is
> > > used
> > > > to
> > > > >> > > > contributing to the multiple repositories we have. More than
> > > that,
> > > > >> > > > while making this assessment, I found more problems that, in
> > my
> > > > >> > > > perspective, block Apache KIE 10.
> > > > >> > > >
> > > > >> > > > In light of that difficulty, I'm coming forward with my
> > proposal
> > > > for
> > > > >> > > > the Apache KIE release process, so we can use Apache's
> > > mechanisms
> > > > to
> > > > >> > > > have a slower-paced, in-depth debate about this really
> > > complicated
> > > > >> > > > matter.
> > > > >> > > >
> > > > >> > > > I'll lay out my entire perspective about the current
> situation
> > > of
> > > > >> our
> > > > >> > > > codebase, as well as problems I can currently see. I'll
> start
> > > with
> > > > >> an
> > > > >> > > > analysis of the repositories and their purposes, point out
> > some
> > > > >> > > > problems that I believe are blocking our 10 release, explain
> > my
> > > > >> > > > proposal and discuss some consequences to what I'm
> proposing.
> > > > >> > > >
> > > > >> > > > Let's begin.
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > # THE APACHE KIE REPOS
> > > > >> > > >
> > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > >> > > > - incubator-kie-drools @ `main`
> > > > >> > > > - incubator-kie-optaplanner @ `main`
> > > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > > >> > > > - incubator-kie-kogito-images @ `main`
> > > > >> > > > - incubator-kie-kogito-serverless-operator @ `main`
> > > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > > >> > > >
> > > > >> > > > B. TOOLS (count: 2)
> > > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > > >> > > > - incubator-kie-tools @ `main`
> > > > >> > > >
> > > > >> > > > C. BENCHMARKS (count: 2)
> > > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > >> > > > - incubator-kie-benchmarks @ `main`
> > > > >> > > >
> > > > >> > > > D. ARCHIVED (count: 1)
> > > > >> > > > - incubator-kie-kogito-operator
> > > > >> > > >
> > > > >> > > > E. "NON-CODE" (count: 5)
> > > > >> > > > - incubator-kie-issues @ `main`
> > > > >> > > > (Issues only, README should be updated @ `main`. Same
> for
> > > > GitHub
> > > > >> > > > Actions workflows.)
> > > > >> > > > - incubator-kie-kogito-website @ `main`
> > > > >> > > > (The Kogito website. Develop & deploy at the `main`
> > branch.)
> > > > >> > > > - incubator-kie-website @ `main`
> > > > >> > > > (The KIE website. Develop @ `main`. Push @ `deploy` to
> > > update
> > > > >> the
> > > > >> > > > website.)
> > > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > >> > > > (GitHub pages used to host sandbox.kie.org and KIE
> Tools'
> > > > >> Chrome
> > > > >> > > > Extension assets.)
> > > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > >> > > > (Same as above, but for manual sanity checks during the
> > > > staging
> > > > >> > > > phase of a release.)
> > > > >> > > >
> > > > >> > > > TOTAL (count: 21)
> > > > >> > > >
> > > > >> > > > I grouped the repositories by category, and listed them in a
> > > > >> > > > topological order. Keep in mind that when flattening out a
> > tree,
> > > > >> there
> > > > >> > > > are multiple possibilities. For example, OptaPlanner
> could've
> > > been
> > > > >> > > > placed in any position after Drools.
> > > > >> > > >
> > > > >> > > > Category A repos are what I've been referring to as `drools`
> > and
> > > > >> > > > `kogito-*` stream. Of course OptaPlanner is inside that
> > stream,
> > > as
> > > > >> the
> > > > >> > > > way these repositories reference each other are through
> Maven
> > > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This
> > > > >> mechanism
> > > > >> > > > is well-known to the team, and although flawed for intra-day
> > > > builds
> > > > >> > > > and disruptive for people in many different time zones, it
> is
> > > > >> already
> > > > >> > > > very comfortable for everyone to work with, I assume.
> > > > >> > > >
> > > > >> > > > Contributions made to Category A have some dedicated
> > pipelines,
> > > > >> which
> > > > >> > > > are, at least to some extent, able to build cross-repo PRs
> > > > together
> > > > >> > > > and verify that the codebase will continue working as
> expected
> > > > after
> > > > >> > > > they're all merged. From what I could gather, there are some
> > > > >> > > > "sub-streams" currently configured for cross-repo PRs.
> > > > >> > > >
> > > > >> > > > - kogito-pipelines
> > > > >> > > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > > >> > > > - kogito-images, and kogito-serverless-operator
> > > > >> > > > - kogito-docs
> > > > >> > > > - kie-docs
> > > > >> > > >
> > > > >> > > > This means that sending cross-repo PRs to any combination of
> > > repos
> > > > >> > > > that are not part of the same "sub-stream" cannot be
> verified
> > > > before
> > > > >> > > > merging, making our contribution model dependent on
> individual
> > > > >> > > > contributors building stuff on their machines to verify that
> > it
> > > > >> works.
> > > > >> > > >
> > > > >> > > > I based this analysis on
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > >> > > > ,
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > >> > > > ,
> > > > >> > > > and
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > >> > > > .
> > > > >> > > > Note that I'm not that familiar with these pipelines, so
> > please
> > > > >> > > > someone correct me if I'm wrong.
> > > > >> > > >
> > > > >> > > > Category B repos are what I've been referring to as
> > `kie-tools`
> > > > >> > > > stream. The first repo there is a template repository that
> is
> > > used
> > > > >> by
> > > > >> > > > people starting projects from scratch on KIE Sandbox,
> similar
> > > to a
> > > > >> > > > Maven archetype, if you will. The other one is the KIE Tools
> > > > >> monorepo,
> > > > >> > > > a polyglot monorepo with `pnpm` as its build system.
> > Currently,
> > > > KIE
> > > > >> > > > Tools hosts Java libraries and apps, TypeScript libraries
> and
> > > > apps,
> > > > >> Go
> > > > >> > > > apps, Docker images, and Helm charts. The `kie-tools`
> monorepo
> > > is
> > > > >> > > > configured to work with sparse checkouts and can do partial
> > > > builds.
> > > > >> > > > Category B repos refer to Category A repos through
> timestamped
> > > > >> > > > SNAPSHOTs. This is a new mechanism we recently introduced
> that
> > > > will
> > > > >> > > > build and publish immutable, persistent artifacts under a
> > > version
> > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly
> > > every
> > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an evolution to the
> > > Kogito
> > > > >> > > > releases, as we're now targeting one release for all of
> Apache
> > > > KIE,
> > > > >> so
> > > > >> > > > we can't have Kogito releases anymore.
> > > > >> > > >
> > > > >> > > > An important note here is that Category B repositories have
> > been
> > > > >> > > > historically kept out of any automations we used to have,
> way
> > > back
> > > > >> > > > when Kogito started and we had the Business Central (a.k.a.
> > v7)
> > > > >> stream
> > > > >> > > > still going on. For this reason, Category B projects have
> > > > developed
> > > > >> > > > their own automations, based on GitHub Actions. Category B
> > repos
> > > > >> have
> > > > >> > > > always depended on Category A repos using fixed versions. If
> > > > >> Category
> > > > >> > > > B repos have had adopted mutable SNAPSHOTs, breaking changes
> > on
> > > > >> > > > Category A repositories would've had the potential to break
> > > > >> Category B
> > > > >> > > > silently, leaving Category B with a broken development
> stream,
> > > and
> > > > >> > > > introducing unpleasant surprises for maintainers of
> Category B
> > > > >> repos,
> > > > >> > > > as historically Category A contributors were not familiar
> with
> > > > >> > > > Category B repos.
> > > > >> > > >
> > > > >> > > > Contributions made to Category B repos go through a GitHub
> > > Actions
> > > > >> > > > workflow that builds the relevant part of the `kie-tools`
> > > monorepo
> > > > >> for
> > > > >> > > > the changes introduced. Changes made to the pipeline itself
> > are
> > > > also
> > > > >> > > > picked up as part of PRs, allowing us to do things like
> > > atomically
> > > > >> > > > bumping the Node.js version, for example. More importantly,
> it
> > > > >> allows
> > > > >> > > > us to upgrade the repository to a new timestamped SNAPSHOT
> > > > together
> > > > >> > > > with the changes necessary to make it stay green.
> > > > >> > > >
> > > > >> > > > This setup, however, makes it impossible to have cross-repo
> > PRs
> > > > >> > > > involving Category A and Category B simultaneously, with the
> > > > current
> > > > >> > > > automations we have.
> > > > >> > > >
> > > > >> > > > Category C repos are kind of floating around, and I'm not
> sure
> > > if
> > > > >> > > > there's much activity going on there. Regardless, as they're
> > > part
> > > > of
> > > > >> > > > Apache KIE, they will be part of our release, so I listed
> them
> > > for
> > > > >> us
> > > > >> > > > to take them into consideration too.
> > > > >> > > >
> > > > >> > > > Category D is self explanatory. There's only one repo that
> has
> > > > >> already
> > > > >> > > > been marked for being archived.
> > > > >> > > >
> > > > >> > > > Category E are repos that do not host code directly, and are
> > > > either
> > > > >> > > > organizational entities, or host websites, that currently
> are
> > > not
> > > > >> part
> > > > >> > > > of any pipelines we have.
> > > > >> > > >
> > > > >> > > > This lack of unification between Category A and Category B
> is,
> > > > IMHO,
> > > > >> > > > what allowed us to introduce the infamous circular
> dependency
> > > > >> between
> > > > >> > > > `kie-tools` and `kogito-apps`, which we now can describe as
> a
> > > > >> circular
> > > > >> > > > dependency between Category A and Category B. The way I see
> > it,
> > > if
> > > > >> we
> > > > >> > > > had a single pipeline, building everything from `drools` to
> > > > >> > > > `kie-tools`, such flaws would've never been introduced, and
> we
> > > > >> > > > wouldn't be having this huge problem in our hands right now.
> > > > >> > > >
> > > > >> > > > My proposal for the Apache KIE release process sees this
> lack
> > of
> > > > >> > > > unification as a central problem, not only for this release
> in
> > > > >> > > > particular, but for the community as a whole. It is my
> belief
> > > that
> > > > >> we
> > > > >> > > > are all under the same roof, and that no contribution should
> > be
> > > > >> > > > allowed to break any part of our codebase. With the
> increasing
> > > > >> volume
> > > > >> > > > of code, and hopefully number of contributors too, we cannot
> > > keep
> > > > >> > > > counting on "common sense" to avoid breaking things. We're
> all
> > > > >> humans
> > > > >> > > > after all, and it is our job to have mechanisms in place to
> > > > prevent
> > > > >> us
> > > > >> > > > from unwillingly making mistakes. Especially when these
> > mistakes
> > > > >> > > > impact on parts of the codebase that we, individually,
> > probably
> > > > >> can't
> > > > >> > > > fix.
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > >> > > >
> > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's
> > KIE
> > > > >> Tools
> > > > >> > > > `0.32.0`.
> > > > >> > > > See:
> > > > >> > > > -
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > P2. PR open for Kogito SWF images @ `kogito-images`
> depending
> > on
> > > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > > >> > > > See:
> > > > >> > > > -
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's
> `lienzo`
> > > and
> > > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > >> > > > See:
> > > > >> > > > -
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > >> > > > -
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > P4. Multiple packages @ `kogito-apps` depending on
> kiegroup's
> > > > >> > > > Explainability `1.22.1.Final`.
> > > > >> > > > * This module was removed from the KIE codebase here:
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > >> > > > and now lives on
> > > > >> > > >
> > > > https://github.com/trustyai-explainability/trustyai-explainability,
> > > > >> > > > under a different GAV.
> > > > >> > > > * This new repo depends on Kogito and OptaPlanner, pointing
> to
> > > > older
> > > > >> > > > versions.
> > > > >> > > > See:
> > > > >> > > > -
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > >> > > > -
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on
> > > > Kogito
> > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > >> > > > See:
> > > > >> > > > -
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > P6. Category C repos are out of date and not part of the
> > > Category
> > > > A
> > > > >> > > > CI/Release pipelines.
> > > > >> > > > * incubator-kie-kogito-benchmarks: (Current version is
> > > > >> `2.0-SNAPSHOT`,
> > > > >> > > > depending on Kogito without a specific version, only by
> using
> > > > >> > > > `http://localhost:8080`)
> > > > >> > > > * incubator-kie-benchmarks: (Current version is
> > `1.0-SNAPSHOT`,
> > > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> > > `8.45.0-SNAPSHOT`)
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E
> > disabled
> > > > >> after
> > > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > In my perspective, P1 and P2 have the same solution, as they
> > > both
> > > > >> > > > suffer from the circular dependency between Category A and
> > > > Category
> > > > >> B.
> > > > >> > > > As Category A and Category B are both streams that have been
> > > > really
> > > > >> > > > active, I see this as a blocker, as there are contributions
> > that
> > > > >> > > > cannot be done, given that Category A depends on Category B
> > > with a
> > > > >> > > > dephasing of 1 release.
> > > > >> > > >
> > > > >> > > > P3 and P4, although not ideal, can be understood as
> technical
> > > > debt.
> > > > >> > > > Depending on unmaintained projects is something we'll always
> > be
> > > > >> > > > susceptible to, given time.
> > > > >> > > >
> > > > >> > > > P5 and P6 are easily fixable, as it's just a matter of
> making
> > > them
> > > > >> > > > part of the play.
> > > > >> > > >
> > > > >> > > > P7 is an isolated problem that won't impact the structure or
> > > > >> anything
> > > > >> > > > that we're talking about here, but it is a regression we
> > > > introduced
> > > > >> > > > recently.
> > > > >> > > >
> > > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and
> that
> > > P5,
> > > > >> P6,
> > > > >> > > > and P7 have easy fixes, the only problems left to discuss
> are
> > P1
> > > > and
> > > > >> > > > P2, which can't be done without a proper proposal.
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > # THE PROPOSAL
> > > > >> > > >
> > > > >> > > > I'll try to be very meticulous here, since from my
> experience,
> > > any
> > > > >> > > > little miscalculation can lead to our release not working
> out
> > in
> > > > the
> > > > >> > > > end. To try and avoid that as much as possible, and make
> > > > everything
> > > > >> we
> > > > >> > > > can to have a successful Apache KIE 10 release, bear with
> me.
> > > I'll
> > > > >> lay
> > > > >> > > > out a timeline of events that need to happen in order for
> our
> > > > >> release
> > > > >> > > > to be published, with all artifacts ending up in the right
> > > places,
> > > > >> but
> > > > >> > > > first, we need to solve problems P1 and P2.
> > > > >> > > >
> > > > >> > > > As you saw at the beginning of this email, all the attempts
> we
> > > > made
> > > > >> > > > left us with the circular dependency showing up at a
> different
> > > > >> place,
> > > > >> > > > but something all these places have in common is that
> they're
> > > all
> > > > >> > > > after kogito-apps, and before to Category B.
> > > > >> > > >
> > > > >> > > > The first part of my proposal is the following:
> > > > >> > > >
> > > > >> > > > S1. We keep the original plan of moving the Quarkus Dev UIs
> > from
> > > > >> > > > `kogito-apps` to `kie-tools`, together with Management and
> > Task
> > > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > > >> > > > S2. We move the `kogito-swf-devmode` and
> `kogito-swf-builder`
> > > > images
> > > > >> > > > from `kogito-images` to `kie-tools` too.
> > > > >> > > > S3. We move the entire `kogito-serverless-operator` repo
> > inside
> > > a
> > > > >> new
> > > > >> > > > package on `kie-tools`, keeping Git history.
> > > > >> > > >
> > > > >> > > > Solutions S1, S2, and S3 together solve problems P1 and P2.
> Of
> > > > >> course
> > > > >> > > > the rest of
> > > > >> https://github.com/apache/incubator-kie-issues/issues/967
> > > > >> > > > would still be done too.
> > > > >> > > >
> > > > >> > > > This doesn't come without consequences, of course, as the
> > > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder` images, and
> the
> > > > >> > > > `kogito-serverless-operator` would be moving from Category A
> > to
> > > > >> > > > Category B. This move would make them have to reference
> > > Category A
> > > > >> > > > repos through timestamped SNAPSHOTs. Since `kogito-images`
> and
> > > > >> > > > `kogito-serverless-operator` are already their own
> > "sub-stream"
> > > > >> inside
> > > > >> > > > Category A, though, contributions made in a cross-repo
> fashion
> > > to
> > > > >> this
> > > > >> > > > "sub-stream" will continue being possible, now via a single
> PR
> > > to
> > > > >> > > > `kie-tools`. Cross-repo PRs between Category A and Category
> B
> > > will
> > > > >> > > > continue not being possible, and a 1-week delay between
> > merging
> > > > >> > > > something on Category A and using it on Category B will
> still
> > > > >> happen.
> > > > >> > > >
> > > > >> > > > It's worth mentioning that `kie-tools`, however, does allow
> > for
> > > > >> sparse
> > > > >> > > > checkouts and partial builds, so working with a subset of
> the
> > > > >> monorepo
> > > > >> > > > is possible and encouraged. Making changes only to
> > > > >> > > > `packages/kn-plugin-workflow`, for example, will have the PR
> > > > checks
> > > > >> > > > run in < 10 minutes, as you can see here:
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > >> > > > .
> > > > >> > > > We're not compromising when running partial builds too. We
> > know
> > > > that
> > > > >> > > > the entire repo will continue working even after only
> > building a
> > > > >> small
> > > > >> > > > subset of the changes. Doing partial or full builds is
> > > > automatically
> > > > >> > > > determined by the changes of a PR.
> > > > >> > > >
> > > > >> > > > Keep in mind that, even though I'm proposing we move a bunch
> > of
> > > > >> > > > additional stuff into `kie-tools`, I see this as a TEMPORARY
> > > > >> solution
> > > > >> > > > for our codebase. `kie-tools` would host some additional
> stuff
> > > > >> > > > TEMPORARILY so that we can release and continue moving
> > forward.
> > > > >> > > >
> > > > >> > > > As I mentioned on other places, `kie-tools` became a
> polyglot
> > > > >> monorepo
> > > > >> > > > out of necessity, and although I'm really proud of what we
> > > > achieved
> > > > >> > > > there so far, I don't think `kie-tools` has a setup that is
> > > > suitable
> > > > >> > > > for all the different nuances that compose our community.
> I'm
> > > well
> > > > >> > > > aware that a polyglot monorepo that does not follow
> widespread
> > > > >> > > > conventions will scare some people away, and as much as
> we've
> > > > tried
> > > > >> to
> > > > >> > > > make build instructions clear, we can't always get past the
> > > > >> prejudice
> > > > >> > > > some people have towards the "front-end" ecosystem.
> > > > >> > > >
> > > > >> > > > With all that said, I keep thinking this is the best course
> of
> > > > >> action
> > > > >> > > > for us right now. We keep most of our stuff unchanged, we
> > > unblock
> > > > >> the
> > > > >> > > > release, and we have a working setup that will suit us well
> > > while
> > > > we
> > > > >> > > > discuss and reach a conclusion regarding the future of our
> > > > codebase
> > > > >> > > > structure.
> > > > >> > > >
> > > > >> > > > Let me paint a quick picture here of what our code base
> would
> > > look
> > > > >> > > > like, repository-wise, if my proposal is accepted:
> > > > >> > > >
> > > > >> > > > CATEGORY REPO
> > > > >> > > > =====================
> > > > >> > > > A incubator-kie-kogito-pipelines
> > > > >> > > > A incubator-kie-drools
> > > > >> > > > A incubator-kie-optaplanner
> > > > >> > > > A incubator-kie-optaplanner-quickstarts
> > > > >> > > > A incubator-kie-kogito-runtimes
> > > > >> > > > A incubator-kie-kogito-apps
> > > > >> > > > A incubator-kie-kogito-examples
> > > > >> > > > A incubator-kie-kogito-images
> > > > >> > > > A incubator-kie-kogito-docs
> > > > >> > > > A incubator-kie-kogito-benchmarks
> > > > >> > > > A incubator-kie-docs
> > > > >> > > > A incubator-kie-benchmarks
> > > > >> > > > =====================
> > > > >> > > > B incubator-kie-sandbox-quarkus-accelerator
> > > > >> > > > B incubator-kie-tools
> > > > >> > > > =====================
> > > > >> > > > D incubator-kie-kogito-operator
> > > > >> > > > =====================
> > > > >> > > > E incubator-kie-issues
> > > > >> > > > E incubator-kie-kogito-website
> > > > >> > > > E incubator-kie-website
> > > > >> > > > E incubator-kie-kogito-online
> > > > >> > > > E incubator-kie-kogito-online-staging
> > > > >> > > > =====================
> > > > >> > > >
> > > > >> > > > * Category C becomes part of Category A, and
> > > > >> > > > `kogito-serverless-operator` moves entirely inside
> > `kie-tools`.
> > > > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > >> > > > `kogito-serverless-operator` inside `kie-tools`, there are
> no
> > > > cycles
> > > > >> > > > anymore, as inside `kie-tools`, we can granularly build:
> > > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > > >> > > > 3. packages/sonataflow-images (containing
> > > `kogito-swf-builder`
> > > > >> and
> > > > >> > > > `kogito-swf-devmode`)
> > > > >> > > > 4. packages/sonataflow-operator (contents from
> > > > >> > > > `kogito-serverless-operator`)
> > > > >> > > > 5. packages/kn-plugin-sonataflow
> > > > (`packages/kn-plugin-workflow`,
> > > > >> > > > but renamed)
> > > > >> > > >
> > > > >> > > > The second part of the proposal is the release process
> itself,
> > > > >> > > > assuming the structure above is what we have.
> > > > >> > > >
> > > > >> > > > Here it is:
> > > > >> > > >
> > > > >> > > > 1. Define a timestamped SNAPSHOT to be used as cutting point
> > for
> > > > >> > > > Category A repos.
> > > > >> > > > 2. Update Category B repos to point to this timestamped
> > > SNAPSHOT,
> > > > >> and
> > > > >> > > > verify that everything is working.
> > > > >> > > > 3. At this point, with everything working, we can branch out
> > to
> > > > >> > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and
> > > > >> Category B
> > > > >> > > > from `main`.
> > > > >> > > > 4. All Category A and Category B repos update their versions
> > to
> > > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > > >> > > > 5. Update Category B repos to point to Category A repos
> using
> > > the
> > > > >> > > > 10.0.0 version.
> > > > >> > > > 6. At this point, we can vote on the release based on the
> > > `10.0.x`
> > > > >> > > > branches, given we don't expect any code changes anymore.
> > > > >> > > > 7. After voting passes, we're good to start the release
> > process.
> > > > >> > > > 8. Category A repos follow their manual/automated release
> > > process,
> > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and
> built
> > > > >> > > > artifacts pushed to their registries.
> > > > >> > > > 9. We wait a little bit for Category A artifacts to be
> > > propagated
> > > > on
> > > > >> > > > registries. ~1 day.
> > > > >> > > > 10. Category B repos follow their manual/automated release
> > > > process,
> > > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and
> built
> > > > >> > > > artifacts pushed to their registries.
> > > > >> > > > 11. Category D repos are ignored.
> > > > >> > > > 12. Category E repos can be manually tagged with 10.0.0 from
> > > their
> > > > >> > > > default branches.
> > > > >> > > >
> > > > >> > > > More needs to be discussed if we're planning to maintain
> > > multiple
> > > > >> > > > release streams in parallel, but I guess it can wait for
> after
> > > > >> Apache
> > > > >> > > > KIE 10.
> > > > >> > > >
> > > > >> > > > Thank you for reading, and I'm looking forward to hearing
> back
> > > > from
> > > > >> > > > everyone.
> > > > >> > > >
> > > > >> > > > Of course, alternative solutions are possible. This email,
> > > > however,
> > > > >> > > > summarizes my view of how we should attack the problem,
> > > > considering
> > > > >> > > > disruption, required effort, the release process itself, and
> > > > >> history.
> > > > >> > > > Feel free to propose alternatives. This is not a voting
> > thread.
> > > > >> > > >
> > > > >> > > > Regards,
> > > > >> > > >
> > > > >> > > > Tiago Bento
> > > > >> > > >
> > > > >> > > >
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > >> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Gabriele Cardosi <ga...@gmail.com>.
As Francisco said,
I also have the impression that the "images" (if we are talking of docker
images) should be the very last one to be built, in a standalone repo.
That way, they may "combine" artifacts that are built in different repos,
regardless of the order in which those are built.
Moving them out of all the repos (kogito-apps/kie-tools) maybe could
simplify the situation a bit.
(I also think there are some statements of undisputable needs while they
are, actually, just technical choices.
Anyway, this latter point is for longer, following, discussion.)
Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier Tirado Sarti <
ftirados@redhat.com> ha scritto:
> Alex,
> There are two assumptions that deserve further discussion:
> 1) That tool has to be the last to build. why? it does not have more sense
> to build final images after everything else has been built?-
> 2) That the impact (in terms of effort now) on fixing CI is bigger than the
> impact (long term consequences) of consolidating two unrelated piece of
> software within the same repository.
>
>
> On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <al...@porcelli.me> wrote:
>
> > Francisco,
> >
> > This was discussed as an alternative solution, however it has major
> impact
> > on CI and there’s also the fact Tool has been always the last to build
> and
> > has no Snapshot published (actually in JavaScript world there is no
> > snapshot concept).
> >
> > So, based on our evaluation… the proposal here is the least disruptive
> and
> > will take less time to unblock the release.
> >
> > Regards,
> > _____________
> > Alex Porcelli
> > http://porcelli.me
> >
> >
> > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado Sarti <
> > ftirados@redhat.com> wrote:
> >
> > > After kie-tools, sorry. I think we are not embracing the fact that
> > > kogito-images depend on kie-tools, because we want those images to
> > include
> > > tools.
> > >
> > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado Sarti <
> > > ftirados@redhat.com> wrote:
> > >
> > > > Hi Tiago,
> > > > It can be an alternative solution to move kn-plugin-workflow to
> > > > kogito-images (so there is not longer dependency from tools to
> images)
> > > and
> > > > then build kogito-images after kogito-tools?
> > > >
> > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez <
> > > > egonzalez@apache.org> wrote:
> > > >
> > > >> +1 to unblock release
> > > >>
> > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > > pefernan@apache.org>
> > > >> escribió:
> > > >>
> > > >> > I say +1 in order to move forward with the 10.
> > > >> >
> > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <al...@porcelli.me>
> > wrote:
> > > >> >
> > > >> > > +1
> > > >> > >
> > > >> > > I spent the last day or so working closely with Tiago, exploring
> > > >> > different
> > > >> > > options and getting deeper on the impact and evaluating the
> > overall
> > > >> > release
> > > >> > > procedure steps required. I agree with the proposal as the most
> > > >> > > viable option for unblocking the 10 release in the reasonable
> time
> > > >> frame.
> > > >> > >
> > > >> > >
> > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> > tiagobento@apache.org>
> > > >> > wrote:
> > > >> > >
> > > >> > > > Hi everyone,
> > > >> > > >
> > > >> > > > Unfortunately, I can't do a tl;dr this time, as this matter
> > > >> requires a
> > > >> > > > lot of context.
> > > >> > > >
> > > >> > > > This email will take you < 20 minutes to read, according to
> > > >> > > > https://thereadtime.com/.
> > > >> > > >
> > > >> > > > As you may have followed on a separate thread
> > > >> > > > (
> > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > > ),
> > > >> > > > many of us were working towards removing a circular dependency
> > > >> > > > currently present between `kogito-apps` and `kie-tools`. As we
> > > >> > > > progressed towards a solution, we kept finding the circular
> > > >> dependency
> > > >> > > > pop up somewhere else. I'll do a breakdown of the things we
> did,
> > > and
> > > >> > > > the results we had.
> > > >> > > >
> > > >> > > > Right now, even though we started the effort to move the
> Quarkus
> > > Dev
> > > >> > > > UI modules to `kie-tools`, we haven't been able to do it yet,
> as
> > > >> we've
> > > >> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and
> > Quarkus
> > > >> > > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT.
> > This
> > > >> > > > effort was concluded this Monday, with
> > > >> > > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > > >> > > >
> > > >> > > > The current scenario we have is:
> > > >> > > >
> > > >> > > > 01. incubator-kie-kogito-runtimes
> > > >> > > > |==> 02. incubator-kie-kogito-apps
> > > >> > > > C | 03. incubator-kie-kogito-examples
> > > >> > > > Y | 04. incubator-kie-kogito-images
> > > >> > > > C | 05. incubator-kie-kogito-serverless-operator
> > > >> > > > L | ==========================
> > > >> > > > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > > >> > > > |==> 07. incubator-kie-tools
> > > >> > > >
> > > >> > > >
> > > >> > > > * As `kie-tools`/extended-services depends on
> > > >> > > > `kogito-apps`/jitexecutor;
> > > >> > > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> > depend
> > > >> on
> > > >> > > > `kie-tools`/{many packages}
> > > >> > > >
> > > >> > > >
> > > >> > > > After moving the Quarkus Dev UIs to `kie-tools`, we would've
> > had:
> > > >> > > >
> > > >> > > > 01. incubator-kie-kogito-runtimes
> > > >> > > > 02. incubator-kie-kogito-apps
> > > >> > > > 03. incubator-kie-kogito-examples
> > > >> > > > C |==> 04. incubator-kie-kogito-images
> > > >> > > > Y | 05. incubator-kie-kogito-serverless-operator
> > > >> > > > C | =====================
> > > >> > > > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > > >> > > > E |==> 07. incubator-kie-tools
> > > >> > > >
> > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > >> > > > `kogito-images`/kogito-swf-devmode;
> > > >> > > > * and `kogito-images`/kogito-swf-devmode depends on
> > > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > > >> > > >
> > > >> > > >
> > > >> > > > After moving the `kogito-swf-devmode` image to `kie-tools`, we
> > > >> would've
> > > >> > > > had:
> > > >> > > >
> > > >> > > > 01. incubator-kie-kogito-runtimes
> > > >> > > > 02. incubator-kie-kogito-apps
> > > >> > > > 03. incubator-kie-kogito-examples
> > > >> > > > 04. incubator-kie-kogito-images
> > > >> > > > C |==> 05. incubator-kie-kogito-serverless-operator
> > > >> > > > Y | =====================
> > > >> > > > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > > >> > > > L |==> 07. incubator-kie-tools
> > > >> > > > E
> > > >> > > >
> > > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > >> > > > `kogito-serverless-operator`;
> > > >> > > > * and `kogito-serverless-operator` depends on
> > > >> > > > `kie-tools`/kogito-swf-devmode
> > > >> > > >
> > > >> > > >
> > > >> > > > Clearly, we have a much bigger problem than a simple circular
> > > >> > dependency.
> > > >> > > >
> > > >> > > > After multiple conversations with a lot of people, it's been
> > > really
> > > >> > > > hard coming up with a simple solution that makes it possible
> to
> > > >> build
> > > >> > > > Apache KIE in one shot, while preserving the way everyone is
> > used
> > > to
> > > >> > > > contributing to the multiple repositories we have. More than
> > that,
> > > >> > > > while making this assessment, I found more problems that, in
> my
> > > >> > > > perspective, block Apache KIE 10.
> > > >> > > >
> > > >> > > > In light of that difficulty, I'm coming forward with my
> proposal
> > > for
> > > >> > > > the Apache KIE release process, so we can use Apache's
> > mechanisms
> > > to
> > > >> > > > have a slower-paced, in-depth debate about this really
> > complicated
> > > >> > > > matter.
> > > >> > > >
> > > >> > > > I'll lay out my entire perspective about the current situation
> > of
> > > >> our
> > > >> > > > codebase, as well as problems I can currently see. I'll start
> > with
> > > >> an
> > > >> > > > analysis of the repositories and their purposes, point out
> some
> > > >> > > > problems that I believe are blocking our 10 release, explain
> my
> > > >> > > > proposal and discuss some consequences to what I'm proposing.
> > > >> > > >
> > > >> > > > Let's begin.
> > > >> > > >
> > > >> > > >
> > > >> > > > # THE APACHE KIE REPOS
> > > >> > > >
> > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > > >> > > > - incubator-kie-drools @ `main`
> > > >> > > > - incubator-kie-optaplanner @ `main`
> > > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > > >> > > > - incubator-kie-kogito-apps @ `main`
> > > >> > > > - incubator-kie-kogito-examples @ `main`
> > > >> > > > - incubator-kie-kogito-images @ `main`
> > > >> > > > - incubator-kie-kogito-serverless-operator @ `main`
> > > >> > > > - incubator-kie-kogito-docs @ `main`
> > > >> > > > - incubator-kie-docs @ `main-kogito`
> > > >> > > >
> > > >> > > > B. TOOLS (count: 2)
> > > >> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > >> > > > - incubator-kie-tools @ `main`
> > > >> > > >
> > > >> > > > C. BENCHMARKS (count: 2)
> > > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > >> > > > - incubator-kie-benchmarks @ `main`
> > > >> > > >
> > > >> > > > D. ARCHIVED (count: 1)
> > > >> > > > - incubator-kie-kogito-operator
> > > >> > > >
> > > >> > > > E. "NON-CODE" (count: 5)
> > > >> > > > - incubator-kie-issues @ `main`
> > > >> > > > (Issues only, README should be updated @ `main`. Same for
> > > GitHub
> > > >> > > > Actions workflows.)
> > > >> > > > - incubator-kie-kogito-website @ `main`
> > > >> > > > (The Kogito website. Develop & deploy at the `main`
> branch.)
> > > >> > > > - incubator-kie-website @ `main`
> > > >> > > > (The KIE website. Develop @ `main`. Push @ `deploy` to
> > update
> > > >> the
> > > >> > > > website.)
> > > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > >> > > > (GitHub pages used to host sandbox.kie.org and KIE Tools'
> > > >> Chrome
> > > >> > > > Extension assets.)
> > > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > > >> > > > (Same as above, but for manual sanity checks during the
> > > staging
> > > >> > > > phase of a release.)
> > > >> > > >
> > > >> > > > TOTAL (count: 21)
> > > >> > > >
> > > >> > > > I grouped the repositories by category, and listed them in a
> > > >> > > > topological order. Keep in mind that when flattening out a
> tree,
> > > >> there
> > > >> > > > are multiple possibilities. For example, OptaPlanner could've
> > been
> > > >> > > > placed in any position after Drools.
> > > >> > > >
> > > >> > > > Category A repos are what I've been referring to as `drools`
> and
> > > >> > > > `kogito-*` stream. Of course OptaPlanner is inside that
> stream,
> > as
> > > >> the
> > > >> > > > way these repositories reference each other are through Maven
> > > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This
> > > >> mechanism
> > > >> > > > is well-known to the team, and although flawed for intra-day
> > > builds
> > > >> > > > and disruptive for people in many different time zones, it is
> > > >> already
> > > >> > > > very comfortable for everyone to work with, I assume.
> > > >> > > >
> > > >> > > > Contributions made to Category A have some dedicated
> pipelines,
> > > >> which
> > > >> > > > are, at least to some extent, able to build cross-repo PRs
> > > together
> > > >> > > > and verify that the codebase will continue working as expected
> > > after
> > > >> > > > they're all merged. From what I could gather, there are some
> > > >> > > > "sub-streams" currently configured for cross-repo PRs.
> > > >> > > >
> > > >> > > > - kogito-pipelines
> > > >> > > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > > >> > > > - optaplanner, and optaplanner-quickstarts
> > > >> > > > - kogito-images, and kogito-serverless-operator
> > > >> > > > - kogito-docs
> > > >> > > > - kie-docs
> > > >> > > >
> > > >> > > > This means that sending cross-repo PRs to any combination of
> > repos
> > > >> > > > that are not part of the same "sub-stream" cannot be verified
> > > before
> > > >> > > > merging, making our contribution model dependent on individual
> > > >> > > > contributors building stuff on their machines to verify that
> it
> > > >> works.
> > > >> > > >
> > > >> > > > I based this analysis on
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > >> > > > ,
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > >> > > > ,
> > > >> > > > and
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > >> > > > .
> > > >> > > > Note that I'm not that familiar with these pipelines, so
> please
> > > >> > > > someone correct me if I'm wrong.
> > > >> > > >
> > > >> > > > Category B repos are what I've been referring to as
> `kie-tools`
> > > >> > > > stream. The first repo there is a template repository that is
> > used
> > > >> by
> > > >> > > > people starting projects from scratch on KIE Sandbox, similar
> > to a
> > > >> > > > Maven archetype, if you will. The other one is the KIE Tools
> > > >> monorepo,
> > > >> > > > a polyglot monorepo with `pnpm` as its build system.
> Currently,
> > > KIE
> > > >> > > > Tools hosts Java libraries and apps, TypeScript libraries and
> > > apps,
> > > >> Go
> > > >> > > > apps, Docker images, and Helm charts. The `kie-tools` monorepo
> > is
> > > >> > > > configured to work with sparse checkouts and can do partial
> > > builds.
> > > >> > > > Category B repos refer to Category A repos through timestamped
> > > >> > > > SNAPSHOTs. This is a new mechanism we recently introduced that
> > > will
> > > >> > > > build and publish immutable, persistent artifacts under a
> > version
> > > >> > > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly
> > every
> > > >> > > > Sunday night. Timestamped SNAPSHOTs are an evolution to the
> > Kogito
> > > >> > > > releases, as we're now targeting one release for all of Apache
> > > KIE,
> > > >> so
> > > >> > > > we can't have Kogito releases anymore.
> > > >> > > >
> > > >> > > > An important note here is that Category B repositories have
> been
> > > >> > > > historically kept out of any automations we used to have, way
> > back
> > > >> > > > when Kogito started and we had the Business Central (a.k.a.
> v7)
> > > >> stream
> > > >> > > > still going on. For this reason, Category B projects have
> > > developed
> > > >> > > > their own automations, based on GitHub Actions. Category B
> repos
> > > >> have
> > > >> > > > always depended on Category A repos using fixed versions. If
> > > >> Category
> > > >> > > > B repos have had adopted mutable SNAPSHOTs, breaking changes
> on
> > > >> > > > Category A repositories would've had the potential to break
> > > >> Category B
> > > >> > > > silently, leaving Category B with a broken development stream,
> > and
> > > >> > > > introducing unpleasant surprises for maintainers of Category B
> > > >> repos,
> > > >> > > > as historically Category A contributors were not familiar with
> > > >> > > > Category B repos.
> > > >> > > >
> > > >> > > > Contributions made to Category B repos go through a GitHub
> > Actions
> > > >> > > > workflow that builds the relevant part of the `kie-tools`
> > monorepo
> > > >> for
> > > >> > > > the changes introduced. Changes made to the pipeline itself
> are
> > > also
> > > >> > > > picked up as part of PRs, allowing us to do things like
> > atomically
> > > >> > > > bumping the Node.js version, for example. More importantly, it
> > > >> allows
> > > >> > > > us to upgrade the repository to a new timestamped SNAPSHOT
> > > together
> > > >> > > > with the changes necessary to make it stay green.
> > > >> > > >
> > > >> > > > This setup, however, makes it impossible to have cross-repo
> PRs
> > > >> > > > involving Category A and Category B simultaneously, with the
> > > current
> > > >> > > > automations we have.
> > > >> > > >
> > > >> > > > Category C repos are kind of floating around, and I'm not sure
> > if
> > > >> > > > there's much activity going on there. Regardless, as they're
> > part
> > > of
> > > >> > > > Apache KIE, they will be part of our release, so I listed them
> > for
> > > >> us
> > > >> > > > to take them into consideration too.
> > > >> > > >
> > > >> > > > Category D is self explanatory. There's only one repo that has
> > > >> already
> > > >> > > > been marked for being archived.
> > > >> > > >
> > > >> > > > Category E are repos that do not host code directly, and are
> > > either
> > > >> > > > organizational entities, or host websites, that currently are
> > not
> > > >> part
> > > >> > > > of any pipelines we have.
> > > >> > > >
> > > >> > > > This lack of unification between Category A and Category B is,
> > > IMHO,
> > > >> > > > what allowed us to introduce the infamous circular dependency
> > > >> between
> > > >> > > > `kie-tools` and `kogito-apps`, which we now can describe as a
> > > >> circular
> > > >> > > > dependency between Category A and Category B. The way I see
> it,
> > if
> > > >> we
> > > >> > > > had a single pipeline, building everything from `drools` to
> > > >> > > > `kie-tools`, such flaws would've never been introduced, and we
> > > >> > > > wouldn't be having this huge problem in our hands right now.
> > > >> > > >
> > > >> > > > My proposal for the Apache KIE release process sees this lack
> of
> > > >> > > > unification as a central problem, not only for this release in
> > > >> > > > particular, but for the community as a whole. It is my belief
> > that
> > > >> we
> > > >> > > > are all under the same roof, and that no contribution should
> be
> > > >> > > > allowed to break any part of our codebase. With the increasing
> > > >> volume
> > > >> > > > of code, and hopefully number of contributors too, we cannot
> > keep
> > > >> > > > counting on "common sense" to avoid breaking things. We're all
> > > >> humans
> > > >> > > > after all, and it is our job to have mechanisms in place to
> > > prevent
> > > >> us
> > > >> > > > from unwillingly making mistakes. Especially when these
> mistakes
> > > >> > > > impact on parts of the codebase that we, individually,
> probably
> > > >> can't
> > > >> > > > fix.
> > > >> > > >
> > > >> > > >
> > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > >> > > >
> > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's
> KIE
> > > >> Tools
> > > >> > > > `0.32.0`.
> > > >> > > > See:
> > > >> > > > -
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > >> > > >
> > > >> > > >
> > > >> > > > P2. PR open for Kogito SWF images @ `kogito-images` depending
> on
> > > >> > > > kiegroup's KIE Tools `0.32.0`.
> > > >> > > > See:
> > > >> > > > -
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > >> > > >
> > > >> > > >
> > > >> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo`
> > and
> > > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > >> > > > See:
> > > >> > > > -
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > >> > > > -
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > >> > > >
> > > >> > > >
> > > >> > > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > > >> > > > Explainability `1.22.1.Final`.
> > > >> > > > * This module was removed from the KIE codebase here:
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > >> > > > and now lives on
> > > >> > > >
> > > https://github.com/trustyai-explainability/trustyai-explainability,
> > > >> > > > under a different GAV.
> > > >> > > > * This new repo depends on Kogito and OptaPlanner, pointing to
> > > older
> > > >> > > > versions.
> > > >> > > > See:
> > > >> > > > -
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > >> > > > -
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > >> > > >
> > > >> > > >
> > > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on
> > > Kogito
> > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > >> > > > See:
> > > >> > > > -
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > >> > > >
> > > >> > > >
> > > >> > > > P6. Category C repos are out of date and not part of the
> > Category
> > > A
> > > >> > > > CI/Release pipelines.
> > > >> > > > * incubator-kie-kogito-benchmarks: (Current version is
> > > >> `2.0-SNAPSHOT`,
> > > >> > > > depending on Kogito without a specific version, only by using
> > > >> > > > `http://localhost:8080`)
> > > >> > > > * incubator-kie-benchmarks: (Current version is
> `1.0-SNAPSHOT`,
> > > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> > `8.45.0-SNAPSHOT`)
> > > >> > > >
> > > >> > > >
> > > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E
> disabled
> > > >> after
> > > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > > >> > > >
> > > >> > > >
> > > >> > > > In my perspective, P1 and P2 have the same solution, as they
> > both
> > > >> > > > suffer from the circular dependency between Category A and
> > > Category
> > > >> B.
> > > >> > > > As Category A and Category B are both streams that have been
> > > really
> > > >> > > > active, I see this as a blocker, as there are contributions
> that
> > > >> > > > cannot be done, given that Category A depends on Category B
> > with a
> > > >> > > > dephasing of 1 release.
> > > >> > > >
> > > >> > > > P3 and P4, although not ideal, can be understood as technical
> > > debt.
> > > >> > > > Depending on unmaintained projects is something we'll always
> be
> > > >> > > > susceptible to, given time.
> > > >> > > >
> > > >> > > > P5 and P6 are easily fixable, as it's just a matter of making
> > them
> > > >> > > > part of the play.
> > > >> > > >
> > > >> > > > P7 is an isolated problem that won't impact the structure or
> > > >> anything
> > > >> > > > that we're talking about here, but it is a regression we
> > > introduced
> > > >> > > > recently.
> > > >> > > >
> > > >> > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that
> > P5,
> > > >> P6,
> > > >> > > > and P7 have easy fixes, the only problems left to discuss are
> P1
> > > and
> > > >> > > > P2, which can't be done without a proper proposal.
> > > >> > > >
> > > >> > > >
> > > >> > > > # THE PROPOSAL
> > > >> > > >
> > > >> > > > I'll try to be very meticulous here, since from my experience,
> > any
> > > >> > > > little miscalculation can lead to our release not working out
> in
> > > the
> > > >> > > > end. To try and avoid that as much as possible, and make
> > > everything
> > > >> we
> > > >> > > > can to have a successful Apache KIE 10 release, bear with me.
> > I'll
> > > >> lay
> > > >> > > > out a timeline of events that need to happen in order for our
> > > >> release
> > > >> > > > to be published, with all artifacts ending up in the right
> > places,
> > > >> but
> > > >> > > > first, we need to solve problems P1 and P2.
> > > >> > > >
> > > >> > > > As you saw at the beginning of this email, all the attempts we
> > > made
> > > >> > > > left us with the circular dependency showing up at a different
> > > >> place,
> > > >> > > > but something all these places have in common is that they're
> > all
> > > >> > > > after kogito-apps, and before to Category B.
> > > >> > > >
> > > >> > > > The first part of my proposal is the following:
> > > >> > > >
> > > >> > > > S1. We keep the original plan of moving the Quarkus Dev UIs
> from
> > > >> > > > `kogito-apps` to `kie-tools`, together with Management and
> Task
> > > >> > > > consoles from `kogito-images` to `kie-tools`.
> > > >> > > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder`
> > > images
> > > >> > > > from `kogito-images` to `kie-tools` too.
> > > >> > > > S3. We move the entire `kogito-serverless-operator` repo
> inside
> > a
> > > >> new
> > > >> > > > package on `kie-tools`, keeping Git history.
> > > >> > > >
> > > >> > > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of
> > > >> course
> > > >> > > > the rest of
> > > >> https://github.com/apache/incubator-kie-issues/issues/967
> > > >> > > > would still be done too.
> > > >> > > >
> > > >> > > > This doesn't come without consequences, of course, as the
> > > >> > > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > > >> > > > `kogito-serverless-operator` would be moving from Category A
> to
> > > >> > > > Category B. This move would make them have to reference
> > Category A
> > > >> > > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > > >> > > > `kogito-serverless-operator` are already their own
> "sub-stream"
> > > >> inside
> > > >> > > > Category A, though, contributions made in a cross-repo fashion
> > to
> > > >> this
> > > >> > > > "sub-stream" will continue being possible, now via a single PR
> > to
> > > >> > > > `kie-tools`. Cross-repo PRs between Category A and Category B
> > will
> > > >> > > > continue not being possible, and a 1-week delay between
> merging
> > > >> > > > something on Category A and using it on Category B will still
> > > >> happen.
> > > >> > > >
> > > >> > > > It's worth mentioning that `kie-tools`, however, does allow
> for
> > > >> sparse
> > > >> > > > checkouts and partial builds, so working with a subset of the
> > > >> monorepo
> > > >> > > > is possible and encouraged. Making changes only to
> > > >> > > > `packages/kn-plugin-workflow`, for example, will have the PR
> > > checks
> > > >> > > > run in < 10 minutes, as you can see here:
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > >> > > > .
> > > >> > > > We're not compromising when running partial builds too. We
> know
> > > that
> > > >> > > > the entire repo will continue working even after only
> building a
> > > >> small
> > > >> > > > subset of the changes. Doing partial or full builds is
> > > automatically
> > > >> > > > determined by the changes of a PR.
> > > >> > > >
> > > >> > > > Keep in mind that, even though I'm proposing we move a bunch
> of
> > > >> > > > additional stuff into `kie-tools`, I see this as a TEMPORARY
> > > >> solution
> > > >> > > > for our codebase. `kie-tools` would host some additional stuff
> > > >> > > > TEMPORARILY so that we can release and continue moving
> forward.
> > > >> > > >
> > > >> > > > As I mentioned on other places, `kie-tools` became a polyglot
> > > >> monorepo
> > > >> > > > out of necessity, and although I'm really proud of what we
> > > achieved
> > > >> > > > there so far, I don't think `kie-tools` has a setup that is
> > > suitable
> > > >> > > > for all the different nuances that compose our community. I'm
> > well
> > > >> > > > aware that a polyglot monorepo that does not follow widespread
> > > >> > > > conventions will scare some people away, and as much as we've
> > > tried
> > > >> to
> > > >> > > > make build instructions clear, we can't always get past the
> > > >> prejudice
> > > >> > > > some people have towards the "front-end" ecosystem.
> > > >> > > >
> > > >> > > > With all that said, I keep thinking this is the best course of
> > > >> action
> > > >> > > > for us right now. We keep most of our stuff unchanged, we
> > unblock
> > > >> the
> > > >> > > > release, and we have a working setup that will suit us well
> > while
> > > we
> > > >> > > > discuss and reach a conclusion regarding the future of our
> > > codebase
> > > >> > > > structure.
> > > >> > > >
> > > >> > > > Let me paint a quick picture here of what our code base would
> > look
> > > >> > > > like, repository-wise, if my proposal is accepted:
> > > >> > > >
> > > >> > > > CATEGORY REPO
> > > >> > > > =====================
> > > >> > > > A incubator-kie-kogito-pipelines
> > > >> > > > A incubator-kie-drools
> > > >> > > > A incubator-kie-optaplanner
> > > >> > > > A incubator-kie-optaplanner-quickstarts
> > > >> > > > A incubator-kie-kogito-runtimes
> > > >> > > > A incubator-kie-kogito-apps
> > > >> > > > A incubator-kie-kogito-examples
> > > >> > > > A incubator-kie-kogito-images
> > > >> > > > A incubator-kie-kogito-docs
> > > >> > > > A incubator-kie-kogito-benchmarks
> > > >> > > > A incubator-kie-docs
> > > >> > > > A incubator-kie-benchmarks
> > > >> > > > =====================
> > > >> > > > B incubator-kie-sandbox-quarkus-accelerator
> > > >> > > > B incubator-kie-tools
> > > >> > > > =====================
> > > >> > > > D incubator-kie-kogito-operator
> > > >> > > > =====================
> > > >> > > > E incubator-kie-issues
> > > >> > > > E incubator-kie-kogito-website
> > > >> > > > E incubator-kie-website
> > > >> > > > E incubator-kie-kogito-online
> > > >> > > > E incubator-kie-kogito-online-staging
> > > >> > > > =====================
> > > >> > > >
> > > >> > > > * Category C becomes part of Category A, and
> > > >> > > > `kogito-serverless-operator` moves entirely inside
> `kie-tools`.
> > > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > > >> > > > `kogito-serverless-operator` inside `kie-tools`, there are no
> > > cycles
> > > >> > > > anymore, as inside `kie-tools`, we can granularly build:
> > > >> > > > 1. packages/sonataflow-deployment-webapp
> > > >> > > > 2. packages/sonataflow-quarkus-devui
> > > >> > > > 3. packages/sonataflow-images (containing
> > `kogito-swf-builder`
> > > >> and
> > > >> > > > `kogito-swf-devmode`)
> > > >> > > > 4. packages/sonataflow-operator (contents from
> > > >> > > > `kogito-serverless-operator`)
> > > >> > > > 5. packages/kn-plugin-sonataflow
> > > (`packages/kn-plugin-workflow`,
> > > >> > > > but renamed)
> > > >> > > >
> > > >> > > > The second part of the proposal is the release process itself,
> > > >> > > > assuming the structure above is what we have.
> > > >> > > >
> > > >> > > > Here it is:
> > > >> > > >
> > > >> > > > 1. Define a timestamped SNAPSHOT to be used as cutting point
> for
> > > >> > > > Category A repos.
> > > >> > > > 2. Update Category B repos to point to this timestamped
> > SNAPSHOT,
> > > >> and
> > > >> > > > verify that everything is working.
> > > >> > > > 3. At this point, with everything working, we can branch out
> to
> > > >> > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and
> > > >> Category B
> > > >> > > > from `main`.
> > > >> > > > 4. All Category A and Category B repos update their versions
> to
> > > >> > > > 10.0.0, in their `10.0.x` branches.
> > > >> > > > 5. Update Category B repos to point to Category A repos using
> > the
> > > >> > > > 10.0.0 version.
> > > >> > > > 6. At this point, we can vote on the release based on the
> > `10.0.x`
> > > >> > > > branches, given we don't expect any code changes anymore.
> > > >> > > > 7. After voting passes, we're good to start the release
> process.
> > > >> > > > 8. Category A repos follow their manual/automated release
> > process,
> > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > >> > > > artifacts pushed to their registries.
> > > >> > > > 9. We wait a little bit for Category A artifacts to be
> > propagated
> > > on
> > > >> > > > registries. ~1 day.
> > > >> > > > 10. Category B repos follow their manual/automated release
> > > process,
> > > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > >> > > > artifacts pushed to their registries.
> > > >> > > > 11. Category D repos are ignored.
> > > >> > > > 12. Category E repos can be manually tagged with 10.0.0 from
> > their
> > > >> > > > default branches.
> > > >> > > >
> > > >> > > > More needs to be discussed if we're planning to maintain
> > multiple
> > > >> > > > release streams in parallel, but I guess it can wait for after
> > > >> Apache
> > > >> > > > KIE 10.
> > > >> > > >
> > > >> > > > Thank you for reading, and I'm looking forward to hearing back
> > > from
> > > >> > > > everyone.
> > > >> > > >
> > > >> > > > Of course, alternative solutions are possible. This email,
> > > however,
> > > >> > > > summarizes my view of how we should attack the problem,
> > > considering
> > > >> > > > disruption, required effort, the release process itself, and
> > > >> history.
> > > >> > > > Feel free to propose alternatives. This is not a voting
> thread.
> > > >> > > >
> > > >> > > > Regards,
> > > >> > > >
> > > >> > > > Tiago Bento
> > > >> > > >
> > > >> > > >
> > > >>
> ---------------------------------------------------------------------
> > > >> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > >> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Alex,
There are two assumptions that deserve further discussion:
1) That tool has to be the last to build. why? it does not have more sense
to build final images after everything else has been built?-
2) That the impact (in terms of effort now) on fixing CI is bigger than the
impact (long term consequences) of consolidating two unrelated piece of
software within the same repository.
On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli <al...@porcelli.me> wrote:
> Francisco,
>
> This was discussed as an alternative solution, however it has major impact
> on CI and there’s also the fact Tool has been always the last to build and
> has no Snapshot published (actually in JavaScript world there is no
> snapshot concept).
>
> So, based on our evaluation… the proposal here is the least disruptive and
> will take less time to unblock the release.
>
> Regards,
> _____________
> Alex Porcelli
> http://porcelli.me
>
>
> On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado Sarti <
> ftirados@redhat.com> wrote:
>
> > After kie-tools, sorry. I think we are not embracing the fact that
> > kogito-images depend on kie-tools, because we want those images to
> include
> > tools.
> >
> > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado Sarti <
> > ftirados@redhat.com> wrote:
> >
> > > Hi Tiago,
> > > It can be an alternative solution to move kn-plugin-workflow to
> > > kogito-images (so there is not longer dependency from tools to images)
> > and
> > > then build kogito-images after kogito-tools?
> > >
> > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez <
> > > egonzalez@apache.org> wrote:
> > >
> > >> +1 to unblock release
> > >>
> > >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> > pefernan@apache.org>
> > >> escribió:
> > >>
> > >> > I say +1 in order to move forward with the 10.
> > >> >
> > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <al...@porcelli.me>
> wrote:
> > >> >
> > >> > > +1
> > >> > >
> > >> > > I spent the last day or so working closely with Tiago, exploring
> > >> > different
> > >> > > options and getting deeper on the impact and evaluating the
> overall
> > >> > release
> > >> > > procedure steps required. I agree with the proposal as the most
> > >> > > viable option for unblocking the 10 release in the reasonable time
> > >> frame.
> > >> > >
> > >> > >
> > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <
> tiagobento@apache.org>
> > >> > wrote:
> > >> > >
> > >> > > > Hi everyone,
> > >> > > >
> > >> > > > Unfortunately, I can't do a tl;dr this time, as this matter
> > >> requires a
> > >> > > > lot of context.
> > >> > > >
> > >> > > > This email will take you < 20 minutes to read, according to
> > >> > > > https://thereadtime.com/.
> > >> > > >
> > >> > > > As you may have followed on a separate thread
> > >> > > > (
> https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> > ),
> > >> > > > many of us were working towards removing a circular dependency
> > >> > > > currently present between `kogito-apps` and `kie-tools`. As we
> > >> > > > progressed towards a solution, we kept finding the circular
> > >> dependency
> > >> > > > pop up somewhere else. I'll do a breakdown of the things we did,
> > and
> > >> > > > the results we had.
> > >> > > >
> > >> > > > Right now, even though we started the effort to move the Quarkus
> > Dev
> > >> > > > UI modules to `kie-tools`, we haven't been able to do it yet, as
> > >> we've
> > >> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and
> Quarkus
> > >> > > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT.
> This
> > >> > > > effort was concluded this Monday, with
> > >> > > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > >> > > >
> > >> > > > The current scenario we have is:
> > >> > > >
> > >> > > > 01. incubator-kie-kogito-runtimes
> > >> > > > |==> 02. incubator-kie-kogito-apps
> > >> > > > C | 03. incubator-kie-kogito-examples
> > >> > > > Y | 04. incubator-kie-kogito-images
> > >> > > > C | 05. incubator-kie-kogito-serverless-operator
> > >> > > > L | ==========================
> > >> > > > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > >> > > > |==> 07. incubator-kie-tools
> > >> > > >
> > >> > > >
> > >> > > > * As `kie-tools`/extended-services depends on
> > >> > > > `kogito-apps`/jitexecutor;
> > >> > > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> depend
> > >> on
> > >> > > > `kie-tools`/{many packages}
> > >> > > >
> > >> > > >
> > >> > > > After moving the Quarkus Dev UIs to `kie-tools`, we would've
> had:
> > >> > > >
> > >> > > > 01. incubator-kie-kogito-runtimes
> > >> > > > 02. incubator-kie-kogito-apps
> > >> > > > 03. incubator-kie-kogito-examples
> > >> > > > C |==> 04. incubator-kie-kogito-images
> > >> > > > Y | 05. incubator-kie-kogito-serverless-operator
> > >> > > > C | =====================
> > >> > > > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > >> > > > E |==> 07. incubator-kie-tools
> > >> > > >
> > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > >> > > > `kogito-images`/kogito-swf-devmode;
> > >> > > > * and `kogito-images`/kogito-swf-devmode depends on
> > >> > > > `kie-tools`/sonataflow-quarkus-devui
> > >> > > >
> > >> > > >
> > >> > > > After moving the `kogito-swf-devmode` image to `kie-tools`, we
> > >> would've
> > >> > > > had:
> > >> > > >
> > >> > > > 01. incubator-kie-kogito-runtimes
> > >> > > > 02. incubator-kie-kogito-apps
> > >> > > > 03. incubator-kie-kogito-examples
> > >> > > > 04. incubator-kie-kogito-images
> > >> > > > C |==> 05. incubator-kie-kogito-serverless-operator
> > >> > > > Y | =====================
> > >> > > > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > >> > > > L |==> 07. incubator-kie-tools
> > >> > > > E
> > >> > > >
> > >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > >> > > > `kogito-serverless-operator`;
> > >> > > > * and `kogito-serverless-operator` depends on
> > >> > > > `kie-tools`/kogito-swf-devmode
> > >> > > >
> > >> > > >
> > >> > > > Clearly, we have a much bigger problem than a simple circular
> > >> > dependency.
> > >> > > >
> > >> > > > After multiple conversations with a lot of people, it's been
> > really
> > >> > > > hard coming up with a simple solution that makes it possible to
> > >> build
> > >> > > > Apache KIE in one shot, while preserving the way everyone is
> used
> > to
> > >> > > > contributing to the multiple repositories we have. More than
> that,
> > >> > > > while making this assessment, I found more problems that, in my
> > >> > > > perspective, block Apache KIE 10.
> > >> > > >
> > >> > > > In light of that difficulty, I'm coming forward with my proposal
> > for
> > >> > > > the Apache KIE release process, so we can use Apache's
> mechanisms
> > to
> > >> > > > have a slower-paced, in-depth debate about this really
> complicated
> > >> > > > matter.
> > >> > > >
> > >> > > > I'll lay out my entire perspective about the current situation
> of
> > >> our
> > >> > > > codebase, as well as problems I can currently see. I'll start
> with
> > >> an
> > >> > > > analysis of the repositories and their purposes, point out some
> > >> > > > problems that I believe are blocking our 10 release, explain my
> > >> > > > proposal and discuss some consequences to what I'm proposing.
> > >> > > >
> > >> > > > Let's begin.
> > >> > > >
> > >> > > >
> > >> > > > # THE APACHE KIE REPOS
> > >> > > >
> > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > >> > > > - incubator-kie-kogito-pipelines @ `main`
> > >> > > > - incubator-kie-drools @ `main`
> > >> > > > - incubator-kie-optaplanner @ `main`
> > >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > >> > > > - incubator-kie-kogito-runtimes @ `main`
> > >> > > > - incubator-kie-kogito-apps @ `main`
> > >> > > > - incubator-kie-kogito-examples @ `main`
> > >> > > > - incubator-kie-kogito-images @ `main`
> > >> > > > - incubator-kie-kogito-serverless-operator @ `main`
> > >> > > > - incubator-kie-kogito-docs @ `main`
> > >> > > > - incubator-kie-docs @ `main-kogito`
> > >> > > >
> > >> > > > B. TOOLS (count: 2)
> > >> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > >> > > > - incubator-kie-tools @ `main`
> > >> > > >
> > >> > > > C. BENCHMARKS (count: 2)
> > >> > > > - incubator-kie-kogito-benchmarks @ `main`
> > >> > > > - incubator-kie-benchmarks @ `main`
> > >> > > >
> > >> > > > D. ARCHIVED (count: 1)
> > >> > > > - incubator-kie-kogito-operator
> > >> > > >
> > >> > > > E. "NON-CODE" (count: 5)
> > >> > > > - incubator-kie-issues @ `main`
> > >> > > > (Issues only, README should be updated @ `main`. Same for
> > GitHub
> > >> > > > Actions workflows.)
> > >> > > > - incubator-kie-kogito-website @ `main`
> > >> > > > (The Kogito website. Develop & deploy at the `main` branch.)
> > >> > > > - incubator-kie-website @ `main`
> > >> > > > (The KIE website. Develop @ `main`. Push @ `deploy` to
> update
> > >> the
> > >> > > > website.)
> > >> > > > - incubator-kie-kogito-online @ `gh-pages`
> > >> > > > (GitHub pages used to host sandbox.kie.org and KIE Tools'
> > >> Chrome
> > >> > > > Extension assets.)
> > >> > > > - incubator-kie-kogito-online-staging @ `main`
> > >> > > > (Same as above, but for manual sanity checks during the
> > staging
> > >> > > > phase of a release.)
> > >> > > >
> > >> > > > TOTAL (count: 21)
> > >> > > >
> > >> > > > I grouped the repositories by category, and listed them in a
> > >> > > > topological order. Keep in mind that when flattening out a tree,
> > >> there
> > >> > > > are multiple possibilities. For example, OptaPlanner could've
> been
> > >> > > > placed in any position after Drools.
> > >> > > >
> > >> > > > Category A repos are what I've been referring to as `drools` and
> > >> > > > `kogito-*` stream. Of course OptaPlanner is inside that stream,
> as
> > >> the
> > >> > > > way these repositories reference each other are through Maven
> > >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This
> > >> mechanism
> > >> > > > is well-known to the team, and although flawed for intra-day
> > builds
> > >> > > > and disruptive for people in many different time zones, it is
> > >> already
> > >> > > > very comfortable for everyone to work with, I assume.
> > >> > > >
> > >> > > > Contributions made to Category A have some dedicated pipelines,
> > >> which
> > >> > > > are, at least to some extent, able to build cross-repo PRs
> > together
> > >> > > > and verify that the codebase will continue working as expected
> > after
> > >> > > > they're all merged. From what I could gather, there are some
> > >> > > > "sub-streams" currently configured for cross-repo PRs.
> > >> > > >
> > >> > > > - kogito-pipelines
> > >> > > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > >> > > > - optaplanner, and optaplanner-quickstarts
> > >> > > > - kogito-images, and kogito-serverless-operator
> > >> > > > - kogito-docs
> > >> > > > - kie-docs
> > >> > > >
> > >> > > > This means that sending cross-repo PRs to any combination of
> repos
> > >> > > > that are not part of the same "sub-stream" cannot be verified
> > before
> > >> > > > merging, making our contribution model dependent on individual
> > >> > > > contributors building stuff on their machines to verify that it
> > >> works.
> > >> > > >
> > >> > > > I based this analysis on
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > >> > > > ,
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > >> > > > ,
> > >> > > > and
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > >> > > > .
> > >> > > > Note that I'm not that familiar with these pipelines, so please
> > >> > > > someone correct me if I'm wrong.
> > >> > > >
> > >> > > > Category B repos are what I've been referring to as `kie-tools`
> > >> > > > stream. The first repo there is a template repository that is
> used
> > >> by
> > >> > > > people starting projects from scratch on KIE Sandbox, similar
> to a
> > >> > > > Maven archetype, if you will. The other one is the KIE Tools
> > >> monorepo,
> > >> > > > a polyglot monorepo with `pnpm` as its build system. Currently,
> > KIE
> > >> > > > Tools hosts Java libraries and apps, TypeScript libraries and
> > apps,
> > >> Go
> > >> > > > apps, Docker images, and Helm charts. The `kie-tools` monorepo
> is
> > >> > > > configured to work with sparse checkouts and can do partial
> > builds.
> > >> > > > Category B repos refer to Category A repos through timestamped
> > >> > > > SNAPSHOTs. This is a new mechanism we recently introduced that
> > will
> > >> > > > build and publish immutable, persistent artifacts under a
> version
> > >> > > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly
> every
> > >> > > > Sunday night. Timestamped SNAPSHOTs are an evolution to the
> Kogito
> > >> > > > releases, as we're now targeting one release for all of Apache
> > KIE,
> > >> so
> > >> > > > we can't have Kogito releases anymore.
> > >> > > >
> > >> > > > An important note here is that Category B repositories have been
> > >> > > > historically kept out of any automations we used to have, way
> back
> > >> > > > when Kogito started and we had the Business Central (a.k.a. v7)
> > >> stream
> > >> > > > still going on. For this reason, Category B projects have
> > developed
> > >> > > > their own automations, based on GitHub Actions. Category B repos
> > >> have
> > >> > > > always depended on Category A repos using fixed versions. If
> > >> Category
> > >> > > > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > >> > > > Category A repositories would've had the potential to break
> > >> Category B
> > >> > > > silently, leaving Category B with a broken development stream,
> and
> > >> > > > introducing unpleasant surprises for maintainers of Category B
> > >> repos,
> > >> > > > as historically Category A contributors were not familiar with
> > >> > > > Category B repos.
> > >> > > >
> > >> > > > Contributions made to Category B repos go through a GitHub
> Actions
> > >> > > > workflow that builds the relevant part of the `kie-tools`
> monorepo
> > >> for
> > >> > > > the changes introduced. Changes made to the pipeline itself are
> > also
> > >> > > > picked up as part of PRs, allowing us to do things like
> atomically
> > >> > > > bumping the Node.js version, for example. More importantly, it
> > >> allows
> > >> > > > us to upgrade the repository to a new timestamped SNAPSHOT
> > together
> > >> > > > with the changes necessary to make it stay green.
> > >> > > >
> > >> > > > This setup, however, makes it impossible to have cross-repo PRs
> > >> > > > involving Category A and Category B simultaneously, with the
> > current
> > >> > > > automations we have.
> > >> > > >
> > >> > > > Category C repos are kind of floating around, and I'm not sure
> if
> > >> > > > there's much activity going on there. Regardless, as they're
> part
> > of
> > >> > > > Apache KIE, they will be part of our release, so I listed them
> for
> > >> us
> > >> > > > to take them into consideration too.
> > >> > > >
> > >> > > > Category D is self explanatory. There's only one repo that has
> > >> already
> > >> > > > been marked for being archived.
> > >> > > >
> > >> > > > Category E are repos that do not host code directly, and are
> > either
> > >> > > > organizational entities, or host websites, that currently are
> not
> > >> part
> > >> > > > of any pipelines we have.
> > >> > > >
> > >> > > > This lack of unification between Category A and Category B is,
> > IMHO,
> > >> > > > what allowed us to introduce the infamous circular dependency
> > >> between
> > >> > > > `kie-tools` and `kogito-apps`, which we now can describe as a
> > >> circular
> > >> > > > dependency between Category A and Category B. The way I see it,
> if
> > >> we
> > >> > > > had a single pipeline, building everything from `drools` to
> > >> > > > `kie-tools`, such flaws would've never been introduced, and we
> > >> > > > wouldn't be having this huge problem in our hands right now.
> > >> > > >
> > >> > > > My proposal for the Apache KIE release process sees this lack of
> > >> > > > unification as a central problem, not only for this release in
> > >> > > > particular, but for the community as a whole. It is my belief
> that
> > >> we
> > >> > > > are all under the same roof, and that no contribution should be
> > >> > > > allowed to break any part of our codebase. With the increasing
> > >> volume
> > >> > > > of code, and hopefully number of contributors too, we cannot
> keep
> > >> > > > counting on "common sense" to avoid breaking things. We're all
> > >> humans
> > >> > > > after all, and it is our job to have mechanisms in place to
> > prevent
> > >> us
> > >> > > > from unwillingly making mistakes. Especially when these mistakes
> > >> > > > impact on parts of the codebase that we, individually, probably
> > >> can't
> > >> > > > fix.
> > >> > > >
> > >> > > >
> > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > >> > > >
> > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE
> > >> Tools
> > >> > > > `0.32.0`.
> > >> > > > See:
> > >> > > > -
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > >> > > >
> > >> > > >
> > >> > > > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > >> > > > kiegroup's KIE Tools `0.32.0`.
> > >> > > > See:
> > >> > > > -
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > >> > > >
> > >> > > >
> > >> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo`
> and
> > >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > >> > > > See:
> > >> > > > -
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > >> > > > -
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > >> > > >
> > >> > > >
> > >> > > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > >> > > > Explainability `1.22.1.Final`.
> > >> > > > * This module was removed from the KIE codebase here:
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > >> > > > and now lives on
> > >> > > >
> > https://github.com/trustyai-explainability/trustyai-explainability,
> > >> > > > under a different GAV.
> > >> > > > * This new repo depends on Kogito and OptaPlanner, pointing to
> > older
> > >> > > > versions.
> > >> > > > See:
> > >> > > > -
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > >> > > > -
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > >> > > >
> > >> > > >
> > >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on
> > Kogito
> > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > >> > > > See:
> > >> > > > -
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > >> > > >
> > >> > > >
> > >> > > > P6. Category C repos are out of date and not part of the
> Category
> > A
> > >> > > > CI/Release pipelines.
> > >> > > > * incubator-kie-kogito-benchmarks: (Current version is
> > >> `2.0-SNAPSHOT`,
> > >> > > > depending on Kogito without a specific version, only by using
> > >> > > > `http://localhost:8080`)
> > >> > > > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> `8.45.0-SNAPSHOT`)
> > >> > > >
> > >> > > >
> > >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled
> > >> after
> > >> > > > upgrading to 999-20240218-SNAPSHOT.
> > >> > > >
> > >> > > >
> > >> > > > In my perspective, P1 and P2 have the same solution, as they
> both
> > >> > > > suffer from the circular dependency between Category A and
> > Category
> > >> B.
> > >> > > > As Category A and Category B are both streams that have been
> > really
> > >> > > > active, I see this as a blocker, as there are contributions that
> > >> > > > cannot be done, given that Category A depends on Category B
> with a
> > >> > > > dephasing of 1 release.
> > >> > > >
> > >> > > > P3 and P4, although not ideal, can be understood as technical
> > debt.
> > >> > > > Depending on unmaintained projects is something we'll always be
> > >> > > > susceptible to, given time.
> > >> > > >
> > >> > > > P5 and P6 are easily fixable, as it's just a matter of making
> them
> > >> > > > part of the play.
> > >> > > >
> > >> > > > P7 is an isolated problem that won't impact the structure or
> > >> anything
> > >> > > > that we're talking about here, but it is a regression we
> > introduced
> > >> > > > recently.
> > >> > > >
> > >> > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that
> P5,
> > >> P6,
> > >> > > > and P7 have easy fixes, the only problems left to discuss are P1
> > and
> > >> > > > P2, which can't be done without a proper proposal.
> > >> > > >
> > >> > > >
> > >> > > > # THE PROPOSAL
> > >> > > >
> > >> > > > I'll try to be very meticulous here, since from my experience,
> any
> > >> > > > little miscalculation can lead to our release not working out in
> > the
> > >> > > > end. To try and avoid that as much as possible, and make
> > everything
> > >> we
> > >> > > > can to have a successful Apache KIE 10 release, bear with me.
> I'll
> > >> lay
> > >> > > > out a timeline of events that need to happen in order for our
> > >> release
> > >> > > > to be published, with all artifacts ending up in the right
> places,
> > >> but
> > >> > > > first, we need to solve problems P1 and P2.
> > >> > > >
> > >> > > > As you saw at the beginning of this email, all the attempts we
> > made
> > >> > > > left us with the circular dependency showing up at a different
> > >> place,
> > >> > > > but something all these places have in common is that they're
> all
> > >> > > > after kogito-apps, and before to Category B.
> > >> > > >
> > >> > > > The first part of my proposal is the following:
> > >> > > >
> > >> > > > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > >> > > > `kogito-apps` to `kie-tools`, together with Management and Task
> > >> > > > consoles from `kogito-images` to `kie-tools`.
> > >> > > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder`
> > images
> > >> > > > from `kogito-images` to `kie-tools` too.
> > >> > > > S3. We move the entire `kogito-serverless-operator` repo inside
> a
> > >> new
> > >> > > > package on `kie-tools`, keeping Git history.
> > >> > > >
> > >> > > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of
> > >> course
> > >> > > > the rest of
> > >> https://github.com/apache/incubator-kie-issues/issues/967
> > >> > > > would still be done too.
> > >> > > >
> > >> > > > This doesn't come without consequences, of course, as the
> > >> > > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > >> > > > `kogito-serverless-operator` would be moving from Category A to
> > >> > > > Category B. This move would make them have to reference
> Category A
> > >> > > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > >> > > > `kogito-serverless-operator` are already their own "sub-stream"
> > >> inside
> > >> > > > Category A, though, contributions made in a cross-repo fashion
> to
> > >> this
> > >> > > > "sub-stream" will continue being possible, now via a single PR
> to
> > >> > > > `kie-tools`. Cross-repo PRs between Category A and Category B
> will
> > >> > > > continue not being possible, and a 1-week delay between merging
> > >> > > > something on Category A and using it on Category B will still
> > >> happen.
> > >> > > >
> > >> > > > It's worth mentioning that `kie-tools`, however, does allow for
> > >> sparse
> > >> > > > checkouts and partial builds, so working with a subset of the
> > >> monorepo
> > >> > > > is possible and encouraged. Making changes only to
> > >> > > > `packages/kn-plugin-workflow`, for example, will have the PR
> > checks
> > >> > > > run in < 10 minutes, as you can see here:
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > >> > > > .
> > >> > > > We're not compromising when running partial builds too. We know
> > that
> > >> > > > the entire repo will continue working even after only building a
> > >> small
> > >> > > > subset of the changes. Doing partial or full builds is
> > automatically
> > >> > > > determined by the changes of a PR.
> > >> > > >
> > >> > > > Keep in mind that, even though I'm proposing we move a bunch of
> > >> > > > additional stuff into `kie-tools`, I see this as a TEMPORARY
> > >> solution
> > >> > > > for our codebase. `kie-tools` would host some additional stuff
> > >> > > > TEMPORARILY so that we can release and continue moving forward.
> > >> > > >
> > >> > > > As I mentioned on other places, `kie-tools` became a polyglot
> > >> monorepo
> > >> > > > out of necessity, and although I'm really proud of what we
> > achieved
> > >> > > > there so far, I don't think `kie-tools` has a setup that is
> > suitable
> > >> > > > for all the different nuances that compose our community. I'm
> well
> > >> > > > aware that a polyglot monorepo that does not follow widespread
> > >> > > > conventions will scare some people away, and as much as we've
> > tried
> > >> to
> > >> > > > make build instructions clear, we can't always get past the
> > >> prejudice
> > >> > > > some people have towards the "front-end" ecosystem.
> > >> > > >
> > >> > > > With all that said, I keep thinking this is the best course of
> > >> action
> > >> > > > for us right now. We keep most of our stuff unchanged, we
> unblock
> > >> the
> > >> > > > release, and we have a working setup that will suit us well
> while
> > we
> > >> > > > discuss and reach a conclusion regarding the future of our
> > codebase
> > >> > > > structure.
> > >> > > >
> > >> > > > Let me paint a quick picture here of what our code base would
> look
> > >> > > > like, repository-wise, if my proposal is accepted:
> > >> > > >
> > >> > > > CATEGORY REPO
> > >> > > > =====================
> > >> > > > A incubator-kie-kogito-pipelines
> > >> > > > A incubator-kie-drools
> > >> > > > A incubator-kie-optaplanner
> > >> > > > A incubator-kie-optaplanner-quickstarts
> > >> > > > A incubator-kie-kogito-runtimes
> > >> > > > A incubator-kie-kogito-apps
> > >> > > > A incubator-kie-kogito-examples
> > >> > > > A incubator-kie-kogito-images
> > >> > > > A incubator-kie-kogito-docs
> > >> > > > A incubator-kie-kogito-benchmarks
> > >> > > > A incubator-kie-docs
> > >> > > > A incubator-kie-benchmarks
> > >> > > > =====================
> > >> > > > B incubator-kie-sandbox-quarkus-accelerator
> > >> > > > B incubator-kie-tools
> > >> > > > =====================
> > >> > > > D incubator-kie-kogito-operator
> > >> > > > =====================
> > >> > > > E incubator-kie-issues
> > >> > > > E incubator-kie-kogito-website
> > >> > > > E incubator-kie-website
> > >> > > > E incubator-kie-kogito-online
> > >> > > > E incubator-kie-kogito-online-staging
> > >> > > > =====================
> > >> > > >
> > >> > > > * Category C becomes part of Category A, and
> > >> > > > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > >> > > > * With `kogito-swf-{builder,devmode}` images and
> > >> > > > `kogito-serverless-operator` inside `kie-tools`, there are no
> > cycles
> > >> > > > anymore, as inside `kie-tools`, we can granularly build:
> > >> > > > 1. packages/sonataflow-deployment-webapp
> > >> > > > 2. packages/sonataflow-quarkus-devui
> > >> > > > 3. packages/sonataflow-images (containing
> `kogito-swf-builder`
> > >> and
> > >> > > > `kogito-swf-devmode`)
> > >> > > > 4. packages/sonataflow-operator (contents from
> > >> > > > `kogito-serverless-operator`)
> > >> > > > 5. packages/kn-plugin-sonataflow
> > (`packages/kn-plugin-workflow`,
> > >> > > > but renamed)
> > >> > > >
> > >> > > > The second part of the proposal is the release process itself,
> > >> > > > assuming the structure above is what we have.
> > >> > > >
> > >> > > > Here it is:
> > >> > > >
> > >> > > > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > >> > > > Category A repos.
> > >> > > > 2. Update Category B repos to point to this timestamped
> SNAPSHOT,
> > >> and
> > >> > > > verify that everything is working.
> > >> > > > 3. At this point, with everything working, we can branch out to
> > >> > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and
> > >> Category B
> > >> > > > from `main`.
> > >> > > > 4. All Category A and Category B repos update their versions to
> > >> > > > 10.0.0, in their `10.0.x` branches.
> > >> > > > 5. Update Category B repos to point to Category A repos using
> the
> > >> > > > 10.0.0 version.
> > >> > > > 6. At this point, we can vote on the release based on the
> `10.0.x`
> > >> > > > branches, given we don't expect any code changes anymore.
> > >> > > > 7. After voting passes, we're good to start the release process.
> > >> > > > 8. Category A repos follow their manual/automated release
> process,
> > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > >> > > > artifacts pushed to their registries.
> > >> > > > 9. We wait a little bit for Category A artifacts to be
> propagated
> > on
> > >> > > > registries. ~1 day.
> > >> > > > 10. Category B repos follow their manual/automated release
> > process,
> > >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > >> > > > artifacts pushed to their registries.
> > >> > > > 11. Category D repos are ignored.
> > >> > > > 12. Category E repos can be manually tagged with 10.0.0 from
> their
> > >> > > > default branches.
> > >> > > >
> > >> > > > More needs to be discussed if we're planning to maintain
> multiple
> > >> > > > release streams in parallel, but I guess it can wait for after
> > >> Apache
> > >> > > > KIE 10.
> > >> > > >
> > >> > > > Thank you for reading, and I'm looking forward to hearing back
> > from
> > >> > > > everyone.
> > >> > > >
> > >> > > > Of course, alternative solutions are possible. This email,
> > however,
> > >> > > > summarizes my view of how we should attack the problem,
> > considering
> > >> > > > disruption, required effort, the release process itself, and
> > >> history.
> > >> > > > Feel free to propose alternatives. This is not a voting thread.
> > >> > > >
> > >> > > > Regards,
> > >> > > >
> > >> > > > Tiago Bento
> > >> > > >
> > >> > > >
> > >> ---------------------------------------------------------------------
> > >> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > >> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <al...@porcelli.me>.
Francisco,
This was discussed as an alternative solution, however it has major impact
on CI and there’s also the fact Tool has been always the last to build and
has no Snapshot published (actually in JavaScript world there is no
snapshot concept).
So, based on our evaluation… the proposal here is the least disruptive and
will take less time to unblock the release.
Regards,
_____________
Alex Porcelli
http://porcelli.me
On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado Sarti <
ftirados@redhat.com> wrote:
> After kie-tools, sorry. I think we are not embracing the fact that
> kogito-images depend on kie-tools, because we want those images to include
> tools.
>
> On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado Sarti <
> ftirados@redhat.com> wrote:
>
> > Hi Tiago,
> > It can be an alternative solution to move kn-plugin-workflow to
> > kogito-images (so there is not longer dependency from tools to images)
> and
> > then build kogito-images after kogito-tools?
> >
> > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez <
> > egonzalez@apache.org> wrote:
> >
> >> +1 to unblock release
> >>
> >> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <
> pefernan@apache.org>
> >> escribió:
> >>
> >> > I say +1 in order to move forward with the 10.
> >> >
> >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <al...@porcelli.me> wrote:
> >> >
> >> > > +1
> >> > >
> >> > > I spent the last day or so working closely with Tiago, exploring
> >> > different
> >> > > options and getting deeper on the impact and evaluating the overall
> >> > release
> >> > > procedure steps required. I agree with the proposal as the most
> >> > > viable option for unblocking the 10 release in the reasonable time
> >> frame.
> >> > >
> >> > >
> >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <ti...@apache.org>
> >> > wrote:
> >> > >
> >> > > > Hi everyone,
> >> > > >
> >> > > > Unfortunately, I can't do a tl;dr this time, as this matter
> >> requires a
> >> > > > lot of context.
> >> > > >
> >> > > > This email will take you < 20 minutes to read, according to
> >> > > > https://thereadtime.com/.
> >> > > >
> >> > > > As you may have followed on a separate thread
> >> > > > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69
> ),
> >> > > > many of us were working towards removing a circular dependency
> >> > > > currently present between `kogito-apps` and `kie-tools`. As we
> >> > > > progressed towards a solution, we kept finding the circular
> >> dependency
> >> > > > pop up somewhere else. I'll do a breakdown of the things we did,
> and
> >> > > > the results we had.
> >> > > >
> >> > > > Right now, even though we started the effort to move the Quarkus
> Dev
> >> > > > UI modules to `kie-tools`, we haven't been able to do it yet, as
> >> we've
> >> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> >> > > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> >> > > > effort was concluded this Monday, with
> >> > > > https://github.com/apache/incubator-kie-tools/pull/2136.
> >> > > >
> >> > > > The current scenario we have is:
> >> > > >
> >> > > > 01. incubator-kie-kogito-runtimes
> >> > > > |==> 02. incubator-kie-kogito-apps
> >> > > > C | 03. incubator-kie-kogito-examples
> >> > > > Y | 04. incubator-kie-kogito-images
> >> > > > C | 05. incubator-kie-kogito-serverless-operator
> >> > > > L | ==========================
> >> > > > E | 06. incubator-kie-sandbox-quarkus-accelerator
> >> > > > |==> 07. incubator-kie-tools
> >> > > >
> >> > > >
> >> > > > * As `kie-tools`/extended-services depends on
> >> > > > `kogito-apps`/jitexecutor;
> >> > > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend
> >> on
> >> > > > `kie-tools`/{many packages}
> >> > > >
> >> > > >
> >> > > > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> >> > > >
> >> > > > 01. incubator-kie-kogito-runtimes
> >> > > > 02. incubator-kie-kogito-apps
> >> > > > 03. incubator-kie-kogito-examples
> >> > > > C |==> 04. incubator-kie-kogito-images
> >> > > > Y | 05. incubator-kie-kogito-serverless-operator
> >> > > > C | =====================
> >> > > > L | 06. incubator-kie-sandbox-quarkus-accelerator
> >> > > > E |==> 07. incubator-kie-tools
> >> > > >
> >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> >> > > > `kogito-images`/kogito-swf-devmode;
> >> > > > * and `kogito-images`/kogito-swf-devmode depends on
> >> > > > `kie-tools`/sonataflow-quarkus-devui
> >> > > >
> >> > > >
> >> > > > After moving the `kogito-swf-devmode` image to `kie-tools`, we
> >> would've
> >> > > > had:
> >> > > >
> >> > > > 01. incubator-kie-kogito-runtimes
> >> > > > 02. incubator-kie-kogito-apps
> >> > > > 03. incubator-kie-kogito-examples
> >> > > > 04. incubator-kie-kogito-images
> >> > > > C |==> 05. incubator-kie-kogito-serverless-operator
> >> > > > Y | =====================
> >> > > > C | 06. incubator-kie-sandbox-quarkus-accelerator
> >> > > > L |==> 07. incubator-kie-tools
> >> > > > E
> >> > > >
> >> > > > * As `kie-tools`/kn-plugin-workflow depends on
> >> > > > `kogito-serverless-operator`;
> >> > > > * and `kogito-serverless-operator` depends on
> >> > > > `kie-tools`/kogito-swf-devmode
> >> > > >
> >> > > >
> >> > > > Clearly, we have a much bigger problem than a simple circular
> >> > dependency.
> >> > > >
> >> > > > After multiple conversations with a lot of people, it's been
> really
> >> > > > hard coming up with a simple solution that makes it possible to
> >> build
> >> > > > Apache KIE in one shot, while preserving the way everyone is used
> to
> >> > > > contributing to the multiple repositories we have. More than that,
> >> > > > while making this assessment, I found more problems that, in my
> >> > > > perspective, block Apache KIE 10.
> >> > > >
> >> > > > In light of that difficulty, I'm coming forward with my proposal
> for
> >> > > > the Apache KIE release process, so we can use Apache's mechanisms
> to
> >> > > > have a slower-paced, in-depth debate about this really complicated
> >> > > > matter.
> >> > > >
> >> > > > I'll lay out my entire perspective about the current situation of
> >> our
> >> > > > codebase, as well as problems I can currently see. I'll start with
> >> an
> >> > > > analysis of the repositories and their purposes, point out some
> >> > > > problems that I believe are blocking our 10 release, explain my
> >> > > > proposal and discuss some consequences to what I'm proposing.
> >> > > >
> >> > > > Let's begin.
> >> > > >
> >> > > >
> >> > > > # THE APACHE KIE REPOS
> >> > > >
> >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> >> > > > - incubator-kie-kogito-pipelines @ `main`
> >> > > > - incubator-kie-drools @ `main`
> >> > > > - incubator-kie-optaplanner @ `main`
> >> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> >> > > > - incubator-kie-kogito-runtimes @ `main`
> >> > > > - incubator-kie-kogito-apps @ `main`
> >> > > > - incubator-kie-kogito-examples @ `main`
> >> > > > - incubator-kie-kogito-images @ `main`
> >> > > > - incubator-kie-kogito-serverless-operator @ `main`
> >> > > > - incubator-kie-kogito-docs @ `main`
> >> > > > - incubator-kie-docs @ `main-kogito`
> >> > > >
> >> > > > B. TOOLS (count: 2)
> >> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> >> > > > - incubator-kie-tools @ `main`
> >> > > >
> >> > > > C. BENCHMARKS (count: 2)
> >> > > > - incubator-kie-kogito-benchmarks @ `main`
> >> > > > - incubator-kie-benchmarks @ `main`
> >> > > >
> >> > > > D. ARCHIVED (count: 1)
> >> > > > - incubator-kie-kogito-operator
> >> > > >
> >> > > > E. "NON-CODE" (count: 5)
> >> > > > - incubator-kie-issues @ `main`
> >> > > > (Issues only, README should be updated @ `main`. Same for
> GitHub
> >> > > > Actions workflows.)
> >> > > > - incubator-kie-kogito-website @ `main`
> >> > > > (The Kogito website. Develop & deploy at the `main` branch.)
> >> > > > - incubator-kie-website @ `main`
> >> > > > (The KIE website. Develop @ `main`. Push @ `deploy` to update
> >> the
> >> > > > website.)
> >> > > > - incubator-kie-kogito-online @ `gh-pages`
> >> > > > (GitHub pages used to host sandbox.kie.org and KIE Tools'
> >> Chrome
> >> > > > Extension assets.)
> >> > > > - incubator-kie-kogito-online-staging @ `main`
> >> > > > (Same as above, but for manual sanity checks during the
> staging
> >> > > > phase of a release.)
> >> > > >
> >> > > > TOTAL (count: 21)
> >> > > >
> >> > > > I grouped the repositories by category, and listed them in a
> >> > > > topological order. Keep in mind that when flattening out a tree,
> >> there
> >> > > > are multiple possibilities. For example, OptaPlanner could've been
> >> > > > placed in any position after Drools.
> >> > > >
> >> > > > Category A repos are what I've been referring to as `drools` and
> >> > > > `kogito-*` stream. Of course OptaPlanner is inside that stream, as
> >> the
> >> > > > way these repositories reference each other are through Maven
> >> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This
> >> mechanism
> >> > > > is well-known to the team, and although flawed for intra-day
> builds
> >> > > > and disruptive for people in many different time zones, it is
> >> already
> >> > > > very comfortable for everyone to work with, I assume.
> >> > > >
> >> > > > Contributions made to Category A have some dedicated pipelines,
> >> which
> >> > > > are, at least to some extent, able to build cross-repo PRs
> together
> >> > > > and verify that the codebase will continue working as expected
> after
> >> > > > they're all merged. From what I could gather, there are some
> >> > > > "sub-streams" currently configured for cross-repo PRs.
> >> > > >
> >> > > > - kogito-pipelines
> >> > > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> >> > > > - optaplanner, and optaplanner-quickstarts
> >> > > > - kogito-images, and kogito-serverless-operator
> >> > > > - kogito-docs
> >> > > > - kie-docs
> >> > > >
> >> > > > This means that sending cross-repo PRs to any combination of repos
> >> > > > that are not part of the same "sub-stream" cannot be verified
> before
> >> > > > merging, making our contribution model dependent on individual
> >> > > > contributors building stuff on their machines to verify that it
> >> works.
> >> > > >
> >> > > > I based this analysis on
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> >> > > > ,
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> >> > > > ,
> >> > > > and
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> >> > > > .
> >> > > > Note that I'm not that familiar with these pipelines, so please
> >> > > > someone correct me if I'm wrong.
> >> > > >
> >> > > > Category B repos are what I've been referring to as `kie-tools`
> >> > > > stream. The first repo there is a template repository that is used
> >> by
> >> > > > people starting projects from scratch on KIE Sandbox, similar to a
> >> > > > Maven archetype, if you will. The other one is the KIE Tools
> >> monorepo,
> >> > > > a polyglot monorepo with `pnpm` as its build system. Currently,
> KIE
> >> > > > Tools hosts Java libraries and apps, TypeScript libraries and
> apps,
> >> Go
> >> > > > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> >> > > > configured to work with sparse checkouts and can do partial
> builds.
> >> > > > Category B repos refer to Category A repos through timestamped
> >> > > > SNAPSHOTs. This is a new mechanism we recently introduced that
> will
> >> > > > build and publish immutable, persistent artifacts under a version
> >> > > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> >> > > > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> >> > > > releases, as we're now targeting one release for all of Apache
> KIE,
> >> so
> >> > > > we can't have Kogito releases anymore.
> >> > > >
> >> > > > An important note here is that Category B repositories have been
> >> > > > historically kept out of any automations we used to have, way back
> >> > > > when Kogito started and we had the Business Central (a.k.a. v7)
> >> stream
> >> > > > still going on. For this reason, Category B projects have
> developed
> >> > > > their own automations, based on GitHub Actions. Category B repos
> >> have
> >> > > > always depended on Category A repos using fixed versions. If
> >> Category
> >> > > > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> >> > > > Category A repositories would've had the potential to break
> >> Category B
> >> > > > silently, leaving Category B with a broken development stream, and
> >> > > > introducing unpleasant surprises for maintainers of Category B
> >> repos,
> >> > > > as historically Category A contributors were not familiar with
> >> > > > Category B repos.
> >> > > >
> >> > > > Contributions made to Category B repos go through a GitHub Actions
> >> > > > workflow that builds the relevant part of the `kie-tools` monorepo
> >> for
> >> > > > the changes introduced. Changes made to the pipeline itself are
> also
> >> > > > picked up as part of PRs, allowing us to do things like atomically
> >> > > > bumping the Node.js version, for example. More importantly, it
> >> allows
> >> > > > us to upgrade the repository to a new timestamped SNAPSHOT
> together
> >> > > > with the changes necessary to make it stay green.
> >> > > >
> >> > > > This setup, however, makes it impossible to have cross-repo PRs
> >> > > > involving Category A and Category B simultaneously, with the
> current
> >> > > > automations we have.
> >> > > >
> >> > > > Category C repos are kind of floating around, and I'm not sure if
> >> > > > there's much activity going on there. Regardless, as they're part
> of
> >> > > > Apache KIE, they will be part of our release, so I listed them for
> >> us
> >> > > > to take them into consideration too.
> >> > > >
> >> > > > Category D is self explanatory. There's only one repo that has
> >> already
> >> > > > been marked for being archived.
> >> > > >
> >> > > > Category E are repos that do not host code directly, and are
> either
> >> > > > organizational entities, or host websites, that currently are not
> >> part
> >> > > > of any pipelines we have.
> >> > > >
> >> > > > This lack of unification between Category A and Category B is,
> IMHO,
> >> > > > what allowed us to introduce the infamous circular dependency
> >> between
> >> > > > `kie-tools` and `kogito-apps`, which we now can describe as a
> >> circular
> >> > > > dependency between Category A and Category B. The way I see it, if
> >> we
> >> > > > had a single pipeline, building everything from `drools` to
> >> > > > `kie-tools`, such flaws would've never been introduced, and we
> >> > > > wouldn't be having this huge problem in our hands right now.
> >> > > >
> >> > > > My proposal for the Apache KIE release process sees this lack of
> >> > > > unification as a central problem, not only for this release in
> >> > > > particular, but for the community as a whole. It is my belief that
> >> we
> >> > > > are all under the same roof, and that no contribution should be
> >> > > > allowed to break any part of our codebase. With the increasing
> >> volume
> >> > > > of code, and hopefully number of contributors too, we cannot keep
> >> > > > counting on "common sense" to avoid breaking things. We're all
> >> humans
> >> > > > after all, and it is our job to have mechanisms in place to
> prevent
> >> us
> >> > > > from unwillingly making mistakes. Especially when these mistakes
> >> > > > impact on parts of the codebase that we, individually, probably
> >> can't
> >> > > > fix.
> >> > > >
> >> > > >
> >> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> >> > > >
> >> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE
> >> Tools
> >> > > > `0.32.0`.
> >> > > > See:
> >> > > > -
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> >> > > >
> >> > > >
> >> > > > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> >> > > > kiegroup's KIE Tools `0.32.0`.
> >> > > > See:
> >> > > > -
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> >> > > >
> >> > > >
> >> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> >> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> >> > > > See:
> >> > > > -
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> >> > > > -
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> >> > > >
> >> > > >
> >> > > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> >> > > > Explainability `1.22.1.Final`.
> >> > > > * This module was removed from the KIE codebase here:
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> >> > > > and now lives on
> >> > > >
> https://github.com/trustyai-explainability/trustyai-explainability,
> >> > > > under a different GAV.
> >> > > > * This new repo depends on Kogito and OptaPlanner, pointing to
> older
> >> > > > versions.
> >> > > > See:
> >> > > > -
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> >> > > > -
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> >> > > >
> >> > > >
> >> > > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on
> Kogito
> >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> >> > > > See:
> >> > > > -
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> >> > > >
> >> > > >
> >> > > > P6. Category C repos are out of date and not part of the Category
> A
> >> > > > CI/Release pipelines.
> >> > > > * incubator-kie-kogito-benchmarks: (Current version is
> >> `2.0-SNAPSHOT`,
> >> > > > depending on Kogito without a specific version, only by using
> >> > > > `http://localhost:8080`)
> >> > > > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> >> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
> >> > > >
> >> > > >
> >> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled
> >> after
> >> > > > upgrading to 999-20240218-SNAPSHOT.
> >> > > >
> >> > > >
> >> > > > In my perspective, P1 and P2 have the same solution, as they both
> >> > > > suffer from the circular dependency between Category A and
> Category
> >> B.
> >> > > > As Category A and Category B are both streams that have been
> really
> >> > > > active, I see this as a blocker, as there are contributions that
> >> > > > cannot be done, given that Category A depends on Category B with a
> >> > > > dephasing of 1 release.
> >> > > >
> >> > > > P3 and P4, although not ideal, can be understood as technical
> debt.
> >> > > > Depending on unmaintained projects is something we'll always be
> >> > > > susceptible to, given time.
> >> > > >
> >> > > > P5 and P6 are easily fixable, as it's just a matter of making them
> >> > > > part of the play.
> >> > > >
> >> > > > P7 is an isolated problem that won't impact the structure or
> >> anything
> >> > > > that we're talking about here, but it is a regression we
> introduced
> >> > > > recently.
> >> > > >
> >> > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5,
> >> P6,
> >> > > > and P7 have easy fixes, the only problems left to discuss are P1
> and
> >> > > > P2, which can't be done without a proper proposal.
> >> > > >
> >> > > >
> >> > > > # THE PROPOSAL
> >> > > >
> >> > > > I'll try to be very meticulous here, since from my experience, any
> >> > > > little miscalculation can lead to our release not working out in
> the
> >> > > > end. To try and avoid that as much as possible, and make
> everything
> >> we
> >> > > > can to have a successful Apache KIE 10 release, bear with me. I'll
> >> lay
> >> > > > out a timeline of events that need to happen in order for our
> >> release
> >> > > > to be published, with all artifacts ending up in the right places,
> >> but
> >> > > > first, we need to solve problems P1 and P2.
> >> > > >
> >> > > > As you saw at the beginning of this email, all the attempts we
> made
> >> > > > left us with the circular dependency showing up at a different
> >> place,
> >> > > > but something all these places have in common is that they're all
> >> > > > after kogito-apps, and before to Category B.
> >> > > >
> >> > > > The first part of my proposal is the following:
> >> > > >
> >> > > > S1. We keep the original plan of moving the Quarkus Dev UIs from
> >> > > > `kogito-apps` to `kie-tools`, together with Management and Task
> >> > > > consoles from `kogito-images` to `kie-tools`.
> >> > > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder`
> images
> >> > > > from `kogito-images` to `kie-tools` too.
> >> > > > S3. We move the entire `kogito-serverless-operator` repo inside a
> >> new
> >> > > > package on `kie-tools`, keeping Git history.
> >> > > >
> >> > > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of
> >> course
> >> > > > the rest of
> >> https://github.com/apache/incubator-kie-issues/issues/967
> >> > > > would still be done too.
> >> > > >
> >> > > > This doesn't come without consequences, of course, as the
> >> > > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> >> > > > `kogito-serverless-operator` would be moving from Category A to
> >> > > > Category B. This move would make them have to reference Category A
> >> > > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> >> > > > `kogito-serverless-operator` are already their own "sub-stream"
> >> inside
> >> > > > Category A, though, contributions made in a cross-repo fashion to
> >> this
> >> > > > "sub-stream" will continue being possible, now via a single PR to
> >> > > > `kie-tools`. Cross-repo PRs between Category A and Category B will
> >> > > > continue not being possible, and a 1-week delay between merging
> >> > > > something on Category A and using it on Category B will still
> >> happen.
> >> > > >
> >> > > > It's worth mentioning that `kie-tools`, however, does allow for
> >> sparse
> >> > > > checkouts and partial builds, so working with a subset of the
> >> monorepo
> >> > > > is possible and encouraged. Making changes only to
> >> > > > `packages/kn-plugin-workflow`, for example, will have the PR
> checks
> >> > > > run in < 10 minutes, as you can see here:
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> >> > > > .
> >> > > > We're not compromising when running partial builds too. We know
> that
> >> > > > the entire repo will continue working even after only building a
> >> small
> >> > > > subset of the changes. Doing partial or full builds is
> automatically
> >> > > > determined by the changes of a PR.
> >> > > >
> >> > > > Keep in mind that, even though I'm proposing we move a bunch of
> >> > > > additional stuff into `kie-tools`, I see this as a TEMPORARY
> >> solution
> >> > > > for our codebase. `kie-tools` would host some additional stuff
> >> > > > TEMPORARILY so that we can release and continue moving forward.
> >> > > >
> >> > > > As I mentioned on other places, `kie-tools` became a polyglot
> >> monorepo
> >> > > > out of necessity, and although I'm really proud of what we
> achieved
> >> > > > there so far, I don't think `kie-tools` has a setup that is
> suitable
> >> > > > for all the different nuances that compose our community. I'm well
> >> > > > aware that a polyglot monorepo that does not follow widespread
> >> > > > conventions will scare some people away, and as much as we've
> tried
> >> to
> >> > > > make build instructions clear, we can't always get past the
> >> prejudice
> >> > > > some people have towards the "front-end" ecosystem.
> >> > > >
> >> > > > With all that said, I keep thinking this is the best course of
> >> action
> >> > > > for us right now. We keep most of our stuff unchanged, we unblock
> >> the
> >> > > > release, and we have a working setup that will suit us well while
> we
> >> > > > discuss and reach a conclusion regarding the future of our
> codebase
> >> > > > structure.
> >> > > >
> >> > > > Let me paint a quick picture here of what our code base would look
> >> > > > like, repository-wise, if my proposal is accepted:
> >> > > >
> >> > > > CATEGORY REPO
> >> > > > =====================
> >> > > > A incubator-kie-kogito-pipelines
> >> > > > A incubator-kie-drools
> >> > > > A incubator-kie-optaplanner
> >> > > > A incubator-kie-optaplanner-quickstarts
> >> > > > A incubator-kie-kogito-runtimes
> >> > > > A incubator-kie-kogito-apps
> >> > > > A incubator-kie-kogito-examples
> >> > > > A incubator-kie-kogito-images
> >> > > > A incubator-kie-kogito-docs
> >> > > > A incubator-kie-kogito-benchmarks
> >> > > > A incubator-kie-docs
> >> > > > A incubator-kie-benchmarks
> >> > > > =====================
> >> > > > B incubator-kie-sandbox-quarkus-accelerator
> >> > > > B incubator-kie-tools
> >> > > > =====================
> >> > > > D incubator-kie-kogito-operator
> >> > > > =====================
> >> > > > E incubator-kie-issues
> >> > > > E incubator-kie-kogito-website
> >> > > > E incubator-kie-website
> >> > > > E incubator-kie-kogito-online
> >> > > > E incubator-kie-kogito-online-staging
> >> > > > =====================
> >> > > >
> >> > > > * Category C becomes part of Category A, and
> >> > > > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> >> > > > * With `kogito-swf-{builder,devmode}` images and
> >> > > > `kogito-serverless-operator` inside `kie-tools`, there are no
> cycles
> >> > > > anymore, as inside `kie-tools`, we can granularly build:
> >> > > > 1. packages/sonataflow-deployment-webapp
> >> > > > 2. packages/sonataflow-quarkus-devui
> >> > > > 3. packages/sonataflow-images (containing `kogito-swf-builder`
> >> and
> >> > > > `kogito-swf-devmode`)
> >> > > > 4. packages/sonataflow-operator (contents from
> >> > > > `kogito-serverless-operator`)
> >> > > > 5. packages/kn-plugin-sonataflow
> (`packages/kn-plugin-workflow`,
> >> > > > but renamed)
> >> > > >
> >> > > > The second part of the proposal is the release process itself,
> >> > > > assuming the structure above is what we have.
> >> > > >
> >> > > > Here it is:
> >> > > >
> >> > > > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> >> > > > Category A repos.
> >> > > > 2. Update Category B repos to point to this timestamped SNAPSHOT,
> >> and
> >> > > > verify that everything is working.
> >> > > > 3. At this point, with everything working, we can branch out to
> >> > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and
> >> Category B
> >> > > > from `main`.
> >> > > > 4. All Category A and Category B repos update their versions to
> >> > > > 10.0.0, in their `10.0.x` branches.
> >> > > > 5. Update Category B repos to point to Category A repos using the
> >> > > > 10.0.0 version.
> >> > > > 6. At this point, we can vote on the release based on the `10.0.x`
> >> > > > branches, given we don't expect any code changes anymore.
> >> > > > 7. After voting passes, we're good to start the release process.
> >> > > > 8. Category A repos follow their manual/automated release process,
> >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> >> > > > artifacts pushed to their registries.
> >> > > > 9. We wait a little bit for Category A artifacts to be propagated
> on
> >> > > > registries. ~1 day.
> >> > > > 10. Category B repos follow their manual/automated release
> process,
> >> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> >> > > > artifacts pushed to their registries.
> >> > > > 11. Category D repos are ignored.
> >> > > > 12. Category E repos can be manually tagged with 10.0.0 from their
> >> > > > default branches.
> >> > > >
> >> > > > More needs to be discussed if we're planning to maintain multiple
> >> > > > release streams in parallel, but I guess it can wait for after
> >> Apache
> >> > > > KIE 10.
> >> > > >
> >> > > > Thank you for reading, and I'm looking forward to hearing back
> from
> >> > > > everyone.
> >> > > >
> >> > > > Of course, alternative solutions are possible. This email,
> however,
> >> > > > summarizes my view of how we should attack the problem,
> considering
> >> > > > disruption, required effort, the release process itself, and
> >> history.
> >> > > > Feel free to propose alternatives. This is not a voting thread.
> >> > > >
> >> > > > Regards,
> >> > > >
> >> > > > Tiago Bento
> >> > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> >> > > > For additional commands, e-mail: dev-help@kie.apache.org
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
After kie-tools, sorry. I think we are not embracing the fact that
kogito-images depend on kie-tools, because we want those images to include
tools.
On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado Sarti <
ftirados@redhat.com> wrote:
> Hi Tiago,
> It can be an alternative solution to move kn-plugin-workflow to
> kogito-images (so there is not longer dependency from tools to images) and
> then build kogito-images after kogito-tools?
>
> On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez <
> egonzalez@apache.org> wrote:
>
>> +1 to unblock release
>>
>> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <pe...@apache.org>
>> escribió:
>>
>> > I say +1 in order to move forward with the 10.
>> >
>> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <al...@porcelli.me> wrote:
>> >
>> > > +1
>> > >
>> > > I spent the last day or so working closely with Tiago, exploring
>> > different
>> > > options and getting deeper on the impact and evaluating the overall
>> > release
>> > > procedure steps required. I agree with the proposal as the most
>> > > viable option for unblocking the 10 release in the reasonable time
>> frame.
>> > >
>> > >
>> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <ti...@apache.org>
>> > wrote:
>> > >
>> > > > Hi everyone,
>> > > >
>> > > > Unfortunately, I can't do a tl;dr this time, as this matter
>> requires a
>> > > > lot of context.
>> > > >
>> > > > This email will take you < 20 minutes to read, according to
>> > > > https://thereadtime.com/.
>> > > >
>> > > > As you may have followed on a separate thread
>> > > > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
>> > > > many of us were working towards removing a circular dependency
>> > > > currently present between `kogito-apps` and `kie-tools`. As we
>> > > > progressed towards a solution, we kept finding the circular
>> dependency
>> > > > pop up somewhere else. I'll do a breakdown of the things we did, and
>> > > > the results we had.
>> > > >
>> > > > Right now, even though we started the effort to move the Quarkus Dev
>> > > > UI modules to `kie-tools`, we haven't been able to do it yet, as
>> we've
>> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
>> > > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
>> > > > effort was concluded this Monday, with
>> > > > https://github.com/apache/incubator-kie-tools/pull/2136.
>> > > >
>> > > > The current scenario we have is:
>> > > >
>> > > > 01. incubator-kie-kogito-runtimes
>> > > > |==> 02. incubator-kie-kogito-apps
>> > > > C | 03. incubator-kie-kogito-examples
>> > > > Y | 04. incubator-kie-kogito-images
>> > > > C | 05. incubator-kie-kogito-serverless-operator
>> > > > L | ==========================
>> > > > E | 06. incubator-kie-sandbox-quarkus-accelerator
>> > > > |==> 07. incubator-kie-tools
>> > > >
>> > > >
>> > > > * As `kie-tools`/extended-services depends on
>> > > > `kogito-apps`/jitexecutor;
>> > > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend
>> on
>> > > > `kie-tools`/{many packages}
>> > > >
>> > > >
>> > > > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
>> > > >
>> > > > 01. incubator-kie-kogito-runtimes
>> > > > 02. incubator-kie-kogito-apps
>> > > > 03. incubator-kie-kogito-examples
>> > > > C |==> 04. incubator-kie-kogito-images
>> > > > Y | 05. incubator-kie-kogito-serverless-operator
>> > > > C | =====================
>> > > > L | 06. incubator-kie-sandbox-quarkus-accelerator
>> > > > E |==> 07. incubator-kie-tools
>> > > >
>> > > > * As `kie-tools`/kn-plugin-workflow depends on
>> > > > `kogito-images`/kogito-swf-devmode;
>> > > > * and `kogito-images`/kogito-swf-devmode depends on
>> > > > `kie-tools`/sonataflow-quarkus-devui
>> > > >
>> > > >
>> > > > After moving the `kogito-swf-devmode` image to `kie-tools`, we
>> would've
>> > > > had:
>> > > >
>> > > > 01. incubator-kie-kogito-runtimes
>> > > > 02. incubator-kie-kogito-apps
>> > > > 03. incubator-kie-kogito-examples
>> > > > 04. incubator-kie-kogito-images
>> > > > C |==> 05. incubator-kie-kogito-serverless-operator
>> > > > Y | =====================
>> > > > C | 06. incubator-kie-sandbox-quarkus-accelerator
>> > > > L |==> 07. incubator-kie-tools
>> > > > E
>> > > >
>> > > > * As `kie-tools`/kn-plugin-workflow depends on
>> > > > `kogito-serverless-operator`;
>> > > > * and `kogito-serverless-operator` depends on
>> > > > `kie-tools`/kogito-swf-devmode
>> > > >
>> > > >
>> > > > Clearly, we have a much bigger problem than a simple circular
>> > dependency.
>> > > >
>> > > > After multiple conversations with a lot of people, it's been really
>> > > > hard coming up with a simple solution that makes it possible to
>> build
>> > > > Apache KIE in one shot, while preserving the way everyone is used to
>> > > > contributing to the multiple repositories we have. More than that,
>> > > > while making this assessment, I found more problems that, in my
>> > > > perspective, block Apache KIE 10.
>> > > >
>> > > > In light of that difficulty, I'm coming forward with my proposal for
>> > > > the Apache KIE release process, so we can use Apache's mechanisms to
>> > > > have a slower-paced, in-depth debate about this really complicated
>> > > > matter.
>> > > >
>> > > > I'll lay out my entire perspective about the current situation of
>> our
>> > > > codebase, as well as problems I can currently see. I'll start with
>> an
>> > > > analysis of the repositories and their purposes, point out some
>> > > > problems that I believe are blocking our 10 release, explain my
>> > > > proposal and discuss some consequences to what I'm proposing.
>> > > >
>> > > > Let's begin.
>> > > >
>> > > >
>> > > > # THE APACHE KIE REPOS
>> > > >
>> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
>> > > > - incubator-kie-kogito-pipelines @ `main`
>> > > > - incubator-kie-drools @ `main`
>> > > > - incubator-kie-optaplanner @ `main`
>> > > > - incubator-kie-optaplanner-quickstarts @ `main`
>> > > > - incubator-kie-kogito-runtimes @ `main`
>> > > > - incubator-kie-kogito-apps @ `main`
>> > > > - incubator-kie-kogito-examples @ `main`
>> > > > - incubator-kie-kogito-images @ `main`
>> > > > - incubator-kie-kogito-serverless-operator @ `main`
>> > > > - incubator-kie-kogito-docs @ `main`
>> > > > - incubator-kie-docs @ `main-kogito`
>> > > >
>> > > > B. TOOLS (count: 2)
>> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
>> > > > - incubator-kie-tools @ `main`
>> > > >
>> > > > C. BENCHMARKS (count: 2)
>> > > > - incubator-kie-kogito-benchmarks @ `main`
>> > > > - incubator-kie-benchmarks @ `main`
>> > > >
>> > > > D. ARCHIVED (count: 1)
>> > > > - incubator-kie-kogito-operator
>> > > >
>> > > > E. "NON-CODE" (count: 5)
>> > > > - incubator-kie-issues @ `main`
>> > > > (Issues only, README should be updated @ `main`. Same for GitHub
>> > > > Actions workflows.)
>> > > > - incubator-kie-kogito-website @ `main`
>> > > > (The Kogito website. Develop & deploy at the `main` branch.)
>> > > > - incubator-kie-website @ `main`
>> > > > (The KIE website. Develop @ `main`. Push @ `deploy` to update
>> the
>> > > > website.)
>> > > > - incubator-kie-kogito-online @ `gh-pages`
>> > > > (GitHub pages used to host sandbox.kie.org and KIE Tools'
>> Chrome
>> > > > Extension assets.)
>> > > > - incubator-kie-kogito-online-staging @ `main`
>> > > > (Same as above, but for manual sanity checks during the staging
>> > > > phase of a release.)
>> > > >
>> > > > TOTAL (count: 21)
>> > > >
>> > > > I grouped the repositories by category, and listed them in a
>> > > > topological order. Keep in mind that when flattening out a tree,
>> there
>> > > > are multiple possibilities. For example, OptaPlanner could've been
>> > > > placed in any position after Drools.
>> > > >
>> > > > Category A repos are what I've been referring to as `drools` and
>> > > > `kogito-*` stream. Of course OptaPlanner is inside that stream, as
>> the
>> > > > way these repositories reference each other are through Maven
>> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This
>> mechanism
>> > > > is well-known to the team, and although flawed for intra-day builds
>> > > > and disruptive for people in many different time zones, it is
>> already
>> > > > very comfortable for everyone to work with, I assume.
>> > > >
>> > > > Contributions made to Category A have some dedicated pipelines,
>> which
>> > > > are, at least to some extent, able to build cross-repo PRs together
>> > > > and verify that the codebase will continue working as expected after
>> > > > they're all merged. From what I could gather, there are some
>> > > > "sub-streams" currently configured for cross-repo PRs.
>> > > >
>> > > > - kogito-pipelines
>> > > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
>> > > > - optaplanner, and optaplanner-quickstarts
>> > > > - kogito-images, and kogito-serverless-operator
>> > > > - kogito-docs
>> > > > - kie-docs
>> > > >
>> > > > This means that sending cross-repo PRs to any combination of repos
>> > > > that are not part of the same "sub-stream" cannot be verified before
>> > > > merging, making our contribution model dependent on individual
>> > > > contributors building stuff on their machines to verify that it
>> works.
>> > > >
>> > > > I based this analysis on
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
>> > > > ,
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
>> > > > ,
>> > > > and
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
>> > > > .
>> > > > Note that I'm not that familiar with these pipelines, so please
>> > > > someone correct me if I'm wrong.
>> > > >
>> > > > Category B repos are what I've been referring to as `kie-tools`
>> > > > stream. The first repo there is a template repository that is used
>> by
>> > > > people starting projects from scratch on KIE Sandbox, similar to a
>> > > > Maven archetype, if you will. The other one is the KIE Tools
>> monorepo,
>> > > > a polyglot monorepo with `pnpm` as its build system. Currently, KIE
>> > > > Tools hosts Java libraries and apps, TypeScript libraries and apps,
>> Go
>> > > > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
>> > > > configured to work with sparse checkouts and can do partial builds.
>> > > > Category B repos refer to Category A repos through timestamped
>> > > > SNAPSHOTs. This is a new mechanism we recently introduced that will
>> > > > build and publish immutable, persistent artifacts under a version
>> > > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
>> > > > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
>> > > > releases, as we're now targeting one release for all of Apache KIE,
>> so
>> > > > we can't have Kogito releases anymore.
>> > > >
>> > > > An important note here is that Category B repositories have been
>> > > > historically kept out of any automations we used to have, way back
>> > > > when Kogito started and we had the Business Central (a.k.a. v7)
>> stream
>> > > > still going on. For this reason, Category B projects have developed
>> > > > their own automations, based on GitHub Actions. Category B repos
>> have
>> > > > always depended on Category A repos using fixed versions. If
>> Category
>> > > > B repos have had adopted mutable SNAPSHOTs, breaking changes on
>> > > > Category A repositories would've had the potential to break
>> Category B
>> > > > silently, leaving Category B with a broken development stream, and
>> > > > introducing unpleasant surprises for maintainers of Category B
>> repos,
>> > > > as historically Category A contributors were not familiar with
>> > > > Category B repos.
>> > > >
>> > > > Contributions made to Category B repos go through a GitHub Actions
>> > > > workflow that builds the relevant part of the `kie-tools` monorepo
>> for
>> > > > the changes introduced. Changes made to the pipeline itself are also
>> > > > picked up as part of PRs, allowing us to do things like atomically
>> > > > bumping the Node.js version, for example. More importantly, it
>> allows
>> > > > us to upgrade the repository to a new timestamped SNAPSHOT together
>> > > > with the changes necessary to make it stay green.
>> > > >
>> > > > This setup, however, makes it impossible to have cross-repo PRs
>> > > > involving Category A and Category B simultaneously, with the current
>> > > > automations we have.
>> > > >
>> > > > Category C repos are kind of floating around, and I'm not sure if
>> > > > there's much activity going on there. Regardless, as they're part of
>> > > > Apache KIE, they will be part of our release, so I listed them for
>> us
>> > > > to take them into consideration too.
>> > > >
>> > > > Category D is self explanatory. There's only one repo that has
>> already
>> > > > been marked for being archived.
>> > > >
>> > > > Category E are repos that do not host code directly, and are either
>> > > > organizational entities, or host websites, that currently are not
>> part
>> > > > of any pipelines we have.
>> > > >
>> > > > This lack of unification between Category A and Category B is, IMHO,
>> > > > what allowed us to introduce the infamous circular dependency
>> between
>> > > > `kie-tools` and `kogito-apps`, which we now can describe as a
>> circular
>> > > > dependency between Category A and Category B. The way I see it, if
>> we
>> > > > had a single pipeline, building everything from `drools` to
>> > > > `kie-tools`, such flaws would've never been introduced, and we
>> > > > wouldn't be having this huge problem in our hands right now.
>> > > >
>> > > > My proposal for the Apache KIE release process sees this lack of
>> > > > unification as a central problem, not only for this release in
>> > > > particular, but for the community as a whole. It is my belief that
>> we
>> > > > are all under the same roof, and that no contribution should be
>> > > > allowed to break any part of our codebase. With the increasing
>> volume
>> > > > of code, and hopefully number of contributors too, we cannot keep
>> > > > counting on "common sense" to avoid breaking things. We're all
>> humans
>> > > > after all, and it is our job to have mechanisms in place to prevent
>> us
>> > > > from unwillingly making mistakes. Especially when these mistakes
>> > > > impact on parts of the codebase that we, individually, probably
>> can't
>> > > > fix.
>> > > >
>> > > >
>> > > > # THE PROBLEMS WE HAVE RIGHT NOW
>> > > >
>> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE
>> Tools
>> > > > `0.32.0`.
>> > > > See:
>> > > > -
>> > > >
>> > >
>> >
>> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
>> > > >
>> > > >
>> > > > P2. PR open for Kogito SWF images @ `kogito-images` depending on
>> > > > kiegroup's KIE Tools `0.32.0`.
>> > > > See:
>> > > > -
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
>> > > >
>> > > >
>> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
>> > > > `kie-soup` artifacts at version `7.59.0.Final`.
>> > > > See:
>> > > > -
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
>> > > > -
>> > > >
>> > >
>> >
>> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
>> > > >
>> > > >
>> > > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
>> > > > Explainability `1.22.1.Final`.
>> > > > * This module was removed from the KIE codebase here:
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
>> > > > and now lives on
>> > > > https://github.com/trustyai-explainability/trustyai-explainability,
>> > > > under a different GAV.
>> > > > * This new repo depends on Kogito and OptaPlanner, pointing to older
>> > > > versions.
>> > > > See:
>> > > > -
>> > > >
>> > >
>> >
>> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
>> > > > -
>> > > >
>> > >
>> >
>> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
>> > > >
>> > > >
>> > > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
>> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
>> > > > See:
>> > > > -
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
>> > > >
>> > > >
>> > > > P6. Category C repos are out of date and not part of the Category A
>> > > > CI/Release pipelines.
>> > > > * incubator-kie-kogito-benchmarks: (Current version is
>> `2.0-SNAPSHOT`,
>> > > > depending on Kogito without a specific version, only by using
>> > > > `http://localhost:8080`)
>> > > > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
>> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
>> > > >
>> > > >
>> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled
>> after
>> > > > upgrading to 999-20240218-SNAPSHOT.
>> > > >
>> > > >
>> > > > In my perspective, P1 and P2 have the same solution, as they both
>> > > > suffer from the circular dependency between Category A and Category
>> B.
>> > > > As Category A and Category B are both streams that have been really
>> > > > active, I see this as a blocker, as there are contributions that
>> > > > cannot be done, given that Category A depends on Category B with a
>> > > > dephasing of 1 release.
>> > > >
>> > > > P3 and P4, although not ideal, can be understood as technical debt.
>> > > > Depending on unmaintained projects is something we'll always be
>> > > > susceptible to, given time.
>> > > >
>> > > > P5 and P6 are easily fixable, as it's just a matter of making them
>> > > > part of the play.
>> > > >
>> > > > P7 is an isolated problem that won't impact the structure or
>> anything
>> > > > that we're talking about here, but it is a regression we introduced
>> > > > recently.
>> > > >
>> > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5,
>> P6,
>> > > > and P7 have easy fixes, the only problems left to discuss are P1 and
>> > > > P2, which can't be done without a proper proposal.
>> > > >
>> > > >
>> > > > # THE PROPOSAL
>> > > >
>> > > > I'll try to be very meticulous here, since from my experience, any
>> > > > little miscalculation can lead to our release not working out in the
>> > > > end. To try and avoid that as much as possible, and make everything
>> we
>> > > > can to have a successful Apache KIE 10 release, bear with me. I'll
>> lay
>> > > > out a timeline of events that need to happen in order for our
>> release
>> > > > to be published, with all artifacts ending up in the right places,
>> but
>> > > > first, we need to solve problems P1 and P2.
>> > > >
>> > > > As you saw at the beginning of this email, all the attempts we made
>> > > > left us with the circular dependency showing up at a different
>> place,
>> > > > but something all these places have in common is that they're all
>> > > > after kogito-apps, and before to Category B.
>> > > >
>> > > > The first part of my proposal is the following:
>> > > >
>> > > > S1. We keep the original plan of moving the Quarkus Dev UIs from
>> > > > `kogito-apps` to `kie-tools`, together with Management and Task
>> > > > consoles from `kogito-images` to `kie-tools`.
>> > > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
>> > > > from `kogito-images` to `kie-tools` too.
>> > > > S3. We move the entire `kogito-serverless-operator` repo inside a
>> new
>> > > > package on `kie-tools`, keeping Git history.
>> > > >
>> > > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of
>> course
>> > > > the rest of
>> https://github.com/apache/incubator-kie-issues/issues/967
>> > > > would still be done too.
>> > > >
>> > > > This doesn't come without consequences, of course, as the
>> > > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
>> > > > `kogito-serverless-operator` would be moving from Category A to
>> > > > Category B. This move would make them have to reference Category A
>> > > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
>> > > > `kogito-serverless-operator` are already their own "sub-stream"
>> inside
>> > > > Category A, though, contributions made in a cross-repo fashion to
>> this
>> > > > "sub-stream" will continue being possible, now via a single PR to
>> > > > `kie-tools`. Cross-repo PRs between Category A and Category B will
>> > > > continue not being possible, and a 1-week delay between merging
>> > > > something on Category A and using it on Category B will still
>> happen.
>> > > >
>> > > > It's worth mentioning that `kie-tools`, however, does allow for
>> sparse
>> > > > checkouts and partial builds, so working with a subset of the
>> monorepo
>> > > > is possible and encouraged. Making changes only to
>> > > > `packages/kn-plugin-workflow`, for example, will have the PR checks
>> > > > run in < 10 minutes, as you can see here:
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
>> > > > .
>> > > > We're not compromising when running partial builds too. We know that
>> > > > the entire repo will continue working even after only building a
>> small
>> > > > subset of the changes. Doing partial or full builds is automatically
>> > > > determined by the changes of a PR.
>> > > >
>> > > > Keep in mind that, even though I'm proposing we move a bunch of
>> > > > additional stuff into `kie-tools`, I see this as a TEMPORARY
>> solution
>> > > > for our codebase. `kie-tools` would host some additional stuff
>> > > > TEMPORARILY so that we can release and continue moving forward.
>> > > >
>> > > > As I mentioned on other places, `kie-tools` became a polyglot
>> monorepo
>> > > > out of necessity, and although I'm really proud of what we achieved
>> > > > there so far, I don't think `kie-tools` has a setup that is suitable
>> > > > for all the different nuances that compose our community. I'm well
>> > > > aware that a polyglot monorepo that does not follow widespread
>> > > > conventions will scare some people away, and as much as we've tried
>> to
>> > > > make build instructions clear, we can't always get past the
>> prejudice
>> > > > some people have towards the "front-end" ecosystem.
>> > > >
>> > > > With all that said, I keep thinking this is the best course of
>> action
>> > > > for us right now. We keep most of our stuff unchanged, we unblock
>> the
>> > > > release, and we have a working setup that will suit us well while we
>> > > > discuss and reach a conclusion regarding the future of our codebase
>> > > > structure.
>> > > >
>> > > > Let me paint a quick picture here of what our code base would look
>> > > > like, repository-wise, if my proposal is accepted:
>> > > >
>> > > > CATEGORY REPO
>> > > > =====================
>> > > > A incubator-kie-kogito-pipelines
>> > > > A incubator-kie-drools
>> > > > A incubator-kie-optaplanner
>> > > > A incubator-kie-optaplanner-quickstarts
>> > > > A incubator-kie-kogito-runtimes
>> > > > A incubator-kie-kogito-apps
>> > > > A incubator-kie-kogito-examples
>> > > > A incubator-kie-kogito-images
>> > > > A incubator-kie-kogito-docs
>> > > > A incubator-kie-kogito-benchmarks
>> > > > A incubator-kie-docs
>> > > > A incubator-kie-benchmarks
>> > > > =====================
>> > > > B incubator-kie-sandbox-quarkus-accelerator
>> > > > B incubator-kie-tools
>> > > > =====================
>> > > > D incubator-kie-kogito-operator
>> > > > =====================
>> > > > E incubator-kie-issues
>> > > > E incubator-kie-kogito-website
>> > > > E incubator-kie-website
>> > > > E incubator-kie-kogito-online
>> > > > E incubator-kie-kogito-online-staging
>> > > > =====================
>> > > >
>> > > > * Category C becomes part of Category A, and
>> > > > `kogito-serverless-operator` moves entirely inside `kie-tools`.
>> > > > * With `kogito-swf-{builder,devmode}` images and
>> > > > `kogito-serverless-operator` inside `kie-tools`, there are no cycles
>> > > > anymore, as inside `kie-tools`, we can granularly build:
>> > > > 1. packages/sonataflow-deployment-webapp
>> > > > 2. packages/sonataflow-quarkus-devui
>> > > > 3. packages/sonataflow-images (containing `kogito-swf-builder`
>> and
>> > > > `kogito-swf-devmode`)
>> > > > 4. packages/sonataflow-operator (contents from
>> > > > `kogito-serverless-operator`)
>> > > > 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
>> > > > but renamed)
>> > > >
>> > > > The second part of the proposal is the release process itself,
>> > > > assuming the structure above is what we have.
>> > > >
>> > > > Here it is:
>> > > >
>> > > > 1. Define a timestamped SNAPSHOT to be used as cutting point for
>> > > > Category A repos.
>> > > > 2. Update Category B repos to point to this timestamped SNAPSHOT,
>> and
>> > > > verify that everything is working.
>> > > > 3. At this point, with everything working, we can branch out to
>> > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and
>> Category B
>> > > > from `main`.
>> > > > 4. All Category A and Category B repos update their versions to
>> > > > 10.0.0, in their `10.0.x` branches.
>> > > > 5. Update Category B repos to point to Category A repos using the
>> > > > 10.0.0 version.
>> > > > 6. At this point, we can vote on the release based on the `10.0.x`
>> > > > branches, given we don't expect any code changes anymore.
>> > > > 7. After voting passes, we're good to start the release process.
>> > > > 8. Category A repos follow their manual/automated release process,
>> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
>> > > > artifacts pushed to their registries.
>> > > > 9. We wait a little bit for Category A artifacts to be propagated on
>> > > > registries. ~1 day.
>> > > > 10. Category B repos follow their manual/automated release process,
>> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
>> > > > artifacts pushed to their registries.
>> > > > 11. Category D repos are ignored.
>> > > > 12. Category E repos can be manually tagged with 10.0.0 from their
>> > > > default branches.
>> > > >
>> > > > More needs to be discussed if we're planning to maintain multiple
>> > > > release streams in parallel, but I guess it can wait for after
>> Apache
>> > > > KIE 10.
>> > > >
>> > > > Thank you for reading, and I'm looking forward to hearing back from
>> > > > everyone.
>> > > >
>> > > > Of course, alternative solutions are possible. This email, however,
>> > > > summarizes my view of how we should attack the problem, considering
>> > > > disruption, required effort, the release process itself, and
>> history.
>> > > > Feel free to propose alternatives. This is not a voting thread.
>> > > >
>> > > > Regards,
>> > > >
>> > > > Tiago Bento
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
>> > > > For additional commands, e-mail: dev-help@kie.apache.org
>> > > >
>> > > >
>> > >
>> >
>>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Hi Tiago,
It can be an alternative solution to move kn-plugin-workflow to
kogito-images (so there is not longer dependency from tools to images) and
then build kogito-images after kogito-tools?
On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez <
egonzalez@apache.org> wrote:
> +1 to unblock release
>
> El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <pe...@apache.org>
> escribió:
>
> > I say +1 in order to move forward with the 10.
> >
> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > +1
> > >
> > > I spent the last day or so working closely with Tiago, exploring
> > different
> > > options and getting deeper on the impact and evaluating the overall
> > release
> > > procedure steps required. I agree with the proposal as the most
> > > viable option for unblocking the 10 release in the reasonable time
> frame.
> > >
> > >
> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <ti...@apache.org>
> > wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > Unfortunately, I can't do a tl;dr this time, as this matter requires
> a
> > > > lot of context.
> > > >
> > > > This email will take you < 20 minutes to read, according to
> > > > https://thereadtime.com/.
> > > >
> > > > As you may have followed on a separate thread
> > > > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> > > > many of us were working towards removing a circular dependency
> > > > currently present between `kogito-apps` and `kie-tools`. As we
> > > > progressed towards a solution, we kept finding the circular
> dependency
> > > > pop up somewhere else. I'll do a breakdown of the things we did, and
> > > > the results we had.
> > > >
> > > > Right now, even though we started the effort to move the Quarkus Dev
> > > > UI modules to `kie-tools`, we haven't been able to do it yet, as
> we've
> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> > > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> > > > effort was concluded this Monday, with
> > > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > > >
> > > > The current scenario we have is:
> > > >
> > > > 01. incubator-kie-kogito-runtimes
> > > > |==> 02. incubator-kie-kogito-apps
> > > > C | 03. incubator-kie-kogito-examples
> > > > Y | 04. incubator-kie-kogito-images
> > > > C | 05. incubator-kie-kogito-serverless-operator
> > > > L | ==========================
> > > > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > |==> 07. incubator-kie-tools
> > > >
> > > >
> > > > * As `kie-tools`/extended-services depends on
> > > > `kogito-apps`/jitexecutor;
> > > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> > > > `kie-tools`/{many packages}
> > > >
> > > >
> > > > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> > > >
> > > > 01. incubator-kie-kogito-runtimes
> > > > 02. incubator-kie-kogito-apps
> > > > 03. incubator-kie-kogito-examples
> > > > C |==> 04. incubator-kie-kogito-images
> > > > Y | 05. incubator-kie-kogito-serverless-operator
> > > > C | =====================
> > > > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > E |==> 07. incubator-kie-tools
> > > >
> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > `kogito-images`/kogito-swf-devmode;
> > > > * and `kogito-images`/kogito-swf-devmode depends on
> > > > `kie-tools`/sonataflow-quarkus-devui
> > > >
> > > >
> > > > After moving the `kogito-swf-devmode` image to `kie-tools`, we
> would've
> > > > had:
> > > >
> > > > 01. incubator-kie-kogito-runtimes
> > > > 02. incubator-kie-kogito-apps
> > > > 03. incubator-kie-kogito-examples
> > > > 04. incubator-kie-kogito-images
> > > > C |==> 05. incubator-kie-kogito-serverless-operator
> > > > Y | =====================
> > > > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > L |==> 07. incubator-kie-tools
> > > > E
> > > >
> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > `kogito-serverless-operator`;
> > > > * and `kogito-serverless-operator` depends on
> > > > `kie-tools`/kogito-swf-devmode
> > > >
> > > >
> > > > Clearly, we have a much bigger problem than a simple circular
> > dependency.
> > > >
> > > > After multiple conversations with a lot of people, it's been really
> > > > hard coming up with a simple solution that makes it possible to build
> > > > Apache KIE in one shot, while preserving the way everyone is used to
> > > > contributing to the multiple repositories we have. More than that,
> > > > while making this assessment, I found more problems that, in my
> > > > perspective, block Apache KIE 10.
> > > >
> > > > In light of that difficulty, I'm coming forward with my proposal for
> > > > the Apache KIE release process, so we can use Apache's mechanisms to
> > > > have a slower-paced, in-depth debate about this really complicated
> > > > matter.
> > > >
> > > > I'll lay out my entire perspective about the current situation of our
> > > > codebase, as well as problems I can currently see. I'll start with an
> > > > analysis of the repositories and their purposes, point out some
> > > > problems that I believe are blocking our 10 release, explain my
> > > > proposal and discuss some consequences to what I'm proposing.
> > > >
> > > > Let's begin.
> > > >
> > > >
> > > > # THE APACHE KIE REPOS
> > > >
> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > - incubator-kie-drools @ `main`
> > > > - incubator-kie-optaplanner @ `main`
> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > - incubator-kie-kogito-apps @ `main`
> > > > - incubator-kie-kogito-examples @ `main`
> > > > - incubator-kie-kogito-images @ `main`
> > > > - incubator-kie-kogito-serverless-operator @ `main`
> > > > - incubator-kie-kogito-docs @ `main`
> > > > - incubator-kie-docs @ `main-kogito`
> > > >
> > > > B. TOOLS (count: 2)
> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > > - incubator-kie-tools @ `main`
> > > >
> > > > C. BENCHMARKS (count: 2)
> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > - incubator-kie-benchmarks @ `main`
> > > >
> > > > D. ARCHIVED (count: 1)
> > > > - incubator-kie-kogito-operator
> > > >
> > > > E. "NON-CODE" (count: 5)
> > > > - incubator-kie-issues @ `main`
> > > > (Issues only, README should be updated @ `main`. Same for GitHub
> > > > Actions workflows.)
> > > > - incubator-kie-kogito-website @ `main`
> > > > (The Kogito website. Develop & deploy at the `main` branch.)
> > > > - incubator-kie-website @ `main`
> > > > (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> > > > website.)
> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> > > > Extension assets.)
> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > (Same as above, but for manual sanity checks during the staging
> > > > phase of a release.)
> > > >
> > > > TOTAL (count: 21)
> > > >
> > > > I grouped the repositories by category, and listed them in a
> > > > topological order. Keep in mind that when flattening out a tree,
> there
> > > > are multiple possibilities. For example, OptaPlanner could've been
> > > > placed in any position after Drools.
> > > >
> > > > Category A repos are what I've been referring to as `drools` and
> > > > `kogito-*` stream. Of course OptaPlanner is inside that stream, as
> the
> > > > way these repositories reference each other are through Maven
> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This
> mechanism
> > > > is well-known to the team, and although flawed for intra-day builds
> > > > and disruptive for people in many different time zones, it is already
> > > > very comfortable for everyone to work with, I assume.
> > > >
> > > > Contributions made to Category A have some dedicated pipelines, which
> > > > are, at least to some extent, able to build cross-repo PRs together
> > > > and verify that the codebase will continue working as expected after
> > > > they're all merged. From what I could gather, there are some
> > > > "sub-streams" currently configured for cross-repo PRs.
> > > >
> > > > - kogito-pipelines
> > > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > > > - optaplanner, and optaplanner-quickstarts
> > > > - kogito-images, and kogito-serverless-operator
> > > > - kogito-docs
> > > > - kie-docs
> > > >
> > > > This means that sending cross-repo PRs to any combination of repos
> > > > that are not part of the same "sub-stream" cannot be verified before
> > > > merging, making our contribution model dependent on individual
> > > > contributors building stuff on their machines to verify that it
> works.
> > > >
> > > > I based this analysis on
> > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > ,
> > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > ,
> > > > and
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > .
> > > > Note that I'm not that familiar with these pipelines, so please
> > > > someone correct me if I'm wrong.
> > > >
> > > > Category B repos are what I've been referring to as `kie-tools`
> > > > stream. The first repo there is a template repository that is used by
> > > > people starting projects from scratch on KIE Sandbox, similar to a
> > > > Maven archetype, if you will. The other one is the KIE Tools
> monorepo,
> > > > a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> > > > Tools hosts Java libraries and apps, TypeScript libraries and apps,
> Go
> > > > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> > > > configured to work with sparse checkouts and can do partial builds.
> > > > Category B repos refer to Category A repos through timestamped
> > > > SNAPSHOTs. This is a new mechanism we recently introduced that will
> > > > build and publish immutable, persistent artifacts under a version
> > > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> > > > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> > > > releases, as we're now targeting one release for all of Apache KIE,
> so
> > > > we can't have Kogito releases anymore.
> > > >
> > > > An important note here is that Category B repositories have been
> > > > historically kept out of any automations we used to have, way back
> > > > when Kogito started and we had the Business Central (a.k.a. v7)
> stream
> > > > still going on. For this reason, Category B projects have developed
> > > > their own automations, based on GitHub Actions. Category B repos have
> > > > always depended on Category A repos using fixed versions. If Category
> > > > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > > > Category A repositories would've had the potential to break Category
> B
> > > > silently, leaving Category B with a broken development stream, and
> > > > introducing unpleasant surprises for maintainers of Category B repos,
> > > > as historically Category A contributors were not familiar with
> > > > Category B repos.
> > > >
> > > > Contributions made to Category B repos go through a GitHub Actions
> > > > workflow that builds the relevant part of the `kie-tools` monorepo
> for
> > > > the changes introduced. Changes made to the pipeline itself are also
> > > > picked up as part of PRs, allowing us to do things like atomically
> > > > bumping the Node.js version, for example. More importantly, it allows
> > > > us to upgrade the repository to a new timestamped SNAPSHOT together
> > > > with the changes necessary to make it stay green.
> > > >
> > > > This setup, however, makes it impossible to have cross-repo PRs
> > > > involving Category A and Category B simultaneously, with the current
> > > > automations we have.
> > > >
> > > > Category C repos are kind of floating around, and I'm not sure if
> > > > there's much activity going on there. Regardless, as they're part of
> > > > Apache KIE, they will be part of our release, so I listed them for us
> > > > to take them into consideration too.
> > > >
> > > > Category D is self explanatory. There's only one repo that has
> already
> > > > been marked for being archived.
> > > >
> > > > Category E are repos that do not host code directly, and are either
> > > > organizational entities, or host websites, that currently are not
> part
> > > > of any pipelines we have.
> > > >
> > > > This lack of unification between Category A and Category B is, IMHO,
> > > > what allowed us to introduce the infamous circular dependency between
> > > > `kie-tools` and `kogito-apps`, which we now can describe as a
> circular
> > > > dependency between Category A and Category B. The way I see it, if we
> > > > had a single pipeline, building everything from `drools` to
> > > > `kie-tools`, such flaws would've never been introduced, and we
> > > > wouldn't be having this huge problem in our hands right now.
> > > >
> > > > My proposal for the Apache KIE release process sees this lack of
> > > > unification as a central problem, not only for this release in
> > > > particular, but for the community as a whole. It is my belief that we
> > > > are all under the same roof, and that no contribution should be
> > > > allowed to break any part of our codebase. With the increasing volume
> > > > of code, and hopefully number of contributors too, we cannot keep
> > > > counting on "common sense" to avoid breaking things. We're all humans
> > > > after all, and it is our job to have mechanisms in place to prevent
> us
> > > > from unwillingly making mistakes. Especially when these mistakes
> > > > impact on parts of the codebase that we, individually, probably can't
> > > > fix.
> > > >
> > > >
> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > >
> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> > > > `0.32.0`.
> > > > See:
> > > > -
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > >
> > > >
> > > > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > > > kiegroup's KIE Tools `0.32.0`.
> > > > See:
> > > > -
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > >
> > > >
> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > See:
> > > > -
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > -
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > >
> > > >
> > > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > > > Explainability `1.22.1.Final`.
> > > > * This module was removed from the KIE codebase here:
> > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > and now lives on
> > > > https://github.com/trustyai-explainability/trustyai-explainability,
> > > > under a different GAV.
> > > > * This new repo depends on Kogito and OptaPlanner, pointing to older
> > > > versions.
> > > > See:
> > > > -
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > -
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > >
> > > >
> > > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > See:
> > > > -
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > >
> > > >
> > > > P6. Category C repos are out of date and not part of the Category A
> > > > CI/Release pipelines.
> > > > * incubator-kie-kogito-benchmarks: (Current version is
> `2.0-SNAPSHOT`,
> > > > depending on Kogito without a specific version, only by using
> > > > `http://localhost:8080`)
> > > > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
> > > >
> > > >
> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled
> after
> > > > upgrading to 999-20240218-SNAPSHOT.
> > > >
> > > >
> > > > In my perspective, P1 and P2 have the same solution, as they both
> > > > suffer from the circular dependency between Category A and Category
> B.
> > > > As Category A and Category B are both streams that have been really
> > > > active, I see this as a blocker, as there are contributions that
> > > > cannot be done, given that Category A depends on Category B with a
> > > > dephasing of 1 release.
> > > >
> > > > P3 and P4, although not ideal, can be understood as technical debt.
> > > > Depending on unmaintained projects is something we'll always be
> > > > susceptible to, given time.
> > > >
> > > > P5 and P6 are easily fixable, as it's just a matter of making them
> > > > part of the play.
> > > >
> > > > P7 is an isolated problem that won't impact the structure or anything
> > > > that we're talking about here, but it is a regression we introduced
> > > > recently.
> > > >
> > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> > > > and P7 have easy fixes, the only problems left to discuss are P1 and
> > > > P2, which can't be done without a proper proposal.
> > > >
> > > >
> > > > # THE PROPOSAL
> > > >
> > > > I'll try to be very meticulous here, since from my experience, any
> > > > little miscalculation can lead to our release not working out in the
> > > > end. To try and avoid that as much as possible, and make everything
> we
> > > > can to have a successful Apache KIE 10 release, bear with me. I'll
> lay
> > > > out a timeline of events that need to happen in order for our release
> > > > to be published, with all artifacts ending up in the right places,
> but
> > > > first, we need to solve problems P1 and P2.
> > > >
> > > > As you saw at the beginning of this email, all the attempts we made
> > > > left us with the circular dependency showing up at a different place,
> > > > but something all these places have in common is that they're all
> > > > after kogito-apps, and before to Category B.
> > > >
> > > > The first part of my proposal is the following:
> > > >
> > > > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > > > `kogito-apps` to `kie-tools`, together with Management and Task
> > > > consoles from `kogito-images` to `kie-tools`.
> > > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> > > > from `kogito-images` to `kie-tools` too.
> > > > S3. We move the entire `kogito-serverless-operator` repo inside a new
> > > > package on `kie-tools`, keeping Git history.
> > > >
> > > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> > > > the rest of
> https://github.com/apache/incubator-kie-issues/issues/967
> > > > would still be done too.
> > > >
> > > > This doesn't come without consequences, of course, as the
> > > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > > > `kogito-serverless-operator` would be moving from Category A to
> > > > Category B. This move would make them have to reference Category A
> > > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > > > `kogito-serverless-operator` are already their own "sub-stream"
> inside
> > > > Category A, though, contributions made in a cross-repo fashion to
> this
> > > > "sub-stream" will continue being possible, now via a single PR to
> > > > `kie-tools`. Cross-repo PRs between Category A and Category B will
> > > > continue not being possible, and a 1-week delay between merging
> > > > something on Category A and using it on Category B will still happen.
> > > >
> > > > It's worth mentioning that `kie-tools`, however, does allow for
> sparse
> > > > checkouts and partial builds, so working with a subset of the
> monorepo
> > > > is possible and encouraged. Making changes only to
> > > > `packages/kn-plugin-workflow`, for example, will have the PR checks
> > > > run in < 10 minutes, as you can see here:
> > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > .
> > > > We're not compromising when running partial builds too. We know that
> > > > the entire repo will continue working even after only building a
> small
> > > > subset of the changes. Doing partial or full builds is automatically
> > > > determined by the changes of a PR.
> > > >
> > > > Keep in mind that, even though I'm proposing we move a bunch of
> > > > additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> > > > for our codebase. `kie-tools` would host some additional stuff
> > > > TEMPORARILY so that we can release and continue moving forward.
> > > >
> > > > As I mentioned on other places, `kie-tools` became a polyglot
> monorepo
> > > > out of necessity, and although I'm really proud of what we achieved
> > > > there so far, I don't think `kie-tools` has a setup that is suitable
> > > > for all the different nuances that compose our community. I'm well
> > > > aware that a polyglot monorepo that does not follow widespread
> > > > conventions will scare some people away, and as much as we've tried
> to
> > > > make build instructions clear, we can't always get past the prejudice
> > > > some people have towards the "front-end" ecosystem.
> > > >
> > > > With all that said, I keep thinking this is the best course of action
> > > > for us right now. We keep most of our stuff unchanged, we unblock the
> > > > release, and we have a working setup that will suit us well while we
> > > > discuss and reach a conclusion regarding the future of our codebase
> > > > structure.
> > > >
> > > > Let me paint a quick picture here of what our code base would look
> > > > like, repository-wise, if my proposal is accepted:
> > > >
> > > > CATEGORY REPO
> > > > =====================
> > > > A incubator-kie-kogito-pipelines
> > > > A incubator-kie-drools
> > > > A incubator-kie-optaplanner
> > > > A incubator-kie-optaplanner-quickstarts
> > > > A incubator-kie-kogito-runtimes
> > > > A incubator-kie-kogito-apps
> > > > A incubator-kie-kogito-examples
> > > > A incubator-kie-kogito-images
> > > > A incubator-kie-kogito-docs
> > > > A incubator-kie-kogito-benchmarks
> > > > A incubator-kie-docs
> > > > A incubator-kie-benchmarks
> > > > =====================
> > > > B incubator-kie-sandbox-quarkus-accelerator
> > > > B incubator-kie-tools
> > > > =====================
> > > > D incubator-kie-kogito-operator
> > > > =====================
> > > > E incubator-kie-issues
> > > > E incubator-kie-kogito-website
> > > > E incubator-kie-website
> > > > E incubator-kie-kogito-online
> > > > E incubator-kie-kogito-online-staging
> > > > =====================
> > > >
> > > > * Category C becomes part of Category A, and
> > > > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> > > > anymore, as inside `kie-tools`, we can granularly build:
> > > > 1. packages/sonataflow-deployment-webapp
> > > > 2. packages/sonataflow-quarkus-devui
> > > > 3. packages/sonataflow-images (containing `kogito-swf-builder`
> and
> > > > `kogito-swf-devmode`)
> > > > 4. packages/sonataflow-operator (contents from
> > > > `kogito-serverless-operator`)
> > > > 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> > > > but renamed)
> > > >
> > > > The second part of the proposal is the release process itself,
> > > > assuming the structure above is what we have.
> > > >
> > > > Here it is:
> > > >
> > > > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > > > Category A repos.
> > > > 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> > > > verify that everything is working.
> > > > 3. At this point, with everything working, we can branch out to
> > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category
> B
> > > > from `main`.
> > > > 4. All Category A and Category B repos update their versions to
> > > > 10.0.0, in their `10.0.x` branches.
> > > > 5. Update Category B repos to point to Category A repos using the
> > > > 10.0.0 version.
> > > > 6. At this point, we can vote on the release based on the `10.0.x`
> > > > branches, given we don't expect any code changes anymore.
> > > > 7. After voting passes, we're good to start the release process.
> > > > 8. Category A repos follow their manual/automated release process,
> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > > artifacts pushed to their registries.
> > > > 9. We wait a little bit for Category A artifacts to be propagated on
> > > > registries. ~1 day.
> > > > 10. Category B repos follow their manual/automated release process,
> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > > artifacts pushed to their registries.
> > > > 11. Category D repos are ignored.
> > > > 12. Category E repos can be manually tagged with 10.0.0 from their
> > > > default branches.
> > > >
> > > > More needs to be discussed if we're planning to maintain multiple
> > > > release streams in parallel, but I guess it can wait for after Apache
> > > > KIE 10.
> > > >
> > > > Thank you for reading, and I'm looking forward to hearing back from
> > > > everyone.
> > > >
> > > > Of course, alternative solutions are possible. This email, however,
> > > > summarizes my view of how we should attack the problem, considering
> > > > disruption, required effort, the release process itself, and history.
> > > > Feel free to propose alternatives. This is not a voting thread.
> > > >
> > > > Regards,
> > > >
> > > > Tiago Bento
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Enrique Gonzalez Martinez <eg...@apache.org>.
+1 to unblock release
El mié, 13 mar 2024, 10:48, Pere Fernandez (apache) <pe...@apache.org>
escribió:
> I say +1 in order to move forward with the 10.
>
> On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <al...@porcelli.me> wrote:
>
> > +1
> >
> > I spent the last day or so working closely with Tiago, exploring
> different
> > options and getting deeper on the impact and evaluating the overall
> release
> > procedure steps required. I agree with the proposal as the most
> > viable option for unblocking the 10 release in the reasonable time frame.
> >
> >
> > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <ti...@apache.org>
> wrote:
> >
> > > Hi everyone,
> > >
> > > Unfortunately, I can't do a tl;dr this time, as this matter requires a
> > > lot of context.
> > >
> > > This email will take you < 20 minutes to read, according to
> > > https://thereadtime.com/.
> > >
> > > As you may have followed on a separate thread
> > > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> > > many of us were working towards removing a circular dependency
> > > currently present between `kogito-apps` and `kie-tools`. As we
> > > progressed towards a solution, we kept finding the circular dependency
> > > pop up somewhere else. I'll do a breakdown of the things we did, and
> > > the results we had.
> > >
> > > Right now, even though we started the effort to move the Quarkus Dev
> > > UI modules to `kie-tools`, we haven't been able to do it yet, as we've
> > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> > > effort was concluded this Monday, with
> > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > >
> > > The current scenario we have is:
> > >
> > > 01. incubator-kie-kogito-runtimes
> > > |==> 02. incubator-kie-kogito-apps
> > > C | 03. incubator-kie-kogito-examples
> > > Y | 04. incubator-kie-kogito-images
> > > C | 05. incubator-kie-kogito-serverless-operator
> > > L | ==========================
> > > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > > |==> 07. incubator-kie-tools
> > >
> > >
> > > * As `kie-tools`/extended-services depends on
> > > `kogito-apps`/jitexecutor;
> > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> > > `kie-tools`/{many packages}
> > >
> > >
> > > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> > >
> > > 01. incubator-kie-kogito-runtimes
> > > 02. incubator-kie-kogito-apps
> > > 03. incubator-kie-kogito-examples
> > > C |==> 04. incubator-kie-kogito-images
> > > Y | 05. incubator-kie-kogito-serverless-operator
> > > C | =====================
> > > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > > E |==> 07. incubator-kie-tools
> > >
> > > * As `kie-tools`/kn-plugin-workflow depends on
> > > `kogito-images`/kogito-swf-devmode;
> > > * and `kogito-images`/kogito-swf-devmode depends on
> > > `kie-tools`/sonataflow-quarkus-devui
> > >
> > >
> > > After moving the `kogito-swf-devmode` image to `kie-tools`, we would've
> > > had:
> > >
> > > 01. incubator-kie-kogito-runtimes
> > > 02. incubator-kie-kogito-apps
> > > 03. incubator-kie-kogito-examples
> > > 04. incubator-kie-kogito-images
> > > C |==> 05. incubator-kie-kogito-serverless-operator
> > > Y | =====================
> > > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > > L |==> 07. incubator-kie-tools
> > > E
> > >
> > > * As `kie-tools`/kn-plugin-workflow depends on
> > > `kogito-serverless-operator`;
> > > * and `kogito-serverless-operator` depends on
> > > `kie-tools`/kogito-swf-devmode
> > >
> > >
> > > Clearly, we have a much bigger problem than a simple circular
> dependency.
> > >
> > > After multiple conversations with a lot of people, it's been really
> > > hard coming up with a simple solution that makes it possible to build
> > > Apache KIE in one shot, while preserving the way everyone is used to
> > > contributing to the multiple repositories we have. More than that,
> > > while making this assessment, I found more problems that, in my
> > > perspective, block Apache KIE 10.
> > >
> > > In light of that difficulty, I'm coming forward with my proposal for
> > > the Apache KIE release process, so we can use Apache's mechanisms to
> > > have a slower-paced, in-depth debate about this really complicated
> > > matter.
> > >
> > > I'll lay out my entire perspective about the current situation of our
> > > codebase, as well as problems I can currently see. I'll start with an
> > > analysis of the repositories and their purposes, point out some
> > > problems that I believe are blocking our 10 release, explain my
> > > proposal and discuss some consequences to what I'm proposing.
> > >
> > > Let's begin.
> > >
> > >
> > > # THE APACHE KIE REPOS
> > >
> > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > - incubator-kie-kogito-pipelines @ `main`
> > > - incubator-kie-drools @ `main`
> > > - incubator-kie-optaplanner @ `main`
> > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > - incubator-kie-kogito-runtimes @ `main`
> > > - incubator-kie-kogito-apps @ `main`
> > > - incubator-kie-kogito-examples @ `main`
> > > - incubator-kie-kogito-images @ `main`
> > > - incubator-kie-kogito-serverless-operator @ `main`
> > > - incubator-kie-kogito-docs @ `main`
> > > - incubator-kie-docs @ `main-kogito`
> > >
> > > B. TOOLS (count: 2)
> > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > - incubator-kie-tools @ `main`
> > >
> > > C. BENCHMARKS (count: 2)
> > > - incubator-kie-kogito-benchmarks @ `main`
> > > - incubator-kie-benchmarks @ `main`
> > >
> > > D. ARCHIVED (count: 1)
> > > - incubator-kie-kogito-operator
> > >
> > > E. "NON-CODE" (count: 5)
> > > - incubator-kie-issues @ `main`
> > > (Issues only, README should be updated @ `main`. Same for GitHub
> > > Actions workflows.)
> > > - incubator-kie-kogito-website @ `main`
> > > (The Kogito website. Develop & deploy at the `main` branch.)
> > > - incubator-kie-website @ `main`
> > > (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> > > website.)
> > > - incubator-kie-kogito-online @ `gh-pages`
> > > (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> > > Extension assets.)
> > > - incubator-kie-kogito-online-staging @ `main`
> > > (Same as above, but for manual sanity checks during the staging
> > > phase of a release.)
> > >
> > > TOTAL (count: 21)
> > >
> > > I grouped the repositories by category, and listed them in a
> > > topological order. Keep in mind that when flattening out a tree, there
> > > are multiple possibilities. For example, OptaPlanner could've been
> > > placed in any position after Drools.
> > >
> > > Category A repos are what I've been referring to as `drools` and
> > > `kogito-*` stream. Of course OptaPlanner is inside that stream, as the
> > > way these repositories reference each other are through Maven
> > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This mechanism
> > > is well-known to the team, and although flawed for intra-day builds
> > > and disruptive for people in many different time zones, it is already
> > > very comfortable for everyone to work with, I assume.
> > >
> > > Contributions made to Category A have some dedicated pipelines, which
> > > are, at least to some extent, able to build cross-repo PRs together
> > > and verify that the codebase will continue working as expected after
> > > they're all merged. From what I could gather, there are some
> > > "sub-streams" currently configured for cross-repo PRs.
> > >
> > > - kogito-pipelines
> > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > > - optaplanner, and optaplanner-quickstarts
> > > - kogito-images, and kogito-serverless-operator
> > > - kogito-docs
> > > - kie-docs
> > >
> > > This means that sending cross-repo PRs to any combination of repos
> > > that are not part of the same "sub-stream" cannot be verified before
> > > merging, making our contribution model dependent on individual
> > > contributors building stuff on their machines to verify that it works.
> > >
> > > I based this analysis on
> > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > ,
> > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > ,
> > > and
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > .
> > > Note that I'm not that familiar with these pipelines, so please
> > > someone correct me if I'm wrong.
> > >
> > > Category B repos are what I've been referring to as `kie-tools`
> > > stream. The first repo there is a template repository that is used by
> > > people starting projects from scratch on KIE Sandbox, similar to a
> > > Maven archetype, if you will. The other one is the KIE Tools monorepo,
> > > a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> > > Tools hosts Java libraries and apps, TypeScript libraries and apps, Go
> > > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> > > configured to work with sparse checkouts and can do partial builds.
> > > Category B repos refer to Category A repos through timestamped
> > > SNAPSHOTs. This is a new mechanism we recently introduced that will
> > > build and publish immutable, persistent artifacts under a version
> > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> > > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> > > releases, as we're now targeting one release for all of Apache KIE, so
> > > we can't have Kogito releases anymore.
> > >
> > > An important note here is that Category B repositories have been
> > > historically kept out of any automations we used to have, way back
> > > when Kogito started and we had the Business Central (a.k.a. v7) stream
> > > still going on. For this reason, Category B projects have developed
> > > their own automations, based on GitHub Actions. Category B repos have
> > > always depended on Category A repos using fixed versions. If Category
> > > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > > Category A repositories would've had the potential to break Category B
> > > silently, leaving Category B with a broken development stream, and
> > > introducing unpleasant surprises for maintainers of Category B repos,
> > > as historically Category A contributors were not familiar with
> > > Category B repos.
> > >
> > > Contributions made to Category B repos go through a GitHub Actions
> > > workflow that builds the relevant part of the `kie-tools` monorepo for
> > > the changes introduced. Changes made to the pipeline itself are also
> > > picked up as part of PRs, allowing us to do things like atomically
> > > bumping the Node.js version, for example. More importantly, it allows
> > > us to upgrade the repository to a new timestamped SNAPSHOT together
> > > with the changes necessary to make it stay green.
> > >
> > > This setup, however, makes it impossible to have cross-repo PRs
> > > involving Category A and Category B simultaneously, with the current
> > > automations we have.
> > >
> > > Category C repos are kind of floating around, and I'm not sure if
> > > there's much activity going on there. Regardless, as they're part of
> > > Apache KIE, they will be part of our release, so I listed them for us
> > > to take them into consideration too.
> > >
> > > Category D is self explanatory. There's only one repo that has already
> > > been marked for being archived.
> > >
> > > Category E are repos that do not host code directly, and are either
> > > organizational entities, or host websites, that currently are not part
> > > of any pipelines we have.
> > >
> > > This lack of unification between Category A and Category B is, IMHO,
> > > what allowed us to introduce the infamous circular dependency between
> > > `kie-tools` and `kogito-apps`, which we now can describe as a circular
> > > dependency between Category A and Category B. The way I see it, if we
> > > had a single pipeline, building everything from `drools` to
> > > `kie-tools`, such flaws would've never been introduced, and we
> > > wouldn't be having this huge problem in our hands right now.
> > >
> > > My proposal for the Apache KIE release process sees this lack of
> > > unification as a central problem, not only for this release in
> > > particular, but for the community as a whole. It is my belief that we
> > > are all under the same roof, and that no contribution should be
> > > allowed to break any part of our codebase. With the increasing volume
> > > of code, and hopefully number of contributors too, we cannot keep
> > > counting on "common sense" to avoid breaking things. We're all humans
> > > after all, and it is our job to have mechanisms in place to prevent us
> > > from unwillingly making mistakes. Especially when these mistakes
> > > impact on parts of the codebase that we, individually, probably can't
> > > fix.
> > >
> > >
> > > # THE PROBLEMS WE HAVE RIGHT NOW
> > >
> > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> > > `0.32.0`.
> > > See:
> > > -
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > >
> > >
> > > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > > kiegroup's KIE Tools `0.32.0`.
> > > See:
> > > -
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > >
> > >
> > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > See:
> > > -
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > -
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > >
> > >
> > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > > Explainability `1.22.1.Final`.
> > > * This module was removed from the KIE codebase here:
> > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > and now lives on
> > > https://github.com/trustyai-explainability/trustyai-explainability,
> > > under a different GAV.
> > > * This new repo depends on Kogito and OptaPlanner, pointing to older
> > > versions.
> > > See:
> > > -
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > -
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > >
> > >
> > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > See:
> > > -
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > >
> > >
> > > P6. Category C repos are out of date and not part of the Category A
> > > CI/Release pipelines.
> > > * incubator-kie-kogito-benchmarks: (Current version is `2.0-SNAPSHOT`,
> > > depending on Kogito without a specific version, only by using
> > > `http://localhost:8080`)
> > > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
> > >
> > >
> > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled after
> > > upgrading to 999-20240218-SNAPSHOT.
> > >
> > >
> > > In my perspective, P1 and P2 have the same solution, as they both
> > > suffer from the circular dependency between Category A and Category B.
> > > As Category A and Category B are both streams that have been really
> > > active, I see this as a blocker, as there are contributions that
> > > cannot be done, given that Category A depends on Category B with a
> > > dephasing of 1 release.
> > >
> > > P3 and P4, although not ideal, can be understood as technical debt.
> > > Depending on unmaintained projects is something we'll always be
> > > susceptible to, given time.
> > >
> > > P5 and P6 are easily fixable, as it's just a matter of making them
> > > part of the play.
> > >
> > > P7 is an isolated problem that won't impact the structure or anything
> > > that we're talking about here, but it is a regression we introduced
> > > recently.
> > >
> > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> > > and P7 have easy fixes, the only problems left to discuss are P1 and
> > > P2, which can't be done without a proper proposal.
> > >
> > >
> > > # THE PROPOSAL
> > >
> > > I'll try to be very meticulous here, since from my experience, any
> > > little miscalculation can lead to our release not working out in the
> > > end. To try and avoid that as much as possible, and make everything we
> > > can to have a successful Apache KIE 10 release, bear with me. I'll lay
> > > out a timeline of events that need to happen in order for our release
> > > to be published, with all artifacts ending up in the right places, but
> > > first, we need to solve problems P1 and P2.
> > >
> > > As you saw at the beginning of this email, all the attempts we made
> > > left us with the circular dependency showing up at a different place,
> > > but something all these places have in common is that they're all
> > > after kogito-apps, and before to Category B.
> > >
> > > The first part of my proposal is the following:
> > >
> > > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > > `kogito-apps` to `kie-tools`, together with Management and Task
> > > consoles from `kogito-images` to `kie-tools`.
> > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> > > from `kogito-images` to `kie-tools` too.
> > > S3. We move the entire `kogito-serverless-operator` repo inside a new
> > > package on `kie-tools`, keeping Git history.
> > >
> > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> > > the rest of https://github.com/apache/incubator-kie-issues/issues/967
> > > would still be done too.
> > >
> > > This doesn't come without consequences, of course, as the
> > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > > `kogito-serverless-operator` would be moving from Category A to
> > > Category B. This move would make them have to reference Category A
> > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > > `kogito-serverless-operator` are already their own "sub-stream" inside
> > > Category A, though, contributions made in a cross-repo fashion to this
> > > "sub-stream" will continue being possible, now via a single PR to
> > > `kie-tools`. Cross-repo PRs between Category A and Category B will
> > > continue not being possible, and a 1-week delay between merging
> > > something on Category A and using it on Category B will still happen.
> > >
> > > It's worth mentioning that `kie-tools`, however, does allow for sparse
> > > checkouts and partial builds, so working with a subset of the monorepo
> > > is possible and encouraged. Making changes only to
> > > `packages/kn-plugin-workflow`, for example, will have the PR checks
> > > run in < 10 minutes, as you can see here:
> > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > .
> > > We're not compromising when running partial builds too. We know that
> > > the entire repo will continue working even after only building a small
> > > subset of the changes. Doing partial or full builds is automatically
> > > determined by the changes of a PR.
> > >
> > > Keep in mind that, even though I'm proposing we move a bunch of
> > > additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> > > for our codebase. `kie-tools` would host some additional stuff
> > > TEMPORARILY so that we can release and continue moving forward.
> > >
> > > As I mentioned on other places, `kie-tools` became a polyglot monorepo
> > > out of necessity, and although I'm really proud of what we achieved
> > > there so far, I don't think `kie-tools` has a setup that is suitable
> > > for all the different nuances that compose our community. I'm well
> > > aware that a polyglot monorepo that does not follow widespread
> > > conventions will scare some people away, and as much as we've tried to
> > > make build instructions clear, we can't always get past the prejudice
> > > some people have towards the "front-end" ecosystem.
> > >
> > > With all that said, I keep thinking this is the best course of action
> > > for us right now. We keep most of our stuff unchanged, we unblock the
> > > release, and we have a working setup that will suit us well while we
> > > discuss and reach a conclusion regarding the future of our codebase
> > > structure.
> > >
> > > Let me paint a quick picture here of what our code base would look
> > > like, repository-wise, if my proposal is accepted:
> > >
> > > CATEGORY REPO
> > > =====================
> > > A incubator-kie-kogito-pipelines
> > > A incubator-kie-drools
> > > A incubator-kie-optaplanner
> > > A incubator-kie-optaplanner-quickstarts
> > > A incubator-kie-kogito-runtimes
> > > A incubator-kie-kogito-apps
> > > A incubator-kie-kogito-examples
> > > A incubator-kie-kogito-images
> > > A incubator-kie-kogito-docs
> > > A incubator-kie-kogito-benchmarks
> > > A incubator-kie-docs
> > > A incubator-kie-benchmarks
> > > =====================
> > > B incubator-kie-sandbox-quarkus-accelerator
> > > B incubator-kie-tools
> > > =====================
> > > D incubator-kie-kogito-operator
> > > =====================
> > > E incubator-kie-issues
> > > E incubator-kie-kogito-website
> > > E incubator-kie-website
> > > E incubator-kie-kogito-online
> > > E incubator-kie-kogito-online-staging
> > > =====================
> > >
> > > * Category C becomes part of Category A, and
> > > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > > * With `kogito-swf-{builder,devmode}` images and
> > > `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> > > anymore, as inside `kie-tools`, we can granularly build:
> > > 1. packages/sonataflow-deployment-webapp
> > > 2. packages/sonataflow-quarkus-devui
> > > 3. packages/sonataflow-images (containing `kogito-swf-builder` and
> > > `kogito-swf-devmode`)
> > > 4. packages/sonataflow-operator (contents from
> > > `kogito-serverless-operator`)
> > > 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> > > but renamed)
> > >
> > > The second part of the proposal is the release process itself,
> > > assuming the structure above is what we have.
> > >
> > > Here it is:
> > >
> > > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > > Category A repos.
> > > 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> > > verify that everything is working.
> > > 3. At this point, with everything working, we can branch out to
> > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
> > > from `main`.
> > > 4. All Category A and Category B repos update their versions to
> > > 10.0.0, in their `10.0.x` branches.
> > > 5. Update Category B repos to point to Category A repos using the
> > > 10.0.0 version.
> > > 6. At this point, we can vote on the release based on the `10.0.x`
> > > branches, given we don't expect any code changes anymore.
> > > 7. After voting passes, we're good to start the release process.
> > > 8. Category A repos follow their manual/automated release process,
> > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > artifacts pushed to their registries.
> > > 9. We wait a little bit for Category A artifacts to be propagated on
> > > registries. ~1 day.
> > > 10. Category B repos follow their manual/automated release process,
> > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > artifacts pushed to their registries.
> > > 11. Category D repos are ignored.
> > > 12. Category E repos can be manually tagged with 10.0.0 from their
> > > default branches.
> > >
> > > More needs to be discussed if we're planning to maintain multiple
> > > release streams in parallel, but I guess it can wait for after Apache
> > > KIE 10.
> > >
> > > Thank you for reading, and I'm looking forward to hearing back from
> > > everyone.
> > >
> > > Of course, alternative solutions are possible. This email, however,
> > > summarizes my view of how we should attack the problem, considering
> > > disruption, required effort, the release process itself, and history.
> > > Feel free to propose alternatives. This is not a voting thread.
> > >
> > > Regards,
> > >
> > > Tiago Bento
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by "Pere Fernandez (apache)" <pe...@apache.org>.
I say +1 in order to move forward with the 10.
On Tue, 12 Mar 2024 at 21:45, Alex Porcelli <al...@porcelli.me> wrote:
> +1
>
> I spent the last day or so working closely with Tiago, exploring different
> options and getting deeper on the impact and evaluating the overall release
> procedure steps required. I agree with the proposal as the most
> viable option for unblocking the 10 release in the reasonable time frame.
>
>
> On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <ti...@apache.org> wrote:
>
> > Hi everyone,
> >
> > Unfortunately, I can't do a tl;dr this time, as this matter requires a
> > lot of context.
> >
> > This email will take you < 20 minutes to read, according to
> > https://thereadtime.com/.
> >
> > As you may have followed on a separate thread
> > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> > many of us were working towards removing a circular dependency
> > currently present between `kogito-apps` and `kie-tools`. As we
> > progressed towards a solution, we kept finding the circular dependency
> > pop up somewhere else. I'll do a breakdown of the things we did, and
> > the results we had.
> >
> > Right now, even though we started the effort to move the Quarkus Dev
> > UI modules to `kie-tools`, we haven't been able to do it yet, as we've
> > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> > effort was concluded this Monday, with
> > https://github.com/apache/incubator-kie-tools/pull/2136.
> >
> > The current scenario we have is:
> >
> > 01. incubator-kie-kogito-runtimes
> > |==> 02. incubator-kie-kogito-apps
> > C | 03. incubator-kie-kogito-examples
> > Y | 04. incubator-kie-kogito-images
> > C | 05. incubator-kie-kogito-serverless-operator
> > L | ==========================
> > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > |==> 07. incubator-kie-tools
> >
> >
> > * As `kie-tools`/extended-services depends on
> > `kogito-apps`/jitexecutor;
> > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> > `kie-tools`/{many packages}
> >
> >
> > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> >
> > 01. incubator-kie-kogito-runtimes
> > 02. incubator-kie-kogito-apps
> > 03. incubator-kie-kogito-examples
> > C |==> 04. incubator-kie-kogito-images
> > Y | 05. incubator-kie-kogito-serverless-operator
> > C | =====================
> > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > E |==> 07. incubator-kie-tools
> >
> > * As `kie-tools`/kn-plugin-workflow depends on
> > `kogito-images`/kogito-swf-devmode;
> > * and `kogito-images`/kogito-swf-devmode depends on
> > `kie-tools`/sonataflow-quarkus-devui
> >
> >
> > After moving the `kogito-swf-devmode` image to `kie-tools`, we would've
> > had:
> >
> > 01. incubator-kie-kogito-runtimes
> > 02. incubator-kie-kogito-apps
> > 03. incubator-kie-kogito-examples
> > 04. incubator-kie-kogito-images
> > C |==> 05. incubator-kie-kogito-serverless-operator
> > Y | =====================
> > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > L |==> 07. incubator-kie-tools
> > E
> >
> > * As `kie-tools`/kn-plugin-workflow depends on
> > `kogito-serverless-operator`;
> > * and `kogito-serverless-operator` depends on
> > `kie-tools`/kogito-swf-devmode
> >
> >
> > Clearly, we have a much bigger problem than a simple circular dependency.
> >
> > After multiple conversations with a lot of people, it's been really
> > hard coming up with a simple solution that makes it possible to build
> > Apache KIE in one shot, while preserving the way everyone is used to
> > contributing to the multiple repositories we have. More than that,
> > while making this assessment, I found more problems that, in my
> > perspective, block Apache KIE 10.
> >
> > In light of that difficulty, I'm coming forward with my proposal for
> > the Apache KIE release process, so we can use Apache's mechanisms to
> > have a slower-paced, in-depth debate about this really complicated
> > matter.
> >
> > I'll lay out my entire perspective about the current situation of our
> > codebase, as well as problems I can currently see. I'll start with an
> > analysis of the repositories and their purposes, point out some
> > problems that I believe are blocking our 10 release, explain my
> > proposal and discuss some consequences to what I'm proposing.
> >
> > Let's begin.
> >
> >
> > # THE APACHE KIE REPOS
> >
> > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > - incubator-kie-kogito-pipelines @ `main`
> > - incubator-kie-drools @ `main`
> > - incubator-kie-optaplanner @ `main`
> > - incubator-kie-optaplanner-quickstarts @ `main`
> > - incubator-kie-kogito-runtimes @ `main`
> > - incubator-kie-kogito-apps @ `main`
> > - incubator-kie-kogito-examples @ `main`
> > - incubator-kie-kogito-images @ `main`
> > - incubator-kie-kogito-serverless-operator @ `main`
> > - incubator-kie-kogito-docs @ `main`
> > - incubator-kie-docs @ `main-kogito`
> >
> > B. TOOLS (count: 2)
> > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > - incubator-kie-tools @ `main`
> >
> > C. BENCHMARKS (count: 2)
> > - incubator-kie-kogito-benchmarks @ `main`
> > - incubator-kie-benchmarks @ `main`
> >
> > D. ARCHIVED (count: 1)
> > - incubator-kie-kogito-operator
> >
> > E. "NON-CODE" (count: 5)
> > - incubator-kie-issues @ `main`
> > (Issues only, README should be updated @ `main`. Same for GitHub
> > Actions workflows.)
> > - incubator-kie-kogito-website @ `main`
> > (The Kogito website. Develop & deploy at the `main` branch.)
> > - incubator-kie-website @ `main`
> > (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> > website.)
> > - incubator-kie-kogito-online @ `gh-pages`
> > (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> > Extension assets.)
> > - incubator-kie-kogito-online-staging @ `main`
> > (Same as above, but for manual sanity checks during the staging
> > phase of a release.)
> >
> > TOTAL (count: 21)
> >
> > I grouped the repositories by category, and listed them in a
> > topological order. Keep in mind that when flattening out a tree, there
> > are multiple possibilities. For example, OptaPlanner could've been
> > placed in any position after Drools.
> >
> > Category A repos are what I've been referring to as `drools` and
> > `kogito-*` stream. Of course OptaPlanner is inside that stream, as the
> > way these repositories reference each other are through Maven
> > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This mechanism
> > is well-known to the team, and although flawed for intra-day builds
> > and disruptive for people in many different time zones, it is already
> > very comfortable for everyone to work with, I assume.
> >
> > Contributions made to Category A have some dedicated pipelines, which
> > are, at least to some extent, able to build cross-repo PRs together
> > and verify that the codebase will continue working as expected after
> > they're all merged. From what I could gather, there are some
> > "sub-streams" currently configured for cross-repo PRs.
> >
> > - kogito-pipelines
> > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > - optaplanner, and optaplanner-quickstarts
> > - kogito-images, and kogito-serverless-operator
> > - kogito-docs
> > - kie-docs
> >
> > This means that sending cross-repo PRs to any combination of repos
> > that are not part of the same "sub-stream" cannot be verified before
> > merging, making our contribution model dependent on individual
> > contributors building stuff on their machines to verify that it works.
> >
> > I based this analysis on
> >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > ,
> >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > ,
> > and
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > .
> > Note that I'm not that familiar with these pipelines, so please
> > someone correct me if I'm wrong.
> >
> > Category B repos are what I've been referring to as `kie-tools`
> > stream. The first repo there is a template repository that is used by
> > people starting projects from scratch on KIE Sandbox, similar to a
> > Maven archetype, if you will. The other one is the KIE Tools monorepo,
> > a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> > Tools hosts Java libraries and apps, TypeScript libraries and apps, Go
> > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> > configured to work with sparse checkouts and can do partial builds.
> > Category B repos refer to Category A repos through timestamped
> > SNAPSHOTs. This is a new mechanism we recently introduced that will
> > build and publish immutable, persistent artifacts under a version
> > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> > releases, as we're now targeting one release for all of Apache KIE, so
> > we can't have Kogito releases anymore.
> >
> > An important note here is that Category B repositories have been
> > historically kept out of any automations we used to have, way back
> > when Kogito started and we had the Business Central (a.k.a. v7) stream
> > still going on. For this reason, Category B projects have developed
> > their own automations, based on GitHub Actions. Category B repos have
> > always depended on Category A repos using fixed versions. If Category
> > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > Category A repositories would've had the potential to break Category B
> > silently, leaving Category B with a broken development stream, and
> > introducing unpleasant surprises for maintainers of Category B repos,
> > as historically Category A contributors were not familiar with
> > Category B repos.
> >
> > Contributions made to Category B repos go through a GitHub Actions
> > workflow that builds the relevant part of the `kie-tools` monorepo for
> > the changes introduced. Changes made to the pipeline itself are also
> > picked up as part of PRs, allowing us to do things like atomically
> > bumping the Node.js version, for example. More importantly, it allows
> > us to upgrade the repository to a new timestamped SNAPSHOT together
> > with the changes necessary to make it stay green.
> >
> > This setup, however, makes it impossible to have cross-repo PRs
> > involving Category A and Category B simultaneously, with the current
> > automations we have.
> >
> > Category C repos are kind of floating around, and I'm not sure if
> > there's much activity going on there. Regardless, as they're part of
> > Apache KIE, they will be part of our release, so I listed them for us
> > to take them into consideration too.
> >
> > Category D is self explanatory. There's only one repo that has already
> > been marked for being archived.
> >
> > Category E are repos that do not host code directly, and are either
> > organizational entities, or host websites, that currently are not part
> > of any pipelines we have.
> >
> > This lack of unification between Category A and Category B is, IMHO,
> > what allowed us to introduce the infamous circular dependency between
> > `kie-tools` and `kogito-apps`, which we now can describe as a circular
> > dependency between Category A and Category B. The way I see it, if we
> > had a single pipeline, building everything from `drools` to
> > `kie-tools`, such flaws would've never been introduced, and we
> > wouldn't be having this huge problem in our hands right now.
> >
> > My proposal for the Apache KIE release process sees this lack of
> > unification as a central problem, not only for this release in
> > particular, but for the community as a whole. It is my belief that we
> > are all under the same roof, and that no contribution should be
> > allowed to break any part of our codebase. With the increasing volume
> > of code, and hopefully number of contributors too, we cannot keep
> > counting on "common sense" to avoid breaking things. We're all humans
> > after all, and it is our job to have mechanisms in place to prevent us
> > from unwillingly making mistakes. Especially when these mistakes
> > impact on parts of the codebase that we, individually, probably can't
> > fix.
> >
> >
> > # THE PROBLEMS WE HAVE RIGHT NOW
> >
> > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> > `0.32.0`.
> > See:
> > -
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> >
> >
> > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > kiegroup's KIE Tools `0.32.0`.
> > See:
> > -
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> >
> >
> > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> > `kie-soup` artifacts at version `7.59.0.Final`.
> > See:
> > -
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > -
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> >
> >
> > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > Explainability `1.22.1.Final`.
> > * This module was removed from the KIE codebase here:
> >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > and now lives on
> > https://github.com/trustyai-explainability/trustyai-explainability,
> > under a different GAV.
> > * This new repo depends on Kogito and OptaPlanner, pointing to older
> > versions.
> > See:
> > -
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > -
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> >
> >
> > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > See:
> > -
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> >
> >
> > P6. Category C repos are out of date and not part of the Category A
> > CI/Release pipelines.
> > * incubator-kie-kogito-benchmarks: (Current version is `2.0-SNAPSHOT`,
> > depending on Kogito without a specific version, only by using
> > `http://localhost:8080`)
> > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
> >
> >
> > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled after
> > upgrading to 999-20240218-SNAPSHOT.
> >
> >
> > In my perspective, P1 and P2 have the same solution, as they both
> > suffer from the circular dependency between Category A and Category B.
> > As Category A and Category B are both streams that have been really
> > active, I see this as a blocker, as there are contributions that
> > cannot be done, given that Category A depends on Category B with a
> > dephasing of 1 release.
> >
> > P3 and P4, although not ideal, can be understood as technical debt.
> > Depending on unmaintained projects is something we'll always be
> > susceptible to, given time.
> >
> > P5 and P6 are easily fixable, as it's just a matter of making them
> > part of the play.
> >
> > P7 is an isolated problem that won't impact the structure or anything
> > that we're talking about here, but it is a regression we introduced
> > recently.
> >
> > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> > and P7 have easy fixes, the only problems left to discuss are P1 and
> > P2, which can't be done without a proper proposal.
> >
> >
> > # THE PROPOSAL
> >
> > I'll try to be very meticulous here, since from my experience, any
> > little miscalculation can lead to our release not working out in the
> > end. To try and avoid that as much as possible, and make everything we
> > can to have a successful Apache KIE 10 release, bear with me. I'll lay
> > out a timeline of events that need to happen in order for our release
> > to be published, with all artifacts ending up in the right places, but
> > first, we need to solve problems P1 and P2.
> >
> > As you saw at the beginning of this email, all the attempts we made
> > left us with the circular dependency showing up at a different place,
> > but something all these places have in common is that they're all
> > after kogito-apps, and before to Category B.
> >
> > The first part of my proposal is the following:
> >
> > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > `kogito-apps` to `kie-tools`, together with Management and Task
> > consoles from `kogito-images` to `kie-tools`.
> > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> > from `kogito-images` to `kie-tools` too.
> > S3. We move the entire `kogito-serverless-operator` repo inside a new
> > package on `kie-tools`, keeping Git history.
> >
> > Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> > the rest of https://github.com/apache/incubator-kie-issues/issues/967
> > would still be done too.
> >
> > This doesn't come without consequences, of course, as the
> > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > `kogito-serverless-operator` would be moving from Category A to
> > Category B. This move would make them have to reference Category A
> > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > `kogito-serverless-operator` are already their own "sub-stream" inside
> > Category A, though, contributions made in a cross-repo fashion to this
> > "sub-stream" will continue being possible, now via a single PR to
> > `kie-tools`. Cross-repo PRs between Category A and Category B will
> > continue not being possible, and a 1-week delay between merging
> > something on Category A and using it on Category B will still happen.
> >
> > It's worth mentioning that `kie-tools`, however, does allow for sparse
> > checkouts and partial builds, so working with a subset of the monorepo
> > is possible and encouraged. Making changes only to
> > `packages/kn-plugin-workflow`, for example, will have the PR checks
> > run in < 10 minutes, as you can see here:
> >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > .
> > We're not compromising when running partial builds too. We know that
> > the entire repo will continue working even after only building a small
> > subset of the changes. Doing partial or full builds is automatically
> > determined by the changes of a PR.
> >
> > Keep in mind that, even though I'm proposing we move a bunch of
> > additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> > for our codebase. `kie-tools` would host some additional stuff
> > TEMPORARILY so that we can release and continue moving forward.
> >
> > As I mentioned on other places, `kie-tools` became a polyglot monorepo
> > out of necessity, and although I'm really proud of what we achieved
> > there so far, I don't think `kie-tools` has a setup that is suitable
> > for all the different nuances that compose our community. I'm well
> > aware that a polyglot monorepo that does not follow widespread
> > conventions will scare some people away, and as much as we've tried to
> > make build instructions clear, we can't always get past the prejudice
> > some people have towards the "front-end" ecosystem.
> >
> > With all that said, I keep thinking this is the best course of action
> > for us right now. We keep most of our stuff unchanged, we unblock the
> > release, and we have a working setup that will suit us well while we
> > discuss and reach a conclusion regarding the future of our codebase
> > structure.
> >
> > Let me paint a quick picture here of what our code base would look
> > like, repository-wise, if my proposal is accepted:
> >
> > CATEGORY REPO
> > =====================
> > A incubator-kie-kogito-pipelines
> > A incubator-kie-drools
> > A incubator-kie-optaplanner
> > A incubator-kie-optaplanner-quickstarts
> > A incubator-kie-kogito-runtimes
> > A incubator-kie-kogito-apps
> > A incubator-kie-kogito-examples
> > A incubator-kie-kogito-images
> > A incubator-kie-kogito-docs
> > A incubator-kie-kogito-benchmarks
> > A incubator-kie-docs
> > A incubator-kie-benchmarks
> > =====================
> > B incubator-kie-sandbox-quarkus-accelerator
> > B incubator-kie-tools
> > =====================
> > D incubator-kie-kogito-operator
> > =====================
> > E incubator-kie-issues
> > E incubator-kie-kogito-website
> > E incubator-kie-website
> > E incubator-kie-kogito-online
> > E incubator-kie-kogito-online-staging
> > =====================
> >
> > * Category C becomes part of Category A, and
> > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > * With `kogito-swf-{builder,devmode}` images and
> > `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> > anymore, as inside `kie-tools`, we can granularly build:
> > 1. packages/sonataflow-deployment-webapp
> > 2. packages/sonataflow-quarkus-devui
> > 3. packages/sonataflow-images (containing `kogito-swf-builder` and
> > `kogito-swf-devmode`)
> > 4. packages/sonataflow-operator (contents from
> > `kogito-serverless-operator`)
> > 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> > but renamed)
> >
> > The second part of the proposal is the release process itself,
> > assuming the structure above is what we have.
> >
> > Here it is:
> >
> > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > Category A repos.
> > 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> > verify that everything is working.
> > 3. At this point, with everything working, we can branch out to
> > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
> > from `main`.
> > 4. All Category A and Category B repos update their versions to
> > 10.0.0, in their `10.0.x` branches.
> > 5. Update Category B repos to point to Category A repos using the
> > 10.0.0 version.
> > 6. At this point, we can vote on the release based on the `10.0.x`
> > branches, given we don't expect any code changes anymore.
> > 7. After voting passes, we're good to start the release process.
> > 8. Category A repos follow their manual/automated release process,
> > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > artifacts pushed to their registries.
> > 9. We wait a little bit for Category A artifacts to be propagated on
> > registries. ~1 day.
> > 10. Category B repos follow their manual/automated release process,
> > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > artifacts pushed to their registries.
> > 11. Category D repos are ignored.
> > 12. Category E repos can be manually tagged with 10.0.0 from their
> > default branches.
> >
> > More needs to be discussed if we're planning to maintain multiple
> > release streams in parallel, but I guess it can wait for after Apache
> > KIE 10.
> >
> > Thank you for reading, and I'm looking forward to hearing back from
> > everyone.
> >
> > Of course, alternative solutions are possible. This email, however,
> > summarizes my view of how we should attack the problem, considering
> > disruption, required effort, the release process itself, and history.
> > Feel free to propose alternatives. This is not a voting thread.
> >
> > Regards,
> >
> > Tiago Bento
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <al...@porcelli.me>.
+1
I spent the last day or so working closely with Tiago, exploring different
options and getting deeper on the impact and evaluating the overall release
procedure steps required. I agree with the proposal as the most
viable option for unblocking the 10 release in the reasonable time frame.
On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento <ti...@apache.org> wrote:
> Hi everyone,
>
> Unfortunately, I can't do a tl;dr this time, as this matter requires a
> lot of context.
>
> This email will take you < 20 minutes to read, according to
> https://thereadtime.com/.
>
> As you may have followed on a separate thread
> (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> many of us were working towards removing a circular dependency
> currently present between `kogito-apps` and `kie-tools`. As we
> progressed towards a solution, we kept finding the circular dependency
> pop up somewhere else. I'll do a breakdown of the things we did, and
> the results we had.
>
> Right now, even though we started the effort to move the Quarkus Dev
> UI modules to `kie-tools`, we haven't been able to do it yet, as we've
> been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> effort was concluded this Monday, with
> https://github.com/apache/incubator-kie-tools/pull/2136.
>
> The current scenario we have is:
>
> 01. incubator-kie-kogito-runtimes
> |==> 02. incubator-kie-kogito-apps
> C | 03. incubator-kie-kogito-examples
> Y | 04. incubator-kie-kogito-images
> C | 05. incubator-kie-kogito-serverless-operator
> L | ==========================
> E | 06. incubator-kie-sandbox-quarkus-accelerator
> |==> 07. incubator-kie-tools
>
>
> * As `kie-tools`/extended-services depends on
> `kogito-apps`/jitexecutor;
> * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> `kie-tools`/{many packages}
>
>
> After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
>
> 01. incubator-kie-kogito-runtimes
> 02. incubator-kie-kogito-apps
> 03. incubator-kie-kogito-examples
> C |==> 04. incubator-kie-kogito-images
> Y | 05. incubator-kie-kogito-serverless-operator
> C | =====================
> L | 06. incubator-kie-sandbox-quarkus-accelerator
> E |==> 07. incubator-kie-tools
>
> * As `kie-tools`/kn-plugin-workflow depends on
> `kogito-images`/kogito-swf-devmode;
> * and `kogito-images`/kogito-swf-devmode depends on
> `kie-tools`/sonataflow-quarkus-devui
>
>
> After moving the `kogito-swf-devmode` image to `kie-tools`, we would've
> had:
>
> 01. incubator-kie-kogito-runtimes
> 02. incubator-kie-kogito-apps
> 03. incubator-kie-kogito-examples
> 04. incubator-kie-kogito-images
> C |==> 05. incubator-kie-kogito-serverless-operator
> Y | =====================
> C | 06. incubator-kie-sandbox-quarkus-accelerator
> L |==> 07. incubator-kie-tools
> E
>
> * As `kie-tools`/kn-plugin-workflow depends on
> `kogito-serverless-operator`;
> * and `kogito-serverless-operator` depends on
> `kie-tools`/kogito-swf-devmode
>
>
> Clearly, we have a much bigger problem than a simple circular dependency.
>
> After multiple conversations with a lot of people, it's been really
> hard coming up with a simple solution that makes it possible to build
> Apache KIE in one shot, while preserving the way everyone is used to
> contributing to the multiple repositories we have. More than that,
> while making this assessment, I found more problems that, in my
> perspective, block Apache KIE 10.
>
> In light of that difficulty, I'm coming forward with my proposal for
> the Apache KIE release process, so we can use Apache's mechanisms to
> have a slower-paced, in-depth debate about this really complicated
> matter.
>
> I'll lay out my entire perspective about the current situation of our
> codebase, as well as problems I can currently see. I'll start with an
> analysis of the repositories and their purposes, point out some
> problems that I believe are blocking our 10 release, explain my
> proposal and discuss some consequences to what I'm proposing.
>
> Let's begin.
>
>
> # THE APACHE KIE REPOS
>
> A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> - incubator-kie-kogito-pipelines @ `main`
> - incubator-kie-drools @ `main`
> - incubator-kie-optaplanner @ `main`
> - incubator-kie-optaplanner-quickstarts @ `main`
> - incubator-kie-kogito-runtimes @ `main`
> - incubator-kie-kogito-apps @ `main`
> - incubator-kie-kogito-examples @ `main`
> - incubator-kie-kogito-images @ `main`
> - incubator-kie-kogito-serverless-operator @ `main`
> - incubator-kie-kogito-docs @ `main`
> - incubator-kie-docs @ `main-kogito`
>
> B. TOOLS (count: 2)
> - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> - incubator-kie-tools @ `main`
>
> C. BENCHMARKS (count: 2)
> - incubator-kie-kogito-benchmarks @ `main`
> - incubator-kie-benchmarks @ `main`
>
> D. ARCHIVED (count: 1)
> - incubator-kie-kogito-operator
>
> E. "NON-CODE" (count: 5)
> - incubator-kie-issues @ `main`
> (Issues only, README should be updated @ `main`. Same for GitHub
> Actions workflows.)
> - incubator-kie-kogito-website @ `main`
> (The Kogito website. Develop & deploy at the `main` branch.)
> - incubator-kie-website @ `main`
> (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> website.)
> - incubator-kie-kogito-online @ `gh-pages`
> (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> Extension assets.)
> - incubator-kie-kogito-online-staging @ `main`
> (Same as above, but for manual sanity checks during the staging
> phase of a release.)
>
> TOTAL (count: 21)
>
> I grouped the repositories by category, and listed them in a
> topological order. Keep in mind that when flattening out a tree, there
> are multiple possibilities. For example, OptaPlanner could've been
> placed in any position after Drools.
>
> Category A repos are what I've been referring to as `drools` and
> `kogito-*` stream. Of course OptaPlanner is inside that stream, as the
> way these repositories reference each other are through Maven
> SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This mechanism
> is well-known to the team, and although flawed for intra-day builds
> and disruptive for people in many different time zones, it is already
> very comfortable for everyone to work with, I assume.
>
> Contributions made to Category A have some dedicated pipelines, which
> are, at least to some extent, able to build cross-repo PRs together
> and verify that the codebase will continue working as expected after
> they're all merged. From what I could gather, there are some
> "sub-streams" currently configured for cross-repo PRs.
>
> - kogito-pipelines
> - drools, kogito-runtimes, kogito-apps, and kogito-examples
> - optaplanner, and optaplanner-quickstarts
> - kogito-images, and kogito-serverless-operator
> - kogito-docs
> - kie-docs
>
> This means that sending cross-repo PRs to any combination of repos
> that are not part of the same "sub-stream" cannot be verified before
> merging, making our contribution model dependent on individual
> contributors building stuff on their machines to verify that it works.
>
> I based this analysis on
>
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> ,
>
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> ,
> and
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> .
> Note that I'm not that familiar with these pipelines, so please
> someone correct me if I'm wrong.
>
> Category B repos are what I've been referring to as `kie-tools`
> stream. The first repo there is a template repository that is used by
> people starting projects from scratch on KIE Sandbox, similar to a
> Maven archetype, if you will. The other one is the KIE Tools monorepo,
> a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> Tools hosts Java libraries and apps, TypeScript libraries and apps, Go
> apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> configured to work with sparse checkouts and can do partial builds.
> Category B repos refer to Category A repos through timestamped
> SNAPSHOTs. This is a new mechanism we recently introduced that will
> build and publish immutable, persistent artifacts under a version
> following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> releases, as we're now targeting one release for all of Apache KIE, so
> we can't have Kogito releases anymore.
>
> An important note here is that Category B repositories have been
> historically kept out of any automations we used to have, way back
> when Kogito started and we had the Business Central (a.k.a. v7) stream
> still going on. For this reason, Category B projects have developed
> their own automations, based on GitHub Actions. Category B repos have
> always depended on Category A repos using fixed versions. If Category
> B repos have had adopted mutable SNAPSHOTs, breaking changes on
> Category A repositories would've had the potential to break Category B
> silently, leaving Category B with a broken development stream, and
> introducing unpleasant surprises for maintainers of Category B repos,
> as historically Category A contributors were not familiar with
> Category B repos.
>
> Contributions made to Category B repos go through a GitHub Actions
> workflow that builds the relevant part of the `kie-tools` monorepo for
> the changes introduced. Changes made to the pipeline itself are also
> picked up as part of PRs, allowing us to do things like atomically
> bumping the Node.js version, for example. More importantly, it allows
> us to upgrade the repository to a new timestamped SNAPSHOT together
> with the changes necessary to make it stay green.
>
> This setup, however, makes it impossible to have cross-repo PRs
> involving Category A and Category B simultaneously, with the current
> automations we have.
>
> Category C repos are kind of floating around, and I'm not sure if
> there's much activity going on there. Regardless, as they're part of
> Apache KIE, they will be part of our release, so I listed them for us
> to take them into consideration too.
>
> Category D is self explanatory. There's only one repo that has already
> been marked for being archived.
>
> Category E are repos that do not host code directly, and are either
> organizational entities, or host websites, that currently are not part
> of any pipelines we have.
>
> This lack of unification between Category A and Category B is, IMHO,
> what allowed us to introduce the infamous circular dependency between
> `kie-tools` and `kogito-apps`, which we now can describe as a circular
> dependency between Category A and Category B. The way I see it, if we
> had a single pipeline, building everything from `drools` to
> `kie-tools`, such flaws would've never been introduced, and we
> wouldn't be having this huge problem in our hands right now.
>
> My proposal for the Apache KIE release process sees this lack of
> unification as a central problem, not only for this release in
> particular, but for the community as a whole. It is my belief that we
> are all under the same roof, and that no contribution should be
> allowed to break any part of our codebase. With the increasing volume
> of code, and hopefully number of contributors too, we cannot keep
> counting on "common sense" to avoid breaking things. We're all humans
> after all, and it is our job to have mechanisms in place to prevent us
> from unwillingly making mistakes. Especially when these mistakes
> impact on parts of the codebase that we, individually, probably can't
> fix.
>
>
> # THE PROBLEMS WE HAVE RIGHT NOW
>
> P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> `0.32.0`.
> See:
> -
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
>
>
> P2. PR open for Kogito SWF images @ `kogito-images` depending on
> kiegroup's KIE Tools `0.32.0`.
> See:
> -
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
>
>
> P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> `kie-soup` artifacts at version `7.59.0.Final`.
> See:
> -
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> -
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
>
>
> P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> Explainability `1.22.1.Final`.
> * This module was removed from the KIE codebase here:
>
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> and now lives on
> https://github.com/trustyai-explainability/trustyai-explainability,
> under a different GAV.
> * This new repo depends on Kogito and OptaPlanner, pointing to older
> versions.
> See:
> -
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> -
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
>
>
> P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> `1.32.0.Final` and Quarkus `2.15.3.Final`.
> See:
> -
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
>
>
> P6. Category C repos are out of date and not part of the Category A
> CI/Release pipelines.
> * incubator-kie-kogito-benchmarks: (Current version is `2.0-SNAPSHOT`,
> depending on Kogito without a specific version, only by using
> `http://localhost:8080`)
> * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
>
>
> P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled after
> upgrading to 999-20240218-SNAPSHOT.
>
>
> In my perspective, P1 and P2 have the same solution, as they both
> suffer from the circular dependency between Category A and Category B.
> As Category A and Category B are both streams that have been really
> active, I see this as a blocker, as there are contributions that
> cannot be done, given that Category A depends on Category B with a
> dephasing of 1 release.
>
> P3 and P4, although not ideal, can be understood as technical debt.
> Depending on unmaintained projects is something we'll always be
> susceptible to, given time.
>
> P5 and P6 are easily fixable, as it's just a matter of making them
> part of the play.
>
> P7 is an isolated problem that won't impact the structure or anything
> that we're talking about here, but it is a regression we introduced
> recently.
>
> Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> and P7 have easy fixes, the only problems left to discuss are P1 and
> P2, which can't be done without a proper proposal.
>
>
> # THE PROPOSAL
>
> I'll try to be very meticulous here, since from my experience, any
> little miscalculation can lead to our release not working out in the
> end. To try and avoid that as much as possible, and make everything we
> can to have a successful Apache KIE 10 release, bear with me. I'll lay
> out a timeline of events that need to happen in order for our release
> to be published, with all artifacts ending up in the right places, but
> first, we need to solve problems P1 and P2.
>
> As you saw at the beginning of this email, all the attempts we made
> left us with the circular dependency showing up at a different place,
> but something all these places have in common is that they're all
> after kogito-apps, and before to Category B.
>
> The first part of my proposal is the following:
>
> S1. We keep the original plan of moving the Quarkus Dev UIs from
> `kogito-apps` to `kie-tools`, together with Management and Task
> consoles from `kogito-images` to `kie-tools`.
> S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> from `kogito-images` to `kie-tools` too.
> S3. We move the entire `kogito-serverless-operator` repo inside a new
> package on `kie-tools`, keeping Git history.
>
> Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> the rest of https://github.com/apache/incubator-kie-issues/issues/967
> would still be done too.
>
> This doesn't come without consequences, of course, as the
> `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> `kogito-serverless-operator` would be moving from Category A to
> Category B. This move would make them have to reference Category A
> repos through timestamped SNAPSHOTs. Since `kogito-images` and
> `kogito-serverless-operator` are already their own "sub-stream" inside
> Category A, though, contributions made in a cross-repo fashion to this
> "sub-stream" will continue being possible, now via a single PR to
> `kie-tools`. Cross-repo PRs between Category A and Category B will
> continue not being possible, and a 1-week delay between merging
> something on Category A and using it on Category B will still happen.
>
> It's worth mentioning that `kie-tools`, however, does allow for sparse
> checkouts and partial builds, so working with a subset of the monorepo
> is possible and encouraged. Making changes only to
> `packages/kn-plugin-workflow`, for example, will have the PR checks
> run in < 10 minutes, as you can see here:
>
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> .
> We're not compromising when running partial builds too. We know that
> the entire repo will continue working even after only building a small
> subset of the changes. Doing partial or full builds is automatically
> determined by the changes of a PR.
>
> Keep in mind that, even though I'm proposing we move a bunch of
> additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> for our codebase. `kie-tools` would host some additional stuff
> TEMPORARILY so that we can release and continue moving forward.
>
> As I mentioned on other places, `kie-tools` became a polyglot monorepo
> out of necessity, and although I'm really proud of what we achieved
> there so far, I don't think `kie-tools` has a setup that is suitable
> for all the different nuances that compose our community. I'm well
> aware that a polyglot monorepo that does not follow widespread
> conventions will scare some people away, and as much as we've tried to
> make build instructions clear, we can't always get past the prejudice
> some people have towards the "front-end" ecosystem.
>
> With all that said, I keep thinking this is the best course of action
> for us right now. We keep most of our stuff unchanged, we unblock the
> release, and we have a working setup that will suit us well while we
> discuss and reach a conclusion regarding the future of our codebase
> structure.
>
> Let me paint a quick picture here of what our code base would look
> like, repository-wise, if my proposal is accepted:
>
> CATEGORY REPO
> =====================
> A incubator-kie-kogito-pipelines
> A incubator-kie-drools
> A incubator-kie-optaplanner
> A incubator-kie-optaplanner-quickstarts
> A incubator-kie-kogito-runtimes
> A incubator-kie-kogito-apps
> A incubator-kie-kogito-examples
> A incubator-kie-kogito-images
> A incubator-kie-kogito-docs
> A incubator-kie-kogito-benchmarks
> A incubator-kie-docs
> A incubator-kie-benchmarks
> =====================
> B incubator-kie-sandbox-quarkus-accelerator
> B incubator-kie-tools
> =====================
> D incubator-kie-kogito-operator
> =====================
> E incubator-kie-issues
> E incubator-kie-kogito-website
> E incubator-kie-website
> E incubator-kie-kogito-online
> E incubator-kie-kogito-online-staging
> =====================
>
> * Category C becomes part of Category A, and
> `kogito-serverless-operator` moves entirely inside `kie-tools`.
> * With `kogito-swf-{builder,devmode}` images and
> `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> anymore, as inside `kie-tools`, we can granularly build:
> 1. packages/sonataflow-deployment-webapp
> 2. packages/sonataflow-quarkus-devui
> 3. packages/sonataflow-images (containing `kogito-swf-builder` and
> `kogito-swf-devmode`)
> 4. packages/sonataflow-operator (contents from
> `kogito-serverless-operator`)
> 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> but renamed)
>
> The second part of the proposal is the release process itself,
> assuming the structure above is what we have.
>
> Here it is:
>
> 1. Define a timestamped SNAPSHOT to be used as cutting point for
> Category A repos.
> 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> verify that everything is working.
> 3. At this point, with everything working, we can branch out to
> `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
> from `main`.
> 4. All Category A and Category B repos update their versions to
> 10.0.0, in their `10.0.x` branches.
> 5. Update Category B repos to point to Category A repos using the
> 10.0.0 version.
> 6. At this point, we can vote on the release based on the `10.0.x`
> branches, given we don't expect any code changes anymore.
> 7. After voting passes, we're good to start the release process.
> 8. Category A repos follow their manual/automated release process,
> pointing to the `10.0.x` branch. Tags pushed to Git, and built
> artifacts pushed to their registries.
> 9. We wait a little bit for Category A artifacts to be propagated on
> registries. ~1 day.
> 10. Category B repos follow their manual/automated release process,
> pointing to the `10.0.x` branch. Tags pushed to Git, and built
> artifacts pushed to their registries.
> 11. Category D repos are ignored.
> 12. Category E repos can be manually tagged with 10.0.0 from their
> default branches.
>
> More needs to be discussed if we're planning to maintain multiple
> release streams in parallel, but I guess it can wait for after Apache
> KIE 10.
>
> Thank you for reading, and I'm looking forward to hearing back from
> everyone.
>
> Of course, alternative solutions are possible. This email, however,
> summarizes my view of how we should attack the problem, considering
> disruption, required effort, the release process itself, and history.
> Feel free to propose alternatives. This is not a voting thread.
>
> Regards,
>
> Tiago Bento
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Thanks a lot for amending the proposal.
Although I agree with almost the whole proposal, as pointed out in my
previous e-mails, I did not understand, out of ignorance probably, the need
for a cutting point of Category A before Category B. If the criteria is the
existence of a dependency, following that rule, apps should force a cut
point on runtimes and runtimes should force a cut point on drools. Since we
are not doing that and everything is still working, I think I should rule
out that as an explanation. It is because we need to test with certain
snapshots manually?. Then, the cutting point is almost simultaneous with
the release isnt it?
If that's the case I propose to slightly amend point 2 by adding manually
at the end, so eventually, if we manage to test that automatically, then we
can remove fixed snapshots between repos of category A and B.
2. Update Category B repos to point to this timestamped SNAPSHOT, and
verify that everything is working manually.
On Mon, Mar 18, 2024 at 11:09 PM Alex Porcelli <po...@apache.org> wrote:
> This is the amended version of the proposal.
>
> # THE PROPOSAL
>
> S1. [Permanent] We keep the original plan of moving the Quarkus Dev
> UIs from `kogito-apps` to `kie-tools`, together with Management and
> Task
> consoles from `kogito-images` to `kie-tools`.
> S2. [Temporary] We copy the `kogito-swf-devmode` and
> `kogito-swf-builder` images from `kogito-images` to `kie-tools` too.
> S3. [Temporary] We copy the entire `kogito-serverless-operator` repo
> inside a new package on `kie-tools`. Disable CI for the operator to
> avoid overlap with kie-tools.
>
>
> List of all repositories that are relevant to Apache KIE 10.0.0 release
>
> CATEGORY REPO
> =====================
> A incubator-kie-drools
> A incubator-kie-optaplanner
> A incubator-kie-kogito-runtimes
> A incubator-kie-kogito-apps
> A incubator-kie-kogito-images
> =====================
> B incubator-kie-sandbox-quarkus-accelerator
> B incubator-kie-tools
>
> * `kogito-serverless-operator` is entirely copied inside `kie-tools`.
> * `kogito-swf-{builder,devmode}` images also copied to `kie-tools`.
> * all other repos are ignored for the Apache KIE 10.0.0 release
>
> This is the updated steps for the release process itself:
>
> 1. Define a timestamped SNAPSHOT to be used as cutting point for
> Category A repos.
> 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> verify that everything is working.
> 3. At this point, with everything working, we can branch out to
> `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
> from `main`.
> 4. Category A and Category B repos update their versions and
> dependencies to 10.0.0 in their `10.0.x` branches.
> 5. Tag 10.0.0-RC1 from `10.0.x`, build source zips and artifacs, and
> publish to staging.
> 6. At this point, we can start the vote on the release based on the
> `10.0.0-RC1` tag.
> 7. After voting passes, we're good to promote Maven artifact from
> staging to release.
> 8. Category A and Category B repos will need a new build to publish
> the release artifacts, except for Maven artifacts which will be
> already promoted in the previous step.
> 9. Once released, remove the temporary code from the `kie-tools`
> repository on `main` (`kogito-swf-{builder,devmode}` images and
> `kogito-serverless-operator` codebase).
> 10. Re-introduce circular dependency in `main` using 10.0.0 fixed
> versions (in `kie-tools`, `kogito-images` and
> `kogito-serverless-operator`) to prevent breaking completely CI.
> Definitive solution must be discussed.
>
> Note: The removal of temporary changes must come after the 10.0.0
> release, otherwise it'll break the CI for `main`.
>
>
> On Fri, Mar 15, 2024 at 1:51 PM Enrique Gonzalez Martinez
> <eg...@apache.org> wrote:
> >
> > Parties = two different visions of how to achieve this.
> > There were two groups of people arguing how to unblock the situation.
> >
> > I think this was clear for anyone following this thread.
> >
> >
> >
> > El vie, 15 mar 2024, 18:33, Jason Porter <li...@apache.org>
> escribió:
> >
> > > On 2024/03/15 12:25:22 Enrique Gonzalez Martinez wrote:
> > > > +1 to the short term approach as it seems both parties agree into
> this.
> > >
> > > Out of curiosity, what do you mean by "both parties?" Everyone is a
> > > contributor, there are no companies within the ASF. We're all one big
> > > community. What we do may not align 100% with the tactical ideas of any
> > > downstream company, but at the community level, that shouldn't be the
> > > driver of things anyway.
> > >
> > > > Regarding the long term proposal plz move to another thread before
> > > someone
> > > > starts engaging in this thread about a topic is not relevant for
> > > unblocking
> > > > the version.
> > > >
> > > > El vie, 15 mar 2024, 13:20, Kris Verlaenen <kris.verlaenen@gmail.com
> >
> > > > escribió:
> > > >
> > > > > TLDR: A +1 to the proposal from Tiago for the release, with the
> > > addition of
> > > > > some short term recommendation (on how to revert some of the
> temporary
> > > > > changes) and some perspective on a potential alternative to
> consider
> > > for
> > > > > the long term
> > > > >
> > > > > * Short term: The plan from Tiago describes a strategy that
> appears to
> > > be
> > > > > able to solve the build cycle issues we have, allowing us to
> proceed
> > > with
> > > > > the 10.0 release. We do realize that some of the changes that are
> > > being
> > > > > done to be able to do the 10.0 release are going to be temporary.
> > > > > Therefore, as part of this proposal, I urge the team to also
> document
> > > how
> > > > > we are going to revert some of these temporary changes immediately
> > > after
> > > > > the release (*). More specifically, my recommendation is that we
> agree
> > > > > that the images and operator folder from kie-tools will be removed
> > > again
> > > > > and development will continue on the existing repositories. But
> let’s
> > > > > discuss if people see this differently or if there might be other
> > > steps.
> > > > > The advantage of this approach would be that it allows us to move
> > > forward
> > > > > with the release, does buy us time to find a consensus on the
> long-term
> > > > > solution and minimizes the impact on the developers regarding
> temporary
> > > > > solutions. And it also requires us to find this consensus before
> the
> > > next
> > > > > release.
> > > > >
> > > > > * Longer term: as discussed to some degree in this thread already,
> > > there
> > > > > seems to be an alternative to explore where we define more strict
> > > > > boundaries (for dependencies) between repositories, and create a
> build
> > > > > chain where images and operator are built after tools. That said,
> it’s
> > > > > fair to say that this proposal needs to be worked out and validated
> > > more,
> > > > > and initial assessments on the effort related to this, if we don’t
> > > want to
> > > > > rush into this and do things right, are indicating this might take
> > > multiple
> > > > > months. We also need to discuss how we will be resourcing this
> effort.
> > > > > And we could potentially combine this with other discussions that
> we
> > > will
> > > > > have in the near future. So if we agree to investigate this
> further, I
> > > > > would like to recommend moving forward with the more concrete
> temporary
> > > > > solution that Tiago is proposing for the 10.0 release.
> > > > >
> > > > > Note that this would mean that at this point, on this thread, we
> don’t
> > > need
> > > > > to agree on the specifics of any alternative proposal longer-term,
> we
> > > can
> > > > > start a different conversation thread for this. I hope this can
> > > convince
> > > > > people to +1 the approach as described by Tiago short term for the
> > > release,
> > > > > with the addition of the recipe how to revert some of the temporary
> > > changes
> > > > > and the promise to further evaluate longer-term alternatives. For
> > > those
> > > > > that are interested, I wanted to also give an indication what this
> > > proposal
> > > > > might mean at a high level from my point of view, which is included
> > > below.
> > > > >
> > > > > Thx,
> > > > > Kris
> > > > >
> > > > > [Optional reading] Alternative longer-term proposal
> > > > >
> > > > > One could subdivide the work we do in two main streams: one focused
> > > more on
> > > > > the runtimes, one focused more on the tooling. In general a lot of
> > > tooling
> > > > > can be built independently from the runtime and vice versa, where
> they
> > > > > communicate with each other through well defined formats or apis.
> > > However,
> > > > > once we start looking at more advanced use cases and the full
> > > end-to-end,
> > > > > this is where we need both tooling and runtime together.
> > > > > The goal is to create one release pipeline(**). The issue with
> cyclic
> > > > > dependencies between repos is imho twofold: 1) we haven’t been 100%
> > > > > consistent in separating runtimes and tooling this way and 2) we
> > > haven’t
> > > > > accommodated well for use cases where runtime and tooling needs to
> be
> > > > > combined. Note that some of these dependencies might not be build
> time
> > > > > dependencies but test and/or runtime dependencies only.
> > > > > As an alternative to one kie-tools monorepo that combines tooling
> and
> > > > > images and operator, I believe we can construct a pipeline where
> most
> > > of
> > > > > runtime and tooling can be built independently, but after runtime
> and
> > > > > tooling are built, we complete the build with other
> > > > > components/repositories, because they logically rely more on both.
> > > > > Examples of components that rely on both are for example be a devui
> > > > > extension (a quarkus extension that embeds tooling) or the devmode
> > > image
> > > > > (that also includes tooling features), or integration testing
> (where we
> > > > > want to test whether tooling and runtime work well together.
> > > > >
> > > > > More specifically, this would mean
> > > > > 1) making sure that there are well-defined boundaries between the
> core
> > > > > runtimes and core tooling so they don’t depend on each other at
> build
> > > > > time. We can decide to move components around where we think that
> > > makes
> > > > > sense, for example:
> > > > > move ui code related to devui into kie-tools (as discussed before)
> > > > > move kn-workflow to the operator repository as it more closely
> related
> > > to
> > > > > that
> > > > > 2) update the CI and release pipelines so that core runtime and
> tooling
> > > > > repositories can be built first, and are followed up by other
> > > repositories
> > > > > like images and operator, that could then rely on both.
> > > > >
> > > > > (*) Note that there would be other options technically to achieve
> this,
> > > > > like cutting a release branch early and performing the changes only
> > > there,
> > > > > but given other work is still ongoing as well, we want to minimize
> the
> > > > > cherry-picking effort.
> > > > > (**) Note that while the goal is to create one release pipeline,
> this
> > > > > should not necessarily mean that we can’t have smaller or optimized
> > > > > pipelines for CI and daily development, where the impact of
> changes is
> > > > > typically more localized.
> > > > >
> > > > > On Tue, Mar 12, 2024 at 8:45 PM Tiago Bento <tiagobento@apache.org
> >
> > > wrote:
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > Unfortunately, I can't do a tl;dr this time, as this matter
> requires
> > > a
> > > > > > lot of context.
> > > > > >
> > > > > > This email will take you < 20 minutes to read, according to
> > > > > > https://thereadtime.com/.
> > > > > >
> > > > > > As you may have followed on a separate thread
> > > > > > (
> https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> > > > > > many of us were working towards removing a circular dependency
> > > > > > currently present between `kogito-apps` and `kie-tools`. As we
> > > > > > progressed towards a solution, we kept finding the circular
> > > dependency
> > > > > > pop up somewhere else. I'll do a breakdown of the things we did,
> and
> > > > > > the results we had.
> > > > > >
> > > > > > Right now, even though we started the effort to move the Quarkus
> Dev
> > > > > > UI modules to `kie-tools`, we haven't been able to do it yet, as
> > > we've
> > > > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and
> Quarkus
> > > > > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT.
> This
> > > > > > effort was concluded this Monday, with
> > > > > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > > > > >
> > > > > > The current scenario we have is:
> > > > > >
> > > > > > 01. incubator-kie-kogito-runtimes
> > > > > > |==> 02. incubator-kie-kogito-apps
> > > > > > C | 03. incubator-kie-kogito-examples
> > > > > > Y | 04. incubator-kie-kogito-images
> > > > > > C | 05. incubator-kie-kogito-serverless-operator
> > > > > > L | ==========================
> > > > > > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > > > |==> 07. incubator-kie-tools
> > > > > >
> > > > > >
> > > > > > * As `kie-tools`/extended-services depends on
> > > > > > `kogito-apps`/jitexecutor;
> > > > > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui
> depend on
> > > > > > `kie-tools`/{many packages}
> > > > > >
> > > > > >
> > > > > > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> > > > > >
> > > > > > 01. incubator-kie-kogito-runtimes
> > > > > > 02. incubator-kie-kogito-apps
> > > > > > 03. incubator-kie-kogito-examples
> > > > > > C |==> 04. incubator-kie-kogito-images
> > > > > > Y | 05. incubator-kie-kogito-serverless-operator
> > > > > > C | =====================
> > > > > > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > > > E |==> 07. incubator-kie-tools
> > > > > >
> > > > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > > > `kogito-images`/kogito-swf-devmode;
> > > > > > * and `kogito-images`/kogito-swf-devmode depends on
> > > > > > `kie-tools`/sonataflow-quarkus-devui
> > > > > >
> > > > > >
> > > > > > After moving the `kogito-swf-devmode` image to `kie-tools`, we
> > > would've
> > > > > > had:
> > > > > >
> > > > > > 01. incubator-kie-kogito-runtimes
> > > > > > 02. incubator-kie-kogito-apps
> > > > > > 03. incubator-kie-kogito-examples
> > > > > > 04. incubator-kie-kogito-images
> > > > > > C |==> 05. incubator-kie-kogito-serverless-operator
> > > > > > Y | =====================
> > > > > > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > > > L |==> 07. incubator-kie-tools
> > > > > > E
> > > > > >
> > > > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > > > `kogito-serverless-operator`;
> > > > > > * and `kogito-serverless-operator` depends on
> > > > > > `kie-tools`/kogito-swf-devmode
> > > > > >
> > > > > >
> > > > > > Clearly, we have a much bigger problem than a simple circular
> > > dependency.
> > > > > >
> > > > > > After multiple conversations with a lot of people, it's been
> really
> > > > > > hard coming up with a simple solution that makes it possible to
> build
> > > > > > Apache KIE in one shot, while preserving the way everyone is
> used to
> > > > > > contributing to the multiple repositories we have. More than
> that,
> > > > > > while making this assessment, I found more problems that, in my
> > > > > > perspective, block Apache KIE 10.
> > > > > >
> > > > > > In light of that difficulty, I'm coming forward with my proposal
> for
> > > > > > the Apache KIE release process, so we can use Apache's
> mechanisms to
> > > > > > have a slower-paced, in-depth debate about this really
> complicated
> > > > > > matter.
> > > > > >
> > > > > > I'll lay out my entire perspective about the current situation
> of our
> > > > > > codebase, as well as problems I can currently see. I'll start
> with an
> > > > > > analysis of the repositories and their purposes, point out some
> > > > > > problems that I believe are blocking our 10 release, explain my
> > > > > > proposal and discuss some consequences to what I'm proposing.
> > > > > >
> > > > > > Let's begin.
> > > > > >
> > > > > >
> > > > > > # THE APACHE KIE REPOS
> > > > > >
> > > > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > > - incubator-kie-drools @ `main`
> > > > > > - incubator-kie-optaplanner @ `main`
> > > > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > > - incubator-kie-kogito-apps @ `main`
> > > > > > - incubator-kie-kogito-examples @ `main`
> > > > > > - incubator-kie-kogito-images @ `main`
> > > > > > - incubator-kie-kogito-serverless-operator @ `main`
> > > > > > - incubator-kie-kogito-docs @ `main`
> > > > > > - incubator-kie-docs @ `main-kogito`
> > > > > >
> > > > > > B. TOOLS (count: 2)
> > > > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > > > > - incubator-kie-tools @ `main`
> > > > > >
> > > > > > C. BENCHMARKS (count: 2)
> > > > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > > - incubator-kie-benchmarks @ `main`
> > > > > >
> > > > > > D. ARCHIVED (count: 1)
> > > > > > - incubator-kie-kogito-operator
> > > > > >
> > > > > > E. "NON-CODE" (count: 5)
> > > > > > - incubator-kie-issues @ `main`
> > > > > > (Issues only, README should be updated @ `main`. Same for
> GitHub
> > > > > > Actions workflows.)
> > > > > > - incubator-kie-kogito-website @ `main`
> > > > > > (The Kogito website. Develop & deploy at the `main` branch.)
> > > > > > - incubator-kie-website @ `main`
> > > > > > (The KIE website. Develop @ `main`. Push @ `deploy` to
> update the
> > > > > > website.)
> > > > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > > (GitHub pages used to host sandbox.kie.org and KIE Tools'
> Chrome
> > > > > > Extension assets.)
> > > > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > > (Same as above, but for manual sanity checks during the
> staging
> > > > > > phase of a release.)
> > > > > >
> > > > > > TOTAL (count: 21)
> > > > > >
> > > > > > I grouped the repositories by category, and listed them in a
> > > > > > topological order. Keep in mind that when flattening out a tree,
> > > there
> > > > > > are multiple possibilities. For example, OptaPlanner could've
> been
> > > > > > placed in any position after Drools.
> > > > > >
> > > > > > Category A repos are what I've been referring to as `drools` and
> > > > > > `kogito-*` stream. Of course OptaPlanner is inside that stream,
> as
> > > the
> > > > > > way these repositories reference each other are through Maven
> > > > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This
> > > mechanism
> > > > > > is well-known to the team, and although flawed for intra-day
> builds
> > > > > > and disruptive for people in many different time zones, it is
> already
> > > > > > very comfortable for everyone to work with, I assume.
> > > > > >
> > > > > > Contributions made to Category A have some dedicated pipelines,
> which
> > > > > > are, at least to some extent, able to build cross-repo PRs
> together
> > > > > > and verify that the codebase will continue working as expected
> after
> > > > > > they're all merged. From what I could gather, there are some
> > > > > > "sub-streams" currently configured for cross-repo PRs.
> > > > > >
> > > > > > - kogito-pipelines
> > > > > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > > > > > - optaplanner, and optaplanner-quickstarts
> > > > > > - kogito-images, and kogito-serverless-operator
> > > > > > - kogito-docs
> > > > > > - kie-docs
> > > > > >
> > > > > > This means that sending cross-repo PRs to any combination of
> repos
> > > > > > that are not part of the same "sub-stream" cannot be verified
> before
> > > > > > merging, making our contribution model dependent on individual
> > > > > > contributors building stuff on their machines to verify that it
> > > works.
> > > > > >
> > > > > > I based this analysis on
> > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > > ,
> > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > > ,
> > > > > > and
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > > .
> > > > > > Note that I'm not that familiar with these pipelines, so please
> > > > > > someone correct me if I'm wrong.
> > > > > >
> > > > > > Category B repos are what I've been referring to as `kie-tools`
> > > > > > stream. The first repo there is a template repository that is
> used by
> > > > > > people starting projects from scratch on KIE Sandbox, similar to
> a
> > > > > > Maven archetype, if you will. The other one is the KIE Tools
> > > monorepo,
> > > > > > a polyglot monorepo with `pnpm` as its build system. Currently,
> KIE
> > > > > > Tools hosts Java libraries and apps, TypeScript libraries and
> apps,
> > > Go
> > > > > > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> > > > > > configured to work with sparse checkouts and can do partial
> builds.
> > > > > > Category B repos refer to Category A repos through timestamped
> > > > > > SNAPSHOTs. This is a new mechanism we recently introduced that
> will
> > > > > > build and publish immutable, persistent artifacts under a version
> > > > > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly
> every
> > > > > > Sunday night. Timestamped SNAPSHOTs are an evolution to the
> Kogito
> > > > > > releases, as we're now targeting one release for all of Apache
> KIE,
> > > so
> > > > > > we can't have Kogito releases anymore.
> > > > > >
> > > > > > An important note here is that Category B repositories have been
> > > > > > historically kept out of any automations we used to have, way
> back
> > > > > > when Kogito started and we had the Business Central (a.k.a. v7)
> > > stream
> > > > > > still going on. For this reason, Category B projects have
> developed
> > > > > > their own automations, based on GitHub Actions. Category B repos
> have
> > > > > > always depended on Category A repos using fixed versions. If
> Category
> > > > > > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > > > > > Category A repositories would've had the potential to break
> Category
> > > B
> > > > > > silently, leaving Category B with a broken development stream,
> and
> > > > > > introducing unpleasant surprises for maintainers of Category B
> repos,
> > > > > > as historically Category A contributors were not familiar with
> > > > > > Category B repos.
> > > > > >
> > > > > > Contributions made to Category B repos go through a GitHub
> Actions
> > > > > > workflow that builds the relevant part of the `kie-tools`
> monorepo
> > > for
> > > > > > the changes introduced. Changes made to the pipeline itself are
> also
> > > > > > picked up as part of PRs, allowing us to do things like
> atomically
> > > > > > bumping the Node.js version, for example. More importantly, it
> allows
> > > > > > us to upgrade the repository to a new timestamped SNAPSHOT
> together
> > > > > > with the changes necessary to make it stay green.
> > > > > >
> > > > > > This setup, however, makes it impossible to have cross-repo PRs
> > > > > > involving Category A and Category B simultaneously, with the
> current
> > > > > > automations we have.
> > > > > >
> > > > > > Category C repos are kind of floating around, and I'm not sure if
> > > > > > there's much activity going on there. Regardless, as they're
> part of
> > > > > > Apache KIE, they will be part of our release, so I listed them
> for us
> > > > > > to take them into consideration too.
> > > > > >
> > > > > > Category D is self explanatory. There's only one repo that has
> > > already
> > > > > > been marked for being archived.
> > > > > >
> > > > > > Category E are repos that do not host code directly, and are
> either
> > > > > > organizational entities, or host websites, that currently are not
> > > part
> > > > > > of any pipelines we have.
> > > > > >
> > > > > > This lack of unification between Category A and Category B is,
> IMHO,
> > > > > > what allowed us to introduce the infamous circular dependency
> between
> > > > > > `kie-tools` and `kogito-apps`, which we now can describe as a
> > > circular
> > > > > > dependency between Category A and Category B. The way I see it,
> if we
> > > > > > had a single pipeline, building everything from `drools` to
> > > > > > `kie-tools`, such flaws would've never been introduced, and we
> > > > > > wouldn't be having this huge problem in our hands right now.
> > > > > >
> > > > > > My proposal for the Apache KIE release process sees this lack of
> > > > > > unification as a central problem, not only for this release in
> > > > > > particular, but for the community as a whole. It is my belief
> that we
> > > > > > are all under the same roof, and that no contribution should be
> > > > > > allowed to break any part of our codebase. With the increasing
> volume
> > > > > > of code, and hopefully number of contributors too, we cannot keep
> > > > > > counting on "common sense" to avoid breaking things. We're all
> humans
> > > > > > after all, and it is our job to have mechanisms in place to
> prevent
> > > us
> > > > > > from unwillingly making mistakes. Especially when these mistakes
> > > > > > impact on parts of the codebase that we, individually, probably
> can't
> > > > > > fix.
> > > > > >
> > > > > >
> > > > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > > >
> > > > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE
> Tools
> > > > > > `0.32.0`.
> > > > > > See:
> > > > > > -
> > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > > >
> > > > > >
> > > > > > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > > > > > kiegroup's KIE Tools `0.32.0`.
> > > > > > See:
> > > > > > -
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > > >
> > > > > >
> > > > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo`
> and
> > > > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > > > See:
> > > > > > -
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > > -
> > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > > >
> > > > > >
> > > > > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > > > > > Explainability `1.22.1.Final`.
> > > > > > * This module was removed from the KIE codebase here:
> > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > > and now lives on
> > > > > >
> https://github.com/trustyai-explainability/trustyai-explainability,
> > > > > > under a different GAV.
> > > > > > * This new repo depends on Kogito and OptaPlanner, pointing to
> older
> > > > > > versions.
> > > > > > See:
> > > > > > -
> > > > > >
> > > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > > -
> > > > > >
> > > > >
> > >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > > >
> > > > > >
> > > > > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on
> Kogito
> > > > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > > See:
> > > > > > -
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > > >
> > > > > >
> > > > > > P6. Category C repos are out of date and not part of the
> Category A
> > > > > > CI/Release pipelines.
> > > > > > * incubator-kie-kogito-benchmarks: (Current version is
> > > `2.0-SNAPSHOT`,
> > > > > > depending on Kogito without a specific version, only by using
> > > > > > `http://localhost:8080`)
> > > > > > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > > > > > pointing to Drools 999-SNAPSHOT and OptaPlanner
> `8.45.0-SNAPSHOT`)
> > > > > >
> > > > > >
> > > > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled
> > > after
> > > > > > upgrading to 999-20240218-SNAPSHOT.
> > > > > >
> > > > > >
> > > > > > In my perspective, P1 and P2 have the same solution, as they both
> > > > > > suffer from the circular dependency between Category A and
> Category
> > > B.
> > > > > > As Category A and Category B are both streams that have been
> really
> > > > > > active, I see this as a blocker, as there are contributions that
> > > > > > cannot be done, given that Category A depends on Category B with
> a
> > > > > > dephasing of 1 release.
> > > > > >
> > > > > > P3 and P4, although not ideal, can be understood as technical
> debt.
> > > > > > Depending on unmaintained projects is something we'll always be
> > > > > > susceptible to, given time.
> > > > > >
> > > > > > P5 and P6 are easily fixable, as it's just a matter of making
> them
> > > > > > part of the play.
> > > > > >
> > > > > > P7 is an isolated problem that won't impact the structure or
> anything
> > > > > > that we're talking about here, but it is a regression we
> introduced
> > > > > > recently.
> > > > > >
> > > > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that
> P5, P6,
> > > > > > and P7 have easy fixes, the only problems left to discuss are P1
> and
> > > > > > P2, which can't be done without a proper proposal.
> > > > > >
> > > > > >
> > > > > > # THE PROPOSAL
> > > > > >
> > > > > > I'll try to be very meticulous here, since from my experience,
> any
> > > > > > little miscalculation can lead to our release not working out in
> the
> > > > > > end. To try and avoid that as much as possible, and make
> everything
> > > we
> > > > > > can to have a successful Apache KIE 10 release, bear with me.
> I'll
> > > lay
> > > > > > out a timeline of events that need to happen in order for our
> release
> > > > > > to be published, with all artifacts ending up in the right
> places,
> > > but
> > > > > > first, we need to solve problems P1 and P2.
> > > > > >
> > > > > > As you saw at the beginning of this email, all the attempts we
> made
> > > > > > left us with the circular dependency showing up at a different
> place,
> > > > > > but something all these places have in common is that they're all
> > > > > > after kogito-apps, and before to Category B.
> > > > > >
> > > > > > The first part of my proposal is the following:
> > > > > >
> > > > > > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > > > > > `kogito-apps` to `kie-tools`, together with Management and Task
> > > > > > consoles from `kogito-images` to `kie-tools`.
> > > > > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder`
> images
> > > > > > from `kogito-images` to `kie-tools` too.
> > > > > > S3. We move the entire `kogito-serverless-operator` repo inside
> a new
> > > > > > package on `kie-tools`, keeping Git history.
> > > > > >
> > > > > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of
> course
> > > > > > the rest of
> > > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > > would still be done too.
> > > > > >
> > > > > > This doesn't come without consequences, of course, as the
> > > > > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > > > > > `kogito-serverless-operator` would be moving from Category A to
> > > > > > Category B. This move would make them have to reference Category
> A
> > > > > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > > > > > `kogito-serverless-operator` are already their own "sub-stream"
> > > inside
> > > > > > Category A, though, contributions made in a cross-repo fashion to
> > > this
> > > > > > "sub-stream" will continue being possible, now via a single PR to
> > > > > > `kie-tools`. Cross-repo PRs between Category A and Category B
> will
> > > > > > continue not being possible, and a 1-week delay between merging
> > > > > > something on Category A and using it on Category B will still
> happen.
> > > > > >
> > > > > > It's worth mentioning that `kie-tools`, however, does allow for
> > > sparse
> > > > > > checkouts and partial builds, so working with a subset of the
> > > monorepo
> > > > > > is possible and encouraged. Making changes only to
> > > > > > `packages/kn-plugin-workflow`, for example, will have the PR
> checks
> > > > > > run in < 10 minutes, as you can see here:
> > > > > >
> > > > > >
> > > > >
> > >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > > .
> > > > > > We're not compromising when running partial builds too. We know
> that
> > > > > > the entire repo will continue working even after only building a
> > > small
> > > > > > subset of the changes. Doing partial or full builds is
> automatically
> > > > > > determined by the changes of a PR.
> > > > > >
> > > > > > Keep in mind that, even though I'm proposing we move a bunch of
> > > > > > additional stuff into `kie-tools`, I see this as a TEMPORARY
> solution
> > > > > > for our codebase. `kie-tools` would host some additional stuff
> > > > > > TEMPORARILY so that we can release and continue moving forward.
> > > > > >
> > > > > > As I mentioned on other places, `kie-tools` became a polyglot
> > > monorepo
> > > > > > out of necessity, and although I'm really proud of what we
> achieved
> > > > > > there so far, I don't think `kie-tools` has a setup that is
> suitable
> > > > > > for all the different nuances that compose our community. I'm
> well
> > > > > > aware that a polyglot monorepo that does not follow widespread
> > > > > > conventions will scare some people away, and as much as we've
> tried
> > > to
> > > > > > make build instructions clear, we can't always get past the
> prejudice
> > > > > > some people have towards the "front-end" ecosystem.
> > > > > >
> > > > > > With all that said, I keep thinking this is the best course of
> action
> > > > > > for us right now. We keep most of our stuff unchanged, we
> unblock the
> > > > > > release, and we have a working setup that will suit us well
> while we
> > > > > > discuss and reach a conclusion regarding the future of our
> codebase
> > > > > > structure.
> > > > > >
> > > > > > Let me paint a quick picture here of what our code base would
> look
> > > > > > like, repository-wise, if my proposal is accepted:
> > > > > >
> > > > > > CATEGORY REPO
> > > > > > =====================
> > > > > > A incubator-kie-kogito-pipelines
> > > > > > A incubator-kie-drools
> > > > > > A incubator-kie-optaplanner
> > > > > > A incubator-kie-optaplanner-quickstarts
> > > > > > A incubator-kie-kogito-runtimes
> > > > > > A incubator-kie-kogito-apps
> > > > > > A incubator-kie-kogito-examples
> > > > > > A incubator-kie-kogito-images
> > > > > > A incubator-kie-kogito-docs
> > > > > > A incubator-kie-kogito-benchmarks
> > > > > > A incubator-kie-docs
> > > > > > A incubator-kie-benchmarks
> > > > > > =====================
> > > > > > B incubator-kie-sandbox-quarkus-accelerator
> > > > > > B incubator-kie-tools
> > > > > > =====================
> > > > > > D incubator-kie-kogito-operator
> > > > > > =====================
> > > > > > E incubator-kie-issues
> > > > > > E incubator-kie-kogito-website
> > > > > > E incubator-kie-website
> > > > > > E incubator-kie-kogito-online
> > > > > > E incubator-kie-kogito-online-staging
> > > > > > =====================
> > > > > >
> > > > > > * Category C becomes part of Category A, and
> > > > > > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > > > > > * With `kogito-swf-{builder,devmode}` images and
> > > > > > `kogito-serverless-operator` inside `kie-tools`, there are no
> cycles
> > > > > > anymore, as inside `kie-tools`, we can granularly build:
> > > > > > 1. packages/sonataflow-deployment-webapp
> > > > > > 2. packages/sonataflow-quarkus-devui
> > > > > > 3. packages/sonataflow-images (containing
> `kogito-swf-builder`
> > > and
> > > > > > `kogito-swf-devmode`)
> > > > > > 4. packages/sonataflow-operator (contents from
> > > > > > `kogito-serverless-operator`)
> > > > > > 5. packages/kn-plugin-sonataflow
> (`packages/kn-plugin-workflow`,
> > > > > > but renamed)
> > > > > >
> > > > > > The second part of the proposal is the release process itself,
> > > > > > assuming the structure above is what we have.
> > > > > >
> > > > > > Here it is:
> > > > > >
> > > > > > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > > > > > Category A repos.
> > > > > > 2. Update Category B repos to point to this timestamped
> SNAPSHOT, and
> > > > > > verify that everything is working.
> > > > > > 3. At this point, with everything working, we can branch out to
> > > > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and
> Category
> > > B
> > > > > > from `main`.
> > > > > > 4. All Category A and Category B repos update their versions to
> > > > > > 10.0.0, in their `10.0.x` branches.
> > > > > > 5. Update Category B repos to point to Category A repos using the
> > > > > > 10.0.0 version.
> > > > > > 6. At this point, we can vote on the release based on the
> `10.0.x`
> > > > > > branches, given we don't expect any code changes anymore.
> > > > > > 7. After voting passes, we're good to start the release process.
> > > > > > 8. Category A repos follow their manual/automated release
> process,
> > > > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > > > > artifacts pushed to their registries.
> > > > > > 9. We wait a little bit for Category A artifacts to be
> propagated on
> > > > > > registries. ~1 day.
> > > > > > 10. Category B repos follow their manual/automated release
> process,
> > > > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > > > > artifacts pushed to their registries.
> > > > > > 11. Category D repos are ignored.
> > > > > > 12. Category E repos can be manually tagged with 10.0.0 from
> their
> > > > > > default branches.
> > > > > >
> > > > > > More needs to be discussed if we're planning to maintain multiple
> > > > > > release streams in parallel, but I guess it can wait for after
> Apache
> > > > > > KIE 10.
> > > > > >
> > > > > > Thank you for reading, and I'm looking forward to hearing back
> from
> > > > > > everyone.
> > > > > >
> > > > > > Of course, alternative solutions are possible. This email,
> however,
> > > > > > summarizes my view of how we should attack the problem,
> considering
> > > > > > disruption, required effort, the release process itself, and
> history.
> > > > > > Feel free to propose alternatives. This is not a voting thread.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Tiago Bento
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <po...@apache.org>.
This is the amended version of the proposal.
# THE PROPOSAL
S1. [Permanent] We keep the original plan of moving the Quarkus Dev
UIs from `kogito-apps` to `kie-tools`, together with Management and
Task
consoles from `kogito-images` to `kie-tools`.
S2. [Temporary] We copy the `kogito-swf-devmode` and
`kogito-swf-builder` images from `kogito-images` to `kie-tools` too.
S3. [Temporary] We copy the entire `kogito-serverless-operator` repo
inside a new package on `kie-tools`. Disable CI for the operator to
avoid overlap with kie-tools.
List of all repositories that are relevant to Apache KIE 10.0.0 release
CATEGORY REPO
=====================
A incubator-kie-drools
A incubator-kie-optaplanner
A incubator-kie-kogito-runtimes
A incubator-kie-kogito-apps
A incubator-kie-kogito-images
=====================
B incubator-kie-sandbox-quarkus-accelerator
B incubator-kie-tools
* `kogito-serverless-operator` is entirely copied inside `kie-tools`.
* `kogito-swf-{builder,devmode}` images also copied to `kie-tools`.
* all other repos are ignored for the Apache KIE 10.0.0 release
This is the updated steps for the release process itself:
1. Define a timestamped SNAPSHOT to be used as cutting point for
Category A repos.
2. Update Category B repos to point to this timestamped SNAPSHOT, and
verify that everything is working.
3. At this point, with everything working, we can branch out to
`10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
from `main`.
4. Category A and Category B repos update their versions and
dependencies to 10.0.0 in their `10.0.x` branches.
5. Tag 10.0.0-RC1 from `10.0.x`, build source zips and artifacs, and
publish to staging.
6. At this point, we can start the vote on the release based on the
`10.0.0-RC1` tag.
7. After voting passes, we're good to promote Maven artifact from
staging to release.
8. Category A and Category B repos will need a new build to publish
the release artifacts, except for Maven artifacts which will be
already promoted in the previous step.
9. Once released, remove the temporary code from the `kie-tools`
repository on `main` (`kogito-swf-{builder,devmode}` images and
`kogito-serverless-operator` codebase).
10. Re-introduce circular dependency in `main` using 10.0.0 fixed
versions (in `kie-tools`, `kogito-images` and
`kogito-serverless-operator`) to prevent breaking completely CI.
Definitive solution must be discussed.
Note: The removal of temporary changes must come after the 10.0.0
release, otherwise it'll break the CI for `main`.
On Fri, Mar 15, 2024 at 1:51 PM Enrique Gonzalez Martinez
<eg...@apache.org> wrote:
>
> Parties = two different visions of how to achieve this.
> There were two groups of people arguing how to unblock the situation.
>
> I think this was clear for anyone following this thread.
>
>
>
> El vie, 15 mar 2024, 18:33, Jason Porter <li...@apache.org> escribió:
>
> > On 2024/03/15 12:25:22 Enrique Gonzalez Martinez wrote:
> > > +1 to the short term approach as it seems both parties agree into this.
> >
> > Out of curiosity, what do you mean by "both parties?" Everyone is a
> > contributor, there are no companies within the ASF. We're all one big
> > community. What we do may not align 100% with the tactical ideas of any
> > downstream company, but at the community level, that shouldn't be the
> > driver of things anyway.
> >
> > > Regarding the long term proposal plz move to another thread before
> > someone
> > > starts engaging in this thread about a topic is not relevant for
> > unblocking
> > > the version.
> > >
> > > El vie, 15 mar 2024, 13:20, Kris Verlaenen <kr...@gmail.com>
> > > escribió:
> > >
> > > > TLDR: A +1 to the proposal from Tiago for the release, with the
> > addition of
> > > > some short term recommendation (on how to revert some of the temporary
> > > > changes) and some perspective on a potential alternative to consider
> > for
> > > > the long term
> > > >
> > > > * Short term: The plan from Tiago describes a strategy that appears to
> > be
> > > > able to solve the build cycle issues we have, allowing us to proceed
> > with
> > > > the 10.0 release. We do realize that some of the changes that are
> > being
> > > > done to be able to do the 10.0 release are going to be temporary.
> > > > Therefore, as part of this proposal, I urge the team to also document
> > how
> > > > we are going to revert some of these temporary changes immediately
> > after
> > > > the release (*). More specifically, my recommendation is that we agree
> > > > that the images and operator folder from kie-tools will be removed
> > again
> > > > and development will continue on the existing repositories. But let’s
> > > > discuss if people see this differently or if there might be other
> > steps.
> > > > The advantage of this approach would be that it allows us to move
> > forward
> > > > with the release, does buy us time to find a consensus on the long-term
> > > > solution and minimizes the impact on the developers regarding temporary
> > > > solutions. And it also requires us to find this consensus before the
> > next
> > > > release.
> > > >
> > > > * Longer term: as discussed to some degree in this thread already,
> > there
> > > > seems to be an alternative to explore where we define more strict
> > > > boundaries (for dependencies) between repositories, and create a build
> > > > chain where images and operator are built after tools. That said, it’s
> > > > fair to say that this proposal needs to be worked out and validated
> > more,
> > > > and initial assessments on the effort related to this, if we don’t
> > want to
> > > > rush into this and do things right, are indicating this might take
> > multiple
> > > > months. We also need to discuss how we will be resourcing this effort.
> > > > And we could potentially combine this with other discussions that we
> > will
> > > > have in the near future. So if we agree to investigate this further, I
> > > > would like to recommend moving forward with the more concrete temporary
> > > > solution that Tiago is proposing for the 10.0 release.
> > > >
> > > > Note that this would mean that at this point, on this thread, we don’t
> > need
> > > > to agree on the specifics of any alternative proposal longer-term, we
> > can
> > > > start a different conversation thread for this. I hope this can
> > convince
> > > > people to +1 the approach as described by Tiago short term for the
> > release,
> > > > with the addition of the recipe how to revert some of the temporary
> > changes
> > > > and the promise to further evaluate longer-term alternatives. For
> > those
> > > > that are interested, I wanted to also give an indication what this
> > proposal
> > > > might mean at a high level from my point of view, which is included
> > below.
> > > >
> > > > Thx,
> > > > Kris
> > > >
> > > > [Optional reading] Alternative longer-term proposal
> > > >
> > > > One could subdivide the work we do in two main streams: one focused
> > more on
> > > > the runtimes, one focused more on the tooling. In general a lot of
> > tooling
> > > > can be built independently from the runtime and vice versa, where they
> > > > communicate with each other through well defined formats or apis.
> > However,
> > > > once we start looking at more advanced use cases and the full
> > end-to-end,
> > > > this is where we need both tooling and runtime together.
> > > > The goal is to create one release pipeline(**). The issue with cyclic
> > > > dependencies between repos is imho twofold: 1) we haven’t been 100%
> > > > consistent in separating runtimes and tooling this way and 2) we
> > haven’t
> > > > accommodated well for use cases where runtime and tooling needs to be
> > > > combined. Note that some of these dependencies might not be build time
> > > > dependencies but test and/or runtime dependencies only.
> > > > As an alternative to one kie-tools monorepo that combines tooling and
> > > > images and operator, I believe we can construct a pipeline where most
> > of
> > > > runtime and tooling can be built independently, but after runtime and
> > > > tooling are built, we complete the build with other
> > > > components/repositories, because they logically rely more on both.
> > > > Examples of components that rely on both are for example be a devui
> > > > extension (a quarkus extension that embeds tooling) or the devmode
> > image
> > > > (that also includes tooling features), or integration testing (where we
> > > > want to test whether tooling and runtime work well together.
> > > >
> > > > More specifically, this would mean
> > > > 1) making sure that there are well-defined boundaries between the core
> > > > runtimes and core tooling so they don’t depend on each other at build
> > > > time. We can decide to move components around where we think that
> > makes
> > > > sense, for example:
> > > > move ui code related to devui into kie-tools (as discussed before)
> > > > move kn-workflow to the operator repository as it more closely related
> > to
> > > > that
> > > > 2) update the CI and release pipelines so that core runtime and tooling
> > > > repositories can be built first, and are followed up by other
> > repositories
> > > > like images and operator, that could then rely on both.
> > > >
> > > > (*) Note that there would be other options technically to achieve this,
> > > > like cutting a release branch early and performing the changes only
> > there,
> > > > but given other work is still ongoing as well, we want to minimize the
> > > > cherry-picking effort.
> > > > (**) Note that while the goal is to create one release pipeline, this
> > > > should not necessarily mean that we can’t have smaller or optimized
> > > > pipelines for CI and daily development, where the impact of changes is
> > > > typically more localized.
> > > >
> > > > On Tue, Mar 12, 2024 at 8:45 PM Tiago Bento <ti...@apache.org>
> > wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > Unfortunately, I can't do a tl;dr this time, as this matter requires
> > a
> > > > > lot of context.
> > > > >
> > > > > This email will take you < 20 minutes to read, according to
> > > > > https://thereadtime.com/.
> > > > >
> > > > > As you may have followed on a separate thread
> > > > > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> > > > > many of us were working towards removing a circular dependency
> > > > > currently present between `kogito-apps` and `kie-tools`. As we
> > > > > progressed towards a solution, we kept finding the circular
> > dependency
> > > > > pop up somewhere else. I'll do a breakdown of the things we did, and
> > > > > the results we had.
> > > > >
> > > > > Right now, even though we started the effort to move the Quarkus Dev
> > > > > UI modules to `kie-tools`, we haven't been able to do it yet, as
> > we've
> > > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> > > > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> > > > > effort was concluded this Monday, with
> > > > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > > > >
> > > > > The current scenario we have is:
> > > > >
> > > > > 01. incubator-kie-kogito-runtimes
> > > > > |==> 02. incubator-kie-kogito-apps
> > > > > C | 03. incubator-kie-kogito-examples
> > > > > Y | 04. incubator-kie-kogito-images
> > > > > C | 05. incubator-kie-kogito-serverless-operator
> > > > > L | ==========================
> > > > > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > > |==> 07. incubator-kie-tools
> > > > >
> > > > >
> > > > > * As `kie-tools`/extended-services depends on
> > > > > `kogito-apps`/jitexecutor;
> > > > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> > > > > `kie-tools`/{many packages}
> > > > >
> > > > >
> > > > > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> > > > >
> > > > > 01. incubator-kie-kogito-runtimes
> > > > > 02. incubator-kie-kogito-apps
> > > > > 03. incubator-kie-kogito-examples
> > > > > C |==> 04. incubator-kie-kogito-images
> > > > > Y | 05. incubator-kie-kogito-serverless-operator
> > > > > C | =====================
> > > > > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > > E |==> 07. incubator-kie-tools
> > > > >
> > > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > > `kogito-images`/kogito-swf-devmode;
> > > > > * and `kogito-images`/kogito-swf-devmode depends on
> > > > > `kie-tools`/sonataflow-quarkus-devui
> > > > >
> > > > >
> > > > > After moving the `kogito-swf-devmode` image to `kie-tools`, we
> > would've
> > > > > had:
> > > > >
> > > > > 01. incubator-kie-kogito-runtimes
> > > > > 02. incubator-kie-kogito-apps
> > > > > 03. incubator-kie-kogito-examples
> > > > > 04. incubator-kie-kogito-images
> > > > > C |==> 05. incubator-kie-kogito-serverless-operator
> > > > > Y | =====================
> > > > > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > > L |==> 07. incubator-kie-tools
> > > > > E
> > > > >
> > > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > > `kogito-serverless-operator`;
> > > > > * and `kogito-serverless-operator` depends on
> > > > > `kie-tools`/kogito-swf-devmode
> > > > >
> > > > >
> > > > > Clearly, we have a much bigger problem than a simple circular
> > dependency.
> > > > >
> > > > > After multiple conversations with a lot of people, it's been really
> > > > > hard coming up with a simple solution that makes it possible to build
> > > > > Apache KIE in one shot, while preserving the way everyone is used to
> > > > > contributing to the multiple repositories we have. More than that,
> > > > > while making this assessment, I found more problems that, in my
> > > > > perspective, block Apache KIE 10.
> > > > >
> > > > > In light of that difficulty, I'm coming forward with my proposal for
> > > > > the Apache KIE release process, so we can use Apache's mechanisms to
> > > > > have a slower-paced, in-depth debate about this really complicated
> > > > > matter.
> > > > >
> > > > > I'll lay out my entire perspective about the current situation of our
> > > > > codebase, as well as problems I can currently see. I'll start with an
> > > > > analysis of the repositories and their purposes, point out some
> > > > > problems that I believe are blocking our 10 release, explain my
> > > > > proposal and discuss some consequences to what I'm proposing.
> > > > >
> > > > > Let's begin.
> > > > >
> > > > >
> > > > > # THE APACHE KIE REPOS
> > > > >
> > > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > > - incubator-kie-kogito-pipelines @ `main`
> > > > > - incubator-kie-drools @ `main`
> > > > > - incubator-kie-optaplanner @ `main`
> > > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > > - incubator-kie-kogito-runtimes @ `main`
> > > > > - incubator-kie-kogito-apps @ `main`
> > > > > - incubator-kie-kogito-examples @ `main`
> > > > > - incubator-kie-kogito-images @ `main`
> > > > > - incubator-kie-kogito-serverless-operator @ `main`
> > > > > - incubator-kie-kogito-docs @ `main`
> > > > > - incubator-kie-docs @ `main-kogito`
> > > > >
> > > > > B. TOOLS (count: 2)
> > > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > > > - incubator-kie-tools @ `main`
> > > > >
> > > > > C. BENCHMARKS (count: 2)
> > > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > > - incubator-kie-benchmarks @ `main`
> > > > >
> > > > > D. ARCHIVED (count: 1)
> > > > > - incubator-kie-kogito-operator
> > > > >
> > > > > E. "NON-CODE" (count: 5)
> > > > > - incubator-kie-issues @ `main`
> > > > > (Issues only, README should be updated @ `main`. Same for GitHub
> > > > > Actions workflows.)
> > > > > - incubator-kie-kogito-website @ `main`
> > > > > (The Kogito website. Develop & deploy at the `main` branch.)
> > > > > - incubator-kie-website @ `main`
> > > > > (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> > > > > website.)
> > > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > > (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> > > > > Extension assets.)
> > > > > - incubator-kie-kogito-online-staging @ `main`
> > > > > (Same as above, but for manual sanity checks during the staging
> > > > > phase of a release.)
> > > > >
> > > > > TOTAL (count: 21)
> > > > >
> > > > > I grouped the repositories by category, and listed them in a
> > > > > topological order. Keep in mind that when flattening out a tree,
> > there
> > > > > are multiple possibilities. For example, OptaPlanner could've been
> > > > > placed in any position after Drools.
> > > > >
> > > > > Category A repos are what I've been referring to as `drools` and
> > > > > `kogito-*` stream. Of course OptaPlanner is inside that stream, as
> > the
> > > > > way these repositories reference each other are through Maven
> > > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This
> > mechanism
> > > > > is well-known to the team, and although flawed for intra-day builds
> > > > > and disruptive for people in many different time zones, it is already
> > > > > very comfortable for everyone to work with, I assume.
> > > > >
> > > > > Contributions made to Category A have some dedicated pipelines, which
> > > > > are, at least to some extent, able to build cross-repo PRs together
> > > > > and verify that the codebase will continue working as expected after
> > > > > they're all merged. From what I could gather, there are some
> > > > > "sub-streams" currently configured for cross-repo PRs.
> > > > >
> > > > > - kogito-pipelines
> > > > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > > > > - optaplanner, and optaplanner-quickstarts
> > > > > - kogito-images, and kogito-serverless-operator
> > > > > - kogito-docs
> > > > > - kie-docs
> > > > >
> > > > > This means that sending cross-repo PRs to any combination of repos
> > > > > that are not part of the same "sub-stream" cannot be verified before
> > > > > merging, making our contribution model dependent on individual
> > > > > contributors building stuff on their machines to verify that it
> > works.
> > > > >
> > > > > I based this analysis on
> > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > > ,
> > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > > ,
> > > > > and
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > > .
> > > > > Note that I'm not that familiar with these pipelines, so please
> > > > > someone correct me if I'm wrong.
> > > > >
> > > > > Category B repos are what I've been referring to as `kie-tools`
> > > > > stream. The first repo there is a template repository that is used by
> > > > > people starting projects from scratch on KIE Sandbox, similar to a
> > > > > Maven archetype, if you will. The other one is the KIE Tools
> > monorepo,
> > > > > a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> > > > > Tools hosts Java libraries and apps, TypeScript libraries and apps,
> > Go
> > > > > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> > > > > configured to work with sparse checkouts and can do partial builds.
> > > > > Category B repos refer to Category A repos through timestamped
> > > > > SNAPSHOTs. This is a new mechanism we recently introduced that will
> > > > > build and publish immutable, persistent artifacts under a version
> > > > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> > > > > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> > > > > releases, as we're now targeting one release for all of Apache KIE,
> > so
> > > > > we can't have Kogito releases anymore.
> > > > >
> > > > > An important note here is that Category B repositories have been
> > > > > historically kept out of any automations we used to have, way back
> > > > > when Kogito started and we had the Business Central (a.k.a. v7)
> > stream
> > > > > still going on. For this reason, Category B projects have developed
> > > > > their own automations, based on GitHub Actions. Category B repos have
> > > > > always depended on Category A repos using fixed versions. If Category
> > > > > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > > > > Category A repositories would've had the potential to break Category
> > B
> > > > > silently, leaving Category B with a broken development stream, and
> > > > > introducing unpleasant surprises for maintainers of Category B repos,
> > > > > as historically Category A contributors were not familiar with
> > > > > Category B repos.
> > > > >
> > > > > Contributions made to Category B repos go through a GitHub Actions
> > > > > workflow that builds the relevant part of the `kie-tools` monorepo
> > for
> > > > > the changes introduced. Changes made to the pipeline itself are also
> > > > > picked up as part of PRs, allowing us to do things like atomically
> > > > > bumping the Node.js version, for example. More importantly, it allows
> > > > > us to upgrade the repository to a new timestamped SNAPSHOT together
> > > > > with the changes necessary to make it stay green.
> > > > >
> > > > > This setup, however, makes it impossible to have cross-repo PRs
> > > > > involving Category A and Category B simultaneously, with the current
> > > > > automations we have.
> > > > >
> > > > > Category C repos are kind of floating around, and I'm not sure if
> > > > > there's much activity going on there. Regardless, as they're part of
> > > > > Apache KIE, they will be part of our release, so I listed them for us
> > > > > to take them into consideration too.
> > > > >
> > > > > Category D is self explanatory. There's only one repo that has
> > already
> > > > > been marked for being archived.
> > > > >
> > > > > Category E are repos that do not host code directly, and are either
> > > > > organizational entities, or host websites, that currently are not
> > part
> > > > > of any pipelines we have.
> > > > >
> > > > > This lack of unification between Category A and Category B is, IMHO,
> > > > > what allowed us to introduce the infamous circular dependency between
> > > > > `kie-tools` and `kogito-apps`, which we now can describe as a
> > circular
> > > > > dependency between Category A and Category B. The way I see it, if we
> > > > > had a single pipeline, building everything from `drools` to
> > > > > `kie-tools`, such flaws would've never been introduced, and we
> > > > > wouldn't be having this huge problem in our hands right now.
> > > > >
> > > > > My proposal for the Apache KIE release process sees this lack of
> > > > > unification as a central problem, not only for this release in
> > > > > particular, but for the community as a whole. It is my belief that we
> > > > > are all under the same roof, and that no contribution should be
> > > > > allowed to break any part of our codebase. With the increasing volume
> > > > > of code, and hopefully number of contributors too, we cannot keep
> > > > > counting on "common sense" to avoid breaking things. We're all humans
> > > > > after all, and it is our job to have mechanisms in place to prevent
> > us
> > > > > from unwillingly making mistakes. Especially when these mistakes
> > > > > impact on parts of the codebase that we, individually, probably can't
> > > > > fix.
> > > > >
> > > > >
> > > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > > >
> > > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> > > > > `0.32.0`.
> > > > > See:
> > > > > -
> > > > >
> > > >
> > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > > >
> > > > >
> > > > > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > > > > kiegroup's KIE Tools `0.32.0`.
> > > > > See:
> > > > > -
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > > >
> > > > >
> > > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> > > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > > See:
> > > > > -
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > > -
> > > > >
> > > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > > >
> > > > >
> > > > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > > > > Explainability `1.22.1.Final`.
> > > > > * This module was removed from the KIE codebase here:
> > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > > and now lives on
> > > > > https://github.com/trustyai-explainability/trustyai-explainability,
> > > > > under a different GAV.
> > > > > * This new repo depends on Kogito and OptaPlanner, pointing to older
> > > > > versions.
> > > > > See:
> > > > > -
> > > > >
> > > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > > -
> > > > >
> > > >
> > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > > >
> > > > >
> > > > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> > > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > > See:
> > > > > -
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > > >
> > > > >
> > > > > P6. Category C repos are out of date and not part of the Category A
> > > > > CI/Release pipelines.
> > > > > * incubator-kie-kogito-benchmarks: (Current version is
> > `2.0-SNAPSHOT`,
> > > > > depending on Kogito without a specific version, only by using
> > > > > `http://localhost:8080`)
> > > > > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > > > > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
> > > > >
> > > > >
> > > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled
> > after
> > > > > upgrading to 999-20240218-SNAPSHOT.
> > > > >
> > > > >
> > > > > In my perspective, P1 and P2 have the same solution, as they both
> > > > > suffer from the circular dependency between Category A and Category
> > B.
> > > > > As Category A and Category B are both streams that have been really
> > > > > active, I see this as a blocker, as there are contributions that
> > > > > cannot be done, given that Category A depends on Category B with a
> > > > > dephasing of 1 release.
> > > > >
> > > > > P3 and P4, although not ideal, can be understood as technical debt.
> > > > > Depending on unmaintained projects is something we'll always be
> > > > > susceptible to, given time.
> > > > >
> > > > > P5 and P6 are easily fixable, as it's just a matter of making them
> > > > > part of the play.
> > > > >
> > > > > P7 is an isolated problem that won't impact the structure or anything
> > > > > that we're talking about here, but it is a regression we introduced
> > > > > recently.
> > > > >
> > > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> > > > > and P7 have easy fixes, the only problems left to discuss are P1 and
> > > > > P2, which can't be done without a proper proposal.
> > > > >
> > > > >
> > > > > # THE PROPOSAL
> > > > >
> > > > > I'll try to be very meticulous here, since from my experience, any
> > > > > little miscalculation can lead to our release not working out in the
> > > > > end. To try and avoid that as much as possible, and make everything
> > we
> > > > > can to have a successful Apache KIE 10 release, bear with me. I'll
> > lay
> > > > > out a timeline of events that need to happen in order for our release
> > > > > to be published, with all artifacts ending up in the right places,
> > but
> > > > > first, we need to solve problems P1 and P2.
> > > > >
> > > > > As you saw at the beginning of this email, all the attempts we made
> > > > > left us with the circular dependency showing up at a different place,
> > > > > but something all these places have in common is that they're all
> > > > > after kogito-apps, and before to Category B.
> > > > >
> > > > > The first part of my proposal is the following:
> > > > >
> > > > > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > > > > `kogito-apps` to `kie-tools`, together with Management and Task
> > > > > consoles from `kogito-images` to `kie-tools`.
> > > > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> > > > > from `kogito-images` to `kie-tools` too.
> > > > > S3. We move the entire `kogito-serverless-operator` repo inside a new
> > > > > package on `kie-tools`, keeping Git history.
> > > > >
> > > > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> > > > > the rest of
> > https://github.com/apache/incubator-kie-issues/issues/967
> > > > > would still be done too.
> > > > >
> > > > > This doesn't come without consequences, of course, as the
> > > > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > > > > `kogito-serverless-operator` would be moving from Category A to
> > > > > Category B. This move would make them have to reference Category A
> > > > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > > > > `kogito-serverless-operator` are already their own "sub-stream"
> > inside
> > > > > Category A, though, contributions made in a cross-repo fashion to
> > this
> > > > > "sub-stream" will continue being possible, now via a single PR to
> > > > > `kie-tools`. Cross-repo PRs between Category A and Category B will
> > > > > continue not being possible, and a 1-week delay between merging
> > > > > something on Category A and using it on Category B will still happen.
> > > > >
> > > > > It's worth mentioning that `kie-tools`, however, does allow for
> > sparse
> > > > > checkouts and partial builds, so working with a subset of the
> > monorepo
> > > > > is possible and encouraged. Making changes only to
> > > > > `packages/kn-plugin-workflow`, for example, will have the PR checks
> > > > > run in < 10 minutes, as you can see here:
> > > > >
> > > > >
> > > >
> > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > > .
> > > > > We're not compromising when running partial builds too. We know that
> > > > > the entire repo will continue working even after only building a
> > small
> > > > > subset of the changes. Doing partial or full builds is automatically
> > > > > determined by the changes of a PR.
> > > > >
> > > > > Keep in mind that, even though I'm proposing we move a bunch of
> > > > > additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> > > > > for our codebase. `kie-tools` would host some additional stuff
> > > > > TEMPORARILY so that we can release and continue moving forward.
> > > > >
> > > > > As I mentioned on other places, `kie-tools` became a polyglot
> > monorepo
> > > > > out of necessity, and although I'm really proud of what we achieved
> > > > > there so far, I don't think `kie-tools` has a setup that is suitable
> > > > > for all the different nuances that compose our community. I'm well
> > > > > aware that a polyglot monorepo that does not follow widespread
> > > > > conventions will scare some people away, and as much as we've tried
> > to
> > > > > make build instructions clear, we can't always get past the prejudice
> > > > > some people have towards the "front-end" ecosystem.
> > > > >
> > > > > With all that said, I keep thinking this is the best course of action
> > > > > for us right now. We keep most of our stuff unchanged, we unblock the
> > > > > release, and we have a working setup that will suit us well while we
> > > > > discuss and reach a conclusion regarding the future of our codebase
> > > > > structure.
> > > > >
> > > > > Let me paint a quick picture here of what our code base would look
> > > > > like, repository-wise, if my proposal is accepted:
> > > > >
> > > > > CATEGORY REPO
> > > > > =====================
> > > > > A incubator-kie-kogito-pipelines
> > > > > A incubator-kie-drools
> > > > > A incubator-kie-optaplanner
> > > > > A incubator-kie-optaplanner-quickstarts
> > > > > A incubator-kie-kogito-runtimes
> > > > > A incubator-kie-kogito-apps
> > > > > A incubator-kie-kogito-examples
> > > > > A incubator-kie-kogito-images
> > > > > A incubator-kie-kogito-docs
> > > > > A incubator-kie-kogito-benchmarks
> > > > > A incubator-kie-docs
> > > > > A incubator-kie-benchmarks
> > > > > =====================
> > > > > B incubator-kie-sandbox-quarkus-accelerator
> > > > > B incubator-kie-tools
> > > > > =====================
> > > > > D incubator-kie-kogito-operator
> > > > > =====================
> > > > > E incubator-kie-issues
> > > > > E incubator-kie-kogito-website
> > > > > E incubator-kie-website
> > > > > E incubator-kie-kogito-online
> > > > > E incubator-kie-kogito-online-staging
> > > > > =====================
> > > > >
> > > > > * Category C becomes part of Category A, and
> > > > > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > > > > * With `kogito-swf-{builder,devmode}` images and
> > > > > `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> > > > > anymore, as inside `kie-tools`, we can granularly build:
> > > > > 1. packages/sonataflow-deployment-webapp
> > > > > 2. packages/sonataflow-quarkus-devui
> > > > > 3. packages/sonataflow-images (containing `kogito-swf-builder`
> > and
> > > > > `kogito-swf-devmode`)
> > > > > 4. packages/sonataflow-operator (contents from
> > > > > `kogito-serverless-operator`)
> > > > > 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> > > > > but renamed)
> > > > >
> > > > > The second part of the proposal is the release process itself,
> > > > > assuming the structure above is what we have.
> > > > >
> > > > > Here it is:
> > > > >
> > > > > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > > > > Category A repos.
> > > > > 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> > > > > verify that everything is working.
> > > > > 3. At this point, with everything working, we can branch out to
> > > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category
> > B
> > > > > from `main`.
> > > > > 4. All Category A and Category B repos update their versions to
> > > > > 10.0.0, in their `10.0.x` branches.
> > > > > 5. Update Category B repos to point to Category A repos using the
> > > > > 10.0.0 version.
> > > > > 6. At this point, we can vote on the release based on the `10.0.x`
> > > > > branches, given we don't expect any code changes anymore.
> > > > > 7. After voting passes, we're good to start the release process.
> > > > > 8. Category A repos follow their manual/automated release process,
> > > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > > > artifacts pushed to their registries.
> > > > > 9. We wait a little bit for Category A artifacts to be propagated on
> > > > > registries. ~1 day.
> > > > > 10. Category B repos follow their manual/automated release process,
> > > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > > > artifacts pushed to their registries.
> > > > > 11. Category D repos are ignored.
> > > > > 12. Category E repos can be manually tagged with 10.0.0 from their
> > > > > default branches.
> > > > >
> > > > > More needs to be discussed if we're planning to maintain multiple
> > > > > release streams in parallel, but I guess it can wait for after Apache
> > > > > KIE 10.
> > > > >
> > > > > Thank you for reading, and I'm looking forward to hearing back from
> > > > > everyone.
> > > > >
> > > > > Of course, alternative solutions are possible. This email, however,
> > > > > summarizes my view of how we should attack the problem, considering
> > > > > disruption, required effort, the release process itself, and history.
> > > > > Feel free to propose alternatives. This is not a voting thread.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Tiago Bento
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Enrique Gonzalez Martinez <eg...@apache.org>.
Parties = two different visions of how to achieve this.
There were two groups of people arguing how to unblock the situation.
I think this was clear for anyone following this thread.
El vie, 15 mar 2024, 18:33, Jason Porter <li...@apache.org> escribió:
> On 2024/03/15 12:25:22 Enrique Gonzalez Martinez wrote:
> > +1 to the short term approach as it seems both parties agree into this.
>
> Out of curiosity, what do you mean by "both parties?" Everyone is a
> contributor, there are no companies within the ASF. We're all one big
> community. What we do may not align 100% with the tactical ideas of any
> downstream company, but at the community level, that shouldn't be the
> driver of things anyway.
>
> > Regarding the long term proposal plz move to another thread before
> someone
> > starts engaging in this thread about a topic is not relevant for
> unblocking
> > the version.
> >
> > El vie, 15 mar 2024, 13:20, Kris Verlaenen <kr...@gmail.com>
> > escribió:
> >
> > > TLDR: A +1 to the proposal from Tiago for the release, with the
> addition of
> > > some short term recommendation (on how to revert some of the temporary
> > > changes) and some perspective on a potential alternative to consider
> for
> > > the long term
> > >
> > > * Short term: The plan from Tiago describes a strategy that appears to
> be
> > > able to solve the build cycle issues we have, allowing us to proceed
> with
> > > the 10.0 release. We do realize that some of the changes that are
> being
> > > done to be able to do the 10.0 release are going to be temporary.
> > > Therefore, as part of this proposal, I urge the team to also document
> how
> > > we are going to revert some of these temporary changes immediately
> after
> > > the release (*). More specifically, my recommendation is that we agree
> > > that the images and operator folder from kie-tools will be removed
> again
> > > and development will continue on the existing repositories. But let’s
> > > discuss if people see this differently or if there might be other
> steps.
> > > The advantage of this approach would be that it allows us to move
> forward
> > > with the release, does buy us time to find a consensus on the long-term
> > > solution and minimizes the impact on the developers regarding temporary
> > > solutions. And it also requires us to find this consensus before the
> next
> > > release.
> > >
> > > * Longer term: as discussed to some degree in this thread already,
> there
> > > seems to be an alternative to explore where we define more strict
> > > boundaries (for dependencies) between repositories, and create a build
> > > chain where images and operator are built after tools. That said, it’s
> > > fair to say that this proposal needs to be worked out and validated
> more,
> > > and initial assessments on the effort related to this, if we don’t
> want to
> > > rush into this and do things right, are indicating this might take
> multiple
> > > months. We also need to discuss how we will be resourcing this effort.
> > > And we could potentially combine this with other discussions that we
> will
> > > have in the near future. So if we agree to investigate this further, I
> > > would like to recommend moving forward with the more concrete temporary
> > > solution that Tiago is proposing for the 10.0 release.
> > >
> > > Note that this would mean that at this point, on this thread, we don’t
> need
> > > to agree on the specifics of any alternative proposal longer-term, we
> can
> > > start a different conversation thread for this. I hope this can
> convince
> > > people to +1 the approach as described by Tiago short term for the
> release,
> > > with the addition of the recipe how to revert some of the temporary
> changes
> > > and the promise to further evaluate longer-term alternatives. For
> those
> > > that are interested, I wanted to also give an indication what this
> proposal
> > > might mean at a high level from my point of view, which is included
> below.
> > >
> > > Thx,
> > > Kris
> > >
> > > [Optional reading] Alternative longer-term proposal
> > >
> > > One could subdivide the work we do in two main streams: one focused
> more on
> > > the runtimes, one focused more on the tooling. In general a lot of
> tooling
> > > can be built independently from the runtime and vice versa, where they
> > > communicate with each other through well defined formats or apis.
> However,
> > > once we start looking at more advanced use cases and the full
> end-to-end,
> > > this is where we need both tooling and runtime together.
> > > The goal is to create one release pipeline(**). The issue with cyclic
> > > dependencies between repos is imho twofold: 1) we haven’t been 100%
> > > consistent in separating runtimes and tooling this way and 2) we
> haven’t
> > > accommodated well for use cases where runtime and tooling needs to be
> > > combined. Note that some of these dependencies might not be build time
> > > dependencies but test and/or runtime dependencies only.
> > > As an alternative to one kie-tools monorepo that combines tooling and
> > > images and operator, I believe we can construct a pipeline where most
> of
> > > runtime and tooling can be built independently, but after runtime and
> > > tooling are built, we complete the build with other
> > > components/repositories, because they logically rely more on both.
> > > Examples of components that rely on both are for example be a devui
> > > extension (a quarkus extension that embeds tooling) or the devmode
> image
> > > (that also includes tooling features), or integration testing (where we
> > > want to test whether tooling and runtime work well together.
> > >
> > > More specifically, this would mean
> > > 1) making sure that there are well-defined boundaries between the core
> > > runtimes and core tooling so they don’t depend on each other at build
> > > time. We can decide to move components around where we think that
> makes
> > > sense, for example:
> > > move ui code related to devui into kie-tools (as discussed before)
> > > move kn-workflow to the operator repository as it more closely related
> to
> > > that
> > > 2) update the CI and release pipelines so that core runtime and tooling
> > > repositories can be built first, and are followed up by other
> repositories
> > > like images and operator, that could then rely on both.
> > >
> > > (*) Note that there would be other options technically to achieve this,
> > > like cutting a release branch early and performing the changes only
> there,
> > > but given other work is still ongoing as well, we want to minimize the
> > > cherry-picking effort.
> > > (**) Note that while the goal is to create one release pipeline, this
> > > should not necessarily mean that we can’t have smaller or optimized
> > > pipelines for CI and daily development, where the impact of changes is
> > > typically more localized.
> > >
> > > On Tue, Mar 12, 2024 at 8:45 PM Tiago Bento <ti...@apache.org>
> wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > Unfortunately, I can't do a tl;dr this time, as this matter requires
> a
> > > > lot of context.
> > > >
> > > > This email will take you < 20 minutes to read, according to
> > > > https://thereadtime.com/.
> > > >
> > > > As you may have followed on a separate thread
> > > > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> > > > many of us were working towards removing a circular dependency
> > > > currently present between `kogito-apps` and `kie-tools`. As we
> > > > progressed towards a solution, we kept finding the circular
> dependency
> > > > pop up somewhere else. I'll do a breakdown of the things we did, and
> > > > the results we had.
> > > >
> > > > Right now, even though we started the effort to move the Quarkus Dev
> > > > UI modules to `kie-tools`, we haven't been able to do it yet, as
> we've
> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> > > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> > > > effort was concluded this Monday, with
> > > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > > >
> > > > The current scenario we have is:
> > > >
> > > > 01. incubator-kie-kogito-runtimes
> > > > |==> 02. incubator-kie-kogito-apps
> > > > C | 03. incubator-kie-kogito-examples
> > > > Y | 04. incubator-kie-kogito-images
> > > > C | 05. incubator-kie-kogito-serverless-operator
> > > > L | ==========================
> > > > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > |==> 07. incubator-kie-tools
> > > >
> > > >
> > > > * As `kie-tools`/extended-services depends on
> > > > `kogito-apps`/jitexecutor;
> > > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> > > > `kie-tools`/{many packages}
> > > >
> > > >
> > > > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> > > >
> > > > 01. incubator-kie-kogito-runtimes
> > > > 02. incubator-kie-kogito-apps
> > > > 03. incubator-kie-kogito-examples
> > > > C |==> 04. incubator-kie-kogito-images
> > > > Y | 05. incubator-kie-kogito-serverless-operator
> > > > C | =====================
> > > > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > E |==> 07. incubator-kie-tools
> > > >
> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > `kogito-images`/kogito-swf-devmode;
> > > > * and `kogito-images`/kogito-swf-devmode depends on
> > > > `kie-tools`/sonataflow-quarkus-devui
> > > >
> > > >
> > > > After moving the `kogito-swf-devmode` image to `kie-tools`, we
> would've
> > > > had:
> > > >
> > > > 01. incubator-kie-kogito-runtimes
> > > > 02. incubator-kie-kogito-apps
> > > > 03. incubator-kie-kogito-examples
> > > > 04. incubator-kie-kogito-images
> > > > C |==> 05. incubator-kie-kogito-serverless-operator
> > > > Y | =====================
> > > > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > L |==> 07. incubator-kie-tools
> > > > E
> > > >
> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > `kogito-serverless-operator`;
> > > > * and `kogito-serverless-operator` depends on
> > > > `kie-tools`/kogito-swf-devmode
> > > >
> > > >
> > > > Clearly, we have a much bigger problem than a simple circular
> dependency.
> > > >
> > > > After multiple conversations with a lot of people, it's been really
> > > > hard coming up with a simple solution that makes it possible to build
> > > > Apache KIE in one shot, while preserving the way everyone is used to
> > > > contributing to the multiple repositories we have. More than that,
> > > > while making this assessment, I found more problems that, in my
> > > > perspective, block Apache KIE 10.
> > > >
> > > > In light of that difficulty, I'm coming forward with my proposal for
> > > > the Apache KIE release process, so we can use Apache's mechanisms to
> > > > have a slower-paced, in-depth debate about this really complicated
> > > > matter.
> > > >
> > > > I'll lay out my entire perspective about the current situation of our
> > > > codebase, as well as problems I can currently see. I'll start with an
> > > > analysis of the repositories and their purposes, point out some
> > > > problems that I believe are blocking our 10 release, explain my
> > > > proposal and discuss some consequences to what I'm proposing.
> > > >
> > > > Let's begin.
> > > >
> > > >
> > > > # THE APACHE KIE REPOS
> > > >
> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > - incubator-kie-drools @ `main`
> > > > - incubator-kie-optaplanner @ `main`
> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > - incubator-kie-kogito-apps @ `main`
> > > > - incubator-kie-kogito-examples @ `main`
> > > > - incubator-kie-kogito-images @ `main`
> > > > - incubator-kie-kogito-serverless-operator @ `main`
> > > > - incubator-kie-kogito-docs @ `main`
> > > > - incubator-kie-docs @ `main-kogito`
> > > >
> > > > B. TOOLS (count: 2)
> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > > - incubator-kie-tools @ `main`
> > > >
> > > > C. BENCHMARKS (count: 2)
> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > - incubator-kie-benchmarks @ `main`
> > > >
> > > > D. ARCHIVED (count: 1)
> > > > - incubator-kie-kogito-operator
> > > >
> > > > E. "NON-CODE" (count: 5)
> > > > - incubator-kie-issues @ `main`
> > > > (Issues only, README should be updated @ `main`. Same for GitHub
> > > > Actions workflows.)
> > > > - incubator-kie-kogito-website @ `main`
> > > > (The Kogito website. Develop & deploy at the `main` branch.)
> > > > - incubator-kie-website @ `main`
> > > > (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> > > > website.)
> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> > > > Extension assets.)
> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > (Same as above, but for manual sanity checks during the staging
> > > > phase of a release.)
> > > >
> > > > TOTAL (count: 21)
> > > >
> > > > I grouped the repositories by category, and listed them in a
> > > > topological order. Keep in mind that when flattening out a tree,
> there
> > > > are multiple possibilities. For example, OptaPlanner could've been
> > > > placed in any position after Drools.
> > > >
> > > > Category A repos are what I've been referring to as `drools` and
> > > > `kogito-*` stream. Of course OptaPlanner is inside that stream, as
> the
> > > > way these repositories reference each other are through Maven
> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This
> mechanism
> > > > is well-known to the team, and although flawed for intra-day builds
> > > > and disruptive for people in many different time zones, it is already
> > > > very comfortable for everyone to work with, I assume.
> > > >
> > > > Contributions made to Category A have some dedicated pipelines, which
> > > > are, at least to some extent, able to build cross-repo PRs together
> > > > and verify that the codebase will continue working as expected after
> > > > they're all merged. From what I could gather, there are some
> > > > "sub-streams" currently configured for cross-repo PRs.
> > > >
> > > > - kogito-pipelines
> > > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > > > - optaplanner, and optaplanner-quickstarts
> > > > - kogito-images, and kogito-serverless-operator
> > > > - kogito-docs
> > > > - kie-docs
> > > >
> > > > This means that sending cross-repo PRs to any combination of repos
> > > > that are not part of the same "sub-stream" cannot be verified before
> > > > merging, making our contribution model dependent on individual
> > > > contributors building stuff on their machines to verify that it
> works.
> > > >
> > > > I based this analysis on
> > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > ,
> > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > ,
> > > > and
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > .
> > > > Note that I'm not that familiar with these pipelines, so please
> > > > someone correct me if I'm wrong.
> > > >
> > > > Category B repos are what I've been referring to as `kie-tools`
> > > > stream. The first repo there is a template repository that is used by
> > > > people starting projects from scratch on KIE Sandbox, similar to a
> > > > Maven archetype, if you will. The other one is the KIE Tools
> monorepo,
> > > > a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> > > > Tools hosts Java libraries and apps, TypeScript libraries and apps,
> Go
> > > > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> > > > configured to work with sparse checkouts and can do partial builds.
> > > > Category B repos refer to Category A repos through timestamped
> > > > SNAPSHOTs. This is a new mechanism we recently introduced that will
> > > > build and publish immutable, persistent artifacts under a version
> > > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> > > > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> > > > releases, as we're now targeting one release for all of Apache KIE,
> so
> > > > we can't have Kogito releases anymore.
> > > >
> > > > An important note here is that Category B repositories have been
> > > > historically kept out of any automations we used to have, way back
> > > > when Kogito started and we had the Business Central (a.k.a. v7)
> stream
> > > > still going on. For this reason, Category B projects have developed
> > > > their own automations, based on GitHub Actions. Category B repos have
> > > > always depended on Category A repos using fixed versions. If Category
> > > > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > > > Category A repositories would've had the potential to break Category
> B
> > > > silently, leaving Category B with a broken development stream, and
> > > > introducing unpleasant surprises for maintainers of Category B repos,
> > > > as historically Category A contributors were not familiar with
> > > > Category B repos.
> > > >
> > > > Contributions made to Category B repos go through a GitHub Actions
> > > > workflow that builds the relevant part of the `kie-tools` monorepo
> for
> > > > the changes introduced. Changes made to the pipeline itself are also
> > > > picked up as part of PRs, allowing us to do things like atomically
> > > > bumping the Node.js version, for example. More importantly, it allows
> > > > us to upgrade the repository to a new timestamped SNAPSHOT together
> > > > with the changes necessary to make it stay green.
> > > >
> > > > This setup, however, makes it impossible to have cross-repo PRs
> > > > involving Category A and Category B simultaneously, with the current
> > > > automations we have.
> > > >
> > > > Category C repos are kind of floating around, and I'm not sure if
> > > > there's much activity going on there. Regardless, as they're part of
> > > > Apache KIE, they will be part of our release, so I listed them for us
> > > > to take them into consideration too.
> > > >
> > > > Category D is self explanatory. There's only one repo that has
> already
> > > > been marked for being archived.
> > > >
> > > > Category E are repos that do not host code directly, and are either
> > > > organizational entities, or host websites, that currently are not
> part
> > > > of any pipelines we have.
> > > >
> > > > This lack of unification between Category A and Category B is, IMHO,
> > > > what allowed us to introduce the infamous circular dependency between
> > > > `kie-tools` and `kogito-apps`, which we now can describe as a
> circular
> > > > dependency between Category A and Category B. The way I see it, if we
> > > > had a single pipeline, building everything from `drools` to
> > > > `kie-tools`, such flaws would've never been introduced, and we
> > > > wouldn't be having this huge problem in our hands right now.
> > > >
> > > > My proposal for the Apache KIE release process sees this lack of
> > > > unification as a central problem, not only for this release in
> > > > particular, but for the community as a whole. It is my belief that we
> > > > are all under the same roof, and that no contribution should be
> > > > allowed to break any part of our codebase. With the increasing volume
> > > > of code, and hopefully number of contributors too, we cannot keep
> > > > counting on "common sense" to avoid breaking things. We're all humans
> > > > after all, and it is our job to have mechanisms in place to prevent
> us
> > > > from unwillingly making mistakes. Especially when these mistakes
> > > > impact on parts of the codebase that we, individually, probably can't
> > > > fix.
> > > >
> > > >
> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > >
> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> > > > `0.32.0`.
> > > > See:
> > > > -
> > > >
> > >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > >
> > > >
> > > > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > > > kiegroup's KIE Tools `0.32.0`.
> > > > See:
> > > > -
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > >
> > > >
> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > See:
> > > > -
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > -
> > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > >
> > > >
> > > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > > > Explainability `1.22.1.Final`.
> > > > * This module was removed from the KIE codebase here:
> > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > and now lives on
> > > > https://github.com/trustyai-explainability/trustyai-explainability,
> > > > under a different GAV.
> > > > * This new repo depends on Kogito and OptaPlanner, pointing to older
> > > > versions.
> > > > See:
> > > > -
> > > >
> > >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > -
> > > >
> > >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > >
> > > >
> > > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > See:
> > > > -
> > > >
> > >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > >
> > > >
> > > > P6. Category C repos are out of date and not part of the Category A
> > > > CI/Release pipelines.
> > > > * incubator-kie-kogito-benchmarks: (Current version is
> `2.0-SNAPSHOT`,
> > > > depending on Kogito without a specific version, only by using
> > > > `http://localhost:8080`)
> > > > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
> > > >
> > > >
> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled
> after
> > > > upgrading to 999-20240218-SNAPSHOT.
> > > >
> > > >
> > > > In my perspective, P1 and P2 have the same solution, as they both
> > > > suffer from the circular dependency between Category A and Category
> B.
> > > > As Category A and Category B are both streams that have been really
> > > > active, I see this as a blocker, as there are contributions that
> > > > cannot be done, given that Category A depends on Category B with a
> > > > dephasing of 1 release.
> > > >
> > > > P3 and P4, although not ideal, can be understood as technical debt.
> > > > Depending on unmaintained projects is something we'll always be
> > > > susceptible to, given time.
> > > >
> > > > P5 and P6 are easily fixable, as it's just a matter of making them
> > > > part of the play.
> > > >
> > > > P7 is an isolated problem that won't impact the structure or anything
> > > > that we're talking about here, but it is a regression we introduced
> > > > recently.
> > > >
> > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> > > > and P7 have easy fixes, the only problems left to discuss are P1 and
> > > > P2, which can't be done without a proper proposal.
> > > >
> > > >
> > > > # THE PROPOSAL
> > > >
> > > > I'll try to be very meticulous here, since from my experience, any
> > > > little miscalculation can lead to our release not working out in the
> > > > end. To try and avoid that as much as possible, and make everything
> we
> > > > can to have a successful Apache KIE 10 release, bear with me. I'll
> lay
> > > > out a timeline of events that need to happen in order for our release
> > > > to be published, with all artifacts ending up in the right places,
> but
> > > > first, we need to solve problems P1 and P2.
> > > >
> > > > As you saw at the beginning of this email, all the attempts we made
> > > > left us with the circular dependency showing up at a different place,
> > > > but something all these places have in common is that they're all
> > > > after kogito-apps, and before to Category B.
> > > >
> > > > The first part of my proposal is the following:
> > > >
> > > > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > > > `kogito-apps` to `kie-tools`, together with Management and Task
> > > > consoles from `kogito-images` to `kie-tools`.
> > > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> > > > from `kogito-images` to `kie-tools` too.
> > > > S3. We move the entire `kogito-serverless-operator` repo inside a new
> > > > package on `kie-tools`, keeping Git history.
> > > >
> > > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> > > > the rest of
> https://github.com/apache/incubator-kie-issues/issues/967
> > > > would still be done too.
> > > >
> > > > This doesn't come without consequences, of course, as the
> > > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > > > `kogito-serverless-operator` would be moving from Category A to
> > > > Category B. This move would make them have to reference Category A
> > > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > > > `kogito-serverless-operator` are already their own "sub-stream"
> inside
> > > > Category A, though, contributions made in a cross-repo fashion to
> this
> > > > "sub-stream" will continue being possible, now via a single PR to
> > > > `kie-tools`. Cross-repo PRs between Category A and Category B will
> > > > continue not being possible, and a 1-week delay between merging
> > > > something on Category A and using it on Category B will still happen.
> > > >
> > > > It's worth mentioning that `kie-tools`, however, does allow for
> sparse
> > > > checkouts and partial builds, so working with a subset of the
> monorepo
> > > > is possible and encouraged. Making changes only to
> > > > `packages/kn-plugin-workflow`, for example, will have the PR checks
> > > > run in < 10 minutes, as you can see here:
> > > >
> > > >
> > >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > .
> > > > We're not compromising when running partial builds too. We know that
> > > > the entire repo will continue working even after only building a
> small
> > > > subset of the changes. Doing partial or full builds is automatically
> > > > determined by the changes of a PR.
> > > >
> > > > Keep in mind that, even though I'm proposing we move a bunch of
> > > > additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> > > > for our codebase. `kie-tools` would host some additional stuff
> > > > TEMPORARILY so that we can release and continue moving forward.
> > > >
> > > > As I mentioned on other places, `kie-tools` became a polyglot
> monorepo
> > > > out of necessity, and although I'm really proud of what we achieved
> > > > there so far, I don't think `kie-tools` has a setup that is suitable
> > > > for all the different nuances that compose our community. I'm well
> > > > aware that a polyglot monorepo that does not follow widespread
> > > > conventions will scare some people away, and as much as we've tried
> to
> > > > make build instructions clear, we can't always get past the prejudice
> > > > some people have towards the "front-end" ecosystem.
> > > >
> > > > With all that said, I keep thinking this is the best course of action
> > > > for us right now. We keep most of our stuff unchanged, we unblock the
> > > > release, and we have a working setup that will suit us well while we
> > > > discuss and reach a conclusion regarding the future of our codebase
> > > > structure.
> > > >
> > > > Let me paint a quick picture here of what our code base would look
> > > > like, repository-wise, if my proposal is accepted:
> > > >
> > > > CATEGORY REPO
> > > > =====================
> > > > A incubator-kie-kogito-pipelines
> > > > A incubator-kie-drools
> > > > A incubator-kie-optaplanner
> > > > A incubator-kie-optaplanner-quickstarts
> > > > A incubator-kie-kogito-runtimes
> > > > A incubator-kie-kogito-apps
> > > > A incubator-kie-kogito-examples
> > > > A incubator-kie-kogito-images
> > > > A incubator-kie-kogito-docs
> > > > A incubator-kie-kogito-benchmarks
> > > > A incubator-kie-docs
> > > > A incubator-kie-benchmarks
> > > > =====================
> > > > B incubator-kie-sandbox-quarkus-accelerator
> > > > B incubator-kie-tools
> > > > =====================
> > > > D incubator-kie-kogito-operator
> > > > =====================
> > > > E incubator-kie-issues
> > > > E incubator-kie-kogito-website
> > > > E incubator-kie-website
> > > > E incubator-kie-kogito-online
> > > > E incubator-kie-kogito-online-staging
> > > > =====================
> > > >
> > > > * Category C becomes part of Category A, and
> > > > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> > > > anymore, as inside `kie-tools`, we can granularly build:
> > > > 1. packages/sonataflow-deployment-webapp
> > > > 2. packages/sonataflow-quarkus-devui
> > > > 3. packages/sonataflow-images (containing `kogito-swf-builder`
> and
> > > > `kogito-swf-devmode`)
> > > > 4. packages/sonataflow-operator (contents from
> > > > `kogito-serverless-operator`)
> > > > 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> > > > but renamed)
> > > >
> > > > The second part of the proposal is the release process itself,
> > > > assuming the structure above is what we have.
> > > >
> > > > Here it is:
> > > >
> > > > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > > > Category A repos.
> > > > 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> > > > verify that everything is working.
> > > > 3. At this point, with everything working, we can branch out to
> > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category
> B
> > > > from `main`.
> > > > 4. All Category A and Category B repos update their versions to
> > > > 10.0.0, in their `10.0.x` branches.
> > > > 5. Update Category B repos to point to Category A repos using the
> > > > 10.0.0 version.
> > > > 6. At this point, we can vote on the release based on the `10.0.x`
> > > > branches, given we don't expect any code changes anymore.
> > > > 7. After voting passes, we're good to start the release process.
> > > > 8. Category A repos follow their manual/automated release process,
> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > > artifacts pushed to their registries.
> > > > 9. We wait a little bit for Category A artifacts to be propagated on
> > > > registries. ~1 day.
> > > > 10. Category B repos follow their manual/automated release process,
> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > > artifacts pushed to their registries.
> > > > 11. Category D repos are ignored.
> > > > 12. Category E repos can be manually tagged with 10.0.0 from their
> > > > default branches.
> > > >
> > > > More needs to be discussed if we're planning to maintain multiple
> > > > release streams in parallel, but I guess it can wait for after Apache
> > > > KIE 10.
> > > >
> > > > Thank you for reading, and I'm looking forward to hearing back from
> > > > everyone.
> > > >
> > > > Of course, alternative solutions are possible. This email, however,
> > > > summarizes my view of how we should attack the problem, considering
> > > > disruption, required effort, the release process itself, and history.
> > > > Feel free to propose alternatives. This is not a voting thread.
> > > >
> > > > Regards,
> > > >
> > > > Tiago Bento
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Jason Porter <li...@apache.org>.
On 2024/03/15 12:25:22 Enrique Gonzalez Martinez wrote:
> +1 to the short term approach as it seems both parties agree into this.
Out of curiosity, what do you mean by "both parties?" Everyone is a contributor, there are no companies within the ASF. We're all one big community. What we do may not align 100% with the tactical ideas of any downstream company, but at the community level, that shouldn't be the driver of things anyway.
> Regarding the long term proposal plz move to another thread before someone
> starts engaging in this thread about a topic is not relevant for unblocking
> the version.
>
> El vie, 15 mar 2024, 13:20, Kris Verlaenen <kr...@gmail.com>
> escribió:
>
> > TLDR: A +1 to the proposal from Tiago for the release, with the addition of
> > some short term recommendation (on how to revert some of the temporary
> > changes) and some perspective on a potential alternative to consider for
> > the long term
> >
> > * Short term: The plan from Tiago describes a strategy that appears to be
> > able to solve the build cycle issues we have, allowing us to proceed with
> > the 10.0 release. We do realize that some of the changes that are being
> > done to be able to do the 10.0 release are going to be temporary.
> > Therefore, as part of this proposal, I urge the team to also document how
> > we are going to revert some of these temporary changes immediately after
> > the release (*). More specifically, my recommendation is that we agree
> > that the images and operator folder from kie-tools will be removed again
> > and development will continue on the existing repositories. But let’s
> > discuss if people see this differently or if there might be other steps.
> > The advantage of this approach would be that it allows us to move forward
> > with the release, does buy us time to find a consensus on the long-term
> > solution and minimizes the impact on the developers regarding temporary
> > solutions. And it also requires us to find this consensus before the next
> > release.
> >
> > * Longer term: as discussed to some degree in this thread already, there
> > seems to be an alternative to explore where we define more strict
> > boundaries (for dependencies) between repositories, and create a build
> > chain where images and operator are built after tools. That said, it’s
> > fair to say that this proposal needs to be worked out and validated more,
> > and initial assessments on the effort related to this, if we don’t want to
> > rush into this and do things right, are indicating this might take multiple
> > months. We also need to discuss how we will be resourcing this effort.
> > And we could potentially combine this with other discussions that we will
> > have in the near future. So if we agree to investigate this further, I
> > would like to recommend moving forward with the more concrete temporary
> > solution that Tiago is proposing for the 10.0 release.
> >
> > Note that this would mean that at this point, on this thread, we don’t need
> > to agree on the specifics of any alternative proposal longer-term, we can
> > start a different conversation thread for this. I hope this can convince
> > people to +1 the approach as described by Tiago short term for the release,
> > with the addition of the recipe how to revert some of the temporary changes
> > and the promise to further evaluate longer-term alternatives. For those
> > that are interested, I wanted to also give an indication what this proposal
> > might mean at a high level from my point of view, which is included below.
> >
> > Thx,
> > Kris
> >
> > [Optional reading] Alternative longer-term proposal
> >
> > One could subdivide the work we do in two main streams: one focused more on
> > the runtimes, one focused more on the tooling. In general a lot of tooling
> > can be built independently from the runtime and vice versa, where they
> > communicate with each other through well defined formats or apis. However,
> > once we start looking at more advanced use cases and the full end-to-end,
> > this is where we need both tooling and runtime together.
> > The goal is to create one release pipeline(**). The issue with cyclic
> > dependencies between repos is imho twofold: 1) we haven’t been 100%
> > consistent in separating runtimes and tooling this way and 2) we haven’t
> > accommodated well for use cases where runtime and tooling needs to be
> > combined. Note that some of these dependencies might not be build time
> > dependencies but test and/or runtime dependencies only.
> > As an alternative to one kie-tools monorepo that combines tooling and
> > images and operator, I believe we can construct a pipeline where most of
> > runtime and tooling can be built independently, but after runtime and
> > tooling are built, we complete the build with other
> > components/repositories, because they logically rely more on both.
> > Examples of components that rely on both are for example be a devui
> > extension (a quarkus extension that embeds tooling) or the devmode image
> > (that also includes tooling features), or integration testing (where we
> > want to test whether tooling and runtime work well together.
> >
> > More specifically, this would mean
> > 1) making sure that there are well-defined boundaries between the core
> > runtimes and core tooling so they don’t depend on each other at build
> > time. We can decide to move components around where we think that makes
> > sense, for example:
> > move ui code related to devui into kie-tools (as discussed before)
> > move kn-workflow to the operator repository as it more closely related to
> > that
> > 2) update the CI and release pipelines so that core runtime and tooling
> > repositories can be built first, and are followed up by other repositories
> > like images and operator, that could then rely on both.
> >
> > (*) Note that there would be other options technically to achieve this,
> > like cutting a release branch early and performing the changes only there,
> > but given other work is still ongoing as well, we want to minimize the
> > cherry-picking effort.
> > (**) Note that while the goal is to create one release pipeline, this
> > should not necessarily mean that we can’t have smaller or optimized
> > pipelines for CI and daily development, where the impact of changes is
> > typically more localized.
> >
> > On Tue, Mar 12, 2024 at 8:45 PM Tiago Bento <ti...@apache.org> wrote:
> >
> > > Hi everyone,
> > >
> > > Unfortunately, I can't do a tl;dr this time, as this matter requires a
> > > lot of context.
> > >
> > > This email will take you < 20 minutes to read, according to
> > > https://thereadtime.com/.
> > >
> > > As you may have followed on a separate thread
> > > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> > > many of us were working towards removing a circular dependency
> > > currently present between `kogito-apps` and `kie-tools`. As we
> > > progressed towards a solution, we kept finding the circular dependency
> > > pop up somewhere else. I'll do a breakdown of the things we did, and
> > > the results we had.
> > >
> > > Right now, even though we started the effort to move the Quarkus Dev
> > > UI modules to `kie-tools`, we haven't been able to do it yet, as we've
> > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> > > effort was concluded this Monday, with
> > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > >
> > > The current scenario we have is:
> > >
> > > 01. incubator-kie-kogito-runtimes
> > > |==> 02. incubator-kie-kogito-apps
> > > C | 03. incubator-kie-kogito-examples
> > > Y | 04. incubator-kie-kogito-images
> > > C | 05. incubator-kie-kogito-serverless-operator
> > > L | ==========================
> > > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > > |==> 07. incubator-kie-tools
> > >
> > >
> > > * As `kie-tools`/extended-services depends on
> > > `kogito-apps`/jitexecutor;
> > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> > > `kie-tools`/{many packages}
> > >
> > >
> > > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> > >
> > > 01. incubator-kie-kogito-runtimes
> > > 02. incubator-kie-kogito-apps
> > > 03. incubator-kie-kogito-examples
> > > C |==> 04. incubator-kie-kogito-images
> > > Y | 05. incubator-kie-kogito-serverless-operator
> > > C | =====================
> > > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > > E |==> 07. incubator-kie-tools
> > >
> > > * As `kie-tools`/kn-plugin-workflow depends on
> > > `kogito-images`/kogito-swf-devmode;
> > > * and `kogito-images`/kogito-swf-devmode depends on
> > > `kie-tools`/sonataflow-quarkus-devui
> > >
> > >
> > > After moving the `kogito-swf-devmode` image to `kie-tools`, we would've
> > > had:
> > >
> > > 01. incubator-kie-kogito-runtimes
> > > 02. incubator-kie-kogito-apps
> > > 03. incubator-kie-kogito-examples
> > > 04. incubator-kie-kogito-images
> > > C |==> 05. incubator-kie-kogito-serverless-operator
> > > Y | =====================
> > > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > > L |==> 07. incubator-kie-tools
> > > E
> > >
> > > * As `kie-tools`/kn-plugin-workflow depends on
> > > `kogito-serverless-operator`;
> > > * and `kogito-serverless-operator` depends on
> > > `kie-tools`/kogito-swf-devmode
> > >
> > >
> > > Clearly, we have a much bigger problem than a simple circular dependency.
> > >
> > > After multiple conversations with a lot of people, it's been really
> > > hard coming up with a simple solution that makes it possible to build
> > > Apache KIE in one shot, while preserving the way everyone is used to
> > > contributing to the multiple repositories we have. More than that,
> > > while making this assessment, I found more problems that, in my
> > > perspective, block Apache KIE 10.
> > >
> > > In light of that difficulty, I'm coming forward with my proposal for
> > > the Apache KIE release process, so we can use Apache's mechanisms to
> > > have a slower-paced, in-depth debate about this really complicated
> > > matter.
> > >
> > > I'll lay out my entire perspective about the current situation of our
> > > codebase, as well as problems I can currently see. I'll start with an
> > > analysis of the repositories and their purposes, point out some
> > > problems that I believe are blocking our 10 release, explain my
> > > proposal and discuss some consequences to what I'm proposing.
> > >
> > > Let's begin.
> > >
> > >
> > > # THE APACHE KIE REPOS
> > >
> > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > - incubator-kie-kogito-pipelines @ `main`
> > > - incubator-kie-drools @ `main`
> > > - incubator-kie-optaplanner @ `main`
> > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > - incubator-kie-kogito-runtimes @ `main`
> > > - incubator-kie-kogito-apps @ `main`
> > > - incubator-kie-kogito-examples @ `main`
> > > - incubator-kie-kogito-images @ `main`
> > > - incubator-kie-kogito-serverless-operator @ `main`
> > > - incubator-kie-kogito-docs @ `main`
> > > - incubator-kie-docs @ `main-kogito`
> > >
> > > B. TOOLS (count: 2)
> > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > - incubator-kie-tools @ `main`
> > >
> > > C. BENCHMARKS (count: 2)
> > > - incubator-kie-kogito-benchmarks @ `main`
> > > - incubator-kie-benchmarks @ `main`
> > >
> > > D. ARCHIVED (count: 1)
> > > - incubator-kie-kogito-operator
> > >
> > > E. "NON-CODE" (count: 5)
> > > - incubator-kie-issues @ `main`
> > > (Issues only, README should be updated @ `main`. Same for GitHub
> > > Actions workflows.)
> > > - incubator-kie-kogito-website @ `main`
> > > (The Kogito website. Develop & deploy at the `main` branch.)
> > > - incubator-kie-website @ `main`
> > > (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> > > website.)
> > > - incubator-kie-kogito-online @ `gh-pages`
> > > (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> > > Extension assets.)
> > > - incubator-kie-kogito-online-staging @ `main`
> > > (Same as above, but for manual sanity checks during the staging
> > > phase of a release.)
> > >
> > > TOTAL (count: 21)
> > >
> > > I grouped the repositories by category, and listed them in a
> > > topological order. Keep in mind that when flattening out a tree, there
> > > are multiple possibilities. For example, OptaPlanner could've been
> > > placed in any position after Drools.
> > >
> > > Category A repos are what I've been referring to as `drools` and
> > > `kogito-*` stream. Of course OptaPlanner is inside that stream, as the
> > > way these repositories reference each other are through Maven
> > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This mechanism
> > > is well-known to the team, and although flawed for intra-day builds
> > > and disruptive for people in many different time zones, it is already
> > > very comfortable for everyone to work with, I assume.
> > >
> > > Contributions made to Category A have some dedicated pipelines, which
> > > are, at least to some extent, able to build cross-repo PRs together
> > > and verify that the codebase will continue working as expected after
> > > they're all merged. From what I could gather, there are some
> > > "sub-streams" currently configured for cross-repo PRs.
> > >
> > > - kogito-pipelines
> > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > > - optaplanner, and optaplanner-quickstarts
> > > - kogito-images, and kogito-serverless-operator
> > > - kogito-docs
> > > - kie-docs
> > >
> > > This means that sending cross-repo PRs to any combination of repos
> > > that are not part of the same "sub-stream" cannot be verified before
> > > merging, making our contribution model dependent on individual
> > > contributors building stuff on their machines to verify that it works.
> > >
> > > I based this analysis on
> > >
> > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > ,
> > >
> > >
> > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > ,
> > > and
> > >
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > .
> > > Note that I'm not that familiar with these pipelines, so please
> > > someone correct me if I'm wrong.
> > >
> > > Category B repos are what I've been referring to as `kie-tools`
> > > stream. The first repo there is a template repository that is used by
> > > people starting projects from scratch on KIE Sandbox, similar to a
> > > Maven archetype, if you will. The other one is the KIE Tools monorepo,
> > > a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> > > Tools hosts Java libraries and apps, TypeScript libraries and apps, Go
> > > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> > > configured to work with sparse checkouts and can do partial builds.
> > > Category B repos refer to Category A repos through timestamped
> > > SNAPSHOTs. This is a new mechanism we recently introduced that will
> > > build and publish immutable, persistent artifacts under a version
> > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> > > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> > > releases, as we're now targeting one release for all of Apache KIE, so
> > > we can't have Kogito releases anymore.
> > >
> > > An important note here is that Category B repositories have been
> > > historically kept out of any automations we used to have, way back
> > > when Kogito started and we had the Business Central (a.k.a. v7) stream
> > > still going on. For this reason, Category B projects have developed
> > > their own automations, based on GitHub Actions. Category B repos have
> > > always depended on Category A repos using fixed versions. If Category
> > > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > > Category A repositories would've had the potential to break Category B
> > > silently, leaving Category B with a broken development stream, and
> > > introducing unpleasant surprises for maintainers of Category B repos,
> > > as historically Category A contributors were not familiar with
> > > Category B repos.
> > >
> > > Contributions made to Category B repos go through a GitHub Actions
> > > workflow that builds the relevant part of the `kie-tools` monorepo for
> > > the changes introduced. Changes made to the pipeline itself are also
> > > picked up as part of PRs, allowing us to do things like atomically
> > > bumping the Node.js version, for example. More importantly, it allows
> > > us to upgrade the repository to a new timestamped SNAPSHOT together
> > > with the changes necessary to make it stay green.
> > >
> > > This setup, however, makes it impossible to have cross-repo PRs
> > > involving Category A and Category B simultaneously, with the current
> > > automations we have.
> > >
> > > Category C repos are kind of floating around, and I'm not sure if
> > > there's much activity going on there. Regardless, as they're part of
> > > Apache KIE, they will be part of our release, so I listed them for us
> > > to take them into consideration too.
> > >
> > > Category D is self explanatory. There's only one repo that has already
> > > been marked for being archived.
> > >
> > > Category E are repos that do not host code directly, and are either
> > > organizational entities, or host websites, that currently are not part
> > > of any pipelines we have.
> > >
> > > This lack of unification between Category A and Category B is, IMHO,
> > > what allowed us to introduce the infamous circular dependency between
> > > `kie-tools` and `kogito-apps`, which we now can describe as a circular
> > > dependency between Category A and Category B. The way I see it, if we
> > > had a single pipeline, building everything from `drools` to
> > > `kie-tools`, such flaws would've never been introduced, and we
> > > wouldn't be having this huge problem in our hands right now.
> > >
> > > My proposal for the Apache KIE release process sees this lack of
> > > unification as a central problem, not only for this release in
> > > particular, but for the community as a whole. It is my belief that we
> > > are all under the same roof, and that no contribution should be
> > > allowed to break any part of our codebase. With the increasing volume
> > > of code, and hopefully number of contributors too, we cannot keep
> > > counting on "common sense" to avoid breaking things. We're all humans
> > > after all, and it is our job to have mechanisms in place to prevent us
> > > from unwillingly making mistakes. Especially when these mistakes
> > > impact on parts of the codebase that we, individually, probably can't
> > > fix.
> > >
> > >
> > > # THE PROBLEMS WE HAVE RIGHT NOW
> > >
> > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> > > `0.32.0`.
> > > See:
> > > -
> > >
> > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > >
> > >
> > > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > > kiegroup's KIE Tools `0.32.0`.
> > > See:
> > > -
> > >
> > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > >
> > >
> > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > See:
> > > -
> > >
> > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > -
> > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > >
> > >
> > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > > Explainability `1.22.1.Final`.
> > > * This module was removed from the KIE codebase here:
> > >
> > >
> > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > and now lives on
> > > https://github.com/trustyai-explainability/trustyai-explainability,
> > > under a different GAV.
> > > * This new repo depends on Kogito and OptaPlanner, pointing to older
> > > versions.
> > > See:
> > > -
> > >
> > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > -
> > >
> > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > >
> > >
> > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > See:
> > > -
> > >
> > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > >
> > >
> > > P6. Category C repos are out of date and not part of the Category A
> > > CI/Release pipelines.
> > > * incubator-kie-kogito-benchmarks: (Current version is `2.0-SNAPSHOT`,
> > > depending on Kogito without a specific version, only by using
> > > `http://localhost:8080`)
> > > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
> > >
> > >
> > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled after
> > > upgrading to 999-20240218-SNAPSHOT.
> > >
> > >
> > > In my perspective, P1 and P2 have the same solution, as they both
> > > suffer from the circular dependency between Category A and Category B.
> > > As Category A and Category B are both streams that have been really
> > > active, I see this as a blocker, as there are contributions that
> > > cannot be done, given that Category A depends on Category B with a
> > > dephasing of 1 release.
> > >
> > > P3 and P4, although not ideal, can be understood as technical debt.
> > > Depending on unmaintained projects is something we'll always be
> > > susceptible to, given time.
> > >
> > > P5 and P6 are easily fixable, as it's just a matter of making them
> > > part of the play.
> > >
> > > P7 is an isolated problem that won't impact the structure or anything
> > > that we're talking about here, but it is a regression we introduced
> > > recently.
> > >
> > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> > > and P7 have easy fixes, the only problems left to discuss are P1 and
> > > P2, which can't be done without a proper proposal.
> > >
> > >
> > > # THE PROPOSAL
> > >
> > > I'll try to be very meticulous here, since from my experience, any
> > > little miscalculation can lead to our release not working out in the
> > > end. To try and avoid that as much as possible, and make everything we
> > > can to have a successful Apache KIE 10 release, bear with me. I'll lay
> > > out a timeline of events that need to happen in order for our release
> > > to be published, with all artifacts ending up in the right places, but
> > > first, we need to solve problems P1 and P2.
> > >
> > > As you saw at the beginning of this email, all the attempts we made
> > > left us with the circular dependency showing up at a different place,
> > > but something all these places have in common is that they're all
> > > after kogito-apps, and before to Category B.
> > >
> > > The first part of my proposal is the following:
> > >
> > > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > > `kogito-apps` to `kie-tools`, together with Management and Task
> > > consoles from `kogito-images` to `kie-tools`.
> > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> > > from `kogito-images` to `kie-tools` too.
> > > S3. We move the entire `kogito-serverless-operator` repo inside a new
> > > package on `kie-tools`, keeping Git history.
> > >
> > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> > > the rest of https://github.com/apache/incubator-kie-issues/issues/967
> > > would still be done too.
> > >
> > > This doesn't come without consequences, of course, as the
> > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > > `kogito-serverless-operator` would be moving from Category A to
> > > Category B. This move would make them have to reference Category A
> > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > > `kogito-serverless-operator` are already their own "sub-stream" inside
> > > Category A, though, contributions made in a cross-repo fashion to this
> > > "sub-stream" will continue being possible, now via a single PR to
> > > `kie-tools`. Cross-repo PRs between Category A and Category B will
> > > continue not being possible, and a 1-week delay between merging
> > > something on Category A and using it on Category B will still happen.
> > >
> > > It's worth mentioning that `kie-tools`, however, does allow for sparse
> > > checkouts and partial builds, so working with a subset of the monorepo
> > > is possible and encouraged. Making changes only to
> > > `packages/kn-plugin-workflow`, for example, will have the PR checks
> > > run in < 10 minutes, as you can see here:
> > >
> > >
> > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > .
> > > We're not compromising when running partial builds too. We know that
> > > the entire repo will continue working even after only building a small
> > > subset of the changes. Doing partial or full builds is automatically
> > > determined by the changes of a PR.
> > >
> > > Keep in mind that, even though I'm proposing we move a bunch of
> > > additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> > > for our codebase. `kie-tools` would host some additional stuff
> > > TEMPORARILY so that we can release and continue moving forward.
> > >
> > > As I mentioned on other places, `kie-tools` became a polyglot monorepo
> > > out of necessity, and although I'm really proud of what we achieved
> > > there so far, I don't think `kie-tools` has a setup that is suitable
> > > for all the different nuances that compose our community. I'm well
> > > aware that a polyglot monorepo that does not follow widespread
> > > conventions will scare some people away, and as much as we've tried to
> > > make build instructions clear, we can't always get past the prejudice
> > > some people have towards the "front-end" ecosystem.
> > >
> > > With all that said, I keep thinking this is the best course of action
> > > for us right now. We keep most of our stuff unchanged, we unblock the
> > > release, and we have a working setup that will suit us well while we
> > > discuss and reach a conclusion regarding the future of our codebase
> > > structure.
> > >
> > > Let me paint a quick picture here of what our code base would look
> > > like, repository-wise, if my proposal is accepted:
> > >
> > > CATEGORY REPO
> > > =====================
> > > A incubator-kie-kogito-pipelines
> > > A incubator-kie-drools
> > > A incubator-kie-optaplanner
> > > A incubator-kie-optaplanner-quickstarts
> > > A incubator-kie-kogito-runtimes
> > > A incubator-kie-kogito-apps
> > > A incubator-kie-kogito-examples
> > > A incubator-kie-kogito-images
> > > A incubator-kie-kogito-docs
> > > A incubator-kie-kogito-benchmarks
> > > A incubator-kie-docs
> > > A incubator-kie-benchmarks
> > > =====================
> > > B incubator-kie-sandbox-quarkus-accelerator
> > > B incubator-kie-tools
> > > =====================
> > > D incubator-kie-kogito-operator
> > > =====================
> > > E incubator-kie-issues
> > > E incubator-kie-kogito-website
> > > E incubator-kie-website
> > > E incubator-kie-kogito-online
> > > E incubator-kie-kogito-online-staging
> > > =====================
> > >
> > > * Category C becomes part of Category A, and
> > > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > > * With `kogito-swf-{builder,devmode}` images and
> > > `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> > > anymore, as inside `kie-tools`, we can granularly build:
> > > 1. packages/sonataflow-deployment-webapp
> > > 2. packages/sonataflow-quarkus-devui
> > > 3. packages/sonataflow-images (containing `kogito-swf-builder` and
> > > `kogito-swf-devmode`)
> > > 4. packages/sonataflow-operator (contents from
> > > `kogito-serverless-operator`)
> > > 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> > > but renamed)
> > >
> > > The second part of the proposal is the release process itself,
> > > assuming the structure above is what we have.
> > >
> > > Here it is:
> > >
> > > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > > Category A repos.
> > > 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> > > verify that everything is working.
> > > 3. At this point, with everything working, we can branch out to
> > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
> > > from `main`.
> > > 4. All Category A and Category B repos update their versions to
> > > 10.0.0, in their `10.0.x` branches.
> > > 5. Update Category B repos to point to Category A repos using the
> > > 10.0.0 version.
> > > 6. At this point, we can vote on the release based on the `10.0.x`
> > > branches, given we don't expect any code changes anymore.
> > > 7. After voting passes, we're good to start the release process.
> > > 8. Category A repos follow their manual/automated release process,
> > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > artifacts pushed to their registries.
> > > 9. We wait a little bit for Category A artifacts to be propagated on
> > > registries. ~1 day.
> > > 10. Category B repos follow their manual/automated release process,
> > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > artifacts pushed to their registries.
> > > 11. Category D repos are ignored.
> > > 12. Category E repos can be manually tagged with 10.0.0 from their
> > > default branches.
> > >
> > > More needs to be discussed if we're planning to maintain multiple
> > > release streams in parallel, but I guess it can wait for after Apache
> > > KIE 10.
> > >
> > > Thank you for reading, and I'm looking forward to hearing back from
> > > everyone.
> > >
> > > Of course, alternative solutions are possible. This email, however,
> > > summarizes my view of how we should attack the problem, considering
> > > disruption, required effort, the release process itself, and history.
> > > Feel free to propose alternatives. This is not a voting thread.
> > >
> > > Regards,
> > >
> > > Tiago Bento
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Eder Ignatowicz <ig...@gmail.com>.
I give +1 for the proposal and to discuss the strategy to revert into a new
thread.
_____________
Eder Ignatowicz
ignatowicz@gmail.com
On Fri, Mar 15, 2024 at 8:35 AM Alex Porcelli <po...@apache.org> wrote:
> +1 on the proposal adding to it the details needed for the revert changes
> post 10
>
> +1 to start new thread to discuss anything other than this proposal
>
> On Fri, Mar 15, 2024 at 8:25 AM Enrique Gonzalez Martinez <
> egonzalez@apache.org> wrote:
>
> > +1 to the short term approach as it seems both parties agree into this.
> >
> > Regarding the long term proposal plz move to another thread before
> someone
> > starts engaging in this thread about a topic is not relevant for
> unblocking
> > the version.
> >
> > El vie, 15 mar 2024, 13:20, Kris Verlaenen <kr...@gmail.com>
> > escribió:
> >
> > > TLDR: A +1 to the proposal from Tiago for the release, with the
> addition
> > of
> > > some short term recommendation (on how to revert some of the temporary
> > > changes) and some perspective on a potential alternative to consider
> for
> > > the long term
> > >
> > > * Short term: The plan from Tiago describes a strategy that appears to
> be
> > > able to solve the build cycle issues we have, allowing us to proceed
> with
> > > the 10.0 release. We do realize that some of the changes that are
> being
> > > done to be able to do the 10.0 release are going to be temporary.
> > > Therefore, as part of this proposal, I urge the team to also document
> how
> > > we are going to revert some of these temporary changes immediately
> after
> > > the release (*). More specifically, my recommendation is that we agree
> > > that the images and operator folder from kie-tools will be removed
> again
> > > and development will continue on the existing repositories. But let’s
> > > discuss if people see this differently or if there might be other
> steps.
> > > The advantage of this approach would be that it allows us to move
> forward
> > > with the release, does buy us time to find a consensus on the long-term
> > > solution and minimizes the impact on the developers regarding temporary
> > > solutions. And it also requires us to find this consensus before the
> > next
> > > release.
> > >
> > > * Longer term: as discussed to some degree in this thread already,
> there
> > > seems to be an alternative to explore where we define more strict
> > > boundaries (for dependencies) between repositories, and create a build
> > > chain where images and operator are built after tools. That said, it’s
> > > fair to say that this proposal needs to be worked out and validated
> more,
> > > and initial assessments on the effort related to this, if we don’t want
> > to
> > > rush into this and do things right, are indicating this might take
> > multiple
> > > months. We also need to discuss how we will be resourcing this effort.
> > > And we could potentially combine this with other discussions that we
> will
> > > have in the near future. So if we agree to investigate this further, I
> > > would like to recommend moving forward with the more concrete temporary
> > > solution that Tiago is proposing for the 10.0 release.
> > >
> > > Note that this would mean that at this point, on this thread, we don’t
> > need
> > > to agree on the specifics of any alternative proposal longer-term, we
> can
> > > start a different conversation thread for this. I hope this can
> convince
> > > people to +1 the approach as described by Tiago short term for the
> > release,
> > > with the addition of the recipe how to revert some of the temporary
> > changes
> > > and the promise to further evaluate longer-term alternatives. For
> those
> > > that are interested, I wanted to also give an indication what this
> > proposal
> > > might mean at a high level from my point of view, which is included
> > below.
> > >
> > > Thx,
> > > Kris
> > >
> > > [Optional reading] Alternative longer-term proposal
> > >
> > > One could subdivide the work we do in two main streams: one focused
> more
> > on
> > > the runtimes, one focused more on the tooling. In general a lot of
> > tooling
> > > can be built independently from the runtime and vice versa, where they
> > > communicate with each other through well defined formats or apis.
> > However,
> > > once we start looking at more advanced use cases and the full
> end-to-end,
> > > this is where we need both tooling and runtime together.
> > > The goal is to create one release pipeline(**). The issue with cyclic
> > > dependencies between repos is imho twofold: 1) we haven’t been 100%
> > > consistent in separating runtimes and tooling this way and 2) we
> haven’t
> > > accommodated well for use cases where runtime and tooling needs to be
> > > combined. Note that some of these dependencies might not be build time
> > > dependencies but test and/or runtime dependencies only.
> > > As an alternative to one kie-tools monorepo that combines tooling and
> > > images and operator, I believe we can construct a pipeline where most
> of
> > > runtime and tooling can be built independently, but after runtime and
> > > tooling are built, we complete the build with other
> > > components/repositories, because they logically rely more on both.
> > > Examples of components that rely on both are for example be a devui
> > > extension (a quarkus extension that embeds tooling) or the devmode
> image
> > > (that also includes tooling features), or integration testing (where we
> > > want to test whether tooling and runtime work well together.
> > >
> > > More specifically, this would mean
> > > 1) making sure that there are well-defined boundaries between the core
> > > runtimes and core tooling so they don’t depend on each other at build
> > > time. We can decide to move components around where we think that
> makes
> > > sense, for example:
> > > move ui code related to devui into kie-tools (as discussed before)
> > > move kn-workflow to the operator repository as it more closely related
> to
> > > that
> > > 2) update the CI and release pipelines so that core runtime and tooling
> > > repositories can be built first, and are followed up by other
> > repositories
> > > like images and operator, that could then rely on both.
> > >
> > > (*) Note that there would be other options technically to achieve this,
> > > like cutting a release branch early and performing the changes only
> > there,
> > > but given other work is still ongoing as well, we want to minimize the
> > > cherry-picking effort.
> > > (**) Note that while the goal is to create one release pipeline, this
> > > should not necessarily mean that we can’t have smaller or optimized
> > > pipelines for CI and daily development, where the impact of changes is
> > > typically more localized.
> > >
> > > On Tue, Mar 12, 2024 at 8:45 PM Tiago Bento <ti...@apache.org>
> > wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > Unfortunately, I can't do a tl;dr this time, as this matter requires
> a
> > > > lot of context.
> > > >
> > > > This email will take you < 20 minutes to read, according to
> > > > https://thereadtime.com/.
> > > >
> > > > As you may have followed on a separate thread
> > > > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> > > > many of us were working towards removing a circular dependency
> > > > currently present between `kogito-apps` and `kie-tools`. As we
> > > > progressed towards a solution, we kept finding the circular
> dependency
> > > > pop up somewhere else. I'll do a breakdown of the things we did, and
> > > > the results we had.
> > > >
> > > > Right now, even though we started the effort to move the Quarkus Dev
> > > > UI modules to `kie-tools`, we haven't been able to do it yet, as
> we've
> > > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> > > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> > > > effort was concluded this Monday, with
> > > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > > >
> > > > The current scenario we have is:
> > > >
> > > > 01. incubator-kie-kogito-runtimes
> > > > |==> 02. incubator-kie-kogito-apps
> > > > C | 03. incubator-kie-kogito-examples
> > > > Y | 04. incubator-kie-kogito-images
> > > > C | 05. incubator-kie-kogito-serverless-operator
> > > > L | ==========================
> > > > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > |==> 07. incubator-kie-tools
> > > >
> > > >
> > > > * As `kie-tools`/extended-services depends on
> > > > `kogito-apps`/jitexecutor;
> > > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> > > > `kie-tools`/{many packages}
> > > >
> > > >
> > > > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> > > >
> > > > 01. incubator-kie-kogito-runtimes
> > > > 02. incubator-kie-kogito-apps
> > > > 03. incubator-kie-kogito-examples
> > > > C |==> 04. incubator-kie-kogito-images
> > > > Y | 05. incubator-kie-kogito-serverless-operator
> > > > C | =====================
> > > > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > E |==> 07. incubator-kie-tools
> > > >
> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > `kogito-images`/kogito-swf-devmode;
> > > > * and `kogito-images`/kogito-swf-devmode depends on
> > > > `kie-tools`/sonataflow-quarkus-devui
> > > >
> > > >
> > > > After moving the `kogito-swf-devmode` image to `kie-tools`, we
> would've
> > > > had:
> > > >
> > > > 01. incubator-kie-kogito-runtimes
> > > > 02. incubator-kie-kogito-apps
> > > > 03. incubator-kie-kogito-examples
> > > > 04. incubator-kie-kogito-images
> > > > C |==> 05. incubator-kie-kogito-serverless-operator
> > > > Y | =====================
> > > > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > > > L |==> 07. incubator-kie-tools
> > > > E
> > > >
> > > > * As `kie-tools`/kn-plugin-workflow depends on
> > > > `kogito-serverless-operator`;
> > > > * and `kogito-serverless-operator` depends on
> > > > `kie-tools`/kogito-swf-devmode
> > > >
> > > >
> > > > Clearly, we have a much bigger problem than a simple circular
> > dependency.
> > > >
> > > > After multiple conversations with a lot of people, it's been really
> > > > hard coming up with a simple solution that makes it possible to build
> > > > Apache KIE in one shot, while preserving the way everyone is used to
> > > > contributing to the multiple repositories we have. More than that,
> > > > while making this assessment, I found more problems that, in my
> > > > perspective, block Apache KIE 10.
> > > >
> > > > In light of that difficulty, I'm coming forward with my proposal for
> > > > the Apache KIE release process, so we can use Apache's mechanisms to
> > > > have a slower-paced, in-depth debate about this really complicated
> > > > matter.
> > > >
> > > > I'll lay out my entire perspective about the current situation of our
> > > > codebase, as well as problems I can currently see. I'll start with an
> > > > analysis of the repositories and their purposes, point out some
> > > > problems that I believe are blocking our 10 release, explain my
> > > > proposal and discuss some consequences to what I'm proposing.
> > > >
> > > > Let's begin.
> > > >
> > > >
> > > > # THE APACHE KIE REPOS
> > > >
> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > > - incubator-kie-kogito-pipelines @ `main`
> > > > - incubator-kie-drools @ `main`
> > > > - incubator-kie-optaplanner @ `main`
> > > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > > - incubator-kie-kogito-runtimes @ `main`
> > > > - incubator-kie-kogito-apps @ `main`
> > > > - incubator-kie-kogito-examples @ `main`
> > > > - incubator-kie-kogito-images @ `main`
> > > > - incubator-kie-kogito-serverless-operator @ `main`
> > > > - incubator-kie-kogito-docs @ `main`
> > > > - incubator-kie-docs @ `main-kogito`
> > > >
> > > > B. TOOLS (count: 2)
> > > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > > - incubator-kie-tools @ `main`
> > > >
> > > > C. BENCHMARKS (count: 2)
> > > > - incubator-kie-kogito-benchmarks @ `main`
> > > > - incubator-kie-benchmarks @ `main`
> > > >
> > > > D. ARCHIVED (count: 1)
> > > > - incubator-kie-kogito-operator
> > > >
> > > > E. "NON-CODE" (count: 5)
> > > > - incubator-kie-issues @ `main`
> > > > (Issues only, README should be updated @ `main`. Same for GitHub
> > > > Actions workflows.)
> > > > - incubator-kie-kogito-website @ `main`
> > > > (The Kogito website. Develop & deploy at the `main` branch.)
> > > > - incubator-kie-website @ `main`
> > > > (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> > > > website.)
> > > > - incubator-kie-kogito-online @ `gh-pages`
> > > > (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> > > > Extension assets.)
> > > > - incubator-kie-kogito-online-staging @ `main`
> > > > (Same as above, but for manual sanity checks during the staging
> > > > phase of a release.)
> > > >
> > > > TOTAL (count: 21)
> > > >
> > > > I grouped the repositories by category, and listed them in a
> > > > topological order. Keep in mind that when flattening out a tree,
> there
> > > > are multiple possibilities. For example, OptaPlanner could've been
> > > > placed in any position after Drools.
> > > >
> > > > Category A repos are what I've been referring to as `drools` and
> > > > `kogito-*` stream. Of course OptaPlanner is inside that stream, as
> the
> > > > way these repositories reference each other are through Maven
> > > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This
> mechanism
> > > > is well-known to the team, and although flawed for intra-day builds
> > > > and disruptive for people in many different time zones, it is already
> > > > very comfortable for everyone to work with, I assume.
> > > >
> > > > Contributions made to Category A have some dedicated pipelines, which
> > > > are, at least to some extent, able to build cross-repo PRs together
> > > > and verify that the codebase will continue working as expected after
> > > > they're all merged. From what I could gather, there are some
> > > > "sub-streams" currently configured for cross-repo PRs.
> > > >
> > > > - kogito-pipelines
> > > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > > > - optaplanner, and optaplanner-quickstarts
> > > > - kogito-images, and kogito-serverless-operator
> > > > - kogito-docs
> > > > - kie-docs
> > > >
> > > > This means that sending cross-repo PRs to any combination of repos
> > > > that are not part of the same "sub-stream" cannot be verified before
> > > > merging, making our contribution model dependent on individual
> > > > contributors building stuff on their machines to verify that it
> works.
> > > >
> > > > I based this analysis on
> > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > > ,
> > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > > ,
> > > > and
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > > .
> > > > Note that I'm not that familiar with these pipelines, so please
> > > > someone correct me if I'm wrong.
> > > >
> > > > Category B repos are what I've been referring to as `kie-tools`
> > > > stream. The first repo there is a template repository that is used by
> > > > people starting projects from scratch on KIE Sandbox, similar to a
> > > > Maven archetype, if you will. The other one is the KIE Tools
> monorepo,
> > > > a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> > > > Tools hosts Java libraries and apps, TypeScript libraries and apps,
> Go
> > > > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> > > > configured to work with sparse checkouts and can do partial builds.
> > > > Category B repos refer to Category A repos through timestamped
> > > > SNAPSHOTs. This is a new mechanism we recently introduced that will
> > > > build and publish immutable, persistent artifacts under a version
> > > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> > > > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> > > > releases, as we're now targeting one release for all of Apache KIE,
> so
> > > > we can't have Kogito releases anymore.
> > > >
> > > > An important note here is that Category B repositories have been
> > > > historically kept out of any automations we used to have, way back
> > > > when Kogito started and we had the Business Central (a.k.a. v7)
> stream
> > > > still going on. For this reason, Category B projects have developed
> > > > their own automations, based on GitHub Actions. Category B repos have
> > > > always depended on Category A repos using fixed versions. If Category
> > > > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > > > Category A repositories would've had the potential to break Category
> B
> > > > silently, leaving Category B with a broken development stream, and
> > > > introducing unpleasant surprises for maintainers of Category B repos,
> > > > as historically Category A contributors were not familiar with
> > > > Category B repos.
> > > >
> > > > Contributions made to Category B repos go through a GitHub Actions
> > > > workflow that builds the relevant part of the `kie-tools` monorepo
> for
> > > > the changes introduced. Changes made to the pipeline itself are also
> > > > picked up as part of PRs, allowing us to do things like atomically
> > > > bumping the Node.js version, for example. More importantly, it allows
> > > > us to upgrade the repository to a new timestamped SNAPSHOT together
> > > > with the changes necessary to make it stay green.
> > > >
> > > > This setup, however, makes it impossible to have cross-repo PRs
> > > > involving Category A and Category B simultaneously, with the current
> > > > automations we have.
> > > >
> > > > Category C repos are kind of floating around, and I'm not sure if
> > > > there's much activity going on there. Regardless, as they're part of
> > > > Apache KIE, they will be part of our release, so I listed them for us
> > > > to take them into consideration too.
> > > >
> > > > Category D is self explanatory. There's only one repo that has
> already
> > > > been marked for being archived.
> > > >
> > > > Category E are repos that do not host code directly, and are either
> > > > organizational entities, or host websites, that currently are not
> part
> > > > of any pipelines we have.
> > > >
> > > > This lack of unification between Category A and Category B is, IMHO,
> > > > what allowed us to introduce the infamous circular dependency between
> > > > `kie-tools` and `kogito-apps`, which we now can describe as a
> circular
> > > > dependency between Category A and Category B. The way I see it, if we
> > > > had a single pipeline, building everything from `drools` to
> > > > `kie-tools`, such flaws would've never been introduced, and we
> > > > wouldn't be having this huge problem in our hands right now.
> > > >
> > > > My proposal for the Apache KIE release process sees this lack of
> > > > unification as a central problem, not only for this release in
> > > > particular, but for the community as a whole. It is my belief that we
> > > > are all under the same roof, and that no contribution should be
> > > > allowed to break any part of our codebase. With the increasing volume
> > > > of code, and hopefully number of contributors too, we cannot keep
> > > > counting on "common sense" to avoid breaking things. We're all humans
> > > > after all, and it is our job to have mechanisms in place to prevent
> us
> > > > from unwillingly making mistakes. Especially when these mistakes
> > > > impact on parts of the codebase that we, individually, probably can't
> > > > fix.
> > > >
> > > >
> > > > # THE PROBLEMS WE HAVE RIGHT NOW
> > > >
> > > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> > > > `0.32.0`.
> > > > See:
> > > > -
> > > >
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > > >
> > > >
> > > > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > > > kiegroup's KIE Tools `0.32.0`.
> > > > See:
> > > > -
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > > >
> > > >
> > > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> > > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > > See:
> > > > -
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > > -
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > > >
> > > >
> > > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > > > Explainability `1.22.1.Final`.
> > > > * This module was removed from the KIE codebase here:
> > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > > and now lives on
> > > > https://github.com/trustyai-explainability/trustyai-explainability,
> > > > under a different GAV.
> > > > * This new repo depends on Kogito and OptaPlanner, pointing to older
> > > > versions.
> > > > See:
> > > > -
> > > >
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > > -
> > > >
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > > >
> > > >
> > > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > > See:
> > > > -
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > > >
> > > >
> > > > P6. Category C repos are out of date and not part of the Category A
> > > > CI/Release pipelines.
> > > > * incubator-kie-kogito-benchmarks: (Current version is
> `2.0-SNAPSHOT`,
> > > > depending on Kogito without a specific version, only by using
> > > > `http://localhost:8080`)
> > > > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > > > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
> > > >
> > > >
> > > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled
> after
> > > > upgrading to 999-20240218-SNAPSHOT.
> > > >
> > > >
> > > > In my perspective, P1 and P2 have the same solution, as they both
> > > > suffer from the circular dependency between Category A and Category
> B.
> > > > As Category A and Category B are both streams that have been really
> > > > active, I see this as a blocker, as there are contributions that
> > > > cannot be done, given that Category A depends on Category B with a
> > > > dephasing of 1 release.
> > > >
> > > > P3 and P4, although not ideal, can be understood as technical debt.
> > > > Depending on unmaintained projects is something we'll always be
> > > > susceptible to, given time.
> > > >
> > > > P5 and P6 are easily fixable, as it's just a matter of making them
> > > > part of the play.
> > > >
> > > > P7 is an isolated problem that won't impact the structure or anything
> > > > that we're talking about here, but it is a regression we introduced
> > > > recently.
> > > >
> > > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> > > > and P7 have easy fixes, the only problems left to discuss are P1 and
> > > > P2, which can't be done without a proper proposal.
> > > >
> > > >
> > > > # THE PROPOSAL
> > > >
> > > > I'll try to be very meticulous here, since from my experience, any
> > > > little miscalculation can lead to our release not working out in the
> > > > end. To try and avoid that as much as possible, and make everything
> we
> > > > can to have a successful Apache KIE 10 release, bear with me. I'll
> lay
> > > > out a timeline of events that need to happen in order for our release
> > > > to be published, with all artifacts ending up in the right places,
> but
> > > > first, we need to solve problems P1 and P2.
> > > >
> > > > As you saw at the beginning of this email, all the attempts we made
> > > > left us with the circular dependency showing up at a different place,
> > > > but something all these places have in common is that they're all
> > > > after kogito-apps, and before to Category B.
> > > >
> > > > The first part of my proposal is the following:
> > > >
> > > > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > > > `kogito-apps` to `kie-tools`, together with Management and Task
> > > > consoles from `kogito-images` to `kie-tools`.
> > > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> > > > from `kogito-images` to `kie-tools` too.
> > > > S3. We move the entire `kogito-serverless-operator` repo inside a new
> > > > package on `kie-tools`, keeping Git history.
> > > >
> > > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> > > > the rest of
> https://github.com/apache/incubator-kie-issues/issues/967
> > > > would still be done too.
> > > >
> > > > This doesn't come without consequences, of course, as the
> > > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > > > `kogito-serverless-operator` would be moving from Category A to
> > > > Category B. This move would make them have to reference Category A
> > > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > > > `kogito-serverless-operator` are already their own "sub-stream"
> inside
> > > > Category A, though, contributions made in a cross-repo fashion to
> this
> > > > "sub-stream" will continue being possible, now via a single PR to
> > > > `kie-tools`. Cross-repo PRs between Category A and Category B will
> > > > continue not being possible, and a 1-week delay between merging
> > > > something on Category A and using it on Category B will still happen.
> > > >
> > > > It's worth mentioning that `kie-tools`, however, does allow for
> sparse
> > > > checkouts and partial builds, so working with a subset of the
> monorepo
> > > > is possible and encouraged. Making changes only to
> > > > `packages/kn-plugin-workflow`, for example, will have the PR checks
> > > > run in < 10 minutes, as you can see here:
> > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > > .
> > > > We're not compromising when running partial builds too. We know that
> > > > the entire repo will continue working even after only building a
> small
> > > > subset of the changes. Doing partial or full builds is automatically
> > > > determined by the changes of a PR.
> > > >
> > > > Keep in mind that, even though I'm proposing we move a bunch of
> > > > additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> > > > for our codebase. `kie-tools` would host some additional stuff
> > > > TEMPORARILY so that we can release and continue moving forward.
> > > >
> > > > As I mentioned on other places, `kie-tools` became a polyglot
> monorepo
> > > > out of necessity, and although I'm really proud of what we achieved
> > > > there so far, I don't think `kie-tools` has a setup that is suitable
> > > > for all the different nuances that compose our community. I'm well
> > > > aware that a polyglot monorepo that does not follow widespread
> > > > conventions will scare some people away, and as much as we've tried
> to
> > > > make build instructions clear, we can't always get past the prejudice
> > > > some people have towards the "front-end" ecosystem.
> > > >
> > > > With all that said, I keep thinking this is the best course of action
> > > > for us right now. We keep most of our stuff unchanged, we unblock the
> > > > release, and we have a working setup that will suit us well while we
> > > > discuss and reach a conclusion regarding the future of our codebase
> > > > structure.
> > > >
> > > > Let me paint a quick picture here of what our code base would look
> > > > like, repository-wise, if my proposal is accepted:
> > > >
> > > > CATEGORY REPO
> > > > =====================
> > > > A incubator-kie-kogito-pipelines
> > > > A incubator-kie-drools
> > > > A incubator-kie-optaplanner
> > > > A incubator-kie-optaplanner-quickstarts
> > > > A incubator-kie-kogito-runtimes
> > > > A incubator-kie-kogito-apps
> > > > A incubator-kie-kogito-examples
> > > > A incubator-kie-kogito-images
> > > > A incubator-kie-kogito-docs
> > > > A incubator-kie-kogito-benchmarks
> > > > A incubator-kie-docs
> > > > A incubator-kie-benchmarks
> > > > =====================
> > > > B incubator-kie-sandbox-quarkus-accelerator
> > > > B incubator-kie-tools
> > > > =====================
> > > > D incubator-kie-kogito-operator
> > > > =====================
> > > > E incubator-kie-issues
> > > > E incubator-kie-kogito-website
> > > > E incubator-kie-website
> > > > E incubator-kie-kogito-online
> > > > E incubator-kie-kogito-online-staging
> > > > =====================
> > > >
> > > > * Category C becomes part of Category A, and
> > > > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > > > * With `kogito-swf-{builder,devmode}` images and
> > > > `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> > > > anymore, as inside `kie-tools`, we can granularly build:
> > > > 1. packages/sonataflow-deployment-webapp
> > > > 2. packages/sonataflow-quarkus-devui
> > > > 3. packages/sonataflow-images (containing `kogito-swf-builder`
> and
> > > > `kogito-swf-devmode`)
> > > > 4. packages/sonataflow-operator (contents from
> > > > `kogito-serverless-operator`)
> > > > 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> > > > but renamed)
> > > >
> > > > The second part of the proposal is the release process itself,
> > > > assuming the structure above is what we have.
> > > >
> > > > Here it is:
> > > >
> > > > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > > > Category A repos.
> > > > 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> > > > verify that everything is working.
> > > > 3. At this point, with everything working, we can branch out to
> > > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category
> B
> > > > from `main`.
> > > > 4. All Category A and Category B repos update their versions to
> > > > 10.0.0, in their `10.0.x` branches.
> > > > 5. Update Category B repos to point to Category A repos using the
> > > > 10.0.0 version.
> > > > 6. At this point, we can vote on the release based on the `10.0.x`
> > > > branches, given we don't expect any code changes anymore.
> > > > 7. After voting passes, we're good to start the release process.
> > > > 8. Category A repos follow their manual/automated release process,
> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > > artifacts pushed to their registries.
> > > > 9. We wait a little bit for Category A artifacts to be propagated on
> > > > registries. ~1 day.
> > > > 10. Category B repos follow their manual/automated release process,
> > > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > > artifacts pushed to their registries.
> > > > 11. Category D repos are ignored.
> > > > 12. Category E repos can be manually tagged with 10.0.0 from their
> > > > default branches.
> > > >
> > > > More needs to be discussed if we're planning to maintain multiple
> > > > release streams in parallel, but I guess it can wait for after Apache
> > > > KIE 10.
> > > >
> > > > Thank you for reading, and I'm looking forward to hearing back from
> > > > everyone.
> > > >
> > > > Of course, alternative solutions are possible. This email, however,
> > > > summarizes my view of how we should attack the problem, considering
> > > > disruption, required effort, the release process itself, and history.
> > > > Feel free to propose alternatives. This is not a voting thread.
> > > >
> > > > Regards,
> > > >
> > > > Tiago Bento
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Alex Porcelli <po...@apache.org>.
+1 on the proposal adding to it the details needed for the revert changes
post 10
+1 to start new thread to discuss anything other than this proposal
On Fri, Mar 15, 2024 at 8:25 AM Enrique Gonzalez Martinez <
egonzalez@apache.org> wrote:
> +1 to the short term approach as it seems both parties agree into this.
>
> Regarding the long term proposal plz move to another thread before someone
> starts engaging in this thread about a topic is not relevant for unblocking
> the version.
>
> El vie, 15 mar 2024, 13:20, Kris Verlaenen <kr...@gmail.com>
> escribió:
>
> > TLDR: A +1 to the proposal from Tiago for the release, with the addition
> of
> > some short term recommendation (on how to revert some of the temporary
> > changes) and some perspective on a potential alternative to consider for
> > the long term
> >
> > * Short term: The plan from Tiago describes a strategy that appears to be
> > able to solve the build cycle issues we have, allowing us to proceed with
> > the 10.0 release. We do realize that some of the changes that are being
> > done to be able to do the 10.0 release are going to be temporary.
> > Therefore, as part of this proposal, I urge the team to also document how
> > we are going to revert some of these temporary changes immediately after
> > the release (*). More specifically, my recommendation is that we agree
> > that the images and operator folder from kie-tools will be removed again
> > and development will continue on the existing repositories. But let’s
> > discuss if people see this differently or if there might be other steps.
> > The advantage of this approach would be that it allows us to move forward
> > with the release, does buy us time to find a consensus on the long-term
> > solution and minimizes the impact on the developers regarding temporary
> > solutions. And it also requires us to find this consensus before the
> next
> > release.
> >
> > * Longer term: as discussed to some degree in this thread already, there
> > seems to be an alternative to explore where we define more strict
> > boundaries (for dependencies) between repositories, and create a build
> > chain where images and operator are built after tools. That said, it’s
> > fair to say that this proposal needs to be worked out and validated more,
> > and initial assessments on the effort related to this, if we don’t want
> to
> > rush into this and do things right, are indicating this might take
> multiple
> > months. We also need to discuss how we will be resourcing this effort.
> > And we could potentially combine this with other discussions that we will
> > have in the near future. So if we agree to investigate this further, I
> > would like to recommend moving forward with the more concrete temporary
> > solution that Tiago is proposing for the 10.0 release.
> >
> > Note that this would mean that at this point, on this thread, we don’t
> need
> > to agree on the specifics of any alternative proposal longer-term, we can
> > start a different conversation thread for this. I hope this can convince
> > people to +1 the approach as described by Tiago short term for the
> release,
> > with the addition of the recipe how to revert some of the temporary
> changes
> > and the promise to further evaluate longer-term alternatives. For those
> > that are interested, I wanted to also give an indication what this
> proposal
> > might mean at a high level from my point of view, which is included
> below.
> >
> > Thx,
> > Kris
> >
> > [Optional reading] Alternative longer-term proposal
> >
> > One could subdivide the work we do in two main streams: one focused more
> on
> > the runtimes, one focused more on the tooling. In general a lot of
> tooling
> > can be built independently from the runtime and vice versa, where they
> > communicate with each other through well defined formats or apis.
> However,
> > once we start looking at more advanced use cases and the full end-to-end,
> > this is where we need both tooling and runtime together.
> > The goal is to create one release pipeline(**). The issue with cyclic
> > dependencies between repos is imho twofold: 1) we haven’t been 100%
> > consistent in separating runtimes and tooling this way and 2) we haven’t
> > accommodated well for use cases where runtime and tooling needs to be
> > combined. Note that some of these dependencies might not be build time
> > dependencies but test and/or runtime dependencies only.
> > As an alternative to one kie-tools monorepo that combines tooling and
> > images and operator, I believe we can construct a pipeline where most of
> > runtime and tooling can be built independently, but after runtime and
> > tooling are built, we complete the build with other
> > components/repositories, because they logically rely more on both.
> > Examples of components that rely on both are for example be a devui
> > extension (a quarkus extension that embeds tooling) or the devmode image
> > (that also includes tooling features), or integration testing (where we
> > want to test whether tooling and runtime work well together.
> >
> > More specifically, this would mean
> > 1) making sure that there are well-defined boundaries between the core
> > runtimes and core tooling so they don’t depend on each other at build
> > time. We can decide to move components around where we think that makes
> > sense, for example:
> > move ui code related to devui into kie-tools (as discussed before)
> > move kn-workflow to the operator repository as it more closely related to
> > that
> > 2) update the CI and release pipelines so that core runtime and tooling
> > repositories can be built first, and are followed up by other
> repositories
> > like images and operator, that could then rely on both.
> >
> > (*) Note that there would be other options technically to achieve this,
> > like cutting a release branch early and performing the changes only
> there,
> > but given other work is still ongoing as well, we want to minimize the
> > cherry-picking effort.
> > (**) Note that while the goal is to create one release pipeline, this
> > should not necessarily mean that we can’t have smaller or optimized
> > pipelines for CI and daily development, where the impact of changes is
> > typically more localized.
> >
> > On Tue, Mar 12, 2024 at 8:45 PM Tiago Bento <ti...@apache.org>
> wrote:
> >
> > > Hi everyone,
> > >
> > > Unfortunately, I can't do a tl;dr this time, as this matter requires a
> > > lot of context.
> > >
> > > This email will take you < 20 minutes to read, according to
> > > https://thereadtime.com/.
> > >
> > > As you may have followed on a separate thread
> > > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> > > many of us were working towards removing a circular dependency
> > > currently present between `kogito-apps` and `kie-tools`. As we
> > > progressed towards a solution, we kept finding the circular dependency
> > > pop up somewhere else. I'll do a breakdown of the things we did, and
> > > the results we had.
> > >
> > > Right now, even though we started the effort to move the Quarkus Dev
> > > UI modules to `kie-tools`, we haven't been able to do it yet, as we've
> > > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> > > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> > > effort was concluded this Monday, with
> > > https://github.com/apache/incubator-kie-tools/pull/2136.
> > >
> > > The current scenario we have is:
> > >
> > > 01. incubator-kie-kogito-runtimes
> > > |==> 02. incubator-kie-kogito-apps
> > > C | 03. incubator-kie-kogito-examples
> > > Y | 04. incubator-kie-kogito-images
> > > C | 05. incubator-kie-kogito-serverless-operator
> > > L | ==========================
> > > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > > |==> 07. incubator-kie-tools
> > >
> > >
> > > * As `kie-tools`/extended-services depends on
> > > `kogito-apps`/jitexecutor;
> > > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> > > `kie-tools`/{many packages}
> > >
> > >
> > > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> > >
> > > 01. incubator-kie-kogito-runtimes
> > > 02. incubator-kie-kogito-apps
> > > 03. incubator-kie-kogito-examples
> > > C |==> 04. incubator-kie-kogito-images
> > > Y | 05. incubator-kie-kogito-serverless-operator
> > > C | =====================
> > > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > > E |==> 07. incubator-kie-tools
> > >
> > > * As `kie-tools`/kn-plugin-workflow depends on
> > > `kogito-images`/kogito-swf-devmode;
> > > * and `kogito-images`/kogito-swf-devmode depends on
> > > `kie-tools`/sonataflow-quarkus-devui
> > >
> > >
> > > After moving the `kogito-swf-devmode` image to `kie-tools`, we would've
> > > had:
> > >
> > > 01. incubator-kie-kogito-runtimes
> > > 02. incubator-kie-kogito-apps
> > > 03. incubator-kie-kogito-examples
> > > 04. incubator-kie-kogito-images
> > > C |==> 05. incubator-kie-kogito-serverless-operator
> > > Y | =====================
> > > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > > L |==> 07. incubator-kie-tools
> > > E
> > >
> > > * As `kie-tools`/kn-plugin-workflow depends on
> > > `kogito-serverless-operator`;
> > > * and `kogito-serverless-operator` depends on
> > > `kie-tools`/kogito-swf-devmode
> > >
> > >
> > > Clearly, we have a much bigger problem than a simple circular
> dependency.
> > >
> > > After multiple conversations with a lot of people, it's been really
> > > hard coming up with a simple solution that makes it possible to build
> > > Apache KIE in one shot, while preserving the way everyone is used to
> > > contributing to the multiple repositories we have. More than that,
> > > while making this assessment, I found more problems that, in my
> > > perspective, block Apache KIE 10.
> > >
> > > In light of that difficulty, I'm coming forward with my proposal for
> > > the Apache KIE release process, so we can use Apache's mechanisms to
> > > have a slower-paced, in-depth debate about this really complicated
> > > matter.
> > >
> > > I'll lay out my entire perspective about the current situation of our
> > > codebase, as well as problems I can currently see. I'll start with an
> > > analysis of the repositories and their purposes, point out some
> > > problems that I believe are blocking our 10 release, explain my
> > > proposal and discuss some consequences to what I'm proposing.
> > >
> > > Let's begin.
> > >
> > >
> > > # THE APACHE KIE REPOS
> > >
> > > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > > - incubator-kie-kogito-pipelines @ `main`
> > > - incubator-kie-drools @ `main`
> > > - incubator-kie-optaplanner @ `main`
> > > - incubator-kie-optaplanner-quickstarts @ `main`
> > > - incubator-kie-kogito-runtimes @ `main`
> > > - incubator-kie-kogito-apps @ `main`
> > > - incubator-kie-kogito-examples @ `main`
> > > - incubator-kie-kogito-images @ `main`
> > > - incubator-kie-kogito-serverless-operator @ `main`
> > > - incubator-kie-kogito-docs @ `main`
> > > - incubator-kie-docs @ `main-kogito`
> > >
> > > B. TOOLS (count: 2)
> > > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > > - incubator-kie-tools @ `main`
> > >
> > > C. BENCHMARKS (count: 2)
> > > - incubator-kie-kogito-benchmarks @ `main`
> > > - incubator-kie-benchmarks @ `main`
> > >
> > > D. ARCHIVED (count: 1)
> > > - incubator-kie-kogito-operator
> > >
> > > E. "NON-CODE" (count: 5)
> > > - incubator-kie-issues @ `main`
> > > (Issues only, README should be updated @ `main`. Same for GitHub
> > > Actions workflows.)
> > > - incubator-kie-kogito-website @ `main`
> > > (The Kogito website. Develop & deploy at the `main` branch.)
> > > - incubator-kie-website @ `main`
> > > (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> > > website.)
> > > - incubator-kie-kogito-online @ `gh-pages`
> > > (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> > > Extension assets.)
> > > - incubator-kie-kogito-online-staging @ `main`
> > > (Same as above, but for manual sanity checks during the staging
> > > phase of a release.)
> > >
> > > TOTAL (count: 21)
> > >
> > > I grouped the repositories by category, and listed them in a
> > > topological order. Keep in mind that when flattening out a tree, there
> > > are multiple possibilities. For example, OptaPlanner could've been
> > > placed in any position after Drools.
> > >
> > > Category A repos are what I've been referring to as `drools` and
> > > `kogito-*` stream. Of course OptaPlanner is inside that stream, as the
> > > way these repositories reference each other are through Maven
> > > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This mechanism
> > > is well-known to the team, and although flawed for intra-day builds
> > > and disruptive for people in many different time zones, it is already
> > > very comfortable for everyone to work with, I assume.
> > >
> > > Contributions made to Category A have some dedicated pipelines, which
> > > are, at least to some extent, able to build cross-repo PRs together
> > > and verify that the codebase will continue working as expected after
> > > they're all merged. From what I could gather, there are some
> > > "sub-streams" currently configured for cross-repo PRs.
> > >
> > > - kogito-pipelines
> > > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > > - optaplanner, and optaplanner-quickstarts
> > > - kogito-images, and kogito-serverless-operator
> > > - kogito-docs
> > > - kie-docs
> > >
> > > This means that sending cross-repo PRs to any combination of repos
> > > that are not part of the same "sub-stream" cannot be verified before
> > > merging, making our contribution model dependent on individual
> > > contributors building stuff on their machines to verify that it works.
> > >
> > > I based this analysis on
> > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > > ,
> > >
> > >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > > ,
> > > and
> > >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > > .
> > > Note that I'm not that familiar with these pipelines, so please
> > > someone correct me if I'm wrong.
> > >
> > > Category B repos are what I've been referring to as `kie-tools`
> > > stream. The first repo there is a template repository that is used by
> > > people starting projects from scratch on KIE Sandbox, similar to a
> > > Maven archetype, if you will. The other one is the KIE Tools monorepo,
> > > a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> > > Tools hosts Java libraries and apps, TypeScript libraries and apps, Go
> > > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> > > configured to work with sparse checkouts and can do partial builds.
> > > Category B repos refer to Category A repos through timestamped
> > > SNAPSHOTs. This is a new mechanism we recently introduced that will
> > > build and publish immutable, persistent artifacts under a version
> > > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> > > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> > > releases, as we're now targeting one release for all of Apache KIE, so
> > > we can't have Kogito releases anymore.
> > >
> > > An important note here is that Category B repositories have been
> > > historically kept out of any automations we used to have, way back
> > > when Kogito started and we had the Business Central (a.k.a. v7) stream
> > > still going on. For this reason, Category B projects have developed
> > > their own automations, based on GitHub Actions. Category B repos have
> > > always depended on Category A repos using fixed versions. If Category
> > > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > > Category A repositories would've had the potential to break Category B
> > > silently, leaving Category B with a broken development stream, and
> > > introducing unpleasant surprises for maintainers of Category B repos,
> > > as historically Category A contributors were not familiar with
> > > Category B repos.
> > >
> > > Contributions made to Category B repos go through a GitHub Actions
> > > workflow that builds the relevant part of the `kie-tools` monorepo for
> > > the changes introduced. Changes made to the pipeline itself are also
> > > picked up as part of PRs, allowing us to do things like atomically
> > > bumping the Node.js version, for example. More importantly, it allows
> > > us to upgrade the repository to a new timestamped SNAPSHOT together
> > > with the changes necessary to make it stay green.
> > >
> > > This setup, however, makes it impossible to have cross-repo PRs
> > > involving Category A and Category B simultaneously, with the current
> > > automations we have.
> > >
> > > Category C repos are kind of floating around, and I'm not sure if
> > > there's much activity going on there. Regardless, as they're part of
> > > Apache KIE, they will be part of our release, so I listed them for us
> > > to take them into consideration too.
> > >
> > > Category D is self explanatory. There's only one repo that has already
> > > been marked for being archived.
> > >
> > > Category E are repos that do not host code directly, and are either
> > > organizational entities, or host websites, that currently are not part
> > > of any pipelines we have.
> > >
> > > This lack of unification between Category A and Category B is, IMHO,
> > > what allowed us to introduce the infamous circular dependency between
> > > `kie-tools` and `kogito-apps`, which we now can describe as a circular
> > > dependency between Category A and Category B. The way I see it, if we
> > > had a single pipeline, building everything from `drools` to
> > > `kie-tools`, such flaws would've never been introduced, and we
> > > wouldn't be having this huge problem in our hands right now.
> > >
> > > My proposal for the Apache KIE release process sees this lack of
> > > unification as a central problem, not only for this release in
> > > particular, but for the community as a whole. It is my belief that we
> > > are all under the same roof, and that no contribution should be
> > > allowed to break any part of our codebase. With the increasing volume
> > > of code, and hopefully number of contributors too, we cannot keep
> > > counting on "common sense" to avoid breaking things. We're all humans
> > > after all, and it is our job to have mechanisms in place to prevent us
> > > from unwillingly making mistakes. Especially when these mistakes
> > > impact on parts of the codebase that we, individually, probably can't
> > > fix.
> > >
> > >
> > > # THE PROBLEMS WE HAVE RIGHT NOW
> > >
> > > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> > > `0.32.0`.
> > > See:
> > > -
> > >
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> > >
> > >
> > > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > > kiegroup's KIE Tools `0.32.0`.
> > > See:
> > > -
> > >
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> > >
> > >
> > > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> > > `kie-soup` artifacts at version `7.59.0.Final`.
> > > See:
> > > -
> > >
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > > -
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> > >
> > >
> > > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > > Explainability `1.22.1.Final`.
> > > * This module was removed from the KIE codebase here:
> > >
> > >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > > and now lives on
> > > https://github.com/trustyai-explainability/trustyai-explainability,
> > > under a different GAV.
> > > * This new repo depends on Kogito and OptaPlanner, pointing to older
> > > versions.
> > > See:
> > > -
> > >
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > > -
> > >
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> > >
> > >
> > > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> > > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > > See:
> > > -
> > >
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> > >
> > >
> > > P6. Category C repos are out of date and not part of the Category A
> > > CI/Release pipelines.
> > > * incubator-kie-kogito-benchmarks: (Current version is `2.0-SNAPSHOT`,
> > > depending on Kogito without a specific version, only by using
> > > `http://localhost:8080`)
> > > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
> > >
> > >
> > > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled after
> > > upgrading to 999-20240218-SNAPSHOT.
> > >
> > >
> > > In my perspective, P1 and P2 have the same solution, as they both
> > > suffer from the circular dependency between Category A and Category B.
> > > As Category A and Category B are both streams that have been really
> > > active, I see this as a blocker, as there are contributions that
> > > cannot be done, given that Category A depends on Category B with a
> > > dephasing of 1 release.
> > >
> > > P3 and P4, although not ideal, can be understood as technical debt.
> > > Depending on unmaintained projects is something we'll always be
> > > susceptible to, given time.
> > >
> > > P5 and P6 are easily fixable, as it's just a matter of making them
> > > part of the play.
> > >
> > > P7 is an isolated problem that won't impact the structure or anything
> > > that we're talking about here, but it is a regression we introduced
> > > recently.
> > >
> > > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> > > and P7 have easy fixes, the only problems left to discuss are P1 and
> > > P2, which can't be done without a proper proposal.
> > >
> > >
> > > # THE PROPOSAL
> > >
> > > I'll try to be very meticulous here, since from my experience, any
> > > little miscalculation can lead to our release not working out in the
> > > end. To try and avoid that as much as possible, and make everything we
> > > can to have a successful Apache KIE 10 release, bear with me. I'll lay
> > > out a timeline of events that need to happen in order for our release
> > > to be published, with all artifacts ending up in the right places, but
> > > first, we need to solve problems P1 and P2.
> > >
> > > As you saw at the beginning of this email, all the attempts we made
> > > left us with the circular dependency showing up at a different place,
> > > but something all these places have in common is that they're all
> > > after kogito-apps, and before to Category B.
> > >
> > > The first part of my proposal is the following:
> > >
> > > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > > `kogito-apps` to `kie-tools`, together with Management and Task
> > > consoles from `kogito-images` to `kie-tools`.
> > > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> > > from `kogito-images` to `kie-tools` too.
> > > S3. We move the entire `kogito-serverless-operator` repo inside a new
> > > package on `kie-tools`, keeping Git history.
> > >
> > > Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> > > the rest of https://github.com/apache/incubator-kie-issues/issues/967
> > > would still be done too.
> > >
> > > This doesn't come without consequences, of course, as the
> > > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > > `kogito-serverless-operator` would be moving from Category A to
> > > Category B. This move would make them have to reference Category A
> > > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > > `kogito-serverless-operator` are already their own "sub-stream" inside
> > > Category A, though, contributions made in a cross-repo fashion to this
> > > "sub-stream" will continue being possible, now via a single PR to
> > > `kie-tools`. Cross-repo PRs between Category A and Category B will
> > > continue not being possible, and a 1-week delay between merging
> > > something on Category A and using it on Category B will still happen.
> > >
> > > It's worth mentioning that `kie-tools`, however, does allow for sparse
> > > checkouts and partial builds, so working with a subset of the monorepo
> > > is possible and encouraged. Making changes only to
> > > `packages/kn-plugin-workflow`, for example, will have the PR checks
> > > run in < 10 minutes, as you can see here:
> > >
> > >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > > .
> > > We're not compromising when running partial builds too. We know that
> > > the entire repo will continue working even after only building a small
> > > subset of the changes. Doing partial or full builds is automatically
> > > determined by the changes of a PR.
> > >
> > > Keep in mind that, even though I'm proposing we move a bunch of
> > > additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> > > for our codebase. `kie-tools` would host some additional stuff
> > > TEMPORARILY so that we can release and continue moving forward.
> > >
> > > As I mentioned on other places, `kie-tools` became a polyglot monorepo
> > > out of necessity, and although I'm really proud of what we achieved
> > > there so far, I don't think `kie-tools` has a setup that is suitable
> > > for all the different nuances that compose our community. I'm well
> > > aware that a polyglot monorepo that does not follow widespread
> > > conventions will scare some people away, and as much as we've tried to
> > > make build instructions clear, we can't always get past the prejudice
> > > some people have towards the "front-end" ecosystem.
> > >
> > > With all that said, I keep thinking this is the best course of action
> > > for us right now. We keep most of our stuff unchanged, we unblock the
> > > release, and we have a working setup that will suit us well while we
> > > discuss and reach a conclusion regarding the future of our codebase
> > > structure.
> > >
> > > Let me paint a quick picture here of what our code base would look
> > > like, repository-wise, if my proposal is accepted:
> > >
> > > CATEGORY REPO
> > > =====================
> > > A incubator-kie-kogito-pipelines
> > > A incubator-kie-drools
> > > A incubator-kie-optaplanner
> > > A incubator-kie-optaplanner-quickstarts
> > > A incubator-kie-kogito-runtimes
> > > A incubator-kie-kogito-apps
> > > A incubator-kie-kogito-examples
> > > A incubator-kie-kogito-images
> > > A incubator-kie-kogito-docs
> > > A incubator-kie-kogito-benchmarks
> > > A incubator-kie-docs
> > > A incubator-kie-benchmarks
> > > =====================
> > > B incubator-kie-sandbox-quarkus-accelerator
> > > B incubator-kie-tools
> > > =====================
> > > D incubator-kie-kogito-operator
> > > =====================
> > > E incubator-kie-issues
> > > E incubator-kie-kogito-website
> > > E incubator-kie-website
> > > E incubator-kie-kogito-online
> > > E incubator-kie-kogito-online-staging
> > > =====================
> > >
> > > * Category C becomes part of Category A, and
> > > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > > * With `kogito-swf-{builder,devmode}` images and
> > > `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> > > anymore, as inside `kie-tools`, we can granularly build:
> > > 1. packages/sonataflow-deployment-webapp
> > > 2. packages/sonataflow-quarkus-devui
> > > 3. packages/sonataflow-images (containing `kogito-swf-builder` and
> > > `kogito-swf-devmode`)
> > > 4. packages/sonataflow-operator (contents from
> > > `kogito-serverless-operator`)
> > > 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> > > but renamed)
> > >
> > > The second part of the proposal is the release process itself,
> > > assuming the structure above is what we have.
> > >
> > > Here it is:
> > >
> > > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > > Category A repos.
> > > 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> > > verify that everything is working.
> > > 3. At this point, with everything working, we can branch out to
> > > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
> > > from `main`.
> > > 4. All Category A and Category B repos update their versions to
> > > 10.0.0, in their `10.0.x` branches.
> > > 5. Update Category B repos to point to Category A repos using the
> > > 10.0.0 version.
> > > 6. At this point, we can vote on the release based on the `10.0.x`
> > > branches, given we don't expect any code changes anymore.
> > > 7. After voting passes, we're good to start the release process.
> > > 8. Category A repos follow their manual/automated release process,
> > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > artifacts pushed to their registries.
> > > 9. We wait a little bit for Category A artifacts to be propagated on
> > > registries. ~1 day.
> > > 10. Category B repos follow their manual/automated release process,
> > > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > > artifacts pushed to their registries.
> > > 11. Category D repos are ignored.
> > > 12. Category E repos can be manually tagged with 10.0.0 from their
> > > default branches.
> > >
> > > More needs to be discussed if we're planning to maintain multiple
> > > release streams in parallel, but I guess it can wait for after Apache
> > > KIE 10.
> > >
> > > Thank you for reading, and I'm looking forward to hearing back from
> > > everyone.
> > >
> > > Of course, alternative solutions are possible. This email, however,
> > > summarizes my view of how we should attack the problem, considering
> > > disruption, required effort, the release process itself, and history.
> > > Feel free to propose alternatives. This is not a voting thread.
> > >
> > > Regards,
> > >
> > > Tiago Bento
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Enrique Gonzalez Martinez <eg...@apache.org>.
+1 to the short term approach as it seems both parties agree into this.
Regarding the long term proposal plz move to another thread before someone
starts engaging in this thread about a topic is not relevant for unblocking
the version.
El vie, 15 mar 2024, 13:20, Kris Verlaenen <kr...@gmail.com>
escribió:
> TLDR: A +1 to the proposal from Tiago for the release, with the addition of
> some short term recommendation (on how to revert some of the temporary
> changes) and some perspective on a potential alternative to consider for
> the long term
>
> * Short term: The plan from Tiago describes a strategy that appears to be
> able to solve the build cycle issues we have, allowing us to proceed with
> the 10.0 release. We do realize that some of the changes that are being
> done to be able to do the 10.0 release are going to be temporary.
> Therefore, as part of this proposal, I urge the team to also document how
> we are going to revert some of these temporary changes immediately after
> the release (*). More specifically, my recommendation is that we agree
> that the images and operator folder from kie-tools will be removed again
> and development will continue on the existing repositories. But let’s
> discuss if people see this differently or if there might be other steps.
> The advantage of this approach would be that it allows us to move forward
> with the release, does buy us time to find a consensus on the long-term
> solution and minimizes the impact on the developers regarding temporary
> solutions. And it also requires us to find this consensus before the next
> release.
>
> * Longer term: as discussed to some degree in this thread already, there
> seems to be an alternative to explore where we define more strict
> boundaries (for dependencies) between repositories, and create a build
> chain where images and operator are built after tools. That said, it’s
> fair to say that this proposal needs to be worked out and validated more,
> and initial assessments on the effort related to this, if we don’t want to
> rush into this and do things right, are indicating this might take multiple
> months. We also need to discuss how we will be resourcing this effort.
> And we could potentially combine this with other discussions that we will
> have in the near future. So if we agree to investigate this further, I
> would like to recommend moving forward with the more concrete temporary
> solution that Tiago is proposing for the 10.0 release.
>
> Note that this would mean that at this point, on this thread, we don’t need
> to agree on the specifics of any alternative proposal longer-term, we can
> start a different conversation thread for this. I hope this can convince
> people to +1 the approach as described by Tiago short term for the release,
> with the addition of the recipe how to revert some of the temporary changes
> and the promise to further evaluate longer-term alternatives. For those
> that are interested, I wanted to also give an indication what this proposal
> might mean at a high level from my point of view, which is included below.
>
> Thx,
> Kris
>
> [Optional reading] Alternative longer-term proposal
>
> One could subdivide the work we do in two main streams: one focused more on
> the runtimes, one focused more on the tooling. In general a lot of tooling
> can be built independently from the runtime and vice versa, where they
> communicate with each other through well defined formats or apis. However,
> once we start looking at more advanced use cases and the full end-to-end,
> this is where we need both tooling and runtime together.
> The goal is to create one release pipeline(**). The issue with cyclic
> dependencies between repos is imho twofold: 1) we haven’t been 100%
> consistent in separating runtimes and tooling this way and 2) we haven’t
> accommodated well for use cases where runtime and tooling needs to be
> combined. Note that some of these dependencies might not be build time
> dependencies but test and/or runtime dependencies only.
> As an alternative to one kie-tools monorepo that combines tooling and
> images and operator, I believe we can construct a pipeline where most of
> runtime and tooling can be built independently, but after runtime and
> tooling are built, we complete the build with other
> components/repositories, because they logically rely more on both.
> Examples of components that rely on both are for example be a devui
> extension (a quarkus extension that embeds tooling) or the devmode image
> (that also includes tooling features), or integration testing (where we
> want to test whether tooling and runtime work well together.
>
> More specifically, this would mean
> 1) making sure that there are well-defined boundaries between the core
> runtimes and core tooling so they don’t depend on each other at build
> time. We can decide to move components around where we think that makes
> sense, for example:
> move ui code related to devui into kie-tools (as discussed before)
> move kn-workflow to the operator repository as it more closely related to
> that
> 2) update the CI and release pipelines so that core runtime and tooling
> repositories can be built first, and are followed up by other repositories
> like images and operator, that could then rely on both.
>
> (*) Note that there would be other options technically to achieve this,
> like cutting a release branch early and performing the changes only there,
> but given other work is still ongoing as well, we want to minimize the
> cherry-picking effort.
> (**) Note that while the goal is to create one release pipeline, this
> should not necessarily mean that we can’t have smaller or optimized
> pipelines for CI and daily development, where the impact of changes is
> typically more localized.
>
> On Tue, Mar 12, 2024 at 8:45 PM Tiago Bento <ti...@apache.org> wrote:
>
> > Hi everyone,
> >
> > Unfortunately, I can't do a tl;dr this time, as this matter requires a
> > lot of context.
> >
> > This email will take you < 20 minutes to read, according to
> > https://thereadtime.com/.
> >
> > As you may have followed on a separate thread
> > (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> > many of us were working towards removing a circular dependency
> > currently present between `kogito-apps` and `kie-tools`. As we
> > progressed towards a solution, we kept finding the circular dependency
> > pop up somewhere else. I'll do a breakdown of the things we did, and
> > the results we had.
> >
> > Right now, even though we started the effort to move the Quarkus Dev
> > UI modules to `kie-tools`, we haven't been able to do it yet, as we've
> > been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> > 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> > effort was concluded this Monday, with
> > https://github.com/apache/incubator-kie-tools/pull/2136.
> >
> > The current scenario we have is:
> >
> > 01. incubator-kie-kogito-runtimes
> > |==> 02. incubator-kie-kogito-apps
> > C | 03. incubator-kie-kogito-examples
> > Y | 04. incubator-kie-kogito-images
> > C | 05. incubator-kie-kogito-serverless-operator
> > L | ==========================
> > E | 06. incubator-kie-sandbox-quarkus-accelerator
> > |==> 07. incubator-kie-tools
> >
> >
> > * As `kie-tools`/extended-services depends on
> > `kogito-apps`/jitexecutor;
> > * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> > `kie-tools`/{many packages}
> >
> >
> > After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
> >
> > 01. incubator-kie-kogito-runtimes
> > 02. incubator-kie-kogito-apps
> > 03. incubator-kie-kogito-examples
> > C |==> 04. incubator-kie-kogito-images
> > Y | 05. incubator-kie-kogito-serverless-operator
> > C | =====================
> > L | 06. incubator-kie-sandbox-quarkus-accelerator
> > E |==> 07. incubator-kie-tools
> >
> > * As `kie-tools`/kn-plugin-workflow depends on
> > `kogito-images`/kogito-swf-devmode;
> > * and `kogito-images`/kogito-swf-devmode depends on
> > `kie-tools`/sonataflow-quarkus-devui
> >
> >
> > After moving the `kogito-swf-devmode` image to `kie-tools`, we would've
> > had:
> >
> > 01. incubator-kie-kogito-runtimes
> > 02. incubator-kie-kogito-apps
> > 03. incubator-kie-kogito-examples
> > 04. incubator-kie-kogito-images
> > C |==> 05. incubator-kie-kogito-serverless-operator
> > Y | =====================
> > C | 06. incubator-kie-sandbox-quarkus-accelerator
> > L |==> 07. incubator-kie-tools
> > E
> >
> > * As `kie-tools`/kn-plugin-workflow depends on
> > `kogito-serverless-operator`;
> > * and `kogito-serverless-operator` depends on
> > `kie-tools`/kogito-swf-devmode
> >
> >
> > Clearly, we have a much bigger problem than a simple circular dependency.
> >
> > After multiple conversations with a lot of people, it's been really
> > hard coming up with a simple solution that makes it possible to build
> > Apache KIE in one shot, while preserving the way everyone is used to
> > contributing to the multiple repositories we have. More than that,
> > while making this assessment, I found more problems that, in my
> > perspective, block Apache KIE 10.
> >
> > In light of that difficulty, I'm coming forward with my proposal for
> > the Apache KIE release process, so we can use Apache's mechanisms to
> > have a slower-paced, in-depth debate about this really complicated
> > matter.
> >
> > I'll lay out my entire perspective about the current situation of our
> > codebase, as well as problems I can currently see. I'll start with an
> > analysis of the repositories and their purposes, point out some
> > problems that I believe are blocking our 10 release, explain my
> > proposal and discuss some consequences to what I'm proposing.
> >
> > Let's begin.
> >
> >
> > # THE APACHE KIE REPOS
> >
> > A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> > - incubator-kie-kogito-pipelines @ `main`
> > - incubator-kie-drools @ `main`
> > - incubator-kie-optaplanner @ `main`
> > - incubator-kie-optaplanner-quickstarts @ `main`
> > - incubator-kie-kogito-runtimes @ `main`
> > - incubator-kie-kogito-apps @ `main`
> > - incubator-kie-kogito-examples @ `main`
> > - incubator-kie-kogito-images @ `main`
> > - incubator-kie-kogito-serverless-operator @ `main`
> > - incubator-kie-kogito-docs @ `main`
> > - incubator-kie-docs @ `main-kogito`
> >
> > B. TOOLS (count: 2)
> > - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> > - incubator-kie-tools @ `main`
> >
> > C. BENCHMARKS (count: 2)
> > - incubator-kie-kogito-benchmarks @ `main`
> > - incubator-kie-benchmarks @ `main`
> >
> > D. ARCHIVED (count: 1)
> > - incubator-kie-kogito-operator
> >
> > E. "NON-CODE" (count: 5)
> > - incubator-kie-issues @ `main`
> > (Issues only, README should be updated @ `main`. Same for GitHub
> > Actions workflows.)
> > - incubator-kie-kogito-website @ `main`
> > (The Kogito website. Develop & deploy at the `main` branch.)
> > - incubator-kie-website @ `main`
> > (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> > website.)
> > - incubator-kie-kogito-online @ `gh-pages`
> > (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> > Extension assets.)
> > - incubator-kie-kogito-online-staging @ `main`
> > (Same as above, but for manual sanity checks during the staging
> > phase of a release.)
> >
> > TOTAL (count: 21)
> >
> > I grouped the repositories by category, and listed them in a
> > topological order. Keep in mind that when flattening out a tree, there
> > are multiple possibilities. For example, OptaPlanner could've been
> > placed in any position after Drools.
> >
> > Category A repos are what I've been referring to as `drools` and
> > `kogito-*` stream. Of course OptaPlanner is inside that stream, as the
> > way these repositories reference each other are through Maven
> > SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This mechanism
> > is well-known to the team, and although flawed for intra-day builds
> > and disruptive for people in many different time zones, it is already
> > very comfortable for everyone to work with, I assume.
> >
> > Contributions made to Category A have some dedicated pipelines, which
> > are, at least to some extent, able to build cross-repo PRs together
> > and verify that the codebase will continue working as expected after
> > they're all merged. From what I could gather, there are some
> > "sub-streams" currently configured for cross-repo PRs.
> >
> > - kogito-pipelines
> > - drools, kogito-runtimes, kogito-apps, and kogito-examples
> > - optaplanner, and optaplanner-quickstarts
> > - kogito-images, and kogito-serverless-operator
> > - kogito-docs
> > - kie-docs
> >
> > This means that sending cross-repo PRs to any combination of repos
> > that are not part of the same "sub-stream" cannot be verified before
> > merging, making our contribution model dependent on individual
> > contributors building stuff on their machines to verify that it works.
> >
> > I based this analysis on
> >
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> > ,
> >
> >
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> > ,
> > and
> >
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> > .
> > Note that I'm not that familiar with these pipelines, so please
> > someone correct me if I'm wrong.
> >
> > Category B repos are what I've been referring to as `kie-tools`
> > stream. The first repo there is a template repository that is used by
> > people starting projects from scratch on KIE Sandbox, similar to a
> > Maven archetype, if you will. The other one is the KIE Tools monorepo,
> > a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> > Tools hosts Java libraries and apps, TypeScript libraries and apps, Go
> > apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> > configured to work with sparse checkouts and can do partial builds.
> > Category B repos refer to Category A repos through timestamped
> > SNAPSHOTs. This is a new mechanism we recently introduced that will
> > build and publish immutable, persistent artifacts under a version
> > following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> > Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> > releases, as we're now targeting one release for all of Apache KIE, so
> > we can't have Kogito releases anymore.
> >
> > An important note here is that Category B repositories have been
> > historically kept out of any automations we used to have, way back
> > when Kogito started and we had the Business Central (a.k.a. v7) stream
> > still going on. For this reason, Category B projects have developed
> > their own automations, based on GitHub Actions. Category B repos have
> > always depended on Category A repos using fixed versions. If Category
> > B repos have had adopted mutable SNAPSHOTs, breaking changes on
> > Category A repositories would've had the potential to break Category B
> > silently, leaving Category B with a broken development stream, and
> > introducing unpleasant surprises for maintainers of Category B repos,
> > as historically Category A contributors were not familiar with
> > Category B repos.
> >
> > Contributions made to Category B repos go through a GitHub Actions
> > workflow that builds the relevant part of the `kie-tools` monorepo for
> > the changes introduced. Changes made to the pipeline itself are also
> > picked up as part of PRs, allowing us to do things like atomically
> > bumping the Node.js version, for example. More importantly, it allows
> > us to upgrade the repository to a new timestamped SNAPSHOT together
> > with the changes necessary to make it stay green.
> >
> > This setup, however, makes it impossible to have cross-repo PRs
> > involving Category A and Category B simultaneously, with the current
> > automations we have.
> >
> > Category C repos are kind of floating around, and I'm not sure if
> > there's much activity going on there. Regardless, as they're part of
> > Apache KIE, they will be part of our release, so I listed them for us
> > to take them into consideration too.
> >
> > Category D is self explanatory. There's only one repo that has already
> > been marked for being archived.
> >
> > Category E are repos that do not host code directly, and are either
> > organizational entities, or host websites, that currently are not part
> > of any pipelines we have.
> >
> > This lack of unification between Category A and Category B is, IMHO,
> > what allowed us to introduce the infamous circular dependency between
> > `kie-tools` and `kogito-apps`, which we now can describe as a circular
> > dependency between Category A and Category B. The way I see it, if we
> > had a single pipeline, building everything from `drools` to
> > `kie-tools`, such flaws would've never been introduced, and we
> > wouldn't be having this huge problem in our hands right now.
> >
> > My proposal for the Apache KIE release process sees this lack of
> > unification as a central problem, not only for this release in
> > particular, but for the community as a whole. It is my belief that we
> > are all under the same roof, and that no contribution should be
> > allowed to break any part of our codebase. With the increasing volume
> > of code, and hopefully number of contributors too, we cannot keep
> > counting on "common sense" to avoid breaking things. We're all humans
> > after all, and it is our job to have mechanisms in place to prevent us
> > from unwillingly making mistakes. Especially when these mistakes
> > impact on parts of the codebase that we, individually, probably can't
> > fix.
> >
> >
> > # THE PROBLEMS WE HAVE RIGHT NOW
> >
> > P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> > `0.32.0`.
> > See:
> > -
> >
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
> >
> >
> > P2. PR open for Kogito SWF images @ `kogito-images` depending on
> > kiegroup's KIE Tools `0.32.0`.
> > See:
> > -
> >
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
> >
> >
> > P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> > `kie-soup` artifacts at version `7.59.0.Final`.
> > See:
> > -
> >
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> > -
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
> >
> >
> > P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> > Explainability `1.22.1.Final`.
> > * This module was removed from the KIE codebase here:
> >
> >
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> > and now lives on
> > https://github.com/trustyai-explainability/trustyai-explainability,
> > under a different GAV.
> > * This new repo depends on Kogito and OptaPlanner, pointing to older
> > versions.
> > See:
> > -
> >
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> > -
> >
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
> >
> >
> > P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> > `1.32.0.Final` and Quarkus `2.15.3.Final`.
> > See:
> > -
> >
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
> >
> >
> > P6. Category C repos are out of date and not part of the Category A
> > CI/Release pipelines.
> > * incubator-kie-kogito-benchmarks: (Current version is `2.0-SNAPSHOT`,
> > depending on Kogito without a specific version, only by using
> > `http://localhost:8080`)
> > * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> > pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
> >
> >
> > P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled after
> > upgrading to 999-20240218-SNAPSHOT.
> >
> >
> > In my perspective, P1 and P2 have the same solution, as they both
> > suffer from the circular dependency between Category A and Category B.
> > As Category A and Category B are both streams that have been really
> > active, I see this as a blocker, as there are contributions that
> > cannot be done, given that Category A depends on Category B with a
> > dephasing of 1 release.
> >
> > P3 and P4, although not ideal, can be understood as technical debt.
> > Depending on unmaintained projects is something we'll always be
> > susceptible to, given time.
> >
> > P5 and P6 are easily fixable, as it's just a matter of making them
> > part of the play.
> >
> > P7 is an isolated problem that won't impact the structure or anything
> > that we're talking about here, but it is a regression we introduced
> > recently.
> >
> > Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> > and P7 have easy fixes, the only problems left to discuss are P1 and
> > P2, which can't be done without a proper proposal.
> >
> >
> > # THE PROPOSAL
> >
> > I'll try to be very meticulous here, since from my experience, any
> > little miscalculation can lead to our release not working out in the
> > end. To try and avoid that as much as possible, and make everything we
> > can to have a successful Apache KIE 10 release, bear with me. I'll lay
> > out a timeline of events that need to happen in order for our release
> > to be published, with all artifacts ending up in the right places, but
> > first, we need to solve problems P1 and P2.
> >
> > As you saw at the beginning of this email, all the attempts we made
> > left us with the circular dependency showing up at a different place,
> > but something all these places have in common is that they're all
> > after kogito-apps, and before to Category B.
> >
> > The first part of my proposal is the following:
> >
> > S1. We keep the original plan of moving the Quarkus Dev UIs from
> > `kogito-apps` to `kie-tools`, together with Management and Task
> > consoles from `kogito-images` to `kie-tools`.
> > S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> > from `kogito-images` to `kie-tools` too.
> > S3. We move the entire `kogito-serverless-operator` repo inside a new
> > package on `kie-tools`, keeping Git history.
> >
> > Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> > the rest of https://github.com/apache/incubator-kie-issues/issues/967
> > would still be done too.
> >
> > This doesn't come without consequences, of course, as the
> > `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> > `kogito-serverless-operator` would be moving from Category A to
> > Category B. This move would make them have to reference Category A
> > repos through timestamped SNAPSHOTs. Since `kogito-images` and
> > `kogito-serverless-operator` are already their own "sub-stream" inside
> > Category A, though, contributions made in a cross-repo fashion to this
> > "sub-stream" will continue being possible, now via a single PR to
> > `kie-tools`. Cross-repo PRs between Category A and Category B will
> > continue not being possible, and a 1-week delay between merging
> > something on Category A and using it on Category B will still happen.
> >
> > It's worth mentioning that `kie-tools`, however, does allow for sparse
> > checkouts and partial builds, so working with a subset of the monorepo
> > is possible and encouraged. Making changes only to
> > `packages/kn-plugin-workflow`, for example, will have the PR checks
> > run in < 10 minutes, as you can see here:
> >
> >
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> > .
> > We're not compromising when running partial builds too. We know that
> > the entire repo will continue working even after only building a small
> > subset of the changes. Doing partial or full builds is automatically
> > determined by the changes of a PR.
> >
> > Keep in mind that, even though I'm proposing we move a bunch of
> > additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> > for our codebase. `kie-tools` would host some additional stuff
> > TEMPORARILY so that we can release and continue moving forward.
> >
> > As I mentioned on other places, `kie-tools` became a polyglot monorepo
> > out of necessity, and although I'm really proud of what we achieved
> > there so far, I don't think `kie-tools` has a setup that is suitable
> > for all the different nuances that compose our community. I'm well
> > aware that a polyglot monorepo that does not follow widespread
> > conventions will scare some people away, and as much as we've tried to
> > make build instructions clear, we can't always get past the prejudice
> > some people have towards the "front-end" ecosystem.
> >
> > With all that said, I keep thinking this is the best course of action
> > for us right now. We keep most of our stuff unchanged, we unblock the
> > release, and we have a working setup that will suit us well while we
> > discuss and reach a conclusion regarding the future of our codebase
> > structure.
> >
> > Let me paint a quick picture here of what our code base would look
> > like, repository-wise, if my proposal is accepted:
> >
> > CATEGORY REPO
> > =====================
> > A incubator-kie-kogito-pipelines
> > A incubator-kie-drools
> > A incubator-kie-optaplanner
> > A incubator-kie-optaplanner-quickstarts
> > A incubator-kie-kogito-runtimes
> > A incubator-kie-kogito-apps
> > A incubator-kie-kogito-examples
> > A incubator-kie-kogito-images
> > A incubator-kie-kogito-docs
> > A incubator-kie-kogito-benchmarks
> > A incubator-kie-docs
> > A incubator-kie-benchmarks
> > =====================
> > B incubator-kie-sandbox-quarkus-accelerator
> > B incubator-kie-tools
> > =====================
> > D incubator-kie-kogito-operator
> > =====================
> > E incubator-kie-issues
> > E incubator-kie-kogito-website
> > E incubator-kie-website
> > E incubator-kie-kogito-online
> > E incubator-kie-kogito-online-staging
> > =====================
> >
> > * Category C becomes part of Category A, and
> > `kogito-serverless-operator` moves entirely inside `kie-tools`.
> > * With `kogito-swf-{builder,devmode}` images and
> > `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> > anymore, as inside `kie-tools`, we can granularly build:
> > 1. packages/sonataflow-deployment-webapp
> > 2. packages/sonataflow-quarkus-devui
> > 3. packages/sonataflow-images (containing `kogito-swf-builder` and
> > `kogito-swf-devmode`)
> > 4. packages/sonataflow-operator (contents from
> > `kogito-serverless-operator`)
> > 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> > but renamed)
> >
> > The second part of the proposal is the release process itself,
> > assuming the structure above is what we have.
> >
> > Here it is:
> >
> > 1. Define a timestamped SNAPSHOT to be used as cutting point for
> > Category A repos.
> > 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> > verify that everything is working.
> > 3. At this point, with everything working, we can branch out to
> > `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
> > from `main`.
> > 4. All Category A and Category B repos update their versions to
> > 10.0.0, in their `10.0.x` branches.
> > 5. Update Category B repos to point to Category A repos using the
> > 10.0.0 version.
> > 6. At this point, we can vote on the release based on the `10.0.x`
> > branches, given we don't expect any code changes anymore.
> > 7. After voting passes, we're good to start the release process.
> > 8. Category A repos follow their manual/automated release process,
> > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > artifacts pushed to their registries.
> > 9. We wait a little bit for Category A artifacts to be propagated on
> > registries. ~1 day.
> > 10. Category B repos follow their manual/automated release process,
> > pointing to the `10.0.x` branch. Tags pushed to Git, and built
> > artifacts pushed to their registries.
> > 11. Category D repos are ignored.
> > 12. Category E repos can be manually tagged with 10.0.0 from their
> > default branches.
> >
> > More needs to be discussed if we're planning to maintain multiple
> > release streams in parallel, but I guess it can wait for after Apache
> > KIE 10.
> >
> > Thank you for reading, and I'm looking forward to hearing back from
> > everyone.
> >
> > Of course, alternative solutions are possible. This email, however,
> > summarizes my view of how we should attack the problem, considering
> > disruption, required effort, the release process itself, and history.
> > Feel free to propose alternatives. This is not a voting thread.
> >
> > Regards,
> >
> > Tiago Bento
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: [PROPOSAL] Unblocking and releasing Apache KIE 10
Posted by Kris Verlaenen <kr...@gmail.com>.
TLDR: A +1 to the proposal from Tiago for the release, with the addition of
some short term recommendation (on how to revert some of the temporary
changes) and some perspective on a potential alternative to consider for
the long term
* Short term: The plan from Tiago describes a strategy that appears to be
able to solve the build cycle issues we have, allowing us to proceed with
the 10.0 release. We do realize that some of the changes that are being
done to be able to do the 10.0 release are going to be temporary.
Therefore, as part of this proposal, I urge the team to also document how
we are going to revert some of these temporary changes immediately after
the release (*). More specifically, my recommendation is that we agree
that the images and operator folder from kie-tools will be removed again
and development will continue on the existing repositories. But let’s
discuss if people see this differently or if there might be other steps.
The advantage of this approach would be that it allows us to move forward
with the release, does buy us time to find a consensus on the long-term
solution and minimizes the impact on the developers regarding temporary
solutions. And it also requires us to find this consensus before the next
release.
* Longer term: as discussed to some degree in this thread already, there
seems to be an alternative to explore where we define more strict
boundaries (for dependencies) between repositories, and create a build
chain where images and operator are built after tools. That said, it’s
fair to say that this proposal needs to be worked out and validated more,
and initial assessments on the effort related to this, if we don’t want to
rush into this and do things right, are indicating this might take multiple
months. We also need to discuss how we will be resourcing this effort.
And we could potentially combine this with other discussions that we will
have in the near future. So if we agree to investigate this further, I
would like to recommend moving forward with the more concrete temporary
solution that Tiago is proposing for the 10.0 release.
Note that this would mean that at this point, on this thread, we don’t need
to agree on the specifics of any alternative proposal longer-term, we can
start a different conversation thread for this. I hope this can convince
people to +1 the approach as described by Tiago short term for the release,
with the addition of the recipe how to revert some of the temporary changes
and the promise to further evaluate longer-term alternatives. For those
that are interested, I wanted to also give an indication what this proposal
might mean at a high level from my point of view, which is included below.
Thx,
Kris
[Optional reading] Alternative longer-term proposal
One could subdivide the work we do in two main streams: one focused more on
the runtimes, one focused more on the tooling. In general a lot of tooling
can be built independently from the runtime and vice versa, where they
communicate with each other through well defined formats or apis. However,
once we start looking at more advanced use cases and the full end-to-end,
this is where we need both tooling and runtime together.
The goal is to create one release pipeline(**). The issue with cyclic
dependencies between repos is imho twofold: 1) we haven’t been 100%
consistent in separating runtimes and tooling this way and 2) we haven’t
accommodated well for use cases where runtime and tooling needs to be
combined. Note that some of these dependencies might not be build time
dependencies but test and/or runtime dependencies only.
As an alternative to one kie-tools monorepo that combines tooling and
images and operator, I believe we can construct a pipeline where most of
runtime and tooling can be built independently, but after runtime and
tooling are built, we complete the build with other
components/repositories, because they logically rely more on both.
Examples of components that rely on both are for example be a devui
extension (a quarkus extension that embeds tooling) or the devmode image
(that also includes tooling features), or integration testing (where we
want to test whether tooling and runtime work well together.
More specifically, this would mean
1) making sure that there are well-defined boundaries between the core
runtimes and core tooling so they don’t depend on each other at build
time. We can decide to move components around where we think that makes
sense, for example:
move ui code related to devui into kie-tools (as discussed before)
move kn-workflow to the operator repository as it more closely related to
that
2) update the CI and release pipelines so that core runtime and tooling
repositories can be built first, and are followed up by other repositories
like images and operator, that could then rely on both.
(*) Note that there would be other options technically to achieve this,
like cutting a release branch early and performing the changes only there,
but given other work is still ongoing as well, we want to minimize the
cherry-picking effort.
(**) Note that while the goal is to create one release pipeline, this
should not necessarily mean that we can’t have smaller or optimized
pipelines for CI and daily development, where the impact of changes is
typically more localized.
On Tue, Mar 12, 2024 at 8:45 PM Tiago Bento <ti...@apache.org> wrote:
> Hi everyone,
>
> Unfortunately, I can't do a tl;dr this time, as this matter requires a
> lot of context.
>
> This email will take you < 20 minutes to read, according to
> https://thereadtime.com/.
>
> As you may have followed on a separate thread
> (https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69),
> many of us were working towards removing a circular dependency
> currently present between `kogito-apps` and `kie-tools`. As we
> progressed towards a solution, we kept finding the circular dependency
> pop up somewhere else. I'll do a breakdown of the things we did, and
> the results we had.
>
> Right now, even though we started the effort to move the Quarkus Dev
> UI modules to `kie-tools`, we haven't been able to do it yet, as we've
> been busy upgrading KIE Tools to Java 17, Maven 3.9.6, and Quarkus
> 3.2.9, compatible with Kogito Runtimes 999-20240218-SNAPSHOT. This
> effort was concluded this Monday, with
> https://github.com/apache/incubator-kie-tools/pull/2136.
>
> The current scenario we have is:
>
> 01. incubator-kie-kogito-runtimes
> |==> 02. incubator-kie-kogito-apps
> C | 03. incubator-kie-kogito-examples
> Y | 04. incubator-kie-kogito-images
> C | 05. incubator-kie-kogito-serverless-operator
> L | ==========================
> E | 06. incubator-kie-sandbox-quarkus-accelerator
> |==> 07. incubator-kie-tools
>
>
> * As `kie-tools`/extended-services depends on
> `kogito-apps`/jitexecutor;
> * and `kogito-apps`/{sonataflow,bpmn}-quarkus-devui depend on
> `kie-tools`/{many packages}
>
>
> After moving the Quarkus Dev UIs to `kie-tools`, we would've had:
>
> 01. incubator-kie-kogito-runtimes
> 02. incubator-kie-kogito-apps
> 03. incubator-kie-kogito-examples
> C |==> 04. incubator-kie-kogito-images
> Y | 05. incubator-kie-kogito-serverless-operator
> C | =====================
> L | 06. incubator-kie-sandbox-quarkus-accelerator
> E |==> 07. incubator-kie-tools
>
> * As `kie-tools`/kn-plugin-workflow depends on
> `kogito-images`/kogito-swf-devmode;
> * and `kogito-images`/kogito-swf-devmode depends on
> `kie-tools`/sonataflow-quarkus-devui
>
>
> After moving the `kogito-swf-devmode` image to `kie-tools`, we would've
> had:
>
> 01. incubator-kie-kogito-runtimes
> 02. incubator-kie-kogito-apps
> 03. incubator-kie-kogito-examples
> 04. incubator-kie-kogito-images
> C |==> 05. incubator-kie-kogito-serverless-operator
> Y | =====================
> C | 06. incubator-kie-sandbox-quarkus-accelerator
> L |==> 07. incubator-kie-tools
> E
>
> * As `kie-tools`/kn-plugin-workflow depends on
> `kogito-serverless-operator`;
> * and `kogito-serverless-operator` depends on
> `kie-tools`/kogito-swf-devmode
>
>
> Clearly, we have a much bigger problem than a simple circular dependency.
>
> After multiple conversations with a lot of people, it's been really
> hard coming up with a simple solution that makes it possible to build
> Apache KIE in one shot, while preserving the way everyone is used to
> contributing to the multiple repositories we have. More than that,
> while making this assessment, I found more problems that, in my
> perspective, block Apache KIE 10.
>
> In light of that difficulty, I'm coming forward with my proposal for
> the Apache KIE release process, so we can use Apache's mechanisms to
> have a slower-paced, in-depth debate about this really complicated
> matter.
>
> I'll lay out my entire perspective about the current situation of our
> codebase, as well as problems I can currently see. I'll start with an
> analysis of the repositories and their purposes, point out some
> problems that I believe are blocking our 10 release, explain my
> proposal and discuss some consequences to what I'm proposing.
>
> Let's begin.
>
>
> # THE APACHE KIE REPOS
>
> A. DROOLS OPTAPLANNER, & KOGITO (count: 11)
> - incubator-kie-kogito-pipelines @ `main`
> - incubator-kie-drools @ `main`
> - incubator-kie-optaplanner @ `main`
> - incubator-kie-optaplanner-quickstarts @ `main`
> - incubator-kie-kogito-runtimes @ `main`
> - incubator-kie-kogito-apps @ `main`
> - incubator-kie-kogito-examples @ `main`
> - incubator-kie-kogito-images @ `main`
> - incubator-kie-kogito-serverless-operator @ `main`
> - incubator-kie-kogito-docs @ `main`
> - incubator-kie-docs @ `main-kogito`
>
> B. TOOLS (count: 2)
> - incubator-kie-sandbox-quarkus-accelerator @ `0.0.0`
> - incubator-kie-tools @ `main`
>
> C. BENCHMARKS (count: 2)
> - incubator-kie-kogito-benchmarks @ `main`
> - incubator-kie-benchmarks @ `main`
>
> D. ARCHIVED (count: 1)
> - incubator-kie-kogito-operator
>
> E. "NON-CODE" (count: 5)
> - incubator-kie-issues @ `main`
> (Issues only, README should be updated @ `main`. Same for GitHub
> Actions workflows.)
> - incubator-kie-kogito-website @ `main`
> (The Kogito website. Develop & deploy at the `main` branch.)
> - incubator-kie-website @ `main`
> (The KIE website. Develop @ `main`. Push @ `deploy` to update the
> website.)
> - incubator-kie-kogito-online @ `gh-pages`
> (GitHub pages used to host sandbox.kie.org and KIE Tools' Chrome
> Extension assets.)
> - incubator-kie-kogito-online-staging @ `main`
> (Same as above, but for manual sanity checks during the staging
> phase of a release.)
>
> TOTAL (count: 21)
>
> I grouped the repositories by category, and listed them in a
> topological order. Keep in mind that when flattening out a tree, there
> are multiple possibilities. For example, OptaPlanner could've been
> placed in any position after Drools.
>
> Category A repos are what I've been referring to as `drools` and
> `kogito-*` stream. Of course OptaPlanner is inside that stream, as the
> way these repositories reference each other are through Maven
> SNAPSHOTs. More specifically, the 999-SNAPSHOT version. This mechanism
> is well-known to the team, and although flawed for intra-day builds
> and disruptive for people in many different time zones, it is already
> very comfortable for everyone to work with, I assume.
>
> Contributions made to Category A have some dedicated pipelines, which
> are, at least to some extent, able to build cross-repo PRs together
> and verify that the codebase will continue working as expected after
> they're all merged. From what I could gather, there are some
> "sub-streams" currently configured for cross-repo PRs.
>
> - kogito-pipelines
> - drools, kogito-runtimes, kogito-apps, and kogito-examples
> - optaplanner, and optaplanner-quickstarts
> - kogito-images, and kogito-serverless-operator
> - kogito-docs
> - kie-docs
>
> This means that sending cross-repo PRs to any combination of repos
> that are not part of the same "sub-stream" cannot be verified before
> merging, making our contribution model dependent on individual
> contributors building stuff on their machines to verify that it works.
>
> I based this analysis on
>
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml
> ,
>
> https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml
> ,
> and
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml
> .
> Note that I'm not that familiar with these pipelines, so please
> someone correct me if I'm wrong.
>
> Category B repos are what I've been referring to as `kie-tools`
> stream. The first repo there is a template repository that is used by
> people starting projects from scratch on KIE Sandbox, similar to a
> Maven archetype, if you will. The other one is the KIE Tools monorepo,
> a polyglot monorepo with `pnpm` as its build system. Currently, KIE
> Tools hosts Java libraries and apps, TypeScript libraries and apps, Go
> apps, Docker images, and Helm charts. The `kie-tools` monorepo is
> configured to work with sparse checkouts and can do partial builds.
> Category B repos refer to Category A repos through timestamped
> SNAPSHOTs. This is a new mechanism we recently introduced that will
> build and publish immutable, persistent artifacts under a version
> following the 999-YYYYMMDD-SNAPSHOT format, published weekly every
> Sunday night. Timestamped SNAPSHOTs are an evolution to the Kogito
> releases, as we're now targeting one release for all of Apache KIE, so
> we can't have Kogito releases anymore.
>
> An important note here is that Category B repositories have been
> historically kept out of any automations we used to have, way back
> when Kogito started and we had the Business Central (a.k.a. v7) stream
> still going on. For this reason, Category B projects have developed
> their own automations, based on GitHub Actions. Category B repos have
> always depended on Category A repos using fixed versions. If Category
> B repos have had adopted mutable SNAPSHOTs, breaking changes on
> Category A repositories would've had the potential to break Category B
> silently, leaving Category B with a broken development stream, and
> introducing unpleasant surprises for maintainers of Category B repos,
> as historically Category A contributors were not familiar with
> Category B repos.
>
> Contributions made to Category B repos go through a GitHub Actions
> workflow that builds the relevant part of the `kie-tools` monorepo for
> the changes introduced. Changes made to the pipeline itself are also
> picked up as part of PRs, allowing us to do things like atomically
> bumping the Node.js version, for example. More importantly, it allows
> us to upgrade the repository to a new timestamped SNAPSHOT together
> with the changes necessary to make it stay green.
>
> This setup, however, makes it impossible to have cross-repo PRs
> involving Category A and Category B simultaneously, with the current
> automations we have.
>
> Category C repos are kind of floating around, and I'm not sure if
> there's much activity going on there. Regardless, as they're part of
> Apache KIE, they will be part of our release, so I listed them for us
> to take them into consideration too.
>
> Category D is self explanatory. There's only one repo that has already
> been marked for being archived.
>
> Category E are repos that do not host code directly, and are either
> organizational entities, or host websites, that currently are not part
> of any pipelines we have.
>
> This lack of unification between Category A and Category B is, IMHO,
> what allowed us to introduce the infamous circular dependency between
> `kie-tools` and `kogito-apps`, which we now can describe as a circular
> dependency between Category A and Category B. The way I see it, if we
> had a single pipeline, building everything from `drools` to
> `kie-tools`, such flaws would've never been introduced, and we
> wouldn't be having this huge problem in our hands right now.
>
> My proposal for the Apache KIE release process sees this lack of
> unification as a central problem, not only for this release in
> particular, but for the community as a whole. It is my belief that we
> are all under the same roof, and that no contribution should be
> allowed to break any part of our codebase. With the increasing volume
> of code, and hopefully number of contributors too, we cannot keep
> counting on "common sense" to avoid breaking things. We're all humans
> after all, and it is our job to have mechanisms in place to prevent us
> from unwillingly making mistakes. Especially when these mistakes
> impact on parts of the codebase that we, individually, probably can't
> fix.
>
>
> # THE PROBLEMS WE HAVE RIGHT NOW
>
> P1. Quarkus Dev UIs @ `kogito-apps` depending on kiegroup's KIE Tools
> `0.32.0`.
> See:
> -
> https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code
>
>
> P2. PR open for Kogito SWF images @ `kogito-images` depending on
> kiegroup's KIE Tools `0.32.0`.
> See:
> -
> https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp
>
>
> P3. DashBuilder @ `kie-tools` depending on kiegroup's `lienzo` and
> `kie-soup` artifacts at version `7.59.0.Final`.
> See:
> -
> https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64
> -
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code
>
>
> P4. Multiple packages @ `kogito-apps` depending on kiegroup's
> Explainability `1.22.1.Final`.
> * This module was removed from the KIE codebase here:
>
> https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965
> and now lives on
> https://github.com/trustyai-explainability/trustyai-explainability,
> under a different GAV.
> * This new repo depends on Kogito and OptaPlanner, pointing to older
> versions.
> See:
> -
> https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code
> -
> https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53
>
>
> P5. `incubator-kie-sandbox-quarkus-accelerator` depending on Kogito
> `1.32.0.Final` and Quarkus `2.15.3.Final`.
> See:
> -
> https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38
>
>
> P6. Category C repos are out of date and not part of the Category A
> CI/Release pipelines.
> * incubator-kie-kogito-benchmarks: (Current version is `2.0-SNAPSHOT`,
> depending on Kogito without a specific version, only by using
> `http://localhost:8080`)
> * incubator-kie-benchmarks: (Current version is `1.0-SNAPSHOT`,
> pointing to Drools 999-SNAPSHOT and OptaPlanner `8.45.0-SNAPSHOT`)
>
>
> P7. `kie-tools`/packages/kn-plugin-workflow has its E2E disabled after
> upgrading to 999-20240218-SNAPSHOT.
>
>
> In my perspective, P1 and P2 have the same solution, as they both
> suffer from the circular dependency between Category A and Category B.
> As Category A and Category B are both streams that have been really
> active, I see this as a blocker, as there are contributions that
> cannot be done, given that Category A depends on Category B with a
> dephasing of 1 release.
>
> P3 and P4, although not ideal, can be understood as technical debt.
> Depending on unmaintained projects is something we'll always be
> susceptible to, given time.
>
> P5 and P6 are easily fixable, as it's just a matter of making them
> part of the play.
>
> P7 is an isolated problem that won't impact the structure or anything
> that we're talking about here, but it is a regression we introduced
> recently.
>
> Assuming P3 and P4 can be ignored for Apache KIE 10, and that P5, P6,
> and P7 have easy fixes, the only problems left to discuss are P1 and
> P2, which can't be done without a proper proposal.
>
>
> # THE PROPOSAL
>
> I'll try to be very meticulous here, since from my experience, any
> little miscalculation can lead to our release not working out in the
> end. To try and avoid that as much as possible, and make everything we
> can to have a successful Apache KIE 10 release, bear with me. I'll lay
> out a timeline of events that need to happen in order for our release
> to be published, with all artifacts ending up in the right places, but
> first, we need to solve problems P1 and P2.
>
> As you saw at the beginning of this email, all the attempts we made
> left us with the circular dependency showing up at a different place,
> but something all these places have in common is that they're all
> after kogito-apps, and before to Category B.
>
> The first part of my proposal is the following:
>
> S1. We keep the original plan of moving the Quarkus Dev UIs from
> `kogito-apps` to `kie-tools`, together with Management and Task
> consoles from `kogito-images` to `kie-tools`.
> S2. We move the `kogito-swf-devmode` and `kogito-swf-builder` images
> from `kogito-images` to `kie-tools` too.
> S3. We move the entire `kogito-serverless-operator` repo inside a new
> package on `kie-tools`, keeping Git history.
>
> Solutions S1, S2, and S3 together solve problems P1 and P2. Of course
> the rest of https://github.com/apache/incubator-kie-issues/issues/967
> would still be done too.
>
> This doesn't come without consequences, of course, as the
> `kogito-swf-devmode` and `kogito-swf-builder` images, and the
> `kogito-serverless-operator` would be moving from Category A to
> Category B. This move would make them have to reference Category A
> repos through timestamped SNAPSHOTs. Since `kogito-images` and
> `kogito-serverless-operator` are already their own "sub-stream" inside
> Category A, though, contributions made in a cross-repo fashion to this
> "sub-stream" will continue being possible, now via a single PR to
> `kie-tools`. Cross-repo PRs between Category A and Category B will
> continue not being possible, and a 1-week delay between merging
> something on Category A and using it on Category B will still happen.
>
> It's worth mentioning that `kie-tools`, however, does allow for sparse
> checkouts and partial builds, so working with a subset of the monorepo
> is possible and encouraged. Making changes only to
> `packages/kn-plugin-workflow`, for example, will have the PR checks
> run in < 10 minutes, as you can see here:
>
> https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136
> .
> We're not compromising when running partial builds too. We know that
> the entire repo will continue working even after only building a small
> subset of the changes. Doing partial or full builds is automatically
> determined by the changes of a PR.
>
> Keep in mind that, even though I'm proposing we move a bunch of
> additional stuff into `kie-tools`, I see this as a TEMPORARY solution
> for our codebase. `kie-tools` would host some additional stuff
> TEMPORARILY so that we can release and continue moving forward.
>
> As I mentioned on other places, `kie-tools` became a polyglot monorepo
> out of necessity, and although I'm really proud of what we achieved
> there so far, I don't think `kie-tools` has a setup that is suitable
> for all the different nuances that compose our community. I'm well
> aware that a polyglot monorepo that does not follow widespread
> conventions will scare some people away, and as much as we've tried to
> make build instructions clear, we can't always get past the prejudice
> some people have towards the "front-end" ecosystem.
>
> With all that said, I keep thinking this is the best course of action
> for us right now. We keep most of our stuff unchanged, we unblock the
> release, and we have a working setup that will suit us well while we
> discuss and reach a conclusion regarding the future of our codebase
> structure.
>
> Let me paint a quick picture here of what our code base would look
> like, repository-wise, if my proposal is accepted:
>
> CATEGORY REPO
> =====================
> A incubator-kie-kogito-pipelines
> A incubator-kie-drools
> A incubator-kie-optaplanner
> A incubator-kie-optaplanner-quickstarts
> A incubator-kie-kogito-runtimes
> A incubator-kie-kogito-apps
> A incubator-kie-kogito-examples
> A incubator-kie-kogito-images
> A incubator-kie-kogito-docs
> A incubator-kie-kogito-benchmarks
> A incubator-kie-docs
> A incubator-kie-benchmarks
> =====================
> B incubator-kie-sandbox-quarkus-accelerator
> B incubator-kie-tools
> =====================
> D incubator-kie-kogito-operator
> =====================
> E incubator-kie-issues
> E incubator-kie-kogito-website
> E incubator-kie-website
> E incubator-kie-kogito-online
> E incubator-kie-kogito-online-staging
> =====================
>
> * Category C becomes part of Category A, and
> `kogito-serverless-operator` moves entirely inside `kie-tools`.
> * With `kogito-swf-{builder,devmode}` images and
> `kogito-serverless-operator` inside `kie-tools`, there are no cycles
> anymore, as inside `kie-tools`, we can granularly build:
> 1. packages/sonataflow-deployment-webapp
> 2. packages/sonataflow-quarkus-devui
> 3. packages/sonataflow-images (containing `kogito-swf-builder` and
> `kogito-swf-devmode`)
> 4. packages/sonataflow-operator (contents from
> `kogito-serverless-operator`)
> 5. packages/kn-plugin-sonataflow (`packages/kn-plugin-workflow`,
> but renamed)
>
> The second part of the proposal is the release process itself,
> assuming the structure above is what we have.
>
> Here it is:
>
> 1. Define a timestamped SNAPSHOT to be used as cutting point for
> Category A repos.
> 2. Update Category B repos to point to this timestamped SNAPSHOT, and
> verify that everything is working.
> 3. At this point, with everything working, we can branch out to
> `10.0.x`. Category A from the timestamped SNAPSHOT tag, and Category B
> from `main`.
> 4. All Category A and Category B repos update their versions to
> 10.0.0, in their `10.0.x` branches.
> 5. Update Category B repos to point to Category A repos using the
> 10.0.0 version.
> 6. At this point, we can vote on the release based on the `10.0.x`
> branches, given we don't expect any code changes anymore.
> 7. After voting passes, we're good to start the release process.
> 8. Category A repos follow their manual/automated release process,
> pointing to the `10.0.x` branch. Tags pushed to Git, and built
> artifacts pushed to their registries.
> 9. We wait a little bit for Category A artifacts to be propagated on
> registries. ~1 day.
> 10. Category B repos follow their manual/automated release process,
> pointing to the `10.0.x` branch. Tags pushed to Git, and built
> artifacts pushed to their registries.
> 11. Category D repos are ignored.
> 12. Category E repos can be manually tagged with 10.0.0 from their
> default branches.
>
> More needs to be discussed if we're planning to maintain multiple
> release streams in parallel, but I guess it can wait for after Apache
> KIE 10.
>
> Thank you for reading, and I'm looking forward to hearing back from
> everyone.
>
> Of course, alternative solutions are possible. This email, however,
> summarizes my view of how we should attack the problem, considering
> disruption, required effort, the release process itself, and history.
> Feel free to propose alternatives. This is not a voting thread.
>
> Regards,
>
> Tiago Bento
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>