Re: the server module rename [1695]: I see that the 1.0 blocker label was removed from it. I'm personally ok with not including it in 1.0.0.
However, I'd prefer to include it if other people find it valuable too. My rationale: * The new module names are more natural and probably more intuitive to users and potential contributors. * The module names make their way to Maven repositories so any rename after the first binary release will be a burden (even if we do it in 2.0) both to Polaris and to downstream projects. The downside for including it now seems small: 1) re-applying the rename to the latest main (hopefully not difficult as there are no functional changes) 2) minor risk of breaking scripts or docker images. Note that this will hold even if we do the renaming later. I do not think this rename is going to slow the release process down considerably. The base release timeline has not been short in Polaris to begin with. [1695] https://github.com/apache/polaris/pull/1695 Cheers, Dmitri. On Thu, Jun 12, 2025 at 11:58 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Not sure I follow you (maybe you didn't reply to my message specifically > :)). > > My proposal was just to call for 1.0 consensus. Are we good in what > should be included ? > > About #1695, if no consensus, I'm fine to remove the 1.0-blocker label > here (it was best effort, and can be done later). > > Regards > JB > > On Thu, Jun 12, 2025 at 5:48 PM Yufei Gu <flyrain...@gmail.com> wrote: > > > > We didn't do that for 0.9 and 0.10 releases before cutting a branch. If > you > > think that's a new process we need to follow, please open a new dev ML > > thread for discussion. > > > > the wrong branch name > > > > > > Can you explain why there is a wrong branch name? > > > > Where is this agreement recorded? > > > > Where is the agreement record of adding [1] as a 1.0 blocker? Can you > open > > a thread for that if there is not? It seems controversial now. > > > > [1] https://github.com/apache/polaris/pull/1695. > > > > Yufei > > > > > > On Thu, Jun 12, 2025 at 4:21 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 > > > > > > > > > > > >
