-1 due to the issues raised by Julian and josh. Otherwise it's OK for me on the functional part.
Thanks a lot Bertil for your work on this release. I've opened #598 Fix missing license <https://github.com/apache/incubator-baremaps/pull/598> for the files that need a header with the license. What I checked: - Full test suite from the git repository with 'mvn clean test -P integration' and maven 3.8.6 openJDK 19 OSX - Full test suite from the src.zip artifacts in the release with 'mvn clean test -P integration' and maven 3.8.6 openJDK 19 OSX (Hash: 4455dbfef94146d4d98292d3feb5da458f4f4e5b1938d27ec2f387ae5b8352bcd93a72cd2d7d1ff7d2479ee890c8a070d626d01786e0a89704fc09af2b197e56 ) - Checked the Release hash - Ran the OpenStreetMap example Best Léonard On Wed, 8 Mar 2023 at 21:01, Julian Hyde <jh...@apache.org> wrote: > -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> > <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> > <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 > > >
