Francisco, Unfortunately I don’t think we are ready to have a conversation about how the future will look like. There’s indeed a need to revisit the whole codebase organization and even the branding positioning (as also mentioned by Ricardo).
Such type of discussions will take time, and I don’t think it’s fair to keep the release hostage because of that. On Wed, Mar 13, 2024 at 9:58 AM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Ok. I now can see why you are supporting the current proposal ;). > However, in order to accept it, I would like to link this temporary > proposal with a future one that accepts that tools repo cannot be the > final one on the ci stream (and remove the freeze condition on the other > repos, which is as absurd as runtime imposing a freeze on drools). > Without that compromise to fix the tools repo overall position in our > project, I cannot accept this temporary solution, because someone can argue > that, after all, is conceptually fine, which, in my opinion, is not the > case. > > On Wed, Mar 13, 2024 at 2:50 PM Alex Porcelli <a...@porcelli.me> wrote: > > > The guestimate of the plan discussed in this thread is around 2-3 weeks. > > > > On Wed, Mar 13, 2024 at 9:47 AM Francisco Javier Tirado Sarti > > <ftira...@redhat.com> wrote: > > > > > > Ok, thanks Alex for the clarification. > > > So two months for changing the order of repos, that sounds realistic, > > based > > > on precedent, to me. > > > Which is the estimation for the changes to be done in tools repo once > all > > > operator stuff is there? > > > What I'm trying to find out now is if the proposed solution really > takes > > > less time. At the end both solutions imply moving stuff around between > > > repos and changing CI, that's why I'm so insistent in pursuing the one > > that > > > makes more sense from a SW dependency point of view: one that does not > > make > > > "tooling" to be the final repo being processed. > > > > > > On Wed, Mar 13, 2024 at 2:33 PM Alex Porcelli <a...@porcelli.me> > wrote: > > > > > > > Francisco, > > > > > > > > As I wrote earlier, I had a conversation with Jan - that is our > > > > community CI expert - and he said that he guesses that it would take > > > > about 2 months to make CI changes implied in your comments. > > > > > > > > He also mentioned that if Tristan was around and could dedicate his > > > > time on this, he believes that Tristan could make the same changes > > > > potentially in about 2 weeks. > > > > > > > > > > > > On Wed, Mar 13, 2024 at 9:26 AM Francisco Javier Tirado Sarti > > > > <ftira...@redhat.com> wrote: > > > > > > > > > > @Ricardo Zanini <zan...@redhat.com> The main issue I have is why > we > > > > > conclude 1 takes less time than 2?. If I understood 1) completely, > it > > > > also > > > > > requires CI adjustments (at tools repo level, not at overall stream > > > > level), > > > > > so I hardly see the estimation different for someone that is > familiar > > > > with > > > > > CI. > > > > > > > > > > On Wed, Mar 13, 2024 at 2:14 PM ricardo zanini fernandes < > > > > > ricardozan...@gmail.com> wrote: > > > > > > > > > > > Hi! > > > > > > > > > > > > Clearly, you all understand that moving images and the operator > to > > > > > > kie-tools is a workaround and wrong in all possible scenarios, > > right? > > > > We > > > > > > won't undo once we merge. I'm pretty positive that once we have a > > > > release > > > > > > train going people will add all the obstacles they can add saying > > "It's > > > > > > working, let's not change it". > > > > > > > > > > > > Also, I understand that we need to unblock the release. We can > > > > compromise > > > > > > in COPYING the code, do the release, and then make the necessary > > > > changes. > > > > > > Images and cloud code are *integration platforms*. Should be the > > last > > > > in a > > > > > > stream. Tooling SHOULD NOT, in any case, depend on the images to > > build. > > > > > > > > > > > > So we can: > > > > > > > > > > > > 1. Accept Tiago's proposal (very well detailed, thanks!) but > > COPYING > > > > the > > > > > > code base, not MERGING. The contributions still flow to the right > > > > repos. > > > > > > 2. After release we: > > > > > > 1. Move the CLI to the operator repo, removing this > dependency > > from > > > > > > tools to image > > > > > > 2. Adjust the CI > > > > > > 3. Remove the copied code > > > > > > > > > > > > Moving forward, I'd like to see a clear boundary between the > > projects > > > > (as > > > > > > stated in the temporary website). At the moment, we do not have. > > And > > > > it's > > > > > > hard for anyone from outside to understand what we are doing. > > > > > > > > > > > > On Wed, Mar 13, 2024 at 9:37 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 > > >
