All in for good functionality!
I think, you wanted to express that overall Polaris must really be "rock
solid" (secure, stable, performant) - aka: it would "just" be annoying,
if a certain functionality/feature isn't working properly. But it would
be a hard no-go if the system isn't stable, or even worse insecure. Correct?
In other words: no feature/change must go in at the cost of security
and/or stability of Apache Polaris.
On 09.12.24 14:10, Jean-Baptiste Onofré wrote:
Hi folks,
Sorry to have been almost quiet last week, I was travelling.
Following some discussion threads we got on the mailing list, I
propose to populate a public roadmap using the following process:
- we create GH Issues with the "proposal" tag
- we can attach a document to this GH issue (and eventually a draft PR)
- we send a message on the dev mailing with [PROPOSAL] subject
- we publish this
I would also like to emphasize we should focus on key features for
Polaris. If it's good to have "technical" discussions, and it's worth
it to spend effort on that, these discussions should be at the service
to a bigger picture: what will be the key features expected by users
and answering Polaris expectations.
Our focus should be Polaris features, to make "progress" on the project.
For instance, TMS, Delta support (reading/converting), persistence,
RBAC, federated catalogs, integration (with OpenLineage, etc), S3
Tables support,... are what make Polaris and the future of Polaris.
The technical discussions (enhanced runtime/Quarkus, persistence
layer, ...) should be at the service of the features. Don't get me
wrong: these are important discussions, however, personally, I'm ready
to make concession here in favor of moving forward faster on the
"features". I have the feeling we are spending a lot of time and
effort on this instead of focusing on the Polaris features.
Thoughts ?
Regards
JB
--
Robert Stupp
@snazy
