Hi Yufei, More broadly, I believe an effective and efficient open-source community should have more trust, less bureaucracy. We should try to minimize unnecessary processes. And as you’ve seen, by requiring consensus to remove a blocker, it logically follows that adding one should also require consensus.
The issues (PRs technically) I raised as 1.0 blockers are not about lack of trust. Those issues are about informing users of important aspects of the features released in 1.0 (the generic tables doc) and about what to expect from follow-up releases (the "evolution" doc). I'll restate my rationale for them here. * The generic tables API is a new API in Polaris. Previously it was documented only in YAML comments. I believe this is not visible enough for end users and not easy to read for non-technical users. Adding the Generic Table doc page addresses both of these concerns, IMHO. * 1.0 being the first binary release will invariably have users wondering about what they can rely on and what needs more careful consideration if they install 1.0, but will want to upgrade to the next release. The "evolution" doc attempts to clarify that. I accept constructive critique on the contents of that page, but I do believe having it in 1.0 is critical to properly set users' expectations. Regarding "unnecessary processes", I do believe we're following the normal release discussion process as far as the above PRs are concerned. I marked them as 1.0 blockers because I believe the points I mentioned above make them critical to address before the release. This is subject to discussion, of course. However, so far I see only a small number of opinions have been expressed. Essentially, these blocker labels are there only to ensure the matter is reviewed with due diligence. Cheers, Dmitri. On Sat, Jun 14, 2025 at 8:43 PM Yufei Gu <flyrain...@gmail.com> wrote: > > > > My opinion is that the issues are critical, even though we do not have an > > agreement on the "fixes" for those issues, yet. > > Thanks for sharing, but I respectfully disagree. This isn’t just about the > “fixes”, the blocker label is meant to reflect the urgency and criticality > of an issue, and in this case, we don’t have consensus on that. Marking > these as blockers without agreement feels premature, especially when you're > suggesting that removing a blocker requires consensus, but adding one does > not. > > More broadly, I believe an effective and efficient open-source community > should have more trust, less bureaucracy. We should try to minimize > unnecessary processes. And as you’ve seen, by requiring consensus to remove > a blocker, it logically follows that adding one should also require > consensus. > > I want to say it again that the 1.0 release is critical to unblocks users' > adoptions. It gives users a stable target for real integration. We should > try to do that sooner rather than later. Neither PR 1889 nor 1890 > introduces a functional issue that would block users from adopting 1.0. > Risks of missing them is low, but on-time releasing provides high value, > esp. for the long term of the project. An OSS project without adoption will > lose momentum and become irrelevant. > > Yufei > > On Fri, Jun 13, 2025 at 2:58 PM Dmitri Bourlatchkov <di...@apache.org> > wrote: > > > I'm OK with the consensus process. Can you explain why introducing a > > blocker doesn't need consensus? > > > > > > This is to have a community-wide acknowledgement whether the _issues_ > > represented by those PRs are not critical for 1.0. > > > > My opinion is that the issues are critical, even though we do not have an > > agreement on the "fixes" for those issues, yet. > > > > Cheers, > > Dmitri. > > > > On Fri, Jun 13, 2025 at 3:45 PM Yufei Gu <flyrain...@gmail.com> wrote: > > > > > Thanks for raising this, but I disagree on three fronts: > > > > > > - Neither 1889[1] nor 1890[2] introduces a functional gap that would > > > prevent users from adopting 1.0. They document best-practice > guidance > > we > > > can safely refine post-GA. Holding the release hostage to docs or > > policy > > > wording sets an impossibly high bar and delays useful features. > > > - The incremental risk of shipping without these PRs is low: we’re > not > > > breaking contracts or data. By contrast, the value of shipping 1.0 > on > > > schedule—unblocking downstream integrations and giving users a clear > > > target—is very high. > > > - We’ve historically treated “blocker” as a last resort for > > regressions > > > or hard compatibility breaks. Expanding that scope to unresolved > > > wording or > > > scope debates dilutes the label. Unless someone surfaces a concrete > > > technical regression linked to these PRs, the blocker tag should be > > > removed. > > > > > > I'd say removing the blocker label from them itself needs consensus. > > > > > > I'm OK with the consensus process. Can you explain why introducing a > > > blocker doesn't need consensus? > > > > > > 1. https://github.com/apache/polaris/pull/1889 > > > 2. https://github.com/apache/polaris/pull/1890 > > > > > > Yufei > > > > > > > > > On Fri, Jun 13, 2025 at 12:14 PM Dmitri Bourlatchkov <di...@apache.org > > > > > wrote: > > > > > > > Hi Yufei, > > > > > > > > I agree that we do not have consensus on the _contents_ of PRs 1889 > and > > > > 1890. > > > > > > > > However, I believe the issues these PRs attempt to address are still > > 1.0 > > > > blockers in my opinion (arguments for that given in previous emails). > > > > > > > > I'd say removing the blocker label from them itself needs consensus. > > > > Thoughts on this aspect are welcome from everyone. > > > > > > > > Thanks, > > > > Dmitri. > > > > > > > > On Fri, Jun 13, 2025 at 1:05 PM Yufei Gu <flyrain...@gmail.com> > wrote: > > > > > > > > > Hi Dmitri, > > > > > > > > > > We don't have a consensus on adding these two PRs as 1.0 blocker. > Can > > > you > > > > > please drop the label? Let's discuss it first. I don't think they > are > > > 1.0 > > > > > blockers, but open to suggestions. > > > > > > > > > > 1. https://github.com/apache/polaris/pull/1889 > > > > > 2. https://github.com/apache/polaris/pull/1890 > > > > > > > > > > Yufei > > > > > > > > > > > > > > > On Fri, Jun 13, 2025 at 9:50 AM Yufei Gu <flyrain...@gmail.com> > > wrote: > > > > > > > > > > > Dimiri, > > > > > > > > > > > > Thanks a lot for driving this initiative[1]. Can you raise a > > > separate > > > > > dev > > > > > > mail thread for this? I think this deserves a broad awareness. > > > > > > > > > > > > 1. https://github.com/apache/polaris/pull/1890 > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > On Fri, Jun 13, 2025 at 4:53 AM Robert Stupp <sn...@snazy.de> > > wrote: > > > > > > > > > > > >> I was thinking of how the Docker images are being staged and > > > > eventually > > > > > >> released. I know there was a dev-ML thread about this, but I > think > > > > this > > > > > >> topic is important for the 1.0 release, so raising it here. > > > > > >> > > > > > >> The release-guide doesn't mention images at all, so the process > > > isn't > > > > > >> clear. > > > > > >> > > > > > >> TL;DR of my reasoning is that we likely need 3 (!) repositories > > for > > > > both > > > > > >> the server and admin-tool: > > > > > >> * one for nightlies > > > > > >> * one for staging (before release-vote passes) > > > > > >> * one for released versions > > > > > >> > > > > > >> Due to the nature and restrictions of image repositories (no > > notion > > > of > > > > > >> "snapshots") we cannot push "pending releases" to the 3rd one, > > > because > > > > > >> tools like renovate of dependabot would blindly use those (same > > > > problem > > > > > >> as nightlies vs releases). > > > > > >> > > > > > >> Thoughts? > > > > > >> > > > > > >> On 16.05.25 04:31, Jean-Baptiste Onofré wrote: > > > > > >> > Hi Yufei > > > > > >> > > > > > > >> > Thanks for your message ! > > > > > >> > > > > > > >> > It looks good to me. > > > > > >> > > > > > > >> > As prerequisite (obviously), we should also complete > > > > > >> > 0.10.0-beta-incubating release to be sure we are good there > > before > > > > > >> > 1.0.0. > > > > > >> > > > > > > >> > Just a comment: I think we should limit the number of > community > > > > > >> > meetings. This topic should be typically discussed on the > > mailing > > > > list > > > > > >> > (as you are doing :)). > > > > > >> > The reasons why I'm not big fan of too much meeetings are: > > > > > >> > 1. No everyone in the community can join (due to timezone, not > > > > willing > > > > > >> > to speak/appear on call, ...) > > > > > >> > 2. It puts "pressure" on the community to attend ("if I'm not > in > > > the > > > > > >> > meeting, I'm not in the community" issue) > > > > > >> > 3. Due to 1 & 2, no decision should be taken in meetings, and > > even > > > > if > > > > > >> > meetings are recorded, it's not archive as mailing list > > > > > >> > So, I encourage meetings as community meet&greed, or to > discuss > > > > about > > > > > >> > specific topics, not decision making topic. > > > > > >> > > > > > > >> > Thanks, > > > > > >> > Regards > > > > > >> > JB > > > > > >> > > > > > > >> > > > > > > >> > On Thu, May 15, 2025 at 11:38 PM Yufei Gu < > flyrain...@gmail.com > > > > > > > > wrote: > > > > > >> >> Hi folks, > > > > > >> >> > > > > > >> >> Many users have been asking about the Polaris release, and I > > > > believe > > > > > >> it's > > > > > >> >> critical to have a formal, production-ready 1.0 release ASAP. > > > > Thanks > > > > > >> to the > > > > > >> >> community’s hard work, we’re very close with a few remaining > > > > blockers > > > > > >> we > > > > > >> >> need to resolve. > > > > > >> >> > > > > > >> >> To keep things moving, I scheduled a community meeting for > the > > > 1.0 > > > > > >> release > > > > > >> >> next Monday at 9 AM PST. At the same time, sharing all > issues > > > > marked > > > > > >> with > > > > > >> >> 1.0 blocker. We could resolve them here if possible. Feel > free > > to > > > > > >> chime in, > > > > > >> >> remove the blocker tag if you think it's not a blocker, or > pick > > > any > > > > > up. > > > > > >> >> Thanks a lot in advance! > > > > > >> >> > > > > > >> >> Here is the list: > > > > > >> >> > > > > > >> >> - Add CI for Python code ( > > > > > >> >> <https://github.com/apache/polaris/issues/1058 > >#1058), > > > > > >> >> - Polaris persistence concurrency issues (#777) > > > > > >> >> <https://github.com/apache/polaris/issues/777> > > > > > >> >> - Task handling is incomplete (#774) > > > > > >> >> <https://github.com/apache/polaris/issues/774> > > > > > >> >> - Generated files in regtests/client/python/polaris > > (#755) > > > > > >> >> <https://github.com/apache/polaris/issues/755> > > > > > >> >> - Resources not properly closed, resource & memory > leaks > > > > > (#563) > > > > > >> >> <https://github.com/apache/polaris/issues/563> > > > > > >> >> - Make Polaris safe against certain unparseable > > locations > > > > > (#552) > > > > > >> >> <https://github.com/apache/polaris/issues/552> > > > > > >> >> - [BUG] Assumption that cache eviction does not happen > > > > (#544) > > > > > >> >> <https://github.com/apache/polaris/issues/544> > > > > > >> >> > > > > > >> >> To make it more interactive, you can also comment on the > google > > > > > >> >> spreadsheet here: > > > > > >> >> > > > > > >> > > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1GyLvp2cdYwioOsBwszNWiphZt_IIdo4LIfsZBFV88mc/edit?usp=sharing > > > > > >> >> > > > > > >> >> Yufei > > > > > >> > > > > > >> -- > > > > > >> Robert Stupp > > > > > >> @snazy > > > > > >> > > > > > >> > > > > > > > > > > > > > > >
