Alex, In [1] I see that we are agreeing on the move and there will be an official proposal shared. Where is the proposal? I see only an announcement [2] that this is in progress already. This is not good imho, we need to learn from this and get better.
about the issue: The proposed solution is only a workaround for the release in my view. Kogito-images depending on kie-tools is still the final solution from my side. Inability to depend on kie-tools, is what still puzzles me. If someone can clear this up, with specific modules/packages and details I will gladly dedicate time to understand. Dominik [1] - https://lists.apache.org/thread/smfjzco6nzccgos38fg83120yoy1whx9 [2] - https://lists.apache.org/thread/nknm6j641qk2c7cl621tsy3fy98tsc69 On Thu, 7 Mar 2024 at 11:38, Francisco Javier Tirado Sarti < [email protected]> wrote: > What I'm trying to say is that changing the streams is probably better than > doing again what we did with tooling and data-index in the past (in > kogito-apps repo), putting unrelated stuff into the same repo (image and > tooling in this case) > > > > On Thu, Mar 7, 2024 at 11:29 AM Francisco Javier Tirado Sarti < > [email protected]> wrote: > > > So, is it possible to have the following build order (regardless of kie > or > > kogito prefix)? > > 1) drools 2) runtimes 3) tools 4) images > > > > > > > > On Thu, Mar 7, 2024 at 10:51 AM Francisco Javier Tirado Sarti < > > [email protected]> wrote: > > > >> Hi Tiago, > >> Let's rewind a bit, if we ignore the kie and kogito name controversy it > >> makes perfect sense that the final image that is delivered for users > >> (whatever the name) includes tooling (whatever the name). > >> I think we need to assume that fact and devise a solution that honors > it. > >> > >> > >> On Wed, Mar 6, 2024 at 6:50 PM Tiago Bento <[email protected]> > wrote: > >> > >>> Dominik and Ricardo, > >>> > >>> I understand your concern with removing features from users. Too much > >>> has grown around the circular dependency we had between `kogito-apps` > >>> and `kie-tools`. We're fixing it now, and it is a challenging task. > >>> > >>> Rather than stating the "need" of `kogito-images` depending on > >>> `kie-tools`, let's keep the focus on the end result. IMHO it is > >>> irrelevant on which repo something is hosted, as long as we can do > >>> atomic releases and kick-off our release train with Apache KIE 10. > >>> That means defining a clear topology of repos during an Apache KIE > >>> build, which, by definition, can't contain cycles. > >>> > >>> Now, `kogito-images` either is part of the `drools` and `kogito-*` > >>> streams, or it's not. > >>> > >>> This PR [1] > >>> https://github.com/apache/incubator-kie-kogito-images/pull/1734 > >>> introduces a cycle, even without the changes proposed by me on the > >>> first email of this thread, so merging this PR would be introducing a > >>> blocker for the Apache KIE 10 release (and for future releases too). > >>> > >>> If we really wanted to have `kogito-images` depending on `kie-tools`, > >>> though, we would need to: > >>> > >>> 1. Make sure `kie-tools` doesn't depend on `kogito-images`; > >>> 2. Create a third development stream, just for `kogito-images`, > >>> leaving a buffer for `kogito-images` to be updated with the latest > >>> `kie-tools` version during a release. Analogous to what we do with > >>> `kie-tools` and the `drools` and `kogito-*` stream; > >>> 3. Create a mechanism to do timestamped SNAPSHOT releases of > >>> `kie-tools`, analogous to what we have on the `drools` and `kogito-*` > >>> streams now. > >>> > >>> This, IMHO, introduces a lot more complexity to our already convoluted > >>> release process, so I wouldn't go on that route. > >>> > >>> With all that said, and to be clear regarding the topology of the > >>> repository, to successfully build and release Apache KIE 10, we need > >>> to take all 22 repositories [1] we have in Apache right now, and sort > >>> them in a way that we can build them one by one, only once, without > >>> referencing older versions of any 1st-party > >>> package/module/image/artifact. > >>> > >>> We can't think about our repos in the same way we used to. KIE Tools > >>> won't have a release published before nor after a Drools or Kogito > >>> Runtimes release. Everything will be released at the same time. That's > >>> the mindset shift we all need to get used to if we want to do atomic > >>> releases of Apache KIE. > >>> > >>> I hope it is clearer now why we can't have `kogito-images` depending > >>> on `kie-tools` if `kogito-images` continues to be part of the `drools` > >>> and `kogito-*` development streams. > >>> > >>> The way I see it, Dominik came to this mail thread with an important > >>> and valid concern, which now we need to solve together, as a > >>> community. > >>> > >>> I'll keep my suggestions of either moving the image from > >>> `kogito-images` to `kie-tools`, or removing the dependency of SWF > >>> Quarkus Dev UI from it. Of course, the PR [1] can't be merged, as it > >>> will introduce a dependency cycle, so I'm -1'ing that PR too, given > >>> the blocker it will introduce to the Apache KIE 10 release. > >>> > >>> Is this image being used anywhere else? Or is `kn-plugin-workflow` the > >>> only place using it? Why does it need to stay at `kogito-images` and > >>> can't go to `kie-tools`? Same questions for the image being introduced > >>> by [1]. > >>> > >>> Let me know if I'm missing something, but I feel like our best course > >>> of action now would be moving the images to `kie-tools`. > >>> > >>> Regards, > >>> > >>> Tiago Bento > >>> > >>> > >>> [1] > >>> > https://github.com/orgs/apache/repositories?language=&q=incubator-kie&sort=&type=all > >>> > >>> > >>> On Wed, Mar 6, 2024 at 9:59 AM Alex Porcelli <[email protected]> wrote: > >>> > > >>> > Ricardo, > >>> > > >>> > Here's a better description [1] of the dependency that KIE Tools has > >>> > with the images. If we have kogito images moved to after KIE Tools, I > >>> > think we'd create a new circular dependency. > >>> > > >>> > [1] - > >>> > https://github.com/apache/incubator-kie-issues/issues/821#issuecomment-1896206199 > >>> > > >>> > On Wed, Mar 6, 2024 at 9:43 AM ricardo zanini fernandes > >>> > <[email protected]> wrote: > >>> > > > >>> > > Alex, > >>> > > > >>> > > I'm not aware of any dependencies in KIE Tools for images. > >>> > > > >>> > > On Wed, Mar 6, 2024 at 9:44 AM Alex Porcelli <[email protected]> > >>> wrote: > >>> > > > >>> > > > Ricardo, > >>> > > > > >>> > > > IIRC, there’s a dependency in KIE Tools for serverless workflow > >>> with > >>> > > > images… if this is correct, your proposal will introduce a new > >>> circular > >>> > > > dependency. > >>> > > > > >>> > > > > >>> > > > On Wed, Mar 6, 2024 at 7:39 AM ricardo zanini fernandes < > >>> > > > [email protected]> wrote: > >>> > > > > >>> > > > > Hi! > >>> > > > > > >>> > > > > A strong -1 from my side moving the images to kie-tools. We can > >>> release > >>> > > > the > >>> > > > > images after a kie-tools release or patch the images with a new > >>> kie-tools > >>> > > > > release if that comes out. It's ok to depend on it, I just need > >>> help to > >>> > > > > setup the pipelines and CI. > >>> > > > > > >>> > > > > So, when releasing SonatFlow images, we can grab the latest > >>> available > >>> > > > > kie-tools version, pack it and ship it. If a new release comes > >>> up and we > >>> > > > > need the fix, we can of course do a patch release. > >>> > > > > > >>> > > > > We just need to automate the process. > >>> > > > > > >>> > > > > Cheers! > >>> > > > > > >>> > > > > On Wed, Mar 6, 2024 at 9:33 AM Alex Porcelli < > >>> [email protected]> > >>> > > > wrote: > >>> > > > > > >>> > > > > > Dominik, > >>> > > > > > > >>> > > > > > The plans and course of action for removing the circular > >>> dependency has > >>> > > > > > been exhaustively discussed in the mailing list and Zulip > >>> channel among > >>> > > > > > community and key stakeholders, I don’t think we have room to > >>> revisit > >>> > > > the > >>> > > > > > decision that has been already agreed. > >>> > > > > > > >>> > > > > > With that being said, I don’t think the current plans removes > >>> any > >>> > > > > > functionality, we are just moving things from one repository > to > >>> > > > another. > >>> > > > > > > >>> > > > > > > >>> > > > > > On Wed, Mar 6, 2024 at 2:19 AM Dominik Hanak < > >>> [email protected]> > >>> > > > > > wrote: > >>> > > > > > > >>> > > > > > > Hi Tiago, > >>> > > > > > > > >>> > > > > > > that is a problem, we are removing an important > >>> functionality for our > >>> > > > > SWF > >>> > > > > > > users, imho it is a killer feature in this case. > >>> > > > > > > I am against it, there needs to be a solution where we can > >>> depend on > >>> > > > > > > kie-tools with kie-kogito-images. > >>> > > > > > > > >>> > > > > > > Another thing that is currently open as a PR [2] that makes > >>> images > >>> > > > > depend > >>> > > > > > > on kie-tools. Here we are following > >>> > > > > > > the approach you started in kiegroup and we were not aware > >>> of any > >>> > > > > > changes, > >>> > > > > > > now with the unexpected and sudden changes it is > irrelevant? > >>> > > > > > > Do you have a proposal on how to achieve what we have in > [2] > >>> after > >>> > > > the > >>> > > > > > > circular dependency issue is fixed according to the > proposal > >>> > > > > annoucement? > >>> > > > > > > > >>> > > > > > > Dominik > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > [2] > >>> https://github.com/apache/incubator-kie-kogito-images/pull/1734 > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > On Wed, 6 Mar 2024 at 02:10, Tiago Bento < > >>> > > > > [email protected]> > >>> > > > > > > wrote: > >>> > > > > > > > >>> > > > > > > > Hi Dominik, > >>> > > > > > > > > >>> > > > > > > > That is indeed an oversight on our part. Thanks for > >>> pointing that > >>> > > > > out. > >>> > > > > > > > > >>> > > > > > > > Unfortunately, given the two development streams > (`drools` > >>> and > >>> > > > > > > > `kogito-*`, and `kie-tools`), we can't have > `kogito-images` > >>> > > > depending > >>> > > > > > > > on packages that will start being hosted on `kie-tools`, > >>> since > >>> > > > > > > > `kogito-images` is part of the `drools` and `kogito-*` > >>> development > >>> > > > > > > > stream, which is upstream from `kie-tools`' perspective. > >>> > > > > > > > > >>> > > > > > > > Since all Dev UI packages are moving to `kie-tools`, > >>> images on > >>> > > > > > > > `kogito-images` can't depend on them. > >>> > > > > > > > > >>> > > > > > > > I'm not familiar with the structure of `kogito-images`, > >>> nor the > >>> > > > > > > > purpose of this image that uses SWF's Quarkus Dev UI, but > >>> following > >>> > > > > > > > the same reasoning we did for `kogito-management-console` > >>> and > >>> > > > > > > > `kogito-task-console`, my suggestion would be moving this > >>> image to > >>> > > > > > > > `kie-tools`. Another option I can see is simply removing > >>> the > >>> > > > Quarkus > >>> > > > > > > > Dev UI dependency on this image. > >>> > > > > > > > > >>> > > > > > > > I'd wait for other opinions, though, as I'm not the best > >>> person to > >>> > > > > > > > answer SWF-related questions. > >>> > > > > > > > > >>> > > > > > > > Regards, > >>> > > > > > > > > >>> > > > > > > > Tiago Bento > >>> > > > > > > > > >>> > > > > > > > > >>> > > > > > > > On Tue, Mar 5, 2024 at 9:31 AM Dominik Hanak < > >>> > > > [email protected]> > >>> > > > > > > > wrote: > >>> > > > > > > > > > >>> > > > > > > > > Hi Tiago, > >>> > > > > > > > > > >>> > > > > > > > > Thanks for moving this forward. > >>> > > > > > > > > > >>> > > > > > > > > I have one thing to highlight with > >>> > > > > > > > > https://github.com/apache/incubator-kie-kogito-images > >>> > > > > > > > > I noticed [1], where the swf devui is being used in an > >>> image. > >>> > > > Imho > >>> > > > > > that > >>> > > > > > > > > would require adjustments to the nightly pipelines & > >>> release > >>> > > > > process. > >>> > > > > > > > > Would it be possible to add tasks to the plan that > ensure > >>> > > > required > >>> > > > > > > > > adjustments to our CI once the migration is done? > >>> > > > > > > > > > >>> > > > > > > > > Best regards, > >>> > > > > > > > > > >>> > > > > > > > > Dominik > >>> > > > > > > > > > >>> > > > > > > > > [1] > >>> > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > https://github.com/apache/incubator-kie-kogito-images/blob/ce62b9d86c2ea0385ab85c3ef5339afe5ecdea72/modules/kogito-swf/devmode/build-config/module.yaml#L30 > >>> > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > On Fri, 1 Mar 2024 at 05:54, Tiago Bento < > >>> [email protected]> > >>> > > > > > > wrote: > >>> > > > > > > > > > >>> > > > > > > > > > Hi everyone, > >>> > > > > > > > > > > >>> > > > > > > > > > Following up on the status of this effort. > >>> > > > > > > > > > > >>> > > > > > > > > > I know I'm a bit late on the email, but it paid off, > >>> as we just > >>> > > > > had > >>> > > > > > > > > > our first green build [1] of KIE Tools with Java 17, > >>> Quarkus > >>> > > > > 3.2.9, > >>> > > > > > > > > > Maven 3.9.6 and Kogito 999-20240218-SNAPSHOT. We > ended > >>> up > >>> > > > > deciding > >>> > > > > > to > >>> > > > > > > > > > do items 1. and 2. together after all, but we > couldn't > >>> use the > >>> > > > > > latest > >>> > > > > > > > > > timestamped SNAPSHOT due to > >>> > > > > > > > > > https://issues.apache.org/jira/browse/INFRA-25546, > >>> which > >>> > > > > prevented > >>> > > > > > > the > >>> > > > > > > > > > publication of the timestamped SNAPSHOT to succeed. > >>> That's why > >>> > > > we > >>> > > > > > > > > > picked 20240218, not 20240225. > >>> > > > > > > > > > > >>> > > > > > > > > > We will proceed with some manual checks now to > confirm > >>> that > >>> > > > > > > everything > >>> > > > > > > > > > is working properly, and I hope on the next status > >>> update we > >>> > > > will > >>> > > > > > > have > >>> > > > > > > > > > the big blocker removed and that we have already made > >>> some > >>> > > > > progress > >>> > > > > > > on > >>> > > > > > > > > > items other than 1. and 2.. > >>> > > > > > > > > > > >>> > > > > > > > > > It's been great seeing everyone working together to > >>> move this > >>> > > > > > forward > >>> > > > > > > > > > as fast as possible. Thanks a lot Eder, Thiago, > >>> Rodrigo, Alex, > >>> > > > > > > > > > Fabrizio, Paulo, and Yeser! > >>> > > > > > > > > > > >>> > > > > > > > > > [1] > >>> > > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > https://github.com/apache/incubator-kie-tools/actions/runs/8105498131/job/22153897965 > >>> > > > > > > > > > > >>> > > > > > > > > > On Mon, Feb 26, 2024 at 5:59 AM Francisco Javier > >>> Tirado Sarti > >>> > > > > > > > > > <[email protected]> wrote: > >>> > > > > > > > > > > > >>> > > > > > > > > > > Hi Tiago, > >>> > > > > > > > > > > It was a nice morning reading ;) Thanks for all the > >>> time > >>> > > > > invested > >>> > > > > > > on > >>> > > > > > > > such > >>> > > > > > > > > > > detailed writing. > >>> > > > > > > > > > > @Ricardo Zanini <[email protected]> @Walter > Medvedeo > >>> > > > > > > > > > > <[email protected]> I guess dev ui can be > >>> removed > >>> > > > > from > >>> > > > > > > > current > >>> > > > > > > > > > > examples, at least from the ones I'm familiar with, > >>> since > >>> > > > their > >>> > > > > > > > README > >>> > > > > > > > > > > files do not really require any graphical tool. But > >>> to be > >>> > > > > honest, > >>> > > > > > > > since I > >>> > > > > > > > > > > have focused my work on SWF simple showcase > >>> examples, I'm > >>> > > > not > >>> > > > > > 100% > >>> > > > > > > > sure > >>> > > > > > > > > > > that's the same case for more elaborate ones, can > >>> you please > >>> > > > > > check > >>> > > > > > > > that > >>> > > > > > > > > > it > >>> > > > > > > > > > > is fine to remove dev ui? If this is not the case, > >>> maybe > >>> > > > those > >>> > > > > > > > examples > >>> > > > > > > > > > can > >>> > > > > > > > > > > be moved to the tools repository (points 9 and 10 > of > >>> Tiago's > >>> > > > > > email) > >>> > > > > > > > > > > Thanks in advance. > >>> > > > > > > > > > > > >>> > > > > > > > > > > On Fri, Feb 23, 2024 at 2:29 AM Tiago Bento < > >>> > > > > > [email protected] > >>> > > > > > > > > >>> > > > > > > > > > wrote: > >>> > > > > > > > > > > > >>> > > > > > > > > > > > DISCLAIMER: this is a long email. Feel free to > >>> jump to the > >>> > > > > > bottom > >>> > > > > > > > for > >>> > > > > > > > > > > > the concrete task list. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > This email aims to explain the issue and lay out > >>> the > >>> > > > efforts > >>> > > > > > that > >>> > > > > > > > are > >>> > > > > > > > > > > > in place to fix it. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Before we start digging into the problem, we need > >>> to > >>> > > > > > understand a > >>> > > > > > > > > > > > little bit of the history of the KIE community > and > >>> the > >>> > > > Kogito > >>> > > > > > > > > > > > initiative, at least from the part I started > >>> contributing > >>> > > > to > >>> > > > > it > >>> > > > > > > > anyway > >>> > > > > > > > > > > > :) > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Back in Business Central days, we had a single > >>> stream of > >>> > > > > > > > development. > >>> > > > > > > > > > > > We had robust CI jobs that would build the entire > >>> stack, > >>> > > > from > >>> > > > > > > > `drools` > >>> > > > > > > > > > > > to `kie-wb-distributions`. When Kogito came > about, > >>> there > >>> > > > was > >>> > > > > a > >>> > > > > > > > fission > >>> > > > > > > > > > > > in our pipelines. Kogito started to release > >>> independently > >>> > > > > from > >>> > > > > > > > > > > > everything else, and because of the organic way > >>> things > >>> > > > > started > >>> > > > > > to > >>> > > > > > > > > > > > organize themselves, the Kogito Tooling > initiative > >>> needed > >>> > > > to > >>> > > > > > have > >>> > > > > > > > its > >>> > > > > > > > > > > > own release cycle as well. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Up until we started the migration to Apache, > >>> Business > >>> > > > Central > >>> > > > > > > > > > > > continued on its `7.x` stream, Kogito was at > `1.x` > >>> stream, > >>> > > > > and > >>> > > > > > > > Kogito > >>> > > > > > > > > > > > Tooling (which was already called KIE Tools) was > >>> still on > >>> > > > > > `0.x`. > >>> > > > > > > > > > > > Drools started its own release stream as well, > >>> with `8.x`, > >>> > > > > and > >>> > > > > > > > > > > > OptaPlanner I believe had jumped to `9.x` > already. > >>> This > >>> > > > > > > > fragmentation > >>> > > > > > > > > > > > had technical implications, which we are trying > to > >>> overcome > >>> > > > > > right > >>> > > > > > > > now > >>> > > > > > > > > > > > with Apache KIE 10. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > The Apache KIE 10 release is aimed to be an > atomic > >>> release, > >>> > > > > > where > >>> > > > > > > > the > >>> > > > > > > > > > > > entire Apache KIE community follows a single > >>> release > >>> > > > stream. > >>> > > > > > This > >>> > > > > > > > > > > > means we need to make sure our code base is in > >>> sync, from > >>> > > > > > > `drools` > >>> > > > > > > > to > >>> > > > > > > > > > > > `kie-tools`. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > This whole conversation of course doesn't come > >>> without a > >>> > > > > > > > background of > >>> > > > > > > > > > > > CI pipelines, organizational perspectives of what > >>> Apache > >>> > > > KIE > >>> > > > > > is, > >>> > > > > > > > and > >>> > > > > > > > > > > > even poly- vs. mono-repo discussions. This is not > >>> the focus > >>> > > > > of > >>> > > > > > > this > >>> > > > > > > > > > > > issue, and I believe with time we'll converge > into > >>> > > > something > >>> > > > > > > > everyone > >>> > > > > > > > > > > > is comfortable with and that ultimately serves > our > >>> users > >>> > > > > well. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Due to the lack of unification and flexibility > >>> while > >>> > > > > > > bootstrapping > >>> > > > > > > > new > >>> > > > > > > > > > > > efforts, KIE Tools had to come up with a way to > >>> depend on > >>> > > > the > >>> > > > > > new > >>> > > > > > > > > > > > stuff (i.e. Kogito) without sacrificing its own > >>> integrity > >>> > > > and > >>> > > > > > > > > > > > stability. KIE Tools, as many of you know, > evolved > >>> to be a > >>> > > > > > > polyglot > >>> > > > > > > > > > > > monorepo, hosting Java, JavaScript/TypeScript, Go > >>> and > >>> > > > Docker > >>> > > > > > > > images. > >>> > > > > > > > > > > > There's a multitude of technologies at play on > KIE > >>> Tools, > >>> > > > > which > >>> > > > > > > > > > > > ultimately gives our users KIE Sandbox, VS Code > >>> and Chrome > >>> > > > > > > > Extensions, > >>> > > > > > > > > > > > and Standalone Editors that can be used as > regular > >>> > > > libraries > >>> > > > > on > >>> > > > > > > web > >>> > > > > > > > > > > > applications. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > The technical solution we found on `kie-tools` > was > >>> > > > depending > >>> > > > > on > >>> > > > > > > > Kogito > >>> > > > > > > > > > > > as if it were a 3rd party dependency. We have a > >>> single, > >>> > > > fixed > >>> > > > > > > > version > >>> > > > > > > > > > > > of it and we manually upgrade it to the latest > one > >>> > > > available > >>> > > > > > when > >>> > > > > > > > we > >>> > > > > > > > > > > > need to. This has worked amazingly well, allowing > >>> us to own > >>> > > > > the > >>> > > > > > > > > > > > codebase and avoid random breaks coming from > >>> SNAPSHOT > >>> > > > > > artifacts. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > This allowed the `drools` and `kogito-*` > >>> repositories to > >>> > > > > evolve > >>> > > > > > > > > > > > independently of `kie-tools`. This also made > >>> `kie-tools` > >>> > > > > > > > responsible > >>> > > > > > > > > > > > for adapting itself to changes coming from > >>> `drools` and > >>> > > > > > > `kogito-*`. > >>> > > > > > > > > > > > Luckily, we didn't have many incompatibilities, > >>> but right > >>> > > > now > >>> > > > > > we > >>> > > > > > > > have > >>> > > > > > > > > > > > an important one, that we'll discuss below. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Note that at this point, and for this issue in > >>> particular, > >>> > > > it > >>> > > > > > is > >>> > > > > > > > > > > > unimportant to discuss why things were done the > >>> way they > >>> > > > > were, > >>> > > > > > or > >>> > > > > > > > what > >>> > > > > > > > > > > > we should've done instead. I'm laying out the > >>> facts so that > >>> > > > > we > >>> > > > > > > can > >>> > > > > > > > > > > > understand how we're moving forward now. Of > >>> course, I would > >>> > > > > > > > personally > >>> > > > > > > > > > > > love to debate this on a separate thread :) > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > One of the most impactful features of KIE Sandbox > >>> is the > >>> > > > DMN > >>> > > > > > > > Runner. > >>> > > > > > > > > > > > It allows people to rapidly interact with their > >>> Decisions > >>> > > > as > >>> > > > > > they > >>> > > > > > > > > > > > author them, and this was all made possible > >>> because of the > >>> > > > > JIT > >>> > > > > > > > > > > > Executor (hosted at `kogito-apps`). KIE Sandbox > >>> also > >>> > > > started > >>> > > > > to > >>> > > > > > > > allow > >>> > > > > > > > > > > > users to deploy their Decisions to OpenShift, > then > >>> later to > >>> > > > > > > > > > > > Kubernetes, and now recently we allow users to > >>> deploy > >>> > > > > anything > >>> > > > > > to > >>> > > > > > > > > > > > OpenShift and Kubernetes, with a very high level > of > >>> > > > > > > customization. > >>> > > > > > > > All > >>> > > > > > > > > > > > these features depend on `kogito-*`, Quarkus, and > >>> all the > >>> > > > > > things > >>> > > > > > > > that > >>> > > > > > > > > > > > come with them. Including the Java version. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Logically, `kie-tools` depends on `drools` and > >>> `kogito-*`, > >>> > > > as > >>> > > > > > > > `drools` > >>> > > > > > > > > > > > and `kogito-*` can (and do!) exist and function > >>> without > >>> > > > > Tools, > >>> > > > > > > but > >>> > > > > > > > not > >>> > > > > > > > > > > > the other way around. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > As `kie-tools` started growing, maturing, and > >>> releasing > >>> > > > some > >>> > > > > > > > pieces of > >>> > > > > > > > > > > > technology that were useful to other domains > (i.e. > >>> > > > > Multiplying > >>> > > > > > > > > > > > Architecture), it became a dependency for other > >>> projects. > >>> > > > > Users > >>> > > > > > > > > > > > started depending on our Standalone Editors, but > >>> also on > >>> > > > the > >>> > > > > > > > > > > > Multiplying Architecture packages. One good > >>> example is > >>> > > > Kaoto, > >>> > > > > > > which > >>> > > > > > > > > > > > released a VS Code extension aligned with our > >>> architecture. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > The capability of encapsulating web components in > >>> any > >>> > > > > > technology > >>> > > > > > > > > > > > behind a well defined, statically typed API was > >>> really > >>> > > > > > appealing, > >>> > > > > > > > and > >>> > > > > > > > > > > > when the Kogito initiative started to design > their > >>> Runtime > >>> > > > > > Tools > >>> > > > > > > > > > > > (i.e., Quarkus Dev UIs, Management Console, and > >>> Task > >>> > > > Inbox), > >>> > > > > > > using > >>> > > > > > > > the > >>> > > > > > > > > > > > Multiplying Architecture was the way to go. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > That's when the circular dependency started. We > had > >>> > > > > > > > > > > > `kogito-apps/ui-packages` depending on > >>> `kie-tools`. Note > >>> > > > that > >>> > > > > > it > >>> > > > > > > > was > >>> > > > > > > > > > > > also logical for these packages to be part of the > >>> > > > `kogito-*` > >>> > > > > > > > > > > > repositories and release stream. Users upgrading > >>> to a new > >>> > > > > > version > >>> > > > > > > > of > >>> > > > > > > > > > > > Kogito would also need to have their Task Inbox, > >>> Management > >>> > > > > > > > Console, > >>> > > > > > > > > > > > and Quarkus Dev UIs aligned with the new version > >>> of Kogito. > >>> > > > > Not > >>> > > > > > > to > >>> > > > > > > > > > > > mention Job Service, Data Index etc. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > For many months (or years!), this was not an > >>> issue, as the > >>> > > > > > > > Multiplying > >>> > > > > > > > > > > > Architecture packages were very stable and very > >>> rarely were > >>> > > > > > > > modified. > >>> > > > > > > > > > > > The last big change we had was 3 years ago, with > >>> the > >>> > > > > > introduction > >>> > > > > > > > of > >>> > > > > > > > > > > > Shared Values [1], which did not impact the > >>> fire-and-forget > >>> > > > > and > >>> > > > > > > > > > > > Promise-based mechanisms we already had in place. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Although we were aware of this circular > dependency > >>> from the > >>> > > > > > > > beginning, > >>> > > > > > > > > > > > it was not that big of a deal for `kogito-apps` > to > >>> depend > >>> > > > on > >>> > > > > an > >>> > > > > > > > older, > >>> > > > > > > > > > > > dephased version of `kie-tools`. We didn't have > >>> plans of > >>> > > > > > unifying > >>> > > > > > > > the > >>> > > > > > > > > > > > streams anyway, and it was the best solution for > >>> our users > >>> > > > to > >>> > > > > > > have > >>> > > > > > > > > > > > their Runtime Tools packages released together > >>> with the > >>> > > > > Kogito > >>> > > > > > > > stream. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > That of course changed after the migration to > >>> Apache. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > If you reached this point, thank you for your > >>> interest in a > >>> > > > > > > little > >>> > > > > > > > bit > >>> > > > > > > > > > > > of the history of KIE, and I hope you can now > >>> understand > >>> > > > why > >>> > > > > > > things > >>> > > > > > > > > > > > are the way they are. Let's talk about what > >>> changed and > >>> > > > what > >>> > > > > we > >>> > > > > > > are > >>> > > > > > > > > > > > doing to adapt to the new requirements. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Hinting a little bit to what I mentioned above, > >>> this > >>> > > > > discussion > >>> > > > > > > is > >>> > > > > > > > > > > > very intertwined with the CI pipelines and > >>> > > > > versioning/releasing > >>> > > > > > > > > > > > strategies subjects, as we are essentially > >>> discussing code > >>> > > > > > > > > > > > organization, coupling/decoupling and granularity > >>> of stuff, > >>> > > > > and > >>> > > > > > > to > >>> > > > > > > > > > > > make things easier at least for a while, `drools` > >>> and > >>> > > > > > `kogito-*` > >>> > > > > > > > will > >>> > > > > > > > > > > > continue being a separate stream from > `kie-tools`. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > `drools` and `kogito-*` will continue being able > >>> to evolve > >>> > > > > > > > > > > > independently of `kie-tools`, and `kie-tools` > will > >>> continue > >>> > > > > > > > adapting > >>> > > > > > > > > > > > itself to whatever changes on `drools` and > >>> `kogito-*`. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > At the same time, Apache KIE 10 (and the next > >>> releases > >>> > > > too!) > >>> > > > > > will > >>> > > > > > > > be > >>> > > > > > > > > > > > atomic. And for our users, a single release > stream. > >>> > > > > `drools@10 > >>> > > > > > ` > >>> > > > > > > > and > >>> > > > > > > > > > > > `kogito-*@10` will be used on `kie-tools@10`. We > >>> started > >>> > > > > this > >>> > > > > > > > effort a > >>> > > > > > > > > > > > while ago, and although we should've been more > >>> open about > >>> > > > it > >>> > > > > > from > >>> > > > > > > > the > >>> > > > > > > > > > > > beginning, we are also learning how to properly > >>> communicate > >>> > > > > > > inside > >>> > > > > > > > the > >>> > > > > > > > > > > > Apache structure. Better late than never :) > Thanks > >>> for the > >>> > > > > tip > >>> > > > > > > > Tibor! > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Here's how we'll do it: > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 1. A couple of weeks ago, one of our newest > >>> committers. > >>> > > > > Rodrigo > >>> > > > > > > > > > > > Antunes, created automated jobs to weekly > publish a > >>> > > > > timestamped > >>> > > > > > > > > > > > SNAPSHOT version of `drools` and `kogito-*`. This > >>> will > >>> > > > allow > >>> > > > > us > >>> > > > > > > to > >>> > > > > > > > > > > > have a persistent, immutable version to point to > on > >>> > > > > > `kie-tools`, > >>> > > > > > > > even > >>> > > > > > > > > > > > without having a full release. Timestamped > >>> SNAPSHOTs, as > >>> > > > > we're > >>> > > > > > > > calling > >>> > > > > > > > > > > > them, are a little bit different than normal > Maven > >>> > > > SNAPSHOTs, > >>> > > > > > as > >>> > > > > > > > there > >>> > > > > > > > > > > > is no `updatePolicy`, so as time passes, the > >>> downloaded > >>> > > > > > artifacts > >>> > > > > > > > do > >>> > > > > > > > > > > > not change. This allows `kie-tools` to be stable > >>> and > >>> > > > > > incorporate > >>> > > > > > > > > > > > changes done to `drools` and `kogito-*` at its > own > >>> pace. We > >>> > > > > > also > >>> > > > > > > > moved > >>> > > > > > > > > > > > the publication of > `@kie-tools/jitexecutor-native` > >>> to this > >>> > > > > new > >>> > > > > > > > job, so > >>> > > > > > > > > > > > we won't have to maintain it on the `kie-tools` > >>> side > >>> > > > anymore. > >>> > > > > > > > Thanks > >>> > > > > > > > > > > > Rodrigo! > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 2. When we define the code freeze prior to > >>> releasing Apache > >>> > > > > > KIE, > >>> > > > > > > > > > > > `drools` and `kogito-*` will need to be frozen a > >>> little bit > >>> > > > > > > earlier > >>> > > > > > > > > > > > than `kie-tools`, leaving a buffer for > `kie-tools` > >>> to start > >>> > > > > > > > pointing > >>> > > > > > > > > > > > to the latest timestamped SNAPSHOT and adapting > >>> itself to > >>> > > > the > >>> > > > > > > > changes. > >>> > > > > > > > > > > > My initial thoughts are around 2 weeks, but with > >>> constant > >>> > > > > > updates > >>> > > > > > > > and > >>> > > > > > > > > > > > proper alignment between the two streams, I see > >>> this time > >>> > > > > > > reducing > >>> > > > > > > > to > >>> > > > > > > > > > > > a couple of days for upcoming releases. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 3. After `kie-tools` is fully functional pointing > >>> to the > >>> > > > > latest > >>> > > > > > > > > > > > timestamped SNAPSHOT of `drools` and `kogito-*`, > >>> we can now > >>> > > > > > start > >>> > > > > > > > > > > > preparing for the actual release. We will cut new > >>> branches > >>> > > > > for > >>> > > > > > > the > >>> > > > > > > > > > > > next version (i.e. 10.0.0) and update all > >>> configuration > >>> > > > files > >>> > > > > > > that > >>> > > > > > > > we > >>> > > > > > > > > > > > have to. This will be done on `drools`, > >>> `kogito-*`, and > >>> > > > > > > > `kie-tools`. > >>> > > > > > > > > > > > Every module/package will declare the same > >>> version, and > >>> > > > will > >>> > > > > > > > depend on > >>> > > > > > > > > > > > the upstream modules/packages with the same > >>> version as > >>> > > > well. > >>> > > > > We > >>> > > > > > > can > >>> > > > > > > > > > > > proceed with this staging phase as normal. > Running > >>> > > > > > > automated/manual > >>> > > > > > > > > > > > tests and eventually signing off that everything > >>> is good to > >>> > > > > go. > >>> > > > > > > > (I'm > >>> > > > > > > > > > > > not 100% on the timeline for the Apache release, > >>> but with > >>> > > > > this > >>> > > > > > > > process > >>> > > > > > > > > > > > we can guarantee that we will vote on branches > >>> that won't > >>> > > > > > change > >>> > > > > > > > when > >>> > > > > > > > > > > > we decide to release. It will be a matter of > >>> pushing tags > >>> > > > > > > pointing > >>> > > > > > > > to > >>> > > > > > > > > > > > these release branches). > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > With the release process defined, we can now > >>> discuss the > >>> > > > > exact > >>> > > > > > > > actions > >>> > > > > > > > > > > > we're taking to remove the circular dependency we > >>> have > >>> > > > > between > >>> > > > > > > > > > > > `kie-tools` and `kogito-apps`. All of which will > >>> need to be > >>> > > > > > > > addressed > >>> > > > > > > > > > > > prior to starting the release process. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 1. (Fabrizio - IN PROGRESS) Make sure `kie-tools` > >>> is on > >>> > > > Java > >>> > > > > > 17, > >>> > > > > > > > Maven > >>> > > > > > > > > > > > 3.9.6, and Quarkus 3. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/960 > >>> > > > ) > >>> > > > > > > > > > > > There's a complication here, since we still > >>> have three > >>> > > > > big > >>> > > > > > > > > > > > packages (Serverless Workflow Diagram Editor, > >>> BPMN, DMN, > >>> > > > and > >>> > > > > > > SceSim > >>> > > > > > > > > > > > Editors, and DashBuilder) on `kie-tools` that > need > >>> GWT, and > >>> > > > > as > >>> > > > > > > you > >>> > > > > > > > > > > > know, GWT together with Java upgrades usually > >>> require some > >>> > > > > > work. > >>> > > > > > > > We're > >>> > > > > > > > > > > > on GWT 2.10, which should already support Java > 17, > >>> but > >>> > > > we'll > >>> > > > > > know > >>> > > > > > > > more > >>> > > > > > > > > > > > once we try it. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 2. (Fabrizio - NOT YET STARTED) Make sure > >>> `kie-tools` is > >>> > > > > using > >>> > > > > > > the > >>> > > > > > > > > > > > latest timestamped SNAPSHOT from `kogito-*`. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/965 > >>> > > > ) > >>> > > > > > > > > > > > We have them built and published every Sunday > >>> EOD, so > >>> > > > on > >>> > > > > > > Monday > >>> > > > > > > > > > > > (Feb 25th, 2024) we'll have a brand new one to > >>> start > >>> > > > working > >>> > > > > > > with. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 3. (Thiago - IN PROGRESS) Move > >>> `kogito-apps/ui-packages` to > >>> > > > > > > > > > > > `kie-tools`. ( > >>> > > > > > > > > > > >>> https://github.com/apache/incubator-kie-issues/issues/833) > >>> > > > > > > > > > > > We started a couple of weeks ago, and we > >>> should be ~80% > >>> > > > > > done > >>> > > > > > > > with > >>> > > > > > > > > > it > >>> > > > > > > > > > > > by now. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 4. (Fabrizio - PR SENT, but blocked by 1. and 2.) > >>> Move the > >>> > > > > SWF > >>> > > > > > > > Quarkus > >>> > > > > > > > > > > > Dev UI package from `kogito-apps` to `kie-tools`. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-tools/pull/2167) > >>> > > > > > > > > > > > This can only be done after 1. and 2. are > >>> merged, since > >>> > > > > > this > >>> > > > > > > > move > >>> > > > > > > > > > > > will require `kie-tools` to be ready to build > >>> packages with > >>> > > > > > Java > >>> > > > > > > > 17, > >>> > > > > > > > > > > > Maven 3.9.6, and Quarkus 3. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 5. (Thiago - NOT YET STARTED) Move the BPMN > >>> Quarkus Dev UI > >>> > > > > > > package > >>> > > > > > > > > > > > from `kogito-apps` to `kie-tools`. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/966 > >>> > > > ) > >>> > > > > > > > > > > > We'll follow the lead of Fabrizio's PR from > 4. > >>> That's > >>> > > > > > > > essentially > >>> > > > > > > > > > > > doing exactly the same thing for the BPMN Quarkus > >>> Dev UI > >>> > > > > > module. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 6. (Rodrigo - NOT YET STARTED) Change the Jenkins > >>> release > >>> > > > > jobs > >>> > > > > > to > >>> > > > > > > > > > > > include publishing both Quarkus Dev UI modules to > >>> Maven > >>> > > > > central > >>> > > > > > > as > >>> > > > > > > > > > > > part of the Apache release. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/964 > >>> > > > ) > >>> > > > > > > > > > > > Should be pretty straight-forward, as we > >>> already have > >>> > > > > > > > experience > >>> > > > > > > > > > > > doing this for other repos. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 7. (Thiago - NOT YET STARTED) Change the > ownership > >>> of > >>> > > > > > > > `task-console` > >>> > > > > > > > > > > > and `management-console` images from > >>> `kogito-images` to > >>> > > > > > > > `kie-tools`. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/963 > >>> > > > ) > >>> > > > > > > > > > > > KIE Tools already hosts and publishes several > >>> images, > >>> > > > and > >>> > > > > > > since > >>> > > > > > > > > > > > the content of those images will now be hosted at > >>> > > > > `kie-tools`, > >>> > > > > > we > >>> > > > > > > > can > >>> > > > > > > > > > > > only host them there. > >>> > > > > > > > > > > > This also means we'll get rid of the two > >>> Quarkus apps > >>> > > > [2] > >>> > > > > > > that > >>> > > > > > > > > > > > wrap both consoles' static assets. We could be > >>> wrong about > >>> > > > > the > >>> > > > > > > > purpose > >>> > > > > > > > > > > > of those apps, so if anyone has more information, > >>> please do > >>> > > > > > reach > >>> > > > > > > > out. > >>> > > > > > > > > > > > Otherwise, we'll skip the Quarkusification of > >>> those static > >>> > > > > > assets > >>> > > > > > > > and > >>> > > > > > > > > > > > we'll ship images with `httpd` directly, like we > >>> do for KIE > >>> > > > > > > > Sandbox. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 8. (Assignee TDB - NOT YET STARTED) Deleting > >>> everything > >>> > > > that > >>> > > > > > was > >>> > > > > > > > moved > >>> > > > > > > > > > > > to `kie-tools` from `kogito-apps`. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/962 > >>> > > > ) > >>> > > > > > > > > > > > That will be the point where we actually get > >>> rid of the > >>> > > > > > > > circular > >>> > > > > > > > > > > > dependency and remove the blocker for the > release. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 9. (Assignee TDB - NOT YET STARTED) Adapt > >>> `kogito-examples` > >>> > > > > to > >>> > > > > > > all > >>> > > > > > > > the > >>> > > > > > > > > > > > changes we mentioned above. > >>> > > > > > > > > > > > ( > >>> https://github.com/apache/incubator-kie-issues/issues/961 > >>> > > > ) > >>> > > > > > > > > > > > Kogito Examples keeps being part of the > >>> `drools` and > >>> > > > > > > `kogito-*` > >>> > > > > > > > > > > > stream, meaning that example modules won't be > able > >>> to use > >>> > > > > > neither > >>> > > > > > > > of > >>> > > > > > > > > > > > the Quarkus Dev UIs, as `kie-tools` is downstream > >>> in > >>> > > > relation > >>> > > > > > to > >>> > > > > > > > the > >>> > > > > > > > > > > > `drools` and `kogito-*` stream. > >>> > > > > > > > > > > > The same would be true for Management Console > >>> and Task > >>> > > > > > > Console > >>> > > > > > > > > > > > images, but for them, we can use the `daily-dev` > >>> tag we > >>> > > > > publish > >>> > > > > > > > daily > >>> > > > > > > > > > > > from `kie-tools@main`. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > 10. (Assignee TDB - NOT YET STARTED) Create some > >>> example > >>> > > > apps > >>> > > > > > > that > >>> > > > > > > > use > >>> > > > > > > > > > > > the Quarkus Dev UIs directly on the `examples` > >>> directory of > >>> > > > > > > > > > > > `kie-tools`. ( > >>> > > > > > > > > > > >>> https://github.com/apache/incubator-kie-issues/issues/959) > >>> > > > > > > > > > > > This is to serve the same purpose of packages > >>> that did > >>> > > > > that > >>> > > > > > > on > >>> > > > > > > > > > > > `kogito-examples`, but now hosted on `kie-tools`. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Pheew! That's a lot of things to do, but it is > the > >>> result > >>> > > > of > >>> > > > > > two > >>> > > > > > > > > > > > intense weeks assessing and planning how we would > >>> address > >>> > > > > this > >>> > > > > > > > issue > >>> > > > > > > > > > > > in a way that the Apache KIE 10 release can be > >>> done in a > >>> > > > way > >>> > > > > > that > >>> > > > > > > > > > > > feels atomic to our users, who are ultimately the > >>> most > >>> > > > > > important > >>> > > > > > > > part > >>> > > > > > > > > > > > of the community. There's an open EPIC too at > >>> > > > > > > > > > > > > >>> https://github.com/apache/incubator-kie-issues/issues/967. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > I appreciate it if you reached this point, and > >>> hope you > >>> > > > feel > >>> > > > > > > > welcome > >>> > > > > > > > > > > > to contributing to solving this lengthy and > >>> historical > >>> > > > > problem > >>> > > > > > if > >>> > > > > > > > you > >>> > > > > > > > > > > > feel like doing so. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > I'll personally send updates to this thread every > >>> week, on > >>> > > > > > > Thursday > >>> > > > > > > > > > > > nights. Do not hesitate to contact me or any of > >>> the people > >>> > > > > > > > involved in > >>> > > > > > > > > > > > this effort if you have questions, or simply want > >>> to chat > >>> > > > > about > >>> > > > > > > it. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Thanks a lot Alex, Paulo, Fabrizio, Thiago, > >>> Rodrigo, and > >>> > > > > others > >>> > > > > > > > that > >>> > > > > > > > > > > > somehow helped so far. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Kind regards, > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > Tiago Bento > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > --- > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > P.S.: You might've noticed we left Trusty out of > >>> the > >>> > > > picture > >>> > > > > > for > >>> > > > > > > > now. > >>> > > > > > > > > > > > Thiago is conducting an investigation to > >>> understand what > >>> > > > > would > >>> > > > > > be > >>> > > > > > > > the > >>> > > > > > > > > > > > best course of action for it. As much as we have > >>> plans to > >>> > > > > > revive > >>> > > > > > > > it, > >>> > > > > > > > > > > > right now our focus has to be on getting Apache > >>> KIE 10 out. > >>> > > > > We > >>> > > > > > > can > >>> > > > > > > > > > > > always rely on Git to bring it back in the > future, > >>> if we > >>> > > > > > > ultimately > >>> > > > > > > > > > > > decide that wiping out Trusty is the best > strategy > >>> for this > >>> > > > > > > moment. > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > [1] > >>> https://github.com/apache/incubator-kie-tools/pull/691 > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > [2] > >>> > > > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > https://github.com/apache/incubator-kie-kogito-apps/tree/main/task-console > >>> > > > > > > > > > > > and > >>> > > > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > https://github.com/apache/incubator-kie-kogito-apps/tree/main/management-console > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> > > > > > > > > >>> > > > > >>> --------------------------------------------------------------------- > >>> > > > > > > > > > > > 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] > >>> > >>> >
