I'm strongly in favor of moving ahead with the work on the persistence layer and improving the plugin experience/ integration with Quarkus. I think we've really highlighted the importance lately of improving the first time user experience with the product and the ability to run Polaris in isolation from a managed service. If you can't do that easily with scalable backends, then we have a problem. We've definitely left those edges a little sharp and It would be great to move towards a setup that anyone can use right out of the box.
I'm excited to see some proposals for any places we can make Polaris a better first choice for our users. Of course, I also want to make sure that being OSS is just one of the reasons to choose Polaris and we also have wide support for all the functionality our users expect. I'm glad we can work together to reach those goals. I know I've been spending a bunch of time recently on some higher level proposals that are feature before ease of use but I'm going to personally devote more of my review time to Polaris as soon as we finish up a bit of that Iceberg V3 work 🙂 On Mon, Dec 9, 2024 at 8:27 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Agree, that was argument one, the second argument is that we need to > move forward on cool features in the meantime ;) > > On Mon, Dec 9, 2024 at 3:10 PM Robert Stupp <sn...@snazy.de> wrote: > > > > 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 > > >
