Please vote on releasing this candidate as Apache Lucy version
0.6.1. The vote will be held open for at least the next 72
All interested parties are welcome to inspect the release candidate
and express approval or disapproval. Votes from members of the Lucy
PMC are binding; the vote passes if there are at least three binding
+1 votes and more +1 votes than -1 votes.
For suggestions as to how to evaluate Apache Lucy release candidates,
and for information on ASF voting procedures, see:
> [ ] +1 Release RC 1 as Apache Lucy 0.6.1.
> [ ] +0
> [ ] -1 Do not release RC 1 as Apache Lucy 0.6.1 because...
I found a small discrepancy between the content of the git tag and the content
of the release tarball: there are 2 lines missing from CHANGES in the tarball.
See below my sig.
My suggestion is to make a commit and update the tag before it is made
permanent by moving it under `rel/`. Rerolling a release candidate would be
overkill, but it is good for the tag and the tarball to match. It is not
critical that CHANGES be exhaustively complete.
Other things I checked:
* Sums and sigs check out.
* The `test_valgrind` build target for Perl, run on Amazon linux, did not
reveal any substantial problems.
* The `test_all.sh` script passed on OS X El Capitan
- Apple LLVM version 8.0.0 (clang-800.0.42.1)
- stock Perl 5.18.2
- go 1.4.2
* Though I've been quiet on-list lately, I've reviewed all commits.
* The issue tracker is clean.
* Copyright dates look good.
* [LUCY-286] - Remote::SearchClient::DESTROY shouldn't throw exceptions
- * [LUCY-309] - BSD make doesn't support pattern rules
* [LUCY-310] - CPAN dist includes Lucy/Test.xs
* [LUCY-311] - Non-ASCII error messages from strerror cause exceptions
- * [LUCY-312] - Remote searcher tests fail if port is in use
* [LUCY-315] - Memory leak in HitQueue with SortSpec
* [LUCY-316] - Don't regenerate POD when building CPAN distro
* [LUCY-317] - Compile failure on FreeBSD 10.1
On 11/12/2016 02:42, Marvin Humphrey wrote:
> I found a small discrepancy between the content of the git tag and the content
> of the release tarball: there are 2 lines missing from CHANGES in the tarball.
> See below my sig.
Right, I forgot to update the tarball after adding these two entries the
> My suggestion is to make a commit and update the tag before it is made
> permanent by moving it under `rel/`. Rerolling a release candidate would be
> overkill, but it is good for the tag and the tarball to match. It is not
> critical that CHANGES be exhaustively complete.
The rc1 tag should match the contents of the tarball now: