+1 on "1.0-blocker" for both 1889 + 1890
On 13.06.25 04:24, Dmitri Bourlatchkov wrote:
As discussed in the community sync today, I opened PR [1890] to inform
users about what to expect in terms of backward compatibility as the
project evolves.
I proactively marked it as 1.0 blocker because I'm not sure whether docs
have to be merged before the release in order to be reflected in the
appropriate release section of the Polaris website. If 1.0 docs can be
adjusted after the release, I suppose this PR does not have to be a blocker.
Comments and suggestions are welcome.
[1890] https://github.com/apache/polaris/pull/1890
Thanks,
Dmitri.
On Thu, Jun 12, 2025 at 8:15 PM Dmitri Bourlatchkov <di...@apache.org>
wrote:
I've marked [1889] as a 1.0 blocker. Feel free to disagree :) My rationale:
Polaris 1.0 is a binary release and will provide a platform for users to
experiment with Generic Tables. It is important to set correct expectations
about this feature in terms of functional scope, level of maturity, plans
for evolution.... which is what the PR hopefully provides (I did not review
yet :) )
[1889] https://github.com/apache/polaris/pull/1889
Cheers,
Dmitri.
On Thu, Jun 12, 2025 at 7:17 AM Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:
Hi folks
Back from the other part of the pond :)
I think we should have a clear consensus about
1.0 content. That’s why I invite everyone to flag issues and PRs with the
1.0-blocker label.
I propose to do a review in 24h. As soon as we don’t have any 1.0-blocker,
we are good to start rc.
We can also chat about that during the community meeting today.
If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass on the
main branch mainly about license/notice etc).
Thanks !
Regards
JB
Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a écrit :
Agree with Dmitri.
Having clear discussion subjects is crucial for the community to follow
the right threads. I think we should only get to consensus about the
particular thread topic and nothing else.
Consensus in a community in general, at least in my opinion, is more
than two people having the same opinion.
We should also be careful about giving everybody enough time, and
consider weekends and potentially public regional holidays.
Regarding the technical actions: The branch name doesn't comply with the
existing naming convention (the branch naming pattern that JB used),
which is also required to later support semi-automatic releases
(discussed a couple months ago during a community sync call).
Considering that we do not seem to have a consensus on the content of
the 1.0 release, there are still 1.0-blockers and the wrong branch name,
I strongly prefer do delete that branch.
Regarding the release manager, I'm in favor of letting JB drive the
release process to ensure that things go smooth.
Related note: We already have quite a bunch of branches in the GH repo
whose meaning is not clear to me.
Robert
On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
Also the
last PPMC member's agreement on thread[1] happened 5 days ago, which
passed
the lazy consensus window. But I agreed it's nice to conclude a
thread.
The consensus in that thread was to skip the 0.10.0 release.
From my POV an agreement to skip 0.10.0 does not mean that the scope
for
1.0 is set and agreed upon.
What I'm asking for is proactively engaging with the community before
executing technical actions for a new release as opposed to informing
after
actions are taken.
[1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
Thanks,
Dmitri.
On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <flyrain...@gmail.com>
wrote:
The branch name is "1.0.x".
Where is this agreement recorded?
Discussed multiple times with JB last Thursday(6/5/2025) and this
Monday(6/9/2025), we agreed to consider it as a nice-to-have instead
of
a
blocker.
As a matter of best practice, given the previous related discussion
thread
[1], it would have been nice to conclude it with a message about
starting
the 1.0 release process before actually cutting the branch.
We got consensus on thread[1]. The 1.0 release was also prepared way
before
the thread. We will kick off 1.0 release even if 0.10 is not
canceled.
JB
and I discussed the parallel releasing option for both versions. Also
the
last PPMC member's agreement on thread[1] happened 5 days ago, which
passed
the lazy consensus window. But I agreed it's nice to conclude a
thread.
[1] https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
Yufei
On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <
di...@apache.org>
wrote:
I cut the 1.0.x branch yesterday morning.
As a matter of best practice, given the previous related discussion
thread
[1], it would have been nice to conclude it with a message about
starting
the 1.0 release process before actually cutting the branch.
[1]
https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
Thanks,
Dmitri.
On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <flyrain...@gmail.com>
wrote:
Thanks everyone for the contribution. We've finally resolved all
blockers[1]. I cut the 1.0.x branch yesterday morning. Will only
cherry
pick bug fixes and license related commits to this branch starting
now.
[1]. PR1695 is labeled with 1.0 blocker, but we agreed that it's a
best-to-have instead of a blocker per offline discussion,
https://github.com/apache/polaris/pull/1695.
Yufei
On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
eric.w.mayn...@gmail.com
wrote:
+1 to making 801 a blocker.
Based on Alex's comments in 1799, it looks like the rotation is
only
happening in JdbcMetastoreManagerFactory? If so, I think we have a
very
simple fix in PR#1804 <
https://github.com/apache/polaris/pull/1804>.
--EM
--
Robert Stupp
@snazy
--
Robert Stupp
@snazy
