Unfortunately we confirmed that there's a dependency between serverless-operator, images and kie-tools that invalidated this proposal. (Thank you Dominik for bringing this up!)
With such circular dependency, we are back to the situation where the Apache KIE 10 is BLOCKED. A new proposal will be sent shortly. On Thu, Mar 7, 2024 at 4:18 PM Tiago Bento <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
