Re: [PROPOSAL] - Dockerhub admins - Must be two persons in the community

ity, I don't see the mandate for first release > > >> manager to be dockerhub admin. > > >> > > >> I would like to prevent myself becoming the only one with releasing > > >> knowledge and privileges, so I hereby decline this nomination. I

Re: [PROPOSAL] - Dockerhub admins - Must be two persons in the community

I’d be interested on this. On Mon, May 27, 2024 at 9:46 AM ricardo zanini fernandes < ricardozan...@gmail.com> wrote: > Friends, > > As you can see in the JIRA [1], we need two commiters to be admins in the > Dockerhub. From there, we can create tokens to work on the CI tools. > > I propose to

Re: [PROPOSAL] Abandon PR checks in Jenkins

+1 On Wed, May 22, 2024 at 5:09 AM Jan Šťastný wrote: > Hello, > > Luckily the github actions workflows are defined within each respective > repository, so it's fully under the developers controls to configure what > is run and how (I assume a profile or system-property needs to be set). > >

Re: [PROPOSAL] Release manager for Apache KIE (incubator) 10.0.0

+1 for Jan! On Fri, May 17, 2024 at 11:55 AM Tiago Bento wrote: > Hi everyone, > > For those who attended the call today [1], we mentioned that > appointing a Release Manager [2] is part of the release process. It's > also necessary for signing the artifacts [3] that compose our release, >

Re: [HEADS-UP] - Upcoming image tag changes to Docker.io

nk it's fair to have it there. > > On Thu, May 16, 2024 at 2:08 PM Alex Porcelli wrote: > > > Ricardo, > > > > I noticed that you included the serverless operator repo, however for > > the current state this repo doesn't exist for apache release.. I'm > > concerned

Re: [HEADS-UP] - Upcoming image tag changes to Docker.io

Ricardo, I noticed that you included the serverless operator repo, however for the current state this repo doesn't exist for apache release.. I'm concerned that this might confuse the IPMC =/ On Thu, May 16, 2024 at 12:20 PM ricardo zanini fernandes wrote: > > Here's the ticket:

Re: [PROPOSAL] - Migrating from Quay to Dockerhub

+1 On Tue, May 14, 2024 at 11:12 AM ricardo zanini fernandes wrote: > > Folks, > > We need to move to Dockerhub from Quay for our first release duo to Apache > Guidelines [1]. > > Here's my initial impact assessment: > > - *Kogito Runtimes* ( >

Re: [PROPOSAL] - Moving CLI and SonataFlow images back to SonataFlow operator's repo

omething > > > else. > > > > > > The other topic you are talking is the build. The question was summarized > > > by Francisco.if we build the repos in order, does kie tool able to build > > > properly with the snapshots built in the pipeline or does need add

Re: [PROPOSAL] - Moving CLI and SonataFlow images back to SonataFlow operator's repo

e cause why > > they > > > are missing checks in our PR, it could be resources it could be > something > > > else. > > > > > > The other topic you are talking is the build. The question was > summarized > > > by Francisco.if we build the repos in o

Re: [PROPOSAL] - Moving CLI and SonataFlow images back to SonataFlow operator's repo

> > > > >> > > On Mon, Apr 22, 2024 at 10:02 PM Tiago Bento < > > tiagobe...@apache.org> > > > >> wrote: > > > >> > > > > > >> > > > Zanini and Alex, > > > >> > > > > > > >> > &g

Re: [DISCUSS] Output of one workflow as input of another

, 6 may 2024, 17:16, Francisco Javier Tirado Sarti < > > ftira...@redhat.com> escribió: > > > > > Alex, I might be missing something, but I do not think this scenario can > > be > > > covered through event consumption. The key part is that w

Re: [DISCUSS] Output of one workflow as input of another

gt; be > > covered through event consumption. The key part is that workflows of > type B > > are manually executed by users, which will provide its own set of > > parameters. Workflow of type A is just setting a variable context which > is > > shared by all workflows of

Re: [DISCUSS] Output of one workflow as input of another

Isn’t this already achievable using events with different topics? - Alex On Mon, May 6, 2024 at 11:02 AM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Hi, > This is related with issue > https://github.com/apache/incubator-kie-kogito-runtimes/issues/3495 > We have one user which

Re: [HEADS-UP] SNAPSHOTS are not up to date

Thank you, Jan - really appreciate your proactiveness! Please keep us posted! On Mon, May 6, 2024 at 9:58 AM Jan Šťastný wrote: > > The workaround resolves the issue. > > But to apply the workaround, it turns out the easiest way is to drop the > existing jobs. It's not clear to me why all of a

Re: [HEADS-UP] Upgrade Quarkus to 3.8.4 for KIE 10.0.0 release

All merged, now we'll start the KIE Tools upgrade - starting with a new weekly snapshot. On Thu, May 2, 2024 at 11:27 AM Alex Porcelli wrote: > > Issue to track has been created: > https://github.com/apache/incubator-kie-issues/issues/1144 > > Based on feedback so far, I'l

Re: [HEADS-UP] Upgrade Quarkus to 3.8.4 for KIE 10.0.0 release

Issue to track has been created: https://github.com/apache/incubator-kie-issues/issues/1144 Based on feedback so far, I'll merge the PRs. On Thu, May 2, 2024 at 5:00 AM Gabriele Cardosi wrote: > > +1 > > Il giorno gio 2 mag 2024 alle ore 10:57 Yeser Amer ha > scritto: > > > + 1 > > I suggest

Re: [HEADS-UP] Upgrade Quarkus to 3.8.4 for KIE 10.0.0 release

+1 - this is holding us for way too long! On Tue, Apr 30, 2024 at 10:25 AM Tibor Zimányi wrote: > > Hi everyone, > > this is a status update about the Quarkus upgrade, that is in progress. > There are PRs open, nearly all PR checks are green, except Jenkins job on > kogito-apps failing on some

Re: [PROPOSAL] - Moving CLI and SonataFlow images back to SonataFlow operator's repo

Thank you for outlining the tasks post the 10.x release. It's important to note that these are already included in the amended proposal [1], specifically in steps 9 and 10, which the community has voted on. If there are concerns about the execution of these steps, I'd like to reassure you that

[PROPOSAL] Upgrade Quarkus to 3.8.4 for KIE 10.0.0 release

I have been exploring the possibility of upgrading Quarkus to the latest LTS version, 3.8.x, as the current 3.2.x version is nearing the end of its support period according to the Quarkus LTS policy [1]. After overcoming some initial challenges and thanks to the excellent collaboration with Luca

Re: [PROPOSAL] Adding more counters to existing metric

+1 On Fri, Apr 19, 2024 at 12:05 PM Francisco Javier Tirado Sarti wrote: > > Hi all, > Let me know if there is any problem with the proposal in this issue > description. > Thanks

Re: DMN with Sonataflow

Tirado Sarti < ftira...@redhat.com> wrote: > Hi, > I agree with the constraints mentioned by Alex. Since the PR is ready to > merge (green and approved), is it enough to have those constraints written > on this list or there is something else to be done? > > On Tue, Apr

Re: [PROPOSAL] Renaming Task and Management consoles images

+1 Assuming that those images are not used by SonataFlow (which seems the case based on the recent proposal for a SonataFlow console). On Wed, Apr 17, 2024 at 4:40 PM Tiago Bento wrote: > > Hi everyone, > > As we approach the Apache KIE 10 release, we're preparing the release > scripts on KIE

Re: DMN with Sonataflow

Although it may look like a simple integration, we should also evaluate the affinity between the technologies, as already pointed out in this thread. There's a general agreement that DMN and SWF are for different target audiences, and—besides being asked by a community member—we don't necessarily

Re: [VOTE] - SonataFlow initial logo

Ricardo, Sorry for being picky, but could you send a voting results email to this ML (something like this [1]) So we can have the results properly recorded directly in the ML. [1] - https://lists.apache.org/thread/ztbqokm59oq0mk00f2wm3k6mytc244ys On Thu, Apr 11, 2024 at 6:13 AM Francisco

Re: [PROPOSAL] Extension mechanism for additional workflow process definitions elements

Glad to hear that! +1 On Tue, Apr 9, 2024 at 6:48 AM Enrique Gonzalez Martinez < egonza...@apache.org> wrote: > It will land after for sure. > > El mar, 9 abr 2024, 12:41, Alex Porcelli escribió: > > > What about any risk of instability? > > > > Looks like

Re: [PROPOSAL] Extension mechanism for additional workflow process definitions elements

gt; > El mar, 9 abr 2024, 12:18, Alex Porcelli escribió: > > > Enrique, > > > > How you see this proposal affecting the 10.0.0 release? > > > > > > On Tue, Apr 9, 2024 at 5:35 AM Francisco Javier Tirado Sarti < > > ftira...@redhat.com> wrote

Re: [PROPOSAL] Extension mechanism for additional workflow process definitions elements

Enrique, How you see this proposal affecting the 10.0.0 release? On Tue, Apr 9, 2024 at 5:35 AM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Hi Enrique, > Thanks for writing down the proposal > +10 ;) > > On Tue, Apr 9, 2024 at 9:50 AM Tibor Zimányi wrote: > > > Hi Enrique, >

Re: [PROPOSAL][VOTE] Sonataflow management console

+1 On Mon, Apr 8, 2024 at 10:55 AM Enrique Gonzalez Martinez wrote: > > +1 > > El lun., 8 abr. 2024 16:33, Paulo Martins escribió: > > > Hello everyone, > > > > I am starting this official vote to accept the Sonataflow management > > console proposal discussed on this list [1], highlighting

Re: Friendly reminder about agreed procedures and communication etiquette

up etiquette on the reference you linked, so I was > assuming you refer to Zulip. > So, whats exactly your proposal for this kind of case? > > > On Fri, Apr 5, 2024 at 4:14 PM Alex Porcelli wrote: > > > Francisco, > > > > Zulip is not an of

Re: Friendly reminder about agreed procedures and communication etiquette

ention the need for a change on jbpm-flow on > Zulip, pinging Enrique. > Of course, if I'm also an interested stakeholder for any change in > jbpm-flow, I expect this to be reciprocal ;) > > > On Fri, Apr 5, 2024 at 4:01 PM Alex Porcelli wrote: > > > Francisco, > >

Re: Friendly reminder about agreed procedures and communication etiquette

Enrique to make sure he was fine with the solution > taken. > Thanks for bringing up the topic. > > > On Fri, Apr 5, 2024 at 2:52 PM Alex Porcelli wrote: > > > I kindly remind everyone of the importance of adhering to our > > established procedures and c

Friendly reminder about agreed procedures and communication etiquette

I kindly remind everyone of the importance of adhering to our established procedures and communication etiquette. These guidelines have been implemented to ensure our community operates efficiently, respectfully, and inclusively. For convenience, here are the links to the relevant information [1]

Community Call

Just a heads up that our community call will start in approximately 45 minutes. This friendly reminder is due to the recent shift to daylight saving time in Europe. How to join the meeting? Here more info [1] [1] - https://github.com/apache/incubator-kie-issues/discussions/906

Re: [PROPOSAL] Sonataflow management console

ó: > > > > > > > > > > > > > Hi Enrique, > > > > > > > > > > > > > > The existing consoles are for jBPM, the one I'm proposing is for > > > > > > serverless > > > > > > > wor

Re: [PROPOSAL] Sonataflow management console

Paulo, Is this a proposal for post or pre 10.0.0? On Tue, Apr 2, 2024 at 10:34 AM Paulo Martins wrote: > > Hello everyone, > > I am proposing we create a new management console for workflows in the > incubator-kie-tools repository. For its first version, it would have the > same features

[RESULT][VOTE] Accept Amended Proposal to unblock Apache KIE 10.0.0 Release

The vote passes [1] with 26 +1s, 26 binding. Thanks to everyone who participated in the discussion and vote. Binding: Tibor Zimányi Yeser Amer Luca Molteni Paolo Bizzarri Enrique Gonzalez Martinez Luiz Motta Pere Fernandez Thiago Lugli Martin Weiler Eder Ignatowicz Ricardo Zanini Fernandes Paulo

Re: [VOTE] Accept Amended Proposal to unblock Apache KIE 10.0.0 Release

at everything is working manually. > > > > On Tue, Mar 19, 2024 at 3:11 PM Alex Porcelli wrote: > > > With all the feedback from the proposal discussion [1], I am starting > > this official vote to accept the amended proposal to unblock Apache > > KIE 10.0.0 Release.

[VOTE] Accept Amended Proposal to unblock Apache KIE 10.0.0 Release

With all the feedback from the proposal discussion [1], I am starting this official vote to accept the amended proposal to unblock Apache KIE 10.0.0 Release. Here [2] is the link for the final amended proposal. Please cast your vote: [ ] +1, accept the proposal [ ] +0, I don't care [ ] -1, do

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

This is the amended version of the proposal. # THE PROPOSAL S1. [Permanent] We keep the original plan of moving the Quarkus Dev UIs from `kogito-apps` to `kie-tools`, together with Management and Task consoles from `kogito-images` to `kie-tools`. S2. [Temporary] We copy the `kogito-swf-devmode`

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

+1 on the proposal adding to it the details needed for the revert changes post 10 +1 to start new thread to discuss anything other than this proposal On Fri, Mar 15, 2024 at 8:25 AM Enrique Gonzalez Martinez < egonza...@apache.org> wrote: > +1 to the short term approach as it seems both parties

[HEADS UP] Tomorrow Community Call Time! (Impacted by USA Daylight savings change)

I'd like to bring to everyone's attention that tomorrow the community call is scheduled for 9am EDT - 1PM GMT - 2pm CET Bellow find the invite information: Alex Porcelli is inviting you to a scheduled Zoom meeting. Topic: KIE Weekly Meeting Time: Mar 15, 2024 09:00 AM Eastern Time (US

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

s all about... You know I don't > > > think > > > > > it's > > > > > > > > > ok. That's why I'm proposing the two images and the > operator > > to > > > > > move > > > > > > > > > into the `kie-tools` repo, where we can more granularly > > control

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

tion 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 wrote: > > > The guestimate of the plan discussed in this

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

Ricardo, Images are not broken because of the circular dependency exists between apps and tools. Once the ui from apps repo is moved to KIE tools, there is no more snapshots being published. Thus the reason I’m concerned about broken CI. Regards, _ Alex Porcelli http://porcelli.me

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

mply copy the code to tools and do the release. I propose to not > start adding contributions from operator/images to tools. > > On Wed, Mar 13, 2024 at 10:41 AM Alex Porcelli wrote: > > > Ricardo, > > > > I think it's more than fair to ask to preserve the original

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

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 wrote: > > > Francisco, > > >

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

ve 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 Porcel

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

y 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 wrote: > > > > > Francisco and G

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

am ;)) agree that tooling should be > executed before images because there is a logical dependency between images > and tooling? > In my opinion, the least we can do is to explore how it really costs to > change CI to execute tooling before images. > > > On Wed, Mar 13, 2024 at 1:

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

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:

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

On the bright side, I’m really happy to see the sudden high interest on CI! Something that we’ve been highlighting the need of hands since we moved to Apache. On Wed, Mar 13, 2024 at 7:29 AM Alex Porcelli wrote: > Francisco, > > Please take the time to make the more in depth analys

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

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

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

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

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

+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

Re: [ANNOUNCEMENT] Removing the circular dependency between `kogito-apps` and `kie-tools`

irectly on the `examples` directory of > `kie-tools`. > (https://github.com/apache/incubator-kie-issues/issues/959) > Unaltered from original plan. > > 11. (Assignee TDB - NOT YET STARTED) Move the `kogito-swf-devmode` > image from `kogito-images` to `kie-tools`. > (https://gi

Re: [ANNOUNCEMENT] Removing the circular dependency between `kogito-apps` and `kie-tools`

Ricardo, Eder and Community Members, We definitely need to have a conversation about how best to deal with our repositories and in general the whole codebase organization. I think it's fair to say that it's not working well. We also consume many times more computing resources that we should and

Re: [ANNOUNCEMENT] Removing the circular dependency between `kogito-apps` and `kie-tools`

leases of Apache KIE. > > >> > > > >> > I hope it is clearer now why we can't have `kogito-images` depending > > >> > on `kie-tools` if `kogito-images` continues to be part of the `drools` > > >> > and `kogito-*` development streams. > > >

Re: [ANNOUNCEMENT] Removing the circular dependency between `kogito-apps` and `kie-tools`

, 2024 at 9:43 AM ricardo zanini fernandes wrote: > > Alex, > > I'm not aware of any dependencies in KIE Tools for images. > > On Wed, Mar 6, 2024 at 9:44 AM Alex Porcelli wrote: > > > Ricardo, > > > > IIRC, there’s a dependency in KIE Tools

Re: [HEADS UP] Renaming Kogito SW artifacts to KIE/SonataFlow starting

tibility taking advantage that we are breaking it > anyway if we rename the packages. > Do you know what Mark is referring to by component project name? > > On Wed, Mar 6, 2024 at 1:29 PM Alex Porcelli wrote: > > > Francisco, > > > > Appreciate your long r

Re: [ANNOUNCEMENT] Removing the circular dependency between `kogito-apps` and `kie-tools`

can grab the latest available > kie-tools version, pack it and ship it. If a new release comes up and we > need the fix, we can of course do a patch release. > > We just need to automate the process. > > Cheers! > > On Wed, Mar 6, 2024 at 9:33 AM Alex Porcelli wrote:

Re: [ANNOUNCEMENT] Removing the circular dependency between `kogito-apps` and `kie-tools`

Dominik, The plans and course of action for removing the circular dependency has been exhaustively discussed in the mailing list and Zulip channel among community and key stakeholders, I don’t think we have room to revisit the decision that has been already agreed. With that being said, I don’t

Re: [HEADS UP] Renaming Kogito SW artifacts to KIE/SonataFlow starting

ted with the package renaming, well, since > we > > are going to break, its the chance to do this kind of movement and > achieve > > a clearer API landscape. > > > > On Wed, Mar 6, 2024 at 2:09 AM Alex Porcelli wrote: > > > > > Team, > > > > > > We

Re: [PROPOSAL] YaRD - Yet Another Rule Definition

ese issues more than others.) > > > > > > > > So I was wondering if such an addition (if/when it happens) would be > run > > > > through voting where we could safe-check the concerns I stated above, > > > > rather than a PR where it's sufficient to g

Re: [HEADS UP] Renaming Kogito SW artifacts to KIE/SonataFlow starting

ricardozan...@gmail.com> wrote: > > > Thanks for this input, Alex!! I really appreciated it! <3 > > > > > > > > On Tue, Feb 27, 2024 at 2:06 PM Tibor Zimányi wrote: > > > > > I am ok either way, if it follows the rules. > > >

[HEADS UP] Hibernate ORM dependency not a blocker for 10.0.0

Dear Apache KIE Dev Community, This topic was raised in last week's community meeting [1], and today, I'm thrilled to share some good news with all of you. We've just received confirmation that using the Hibernate ORM dependency (LGPL, classified as Category-X) will not block the release of

Re: [PROPOSAL] YaRD - Yet Another Rule Definition

xperimental", can I ask what the plans are > > for YaRD? > > I think clarifying this point can help us make the best decision. > > > > > > On 2024/03/04 13:53:07 Alex Porcelli wrote: > > > Toni, > > > > > > As in previous disc

Re: [DISCUSS] version 10.0 documents

Toshiya, We, as a community, still didn't discuss docs and our overall communications strategy - it's clear that we have a lot of work to be done in this space. One thing that seems clear based on recent exchanges with Apache members (infra, brand and legal) is that I don't think

Re: [PROPOSAL] YaRD - Yet Another Rule Definition

Toni, As in previous discussion related to the new Drools parser, my concern is how much this might affect the 10.0.0 release. I personally am not a big fan of YAML, in a recent demo I got in trouble because of 2 spaces :D - but I understand that this might look appealing to k8s audience :) On

Re: new Antlr4 based DRL parser development

ilure evidencing the problem > and of course we will do the replacement only when the entire Drools test > suite will be green also using the new parser. > > I hope this clarifies the situation. > Thanks, > Mario > > On 2024/02/26 13:57:11 Alex Porcelli wrote: > >

Re: [HEADS UP] Renaming Kogito SW artifacts to KIE/SonataFlow starting

+1 for org.apache.sonataflow Craig Russell provided an input early in the branding discussions that it’s not required to use the project suffix [1]. Based on that, I believe the namespace is not only shorter, but we continue to play the strengths of individual modules while keeping the unified

Re: [PROPOSAL] - Whitelisting "add-one-comment" GH Action to enable docs preview

Agreed! On Mon, Feb 26, 2024 at 11:20 AM ricardo zanini fernandes < ricardozan...@gmail.com> wrote: > @Alex Porcelli indeed we will need to > review the docs, but the preview structure will remain I believe. > > On Mon, Feb 26, 2024 at 12:48 PM Dominik Hanak > wrote: >

Re: [PROPOSAL] - Whitelisting "add-one-comment" GH Action to enable docs preview

+1 from me (although I think we'll have to revisit the whole docs shortly after 10) On Mon, Feb 26, 2024 at 9:57 AM ricardo zanini fernandes wrote: > > The correct action name is "maintain-one-comment". > > On Mon, Feb 26, 2024 at 11:55 AM ricardo zanini fernandes < > ricardozan...@gmail.com>

Re: new Antlr4 based DRL parser development

Toshiya, Thank you for the heads up, however I'm a bit concerned how far this implementation has gone without a previous proposal to be discussed as stated in our community communication guidelines [1]. Although I really appreciate the effort to keep up to date with technology advances (ANTLR v4

Re: [DISCUSSION] Performance issues with data-index persistence addon

he properties approach I recommend). > In my opinion, if we have the explicit REST API, we should not use the > cron. > > On Thu, Feb 22, 2024 at 6:32 AM Enrique Gonzalez Martinez < > egonza...@apache.org> wrote: > > > +1 alex > > > > El jue, 22 feb 2024, 0:14, A

Re: [DISCUSSION] Performance issues with data-index persistence addon

ething but I see the cron > approach not reconcilable with the REST approach. > Anyway just a detail, I agree the purge approach should be similar for all > microservices > > On Wed, Feb 21, 2024 at 4:37 PM Alex Porcelli wrote: > > > +1 for provide consistent behavior across the b

Re: [DISCUSSION] Performance issues with data-index persistence addon

did > in > > v7 > > > > > with > > > > > > > the emitters. The only difference between two impl is that in > > here > > > > the > > > > > > > storage is pgsql instead elastic search. You are right >

Re: [DISCUSSION] Performance issues with data-index persistence addon

ata-index is a way to query recently closed and active processes (the > > key > > > here is the definition of recently, which in my opinion should be > > > configurable) > > > But, besides that discussion and being pragmatic, keeping finishing > > process > > >

Re: [DISCUSSION] Performance issues with data-index persistence addon

e: > >> > > > > > > > > >> > > > > > > > > Hi Francisco, > >> > > > > > > > > > >> > > > > > > > > thanks for your work on this impo

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

add the missing ones in the spreadsheet? > > > > > > On Wed, 14 Feb 2024 at 09:25, Pere Fernandez (apache) < > pefer...@apache.org > > > > > wrote: > > > > > +1 to that! > > > > > > On Tue, 13 Feb 2024 at 23:40, Alex Porcell

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

up with more changes later. > > Thx, > Kris > > > On Wed, Feb 7, 2024 at 4:44 PM Alex Porcelli wrote: > > > The following extensions are missing in the spreadsheet: > > > > org.kie:kogito-addons-quarkus-jobs > > org.kie:kogito-addons-data-audit-qua

Re: [PROPOSAL] Drop legacy runtime and KieAssemblerService Drools integration

+1 With the caveat that I expect this will not interfere in the 10.0.0 release that I expect we'll be able to start the release procedures in less than 2 weeks. On Wed, Feb 7, 2024 at 3:58 AM Gabriele Cardosi wrote: > > Hi Enrique, > sorry, from your mail I did not get that your suggestion was

Re: [PROPOSAL] Drop support for DRF in bussines automation domain

+1 for it With the caveat that I expect this will not interfere in the 10.0.0 release that I expect we'll be able to start the release procedures in less than 2 weeks. On Wed, Feb 7, 2024 at 11:33 AM Martin Weiler wrote: > > +1 > > Martin > > > From:

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

as > > created, I added them, but they are following the same reasoning. > > I also incorporated Pere's suggestion on jbpm-quarkus-devui. > > > > Thx, > > Kris > > > > On Tue, Feb 6, 2024 at 4:30 PM Alex Porcelli wrote: > > > >

Re: [PROPOSAL] Archive incubator-kie-kogito-operator

rtinez < > egonza...@apache.org> wrote: > > > +1 > > > > El mar, 6 feb 2024, 15:02, Pere Fernandez > > escribió: > > > > > +1 > > > > > > On Tue, 6 Feb 2024 at 14:56, Yeser Amer wrote: > > > > > > > +1 &

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

), if we want to do the distinction > into > > > > > > libraries > > > > > > > > that are added to a microservice as addon (infra) and > > microservices > > > > > > that > > > > > > > > are not mandatory

Re: [PROPOSAL] Archive incubator-kie-kogito-operator

t; > On Tue, Jan 30, 2024 at 3:43 AM Pere Fernandez (apache) > wrote: > > > +1 > > > > El dl., 29 de gen. 2024, 17:03, Alex Porcelli va > > escriure: > > > > > Thank you, Ricardo. Looking forward to your assessment. > > > > &g

Re: [DISCUSS] Community Meeting Recordings

Link for the recording is part of the meetings already published [1]. +1 to move to YouTube [1] - https://github.com/apache/incubator-kie-issues/discussions/905 On Fri, Feb 2, 2024 at 11:59 AM Jason Porter wrote: > I was not able to attend the meeting earlier today, but I understand it > was

Re: Community Weekly meetings

Today's meeting minutes is already published in GitHub Discussions [1]. [1] - https://github.com/apache/incubator-kie-issues/discussions/905 On Fri, Feb 2, 2024 at 8:04 AM Alex Porcelli wrote: > > Here is the invitation for today's meeting using a Pro account: > > Alex Porcelli is

Re: Enable GitHub Discussions for Community Meeting Notes

+1 for apache/incubator-kie-issues On Fri, Feb 2, 2024 at 9:20 AM Eduardo Cerqueira < eduardocerque...@apache.org> wrote: > +1 to use apache/incubator-kie-issues for Meeting notes! > > Thank you Ricardo for the presentation! > > On 2024/02/02 13:41:01 Alex Porcelli wrot

Enable GitHub Discussions for Community Meeting Notes

Is everyone ok with the idea to use, as suggested by Ricardo [1], to enable GitHub Discussions in the incubator-kie-website repository? Please feel free to also suggest what other repository would be a better fit to host the GitHub Discussions for meeting minutes. [1] -

Re: Community Weekly meetings

Here is the invitation for today's meeting using a Pro account: Alex Porcelli is inviting you to a scheduled Zoom meeting. Topic: KIE Weekly Meeting Time: Feb 2, 2024 09:00 AM Eastern Time (US and Canada) Every week on Fri, until May 31, 2024, 18 occurrence(s) Feb 2, 2024 09:00

Re: Community Weekly meetings

> > > > On 2024/01/30 17:42:50 Jan Šťastný wrote: > > > > Hello, > > > > Doesn't Zulip provide a video call option? I've seen also jitsi > > reference > > > > in there.. > > > > But not sure about tech aspects. > > > > > &g

Re: Community Weekly meetings

> > But not sure about tech aspects. > > > > Regards > > Jan > > > > Dne út 30. 1. 2024 15:02 uživatel Alex Porcelli > napsal: > > > > > Sounds like a good idea, Ricardo! > > > > > > On Tue, Jan 30, 2024 at 8:40 AM ricardo zanini

Re: Community Weekly meetings

024 at 10:35 AM Tibor Zimányi wrote: > > > Thanks Alex for clarification, +1 for Zoom from me then. > > > > Tibir > > > > Dňa ut 30. 1. 2024, 14:05 Alex Porcelli napísal(a): > > > > > I agree that it is less than ideal to have anything bound to a personal

Re: Community Weekly meetings

t it might require a Google account to join, so not ideal. Regards, _ Alex Porcelli http://porcelli.me On Tue, Jan 30, 2024 at 2:45 AM Dominik Hanak wrote: > > Hi, > > imho we should avoid binding the meeting to one person, this will create > problems in the future

Re: What's the status of the Project website?

have for any code > contribution. Send a PR and have 2 reviews from comitters. > > Of course, this should be voted on, but I would like to hear other > opinions. > > Dominik > > > [1] https://infra.apache.org/project-blogs > > > > On Mon, 29 Jan 2024 at 21:56, Al

Community Weekly meetings

I'd like to propose to use for the weekly meetings something outside the corporate infrastructure. My suggestion is to start with the free Zoom - which is limited to 40 minutes. The downside is that it's associated with a personal account, so if the host is not able to attend, we won't be able to

Re: What's the status of the Project website?

We have a placeholder website already alive: https://kie.apache.org/ - the source code is available here [1] [1] - https://github.com/apache/incubator-kie-website On Mon, Jan 29, 2024 at 12:23 PM Alex Porcelli wrote: > > For tracking purposes: https://issues.apache.org/jira/browse/INFRA

Re: What's the status of the Project website?

For tracking purposes: https://issues.apache.org/jira/browse/INFRA-25438 On Sat, Jan 27, 2024 at 8:33 AM Paolo Bizzarri wrote: > > Hi Alex, > > that is great! > > Let me know if you need help on completing the website. > > Regards > > Paolo > > On Fri, Ja

Re: [HEADS UP] Legal issue with Oracle driver

Good point, Brian! Just did [1]. [1] - https://lists.apache.org/thread/nbj94o1bl5c39j04fydhh2f8z280m79j On Mon, Jan 29, 2024 at 8:47 AM Brian Proffitt wrote: > > Did you reach out to the Spark people to see how they had included this? > > BKP > > On 2024/01/11 22:16:37 A

  1   2   >