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 <ftira...@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ý <jstastn...@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 < > > ftira...@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 < > > > ricardozan...@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 < > > > tiagobentofernan...@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 > > > > > <ftira...@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 < > > > > > tiagobentofernan...@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 > > > > > > > <ftira...@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 < > > > > > > > tiagobentofernan...@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 > > > > > > > > > <ftira...@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 < > > > > > tiagobe...@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 < > > > > > a...@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.card...@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 > > > > > > > > > > > < > > > > > > > > > > > > > ftira...@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 < > > > > > > > > > porce...@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 < > > > > > > > > > > > > > > > ftira...@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 > > < > > > > > > > > > a...@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.card...@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 > > > > > > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > ftira...@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 > > > > > < > > > > > > > > > > > > > a...@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 < > > > > > > > > > > > > > > > > > > > > ftira...@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 > > > > > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > ftira...@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 > > > > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > egonza...@apache.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> +1 to unblock release > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere > > > > > Fernandez > > > > > > > > > (apache) > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > pefer...@apache.org> > > > > > > > > > > > > > > > > > > > > > >> escribió: > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > >> > I say +1 in order to move > > forward > > > > with > > > > > > > the 10. > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, > > Alex > > > > > > > Porcelli < > > > > > > > > > > > > > > > > a...@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 > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > tiagobe...@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-unsubscr...@kie.apache.org > > > > > > > > > > > > > > > > > > > > > >> > > > For additional commands, > > > e-mail: > > > > > > > > > > > > > > > > dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > > > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
