Danny, thanks for putting things together, however, I guess the vote mail
requires clarifications before the votes can be cast :-/

Danny>The hashes of the artifacts are as follows:

dist.apache.org contains two archives, however, the vote mail lists just
one of them.
We had the very same case with 1.21.0 vote:
https://lists.apache.org/thread.html/ebfdfc6d3ac0f81801d805dec014f10507ee9cd7af63cac2999aeb19%40%3Cdev.calcite.apache.org%3E

Danny, can you please double-check all the release artifact checksums you
are going to release via dist.apache.org?


Danny>Release artifacts are signed with the following key:
Danny>https://people.apache.org/keys/committer/danny0405.asc

Is this key on the ASF web of trust?
I'm not sure that is a hard requirement for release signing, but I guess
historically we used the keys that were cross-signed by other
PMC/committers.

Danny>You can read the release notes here:
Danny>
https://github.com/apache/calcite/blob/calcite-1.22.0/site/_docs/history.md

Did you create calcite-1.22.0 tag manually?
I thought the build script should have created calcite-1.22.0-rc2,
however, I do not see it.

It looks sad to have the very same link /calcite/blob/calcite-1.22.0/site/
in different mails :-/
Then, it is not clear how to compare what has changed between the release
candidates.

The naming of calcite-1.22.0 tag is confusing: it can easily be confused
with a true release tag (see
https://lists.apache.org/thread.html/ra2bfc17c52d80250ed9848a1977ac23807282ab4c1c1b643625b36a8%40%3Cdev.calcite.apache.org%3E
 )

Do we really need a release branch? Why can't we build candidates out of
the master?
I guess if we had calcite-1.22.0-rc0, -rc1, and so on tags right in the
master branch, then everybody would see there's a release pending.

Vladimir

Reply via email to