+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
> > > >
> > >
> >
>

Reply via email to