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
