Re: [VOTE] Apache Accumulo-Access 1.0.0-beta-rc4

[Daniel Roberts]

+1 (binding)

* Verified sha checksums on all release artifacts
* Verified sha512 checksum matched the one in vote thread
* Verified GPG fingerprint matched expected "F9BF248E".
* Verified source artifact contents matched the rc4 branch sans .dotfiles
* Verified LICENSE file and NOTICE file contents are correct.
* Verified successfully source build by running `mvn clean package
verify -Perrorprone`
* Ran AccessExpressionBenchmark via README instructions.
* Ran AccessExample.java via README instructions.
* Ran AccessExpressionAntlrBenchmark via README instructions.

I found a reference to the "contrib" project in
the src/it/antlr4-example/README.md file.
I don't consider that a blocking issue for this release and I created PR #62
 to update that README
file.

- Dan R.

On Fri, Feb 16, 2024 at 2:12 PM Christopher  wrote:

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

Re: [VOTE] Apache Accumulo-Access 1.0.0-beta-rc4

[Christopher]

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  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  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 `` back to HEAD, which is
> what
> > it should be during development. We tag the 

Re: [VOTE] Apache Accumulo-Access 1.0.0-beta-rc4

[Christopher Shannon]

+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 
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  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  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 `` back to HEAD, which is
> > what
> > > it should be during development. We tag the 

Re: [VOTE] Apache Accumulo-Access 1.0.0-beta-rc4

[Dominic Garguilo]

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

Re: [VOTE] Apache Accumulo-Access 1.0.0-beta-rc4

[Keith Turner]

+1

Verified checksums and signatures
Compared source zip to branch
Updated #3746 to use the version 1.0.0-beta of Accumulo Access, configured
maven to point to the staging repository, ran all accumulo unit test (which
tests Accumulo classes that use accumulo-access), and ran ComprehensiveIT
(while covers visibility in an IT).  All test runs were successful.  I saw
the jars being downloaded from the staging repo in the maven build logs.


On Wed, Feb 14, 2024 at 9:28 AM Dave Marion  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-
> Source (official release artifact):
>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-/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-/
> # note the trailing slash is needed
>

Re: [VOTE] Apache Accumulo-Access 1.0.0-beta-rc4

[Dave Marion]

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  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 `` 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  wrote:
>
> > +1 (binding)
> >
> > I did the following:
> >
> > verified hashes
> > verified