I think we all want to unblock the release, the question is how, because one way or another we need to do something to unblock it. If the proposed solution was one that was not really jeopardizing the evolution of the project, I will accept it. But since I really believe the proposed solution is not better, it does not necessarily take less time to achieve than the alternative I mentioned, can someone fluent on CI tell everyone how much it really cost to tell our current CI to compile tools repo before operator one?
On Wed, Mar 13, 2024 at 2:26 PM Tibor Zimányi <tzima...@apache.org> wrote: > Hi everyone, > > I just want to remind everyone, that we have not released a release for > more than half a year (6 months). We are being constantly asked, when will > we release a new release, due to multiple reasons. E.g. Quarkus 3 support, > newer Java support etc. Keep in mind that the current release, that is out, > is outdated on many fronts, e.g. security, as it contains outdated > dependencies and frameworks support. I even heard the need to have a > release internally, from our commiters members, because they need it for > their projects that they are working on, and they are blocked, until we > have a new release. So I personally think we cannot solve the current > problem now. As Alex mentioned, I would also suggest to fix it for now as > it is proposed. After the release, we can discuss whatever we want, to fix > it properly. But we need to finally have a release. Everyone involved put > great effort to this (including people discussing in this thread), so I > have the feeling postponing the release for another two or more months will > just grow frustration within the community. > Please keep this all in mind. I think everyone would like to fix this > properly. However sometimes doing that just doesn't help at all at the > moment. Sometimes a temporary solution is better in my opinion. > > Best regards, > Tibor > > Dňa st 13. 3. 2024, 14:12 Alex Porcelli <porce...@apache.org> napísal(a): > > > Francisco, > > > > Please feel free to open a new thread with such a proposal, although I > > still consider that it’s necessary more details to be properly evaluated. > > > > Keep in mind that CI code, configs and infrastructure is accessible for > all > > committers. > > > > Please let’s keep this thread focused on the detailed proposal shared. > > > > In case of multiple proposals we can start an official vote. > > > > > > On Wed, Mar 13, 2024 at 9:05 AM Francisco Javier Tirado Sarti < > > ftira...@redhat.com> wrote: > > > > > I hardly see a difference in detail between the proposal to move > > > kn-workflow module from tooling to images (it should have never been in > > > tooling repo) plus changing CI stream to compile tooling repo before > > images > > > repo (which I hope we all agree is the natural order) and the proposal > to > > > move all stuff from images that depends on tooling to tooling repo > > (which I > > > hope we all agree hardly fits in current multi repo structure) and > sort > > > out the "details" on the ci pipeline associated to that repo (which > > implies > > > CI knowledge after all) > > > The key point here is, does Tiago (as tooling SME, it seems that there > > is a > > > tools team but there is not a drools team ;)) agree that tooling should > > be > > > executed before images because there is a logical dependency between > > images > > > and tooling? > > > In my opinion, the least we can do is to explore how it really costs to > > > change CI to execute tooling before images. > > > > > > > > > On Wed, Mar 13, 2024 at 1:36 PM Alex Porcelli <a...@porcelli.me> > wrote: > > > > > > > Francisco and Gabriele, > > > > > > > > I understand and acknowledge your desire to find the “right” solution > > > > instead to work on a temporary “patch” - however without a detailed > > > > proposal I don’t think we can properly evaluate the impact of your > > > > suggestion. > > > > > > > > When I spoke with different SMEs that included tools and CI, the > > > > guesstimate for making the necessary changes on CI and codebase to > > > > basically have images and operators in the end of the build chain is > > > > something like 2 months of effort. Another impact that needs to be > > > > discussed is that KIE Tools repo had to be injected in the middle of > > all > > > > pipelines - forcing all PR checks and nightlies to build all repos > (PR > > > > checks will likely take 12+ hours… I even heard that it could be even > > 24 > > > > hours). > > > > > > > > Based on the input above, I think it’s quite risk to move in such > > > direction > > > > without a more detailed plan… because 2 months could be turned easily > > in > > > 6! > > > > And this is exactly what happened when we guessed that moving to > Apache > > > > would take no more than 3 months. But here we are. > > > > > > > > I really strongly suggest that we focus on a release that could be > > > > achievable in less than a month from now, and we - after release - > > have a > > > > in depth discussion about the overall codebase and ci organization. > > > > > > > > > > > > On Wed, Mar 13, 2024 at 8:24 AM Gabriele Cardosi < > > > > gabriele.card...@gmail.com> > > > > wrote: > > > > > > > > > Alex, > > > > > my suggestion is to move the building of all docker images, from > > > whatever > > > > > repo (kogito-apps, kie-tools) in a different, downstream repo, to > be > > > > > invoked after all the others. > > > > > I'm not sure if this would solve all the issues, and since I could > > not > > > > > enter in the details of all the involved code, my suggestion may be > > too > > > > > naive. > > > > > Having spent almost all of the last year in CI, I may say that, at > > > least > > > > > for the kie-tools repo, removing the image build step from it > should > > > not > > > > be > > > > > too difficult (since it is an issue we already faced and solved). > > > > > If, with "detailed proposal", you mean a complete list of all > modules > > > to > > > > be > > > > > moved and dependency refactoring, of course I can not provide it > > right > > > > now. > > > > > > > > > > Anyway, I share the concern from Francisco: undoing something is > > almost > > > > > always harder than doing it "rightly" from scratch... > > > > > > > > > > > > > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 12:43 Francisco Javier Tirado > > Sarti > > > < > > > > > ftira...@redhat.com> ha scritto: > > > > > > > > > > > I do not think estimations should be the only driver to make a > > > > decision, > > > > > > especially when the current proposal is conceptually incompatible > > > with > > > > > the > > > > > > multi repo approach that is taken elsewhere in the project. > > > > > > Given my knowledge of the CI it is nearly impossible for me to > > give > > > a > > > > > fair > > > > > > estimate of how much it might take to achieve step 2) of my > > previous > > > > > e-mail > > > > > > . It might take a while or it might be pretty easy after all, I > > don't > > > > > > really know, but I think it will be a good idea if some of the > > > experts > > > > > on > > > > > > CI in the team (the ones that set up the pipeline, which was a > huge > > > > > > achievement) give an estimate, not me. Estimating how much it > > takes > > > to > > > > > > merge two existing repos (without altering CI) is easier, but it > > does > > > > not > > > > > > mean we are doing the right thing. > > > > > > My main concern is that it will be very difficult for me to > explain > > > to > > > > > > someone that arrives new to the team, that having experts on CI > on > > > the > > > > > > team, we decided to merge two repos (once merged, it would be > > rather > > > > > > difficult to unmerge) rather than fix the CI, because of > > expediency. > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:30 PM Alex Porcelli < > > porce...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > Francisco, > > > > > > > > > > > > > > Please take the time to make the more in depth analysis needed > > and > > > > > > provide > > > > > > > a more detailed plan… so we - as community- can evaluate the > size > > > of > > > > > the > > > > > > > effort. In the conceptual level you shared it’s near impossible > > to > > > > > > estimate > > > > > > > the size of the effort and compare with the current proposal. > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti < > > > > > > > ftira...@redhat.com> wrote: > > > > > > > > > > > > > > > I think I already did a high level proposal. > > > > > > > > 1) Remove all dependencies from tooling to images, so images > > > > depend > > > > > on > > > > > > > > tooling but tooling does not depend on images. > > > > > > > > 2) Then change CI to deal with tooling repo before dealing > with > > > > > images > > > > > > > > repo. > > > > > > > > I understand that CI details are tricky and since I'm not > > > familiar > > > > > with > > > > > > > CI > > > > > > > > in any way, I barely can make a low level design, but we do > not > > > > need > > > > > to > > > > > > > fix > > > > > > > > everything, just achieve 2), a change of compilation order. > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 12:17 PM Alex Porcelli < > > a...@porcelli.me > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Francisco and Grabriele, > > > > > > > > > > > > > > > > > > You may not like or understand why the current state of the > > CI > > > is > > > > > > like > > > > > > > > > that… actually has been in Red Hat and has been replicated > in > > > > > Apache > > > > > > as > > > > > > > > > used to be…. > > > > > > > > > > > > > > > > > > But the fact is that this is the current reality. > > > > > > > > > > > > > > > > > > If you disagree with the current plan, please provide a > > > detailed > > > > > > > > > alternative so we, as community, can better evaluate the > pros > > > and > > > > > > cons > > > > > > > of > > > > > > > > > each proposal. > > > > > > > > > > > > > > > > > > > > > > > > > > > I think it’s also fair to say that, post 10 release we need > > to > > > > > have a > > > > > > > > much > > > > > > > > > in depth discussion about how our codebase is organized, > it’s > > > > clear > > > > > > > that > > > > > > > > > it’s not working. > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:41 AM Gabriele Cardosi < > > > > > > > > > gabriele.card...@gmail.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > As Francisco said, > > > > > > > > > > I also have the impression that the "images" (if we are > > > talking > > > > > of > > > > > > > > docker > > > > > > > > > > images) should be the very last one to be built, in a > > > > standalone > > > > > > > repo. > > > > > > > > > > That way, they may "combine" artifacts that are built in > > > > > different > > > > > > > > repos, > > > > > > > > > > regardless of the order in which those are built. > > > > > > > > > > Moving them out of all the repos (kogito-apps/kie-tools) > > > maybe > > > > > > could > > > > > > > > > > simplify the situation a bit. > > > > > > > > > > (I also think there are some statements of undisputable > > needs > > > > > while > > > > > > > > they > > > > > > > > > > are, actually, just technical choices. > > > > > > > > > > Anyway, this latter point is for longer, following, > > > > discussion.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier > > > > Tirado > > > > > > > Sarti > > > > > > > > < > > > > > > > > > > ftira...@redhat.com> ha scritto: > > > > > > > > > > > > > > > > > > > > > Alex, > > > > > > > > > > > There are two assumptions that deserve further > > discussion: > > > > > > > > > > > 1) That tool has to be the last to build. why? it does > > not > > > > have > > > > > > > more > > > > > > > > > > sense > > > > > > > > > > > to build final images after everything else has been > > > built?- > > > > > > > > > > > 2) That the impact (in terms of effort now) on fixing > CI > > is > > > > > > bigger > > > > > > > > than > > > > > > > > > > the > > > > > > > > > > > impact (long term consequences) of consolidating two > > > > unrelated > > > > > > > piece > > > > > > > > of > > > > > > > > > > > software within the same repository. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:15 AM Alex Porcelli < > > > > > a...@porcelli.me > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Francisco, > > > > > > > > > > > > > > > > > > > > > > > > This was discussed as an alternative solution, > however > > it > > > > has > > > > > > > major > > > > > > > > > > > impact > > > > > > > > > > > > on CI and there’s also the fact Tool has been always > > the > > > > last > > > > > > to > > > > > > > > > build > > > > > > > > > > > and > > > > > > > > > > > > has no Snapshot published (actually in JavaScript > world > > > > there > > > > > > is > > > > > > > no > > > > > > > > > > > > snapshot concept). > > > > > > > > > > > > > > > > > > > > > > > > So, based on our evaluation… the proposal here is the > > > least > > > > > > > > > disruptive > > > > > > > > > > > and > > > > > > > > > > > > will take less time to unblock the release. > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > _____________ > > > > > > > > > > > > Alex Porcelli > > > > > > > > > > > > http://porcelli.me > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier > Tirado > > > > > Sarti < > > > > > > > > > > > > ftira...@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > After kie-tools, sorry. I think we are not > embracing > > > the > > > > > fact > > > > > > > > that > > > > > > > > > > > > > kogito-images depend on kie-tools, because we want > > > those > > > > > > images > > > > > > > > to > > > > > > > > > > > > include > > > > > > > > > > > > > tools. > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier > > > Tirado > > > > > > Sarti > > > > > > > < > > > > > > > > > > > > > ftira...@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tiago, > > > > > > > > > > > > > > It can be an alternative solution to move > > > > > > kn-plugin-workflow > > > > > > > to > > > > > > > > > > > > > > kogito-images (so there is not longer dependency > > from > > > > > tools > > > > > > > to > > > > > > > > > > > images) > > > > > > > > > > > > > and > > > > > > > > > > > > > > then build kogito-images after kogito-tools? > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez > > > > > Martinez > > > > > > < > > > > > > > > > > > > > > egonza...@apache.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > >> +1 to unblock release > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> El mié, 13 mar 2024, 10:48, Pere Fernandez > > (apache) > > > < > > > > > > > > > > > > > pefer...@apache.org> > > > > > > > > > > > > > >> escribió: > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > I say +1 in order to move forward with the 10. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > On Tue, 12 Mar 2024 at 21:45, Alex Porcelli < > > > > > > > > a...@porcelli.me > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > +1 > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > I spent the last day or so working closely > > with > > > > > Tiago, > > > > > > > > > > exploring > > > > > > > > > > > > > >> > different > > > > > > > > > > > > > >> > > options and getting deeper on the impact and > > > > > > evaluating > > > > > > > > the > > > > > > > > > > > > overall > > > > > > > > > > > > > >> > release > > > > > > > > > > > > > >> > > procedure steps required. I agree with the > > > > proposal > > > > > as > > > > > > > the > > > > > > > > > > most > > > > > > > > > > > > > >> > > viable option for unblocking the 10 release > in > > > the > > > > > > > > > reasonable > > > > > > > > > > > time > > > > > > > > > > > > > >> frame. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > On Tue, Mar 12, 2024 at 3:45 PM Tiago Bento > < > > > > > > > > > > > > tiagobe...@apache.org> > > > > > > > > > > > > > >> > wrote: > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > Hi everyone, > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Unfortunately, I can't do a tl;dr this > time, > > > as > > > > > this > > > > > > > > > matter > > > > > > > > > > > > > >> requires a > > > > > > > > > > > > > >> > > > lot of context. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > This email will take you < 20 minutes to > > read, > > > > > > > according > > > > > > > > > to > > > > > > > > > > > > > >> > > > https://thereadtime.com/. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > As you may have followed on a separate > > thread > > > > > > > > > > > > > >> > > > ( > > > > > > > > > > > > > > > > > > https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69 > > > > > > > > > > > > > ), > > > > > > > > > > > > > >> > > > many of us were working towards removing a > > > > > circular > > > > > > > > > > dependency > > > > > > > > > > > > > >> > > > currently present between `kogito-apps` > and > > > > > > > `kie-tools`. > > > > > > > > > As > > > > > > > > > > we > > > > > > > > > > > > > >> > > > progressed towards a solution, we kept > > finding > > > > the > > > > > > > > > circular > > > > > > > > > > > > > >> dependency > > > > > > > > > > > > > >> > > > pop up somewhere else. I'll do a breakdown > > of > > > > the > > > > > > > things > > > > > > > > > we > > > > > > > > > > > did, > > > > > > > > > > > > > and > > > > > > > > > > > > > >> > > > the results we had. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Right now, even though we started the > effort > > > to > > > > > move > > > > > > > the > > > > > > > > > > > Quarkus > > > > > > > > > > > > > Dev > > > > > > > > > > > > > >> > > > UI modules to `kie-tools`, we haven't been > > > able > > > > to > > > > > > do > > > > > > > it > > > > > > > > > > yet, > > > > > > > > > > > as > > > > > > > > > > > > > >> we've > > > > > > > > > > > > > >> > > > been busy upgrading KIE Tools to Java 17, > > > Maven > > > > > > 3.9.6, > > > > > > > > and > > > > > > > > > > > > Quarkus > > > > > > > > > > > > > >> > > > 3.2.9, compatible with Kogito Runtimes > > > > > > > > > > 999-20240218-SNAPSHOT. > > > > > > > > > > > > This > > > > > > > > > > > > > >> > > > effort was concluded this Monday, with > > > > > > > > > > > > > >> > > > > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2136 > > > > > > > > . > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > The current scenario we have is: > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > 01. > > > > incubator-kie-kogito-runtimes > > > > > > > > > > > > > >> > > > |==> 02. incubator-kie-kogito-apps > > > > > > > > > > > > > >> > > > C | 03. > > > incubator-kie-kogito-examples > > > > > > > > > > > > > >> > > > Y | 04. > > > incubator-kie-kogito-images > > > > > > > > > > > > > >> > > > C | 05. > > > > > > > > > incubator-kie-kogito-serverless-operator > > > > > > > > > > > > > >> > > > L | ========================== > > > > > > > > > > > > > >> > > > E | 06. > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator > > > > > > > > > > > > > >> > > > |==> 07. incubator-kie-tools > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > * As `kie-tools`/extended-services > > > > depends > > > > > > on > > > > > > > > > > > > > >> > > > `kogito-apps`/jitexecutor; > > > > > > > > > > > > > >> > > > * and > > > > > > > > > `kogito-apps`/{sonataflow,bpmn}-quarkus-devui > > > > > > > > > > > > depend > > > > > > > > > > > > > >> on > > > > > > > > > > > > > >> > > > `kie-tools`/{many packages} > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > After moving the Quarkus Dev UIs to > > > `kie-tools`, > > > > > we > > > > > > > > > would've > > > > > > > > > > > > had: > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > 01. > > > > incubator-kie-kogito-runtimes > > > > > > > > > > > > > >> > > > 02. > > incubator-kie-kogito-apps > > > > > > > > > > > > > >> > > > 03. > > > > incubator-kie-kogito-examples > > > > > > > > > > > > > >> > > > C |==> 04. > incubator-kie-kogito-images > > > > > > > > > > > > > >> > > > Y | 05. > > > > > > > > > incubator-kie-kogito-serverless-operator > > > > > > > > > > > > > >> > > > C | ===================== > > > > > > > > > > > > > >> > > > L | 06. > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator > > > > > > > > > > > > > >> > > > E |==> 07. incubator-kie-tools > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > * As > `kie-tools`/kn-plugin-workflow > > > > > depends > > > > > > on > > > > > > > > > > > > > >> > > > `kogito-images`/kogito-swf-devmode; > > > > > > > > > > > > > >> > > > * and > > > `kogito-images`/kogito-swf-devmode > > > > > > > depends > > > > > > > > > on > > > > > > > > > > > > > >> > > > `kie-tools`/sonataflow-quarkus-devui > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > After moving the `kogito-swf-devmode` > image > > to > > > > > > > > > `kie-tools`, > > > > > > > > > > we > > > > > > > > > > > > > >> would've > > > > > > > > > > > > > >> > > > had: > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > 01. > > > > incubator-kie-kogito-runtimes > > > > > > > > > > > > > >> > > > 02. > > incubator-kie-kogito-apps > > > > > > > > > > > > > >> > > > 03. > > > > incubator-kie-kogito-examples > > > > > > > > > > > > > >> > > > 04. > > > incubator-kie-kogito-images > > > > > > > > > > > > > >> > > > C |==> 05. > > > > > > > > incubator-kie-kogito-serverless-operator > > > > > > > > > > > > > >> > > > Y | ===================== > > > > > > > > > > > > > >> > > > C | 06. > > > > > > > > > > incubator-kie-sandbox-quarkus-accelerator > > > > > > > > > > > > > >> > > > L |==> 07. incubator-kie-tools > > > > > > > > > > > > > >> > > > E > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > * As > `kie-tools`/kn-plugin-workflow > > > > > depends > > > > > > on > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`; > > > > > > > > > > > > > >> > > > * and `kogito-serverless-operator` > > > > depends > > > > > > on > > > > > > > > > > > > > >> > > > `kie-tools`/kogito-swf-devmode > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Clearly, we have a much bigger problem > than > > a > > > > > simple > > > > > > > > > > circular > > > > > > > > > > > > > >> > dependency. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > After multiple conversations with a lot of > > > > people, > > > > > > > it's > > > > > > > > > been > > > > > > > > > > > > > really > > > > > > > > > > > > > >> > > > hard coming up with a simple solution that > > > makes > > > > > it > > > > > > > > > possible > > > > > > > > > > > to > > > > > > > > > > > > > >> build > > > > > > > > > > > > > >> > > > Apache KIE in one shot, while preserving > the > > > way > > > > > > > > everyone > > > > > > > > > is > > > > > > > > > > > > used > > > > > > > > > > > > > to > > > > > > > > > > > > > >> > > > contributing to the multiple repositories > we > > > > have. > > > > > > > More > > > > > > > > > than > > > > > > > > > > > > that, > > > > > > > > > > > > > >> > > > while making this assessment, I found more > > > > > problems > > > > > > > > that, > > > > > > > > > in > > > > > > > > > > > my > > > > > > > > > > > > > >> > > > perspective, block Apache KIE 10. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > In light of that difficulty, I'm coming > > > forward > > > > > with > > > > > > > my > > > > > > > > > > > proposal > > > > > > > > > > > > > for > > > > > > > > > > > > > >> > > > the Apache KIE release process, so we can > > use > > > > > > Apache's > > > > > > > > > > > > mechanisms > > > > > > > > > > > > > to > > > > > > > > > > > > > >> > > > have a slower-paced, in-depth debate about > > > this > > > > > > really > > > > > > > > > > > > complicated > > > > > > > > > > > > > >> > > > matter. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > I'll lay out my entire perspective about > the > > > > > current > > > > > > > > > > situation > > > > > > > > > > > > of > > > > > > > > > > > > > >> our > > > > > > > > > > > > > >> > > > codebase, as well as problems I can > > currently > > > > see. > > > > > > > I'll > > > > > > > > > > start > > > > > > > > > > > > with > > > > > > > > > > > > > >> an > > > > > > > > > > > > > >> > > > analysis of the repositories and their > > > purposes, > > > > > > point > > > > > > > > out > > > > > > > > > > > some > > > > > > > > > > > > > >> > > > problems that I believe are blocking our > 10 > > > > > release, > > > > > > > > > explain > > > > > > > > > > > my > > > > > > > > > > > > > >> > > > proposal and discuss some consequences to > > what > > > > I'm > > > > > > > > > > proposing. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Let's begin. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > # THE APACHE KIE REPOS > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > A. DROOLS OPTAPLANNER, & KOGITO (count: > 11) > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-pipelines @ `main` > > > > > > > > > > > > > >> > > > - incubator-kie-drools @ `main` > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner @ `main` > > > > > > > > > > > > > >> > > > - incubator-kie-optaplanner-quickstarts @ > > > `main` > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-runtimes @ `main` > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-apps @ `main` > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-examples @ `main` > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-images @ `main` > > > > > > > > > > > > > >> > > > - > incubator-kie-kogito-serverless-operator @ > > > > > `main` > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-docs @ `main` > > > > > > > > > > > > > >> > > > - incubator-kie-docs @ `main-kogito` > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > B. TOOLS (count: 2) > > > > > > > > > > > > > >> > > > - > incubator-kie-sandbox-quarkus-accelerator > > @ > > > > > > `0.0.0` > > > > > > > > > > > > > >> > > > - incubator-kie-tools @ `main` > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > C. BENCHMARKS (count: 2) > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-benchmarks @ `main` > > > > > > > > > > > > > >> > > > - incubator-kie-benchmarks @ `main` > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > D. ARCHIVED (count: 1) > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-operator > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > E. "NON-CODE" (count: 5) > > > > > > > > > > > > > >> > > > - incubator-kie-issues @ `main` > > > > > > > > > > > > > >> > > > (Issues only, README should be > updated @ > > > > > `main`. > > > > > > > > Same > > > > > > > > > > for > > > > > > > > > > > > > GitHub > > > > > > > > > > > > > >> > > > Actions workflows.) > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-website @ `main` > > > > > > > > > > > > > >> > > > (The Kogito website. Develop & deploy > at > > > the > > > > > > > `main` > > > > > > > > > > > branch.) > > > > > > > > > > > > > >> > > > - incubator-kie-website @ `main` > > > > > > > > > > > > > >> > > > (The KIE website. Develop @ `main`. > > Push @ > > > > > > > `deploy` > > > > > > > > to > > > > > > > > > > > > update > > > > > > > > > > > > > >> the > > > > > > > > > > > > > >> > > > website.) > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online @ `gh-pages` > > > > > > > > > > > > > >> > > > (GitHub pages used to host > > > sandbox.kie.org > > > > > and > > > > > > > KIE > > > > > > > > > > Tools' > > > > > > > > > > > > > >> Chrome > > > > > > > > > > > > > >> > > > Extension assets.) > > > > > > > > > > > > > >> > > > - incubator-kie-kogito-online-staging @ > > `main` > > > > > > > > > > > > > >> > > > (Same as above, but for manual sanity > > > checks > > > > > > > during > > > > > > > > > the > > > > > > > > > > > > > staging > > > > > > > > > > > > > >> > > > phase of a release.) > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > TOTAL (count: 21) > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > I grouped the repositories by category, > and > > > > listed > > > > > > > them > > > > > > > > > in a > > > > > > > > > > > > > >> > > > topological order. Keep in mind that when > > > > > flattening > > > > > > > > out a > > > > > > > > > > > tree, > > > > > > > > > > > > > >> there > > > > > > > > > > > > > >> > > > are multiple possibilities. For example, > > > > > OptaPlanner > > > > > > > > > > could've > > > > > > > > > > > > been > > > > > > > > > > > > > >> > > > placed in any position after Drools. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Category A repos are what I've been > > referring > > > to > > > > > as > > > > > > > > > `drools` > > > > > > > > > > > and > > > > > > > > > > > > > >> > > > `kogito-*` stream. Of course OptaPlanner > is > > > > inside > > > > > > > that > > > > > > > > > > > stream, > > > > > > > > > > > > as > > > > > > > > > > > > > >> the > > > > > > > > > > > > > >> > > > way these repositories reference each > other > > > are > > > > > > > through > > > > > > > > > > Maven > > > > > > > > > > > > > >> > > > SNAPSHOTs. More specifically, the > > 999-SNAPSHOT > > > > > > > version. > > > > > > > > > This > > > > > > > > > > > > > >> mechanism > > > > > > > > > > > > > >> > > > is well-known to the team, and although > > flawed > > > > for > > > > > > > > > intra-day > > > > > > > > > > > > > builds > > > > > > > > > > > > > >> > > > and disruptive for people in many > different > > > time > > > > > > > zones, > > > > > > > > it > > > > > > > > > > is > > > > > > > > > > > > > >> already > > > > > > > > > > > > > >> > > > very comfortable for everyone to work > with, > > I > > > > > > assume. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Contributions made to Category A have some > > > > > dedicated > > > > > > > > > > > pipelines, > > > > > > > > > > > > > >> which > > > > > > > > > > > > > >> > > > are, at least to some extent, able to > build > > > > > > cross-repo > > > > > > > > PRs > > > > > > > > > > > > > together > > > > > > > > > > > > > >> > > > and verify that the codebase will continue > > > > working > > > > > > as > > > > > > > > > > expected > > > > > > > > > > > > > after > > > > > > > > > > > > > >> > > > they're all merged. From what I could > > gather, > > > > > there > > > > > > > are > > > > > > > > > some > > > > > > > > > > > > > >> > > > "sub-streams" currently configured for > > > > cross-repo > > > > > > PRs. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > - kogito-pipelines > > > > > > > > > > > > > >> > > > - drools, kogito-runtimes, kogito-apps, > and > > > > > > > > > kogito-examples > > > > > > > > > > > > > >> > > > - optaplanner, and optaplanner-quickstarts > > > > > > > > > > > > > >> > > > - kogito-images, and > > > kogito-serverless-operator > > > > > > > > > > > > > >> > > > - kogito-docs > > > > > > > > > > > > > >> > > > - kie-docs > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > This means that sending cross-repo PRs to > > any > > > > > > > > combination > > > > > > > > > of > > > > > > > > > > > > repos > > > > > > > > > > > > > >> > > > that are not part of the same "sub-stream" > > > > cannot > > > > > be > > > > > > > > > > verified > > > > > > > > > > > > > before > > > > > > > > > > > > > >> > > > merging, making our contribution model > > > dependent > > > > > on > > > > > > > > > > individual > > > > > > > > > > > > > >> > > > contributors building stuff on their > > machines > > > to > > > > > > > verify > > > > > > > > > that > > > > > > > > > > > it > > > > > > > > > > > > > >> works. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > I based this analysis on > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/project-dependencies.yaml > > > > > > > > > > > > > >> > > > , > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-optaplanner/blob/main/.ci/buildchain-project-dependencies.yaml > > > > > > > > > > > > > >> > > > , > > > > > > > > > > > > > >> > > > and > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/jenkins/config/branch.yaml > > > > > > > > > > > > > >> > > > . > > > > > > > > > > > > > >> > > > Note that I'm not that familiar with these > > > > > > pipelines, > > > > > > > so > > > > > > > > > > > please > > > > > > > > > > > > > >> > > > someone correct me if I'm wrong. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Category B repos are what I've been > > referring > > > to > > > > > as > > > > > > > > > > > `kie-tools` > > > > > > > > > > > > > >> > > > stream. The first repo there is a template > > > > > > repository > > > > > > > > that > > > > > > > > > > is > > > > > > > > > > > > used > > > > > > > > > > > > > >> by > > > > > > > > > > > > > >> > > > people starting projects from scratch on > KIE > > > > > > Sandbox, > > > > > > > > > > similar > > > > > > > > > > > > to a > > > > > > > > > > > > > >> > > > Maven archetype, if you will. The other > one > > is > > > > the > > > > > > KIE > > > > > > > > > Tools > > > > > > > > > > > > > >> monorepo, > > > > > > > > > > > > > >> > > > a polyglot monorepo with `pnpm` as its > build > > > > > system. > > > > > > > > > > > Currently, > > > > > > > > > > > > > KIE > > > > > > > > > > > > > >> > > > Tools hosts Java libraries and apps, > > > TypeScript > > > > > > > > libraries > > > > > > > > > > and > > > > > > > > > > > > > apps, > > > > > > > > > > > > > >> Go > > > > > > > > > > > > > >> > > > apps, Docker images, and Helm charts. The > > > > > > `kie-tools` > > > > > > > > > > monorepo > > > > > > > > > > > > is > > > > > > > > > > > > > >> > > > configured to work with sparse checkouts > and > > > can > > > > > do > > > > > > > > > partial > > > > > > > > > > > > > builds. > > > > > > > > > > > > > >> > > > Category B repos refer to Category A repos > > > > through > > > > > > > > > > timestamped > > > > > > > > > > > > > >> > > > SNAPSHOTs. This is a new mechanism we > > recently > > > > > > > > introduced > > > > > > > > > > that > > > > > > > > > > > > > will > > > > > > > > > > > > > >> > > > build and publish immutable, persistent > > > > artifacts > > > > > > > under > > > > > > > > a > > > > > > > > > > > > version > > > > > > > > > > > > > >> > > > following the 999-YYYYMMDD-SNAPSHOT > format, > > > > > > published > > > > > > > > > weekly > > > > > > > > > > > > every > > > > > > > > > > > > > >> > > > Sunday night. Timestamped SNAPSHOTs are an > > > > > evolution > > > > > > > to > > > > > > > > > the > > > > > > > > > > > > Kogito > > > > > > > > > > > > > >> > > > releases, as we're now targeting one > release > > > for > > > > > all > > > > > > > of > > > > > > > > > > Apache > > > > > > > > > > > > > KIE, > > > > > > > > > > > > > >> so > > > > > > > > > > > > > >> > > > we can't have Kogito releases anymore. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > An important note here is that Category B > > > > > > repositories > > > > > > > > > have > > > > > > > > > > > been > > > > > > > > > > > > > >> > > > historically kept out of any automations > we > > > used > > > > > to > > > > > > > > have, > > > > > > > > > > way > > > > > > > > > > > > back > > > > > > > > > > > > > >> > > > when Kogito started and we had the > Business > > > > > Central > > > > > > > > > (a.k.a. > > > > > > > > > > > v7) > > > > > > > > > > > > > >> stream > > > > > > > > > > > > > >> > > > still going on. For this reason, Category > B > > > > > projects > > > > > > > > have > > > > > > > > > > > > > developed > > > > > > > > > > > > > >> > > > their own automations, based on GitHub > > > Actions. > > > > > > > > Category B > > > > > > > > > > > repos > > > > > > > > > > > > > >> have > > > > > > > > > > > > > >> > > > always depended on Category A repos using > > > fixed > > > > > > > > versions. > > > > > > > > > If > > > > > > > > > > > > > >> Category > > > > > > > > > > > > > >> > > > B repos have had adopted mutable > SNAPSHOTs, > > > > > breaking > > > > > > > > > changes > > > > > > > > > > > on > > > > > > > > > > > > > >> > > > Category A repositories would've had the > > > > potential > > > > > > to > > > > > > > > > break > > > > > > > > > > > > > >> Category B > > > > > > > > > > > > > >> > > > silently, leaving Category B with a broken > > > > > > development > > > > > > > > > > stream, > > > > > > > > > > > > and > > > > > > > > > > > > > >> > > > introducing unpleasant surprises for > > > maintainers > > > > > of > > > > > > > > > > Category B > > > > > > > > > > > > > >> repos, > > > > > > > > > > > > > >> > > > as historically Category A contributors > were > > > not > > > > > > > > familiar > > > > > > > > > > with > > > > > > > > > > > > > >> > > > Category B repos. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Contributions made to Category B repos go > > > > through > > > > > a > > > > > > > > GitHub > > > > > > > > > > > > Actions > > > > > > > > > > > > > >> > > > workflow that builds the relevant part of > > the > > > > > > > > `kie-tools` > > > > > > > > > > > > monorepo > > > > > > > > > > > > > >> for > > > > > > > > > > > > > >> > > > the changes introduced. Changes made to > the > > > > > pipeline > > > > > > > > > itself > > > > > > > > > > > are > > > > > > > > > > > > > also > > > > > > > > > > > > > >> > > > picked up as part of PRs, allowing us to > do > > > > things > > > > > > > like > > > > > > > > > > > > atomically > > > > > > > > > > > > > >> > > > bumping the Node.js version, for example. > > More > > > > > > > > > importantly, > > > > > > > > > > it > > > > > > > > > > > > > >> allows > > > > > > > > > > > > > >> > > > us to upgrade the repository to a new > > > > timestamped > > > > > > > > SNAPSHOT > > > > > > > > > > > > > together > > > > > > > > > > > > > >> > > > with the changes necessary to make it stay > > > > green. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > This setup, however, makes it impossible > to > > > have > > > > > > > > > cross-repo > > > > > > > > > > > PRs > > > > > > > > > > > > > >> > > > involving Category A and Category B > > > > > simultaneously, > > > > > > > with > > > > > > > > > the > > > > > > > > > > > > > current > > > > > > > > > > > > > >> > > > automations we have. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Category C repos are kind of floating > > around, > > > > and > > > > > > I'm > > > > > > > > not > > > > > > > > > > sure > > > > > > > > > > > > if > > > > > > > > > > > > > >> > > > there's much activity going on there. > > > > Regardless, > > > > > as > > > > > > > > > they're > > > > > > > > > > > > part > > > > > > > > > > > > > of > > > > > > > > > > > > > >> > > > Apache KIE, they will be part of our > > release, > > > > so I > > > > > > > > listed > > > > > > > > > > them > > > > > > > > > > > > for > > > > > > > > > > > > > >> us > > > > > > > > > > > > > >> > > > to take them into consideration too. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Category D is self explanatory. There's > only > > > one > > > > > > repo > > > > > > > > that > > > > > > > > > > has > > > > > > > > > > > > > >> already > > > > > > > > > > > > > >> > > > been marked for being archived. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Category E are repos that do not host code > > > > > directly, > > > > > > > and > > > > > > > > > are > > > > > > > > > > > > > either > > > > > > > > > > > > > >> > > > organizational entities, or host websites, > > > that > > > > > > > > currently > > > > > > > > > > are > > > > > > > > > > > > not > > > > > > > > > > > > > >> part > > > > > > > > > > > > > >> > > > of any pipelines we have. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > This lack of unification between Category > A > > > and > > > > > > > > Category B > > > > > > > > > > is, > > > > > > > > > > > > > IMHO, > > > > > > > > > > > > > >> > > > what allowed us to introduce the infamous > > > > circular > > > > > > > > > > dependency > > > > > > > > > > > > > >> between > > > > > > > > > > > > > >> > > > `kie-tools` and `kogito-apps`, which we > now > > > can > > > > > > > describe > > > > > > > > > as > > > > > > > > > > a > > > > > > > > > > > > > >> circular > > > > > > > > > > > > > >> > > > dependency between Category A and Category > > B. > > > > The > > > > > > way > > > > > > > I > > > > > > > > > see > > > > > > > > > > > it, > > > > > > > > > > > > if > > > > > > > > > > > > > >> we > > > > > > > > > > > > > >> > > > had a single pipeline, building everything > > > from > > > > > > > `drools` > > > > > > > > > to > > > > > > > > > > > > > >> > > > `kie-tools`, such flaws would've never > been > > > > > > > introduced, > > > > > > > > > and > > > > > > > > > > we > > > > > > > > > > > > > >> > > > wouldn't be having this huge problem in > our > > > > hands > > > > > > > right > > > > > > > > > now. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > My proposal for the Apache KIE release > > process > > > > > sees > > > > > > > this > > > > > > > > > > lack > > > > > > > > > > > of > > > > > > > > > > > > > >> > > > unification as a central problem, not only > > for > > > > > this > > > > > > > > > release > > > > > > > > > > in > > > > > > > > > > > > > >> > > > particular, but for the community as a > > whole. > > > It > > > > > is > > > > > > my > > > > > > > > > > belief > > > > > > > > > > > > that > > > > > > > > > > > > > >> we > > > > > > > > > > > > > >> > > > are all under the same roof, and that no > > > > > > contribution > > > > > > > > > should > > > > > > > > > > > be > > > > > > > > > > > > > >> > > > allowed to break any part of our codebase. > > > With > > > > > the > > > > > > > > > > increasing > > > > > > > > > > > > > >> volume > > > > > > > > > > > > > >> > > > of code, and hopefully number of > > contributors > > > > too, > > > > > > we > > > > > > > > > cannot > > > > > > > > > > > > keep > > > > > > > > > > > > > >> > > > counting on "common sense" to avoid > breaking > > > > > things. > > > > > > > > We're > > > > > > > > > > all > > > > > > > > > > > > > >> humans > > > > > > > > > > > > > >> > > > after all, and it is our job to have > > > mechanisms > > > > in > > > > > > > place > > > > > > > > > to > > > > > > > > > > > > > prevent > > > > > > > > > > > > > >> us > > > > > > > > > > > > > >> > > > from unwillingly making mistakes. > Especially > > > > when > > > > > > > these > > > > > > > > > > > mistakes > > > > > > > > > > > > > >> > > > impact on parts of the codebase that we, > > > > > > individually, > > > > > > > > > > > probably > > > > > > > > > > > > > >> can't > > > > > > > > > > > > > >> > > > fix. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > # THE PROBLEMS WE HAVE RIGHT NOW > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > P1. Quarkus Dev UIs @ `kogito-apps` > > depending > > > on > > > > > > > > > kiegroup's > > > > > > > > > > > KIE > > > > > > > > > > > > > >> Tools > > > > > > > > > > > > > >> > > > `0.32.0`. > > > > > > > > > > > > > >> > > > See: > > > > > > > > > > > > > >> > > > - > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/search?q=repo%3Akiegroup%2Fkogito-apps+path%3Apackage.json+kie-tools&type=code > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > P2. PR open for Kogito SWF images @ > > > > > `kogito-images` > > > > > > > > > > depending > > > > > > > > > > > on > > > > > > > > > > > > > >> > > > kiegroup's KIE Tools `0.32.0`. > > > > > > > > > > > > > >> > > > See: > > > > > > > > > > > > > >> > > > - > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-tools/tree/main/packages/sonataflow-deployment-webapp > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > P3. DashBuilder @ `kie-tools` depending on > > > > > > kiegroup's > > > > > > > > > > `lienzo` > > > > > > > > > > > > and > > > > > > > > > > > > > >> > > > `kie-soup` artifacts at version > > > `7.59.0.Final`. > > > > > > > > > > > > > >> > > > See: > > > > > > > > > > > > > >> > > > - > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder/pom.xml#L64 > > > > > > > > > > > > > >> > > > - > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools+path%3Apackages%2Fdashbuilder+%24%7Bversion.org.kie%7D&type=code > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > P4. Multiple packages @ `kogito-apps` > > > depending > > > > on > > > > > > > > > > kiegroup's > > > > > > > > > > > > > >> > > > Explainability `1.22.1.Final`. > > > > > > > > > > > > > >> > > > * This module was removed from the KIE > > > codebase > > > > > > here: > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-kogito-apps/commit/bbb22c06d37e77b97aae6496d74abe43a8cfc965 > > > > > > > > > > > > > >> > > > and now lives on > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/trustyai-explainability/trustyai-explainability > > > > > > > > > , > > > > > > > > > > > > > >> > > > under a different GAV. > > > > > > > > > > > > > >> > > > * This new repo depends on Kogito and > > > > OptaPlanner, > > > > > > > > > pointing > > > > > > > > > > to > > > > > > > > > > > > > older > > > > > > > > > > > > > >> > > > versions. > > > > > > > > > > > > > >> > > > See: > > > > > > > > > > > > > >> > > > - > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-kogito-apps+%3Eexplainability-core%3C&type=code > > > > > > > > > > > > > >> > > > - > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/trustyai-explainability/trustyai-explainability/blob/main/pom.xml#L52-L53 > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > P5. > > > `incubator-kie-sandbox-quarkus-accelerator` > > > > > > > > depending > > > > > > > > > on > > > > > > > > > > > > > Kogito > > > > > > > > > > > > > >> > > > `1.32.0.Final` and Quarkus `2.15.3.Final`. > > > > > > > > > > > > > >> > > > See: > > > > > > > > > > > > > >> > > > - > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-sandbox-quarkus-accelerator/blob/0.0.0/pom.xml#L32-L38 > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > P6. Category C repos are out of date and > not > > > > part > > > > > of > > > > > > > the > > > > > > > > > > > > Category > > > > > > > > > > > > > A > > > > > > > > > > > > > >> > > > CI/Release pipelines. > > > > > > > > > > > > > >> > > > * incubator-kie-kogito-benchmarks: > (Current > > > > > version > > > > > > is > > > > > > > > > > > > > >> `2.0-SNAPSHOT`, > > > > > > > > > > > > > >> > > > depending on Kogito without a specific > > > version, > > > > > only > > > > > > > by > > > > > > > > > > using > > > > > > > > > > > > > >> > > > `http://localhost:8080`) > > > > > > > > > > > > > >> > > > * incubator-kie-benchmarks: (Current > version > > > is > > > > > > > > > > > `1.0-SNAPSHOT`, > > > > > > > > > > > > > >> > > > pointing to Drools 999-SNAPSHOT and > > > OptaPlanner > > > > > > > > > > > > `8.45.0-SNAPSHOT`) > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > P7. > `kie-tools`/packages/kn-plugin-workflow > > > has > > > > > its > > > > > > > E2E > > > > > > > > > > > disabled > > > > > > > > > > > > > >> after > > > > > > > > > > > > > >> > > > upgrading to 999-20240218-SNAPSHOT. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > In my perspective, P1 and P2 have the same > > > > > solution, > > > > > > > as > > > > > > > > > they > > > > > > > > > > > > both > > > > > > > > > > > > > >> > > > suffer from the circular dependency > between > > > > > > Category A > > > > > > > > and > > > > > > > > > > > > > Category > > > > > > > > > > > > > >> B. > > > > > > > > > > > > > >> > > > As Category A and Category B are both > > streams > > > > that > > > > > > > have > > > > > > > > > been > > > > > > > > > > > > > really > > > > > > > > > > > > > >> > > > active, I see this as a blocker, as there > > are > > > > > > > > > contributions > > > > > > > > > > > that > > > > > > > > > > > > > >> > > > cannot be done, given that Category A > > depends > > > on > > > > > > > > Category > > > > > > > > > B > > > > > > > > > > > > with a > > > > > > > > > > > > > >> > > > dephasing of 1 release. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > P3 and P4, although not ideal, can be > > > understood > > > > > as > > > > > > > > > > technical > > > > > > > > > > > > > debt. > > > > > > > > > > > > > >> > > > Depending on unmaintained projects is > > > something > > > > > > we'll > > > > > > > > > always > > > > > > > > > > > be > > > > > > > > > > > > > >> > > > susceptible to, given time. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > P5 and P6 are easily fixable, as it's > just a > > > > > matter > > > > > > of > > > > > > > > > > making > > > > > > > > > > > > them > > > > > > > > > > > > > >> > > > part of the play. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > P7 is an isolated problem that won't > impact > > > the > > > > > > > > structure > > > > > > > > > or > > > > > > > > > > > > > >> anything > > > > > > > > > > > > > >> > > > that we're talking about here, but it is a > > > > > > regression > > > > > > > we > > > > > > > > > > > > > introduced > > > > > > > > > > > > > >> > > > recently. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Assuming P3 and P4 can be ignored for > Apache > > > KIE > > > > > 10, > > > > > > > and > > > > > > > > > > that > > > > > > > > > > > > P5, > > > > > > > > > > > > > >> P6, > > > > > > > > > > > > > >> > > > and P7 have easy fixes, the only problems > > left > > > > to > > > > > > > > discuss > > > > > > > > > > are > > > > > > > > > > > P1 > > > > > > > > > > > > > and > > > > > > > > > > > > > >> > > > P2, which can't be done without a proper > > > > proposal. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > # THE PROPOSAL > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > I'll try to be very meticulous here, since > > > from > > > > my > > > > > > > > > > experience, > > > > > > > > > > > > any > > > > > > > > > > > > > >> > > > little miscalculation can lead to our > > release > > > > not > > > > > > > > working > > > > > > > > > > out > > > > > > > > > > > in > > > > > > > > > > > > > the > > > > > > > > > > > > > >> > > > end. To try and avoid that as much as > > > possible, > > > > > and > > > > > > > make > > > > > > > > > > > > > everything > > > > > > > > > > > > > >> we > > > > > > > > > > > > > >> > > > can to have a successful Apache KIE 10 > > > release, > > > > > bear > > > > > > > > with > > > > > > > > > > me. > > > > > > > > > > > > I'll > > > > > > > > > > > > > >> lay > > > > > > > > > > > > > >> > > > out a timeline of events that need to > happen > > > in > > > > > > order > > > > > > > > for > > > > > > > > > > our > > > > > > > > > > > > > >> release > > > > > > > > > > > > > >> > > > to be published, with all artifacts ending > > up > > > in > > > > > the > > > > > > > > right > > > > > > > > > > > > places, > > > > > > > > > > > > > >> but > > > > > > > > > > > > > >> > > > first, we need to solve problems P1 and > P2. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > As you saw at the beginning of this email, > > all > > > > the > > > > > > > > > attempts > > > > > > > > > > we > > > > > > > > > > > > > made > > > > > > > > > > > > > >> > > > left us with the circular dependency > showing > > > up > > > > > at a > > > > > > > > > > different > > > > > > > > > > > > > >> place, > > > > > > > > > > > > > >> > > > but something all these places have in > > common > > > is > > > > > > that > > > > > > > > > > they're > > > > > > > > > > > > all > > > > > > > > > > > > > >> > > > after kogito-apps, and before to Category > B. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > The first part of my proposal is the > > > following: > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > S1. We keep the original plan of moving > the > > > > > Quarkus > > > > > > > Dev > > > > > > > > > UIs > > > > > > > > > > > from > > > > > > > > > > > > > >> > > > `kogito-apps` to `kie-tools`, together > with > > > > > > Management > > > > > > > > and > > > > > > > > > > > Task > > > > > > > > > > > > > >> > > > consoles from `kogito-images` to > > `kie-tools`. > > > > > > > > > > > > > >> > > > S2. We move the `kogito-swf-devmode` and > > > > > > > > > > `kogito-swf-builder` > > > > > > > > > > > > > images > > > > > > > > > > > > > >> > > > from `kogito-images` to `kie-tools` too. > > > > > > > > > > > > > >> > > > S3. We move the entire > > > > > `kogito-serverless-operator` > > > > > > > repo > > > > > > > > > > > inside > > > > > > > > > > > > a > > > > > > > > > > > > > >> new > > > > > > > > > > > > > >> > > > package on `kie-tools`, keeping Git > history. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > Solutions S1, S2, and S3 together solve > > > problems > > > > > P1 > > > > > > > and > > > > > > > > > P2. > > > > > > >
