Great job getting this started. Comments are inlined. Websites referenced: [1] https://creadur.apache.org/rat/ [2] https://incubator.apache.org/policy/incubation.html#disclaimers
On Sun, Nov 20, 2022 at 4:24 PM Julian Hyde <jh...@apache.org> wrote: > 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. :) > ** I ran an Apache Rat [1] check in the repo. We need to add a rat excludes to ignore files where appropriate and add header files, Like Julian suggested. The command I ran (from inside the root folder of the repo) was $ java -jar ~/path-to-jar/apache-rat-0.15.jar . Typically, going through the licensing is a tedious task and we can get around doing this before the first release by adding a "Work in progress" Disclaimer [2] 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 > >
