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 <[email protected]> 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 > <[email protected]> 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 < > [email protected]> > > 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 > > > <[email protected]> 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 < > > > [email protected]> > > > > 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 > > > > > <[email protected]> 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 < > [email protected]> > > > > > 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 < > [email protected]> > > > > > 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 < > > > > > > > [email protected]> > > > > > > > > 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 > > > > > > > < > > > > > > > > > [email protected]> 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 < > > > > > [email protected]> > > > > > > > > > > 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 < > > > > > > > > > > > [email protected]> 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 < > > > > > [email protected] > > > > > > > > > > > > > > > > > > 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 < > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > 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 > > > > > > > > > > > > < > > > > > > > > > > > > > > [email protected]> 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 > < > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > > > > > > > > > > [email protected]> 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 > > > > > > > > > > > < > > > > > > > > > > > > > > > > > [email protected]> 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 > > > > > > > > > > < > > > > > > > > > > > > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> +1 to unblock release > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere > Fernandez > > > > > (apache) > > > > > > > < > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > >> escribió: > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > I say +1 in order to move forward with > > > the 10. > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex > > > Porcelli < > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > < > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > >> > 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: > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > >> > > > For additional commands, e-mail: > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
