Tiago, Unfortunately, my plan is too conceptually simple to write more than I already wrote. 1) Move kn-plugin-workflow module to operator repo (this remove the dependency between tools and operator, breaking the loop) 2) Change CI global stream to execute tooling repo before operator repo (this seems to take 2 months unless Tristan helps and reduce the time to 2 weeks) 3) Optionally, and just as a consequence of that CI change, set 999-SNAPSHOT version to all poms in all repos (if current snapshot numbers turns out to be a problem, in any case this is just search-replace)
The current plan is: 1) Move everything depending on tools to tools repo, which includes operator code and examples. 2) Change CI of tooling repo to enforce dependencies between the existing modules there and the newly moved ones (this seems to take 3 weeks or less) I think rather than asking for a more detailed alternative, what needs to be done is to refine the existing proposal with the feedback received. I do not think both proposals are antagonistic. I think that, being now clear we have the same overall goal (execute tooling before operator), it is just a question of deciding between move more stuff to an already heterodox repo, coming from repos not as heterodox, plus changing the repo CI to impose certain order between these modules or pull out the the operator stuff from tool repo and put it inside the operator repo plus changing the CI handling repos to impose the desired order: first tooling and then operator. On Wed, Mar 13, 2024 at 4:12 PM Tiago Bento <tiagobentofernan...@gmail.com> wrote: > Francisco, > > 1) `kie-tools` is already a heterodox repo. The reason why I proposed > my proposal is because it is what I think is the best course of action > for our community right now. If you think there's a better way to do > it, I think everyone, including me, needs to see a proposal with a > clear execution plan with a comparable level of detail and analysis in > regards to disruption of the current state, the required effort, the > contribution workflow for cross-repo PRs, and the release process > itself. Otherwise, we risk having gaps that each person will fill in a > different way, and IMHO, that's where problems happen. +1 for examples > unification, btw :) > > 2) Ok, and +1 for no categorization. > > On Wed, Mar 13, 2024 at 10:42 AM Francisco Javier Tirado Sarti > <ftira...@redhat.com> wrote: > > > > 1) Ok, if that is the case, I do not get why your first proposal was not > > the one I'm proposing and it is apparently not detailed enough. To move > > kn-workflow from tooling to operator one and change the order in which > the > > repos are being processed. Basically, the problem of the proposed > solution > > is that it kind of converts tooling repo into a pretty heterodox repo > > compared with runtimes, drools or operator one. Also once tooling is not > a > > final repo in the overall chain, we can consider moving examples as the > > final one and include tooling showcases there (rather than splitting > > examples into examples with tooling and examples without tooling). > > 2) I think this distinction between A and B is one between several > possible > > categorizations (not much, including no categorization at all) that > > deserves a separate discussion. I will open a separate thread for that > > purpose, since we are not going to change that now and it is not really > > part of the proposal. > > > > On Wed, Mar 13, 2024 at 3:28 PM Tiago Bento < > tiagobentofernan...@gmail.com> > > wrote: > > > > > Francisco, > > > > > > 1) That's what this thread is all about... You know I don't think it's > > > ok. That's why I'm proposing the two images and the operator to move > > > into the `kie-tools` repo, where we can more granularly control the > > > order things are built, thus removing the dependency cycle. > > > > > > 2) Not sure we understand the same thing by "freeze". My proposal is > > > that we select a timestamped SNAPSHOT version from Category A repos to > > > use as base for a release. We give Category B repos some time to > > > adjust, and then cut the release branches. This can happen anytime, > > > and no contributions would ever stop because of it. The development > > > branches can continue accepting PRs normally, even during the release > > > process. Now, if what you're asking is why Category B repos refer to > > > Category A repos via timestamped SNAPSHOTs, the answer is in my first > > > email. See the paragraph starting with "An important note here is that > > > Category B repositories...". > > > > > > On Wed, Mar 13, 2024 at 10:07 AM Francisco Javier Tirado Sarti > > > <ftira...@redhat.com> wrote: > > > > > > > > Tiago > > > > There are a couple of simple and straightforward questions that I > > > > formulated, but since we both write a lot, it might have been lost. > > > Please > > > > let me ask them again. > > > > 1) Do you think it is ok that tools repo is executed after > generation of > > > > docker images that are supposed to include those tools or the > operator > > > that > > > > is supposed to deploy such images? > > > That's what this thread is all about... You know I'm not ok with it, > > > that's why I'm proposing the two images and the operator to move into > > > the `kie-tools` repo, where we can more granularly control the order > > > things are built and remove the dependency cycle. > > > > 2) Besides that, although not directly related with the current > proposal > > > we > > > > are discussing, I really think there are some restrictions taken for > > > > granted that are arbitrary and difficult to sustain on strictly > technical > > > > arguments. For example, the need to freeze the rest of the software > > > before > > > > tools are generated. Why? We have dependencies between repos that > are not > > > > handled that way: Apps depend on runtimes. Runtimes depend on drools, > > > > Operator depend on runtimes,....and we are not freezing that repos > since > > > we > > > > are all releasing at the same time. If we are all releasing at the > same > > > > time, what's the rationale behind the freeze? > > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 2:56 PM Tiago Bento <tiagobe...@apache.org> > > > wrote: > > > > > > > > > Glad to see the interest this proposal has gotten, and it's good to > > > > > see some alternatives being drafted here, although still lacking > clear > > > > > definitions and analysis in regards to disruption, required effort, > > > > > the release process itself, and history. Of course, lots of details > > > > > and clarity on the execution part would be missing too. > > > > > > > > > > As of this moment, based on what I read here, I'm assuming that > > > > > everyone who participated so far doesn't see the initial proposal > as > > > > > problematic in terms of feasibility, but some of you have a > preference > > > > > not to go with it, because it is "wrong", and apparently because it > > > > > would "jeopardize the evolution of the project". Reading these last > > > > > words made me a little sad, to be honest. But I can deal with it :) > > > > > > > > > > Please let's try and keep the discussion as objective as possible. > > > > > "Right" and "wrong" are too subjective for this kind of > conversation. > > > > > > > > > > Now, being practical, unless there are clear arguments based on > facts > > > > > and objective concepts that invalidate the initial proposal shared > on > > > > > this email, it seems to me that it is currently the only viable > > > > > proposal we have for unblocking and releasing Apache KIE 10. Of > > > > > course, if we end up seeing an alternative proposal with enough > > > > > details and a clear execution plan, I think then we'll be in a very > > > > > good position to choose from multiple options! > > > > > > > > > > > > > > > On Wed, Mar 13, 2024 at 8:36 AM 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. > > > > > > > > > > > > Of > > > > > > > > > > > > > > > >> course > > > > > > > > > > > > > > > >> > > > the rest of > > > > > > > > > > > > > > > >> > > > > > > > https://github.com/apache/incubator-kie-issues/issues/967 > > > > > > > > > > > > > > > >> > > > would still be done too. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > This doesn't come without > consequences, of > > > > > course, > > > > > > > > as > > > > > > > > > > the > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode` and > > > `kogito-swf-builder` > > > > > > > > images, > > > > > > > > > > and > > > > > > > > > > > > the > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` would be > > > moving > > > > > from > > > > > > > > > > > Category A > > > > > > > > > > > > > to > > > > > > > > > > > > > > > >> > > > Category B. This move would make them > > > have to > > > > > > > > > reference > > > > > > > > > > > > > > Category A > > > > > > > > > > > > > > > >> > > > repos through timestamped SNAPSHOTs. > Since > > > > > > > > > > `kogito-images` > > > > > > > > > > > > and > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` are > already > > > > > their own > > > > > > > > > > > > > "sub-stream" > > > > > > > > > > > > > > > >> inside > > > > > > > > > > > > > > > >> > > > Category A, though, contributions > made in > > > a > > > > > > > > cross-repo > > > > > > > > > > > > fashion > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > >> this > > > > > > > > > > > > > > > >> > > > "sub-stream" will continue being > > > possible, now > > > > > > > via a > > > > > > > > > > > single > > > > > > > > > > > > PR > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > >> > > > `kie-tools`. Cross-repo PRs between > > > Category > > > > > A and > > > > > > > > > > > Category > > > > > > > > > > > > B > > > > > > > > > > > > > > will > > > > > > > > > > > > > > > >> > > > continue not being possible, and a > 1-week > > > > > delay > > > > > > > > > between > > > > > > > > > > > > > merging > > > > > > > > > > > > > > > >> > > > something on Category A and using it > on > > > > > Category B > > > > > > > > > will > > > > > > > > > > > > still > > > > > > > > > > > > > > > >> happen. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > It's worth mentioning that > `kie-tools`, > > > > > however, > > > > > > > > does > > > > > > > > > > > allow > > > > > > > > > > > > > for > > > > > > > > > > > > > > > >> sparse > > > > > > > > > > > > > > > >> > > > checkouts and partial builds, so > working > > > with > > > > > a > > > > > > > > subset > > > > > > > > > > of > > > > > > > > > > > > the > > > > > > > > > > > > > > > >> monorepo > > > > > > > > > > > > > > > >> > > > is possible and encouraged. Making > changes > > > > > only to > > > > > > > > > > > > > > > >> > > > `packages/kn-plugin-workflow`, for > > > example, > > > > > will > > > > > > > > have > > > > > > > > > > the > > > > > > > > > > > PR > > > > > > > > > > > > > > > checks > > > > > > > > > > > > > > > >> > > > run in < 10 minutes, as you can see > here: > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-tools/actions/runs/8237244382/job/22525511722?pr=2136 > > > > > > > > > > > > > > > >> > > > . > > > > > > > > > > > > > > > >> > > > We're not compromising when running > > > partial > > > > > builds > > > > > > > > > too. > > > > > > > > > > We > > > > > > > > > > > > > know > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > >> > > > the entire repo will continue working > even > > > > > after > > > > > > > > only > > > > > > > > > > > > > building a > > > > > > > > > > > > > > > >> small > > > > > > > > > > > > > > > >> > > > subset of the changes. Doing partial > or > > > full > > > > > > > builds > > > > > > > > is > > > > > > > > > > > > > > > automatically > > > > > > > > > > > > > > > >> > > > determined by the changes of a PR. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > Keep in mind that, even though I'm > > > proposing > > > > > we > > > > > > > > move a > > > > > > > > > > > bunch > > > > > > > > > > > > > of > > > > > > > > > > > > > > > >> > > > additional stuff into `kie-tools`, I > see > > > this > > > > > as a > > > > > > > > > > > TEMPORARY > > > > > > > > > > > > > > > >> solution > > > > > > > > > > > > > > > >> > > > for our codebase. `kie-tools` would > host > > > some > > > > > > > > > additional > > > > > > > > > > > > stuff > > > > > > > > > > > > > > > >> > > > TEMPORARILY so that we can release and > > > > > continue > > > > > > > > moving > > > > > > > > > > > > > forward. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > As I mentioned on other places, > > > `kie-tools` > > > > > > > became a > > > > > > > > > > > > polyglot > > > > > > > > > > > > > > > >> monorepo > > > > > > > > > > > > > > > >> > > > out of necessity, and although I'm > really > > > > > proud of > > > > > > > > > what > > > > > > > > > > we > > > > > > > > > > > > > > > achieved > > > > > > > > > > > > > > > >> > > > there so far, I don't think > `kie-tools` > > > has a > > > > > > > setup > > > > > > > > > that > > > > > > > > > > > is > > > > > > > > > > > > > > > suitable > > > > > > > > > > > > > > > >> > > > for all the different nuances that > > > compose our > > > > > > > > > > community. > > > > > > > > > > > > I'm > > > > > > > > > > > > > > well > > > > > > > > > > > > > > > >> > > > aware that a polyglot monorepo that > does > > > not > > > > > > > follow > > > > > > > > > > > > widespread > > > > > > > > > > > > > > > >> > > > conventions will scare some people > away, > > > and > > > > > as > > > > > > > much > > > > > > > > > as > > > > > > > > > > > > we've > > > > > > > > > > > > > > > tried > > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > > >> > > > make build instructions clear, we > can't > > > > > always get > > > > > > > > > past > > > > > > > > > > > the > > > > > > > > > > > > > > > >> prejudice > > > > > > > > > > > > > > > >> > > > some people have towards the > "front-end" > > > > > > > ecosystem. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > With all that said, I keep thinking > this > > > is > > > > > the > > > > > > > best > > > > > > > > > > > course > > > > > > > > > > > > of > > > > > > > > > > > > > > > >> action > > > > > > > > > > > > > > > >> > > > for us right now. We keep most of our > > > stuff > > > > > > > > unchanged, > > > > > > > > > > we > > > > > > > > > > > > > > unblock > > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > > >> > > > release, and we have a working setup > that > > > will > > > > > > > suit > > > > > > > > us > > > > > > > > > > > well > > > > > > > > > > > > > > while > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > >> > > > discuss and reach a conclusion > regarding > > > the > > > > > > > future > > > > > > > > of > > > > > > > > > > our > > > > > > > > > > > > > > > codebase > > > > > > > > > > > > > > > >> > > > structure. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > Let me paint a quick picture here of > what > > > our > > > > > code > > > > > > > > > base > > > > > > > > > > > > would > > > > > > > > > > > > > > look > > > > > > > > > > > > > > > >> > > > like, repository-wise, if my proposal > is > > > > > accepted: > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > CATEGORY REPO > > > > > > > > > > > > > > > >> > > > ===================== > > > > > > > > > > > > > > > >> > > > A > incubator-kie-kogito-pipelines > > > > > > > > > > > > > > > >> > > > A incubator-kie-drools > > > > > > > > > > > > > > > >> > > > A incubator-kie-optaplanner > > > > > > > > > > > > > > > >> > > > A > > > > > incubator-kie-optaplanner-quickstarts > > > > > > > > > > > > > > > >> > > > A > incubator-kie-kogito-runtimes > > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-apps > > > > > > > > > > > > > > > >> > > > A > incubator-kie-kogito-examples > > > > > > > > > > > > > > > >> > > > A > incubator-kie-kogito-images > > > > > > > > > > > > > > > >> > > > A incubator-kie-kogito-docs > > > > > > > > > > > > > > > >> > > > A > > > incubator-kie-kogito-benchmarks > > > > > > > > > > > > > > > >> > > > A incubator-kie-docs > > > > > > > > > > > > > > > >> > > > A incubator-kie-benchmarks > > > > > > > > > > > > > > > >> > > > ===================== > > > > > > > > > > > > > > > >> > > > B > > > > > > > > incubator-kie-sandbox-quarkus-accelerator > > > > > > > > > > > > > > > >> > > > B incubator-kie-tools > > > > > > > > > > > > > > > >> > > > ===================== > > > > > > > > > > > > > > > >> > > > D > incubator-kie-kogito-operator > > > > > > > > > > > > > > > >> > > > ===================== > > > > > > > > > > > > > > > >> > > > E incubator-kie-issues > > > > > > > > > > > > > > > >> > > > E > incubator-kie-kogito-website > > > > > > > > > > > > > > > >> > > > E incubator-kie-website > > > > > > > > > > > > > > > >> > > > E > incubator-kie-kogito-online > > > > > > > > > > > > > > > >> > > > E > > > > > incubator-kie-kogito-online-staging > > > > > > > > > > > > > > > >> > > > ===================== > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > * Category C becomes part of Category > A, > > > and > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` moves > > > entirely > > > > > inside > > > > > > > > > > > > > `kie-tools`. > > > > > > > > > > > > > > > >> > > > * With `kogito-swf-{builder,devmode}` > > > images > > > > > and > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator` inside > > > > > `kie-tools`, > > > > > > > > there > > > > > > > > > > are > > > > > > > > > > > > no > > > > > > > > > > > > > > > cycles > > > > > > > > > > > > > > > >> > > > anymore, as inside `kie-tools`, we can > > > > > granularly > > > > > > > > > build: > > > > > > > > > > > > > > > >> > > > 1. > > > packages/sonataflow-deployment-webapp > > > > > > > > > > > > > > > >> > > > 2. > packages/sonataflow-quarkus-devui > > > > > > > > > > > > > > > >> > > > 3. packages/sonataflow-images > > > (containing > > > > > > > > > > > > > > `kogito-swf-builder` > > > > > > > > > > > > > > > >> and > > > > > > > > > > > > > > > >> > > > `kogito-swf-devmode`) > > > > > > > > > > > > > > > >> > > > 4. packages/sonataflow-operator > > > (contents > > > > > from > > > > > > > > > > > > > > > >> > > > `kogito-serverless-operator`) > > > > > > > > > > > > > > > >> > > > 5. packages/kn-plugin-sonataflow > > > > > > > > > > > > > > > (`packages/kn-plugin-workflow`, > > > > > > > > > > > > > > > >> > > > but renamed) > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > The second part of the proposal is the > > > release > > > > > > > > process > > > > > > > > > > > > itself, > > > > > > > > > > > > > > > >> > > > assuming the structure above is what > we > > > have. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > Here it is: > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > 1. Define a timestamped SNAPSHOT to be > > > used as > > > > > > > > cutting > > > > > > > > > > > point > > > > > > > > > > > > > for > > > > > > > > > > > > > > > >> > > > Category A repos. > > > > > > > > > > > > > > > >> > > > 2. Update Category B repos to point to > > > this > > > > > > > > > timestamped > > > > > > > > > > > > > > SNAPSHOT, > > > > > > > > > > > > > > > >> and > > > > > > > > > > > > > > > >> > > > verify that everything is working. > > > > > > > > > > > > > > > >> > > > 3. At this point, with everything > > > working, we > > > > > can > > > > > > > > > branch > > > > > > > > > > > out > > > > > > > > > > > > > to > > > > > > > > > > > > > > > >> > > > `10.0.x`. Category A from the > timestamped > > > > > SNAPSHOT > > > > > > > > > tag, > > > > > > > > > > > and > > > > > > > > > > > > > > > >> Category B > > > > > > > > > > > > > > > >> > > > from `main`. > > > > > > > > > > > > > > > >> > > > 4. All Category A and Category B repos > > > update > > > > > > > their > > > > > > > > > > > versions > > > > > > > > > > > > > to > > > > > > > > > > > > > > > >> > > > 10.0.0, in their `10.0.x` branches. > > > > > > > > > > > > > > > >> > > > 5. Update Category B repos to point to > > > > > Category A > > > > > > > > > repos > > > > > > > > > > > > using > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > >> > > > 10.0.0 version. > > > > > > > > > > > > > > > >> > > > 6. At this point, we can vote on the > > > release > > > > > based > > > > > > > > on > > > > > > > > > > the > > > > > > > > > > > > > > `10.0.x` > > > > > > > > > > > > > > > >> > > > branches, given we don't expect any > code > > > > > changes > > > > > > > > > > anymore. > > > > > > > > > > > > > > > >> > > > 7. After voting passes, we're good to > > > start > > > > > the > > > > > > > > > release > > > > > > > > > > > > > process. > > > > > > > > > > > > > > > >> > > > 8. Category A repos follow their > > > > > manual/automated > > > > > > > > > > release > > > > > > > > > > > > > > process, > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags > > > pushed > > > > > to > > > > > > > Git, > > > > > > > > > and > > > > > > > > > > > > built > > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries. > > > > > > > > > > > > > > > >> > > > 9. We wait a little bit for Category A > > > > > artifacts > > > > > > > to > > > > > > > > be > > > > > > > > > > > > > > propagated > > > > > > > > > > > > > > > on > > > > > > > > > > > > > > > >> > > > registries. ~1 day. > > > > > > > > > > > > > > > >> > > > 10. Category B repos follow their > > > > > manual/automated > > > > > > > > > > release > > > > > > > > > > > > > > > process, > > > > > > > > > > > > > > > >> > > > pointing to the `10.0.x` branch. Tags > > > pushed > > > > > to > > > > > > > Git, > > > > > > > > > and > > > > > > > > > > > > built > > > > > > > > > > > > > > > >> > > > artifacts pushed to their registries. > > > > > > > > > > > > > > > >> > > > 11. Category D repos are ignored. > > > > > > > > > > > > > > > >> > > > 12. Category E repos can be manually > > > tagged > > > > > with > > > > > > > > > 10.0.0 > > > > > > > > > > > from > > > > > > > > > > > > > > their > > > > > > > > > > > > > > > >> > > > default branches. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > More needs to be discussed if we're > > > planning > > > > > to > > > > > > > > > maintain > > > > > > > > > > > > > > multiple > > > > > > > > > > > > > > > >> > > > release streams in parallel, but I > guess > > > it > > > > > can > > > > > > > wait > > > > > > > > > for > > > > > > > > > > > > after > > > > > > > > > > > > > > > >> Apache > > > > > > > > > > > > > > > >> > > > KIE 10. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > Thank you for reading, and I'm looking > > > > > forward to > > > > > > > > > > hearing > > > > > > > > > > > > back > > > > > > > > > > > > > > > from > > > > > > > > > > > > > > > >> > > > everyone. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > Of course, alternative solutions are > > > possible. > > > > > > > This > > > > > > > > > > email, > > > > > > > > > > > > > > > however, > > > > > > > > > > > > > > > >> > > > summarizes my view of how we should > > > attack the > > > > > > > > > problem, > > > > > > > > > > > > > > > considering > > > > > > > > > > > > > > > >> > > > disruption, required effort, the > release > > > > > process > > > > > > > > > itself, > > > > > > > > > > > and > > > > > > > > > > > > > > > >> history. > > > > > > > > > > > > > > > >> > > > Feel free to propose alternatives. > This is > > > > > not a > > > > > > > > > voting > > > > > > > > > > > > > thread. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > Regards, > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > Tiago Bento > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > > >> > > > To unsubscribe, e-mail: > > > > > > > > > dev-unsubscr...@kie.apache.org > > > > > > > > > > > > > > > >> > > > For additional commands, e-mail: > > > > > > > > > > dev-h...@kie.apache.org > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > >
