I don't really have any skin in the game as far as which components stay vs
which go, however, I want to make sure we're not alienating the community. I
see this as a great opportunity for the wider community to step up. I wouldn't
want to simply trash the work that was done. That sends the
Hi Mario,
some thoughts inline
El mar, 19 dic 2023 a las 10:25, Mario Fusco () escribió:
>
> > drools has `drools-reliability` component which persistence is pluggable.
> > We have infinispan persistence and h2 persistence at the moment. If we want
> > to make the version 10 release "minimal",
Here's my take on removing images we might not support anymore:
https://github.com/apache/incubator-kie-kogito-images/pull/1726
I've stripped 10 images, we have "only" 14 running in the CI:
Infinispan and filesystem persistence on runtimes, I think we all agree
these should be goners.
On Thu, Dec 21, 2023 at 5:56 PM Alex Porcelli wrote:
> Looks like we have a diverse perspective on the possible deprecation list.
>
> Wondering if we could try to find common sense on components that
Looks like we have a diverse perspective on the possible deprecation list.
Wondering if we could try to find common sense on components that we
all would easily agree to start with. A good candidates list are the
images and maybe the Infinispan as persistence for workflow. Thoughts?
Another
> drools has `drools-reliability` component which persistence is pluggable.
> We have infinispan persistence and h2 persistence at the moment. If we want
> to make the version 10 release "minimal", shall we keep only the h2
> persistence and then move the infinispan persistence to another repo
>
+1
On Tue, Dec 19, 2023 at 11:38 AM Tibor Zimányi wrote:
> Hi,
>
> I think it is hard to compare with Spring Boot, because Spring is the most
> used framework with much bigger market share than Quarkus. The focus on
> Quarkus from the past (before KIE in Apache) was driven by internal company
>
Hi,
I think it is hard to compare with Spring Boot, because Spring is the most
used framework with much bigger market share than Quarkus. The focus on
Quarkus from the past (before KIE in Apache) was driven by internal company
decisions, not market share. But this is getting a bit off topic,
Ricardo, for images I fully agree we should only include postgresql stuff.
I think we need to separate the image content from the repo content.
We can even select what we want to test in our CI, through maven profiles.
What I want to avoid, given the changing priorities, is to remove some
stuff
Enrique, MongoDB data index persistence add-on is not a tech experiment, it
is the technology that is used by one of the most active users in the Zulip
community.
Therefore, Mongo satisfies all the requirements you mention to stay, except
being one of our primary company goals.
Mongo per se is not
drools has `drools-reliability` component which persistence is pluggable.
We have infinispan persistence and h2 persistence at the moment. If we want
to make the version 10 release "minimal", shall we keep only the h2
persistence and then move the infinispan persistence to another repo
(kiegroup)?
I think keeping a few addons in a "sandbox" shows the right message to the
community and we can even have a governance model that updates the state of
such components. We can even keep them in the same repository, in a
"sandbox" profile so we won't add too much maintenance effort. From the
image's
Answering in line:
El lun, 18 dic 2023 a las 16:04, Francisco Javier Tirado Sarti
() escribió:
>
> As mentioned before, currently I'm working at DataIndex persistence to
> increase performance (avoiding a lot of updates when using Postgresql).
> This requires changes in the interface used between
As mentioned before, currently I'm working at DataIndex persistence to
increase performance (avoiding a lot of updates when using Postgresql).
This requires changes in the interface used between indexing and storage,
and it affects MongoDB, Infinispan and Oracle implementations, not only
Postgres.
Also, adding to the last bits, it was mentioned to move that code somewhere
else so we can let the community or other active members interested in it
to keep working on them but at different pace.
This way we have some sort of incubator within the project so those
projects are not added
Francisco,
This discussion should provide enough heads-up, and community members
should be able to engage in this ML to express their concerns.
But as I wrote before, this is not about the user's perspective, it's
about active development and focus.
So far in this thread there's some push back
Alex, we know the team one of the most active community contributors on
Zulip ( Debabrata Patnaik) is using MongoDB for their product.
So removing that without a previous warning will not be welcomed.
On Mon, Dec 18, 2023 at 2:31 PM Alex Porcelli wrote:
> The question is not about usage, but
Playing advocate devil now, from a community point of view, I do not see
which extra merits deserves postgresql data index storage implementation
over MongoDB one (again, from a community point of view)
Following with data index case, I would remove Infinispan and keep just one
generic JDBC
The question is not about usage, but the effort to keep components
that haven't been actively maintained.
The components suggested (including MongoDB) haven’t been actively
developed and keeping those for the 10 release might send the wrong message
regarding continued investment and focus.
Maybe
My 2 cents:
I think we should keep MongoDB implementation.
As far as I remember from Zulip, there are quite some people using it.
Others are less important.
On Mon, Dec 18, 2023 at 12:38 PM Tibor Zimányi wrote:
> Hi everyone,
>
> I was about to write something similar as Enrique. There are two
Hi everyone,
I was about to write something similar as Enrique. There are two aspects
now:
- What should we release as part of 10?
- What should be part of the release in the future?
I agree, it might be better to start with a minimal set in 10 to reduce the
maintenance costs and then we could
I do agree in removing or at least setting aside those componentes that are
not our primary focus.
As Alex suggested this increases the overhead and we don' t really have
many hands for now.
I would say that if we don't agree in remove them, at least move those to
another repo outside the apache
There’s no proposal yet, this is just a discussion… it’s expected that a
proposal will emerge from here.
The discussion is an invite to revisit the complex matrix of dependencies +
any codebase that hasn’t been much maintained that could be cleaned up.
Now to be more specific to persistence,
Got it, thank you Eder!
On 2023/12/18 11:00:02 Eder Ignatowicz wrote:
> We extensively use Dashbuilder on Serveless Dev UI.
>
> If there is any vulnerability it needs to be addressed like other
> components.
>
> On Mon, Dec 18, 2023 at 5:01 AM Yeser Amer wrote:
>
> > I have a question about
About images, we do not need to include all projects in the repo into an
image, we can use profiles. My point is that we can still have a
persistence implementation of data index on mysql (we do not have any at
the moment) and do not necessarily pay the cost of having it into the
repository in
We extensively use Dashbuilder on Serveless Dev UI.
If there is any vulnerability it needs to be addressed like other
components.
On Mon, Dec 18, 2023 at 5:01 AM Yeser Amer wrote:
> I have a question about one component related to kie-tools repo,
> Dashbuilder. It seems to me that the module
But in order to be more precise about what we are discussing, I guess the
proposal (at least part of it) is to keep only one implementation of
persistence for data index, the postgresql one. Is my understanding correct?
Or keep Oracle and Postgresql and remove Infinipan and MongoDB?
On Mon, Dec
I think my point is that value is not that marginal
On Mon, Dec 18, 2023 at 11:53 AM Alex Porcelli wrote:
> Francisco,
>
> The question is not about the potential value those components provide…
> it’s about the cost associated to maintain those for the marginal value
> they provide.
>
>
Francisco,
The question is not about the potential value those components provide…
it’s about the cost associated to maintain those for the marginal value
they provide.
There’s a ripple effect for every component we carry over, adding a complex
matrix of additional resources to be managed like
Anyway, I'm currently refactoring data index persistence, including changes
in Storage interface (shared with trusty), so maybe we should table the
discussion after that PR is done. Although removing infinispan and MongoDB
will save me substantial work, I truly believe keeping them adds value to
I think having "secondary" addons that illustrate platform extension
capabilities beyond the one we are prioritizing: postgresql is a great
value.
Therefore I vote for keeping them, except maybe Infinispan.
On Sun, Dec 17, 2023 at 6:49 PM Alex Porcelli wrote:
> As we gear up for the
I have a question about one component related to kie-tools repo, Dashbuilder.
It seems to me that the module is currently not manned by our community, it is
affected by several vulnerabilities and it depends on old dependency versions
(eg. GWT 2.9). It could be potentially a problem when we
32 matches
Mail list logo
