Thanks for creating a process. Now we have a process, we can iterate. A few thoughts.
1. On terminology. The release itself consists of the source code, literally the src.tar.gz file. People incorrectly use the term 'binary release' but the binaries are just artifacts generated from the release. Part of the reason that binaries are not part of the release is that it's only practical to vote on source code. What you have done here, generating and signing binaries from the source code, is about the best we can do. An Apache project MAY distribute binary artifacts with a release. Since Baremaps is a Java project, I would recommend deploying the jars to Maven Central. There are Maven plugins to stage the jars in Apache's repository so that people can inspect them during the vote. 2. On process. The release manager will send an email to vote on the artifacts. The email contains the hashes of the objects (to prevent, among other things, a man-in-the-middle attack where a server spoofs github.com), and instructions to verify the artifacts. As a mentor, I generally recommend that the first release is source only, and therefore you would not mention the binary artifacts in the release vote. 3. On the contents of the release. I noticed a few errors in the files: * the LICENSE file still contains its appendix; you should remove it; * in NOTICE, '2022 and onwards' should be '2022'; * there will need to be a DISCLAIMER file noting the incubating status; * maven-wrapper.jar should not be in the source distro (see https://issues.apache.org/jira/browse/LEGAL-570); * I strongly recommend that there is a README or README.txt file, written for the person who has just downloaded and unzipped the tar ball, describing what they have downloaded (including the version) and how to build it (yes, it's unfortunate that this file clashes with the README.md required by GitHub); * I would add headers to every text file that supports it, e.g. pom.xml, READM.md, baremaps.bat; there is an argument to skip for files where size is important, e.g. .js files that won't be minified; * Are there any generated files in the source code? maplibre-gl-inspect.js and schema.db. Errors are expected at this point. I'm sure I will find many more when there is a release candidate. :) 4. On licensing. The NOTICE file looks in fairly good shape. But I think we will need to audit the various test data sets. 5. On the location. Generally RMs stage the files into Apache subversion before a release vote. This ensures that the artifacts cannot be accidentally updated or deleted. (It also makes it easier for me, because I can just do 'svn update' on my directory that maps to https://dist.apache.org/repos/dist/dev/incubator/baremaps.) Lastly, I recommend that java classes have javadoc, without exception. (This advice pertains to the software development process, not releases, so feel free to ignore it.) Javadoc is a great place to document the purpose of a class; not just what it does, but why it is necessary, how it works, how you should use it, and why we put it in this place. If contributors see classes without javadoc they will contribute classes without javadoc, so if you start badly, things will only get worse over time. Julian On Fri, Nov 18, 2022 at 9:33 AM Bertil Chapuis <bchap...@gmail.com> wrote: > > Hello Everyone, > > The following draft release has been generated with github actions: > https://github.com/apache/incubator-baremaps/releases/tag/untagged-4d07860016b500637021 > > We have two distributions (source and binary) created with the maven assembly > plugin. The checksums and signatures are generated by the CI. For now, the > PGP signatures are computed with the PGP key used to sign the maven > artifacts. The release action is located here: > https://github.com/apache/incubator-baremaps/blob/cd0a1fdb7c7c29a6f41d1f299239cb61580b3036/.github/workflows/release.yml#L23 > > In order to publish a new release, the release manager would have to perform > the following steps: > 1) create a branch for the release > 2) execute the mvn release:prepare command in this branch > 3) check that the release action completes on github and produces a draft of > the release > 4) generate and edit the release notes on github > 5) ask the mailing list to vote for the release > 7) if the vote passes, merge the release branch into main and publish the > release > > What do you think about this process? Do not hesitate to share your thoughts. > > Best, > > Bertil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org For additional commands, e-mail: dev-h...@baremaps.apache.org
