+1, I verified: * source-release artifact content matches contents of git checkout at the commit that will be tagged * signatures match and are signed by the key with the specified fingerprint * nexus-generated md5 and sha1 hashes exist in the staging repo and match the artifacts * the jar, the pom, the source-release tarball, the javadoc.jar, and the source.jar all have expected content * the LICENSE and NOTICE files all exist and appear correct * manifest includes the expected git commit ID and the jar is sealed * the sha512 in the vote thread matches the source-release artifact * full build with tests pass
Note: I made a change to the staging repo. I deleted the .sha512 file automatically created by the checksum-maven-plugin in the apache-release profile in the parent POM, as well as the .sha512.md5 and .sha512.sha1 files that went with it that Nexus created. These are created with the intent to be removed from the staging repo before a release, along with the source-release tarball itself, by some projects' workflows, and the checksum-maven-plugin was added to the parent POM (poorly, IMO) to support those specific use cases. However, for Accumulo, we usually go ahead and publish the source-release tarball... because that's a perfectly acceptable distribution mechanism (Maven2-style repos are designed for artifacts beyond just jar artifacts). There are many issues with the checksum-maven-plugin (see https://issues.apache.org/jira/browse/MPOM-468 which discusses this in more detail). I will work to try to find a bypass for our projects' POM files, but in the meantime, the workaround (which I have already done) is to remove the 3 extra files (.sha512, .sha512.md5, and .sha512.sha1) for the source-release artifact (but leave the source-release.tar.gz, along with that tarball's .md5 and .sha1 generated by Nexus). Note that this doesn't affect the main accumulo release, because we override the source-release artifact creation and create an artifact with a -src classifier instead, and the plugin is not configured to create sha512 files for artifacts that have that classifier. Other issues, notes, and questions about the RC prep process: 1. It's not a big deal, but I'm a little confused about the release candidate numbering. The last one was 3, and this one is 4, but I think there's only been two? Curious what happened to the first two. Also, if it helps future release candidate preparation, I typically do a non-voting test of the release candidate process and call it rc0 (even if I do it more than once). 2. My next question is about the `-next` branch. In the core Accumulo project, the release candidate script creates a -next branch to be merged into the main (or maintenance) branch after the release vote passes. I don't see that one here, and I'm wondering if that's a difference in the script, or if you're doing something different for this library, and what the reasoning is behind it. The reason we typically create two branches, is because the maven-release-plugin creates two commits to bump the version. The first bumps to the release version (drops "-SNAPSHOT"), and the second bumps to the next anticipated version (and re-adds the "-SNAPSHOT"). This is the version that the script prompts you for. It also does some other important things like changing the `<scm><tag>` back to HEAD, which is what it should be during development. We tag the first commit, but the second commit (which carries the first) is what we merge into the branch. This is the branch that is referred to in the post-vote release checklist on line 13 (See https://github.com/apache/accumulo-access/pull/44/files#diff-b5bd1459153d0ed1c92644d562eeb14e3e974891fefa43ea21aa5ac73d42f25fR13 ) 3. The issue with the .sha512 file mentioned above should be addressed either upstream in the parent POM (hopefully; see https://issues.apache.org/jira/browse/MPOM-468) or as some kind of workaround in the accumulo-access POM, so we don't have to do any manual modification to the staging repo when doing releases. It's late tonight as I write this, but I created the upstream issue. We'll see if it gains traction, and if a solution arises upstream. If not, I have an idea for a workaround locally in our project that might work for the next release or release candidate. On Thu, Feb 15, 2024 at 8:21 AM Dave Marion <dmario...@gmail.com> wrote: > +1 (binding) > > I did the following: > > verified hashes > verified signatures > confirmed no difference between source release tar contents and rc4 branch > (sans dotfiles in the branch) > confirmed LICENSE file contents are correct > confirmed NOTICE file contents are correct and copyright date is correct > confirmed DEPENDENCIES file contents are correct > built the source using `mvn clean package verify -Perrorprone` > ran the AccessExample using the commands in the README > ran the AccessExpressionBenchmark using the commands in the README > ran the AccessExpressionAntlrBenchmark using the commands in the README > > On Wed, Feb 14, 2024 at 9:27 AM Dave Marion <dmario...@gmail.com> wrote: > > > Accumulo Developers, > > > > Please consider the following candidate for Apache Accumulo-Access > > 1.0.0-beta. > > > > Git Commit: > > 1c6051d4f450d620e3594659ed8f00c107348003 > > Branch: > > 1.0.0-beta-rc4 > > > > If this vote passes, a gpg-signed tag will be created using: > > git tag -f -s -m 'Apache Accumulo-Access 1.0.0-beta' rel/1.0.0-beta \ > > 1c6051d4f450d620e3594659ed8f00c107348003 > > > > Staging repo: > > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1111 > > Source (official release artifact): > > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1111/org/apache/accumulo/accumulo-access/1.0.0-beta/accumulo-access-1.0.0-beta-source-release.tar.gz > > > > Append ".asc" to download the cryptographic signature for a given > artifact. > > (You can also append ".sha1" or ".md5" instead in order to verify the > > checksums > > generated by Maven to verify the integrity of the Nexus repository > staging > > area.) > > > > Signing keys are available at https://www.apache.org/dist/accumulo/KEYS > > (Expected fingerprint: CF4A5B6E1321844EB658728306CC9CA1F9BF248E) > > > > In addition to the tarballs and their signatures, the following checksum > > files will be added to the dist/release SVN area after release: > > accumulo-access-1.0.0-beta-source-release.tar.gz.sha512 will contain: > > SHA512 (accumulo-access-1.0.0-beta-source-release.tar.gz) = > > > 033df0942c1015697977494c13da56f78fa6f12e6559a871ec16a14891775781da932e42e4b34edb3138eaaf9085af989ef3e864e09547b0160779ce2694d51d > > > > Issues and pull requests related to this release can be found at: > > > https://github.com/apache/accumulo-access/issues?q=milestone%3A1.0.0-beta > > > > Please vote one of: > > [ ] +1 - I have verified and accept... > > [ ] +0 - I have reservations, but not strong enough to vote against... > > [ ] -1 - Because..., I do not accept... > > ... these artifacts as the 1.0.0-beta release of Apache Accumulo-Access. > > > > This vote will remain open until at least Sat Feb 17 14:30:00 UTC 2024. > > (Sat Feb 17 09:30:00 EST 2024 / Sat Feb 17 06:30:00 PST 2024) > > Voting can continue after this deadline until the release manager > > sends an email ending the vote. > > > > Thanks! > > > > P.S. Hint: download the whole staging repo with > > wget -erobots=off -r -l inf -np -nH \ > > > > > https://repository.apache.org/content/repositories/orgapacheaccumulo-1111/ > > # note the trailing slash is needed > > >
