Francisco,
Unfortunately we just learned all this very recently… and, as we keep
digging more, we keep finding more (new dependencies between images and
tools has been found on serverless workflow).
I’d argue that this discussion is in the end positive, because we all could
realize the importance of CI and the required need to organize codebase in
a more sustainable way.
On Thu, Mar 14, 2024 at 1:43 PM Francisco Javier Tirado Sarti <
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
> > > >
