Hi Tiago, as we are Aditya, Kennedy and me working on the same branch through PRs on Aditya's fork, I would propose to move our branch [1] to kie-tools with a new name (patternfly-v5-upgrade). The PROS of moving the branch to kie-tools repo are: * we don't consume Aditya's GH profile * faster CI run: when we create a PR against `patternfly-v5-upgrade` branch, the CI will test only the packages which has been modified and it's dependencies.
Please let me know what you think. Regards, Fabrizio 1. https://github.com/kumaradityaraj/kie-tools/tree/allpackagesp4top5On Fri, 2025-04-18 at 17:21 +0200, Fabrizio Antonangeli wrote: > Status update: Thanks also to Kennedy's effort, we fixed dmn-editor, > dmn-editor-standalone, scesim-editor and online-editor is WIP. > We have 17 e2e errors on the online-editor to fix but it seems is the > last package to be fixed. > SonataFlow/SWF side is also already fixed. > Next week I will be on PTO but there will be Aditya and Kennedy > working > on this. > Have a good weekend! > > On Fri, 2025-04-04 at 12:35 -0400, Tiago Bento wrote: > > Great suggestion Jan! Thanks! > > > > FYI I added some labels to PRs today. Most notably I marked the > > `react-router` upgrade as order:2 > > https://github.com/apache/incubator-kie-tools/pull/3042, and the > > PatternFly 5 upgrade as order:1. Meaning the PatternFly 5 upgrade > > should be merged before the `react-router` upgrade. I hope that > > eases > > things on your end Fabrizio. Since I'm working closely with Luiz on > > the `react-router` PR, we can revisit it and fix any conflicts that > > may occur after the PatternFly 5 PR is merged. > > > > Regards, > > > > Tiago Bento > > > > On Fri, Apr 4, 2025 at 8:08 AM Fabrizio Antonangeli > > <fantonang...@apache.org> wrote: > > > > > > That's true, this is also something we can try and it's also > > > easier. :- > > > ) > > > Even creating a separate kie-tools PR, so we don't leave > > > temporary > > > code > > > in the real PR. > > > Thanks a lot, Jan. > > > > > > On Fri, 2025-04-04 at 13:12 +0200, Jan Šťastný wrote: > > > > Hello, > > > > Regarding the PR check workflow - you could as part of your PR > > > > temporarily > > > > change/override the respective values and they should take > > > > effect > > > > for > > > > the > > > > particular PR only, shouldn't they? > > > > Regards > > > > Jan > > > > > > > > > > > > Dne pá 4. 4. 2025 11:15 uživatel Fabrizio Antonangeli < > > > > fantonang...@apache.org> napsal: > > > > > > > > > Thank you Tiago for you suggestions and the env vars. > > > > > Yesterday, I created the CI on a personal fork: > > > > > > > > > > https://github.com/fantonangeli/kie-tools-fantonangeli-ghas/actions/runs/14247565814 > > > > > Unfortunately I had to stop the running when GH emailed me > > > > > that > > > > > I > > > > > consumed 100% of my personal Actions usage for the current > > > > > month, > > > > > so I > > > > > don't have a result to show ATM. > > > > > I will check if I can run this in a different account. > > > > > > > > > > > > > > > On Thu, 2025-04-03 at 09:20 -0400, Tiago Bento wrote: > > > > > > No need to worry about freezing the `main` branch because > > > > > > of > > > > > > the > > > > > > release process, as releases are done from a "minor stream" > > > > > > branch, > > > > > > like `10.0.x`, or `10.1.x`. > > > > > > > > > > > > To not stop the build/test process when a test breaks, you > > > > > > can > > > > > > use > > > > > > these env vars: > > > > > > - KIE_TOOLS_BUILD__ignoreTestFailures="true" > > > > > > - KIE_TOOLS_BUILD__ignoreEndToEndTestFailures="true" > > > > > > > > > > > > These env vars are already configured like this for > > > > > > checking > > > > > > commits > > > > > > on `main`, but on PRs we left it configured as `false` to > > > > > > fail > > > > > > faster. > > > > > > I agree, however, that for an effort like this it would be > > > > > > interesting > > > > > > to have the PR checks behave in the same way as well. Doing > > > > > > that > > > > > > in > > > > > > your personal fork is a great idea, though. > > > > > > > > > > > > As for your suggestions, unfortunately I think having > > > > > > everyone > > > > > > open > > > > > > "cherry-picks" to the PF5 upgrade branch would result in > > > > > > even > > > > > > more > > > > > > chaos, since conflicts only happen after a PR is merged on > > > > > > `main`, > > > > > > and > > > > > > it wouldn't be clear who would be solving conflicts when > > > > > > multiple > > > > > > PRs > > > > > > were merged together. Splitting the work between > > > > > > "partitions" > > > > > > is > > > > > > not > > > > > > a > > > > > > bad idea, we just need to find an easy way to split the > > > > > > repository > > > > > > into disjoint sets so that we can move the upgrade > > > > > > independently > > > > > > in > > > > > > each one of them. > > > > > > > > > > > > From my experience, the most efficient way is to have one > > > > > > person > > > > > > driving the upgrade effort with regular broadcast updates > > > > > > on > > > > > > completion state, combined with requesting authors of big > > > > > > PRs > > > > > > to > > > > > > hold > > > > > > merging them until the upgrade is done, if possible, and > > > > > > frequent > > > > > > merges of course. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Tiago Bento > > > > > > > > > > > > > > > > > > On Wed, Apr 2, 2025 at 5:24 PM Fabrizio Antonangeli > > > > > > <fantonang...@apache.org> wrote: > > > > > > > > > > > > > > Hi Tiago, > > > > > > > > > > > > > > Thanks for your advice! We've been continuously merging > > > > > > > from > > > > > > > the > > > > > > > main > > > > > > > branch to keep the "delta" as small as possible. > > > > > > > > > > > > > > Please see my answers below. > > > > > > > > > > > > > > > > > > > > > On Wed, 2025-04-02 at 13:51 -0400, Tiago Bento wrote: > > > > > > > > Hi Fabrizio, > > > > > > > > > > > > > > > > Thanks for raising awareness of the issue! This upgrade > > > > > > > > is > > > > > > > > indeed > > > > > > > > very > > > > > > > > important since PatternFly is already on version 6! > > > > > > > > > > > > > > > > Having done some complicated upgrades myself in the > > > > > > > > past, > > > > > > > > I > > > > > > > > know > > > > > > > > how > > > > > > > > frustrating it can be to keep the upgrade branch up-to- > > > > > > > > date > > > > > > > > with > > > > > > > > other > > > > > > > > things being developed simultaneously. If it helps, my > > > > > > > > strategy > > > > > > > > was > > > > > > > > doing frequent merges to not let work accumulate. It's > > > > > > > > more > > > > > > > > or > > > > > > > > less > > > > > > > > fighting the clock, as the more time you take to make > > > > > > > > it > > > > > > > > stable, > > > > > > > > the > > > > > > > > less stable it gets due to other changes being merged > > > > > > > > in > > > > > > > > the > > > > > > > > `main` > > > > > > > > branch. You'll know if you're winning the race if > > > > > > > > you're > > > > > > > > ever > > > > > > > > able to > > > > > > > > get a green build, even if for a couple of hours > > > > > > > > without > > > > > > > > getting > > > > > > > > more > > > > > > > > conflicting code merged on `main`. > > > > > > > > > > > > > > > > My suggestion for you is to do frequent merges and keep > > > > > > > > regularly > > > > > > > > updating everyone else to know where you're being most > > > > > > > > impacted > > > > > > > > (package names, for example), so that people > > > > > > > > contributing > > > > > > > > to > > > > > > > > that > > > > > > > > package are aware that they can end up making this > > > > > > > > migration > > > > > > > > take > > > > > > > > longer, and if they can hold their PRs a little longer, > > > > > > > > they > > > > > > > > can > > > > > > > > help > > > > > > > > you indirectly. At the same, it helps everyone else if > > > > > > > > you're > > > > > > > > able to > > > > > > > > tell how close to completeness the PR is, so we can > > > > > > > > eventually do > > > > > > > > a > > > > > > > > 1-week stabilization period, for example, without > > > > > > > > merging > > > > > > > > anything > > > > > > > > else on `main` to make sure this upgrade is finally > > > > > > > > finished. > > > > > > > > > > > > > > Aditya has already upgraded all components using PF4. At > > > > > > > this > > > > > > > stage, we > > > > > > > are focused on syncing and fixing issues. > > > > > > > Many packages have already passed the tests, while others > > > > > > > were > > > > > > > successfully tested in an earlier stage. > > > > > > > > > > > > > > For future upgrades like this, I believe it would be > > > > > > > useful > > > > > > > to > > > > > > > have > > > > > > > a > > > > > > > Build CI that can be triggered only manually on a > > > > > > > specific > > > > > > > branch > > > > > > > without stopping execution if a package fails. This way, > > > > > > > we > > > > > > > can > > > > > > > get > > > > > > > the > > > > > > > test results for all packages. > > > > > > > As an alternative, I can also set up a CI job in a > > > > > > > personal > > > > > > > repository > > > > > > > to gather the test results and share them with you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Right now, if you're confident that the PR is very > > > > > > > > close > > > > > > > > to > > > > > > > > being > > > > > > > > ready and you were already able to get a green build > > > > > > > > (meaning > > > > > > > > that > > > > > > > > for > > > > > > > > a short period of time you had "everything working"), > > > > > > > > we > > > > > > > > can > > > > > > > > issue a > > > > > > > > freeze proposal here in the mailing list and have > > > > > > > > everyone > > > > > > > > contributing to `kie-tools` to hold their PRs until > > > > > > > > this > > > > > > > > upgrade > > > > > > > > is > > > > > > > > reviewed and merged. WDYT? > > > > > > > > > > > > > > > > > > > > > > I would avoid to freeze `main` branch (and maybe impact a > > > > > > > release > > > > > > > process) and then have a blocker like for the Serverless > > > > > > > Workflow > > > > > > > Chrome Extension, which is something that can happens in > > > > > > > these > > > > > > > activities. > > > > > > > > > > > > > > > > > > > > > I would prefer to avoid freezing the `main` branch (which > > > > > > > might > > > > > > > impact > > > > > > > the release process) and then potentially encountering > > > > > > > blockers, > > > > > > > such > > > > > > > as the issue with the Serverless Workflow Chrome > > > > > > > Extension, > > > > > > > which > > > > > > > can > > > > > > > happens in these types of upgrades. > > > > > > > > > > > > > > Please, let me know what you think! > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Tiago Bento > > > > > > > > > > > > > > > > On Wed, Apr 2, 2025 at 12:03 PM Fabrizio Antonangeli > > > > > > > > <fantonang...@apache.org> wrote: > > > > > > > > > > > > > > > > > > I totally agree freezing PF4 work is not really an > > > > > > > > > option. > > > > > > > > > But it also quite difficult to forecast the closing > > > > > > > > > time > > > > > > > > > for > > > > > > > > > this > > > > > > > > > PR as > > > > > > > > > many "variables" are involved and there can be > > > > > > > > > blockers > > > > > > > > > not > > > > > > > > > related > > > > > > > > > to > > > > > > > > > our changes. > > > > > > > > > > > > > > > > > > For instance the ubuntu-1 GHA is currently failing > > > > > > > > > because > > > > > > > > > GH > > > > > > > > > web > > > > > > > > > UI > > > > > > > > > changed something and the Serverless Workflow Chrome > > > > > > > > > Extension > > > > > > > > > is > > > > > > > > > not > > > > > > > > > passing the tests in this PR but also in this one, > > > > > > > > > which is > > > > > > > > > not > > > > > > > > > related > > > > > > > > > to our work: > > > > > > > > > https://github.com/apache/incubator-kie-tools/pull/3041 > > > > > > > > > I'm working on this fix. > > > > > > > > > > > > > > > > > > In addition to this, I think establishing a good way > > > > > > > > > to > > > > > > > > > handle > > > > > > > > > this > > > > > > > > > core activities will help us on the next ones as we > > > > > > > > > still > > > > > > > > > have > > > > > > > > > to > > > > > > > > > update React, Patternfly v6. > > > > > > > > > > > > > > > > > > On Wed, 2025-04-02 at 13:42 +0000, Jozef Marko wrote: > > > > > > > > > > Hi Fabrizio, as this is very crucial PR, I can > > > > > > > > > > imagine > > > > > > > > > > also > > > > > > > > > > we > > > > > > > > > > 'block' PRs that contain patternfly changes until > > > > > > > > > > the > > > > > > > > > > big > > > > > > > > > > PF4 > > > > > > > > > > -> > > > > > > > > > > PF5 > > > > > > > > > > PR is merged. I can imagine this only if we are > > > > > > > > > > confident > > > > > > > > > > enough > > > > > > > > > > PF4 > > > > > > > > > > -> PF5 PR will be merged in a week? or two weeks? > > > > > > > > > > Not > > > > > > > > > > sure > > > > > > > > > > what > > > > > > > > > > should be such 'blocking window' size. > > > > > > > > > > > > > > > > > > > > Personally, I can not imagine we do similar > > > > > > > > > > 'blocking > > > > > > > > > > window' > > > > > > > > > > longer > > > > > > > > > > than two weeks. Ideal 'blocking window' size > > > > > > > > > > doesn't > > > > > > > > > > exist > > > > > > > > > > for > > > > > > > > > > sure. > > > > > > > > > > We would probably agree - the shorter the better. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jozef Marko > > > > > > > > > > > > > > > > > > > > Software Developer > > > > > > > > > > > > > > > > > > > > jozef.ma...@ibm.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > From: Fabrizio Antonangeli > > > > > > > > > > <fantonang...@apache.org> > > > > > > > > > > Sent: Tuesday, April 1, 2025 4:00 PM > > > > > > > > > > To: dev@kie.apache.org <dev@kie.apache.org> > > > > > > > > > > Subject: [EXTERNAL] [PROPOSAL] Coordinating > > > > > > > > > > PatternFly 5 > > > > > > > > > > Upgrade > > > > > > > > > > Effort > > > > > > > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > > > > > > > Aditya and I are very close to finishing a PR for > > > > > > > > > > updating > > > > > > > > > > PatternFly > > > > > > > > > > to v5 [1]. The main problem we have is that while > > > > > > > > > > we > > > > > > > > > > update, > > > > > > > > > > fix > > > > > > > > > > issues, and run the CI, the work on the main branch > > > > > > > > > > using > > > > > > > > > > PF4 > > > > > > > > > > continues. This means we have to continuously sync > > > > > > > > > > our > > > > > > > > > > PR, > > > > > > > > > > update > > > > > > > > > > the > > > > > > > > > > new code to PF5, re-test, and check the CI. > > > > > > > > > > > > > > > > > > > > The CI also takes time to run, as all frontend > > > > > > > > > > packages > > > > > > > > > > use > > > > > > > > > > PatternFly, > > > > > > > > > > and the CI tests all of them. Once everything is > > > > > > > > > > green, > > > > > > > > > > reviewers > > > > > > > > > > may > > > > > > > > > > also need time to go through the PR (which includes > > > > > > > > > > 530 > > > > > > > > > > files), > > > > > > > > > > while > > > > > > > > > > in the meantime, PF4 development on `main` > > > > > > > > > > continues. > > > > > > > > > > > > > > > > > > > > Since I don't think we can freeze PF4 work until > > > > > > > > > > the > > > > > > > > > > PF5 > > > > > > > > > > update > > > > > > > > > > is > > > > > > > > > > completed, my suggestion is to establish a > > > > > > > > > > temporary > > > > > > > > > > "rule": > > > > > > > > > > > > > > > > > > > > Anyone developing PF4 code on main should also > > > > > > > > > > open a > > > > > > > > > > PR > > > > > > > > > > on > > > > > > > > > > Aditya's `allpackagesp4top5` branch with the > > > > > > > > > > corresponding > > > > > > > > > > PF5 > > > > > > > > > > update. > > > > > > > > > > > > > > > > > > > > This would be required only until the PR is > > > > > > > > > > reviewed > > > > > > > > > > and > > > > > > > > > > merged. > > > > > > > > > > > > > > > > > > > > Alternatively, can we "split" our work into SWF- > > > > > > > > > > related > > > > > > > > > > updates > > > > > > > > > > and > > > > > > > > > > Online Editor-related work? > > > > > > > > > > > > > > > > > > > > As always, I'm open to other ideas. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://github.com/apache/incubator-kie-tools/pull/2853 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------- > > > > > > > > > > -- > > > > > > > > > > ---- > > > > > > > > > > ---- > > > > > > > > > > ---- > > > > > > > > > > ---- > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > ---- > > > > > > 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 > > > > > --------------------------------------------------------------------- > 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
