Seems reasonable! Thanks for the explanation. 1. Next time I recommend testing with as many rc0's as you need, then starting at rc1, because it only really becomes a release candidate once it's presented to the mailing list for a vote. If that turns out to be inconvenient or impossible for some technical reason, it's not really a big deal, but a brief explanation on the vote thread would be helpful to clarify, so people know what happened to the earlier numbers, and don't think they got lost in their Inbox or something. 2. Ah, that makes sense. I think it's helpful to have it in a central place so somebody else can easily help with wrapping up the post-vote tasks, if you were unavailable for some reason. It can also be useful for review of the release candidate creation process, if somebody were looking at that during their vote checks.
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 > > > > > > > > > >
