Sounds good, let’s focus on implementing a release process conform to Apache's guidelines.
> On 9 Mar 2023, at 10:52, Julian Hyde <jh...@apache.org> wrote: > > I could attempt to justify why ASF uses sha256 (or higher) and PGP for > its releases, but suffice to say that's just just how ASF does > releases and it's not negotiable. > > On Wed, Mar 8, 2023 at 2:38 PM Bertil Chapuis <bchap...@gmail.com> wrote: >> >> 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 th£ning 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 >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org > For additional commands, e-mail: dev-h...@baremaps.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org For additional commands, e-mail: dev-h...@baremaps.apache.org
