Thanks for the comprehensive response. As far as I can tell, the only point that is blocking this release is the fact that ASF Infra has not reviewed the workflow. Here is a recap of my understanding from the last e-mails.
- As per [1], releases do not *have* to be built on hardware owned and controlled by the committer. But they must be verified on hardware owned and controlled by the committer. We are compliant with this requirement as we use the verification scripts to rebuild Polaris locally and ensure that the build is reproducible. - Our current build process matches the definition of a reproducible build, even though it is not yet bit-by-bit reproducible - CI (Github workflows) do deploy the artifacts to a staging environment (dist dev and a staging Maven repository) - We have created and used a script that rebuilds Polaris locally and verifies that the release is as identical as the current checks allows (with known exceptions) Which means that we comply with the requirements from [2]. So really the only thing we missed is to get the workflows reviewed by ASF Infra. And until this is done, we should revert to manual releases. Am I understanding correctly? If so, I will send a [CANCEL] e-mail. [1] https://www.apache.org/legal/release-policy.html#owned-controlled-hardware [2] https://infra.apache.org/release-signing.html#automated-release-signing -- Pierre On Wed, Dec 10, 2025 at 1:23 PM Jarek Potiuk <[email protected]> wrote: > > I can point you to the `How to verify a release` section on our release > guide page [1] > > Oh fantastic - that's what I was looking for - and will use it for the next > rc :). Thanks for that. Small suggestion - if you could include link to > that in the VOTE mail, that would help a lot - also people voting could > just say "I run all the checks described in the release check page." - > that would also help people like me who comes from "outside" and want to > check if everything is fine (and with my +1 power being part of incubator > help with the release). > > > If we need review from ASF infra, please let me know so that we can > include this step in our development process. > > I think only initial review of the process is needed as you ask for the > release key via JIRA ticket. They just want to be sure that the process is > sound (from my quick review - it is) and that reproducibility check (but > not necessarily bit-by-bit - see below) is there. > > > Regarding reproducible builds, it is a very good point. Currently, > Polaris does not meet the reproducible builds property. > > Which is not needed. Bit-by-bit reproducibility is really helpful to make > the checks easier ("diff a.jar b.jar => success") - but there are other > ways to check reproducibility - scripts (checked in your repository) > comparing artifacts minus "known differences" are perfectly fine to pass > the reproducibility checks (as long as there are no binary / generated > pieces you can't compare even with "known, explainable differences"). The > key here is that the checks are done by at least 3 individual PPMC members > on their machines, with their environment they control, this is really what > the policy [2] says: > > >> Must releases be built on hardware owned and controlled by the > committer? > >> Strictly speaking, releases must be verified on hardware owned and > controlled by the committer. That means hardware the committer has physical > possession and control of and exclusively full administrative/superuser > access to. That's because only such hardware is qualified to hold a PGP > private key, and the release should be verified on the machine the private > key lives on or on a machine as trusted as that. > >> Practically speaking, when a release consists of anything beyond an > archive (e.g., tarball or zip file) of a source control tag, the only > practical way to validate that archive is to build it locally; manually > inspecting generated files (especially binary files) is not feasible. So, > basically, "Yes". > > I am actually amazed how well this piece of the policy was written years > ago - standing the pass of time. It does not tell you that you have to have > your personal private key on your machine and that you have to sign it > there. It just tells you that you should be able to VERIFY the signature > (while verifying that what you are verifying **actually** comes from the > sources in the git repo that ASF controls). This is the "manually > inspecting" part. If as a PMC you can compare on Your Machine, taking > appropriate ASF repo sources that the package you verify signature of is > coming from the sources - you are good. It does not have to be bit-by-bit > identical. But the step of doing it MUST be part of the process - > especially when signing is done somewhere else than building - because > otherwise the content of the binary to sign might be modified somewhere on > the way - from the machine where things were build to the machine where it > is signed, also if the machine is controlled by someone else, that someone > (GitHub) could modify the binary even if it is build on the same machine > where signing happens. > > > All of this to say, it is our goal to get to fully reproducible builds. > > This is great! I was at the reproducible builds summit in Vienna [3] > earlier this year - with Hervé Boutemy and other people from the community > - and we are all working hard to make it as easy as possible to have > reproducible builds for maintainers. Herveé - particularly - as a PMC > member of Maven has this as a personal goal to have Maven builds to be > easily reproducible, so you might want to talk to him if you would like to > improve things in your reproducibility. He knows everything about it. > > > Could you clarify if this requirement (INFRA key management) applies > equally to all resources used in the release process, such as the Docker > account, or if it is specific to the signing key? I did create a JIRA > ticket for INFRA a while ago requesting a release account for the podling. > > Docker releases are "compiled/convenience" packages - so they are not > "official/legal" releases and they - as I understand - have a little > relaxed expectations (especially with regards to reproducibility). And also > seems you have the key assigned by INFRA [1] - so I believe you are > perfectly fine here. > > > This is beyond the current discussion, but AFAICT Airflow's Helm Chart > release guide requires Helm 3.14.0 which does not support reproducible > builds (see helm#31323 [8]). I am interested to know more about this, as > this is one of the issues we identified. > > Absolutely. Here you go. Note that there are no "strict" requirements about > "compile/convenience" packages (which Helm chart belongs to). The > reproducibility and even "signing/checksumming" only actually refers to the > official "source" packages. But in Airflow we opted in on full bit-to-bit > reproducibility for all artifacts we produce (even if it is not strictly > required) - except container images, that are extremely difficult to get > bit-to-bit identical. > > I am fully aware Helm 4 released last month has support for reproducibility > - I've been following thatm and was waiting for it to happen. We have not > switched to it yet, mostly because we have not released Helm Chart for a > few months and we will likely release a new version in 2-3 months so we > still have time to switch. We are also heavily changing our approach for > Helm chart - we want to get rid of Postgres and leverage kustomize to not > have to get and approve every single customisation our users want from us. > We want to rather tell them how to use kustomize so that they can do it on > their own (to be perfectly honest - maintaining the chart is ... pain in > the neck ... when your chart starts having 100s of optional features). More > about it in [4] - but switching to Helm 4 will happen when we make final > decisions and implement them. > > But when it comes to current Airflow Helm reproducibility - we implemented > a hack. Helm chart is basically a zip archive, and ir-reproducibility came > mostly from the way how the .zip file was prepared. So what we do is we > repack the Helm .zip archive deterministically after it's prepared by helm > build command and sign it after as part of our regular release process. We > have our own `breeze` tooling that we use to do all our dev and release > management stuff - and this is the piece of code that does it as part of > `breeze release-management prepare-helm-chart` command - calling > `repack_deterministically` method from `reproducible` module in breeze [5] > > result = repack_deterministically( > source_archive=source_archive, > dest_archive=final_archive, > prepend_path=None, > timestamp=get_source_date_epoch(CHART_DIR), > ) > > > [1] DockerHub token ticket: > https://issues.apache.org/jira/browse/INFRA-26824 > [2] Hardware/Verification in release policy > https://www.apache.org/legal/release-policy.html#owned-controlled-hardware > [3] Reproducible builds summit - > https://reproducible-builds.org/events/vienna2025/ > [4] Kustomize and Helm discussion in Airflow - > https://lists.apache.org/thread/ffolg4m3953qybp69n95p8zzd5tj05nw > [5] Airlfow reproducibility module -> > > https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/reproducible.py > > > > > On Wed, Dec 10, 2025 at 12:33 PM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Jarek, > > > > That is a good point regarding the "owned and controlled hardware" > > requirement for a release signed by an RM, which is a major difference > from > > our current semi-automated process. > > > > If the requirement is that INFRA must be responsible for creating the key > > and managing the GitHub secrets—and that this is the practice we must > > strictly follow for all incubating project releases—then we can cancel > this > > release and remove the secrets. > > > > Could you clarify if this requirement (INFRA key management) applies > > equally to all resources used in the release process, such as the Docker > > account, or if it is specific to the signing key? I did create a JIRA > > ticket for INFRA a while ago requesting a release account for the > podling. > > > > Regards, > > JB > > > > Le mer. 10 déc. 2025 à 12:11, Jarek Potiuk <[email protected]> a écrit : > > > >> Just another clarification from a short discussion on slack. JBO > >> mentioned that this is not an automated release, but semi-automated, > >> triggered by RM but this is not entirely how I see it. The main > difference > >> between "signed by RM" and "signed by automation" is where the release > is > >> signed (not even "technically" when the release is built). > >> The key here is that when RM builds the release (not automation) they > >> have to use. From the release policy > >> > https://www.apache.org/legal/release-policy.html#owned-controlled-hardware > >> : > >> > >> > That means hardware the committer has physical possession and control > >> of and exclusively full administrative/superuser access to. That's > because > >> only such hardware is qualified to hold a PGP private key, and the > release > >> should be verified on the machine the private key lives on or on a > machine > >> as trusted as that. > >> > >> This Is NOT what happens here. > >> > >> J. > >> > >> > >> > >> On Wed, Dec 10, 2025 at 12:02 PM Jean-Baptiste Onofré <[email protected]> > >> wrote: > >> > >>> Also, another clarification: I created the key (as mentor/PPMC member) > >>> and > >>> added it to the GitHub secrets. Only PPMC members can do it. > >>> > >>> Regards, > >>> JB > >>> > >>> Le mer. 10 déc. 2025 à 11:49, Jean-Baptiste Onofré <[email protected]> a > >>> écrit : > >>> > >>> > Jarek, > >>> > > >>> > Just to clarify, my understanding is that Infra is typically > >>> responsible > >>> > for creating the signing key only for TLP releases and for projects > >>> > participating in the Automated TLP Releases (ATR) program. > >>> > I might be wrong but that’s my understanding. > >>> > > >>> > Regards, > >>> > JB > >>> > > >>> > Le mer. 10 déc. 2025 à 11:11, Jean-Baptiste Onofré <[email protected]> > a > >>> > écrit : > >>> > > >>> >> Hi, > >>> >> > >>> >> I would like to clarify why I do not see the concerns about the > >>> release > >>> >> process being intrinsically different from a regular release: > >>> >> > >>> >> 1. Release Execution: This was a semi-automatic release, not fully > >>> >> automatic. The process was initiated by a release manager (Pierre) > who > >>> >> executed the script; it was not triggered by a simple button click > on > >>> >> GitHub Actions. > >>> >> 2. Key Management: The script uses a key that is published in the > KEYS > >>> >> file, available at: > >>> >> https://dist.apache.org/repos/dist/release/incubator/polaris/KEYS. > >>> The > >>> >> corresponding private key and password are securely stored as GitHub > >>> >> secrets, a practice also adopted by other Apache projects ( > >>> >> https://github.com/apache/iceberg/tree/main/dev for instance). I > >>> don't > >>> >> think the infra has to review all Apache release scripts (not really > >>> >> different from a mvn release:prepare/perform for instance). > >>> >> 3. Verification Process: The verification steps remain identical to > >>> >> previous releases. Voters can still verify the signature, checksum, > >>> and > >>> >> other artifacts. The documentation on the website is still valid. > >>> >> > >>> >> I do not see the key not belonging to the release manager as an > issue, > >>> >> given that the key is publicly registered and securely managed. > >>> >> > >>> >> As a side note, Polaris is also volunteering for the Automated TLP > >>> >> Releases (ATR) program. > >>> >> > >>> >> Regards, > >>> >> JB > >>> >> > >>> >> On Wed, Dec 10, 2025 at 10:26 AM Jarek Potiuk <[email protected]> > >>> wrote: > >>> >> > >>> >>> Hello here, > >>> >>> > >>> >>> Just lurking around here and JBO asked me to take a look. So I did > >>> :). > >>> >>> JBO > >>> >>> - I hope you will not regret it, but for me it is: -1 currently. > >>> Mostly > >>> >>> because I believe that the automation setup - even if very mature > and > >>> >>> well > >>> >>> designed - is not done in an ASF / INFRA compliant way, and > because > >>> I > >>> >>> think the verification process is not well communicated (and we do > >>> not > >>> >>> know > >>> >>> if it has been followed). > >>> >>> I might be mistaken of course - and it could be that I could not > >>> find the > >>> >>> necessary information - so I might change the vote once I got more > >>> >>> feedback. Sorry if I missed something obvious, I tried to be as > >>> diligent > >>> >>> as > >>> >>> possible to find all the information - this is my first message > >>> here, so > >>> >>> I > >>> >>> might have missed **something**, > >>> >>> > >>> >>> Automation of signing the release is only allowed when infra > reviews > >>> your > >>> >>> automation and when the build reproducibility is part of the > >>> verification > >>> >>> done by the (P)PMC. This is clearly described in the Automated > >>> Release > >>> >>> Signing step of release signing policy by infra [1]. > >>> >>> I think while the signing process is technically sound, those > >>> conditions > >>> >>> are not met. > >>> >>> > >>> >>> It's the first time for me to look at that as I am a new Incubator > >>> >>> mentor, > >>> >>> but I did my homework and tried to find all the answers - including > >>> >>> reading > >>> >>> the automation process thread [5] and the process proposal [6] > that I > >>> >>> found > >>> >>> after JBO's comment. > >>> >>> > >>> >>> As a side comment - this is a fantastic job and way to set it up - > >>> with > >>> >>> devlist discussion, proposal, prototypes etc. You definitely rock > >>> when it > >>> >>> comes to maturity of your automation, process and description of > >>> what > >>> >>> you > >>> >>> have done. This was a fantastic read. > >>> >>> > >>> >>> However I think some crucial steps are missing in the "approval" > and > >>> >>> "communication" parts from [1]: > >>> >>> > >>> >>> 1) There must be a JIRA ticket in Infra where they reviewed the > >>> >>> signing process and agreed to it and provided you with the key (and > >>> you > >>> >>> never had access to the key). I actually looked at JIRA and tried > to > >>> find > >>> >>> the Polaris ticket about it and could not - I saw quite a few > "setup" > >>> >>> tickets - including Dockerhub secrets creation - but I could not > see > >>> the > >>> >>> key signing ticket (maybe I missed it and you can refer to it > here). > >>> From > >>> >>> the policy: > >>> >>> > The project must request a signing key through an Infra Jira > >>> ticket, > >>> >>> and > >>> >>> Infra will provide a signing key for the project: > >>> >>> > >>> >>> 2) There must be a step (and it has to be followed) in the release > >>> >>> process > >>> >>> where (P)PMC member giving +1 builds the artifacts locally and > gets a > >>> >>> binary identical result as the one that is automatically signed - > >>> i.e. > >>> >>> reproducibility check. It does not have to be binary > reproducibility > >>> - in > >>> >>> case package contains only sources and no compiled code, it's > enough > >>> to > >>> >>> compare if sources are identical, some binary properties like > >>> timestamps, > >>> >>> permissions are not necessary (but binary reproducibility check is > >>> >>> generally easier if your process is binary-build-reproducible). > This > >>> is > >>> >>> explained in the incubator release checklist [2] as "Do the > contents > >>> of > >>> >>> the > >>> >>> release match with what's tagged in version control?". I tried to > >>> find > >>> >>> such > >>> >>> process and find out what level of reproducibility Polaris has and > >>> how > >>> >>> you > >>> >>> verify it - all I found was the (very nice) description of the > >>> release > >>> >>> process > >>> >>> > >>> >>> > >>> > https://github.com/apache/polaris/tree/apache-polaris-1.3.0-incubating-rc2/releasey > >>> >>> and the release scipts mentioned in the doc, but I could not find a > >>> step > >>> >>> describing the process of verification - so I could not find how > you > >>> >>> verify > >>> >>> reproducibility. The reproducibility / verification scripts are > >>> mentioned > >>> >>> in [7] as an idea of "Release verification script" and > >>> reproducibility is > >>> >>> even mentioned there. But again - this is my first time here, so I > >>> could > >>> >>> have missed it. > >>> >>> > >>> >>> I looked at the release email - and I cannot see the verification > >>> process > >>> >>> referred to. So as someone who would give +1 - I am not sure if I > >>> know > >>> >>> the > >>> >>> process to follow. And I have no idea what any of the people giving > >>> +1 > >>> >>> did. > >>> >>> > >>> >>> Also - this is actually required - each of the people casting their > >>> vote > >>> >>> should specify what they did - which of the checks they did > >>> (signatures, > >>> >>> checksums, licences, reproducibility). I see only +1s without > >>> explaining > >>> >>> what has been done which is considered generally a bad practice (I > >>> cannot > >>> >>> find a reference here - but maybe some other mentors might help > heere > >>> >>> > >>> >>> Example of similar processes we do in Airflow [3] -> this is where > >>> the > >>> >>> release verification "steps" are described. And when we vote, we > >>> mention > >>> >>> the steps we have done - example here [4] (usually we do all of > them > >>> as > >>> >>> PMC > >>> >>> members). There you can see: > >>> >>> > >>> >>> * link to the release verification process > >>> >>> * each PMC member voting explicitly states what they have done > >>> >>> * reproducibility is specifically checked (even if we do not have > yet > >>> >>> automation of releases - we do it to verify Release Manager's > work). > >>> >>> > >>> >>> And just to explain why this is needed, so that you do not think > it's > >>> >>> some > >>> >>> "cargo cult". It's all but that. > >>> >>> > >>> >>> This is needed from the legal standpoint. Voting on the release is > a > >>> >>> legal > >>> >>> act of Foundation - which means that the three (P)PMC members > voting > >>> on > >>> >>> it, > >>> >>> make the Foundation potentially liable in case someone has a legal > >>> >>> complaint - for example harm done by using the software. That's why > >>> it's > >>> >>> super important that we follow the process and confirm it. > >>> >>> Reproducibility > >>> >>> check in this case is a proof that this release has been prepared > >>> from > >>> >>> the > >>> >>> source code that is stored in our git repository - otherwise it is > >>> >>> possible > >>> >>> that release manager (if the build is prepared manually) or > malicious > >>> >>> actor > >>> >>> who broke into the machine/system that build the artifacts (in case > >>> of > >>> >>> automated process) has not injected anything. And it's not > >>> >>> theoretical threat - this is exactly what happened in the infamous > xz > >>> >>> case > >>> >>> [5] where maintainer got release manager status turned out to be a > >>> >>> malicious actor and injected backdoor that almost made it to major > >>> >>> distributions because they used the "official" packaged artifact > >>> >>> published > >>> >>> by the project and it contained malicious modification of the build > >>> >>> process > >>> >>> that was not in the source code. > >>> >>> > >>> >>> Since this is PPMC and not yet TLP, possibly not all those > >>> requirements > >>> >>> have to be met, but that will not qualify this release as "ASF cm > >>> >>> > >>> >>> [1] Infra Signing Policy > >>> >>> > >>> > https://infra.apache.org/release-signing.html#automated-release-signing > >>> >>> [2] Icubator Release Checklist > >>> >>> > >>> >>> > >>> > https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist > >>> >>> [3] Airflow's Release verification process: > >>> >>> > >>> >>> > >>> > https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md#verify-the-release-candidate-by-pmc-members > >>> >>> > >>> >>> [4] Airflow Voting mail example with +1s and stating the actions: > >>> >>> https://lists.apache.org/thread/crsg4bxhovyyz3gjorv5dcm85d7ytm5x > >>> >>> [5] XZ Utils backdoor: > >>> https://en.wikipedia.org/wiki/XZ_Utils_backdoor > >>> >>> [6] Polaris devlist discussion on automated releases: > >>> >>> https://lists.apache.org/thread/7tlmzwpdc9m4p4dx79jrydxs3x60m875 > >>> >>> [7] Polaris release automation process: > >>> >>> > >>> >>> > >>> > https://docs.google.com/document/d/1MpovNXHFxqC1rxw_WhekQujDSj_zOAl4AN2QyFkX23k/edit?tab=t.0#heading=h.itmh6zawe02p > >>> >>> > >>> >>> J. > >>> >>> > >>> >>> > >>> >>> > >>> >>> On Wed, Dec 10, 2025, 05:04 Jean-Baptiste Onofré <[email protected]> > >>> >>> wrote: > >>> >>> > >>> >>> > Hi > >>> >>> > > >>> >>> > Yes the key is in GitHub Secret. > >>> >>> > As other ASF projects, the podling uses several GitHub Secrets to > >>> >>> automate > >>> >>> > release. > >>> >>> > It has been described in the podling dev mailing list and also > the > >>> >>> > semi-automated script was on a PR and reviewed. > >>> >>> > > >>> >>> > Regards > >>> >>> > JB > >>> >>> > > >>> >>> > Le mar. 9 déc. 2025 à 21:53, Ryan Blue <[email protected]> a > écrit > >>> : > >>> >>> > > >>> >>> > > +0 > >>> >>> > > > >>> >>> > > More information is needed for me to update to +1. > >>> >>> > > > >>> >>> > > I see this signature: > >>> >>> > > > >>> >>> > > ``` > >>> >>> > > [blue@dev tmp]$ gpg --verify > >>> >>> apache-polaris-1.3.0-incubating.tar.gz.asc > >>> >>> > > gpg: assuming signed data in > >>> 'apache-polaris-1.3.0-incubating.tar.gz' > >>> >>> > > gpg: Signature made Tue 25 Nov 2025 01:08:54 AM PST > >>> >>> > > gpg: using RSA key > >>> >>> > 6A6532EAD1AE4441ACE054870E971D601C4AD16F > >>> >>> > > gpg: Good signature from "Apache Polaris < > [email protected] > >>> >" > >>> >>> > > [unknown] > >>> >>> > > gpg: WARNING: This key is not certified with a trusted > signature! > >>> >>> > > gpg: There is no indication that the signature belongs > >>> to > >>> >>> the > >>> >>> > > owner. > >>> >>> > > Primary key fingerprint: 6A65 32EA D1AE 4441 ACE0 5487 0E97 > 1D60 > >>> >>> 1C4A > >>> >>> > D16F > >>> >>> > > ``` > >>> >>> > > > >>> >>> > > Since that is not a release manager, this must have been > >>> produced by > >>> >>> the > >>> >>> > > release automation scripts that were discussed on the dev > list. I > >>> >>> took a > >>> >>> > > quick look, but I don't see how the private key is protected. > The > >>> >>> release > >>> >>> > > guide covers manual releases. I'm assuming that this is stored > >>> as a > >>> >>> > github > >>> >>> > > secret and is only accessible in a workflow that authorized > users > >>> >>> have > >>> >>> > > access to? (I see that it must be run by a committer from the > >>> thread > >>> >>> on > >>> >>> > the > >>> >>> > > dev list.) > >>> >>> > > > >>> >>> > > I'll change to +1 if someone can let me know how the keys are > >>> >>> managed. > >>> >>> > > > >>> >>> > > On Tue, Dec 9, 2025 at 9:27 AM Jean-Baptiste Onofré < > >>> [email protected] > >>> >>> > > >>> >>> > > wrote: > >>> >>> > > > >>> >>> > > > Dear IPMC members, > >>> >>> > > > > >>> >>> > > > This is a gentle reminder that the Apache Polaris > >>> 1.3.0-incubating > >>> >>> > (RC2) > >>> >>> > > > vote still requires a third binding vote to pass. > >>> >>> > > > > >>> >>> > > > Thank you, > >>> >>> > > > > >>> >>> > > > Regards > >>> >>> > > > JB > >>> >>> > > > > >>> >>> > > > On Mon, Dec 1, 2025 at 9:35 AM Pierre Laporte < > >>> >>> [email protected]> > >>> >>> > > > wrote: > >>> >>> > > > > >>> >>> > > > > Hello everyone, > >>> >>> > > > > > >>> >>> > > > > The Apache Polaris community has voted and approved the > >>> release > >>> >>> of > >>> >>> > > Apache > >>> >>> > > > > Polaris 1.3.0-incubating (RC2). We now kindly request the > >>> IPMC > >>> >>> > members > >>> >>> > > > > review and vote for this release. > >>> >>> > > > > > >>> >>> > > > > Polaris community vote thread: > >>> >>> > > > > * > >>> >>> https://lists.apache.org/thread/fw8xhobpnoy3mvvw8hxd3r7kw5of4kos > >>> >>> > > > > > >>> >>> > > > > Vote result thread: > >>> >>> > > > > * > >>> >>> https://lists.apache.org/thread/xjwb04c33oo387g5gjdx674bw7t9bhz2 > >>> >>> > > > > > >>> >>> > > > > This corresponds to the tag: > >>> apache-polaris-1.3.0-incubating-rc2 > >>> >>> > > > > * > >>> >>> > > > > > >>> >>> > > > > > >>> >>> > > > > >>> >>> > > > >>> >>> > > >>> >>> > >>> > https://github.com/apache/polaris/commits/apache-polaris-1.3.0-incubating-rc2 > >>> >>> > > > > * > >>> >>> > > > > > >>> >>> > > > > > >>> >>> > > > > >>> >>> > > > >>> >>> > > >>> >>> > >>> > https://github.com/apache/polaris/tree/308134d6440f8167afd563a885187e238c21048a > >>> >>> > > > > > >>> >>> > > > > The release tarball, signature, and checksums are here: > >>> >>> > > > > * > >>> >>> > > > > > >>> >>> > > > > >>> >>> > > > >>> >>> > > >>> >>> > >>> > https://dist.apache.org/repos/dist/dev/incubator/polaris/1.3.0-incubating > >>> >>> > > > > > >>> >>> > > > > Helm charts are available on: > >>> >>> > > > > * > >>> >>> > > > > > >>> >>> > > > > > >>> >>> > > > > >>> >>> > > > >>> >>> > > >>> >>> > >>> > https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart/1.3.0-incubating/ > >>> >>> > > > > NB: you have to build the Docker images locally in order to > >>> test > >>> >>> Helm > >>> >>> > > > > charts. > >>> >>> > > > > > >>> >>> > > > > You can find the KEYS file here: > >>> >>> > > > > * https://downloads.apache.org/incubator/polaris/KEYS > >>> >>> > > > > > >>> >>> > > > > Convenience binary artifacts are staged on Nexus. The Maven > >>> >>> > repository > >>> >>> > > > URL > >>> >>> > > > > is: > >>> >>> > > > > * > >>> >>> > > > > >>> >>> > > >>> >>> > >>> > https://repository.apache.org/content/repositories/orgapachepolaris-1046 > >>> >>> > > > > > >>> >>> > > > > Please download, verify and test. > >>> >>> > > > > > >>> >>> > > > > Please vote in the next 72 hours. > >>> >>> > > > > > >>> >>> > > > > [ ] +1 approve > >>> >>> > > > > [ ] +0 no opinion > >>> >>> > > > > [ ] -1 disapprove with the reason > >>> >>> > > > > > >>> >>> > > > > To learn more about apache Polaris, please see > >>> >>> > > > https://polaris.apache.org/ > >>> >>> > > > > > >>> >>> > > > > Thanks, > >>> >>> > > > > > >>> >>> > > > > -- > >>> >>> > > > > > >>> >>> > > > > Pierre > >>> >>> > > > > > >>> >>> > > > > >>> >>> > > > >>> >>> > > >>> >>> > >>> >> > >>> > >> >
