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