Hi all, I reviewed Pierre's script and it looks like a nice quick win, so +1.
Thanks, Alex On Fri, Jan 23, 2026 at 3:42 PM Jean-Baptiste Onofré <[email protected]> wrote: > > Hi Pierre, > > Thanks a lot for the PR! I will review it shortly. > > Regards, > JB > > On Fri, Jan 23, 2026 at 3:13 PM Pierre Laporte <[email protected]> > wrote: > > > Hi folks > > > > Here is a tentative solution: https://github.com/apache/polaris/pull/3515 > > > > This is currently developed as a standalone script so that we can quickly > > provide a workaround for #3500. This would work with your proposed > > step-by-step process, JB. The script (or its integration in automated > > workflows) would be run before we vote for a release. > > > > Let me know what you think > > > > Cheers > > -- > > > > Pierre > > > > > > On Fri, Jan 23, 2026 at 10:28 AM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > Hi, > > > > > > That works for me. > > > In terms of the release process, I think it would be easier: > > > 1. To maintain the "aggregate" index on dist dev ( > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart/index.yaml > > > ), > > > with the latest release using downloads.apache.org and all previous > > > releases using archive.apache.org > > > 2. When we stage a new release (for vote), we update the index on dist > > dev > > > 3. When we "promote" the release, we copy the index from dist dev to dist > > > release ( > > > > > > > > https://dist.apache.org/repos/dist/release/incubator/polaris/helm-chart/index.yaml > > > ) > > > With this approach, we will review and release artifacts (includes index) > > > that we publish. > > > > > > Just my $0.01 > > > > > > Regards > > > JB > > > > > > On Fri, Jan 23, 2026 at 10:19 AM Alexandre Dutra <[email protected]> > > > wrote: > > > > > > > Hi all, > > > > > > > > I think that the workflow suggested by Dmitri is the best in terms of > > UX. > > > > > > > > As for fixing the current state of things, what Pierre suggested seems > > > > like a quick win: regenerate an index that spans the two servers and > > > > publish it to dist > > > > release so that it replaces the one on download.a.o. > > > > > > > > Thanks, > > > > Alex > > > > > > > > On Thu, Jan 22, 2026 at 7:02 PM Jean-Baptiste Onofré <[email protected]> > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > We can argue that the index file is similar to the KEYS file and not > > > > > strictly part of the release. > > > > > > > > > > Theoretically, every artifact we publish should be voted on and > > remain > > > > > unchanged after the vote. This is why I suggested updating the > > > aggregated > > > > > index as part of the release currently under review. > > > > > > > > > > I believe this approach should work. > > > > > > > > > > Regards, > > > > > JB > > > > > > > > > > On Thu, Jan 22, 2026 at 6:58 PM Pierre Laporte < > > [email protected]> > > > > > wrote: > > > > > > > > > > > Thanks Robert for opening this thread. > > > > > > > > > > > > Regarding attaching the binary artifacts to GitHub releases, here > > is > > > > some > > > > > > good news: it is already the case :-). You can see that the > > source, > > > > binary > > > > > > tarballs as well as helm chart are attached to the 1.3.0 Github > > > Release > > > > > > [1]. That being said the file names are not great, let me open an > > > > issue > > > > > > for that. > > > > > > > > > > > > As for creating a Helm index that references charts across > > > > downloads.a.o > > > > > > and archive.a.o, I think it should be fairly easy to do. It can > > > > certainly > > > > > > be included as part of the release automation. > > > > > > > > > > > > For me the big question is: can we fix the user-facing issue asap? > > > As > > > > far > > > > > > as I can tell, we could either: > > > > > > * Restore the previous binaries in dist release by performing a > > > couple > > > > of > > > > > > `svn revert` commands > > > > > > * Regenerate an index that spans the two servers and publish it to > > > dist > > > > > > release so that it replaces the one on download.a.o > > > > > > > > > > > > JB, would it be possible to publish the index.yaml file to > > > dist/release > > > > > > without requiring voting on dev and on the incubator? Technically, > > > the > > > > > > file that is on dist release has been generated after the incubator > > > > vote > > > > > > was closed. So I think we could argue it is not part of any > > specific > > > > > > release. Wdyt? > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/polaris/releases/tag/apache-polaris-1.3.0-incubating > > > > > > -- > > > > > > > > > > > > Pierre > > > > > > > > > > > > > > > > > > On Thu, Jan 22, 2026 at 5:28 PM Jean-Baptiste Onofré < > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > index is already on downloads.apache.org ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/release/incubator/polaris/helm-chart/index.yaml > > > > > > > , dist is basically the "driver" of downloads.apache.org). > > > > > > > > > > > > > > I see only two possible options: > > > > > > > - we don't provide the Helm index (it's what Airflow is doing > > > > afair), but > > > > > > > the user experience is not great (helm repo add would not work > > "out > > > > of > > > > > > the > > > > > > > box") > > > > > > > - we create aggregate Helm index when staging a release, and so > > we > > > > keep > > > > > > the > > > > > > > index up to date, to be updated on downloads/dist release > > > > > > > > > > > > > > Regards > > > > > > > JB > > > > > > > > > > > > > > On Thu, Jan 22, 2026 at 5:23 PM Dmitri Bourlatchkov < > > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > Thanks for opening this discussion, Robert! It definitely looks > > > > like we > > > > > > > can > > > > > > > > improve helm UX. > > > > > > > > > > > > > > > > All: > > > > > > > > > > > > > > > > WDYT about hosting helm index for all supported releases on > > > > > > > > downloads.apache.org (as before), but moving old charts to the > > > > > > archive? > > > > > > > > > > > > > > > > When a new RC comes out it will have helm index updates > > according > > > > to > > > > > > what > > > > > > > > version is the latest at the time of release and some links > > > > > > (re-)pointing > > > > > > > > to the archive. When the RC is approved, its helm index will > > > simply > > > > > > > replace > > > > > > > > the old one on downloads.apache.org. > > > > > > > > > > > > > > > > The archive site will _not_ have a helm index, only chart tar > > > > files, > > > > > > > > signatures, etc. > > > > > > > > > > > > > > > > Link changes should not be a problem for automated tools, I > > hope. > > > > > > > > > > > > > > > > The helm index will be truncated as the community decides to > > > > > > "unsupport" > > > > > > > > old releases (with proper release note notifications, etc.). > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > On Thu, Jan 22, 2026 at 6:43 AM Robert Stupp <[email protected]> > > > > wrote: > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > The issue #3500 mentions an issue with (perma)links to Helm > > > > charts to > > > > > > > > > downloads.a.o. Once a new release is published, the > > previously > > > > > > working > > > > > > > > link > > > > > > > > > will no longer work, as old releases, although available on > > > > > > archive.a.o > > > > > > > > get > > > > > > > > > removed from downloads.a.o. That's just how it works. > > > > > > > > > > > > > > > > > > For helm charts referenced by their URL and potential > > > > user-automation > > > > > > > to > > > > > > > > > grab other binary artifacts, a new release kind-of "suddenly" > > > > breaks > > > > > > > user > > > > > > > > > environments/workflows. > > > > > > > > > > > > > > > > > > What do you guys think about the following? > > > > > > > > > > > > > > > > > > We can attach the binary artifacts to GitHub releases and/or > > > > publish > > > > > > > > those > > > > > > > > > to Maven Central - and adjust the documented download links > > to > > > > either > > > > > > > of > > > > > > > > > these locations? > > > > > > > > > > > > > > > > > > For the Helm charts, the situation is a bit more complex, > > > > because of > > > > > > > the > > > > > > > > > index.yaml. While it is correct on downloads.a.o [1], the one > > > on > > > > > > > > > archive.a.o [2] is missing older releases. But since the > > > content > > > > of > > > > > > > > > archive.a.o is taken from downloads.a.o, there's not much we > > > can > > > > do > > > > > > > about > > > > > > > > > it. > > > > > > > > > An option could be to have an index.yaml elsewhere, > > potentially > > > > on a > > > > > > > > > separate web site like https://polaris-charts.apache.org/ > > that > > > > only > > > > > > > > > contains an ever-growing index.yaml file, which is updated > > > > during a > > > > > > > > release > > > > > > > > > publication using 'helm repo index . --merge index.yaml --url > > > > ...', > > > > > > > where > > > > > > > > > that URL points to the helm package, which can be a GitHub > > > > release > > > > > > > > artifact > > > > > > > > > or some other location. > > > > > > > > > > > > > > > > > > Robert > > > > > > > > > > > > > > > > > > [3500] https://github.com/apache/polaris/issues/3500 > > > > > > > > > [1] > > > > > > > > > > https://downloads.apache.org/incubator/polaris/helm-chart/index.yaml > > > > > > > > > [2] > > > > > > > > > > > > > > > > > > > > > > https://archive.apache.org/dist/incubator/polaris/helm-chart/index.yaml > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
