Zanini and Alex,
The task we agreed on for after releasing Apache KIE 10 is
https://github.com/apache/incubator-kie-issues/issues/1040. It only
describes deleting the temporary copies we'll have on KIE Tools and
reverting things back to where they were, using the fixed 10.0.0
version.
Moving `kn-plugin-workflow` and the `kogito-swf-{devmode,builder}`
images to `kogito-serverless-operator` would be a new move, which I
understand is the scope of this proposal thread.
Doing so, however, will make `kogito-serverless-operator` depend on
`kie-tools`, since the SonataFlow Quarkus Dev UI is hosted there now,
and it is a dependency of the `kogito-swf-devmode` image.
I'm saying this because I think we need to further discuss the
consequences of this change...
The `kie-tools` CI is not prepared to build
`kogito-serverless-operator`, so the way `kogito-serverless-operator`
references the SonataFlow Quarkus Dev UI will be important to
establish the boundaries between both repos. To further develop the
SonataFlow Quarkus Dev UI and have its changes reflect on the
`kogito-swf-devmode` image, we need to come up with a strategy that is
both safe, consistent, and enforces correctness. There's also the fact
that currently `kie-tools` depends on timestamped SNAPSHOTs of
Kogito/Drools, while `kogito-serverless-operator` uses 999-SNAPSHOT,
if I'm not mistaken. Can you elaborate a little bit more on how you
see this reference being done? Please consider cross-repo PRs for big
migrations like the Quarkus 3.8.4 that is currently happening.
Also, regarding point "4. Review the PR GHA checks to run CLI tests
once there's a change in the cmd module" of the proposed EPIC, I think
we might run into problems, since the `cmd` module also depends on the
`api` and `workflowproj` modules of `kogito-serverless-operator.` I'm
afraid changes made to these two modules would also need to trigger a
build of the `cmd` module, and they can potentially break it.
These considerations alone, IMHO, expose one of the biggest challenges
we have in our community right now, which is that the definition and
implementation of the dependency graph between repos/modules/packages
is currently spread across many different "build systems", like the
new proposed GHA jobs exclusive to the `kogito-serverless-operator`
repo, the Build Chain system we have for the Drools/Kogito repos, the
`kie-tools` CI, and the many Jenkins jobs we have on Apache's Jenkins.
There's also the fact that we have `kogito-images` selectively
building parts of `kogito-apps` during its own build to include them
in the images it produces.
With all that said, I'm not opposed to moving the `kn-workflow-plugin`
package from `kie-tools` to the `cmd` module of
`kogito-serverless-operator`. In fact, like I said in the past, I
think it makes a lot of sense that they're part of the same
compilation unit, as they're very closely related, and should
therefore be in sync at all times.
I just think it is important to highlight that this proposal would
only address a LOCAL problem related exclusively to the SonataFlow
section of the Apache KIE community, while, at the same time, not
contributing to reducing the segmentation of the Apache KIE community
as a whole.
Regards,
Tiago Bento
On Fri, Apr 19, 2024 at 4:08 PM ricardo zanini fernandes
<[email protected]> wrote:
>
> Alex,
>
> Yes, in the proposal we just barely outlined. I create the EPIC to have
> more details and start working on them as soon as we agree.
>
> On Fri, Apr 19, 2024 at 4:24 PM Alex Porcelli <[email protected]> wrote:
>
> > Thank you for outlining the tasks post the 10.x release. It's
> > important to note that these are already included in the amended
> > proposal [1], specifically in steps 9 and 10, which the community has
> > voted on. If there are concerns about the execution of these steps,
> > I'd like to reassure you that they will proceed as planned, in
> > compliance with Apache guidelines.
> >
> > Looking ahead, after the release of version 10, we already agreed that
> > we'll need to have a thorough discussion regarding the codebase
> > structure. This will allow us to refine our understanding of the
> > sub-brands, their interrelationships, and their strategic positioning.
> > I agree that this is crucial for our next steps and look forward to
> > our collaborative efforts in shaping this.
> >
> > [1] - https://lists.apache.org/thread/pw327lkpmy9gxklq4t5zbwzxjo2y3c0w
> >
> > On Fri, Apr 19, 2024 at 2:50 PM ricardo zanini fernandes
> > <[email protected]> wrote:
> > >
> > > Folks,
> > >
> > > I've outlined the tasks we need once we release 10.x from kie-tools:
> > > https://github.com/apache/incubator-kie-issues/issues/1102
> > >
> > > Once we release, we can detail this planning and start working on it to
> > > have a streamlined process for the next release.
> > >
> > > Please let me know if it makes sense to you. We can break down and detail
> > > the tasks once we agree on this initial plan.
> > >
> > > Cheers!
> > > --
> > > Ricardo Zanini Fernandes
> > > Vida longa e próspera.
> >
> > ---------------------------------------------------------------------
> > 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]
