Alright, lots to unpack here! Thank you so much for the interest in
this effort, and yeah, we won't escape a much broader conversation
about our structure in regards to poly- vs mono-repo, the CI builds,
topology and all that. Let me try to get everything cleared out for
this thread, though. Here are some bullet points I extracted from your
messages:

A. Missing proposal, raised by Dominik --> Got your point. I think
this could've been done in a much more transparent and slow-paced way,
and we will definitely use this experience as a lesson. This effort
emerged from the need of an atomic Apache KIE release, and those plans
were mainly discussed at the Friday meetings. I guess given our urge
to get this first release out, we ended up skipping the regular
proposal process. Just remember we're all learning how to be part of
an Apache project, and how to use its proper communication channels,
so we can expect this kind of "mistake" happening again. Let's be
patient and understand that everyone is susceptible to it.

B. Unrelated stuff on the same repo, raised by Francisco --> I
personally don't think that any of the images we're considering moving
to KIE Tools would be unrelated to what KIE Tools already hosts, nor
to its general purpose. KIE Tools concentrates projects that are
complementary to the technologies and engines we have. A `devmode`
image for `kn-plugin-workflow` being hosted on KIE Tools sounds
expected to me, analogous to what we have for Dev deployments on KIE
Sandbox.

C. Circular dependencies being determined by code, not repos, raised
by Gabriele --> Given a poly-repo setting (which is what we have on
Apache KIE right now), we can't escape having an order in which repos
have to be built.`kie-tools` is built after `kogito-apps`, and I guess
everyone agrees that this is expected, and correctly represents our
community's topology. The fact that the Quarkus Dev UI packages were
depending on `kie-tools` and hosted on `kogito-apps`, introduces a
cycle, breaking that topology. That's exactly what we're trying to fix
here, but it's not without consequences, of course, as a lot has grown
around this broken topology already.

D. Moving things to the same repo not being a solution, raised by
Gabriele --> This in fact solves the problem in our case, as our cycle
is currently structural, not logical. Our individual modules are
correctly modeled, they're just hosted in the wrong place.

E. `kogito-images` depending on `kie-tools` as a goal, raised by
multiple people --> As I mentioned on one of my other emails, this is
technically possible, of course, but it will introduce a lot more
complexity to our release process and automation jobs. Restricting our
development streams to two (`drools` and `kogito-*`, and `kie-tools`)
will allow us to more easily come up with a definitive solution,
which, IMHO, is not creating more streams.

F. New repo for operator + kn-plugin-workflow + devmode image, raised
by Ricardo --> I guess we're already on the same page that this won't
be an option, unfortunately...

E. [ANNOUNCEMENT] vs [HEADS UP], raised by Alex --> Noted. Thanks for
mentioning it!

I hope I was able to somewhat address many of the concerns and
comments raised here at this thread, and please if you feel like
starting a digression from this discussion, let's do it in a separate
email thread. I know it is really hard to talk about topology without
bringing other factors in, but let's try to keep the email threads
focused and as soon as we feel a new topic emerging, start a separate
thread.

This is especially true for the whole poly- vs. mono-repo subject. You
know I'll love discussing it :)

Before I go back to talking about the circular dependency issue, let
me just take a quick paragraph to apologize for suggesting the removal
of SWF Quarkus Dev UI from the `devmode` image as an option, as I
understand it might've sounded like I was implying that the Dev UI was
unimportant. That was not my intention at all.

Ok, keeping it practical here then, let me share the updated status
and tasks for the removal of the circular dependency between
`kogito-apps` and `kie-tools`.
(EPIC -> https://github.com/apache/incubator-kie-issues/issues/967)

1. (DONE) Make sure `kie-tools` is on Java 17, Maven 3.9.6, and Quarkus 3.
(https://github.com/apache/incubator-kie-tools/pull/2182)
    Done.

2. (Eder and others - PR SENT) Make sure `kie-tools` is using the
latest timestamped SNAPSHOT from `kogito-*`.
(https://github.com/apache/incubator-kie-issues/issues/965)
    We had part of this done on 1., but there's an open PR
(https://github.com/apache/incubator-kie-tools/pull/2136) that will
finish upgrading some packages to the latest timestamped SNAPSHOT,
concluding this task.

3. (Thiago - PR SENT) Move `kogito-apps/ui-packages` to `kie-tools`.
(https://github.com/apache/incubator-kie-issues/issues/833)
    Almost done, missing some manual checks before merging, but the
build is green already.

4. (Fabrizio - PR SENT) Move the SWF Quarkus Dev UI package from
`kogito-apps` to `kie-tools`.
(https://github.com/apache/incubator-kie-tools/pull/2167)
    Still blocked by 2.

5. (Pere - 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)
    Unaltered from original plan, but assignee changed to Pere, as
Thiago will be out for a few weeks.

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)
    Unaltered from original plan.

7. (Pere - 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)
    Unaltered from original plan, but assignee changed to Pere, as
Thiago will be out for a few weeks.

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)
    Unaltered from original plan.

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)
    Unaltered from original plan.

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)
    Unaltered from original plan.

11. (Assignee TDB - NOT YET STARTED) Move the `kogito-swf-devmode`
image from `kogito-images` to `kie-tools`.
(https://github.com/apache/incubator-kie-issues/issues/1001)
    NEW! Thanks all for helping us identify this.

After 2. and 3. are merged, I feel like we can work in parallel for
the remaining tasks, as they're not blocking between each other.

Thanks again everyone. We can use the meeting tomorrow to discuss it
in more depth if necessary.

Regards,

Tiago Bento


On Thu, Mar 7, 2024 at 12:43 PM Alex Porcelli <[email protected]> wrote:
>
> Ricardo, Eder and Community Members,
>
> We definitely need to have a conversation about how best to deal with
> our repositories and in general the whole codebase organization. I
> think it's fair to say that it's not working well. We also consume
> many times more computing resources that we should and we have complex
> workflows using external CI on top of CI to coordinate such
> complexity.
>
> With that being said, I don't think this is the right moment to do so.
> My suggestion is that we find a solution for the current problem and I
> ack that it might not be a small change.
>
>
> On Thu, Mar 7, 2024 at 12:27 PM ricardo zanini fernandes
> <[email protected]> wrote:
> >
> > Yeah I forgot about the jars now in tools that we need in images. So I
> > guess the solution is to move everythign to one single monorepo. That might
> > be really tough to handle in the long run.
> >
> > I hope I can learn how to pull specific folders from the monorepo then. 😅
> >
> > --
> > Ricardo Zanini Fernandes
> > Vida longa e próspera.
> >
> >
> > On Thu, 7 Mar 2024 at 1:33 PM Eder Ignatowicz <[email protected]> wrote:
> >
> > > Zanini,
> > >
> > > On Thu, Mar 7, 2024 at 9:44 AM ricardo zanini fernandes <
> > > [email protected]> wrote:
> > >
> > > > Hi! Apart from the kn-workflow, what else kie-tools depends on the
> > > images?
> > > >
> > >
> > > Paulo/Caponetto can elaborate more, but remember that in the past, we
> > > stopped using tools for custom images to use only images from images repo?
> > >
> > > Also, what do we do in cases like this one?
> > > https://github.com/apache/incubator-kie-kogito-images/pull/1734
> > >
> > > My guess is that we will eventually include something from tools in
> > > an image, and if I understand correctly, operator repo (including
> > > kn-workflow, images) -> runtimes -> kie-tools will not accommodate that.
> > >
> > >
> > >
> > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> 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]

Reply via email to