This is a good list of points and pointers. It will take some time to address them all, but it clarify things a lot.
Regarding the hash, I appreciate the necessity to include it in the email. However, if we assume that we and our users download the files with an uncompromised machine and over an HTTPS connection, the risk of a MITM attack seems low. In my understanding, the main risk occurs when an attacker gains access to the download server. In this case, he could probably tamper both the .tar.gz file and the .sha256 files and this may go unnoticed for a while. I didn’t raised this issue because I wanted to focus on the release, but I would prefer to store the .sha256 file on another server or to rely exclusively on PGP (the .asc file is more difficult to tamper). What do you think? Regarding the release of artifacts, GitHub and Docker are mentioned as being approved distribution platforms in the “Other release platforms” section of the guide [1]. I didn’t realise that a special authorisation was needed. Josh, thank you for your availability. Would Friday work for you? (I’m not sure about your time zone; GMT+1 for me). As for wine, beer and whisky, I suppose that a good old release process eventually tastes good ;) Bertil [1] https://infra.apache.org/release-distribution.html#other-platforms > On 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>; 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org For additional commands, e-mail: dev-h...@baremaps.apache.org
