+1 (binding) * Validated signatures and checksums * Verified license and notice files in archives * Verified license headers in soue with mvn apache-rat:check * Ran the full build and tests * Tested out the project with a bunch of examples with different input using the instructions on the wiki On Fri, Feb 16, 2024 at 10:57 AM Dominic Garguilo <domgargu...@apache.org> wrote:
> +1 (binding) > > * full build passes. built from source using `mvn clean package verify > -Perrorprone` > * verified tests pass > * verified the sha512 in the vote thread matches the source-release > artifact > * ran the example and both benchmarks using the instructions in the readme > > > > On Fri, Feb 16, 2024 at 7:53 AM Dave Marion <dmario...@gmail.com> wrote: > > > Christopher, > > > > Regarding your issues, notes, etc.: > > > > 1. IIRC versions 1 and 2 were not built correctly and I did not restart > > the numbering for the first good build. > > 2. The build script gave me the option of where to put the branches > and I > > wasn't sure what the correct answer was. They are in my repo and I pushed > > the one branch upstream. I can push the other if needed. > > > > On Fri, Feb 16, 2024 at 1:29 AM Christopher <ctubb...@apache.org> wrote: > > > > > +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 > > > > > > > > > > > > > > >
