On Sun, Oct 30, 2022 at 2:03 PM Alex Herbert <alex.d.herb...@gmail.com>
wrote:

> Hi,
>
> On Sun, 30 Oct 2022 at 16:03, Gilles Sadowski <gillese...@gmail.com>
> wrote:
> >
> > Hello.
> >
> > Le ven. 28 oct. 2022 à 18:53, Alex Herbert <aherb...@apache.org> a
> écrit :
> > >
> > > We have fixed quite a few bugs and added some significant enhancements
> > > since Apache Commons Numbers 1.0 was released, so I would like to
> > > release Apache Commons Numbers 1.1.
> > >
> > > Apache Commons Numbers 1.1 RC1 is available for review here:
> > >     https://dist.apache.org/repos/dist/dev/commons/numbers/1.1-RC1
> > > (svn revision 57646)
> >
> >  $ svn co https://dist.apache.org/repos/dist/dev/commons/numbers/1.1-RC1
> >  $ cd 1.1-RC1
> >  $ ./signature-validator.sh .
> > ---CUT---
> >
> >
> >   % Total    % Received % Xferd  Average Speed   Time    Time     Time
> Current
> >                                  Dload  Upload   Total   Spent    Left
> Speed
> >   0     0    0     0    0     0      0      0 --:--:-- --:--:--
> > --:--:--     0curl: (6) Could not resolve host: .
> > INFO: Downloading artifacts from nexus
> > INFO: Validating Signatures in
> >
> /home/gilles/gilles/devel/java/apache/release_check/numbers/1.1-RC1/artifacts-for-validation-deletable-post-validation
> > SUCCESSFUL VALIDATION
> > ---CUT---
> >
>
> Caveat: I did not write this script and have only modified it recently
> to make the cut commands to be more robust to different checksum
> outputs. It works for a single module commons release. For the recent
> RNG release I gave the command to run the script for each module in
> turn. This duplicates the validation of the zip archives but does
> download and validate everything. I deemed the script too fragile to
> repeat providing the command for the 10 modules for numbers. It does
> not report very well on incorrect or unexpected execution (see below).
> It also does not work on my MacBook as I just found out.
>
> > Does it try to download "." ?  [This contradicts the comments within
> > the script.]
>
> Yes. Not very helpful.
>
> > Did it perform the validation?  Or does it mean "0 files were
> > successfully validated."?
>
> It validated what it found, which was nothing to validate. The script
> either runs and outputs this message, or fails on one of the checksum
> commands that precede it. But when it has no list of checksums it just
> reports success.
>
> >
> > >
> > > The Git tag for this RC is commons-numbers-1.1-RC1 which you can
> browse here:
> > >
> https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=commit;h=commons-numbers-1.1-RC1
> > >
> > > You may checkout this tag using:
> > >     git clone https://gitbox.apache.org/repos/asf/commons-numbers.git
> > > --branch commons-numbers-1.1-RC1 commons-numbers-1.1-RC1
> > >
> > > Maven artifacts are here:
> > >
> https://repository.apache.org/content/repositories/orgapachecommons-1604/org/apache/commons/
> >
> > Calling
> >  $
> > generates a bunch of message to standard error, like
> > ---CUT---
> >   % Total    % Received % Xferd  Average Speed   Time    Time     Time
> Current
> >                                  Dload  Upload   Total   Spent    Left
> Speed
> >    0     0    0     0    0     0      0      0 --:--:-- --:--:--
> > --:--:--     0Warning: Failed to create the file
> > Warning:
> /home/gilles/gilles/devel/java/apache/release_check/numbers/1.1-RC1/ar
> > Warning: tifacts-for-validation-deletable-post-validation/: Is a
> directory
> >    0     0    0     0    0     0      0      0 --:--:-- --:--:--
> --:--:--     0
> > curl: (23) Failure writing output to destination
> > ---CUT---
> > While on standard output:
> > ---CUT---
> > INFO: Downloading artifacts from nexus
> > INFO: Validating Signatures in
> >
> /home/gilles/gilles/devel/java/apache/release_check/numbers/1.1-RC1/artifacts-for-validation-deletable-post-validation
> > SUCCESSFUL VALIDATION
> > ---CUT---
> >
> > [Noting again that for the casual reviewer, that's fairly cryptic and
> > possibly misleading (I don't know if the check was actually done...).]
>
> I think the command would be needed for each module, e.g.:
>
> > ./signature-validator.sh
> https://repository.apache.org/content/repositories/orgapachecommons-1604/org/apache/commons/commons-numbers-core/1.1/
>
> But I cannot verify this as it does not work on my MacBook: one of the
> sed commands breaks. I've only tried it before on a linux box where it
> worked OK if the argument was correct.
>
> >
> >
> > >
> > > These are the artifacts and their hashes:
> > >
> > >
> commons-numbers-1.1-bin.tar.gz=e3827bf92a58bef6c1e1760a771c38a78ef74d452c030e7e0b0220ef439a93e7f9102bf871b1bcc6d2fd36e5cdd3f8cf457bf020d5c7b58b93675cade2937040
> > >
> commons-numbers-1.1-bin.zip=5d4f132253df294f30eea4893d94ad3c63788dee5c6b006f861ea502da3da34918b215b3d5cb2f534a59f864ba4c3ba1f536cb914c1de0388974e19e3e5f9b52
> > >
> commons-numbers-1.1-src.tar.gz=7398d725ac4fa7d8c3ef6f3578630ffd66c740c70120dfea1dd2dbe99dcbe75925bce7f3c98651613c13878997ccf669b4c66dd8c13e09b737988ce5c69419c6
> > >
> commons-numbers-1.1-src.zip=7b448154dc0f917004780e52e982fdbc852840bb5dc87fa14d20cf0fb7701d755fbcaf492a27058db4cfbb6e9e024e19929857b69289d2c77c89f605addc998a
> > >
> > > I have tested this with 'mvn clean install' using:
> > >
> > > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > > Maven home: /usr/local/apache-maven-3
> > > Java version: 1.8.0_333, vendor: Oracle Corporation, runtime:
> > > /usr/lib/jvm/jdk1.8.0_333/jre
> > > Default locale: en_GB, platform encoding: UTF-8
> > > OS name: "linux", version: "4.15.0-194-generic", arch: "amd64",
> family: "unix"
> > >
> > > I have tested this with 'mvn package site site:stage
> > > -Pcommons-numbers-examples' using:
> > >
> > > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > > Maven home: /usr/local/apache-maven-3
> > > Java version: 11.0.16, vendor: Ubuntu, runtime:
> > > /usr/lib/jvm/java-11-openjdk-amd64
> > > Default locale: en_GB, platform encoding: UTF-8
> > > OS name: "linux", version: "4.15.0-194-generic", arch: "amd64",
> family: "unix"
> >
> > Build was successful when running
> >   $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn
> > -Pcommons-numbers-examples clean package site site:stage
> > [on Debian GNU/Linux.]
> >
> > Warning:
> > ---CUT---
> > WARNING: An illegal reflective access operation has occurred
> > WARNING: Illegal reflective access by
> > org.apache.cxf.transport.http.CXFAuthenticator
> >
> (file:/home/gilles/gilles/.m2/repository/org/apache/cxf/cxf-rt-transports-http/2.6.3/cxf-rt-transports-http-2.6.3.jar)
> > to field java.net.Authenticator.theAuthenticator
> > WARNING: Please consider reporting this to the maintainers of
> > org.apache.cxf.transport.http.CXFAuthenticator
> > WARNING: Use --illegal-access=warn to enable warnings of further
> > illegal reflective access operations
> > WARNING: All illegal access operations will be denied in a future release
> > ---CUT---
>
> Yet another java piece of code doing things with reflection because, I
> presume, it was the only way to get it done.
>
> Using: mvn dependencies:resolve-plugins
>
> org.apache.maven.plugins:maven-changes-plugin:maven-plugin:2.12.1:runtime
>    ...
>    org.apache.cxf:cxf-rt-transports-http:jar:2.6.3
>
> This is the latest version of the changes plugin. So we have to wait
> for an update, or try to update the POM to bring in a later version of
> this transitive dependency. The 2.6.3 version is from 2012. The latest
> is for a major version upgrade 3.5.4. The last on the 2.X branch is
> from 2014.
>
> https://search.maven.org/artifact/org.apache.cxf/cxf-rt-transports-http
> https://archive.apache.org/dist/cxf/
>
> If you build on JDK 8 this warning is probably not shown. Since it is
> for the build tools I do not think it is worth worrying about a
> warning. If it was an error then it would block building on later
> JDKs.
>
> I presume this will be fixed when maven-changes-plugin 3.X is released.
>
> >
> > >
> > > Note: The examples included by the profile require Java 9+.
> > >
> > > Details of changes since 1.0 are in the release notes:
> > >
> https://dist.apache.org/repos/dist/dev/commons/numbers/1.1-RC1/RELEASE-NOTES.txt
> > >
> https://dist.apache.org/repos/dist/dev/commons/numbers/1.1-RC1/site/changes-report.html
> >
> > There are issues supposedly targeted for v1.1 that are still "open".
> > Either the "fix version" should be modified, or did we miss some
> > intended features?
>
> Link provided for clarity (thanks Gilles):
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.1%20AND%20statusCategory%20%3D%20new
>
> I resolved Numbers-70 as the user guide is done. This was an omission
> on my part after the user guide was added.
>
> Numbers-29: The combinatorics are mostly done. The last comment (2017)
> was about an unported stirlingS2 method. I suggest resolving this
> ticket (done in version 1.0-beta1) and creating a new ticket for the
> stirlingS2 method if a port is required. I've not looked at the method
> so cannot comment about the difficulty of a port (and why it was left
> out of the original port to create the combinatorics module).
>
> Numbers-167: This was an optimisation for the precomputation of some
> factors. The method was changed to the Boost implementation after this
> ticket was created. Precomputation of factors for the Boost
> implementation would require more work as there are many code paths
> with different factors. I suggest moving to 1.2 for now.
>
> Numbers-69: All comments predate release 1.1. I suggest bumping to 1.2 for
> now.
>
> Numbers-30: All comments predate release 1.0. I suggest bumping to 1.2 for
> now.
>
> If there are no objections then I can update Jira. It will only affect
> the changes report for Numbers-70 (added a user guide). I plan to
> rebuild the site for the release anyway to fix the MathJax issue. If
> rebuilt after jira is updated then the jira report will contain it.
> Only the release notes and changes will be missing this.
>
> What is the precedent for changing the release notes after a vote?
> Does this require an RC2?
>

We vote on specific sources: the commit hash identified by a git commit (a
git tag) and the source zip/tar files; git and zip/tars must match. Jars
and bin zip/tar files are only delivered as a convenience to our users.

So, if you plan on changing the release note file that is inside the source
zip and tar files, then that requires a new RC and vote.

OTOH, you could just change the RN file on the dist area and in git after
the release, and regenerate the site then if needed.

It all depends on how tidy and accurate you want the release note to be.

Gary


>
> Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Reply via email to