-1 (binding)
This is a very good first release candidate from an incubating project.
Many things are done right. As noted below, the release needs to be in
tar.gz form, but I reviewed the release based on the contents of git. When
the errors have been fixed, let's have another release candidate.
What I checked:
* I checked NOTICE, LICENSE, DISCLAIMER-WIP. README was great (could use a
newline at the end).
* I could not check hashes or signatures (because this was based on Git,
not a tarball).
* I compiled and ran tests using Maven 3.8.1 on OpenJDK 17 Ubuntu Linux.
* I ran Apache RAT using ‘mvn rat:rat’ and it failed with 'Too many
unapproved licenses: 6’. This is not unexpected at this stage.
A lot of files need headers: .xml, .html, .sql, .js, .md, .yaml files can
all support headers. Can you document the source of the .tif, .ico and
.json files, since these don’t admit headers?
——
I agree with Josh’s remarks regarding the structure of the release and the
email.
The KEYS file can wait a little while, but the main thing we are voting on
is the artifacts - the tar.gz file and its signature files. It may seem
archaic in this age of Git, but it makes sense when you remember that a
release is a legal action - publishing something that wasn’t previously
published.
Bertil, a good place to start would be the vote email from an established
project such as Calcite. For example, the vote for Calcite 1.33 rc1 [1].
Just about everything in that email is necessary:
* the subject should include the name of the release candidate, so that you
can start a distinct email thread for the next RC;
* there are release notes (often external to the release, so that they can
be modified after the vote);
* there is a git tag (mainly for convenience)
* the artifacts to be voted on are staged at
dist.apache.org/repos/dist/dev/{project}/{version}
<http://dist.apache.org/repos/dist/dev/%7Bproject%7D/%7Bversion%7D>; after
the vote they will be moved to
dist.apache.org/dist/release/{project}/{version}
<http://dist.apache.org/dist/release/%7Bproject%7D/%7Bversion%7D>
* hashes must be in the email, so that voters can be sure they are voting
on the same artifacts that the release manager prepared (i.e. to prevent
man-in-the-middle attacks);
* the maven repository containing binary artifacts can be skipped;
* the PGP key of the release manager who signed the artifacts;
* instructions for how people can recreate the release (optional);
* instructions for people to build the release based on these artifacts;
* instructions how to vote, the duration of the vote.
If you are not already doing so, document the process of making the
release, and write scripts. Anyone on the PPMC should be able to step into
the release manager role.
Community members, please vote on the release, and please say what you did
to verify the release; don’t just vote ‘+1’ or ‘-1’.
Julian
On Mar 8, 2023, at 11:06 AM, Josh Fischer <j...@joshfischer.io> wrote:
Using dist.a.o is a must [1]. You could always ask for a special case to
be made, but I think you'd have to have solid reasoning behind it. We will
have to use the mirroring system as well [2]. I can be available in the
next few days.
1. https://infra.apache.org/release-distribution.html#public-distribution
2. https://infra.apache.org/release-distribution.html#download-links
On Wed, Mar 8, 2023 at 8:28 AM Bertil Chapuis <bchap...@gmail.com> wrote:
> Sorry, I should have better checked the URLs.
>
> Here is the release (incorrect in the first mail):
> https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1
>
> And the corresponding commit (correct in the first mail):
>
> https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1
>
> 1. We need accompanying checksum files and a gpg signature to verify the
> integrity of the download.
>
>
> The signature and integrity files are listed among the assets attached to
> the release (screenshot).
>
> 2. The archives should be uploaded to somewhere like
> https://dist.apache.org/repos/dist/dev/incubator/
> baremaps/baremaps-${version}-candidate-1
> <
> https://dist.apache.org/repos/dist/dev/incubator/baremaps/baremaps-${version}-candidate-1
> >
>
>
> Is this mandatory, or can we use the release page of GitHub to distribute
> the release?
>
> 4. We also need a KEYS file here:
> https://dist.apache.org/repos/dist/dev/incubator/baremaps/. An example is
> https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS
>
>
> I just read the instructions on release signing and I will probably have
> to adapt the release pipeline.
> https://infra.apache.org/release-signing.html
>
> There may be other things, but this is a rough first pass. We don't need
> to start a new vote or create a new candidate. I think we can simply add
> the required files and continue the vote.
>
>
> I will upload the necessary files. Would someone be available to review
> the release pipeline during a video call before resuming the vote? I think
> it may be a good way to eliminate the most salient problems.
>
> Best,
>
> Bertil
>
