Hi Jarek, just adding some context here.
For (full bit-by-bit) reproducibility, we have a tracking issue [1] for reference and to keep track of the known issues. Some of the resolved ones are not in 1.3.0-incubating-rc2, but already merged to the "main" branch. I've contributed information about identified issues of general interest back to reproducibile-builds.org and the ASF reproducible builds page [2]. The script [2] to verify RCs (I fixed a couple differences for macOS this morning) is pretty much ready now. It exists to help people verifying an RC - aka the technical bits like signature, checksums and bit-by-bit reproducibility. It's hard, especially for new people, to properly verify all staged artifacts (hello Maven repo) and consider all the project specific things. It's intentionally a bash script so it's possible to inspect what it's doing in a browser window as plain text before you run it (just in case someone doesn't trust it). Regarding helm charts, the implemented approach is a bit different: the verification script currently only verifies the content of the non-reproducible Helm zip file (so no bit-by-bit comparison failure). And I'm not sure whether even Helm 4 is fully reproducible as the order of archive entries might differ between builds. There'll be a page on the project web site describing what it does, how to run and use it [4]. All that happens against the Git tag and GIt SHA provided during the invocation. If the script identifies "mismatches", it tries to provide as much information as possible - including all the very verbose technical bits (most of that ends in a separate log file to not clutter the console output more than necessary). You can actually run it from the PR branch: bash <(curl \ --silent https://raw.githubusercontent.com/snazy/polaris/refs/heads/release-verification/tools/verify-release/verify-release.sh) \ --git-sha 308134d6440f8167afd563a885187e238c21048a \ --version 1.3.0-incubating-rc2 \ --maven-repo-id 1046 The reported bit-by-bit reproducibility issues are known and fixed on main, just not for the 1.3.0-incubating release, because we chose to not add more stuff to the release branch (compared to the base branch) than absolutely necessary. The only remaining by-bit reproducibility issue is Quarkus generated bytecode. I'm confident that there'll be a fix relatively soon, because they want to have/support bit-by-bit reproducible builds as well. It's "just" a tricky thing to solve. Looking at other release-vote threads on general@incubator I was under the impression that casted/forwarded votes don't need to repeat the verification steps mentioned in the podling's release-vote thread. But I understand that it's more convenient for IPMC members and I'll keep that in mind. I like the idea to add information/links about "how to verify" to the release-vote emails! Robert [1] https://github.com/apache/polaris/issues/2204 [2] https://cwiki.apache.org/confluence/display/SECURITY/Reproducible+Builds [3] https://github.com/apache/polaris/pull/2824 [4] https://github.com/snazy/polaris/blob/release-verification/site/content/release-verify.md 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 > >>> >>> > > > > > >>> >>> > > > > >>> >>> > > > >>> >>> > > >>> >>> > >>> >> > >>> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
