PR checks are green on the main PR! I guess we just need a quick round of reviews and we'll be good to go. If we detect problems we can always send followup PRs. Thanks all!
On Mon, Apr 28, 2025 at 4:16 PM Fabrizio Antonangeli <fantonang...@apache.org> wrote: > > Thank you Tiago. > The new branch is: > https://github.com/apache/incubator-kie-tools/tree/patternfly-v5-upgrade > > Regards, > Fabrizio > > On Mon, 2025-04-28 at 12:20 -0400, Tiago Bento wrote: > > Fabrizio, > > > > Agree, good strategy. Thanks for the heads up! > > > > Regards, > > > > Tiago Bento > > > > On Mon, Apr 28, 2025 at 8:18 AM Fabrizio Antonangeli > > <fantonang...@apache.org> wrote: > > > > > > 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 > > > > > > > --------------------------------------------------------------------- > > 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
