You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by James Dailey <jd...@apache.org> on 2025/02/06 01:18:20 UTC
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Devs - I started the release process but became aware of a blocker to that
- so we are delayed.
*Please help to stabilize the code base by Friday, Feb 21st.*
AND, looking at the commit log and the Jira tickets, what am I to make of
only 35 tickets in Jira (fixVersion = 1.11.0) and roughly 350 commits and
PRs in the GitHub log?
See
https://cwiki.apache.org/confluence/display/FINERACT/1.11.0+%28Pre-+Release+work%29+-+Apache+Fineract
.
It cannot be the job of the Release Manager to make sure that the processes
are being followed. The project needs everyone to follow good project
hygiene so that it can be maintained and understood. Can we please discuss
how to improve that?
My starting point was "Please make sure your tickets that were closed
between May 1st, 2024 and February 5th, 2025 (NOW) are tagged with
FixVersion=1.11.0."
But, I think the problem is probably deeper than that. Comment.
James
On Sun, Jan 26, 2025 at 6:44 PM James Dailey <jd...@apache.org> wrote:
> Hello everyone,
>
> I am the Release Manager for this next release.
>
> Based on our "How to Release Apache Fineract" process documented at
> https://cwiki.apache.org/confluence/x/DRwIB, I will create a Release 1.11
> branch off develop in our git repository at
> https://github.com/apache/fineract on
>
> ==> FEBRUARY 5th, 2025
>
> The release tracking umbrella issue for tracking all activity in JIRA is
> https://issues.apache.org/jira/browse/FINERACT-2172
> <https://issues.apache.org/jira/browse/FINERACT-2172>
>
> If you have any work in progress that you would like to see included in
> this release, please add "blocking" links to the release JIRA issue.
>
> I'll add that as far as I know, this is a good moment with key features
> reaching some maturity and a lot of development happening since the release
> 1.10.1 (which was a branch freeze around May 1, 2024). This is not a
> request to stop development, but please be aware of the branch being
> created on February 5th, 2025 at 1700 GMT.
>
> Cheers,
> James
>
>
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by VICTOR MANUEL ROMERO RODRIGUEZ <vi...@fintecheando.mx>.
I am ready
El mié, 5 mar 2025 a las 10:40, Adam Monsen (<am...@mifos.org>) escribió:
> We have thumbs-ups from Victor and Ádám and--as far as I know--nothing
> blocking the v1.11.0 release. Are we ready to vote?
>
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by Adam Monsen <am...@mifos.org>.
We have thumbs-ups from Victor and Ádám and--as far as I know--nothing
blocking the v1.11.0 release. Are we ready to vote?
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by Adam Monsen <am...@mifos.org>.
Ah sorry, let me clarify. Do not ignore "Firma INCORRECTA" / "BAD
signature". That's a fatal error causing gpg to exit with a nonzero return
code. The reason it's bad is that, with the commands as written, gpg is
trying to verify data in the wrong files. Please use these commands instead
to avoid signature / data file mismatch issues:
gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc
gpg --verify apache-fineract-1.11.0-binary.tar.gz.sha512.asc
gpg --verify apache-fineract-1.11.0-src.tar.gz.asc
gpg --verify apache-fineract-1.11.0-src.tar.gz.sha512.asc
Written that way, gpg will assume the signed data is in the file of the
same name minus the .asc extension. We've carefully named these files so
it'll work as expected.
Here's the one gpg warning you can ignore, for now:
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Related: https://en.wikipedia.org/wiki/Key_signing_party and
https://en.wikipedia.org/wiki/Web_of_trust , mentioned in
https://lists.apache.org/thread/7wq9moshw1hfndycodfnzy8ndocpwoy7 . That's a
great way we can eliminate confusing warnings like this.
Victor wrote:
> (base) fintecheando@thales:~/dev/apache/v11/binaries$ gpg --verify
> apache-fineract-1.11.0-src.tar.gz.sha512.asc
> apache-fineract-1.11.0-src.tar.gz
> gpg: Firmado el vie 28 feb 2025 12:41:08 CST
> gpg: usando EDDSA clave
> BD58EA9F85201ADB52CFC0444F169FF263F5F98E
> gpg: Firma INCORRECTA de "James Patrick Dailey <jd...@apache.org>"
> [desconocido]
> (base) fintecheando@thales:~/dev/apache/v11/binaries$ gpg --verify
> apache-fineract-1.11.0-binary.tar.gz.sha512.asc
> apache-fineract-1.11.0-binary.tar.gz
> gpg: Firmado el vie 28 feb 2025 20:06:37 CST
> gpg: usando EDDSA clave
> BD58EA9F85201ADB52CFC0444F169FF263F5F98E
> gpg: Firma INCORRECTA de "James Patrick Dailey <jd...@apache.org>"
> [desconocido]
>
> Keys are matching with the shared keys, just the warning.
>
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by VICTOR MANUEL ROMERO RODRIGUEZ <vi...@fintecheando.mx>.
*TL;DR The released files are correct.*
Sharing my detailed results:
(base) fintecheando@thales:~/dev/apache/v11/binaries$ gpg --verify
apache-fineract-1.11.0-src.tar.gz.sha512.asc
apache-fineract-1.11.0-src.tar.gz
gpg: Firmado el vie 28 feb 2025 12:41:08 CST
gpg: usando EDDSA clave
BD58EA9F85201ADB52CFC0444F169FF263F5F98E
gpg: Firma INCORRECTA de "James Patrick Dailey <jd...@apache.org>"
[desconocido]
(base) fintecheando@thales:~/dev/apache/v11/binaries$ gpg --verify
apache-fineract-1.11.0-binary.tar.gz.sha512.asc
apache-fineract-1.11.0-binary.tar.gz
gpg: Firmado el vie 28 feb 2025 20:06:37 CST
gpg: usando EDDSA clave
BD58EA9F85201ADB52CFC0444F169FF263F5F98E
gpg: Firma INCORRECTA de "James Patrick Dailey <jd...@apache.org>"
[desconocido]
Keys are matching with the shared keys, just the warning.
Same results as Ádám Sághy
Extracted the apache-fineract-1.11.0-binary.tar.gz:
- Run fineract locally: Successful
- Run fineract locally (Tomcat): Successful
- Building fineract from source:
- Run: `./gradlew binaryDistTar` -> Partially successful
- Run `./gradlew srcDistTar` -> Successful
- Run `./gradlew bootRun` -> Successful
- Run `./gradlew bootJar` -> Successful- Run `./gradlew :fineract-war:clean
:fineract-war:war` -> Successful
- Run (Jar file) -> Successful- Run (WAR file ) -> Successful
(base) fintecheando@thales:~/dev/apache/v11/binaries$ java --version
openjdk 17.0.14 2025-01-21 LTS
OpenJDK Runtime Environment Zulu17.56+15-CA (build 17.0.14+7-LTS)
OpenJDK 64-Bit Server VM Zulu17.56+15-CA (build 17.0.14+7-LTS, mixed mode,
sharing)
(base) fintecheando@thales:~/dev/apache/v11/binaries$ javac --version
javac 17.0.14
(base) fintecheando@thales:~/dev/apache/v11/binaries$ uname -a
Linux thales 6.8.0-52-generic #53~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed
Jan 15 19:18:46 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
(base) fintecheando@thales:~/dev/apache/v11/binaries$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.5 LTS
Release: 22.04
Codename: jammy
MariaDB 11.4 (Docker version)
https://github.com/apache/fineract/blob/develop/config/docker/compose/mariadb.yml
Postgresql 16.1 (Docker version)
https://github.com/apache/fineract/blob/develop/config/docker/compose/postgresql.yml
Tomcat 10.1.36 (Native version) https://tomcat.apache.org/download-10.cgi
The released files are correct.
*Thank you James, Adam Monsen & Ádám Sághy great work!*
El mar, 4 mar 2025 a las 11:10, Ádám Sághy (<ad...@gmail.com>) escribió:
> Hi
>
> With the new KEYS, i got the following:
> ➜ Downloads gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc
> apache-fineract-1.11.0-binary.tar.gz
> gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT
> gpg: using EDDSA key
> BD58EA9F85201ADB52CFC0444F169FF263F5F98E
> *gpg: Good signature from "James Patrick Dailey <jdailey@apache.org
> <jd...@apache.org>>" [unknown]*
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg: There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: BD58 EA9F 8520 1ADB 52CF C044 4F16 9FF2 63F5 F98E
>
> ➜ Downloads gpg --verify apache-fineract-1.11.0-src.tar.gz.asc.txt
> apache-fineract-1.11.0-src.tar.gz
> gpg: Signature made Fri 28 Feb 18:38:25 2025 GMT
> gpg: using EDDSA key
> BD58EA9F85201ADB52CFC0444F169FF263F5F98E
> *gpg: Good signature from "James Patrick Dailey <jdailey@apache.org
> <jd...@apache.org>>" [unknown]*
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg: There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: BD58 EA9F 8520 1ADB 52CF C044 4F16 9FF2 63F5 F98E
>
> *Seems the keys are matching with the shared keys!*
>
> *Extracted the apache-fineract-1.11.0-binary.tar.gz:*
> - Run fineract locally: `java -jar fineract-provider-1.11.0.jar` ->
> Successful (required database were running in docker)
> - Run fineract locally: `docker run --rm -it -v
> "$(pwd):/usr/local/tomcat/webapps" --net=host tomcat:jre17`, WAR got
> deployed and started successfully (required database were running in docker
> also)
>
> *- Building fineract from source:*
> - Run: `./gradlew binaryDistTar` -> Partially successful, tests are
> green, but `:fineract-doc:asciidoctorPdf` task failed. but i guess it is
> fine since it requires Ghost Script dependencies….
> - Run `./gradlew srcDistTar` -> Successful
> - Run `./gradlew bootRun` -> Fineract backend started successfully. l
> (required database were running in docker)
> - Run `./gradlew bootJar` -> Executable JAR got created successfully
> - Run `java -jar fineract-provider/build/libs/fineract-provider.jar` ->
> Fineract backend started successfully l (required database were running in
> docker)
>
>
> I think i am confident to say the released files are correct and Fineract
> can be compiled and executed!
>
> Regards,
> Adam
>
>
> On 2025. Mar 4., at 6:52, Adam Monsen <am...@mifos.org> wrote:
>
> Thank you again Ádám and Victor! Bummer about the PGP keys hiccups -- I'm
> confident we can sort this all out. I'm more worried about making sure the
> build contents are valid so hopefully we can move on to that step soon.
>
> James and I fixed the KEYS file together earlier today (US/Pacific
> time)--the problem was the missing newline in James's armored public key
> data block--this is what I identified/mentioned in my previous email
> <https://lists.apache.org/thread/wbzyo7o4qlfl8yyh3l4gkjgfoj1fpd96>. My
> improve-keys.patch fixes it, but please ignore that patch, I need to take
> another look at it tomorrow (I may have made a mistake, my eyes and hands
> are too tired right now to be trusted). The minimal fix in r75241 will do
> for the time being -- James's key in the KEYS file is valid now. But only
> in the "dev" area!
>
> https://dist.apache.org/repos/dist/dev/fineract/KEYS is fixed
>
> https://dist.apache.org/repos/dist/release/fineract/KEYS is still broken
>
> This difference in these two files is a nuance of the Apache release
> process we're using (their subversion setup for test/dev/release
> distribution). After reviewing their keys policy
> <https://infra.apache.org/release-signing.html#keys-policy> I suggest
> deleting the "dev" KEYS file and fixing the "release" KEYS file. I can
> think of one good reason to delete the dev one (hooray single source of
> truth!), and no good reasons to maintain both. James, I'm happy to pair
> with you to fix this.
>
> Ádám Sághy: 4F16 9FF2 63F5 F98E is James's key ID and BD58 EA9F 8520 1ADB
> 52CF C044 4F16 9FF2 63F5 F98E is the full fingerprint. Notice how those
> two strings overlap. I believe the missing uid is an annoying "feature" of
> openpgp's keyserver. They require you to answer an email challenge to
> include a uid, so James will have to do that if he wants to get his keys in
> sync. Since the KEYS file is now valid, that's the best place to get his
> key. Please grab the latest copy. For example:
>
> curl https://dist.apache.org/repos/dist/dev/fineract/KEYS | gpg --import
>
> Per PGP best practices, James must be the one to verify the fingerprint
> for his key, over a communications channel you both trust. Then he gets
> your public key and verifies your fingerprint, then you both trust and sign
> each others' keys (hooray web of trust!). The typical / ideal way to do
> this is a keysigning party in person. Since we basically span the globe,
> just checking fingerprints and release candidate signature validity is
> probably the best we can do until we're all able to get together and share
> some fun times. I do suggest everyone brush up on PGP skills. I'd be
> honored to do a little tutorial on that if folks are interested. This is
> useful even/also for non-Apache projects.
>
> Anyway, hopefully now we can get to running the build and war. Anyone else
> get as far as running the build and running the war?
>
> Victor wrote:
>
>> I found that the testing on binaryDistTar task is taking my JVM locale
>> (which is es-MX), so then changing the locale to en-US fixes it.
>
>
> Huh! Ok, I'm not really familiar with the nuance there. I'd hope it would
> work in both, but I know the build env settings are super fickle so I'm not
> surprised. Did the build succeed?
>
> Victor: should your PRs hold up the release?
>
> James: I just noticed you have another key up on the keys.openpgp.org
> keyserver, and that one *does* include a uid. Fingerprint is 849F 00D7
> F9ED B744 CCE3 9EF8 B394 C742 765F 8757. I think we made it before the
> new year? I suggest revoking that one.
>
>
>
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by Ádám Sághy <ad...@gmail.com>.
Hi
With the new KEYS, i got the following:
➜ Downloads gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc apache-fineract-1.11.0-binary.tar.gz
gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT
gpg: using EDDSA key BD58EA9F85201ADB52CFC0444F169FF263F5F98E
gpg: Good signature from "James Patrick Dailey <jd...@apache.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: BD58 EA9F 8520 1ADB 52CF C044 4F16 9FF2 63F5 F98E
➜ Downloads gpg --verify apache-fineract-1.11.0-src.tar.gz.asc.txt apache-fineract-1.11.0-src.tar.gz
gpg: Signature made Fri 28 Feb 18:38:25 2025 GMT
gpg: using EDDSA key BD58EA9F85201ADB52CFC0444F169FF263F5F98E
gpg: Good signature from "James Patrick Dailey <jd...@apache.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: BD58 EA9F 8520 1ADB 52CF C044 4F16 9FF2 63F5 F98E
Seems the keys are matching with the shared keys!
Extracted the apache-fineract-1.11.0-binary.tar.gz:
- Run fineract locally: `java -jar fineract-provider-1.11.0.jar` -> Successful (required database were running in docker)
- Run fineract locally: `docker run --rm -it -v "$(pwd):/usr/local/tomcat/webapps" --net=host tomcat:jre17`, WAR got deployed and started successfully (required database were running in docker also)
- Building fineract from source:
- Run: `./gradlew binaryDistTar` -> Partially successful, tests are green, but `:fineract-doc:asciidoctorPdf` task failed. but i guess it is fine since it requires Ghost Script dependencies….
- Run `./gradlew srcDistTar` -> Successful
- Run `./gradlew bootRun` -> Fineract backend started successfully. l (required database were running in docker)
- Run `./gradlew bootJar` -> Executable JAR got created successfully
- Run `java -jar fineract-provider/build/libs/fineract-provider.jar` -> Fineract backend started successfully l (required database were running in docker)
I think i am confident to say the released files are correct and Fineract can be compiled and executed!
Regards,
Adam
> On 2025. Mar 4., at 6:52, Adam Monsen <am...@mifos.org> wrote:
>
> Thank you again Ádám and Victor! Bummer about the PGP keys hiccups -- I'm confident we can sort this all out. I'm more worried about making sure the build contents are valid so hopefully we can move on to that step soon.
>
> James and I fixed the KEYS file together earlier today (US/Pacific time)--the problem was the missing newline in James's armored public key data block--this is what I identified/mentioned in my previous email <https://lists.apache.org/thread/wbzyo7o4qlfl8yyh3l4gkjgfoj1fpd96>. My improve-keys.patch fixes it, but please ignore that patch, I need to take another look at it tomorrow (I may have made a mistake, my eyes and hands are too tired right now to be trusted). The minimal fix in r75241 will do for the time being -- James's key in the KEYS file is valid now. But only in the "dev" area!
>
> https://dist.apache.org/repos/dist/dev/fineract/KEYS is fixed
>
> https://dist.apache.org/repos/dist/release/fineract/KEYS is still broken
>
> This difference in these two files is a nuance of the Apache release process we're using (their subversion setup for test/dev/release distribution). After reviewing their keys policy <https://infra.apache.org/release-signing.html#keys-policy> I suggest deleting the "dev" KEYS file and fixing the "release" KEYS file. I can think of one good reason to delete the dev one (hooray single source of truth!), and no good reasons to maintain both. James, I'm happy to pair with you to fix this.
>
> Ádám Sághy: 4F16 9FF2 63F5 F98E is James's key ID and BD58 EA9F 8520 1ADB 52CF C044 4F16 9FF2 63F5 F98E is the full fingerprint. Notice how those two strings overlap. I believe the missing uid is an annoying "feature" of openpgp's keyserver. They require you to answer an email challenge to include a uid, so James will have to do that if he wants to get his keys in sync. Since the KEYS file is now valid, that's the best place to get his key. Please grab the latest copy. For example:
>
> curl https://dist.apache.org/repos/dist/dev/fineract/KEYS | gpg --import
>
> Per PGP best practices, James must be the one to verify the fingerprint for his key, over a communications channel you both trust. Then he gets your public key and verifies your fingerprint, then you both trust and sign each others' keys (hooray web of trust!). The typical / ideal way to do this is a keysigning party in person. Since we basically span the globe, just checking fingerprints and release candidate signature validity is probably the best we can do until we're all able to get together and share some fun times. I do suggest everyone brush up on PGP skills. I'd be honored to do a little tutorial on that if folks are interested. This is useful even/also for non-Apache projects.
>
> Anyway, hopefully now we can get to running the build and war. Anyone else get as far as running the build and running the war?
>
> Victor wrote:
>> I found that the testing on binaryDistTar task is taking my JVM locale (which is es-MX), so then changing the locale to en-US fixes it.
>
> Huh! Ok, I'm not really familiar with the nuance there. I'd hope it would work in both, but I know the build env settings are super fickle so I'm not surprised. Did the build succeed?
>
> Victor: should your PRs hold up the release?
>
> James: I just noticed you have another key up on the keys.openpgp.org <http://keys.openpgp.org/> keyserver, and that one does include a uid. Fingerprint is 849F 00D7 F9ED B744 CCE3 9EF8 B394 C742 765F 8757. I think we made it before the new year? I suggest revoking that one.
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by Adam Monsen <am...@mifos.org>.
I wrote:
> *we need help from at least two more people to get this release out the
> door*. Please:
> 1. download the release candidate artifacts and verify their integrity
> 2. run a build using only the source tarball and the recommended JDK
> 3. start up a Fineract server using the war in the binary tarball
To expand on step 1: first verify checksums, then verify signatures. Here's
an example of acceptable output:
$ sha512sum -c apache-fineract-1.11.0-binary.tar.gz.sha512
apache-fineract-1.11.0-binary.tar.gz: OK
$ gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc
gpg: assuming signed data in 'apache-fineract-1.11.0-binary.tar.gz'
gpg: Signature made Fri 28 Feb 2025 06:06:12 PM PST
gpg: using EDDSA key BD58EA9F85201ADB52CFC0444F169FF263F5F98E
gpg: Good signature from "James Patrick Dailey <jd...@apache.org>"
[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: BD58 EA9F 8520 1ADB 52CF C044 4F16 9FF2 63F5 F98E
$ sha512sum -c apache-fineract-1.11.0-src.tar.gz.sha512
apache-fineract-1.11.0-src.tar.gz: OK
$ gpg --verify apache-fineract-1.11.0-src.tar.gz.asc
gpg: assuming signed data in 'apache-fineract-1.11.0-src.tar.gz'
gpg: Signature made Fri 28 Feb 2025 10:38:25 AM PST
gpg: using EDDSA key BD58EA9F85201ADB52CFC0444F169FF263F5F98E
gpg: Good signature from "James Patrick Dailey <jd...@apache.org>"
[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: BD58 EA9F 8520 1ADB 52CF C044 4F16 9FF2 63F5 F98E
Note the scary warnings from gpg. You can ignore these, for now. They are
because I have James's key, but nobody I know has signed it. If we ever do
a keysigning party, we can get rid of those warnings. Read all about
keysigning and the web of trust online or ask your favorite ai. 🙂
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by Adam Monsen <am...@mifos.org>.
Thank you again Ádám and Victor! Bummer about the PGP keys hiccups -- I'm
confident we can sort this all out. I'm more worried about making sure the
build contents are valid so hopefully we can move on to that step soon.
James and I fixed the KEYS file together earlier today (US/Pacific
time)--the problem was the missing newline in James's armored public key
data block--this is what I identified/mentioned in my previous email
<https://lists.apache.org/thread/wbzyo7o4qlfl8yyh3l4gkjgfoj1fpd96>. My
improve-keys.patch fixes it, but please ignore that patch, I need to take
another look at it tomorrow (I may have made a mistake, my eyes and hands
are too tired right now to be trusted). The minimal fix in r75241 will do
for the time being -- James's key in the KEYS file is valid now. But only
in the "dev" area!
https://dist.apache.org/repos/dist/dev/fineract/KEYS is fixed
https://dist.apache.org/repos/dist/release/fineract/KEYS is still broken
This difference in these two files is a nuance of the Apache release
process we're using (their subversion setup for test/dev/release
distribution). After reviewing their keys policy
<https://infra.apache.org/release-signing.html#keys-policy> I suggest
deleting the "dev" KEYS file and fixing the "release" KEYS file. I can
think of one good reason to delete the dev one (hooray single source of
truth!), and no good reasons to maintain both. James, I'm happy to pair
with you to fix this.
Ádám Sághy: 4F16 9FF2 63F5 F98E is James's key ID and BD58 EA9F 8520 1ADB
52CF C044 4F16 9FF2 63F5 F98E is the full fingerprint. Notice how those two
strings overlap. I believe the missing uid is an annoying "feature" of
openpgp's keyserver. They require you to answer an email challenge to
include a uid, so James will have to do that if he wants to get his keys in
sync. Since the KEYS file is now valid, that's the best place to get his
key. Please grab the latest copy. For example:
curl https://dist.apache.org/repos/dist/dev/fineract/KEYS | gpg --import
Per PGP best practices, James must be the one to verify the fingerprint for
his key, over a communications channel you both trust. Then he gets your
public key and verifies your fingerprint, then you both trust and sign each
others' keys (hooray web of trust!). The typical / ideal way to do this is
a keysigning party in person. Since we basically span the globe, just
checking fingerprints and release candidate signature validity is probably
the best we can do until we're all able to get together and share some fun
times. I do suggest everyone brush up on PGP skills. I'd be honored to do a
little tutorial on that if folks are interested. This is useful even/also
for non-Apache projects.
Anyway, hopefully now we can get to running the build and war. Anyone else
get as far as running the build and running the war?
Victor wrote:
> I found that the testing on binaryDistTar task is taking my JVM locale
> (which is es-MX), so then changing the locale to en-US fixes it.
Huh! Ok, I'm not really familiar with the nuance there. I'd hope it would
work in both, but I know the build env settings are super fickle so I'm not
surprised. Did the build succeed?
Victor: should your PRs hold up the release?
James: I just noticed you have another key up on the keys.openpgp.org
keyserver, and that one *does* include a uid. Fingerprint is 849F 00D7 F9ED
B744 CCE3 9EF8 B394 C742 765F 8757. I think we made it before the new year?
I suggest revoking that one.
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by VICTOR MANUEL ROMERO RODRIGUEZ <vi...@fintecheando.mx>.
Yes, 1 for fixing some libraries
El lun, 3 mar 2025 a las 16:57, James Dailey (<jd...@apache.org>)
escribió:
> I fixed a small error in my KEY in KEYS. Should be working now.
>
> Victor - are you planning on adding some PRs?
>
> On Mon, Mar 3, 2025 at 11:55 AM Ádám Sághy <ad...@gmail.com> wrote:
>
>> Hi guys,
>>
>> Adam, James: I am afraid something is not right around the keys and i was
>> unable to verify :(
>>
>> Let me share my steps and findings:
>> - Downloaded "apache-fineract-1.11.0-binary.tar.gz.asc” and
>> "apache-fineract-1.11.0-binary.tar.gz”.
>>
>> Run "gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc
>> apache-fineract-1.11.0-binary.tar.gz” on them gave the following:
>>
>> gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT
>> gpg: using EDDSA key
>> BD58EA9F85201ADB52CFC0444F169FF263F5F98E
>> gpg: Can't check signature: No public key
>>
>> Run "gpg --keyserver keys.openpgp.org --recv-key
>> BD58EA9F85201ADB52CFC0444F169FF263F5F98E”
>>
>> gpg: key 4F169FF263F5F98E: no user ID <- THIS LOOKS BAD!
>> gpg: Total number processed: 1
>>
>> Run "gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc
>> apache-fineract-1.11.0-binary.tar.gz” once ag
>> gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT
>> gpg: using EDDSA key
>> BD58EA9F85201ADB52CFC0444F169FF263F5F98E
>> gpg: Can't check signature: No public key
>>
>>
>> I have tried to import the KEYS from
>> https://dist.apache.org/repos/dist/dev/fineract/KEYS but got the very
>> same issue that Victor mentioned.
>>
>> I have taken a look on the patch that was shared by Adam Monsen, but i am
>> not comfortable with that since it contains many changes compared to the
>> uploaded file!
>>
>> Also the previous PGP keys and the one that was uploaded by James? not
>> even similar in length.
>>
>> Are we sure the proper keys were created?
>>
>> Regards,
>> Adam
>>
>>
>> On 2025. Mar 3., at 17:45, VICTOR MANUEL ROMERO RODRIGUEZ <
>> victor.romero@fintecheando.mx> wrote:
>>
>> @Adam Monsen <am...@mifos.org> I found that the testing on
>> binaryDistTar task is taking my JVM locale (which is es-MX), so then
>> changing the locale to en-US fixes it.
>>
>> Caused by: PlatformApiDataValidationException{errors=[The parameter `startDate` is invalid based on the dateFormat: *`dd MMMM yyyy` and locale: `en` provided*:]}
>> at app//org.apache.fineract.portfolio.loanaccount.service.reaging.LoanReAgingValidatorTest.lambda$testValidateReAge_ShouldThrowException_WhenLoanIsNotActive$13(LoanReAgingValidatorTest.java:361)
>> Caused by: java.time.format.DateTimeParseException: Text '*08 abril 2025*'
>>
>>
>> El lun, 3 mar 2025 a las 11:36, Adam Monsen (<am...@mifos.org>)
>> escribió:
>>
>>> Hi Victor, thank you for helping me with this!
>>>
>>> Others: *we need help* *from at least two more people* to get this
>>> release out the door. Please:
>>>
>>> 1. download the release candidate artifacts and verify their integrity
>>> 2. run a build using only the source tarball and the recommended JDK
>>> 3. start up a Fineract server using the war in the binary tarball
>>>
>>> These are just suggestions and I apologize for being brief/vague, I'm
>>> looking forward to helping out with documenting and detailing this process.
>>> If you have feedback on the best way to perform these steps, please share.
>>>
>>> Victor wrote:
>>>
>>>> The attached file contains the commands executed and shows checksum
>>>> error verification for the KEYS file.
>>>
>>>
>>> Good catch! I was able to reproduce this. The "invalid armor header" /
>>> "cabecera de armadura inválida", "CRC error" / "Error en suma de
>>> comprobación", and "[don't know]: invalid packet (ctb=40)" messages are all
>>> due to *one missing newline in the last key*. I hadn't run into this
>>> error previously because I think James gave me that key directly when we
>>> were able to do a mini keysigning party in person and it was properly
>>> formatted. But yeah, that's an invalid key there. Probably a copy/paste
>>> error or something.
>>>
>>> I'd like to improve this KEYS file to fix the broken key, add some
>>> documentation at the top, and use consistent formatting. James or Aleks,
>>> will you please review, apply and commit the attached patch against
>>> https://dist.apache.org/repos/dist/dev/fineract/KEYS at r71016?
>>>
>>> Regarding verifying the release candidate, I don't think there's much
>>> value in running the srcDistTar task, but I suppose it doesn't hurt. The
>>> binaryDistTar task is a bit more useful since it does build the code and
>>> run some basic tests. I'm not sure exactly what failed there but I'd say
>>> start with the recommended JDK version and try running the build from a
>>> *very* clean environment. For example, I've found I need to sometimes
>>> run `git clean -fdx` remove all of ~/.gradle to get a successful Fineract
>>> build and/or test run. I think this helps get rid of cached artifacts or
>>> old/bad dependencies or something.
>>>
>>> I wrote:
>>>
>>>> The help I'm seeking is for PMC members to fetch and verify these
>>>> artifacts are valid, following "Step 9: Verify Distribution Staging" from
>>>> the official docs (current-enough copy at
>>>> https://fineract.apache.org/docs/current/ ) and
>>>> https://www.apache.org/legal/release-policy.html . Additionally, my
>>>> unofficial suggestions are currently living at
>>>> https://github.com/meonkeys/fineract-asf-release-checklist/ (there's
>>>> some overlap and it's a work in progress, but I've got some good ideas
>>>> there).
>>>>
>>>> I'm working on updates to the docs to reflect what worked and didn't
>>>> for us today.
>>>
>>>
>>
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by James Dailey <jd...@apache.org>.
I fixed a small error in my KEY in KEYS. Should be working now.
Victor - are you planning on adding some PRs?
On Mon, Mar 3, 2025 at 11:55 AM Ádám Sághy <ad...@gmail.com> wrote:
> Hi guys,
>
> Adam, James: I am afraid something is not right around the keys and i was
> unable to verify :(
>
> Let me share my steps and findings:
> - Downloaded "apache-fineract-1.11.0-binary.tar.gz.asc” and
> "apache-fineract-1.11.0-binary.tar.gz”.
>
> Run "gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc
> apache-fineract-1.11.0-binary.tar.gz” on them gave the following:
>
> gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT
> gpg: using EDDSA key
> BD58EA9F85201ADB52CFC0444F169FF263F5F98E
> gpg: Can't check signature: No public key
>
> Run "gpg --keyserver keys.openpgp.org --recv-key
> BD58EA9F85201ADB52CFC0444F169FF263F5F98E”
>
> gpg: key 4F169FF263F5F98E: no user ID <- THIS LOOKS BAD!
> gpg: Total number processed: 1
>
> Run "gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc
> apache-fineract-1.11.0-binary.tar.gz” once ag
> gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT
> gpg: using EDDSA key
> BD58EA9F85201ADB52CFC0444F169FF263F5F98E
> gpg: Can't check signature: No public key
>
>
> I have tried to import the KEYS from
> https://dist.apache.org/repos/dist/dev/fineract/KEYS but got the very
> same issue that Victor mentioned.
>
> I have taken a look on the patch that was shared by Adam Monsen, but i am
> not comfortable with that since it contains many changes compared to the
> uploaded file!
>
> Also the previous PGP keys and the one that was uploaded by James? not
> even similar in length.
>
> Are we sure the proper keys were created?
>
> Regards,
> Adam
>
>
> On 2025. Mar 3., at 17:45, VICTOR MANUEL ROMERO RODRIGUEZ <
> victor.romero@fintecheando.mx> wrote:
>
> @Adam Monsen <am...@mifos.org> I found that the testing on
> binaryDistTar task is taking my JVM locale (which is es-MX), so then
> changing the locale to en-US fixes it.
>
> Caused by: PlatformApiDataValidationException{errors=[The parameter `startDate` is invalid based on the dateFormat: *`dd MMMM yyyy` and locale: `en` provided*:]}
> at app//org.apache.fineract.portfolio.loanaccount.service.reaging.LoanReAgingValidatorTest.lambda$testValidateReAge_ShouldThrowException_WhenLoanIsNotActive$13(LoanReAgingValidatorTest.java:361)
> Caused by: java.time.format.DateTimeParseException: Text '*08 abril 2025*'
>
>
> El lun, 3 mar 2025 a las 11:36, Adam Monsen (<am...@mifos.org>)
> escribió:
>
>> Hi Victor, thank you for helping me with this!
>>
>> Others: *we need help* *from at least two more people* to get this
>> release out the door. Please:
>>
>> 1. download the release candidate artifacts and verify their integrity
>> 2. run a build using only the source tarball and the recommended JDK
>> 3. start up a Fineract server using the war in the binary tarball
>>
>> These are just suggestions and I apologize for being brief/vague, I'm
>> looking forward to helping out with documenting and detailing this process.
>> If you have feedback on the best way to perform these steps, please share.
>>
>> Victor wrote:
>>
>>> The attached file contains the commands executed and shows checksum
>>> error verification for the KEYS file.
>>
>>
>> Good catch! I was able to reproduce this. The "invalid armor header" /
>> "cabecera de armadura inválida", "CRC error" / "Error en suma de
>> comprobación", and "[don't know]: invalid packet (ctb=40)" messages are all
>> due to *one missing newline in the last key*. I hadn't run into this
>> error previously because I think James gave me that key directly when we
>> were able to do a mini keysigning party in person and it was properly
>> formatted. But yeah, that's an invalid key there. Probably a copy/paste
>> error or something.
>>
>> I'd like to improve this KEYS file to fix the broken key, add some
>> documentation at the top, and use consistent formatting. James or Aleks,
>> will you please review, apply and commit the attached patch against
>> https://dist.apache.org/repos/dist/dev/fineract/KEYS at r71016?
>>
>> Regarding verifying the release candidate, I don't think there's much
>> value in running the srcDistTar task, but I suppose it doesn't hurt. The
>> binaryDistTar task is a bit more useful since it does build the code and
>> run some basic tests. I'm not sure exactly what failed there but I'd say
>> start with the recommended JDK version and try running the build from a
>> *very* clean environment. For example, I've found I need to sometimes
>> run `git clean -fdx` remove all of ~/.gradle to get a successful Fineract
>> build and/or test run. I think this helps get rid of cached artifacts or
>> old/bad dependencies or something.
>>
>> I wrote:
>>
>>> The help I'm seeking is for PMC members to fetch and verify these
>>> artifacts are valid, following "Step 9: Verify Distribution Staging" from
>>> the official docs (current-enough copy at
>>> https://fineract.apache.org/docs/current/ ) and
>>> https://www.apache.org/legal/release-policy.html . Additionally, my
>>> unofficial suggestions are currently living at
>>> https://github.com/meonkeys/fineract-asf-release-checklist/ (there's
>>> some overlap and it's a work in progress, but I've got some good ideas
>>> there).
>>>
>>> I'm working on updates to the docs to reflect what worked and didn't for
>>> us today.
>>
>>
>
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by Ádám Sághy <ad...@gmail.com>.
Hi guys,
Adam, James: I am afraid something is not right around the keys and i was unable to verify :(
Let me share my steps and findings:
- Downloaded "apache-fineract-1.11.0-binary.tar.gz.asc” and "apache-fineract-1.11.0-binary.tar.gz”.
Run "gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc apache-fineract-1.11.0-binary.tar.gz” on them gave the following:
gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT
gpg: using EDDSA key BD58EA9F85201ADB52CFC0444F169FF263F5F98E
gpg: Can't check signature: No public key
Run "gpg --keyserver keys.openpgp.org --recv-key BD58EA9F85201ADB52CFC0444F169FF263F5F98E”
gpg: key 4F169FF263F5F98E: no user ID <- THIS LOOKS BAD!
gpg: Total number processed: 1
Run "gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc apache-fineract-1.11.0-binary.tar.gz” once ag
gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT
gpg: using EDDSA key BD58EA9F85201ADB52CFC0444F169FF263F5F98E
gpg: Can't check signature: No public key
I have tried to import the KEYS from https://dist.apache.org/repos/dist/dev/fineract/KEYS but got the very same issue that Victor mentioned.
I have taken a look on the patch that was shared by Adam Monsen, but i am not comfortable with that since it contains many changes compared to the uploaded file!
Also the previous PGP keys and the one that was uploaded by James? not even similar in length.
Are we sure the proper keys were created?
Regards,
Adam
> On 2025. Mar 3., at 17:45, VICTOR MANUEL ROMERO RODRIGUEZ <vi...@fintecheando.mx> wrote:
>
> @Adam Monsen <ma...@mifos.org> I found that the testing on binaryDistTar task is taking my JVM locale (which is es-MX), so then changing the locale to en-US fixes it.
>
> Caused by: PlatformApiDataValidationException{errors=[The parameter `startDate` is invalid based on the dateFormat: `dd MMMM yyyy` and locale: `en` provided:]}
> at app//org.apache.fineract.portfolio.loanaccount.service.reaging.LoanReAgingValidatorTest.lambda$testValidateReAge_ShouldThrowException_WhenLoanIsNotActive$13(LoanReAgingValidatorTest.java:361)
> Caused by: java.time.format.DateTimeParseException: Text '08 abril 2025'
>
> El lun, 3 mar 2025 a las 11:36, Adam Monsen (<amonsen@mifos.org <ma...@mifos.org>>) escribió:
>> Hi Victor, thank you for helping me with this!
>>
>> Others: we need help from at least two more people to get this release out the door. Please:
>>
>> 1. download the release candidate artifacts and verify their integrity
>> 2. run a build using only the source tarball and the recommended JDK
>> 3. start up a Fineract server using the war in the binary tarball
>>
>> These are just suggestions and I apologize for being brief/vague, I'm looking forward to helping out with documenting and detailing this process. If you have feedback on the best way to perform these steps, please share.
>>
>> Victor wrote:
>>> The attached file contains the commands executed and shows checksum error verification for the KEYS file.
>>
>> Good catch! I was able to reproduce this. The "invalid armor header" / "cabecera de armadura inválida", "CRC error" / "Error en suma de comprobación", and "[don't know]: invalid packet (ctb=40)" messages are all due to one missing newline in the last key. I hadn't run into this error previously because I think James gave me that key directly when we were able to do a mini keysigning party in person and it was properly formatted. But yeah, that's an invalid key there. Probably a copy/paste error or something.
>>
>> I'd like to improve this KEYS file to fix the broken key, add some documentation at the top, and use consistent formatting. James or Aleks, will you please review, apply and commit the attached patch against https://dist.apache.org/repos/dist/dev/fineract/KEYS at r71016?
>>
>> Regarding verifying the release candidate, I don't think there's much value in running the srcDistTar task, but I suppose it doesn't hurt. The binaryDistTar task is a bit more useful since it does build the code and run some basic tests. I'm not sure exactly what failed there but I'd say start with the recommended JDK version and try running the build from a very clean environment. For example, I've found I need to sometimes run `git clean -fdx` remove all of ~/.gradle to get a successful Fineract build and/or test run. I think this helps get rid of cached artifacts or old/bad dependencies or something.
>>
>> I wrote:
>>> The help I'm seeking is for PMC members to fetch and verify these artifacts are valid, following "Step 9: Verify Distribution Staging" from the official docs (current-enough copy at https://fineract.apache.org/docs/current/ ) and https://www.apache.org/legal/release-policy.html . Additionally, my unofficial suggestions are currently living at https://github.com/meonkeys/fineract-asf-release-checklist/ (there's some overlap and it's a work in progress, but I've got some good ideas there).
>>>
>>> I'm working on updates to the docs to reflect what worked and didn't for us today.
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by VICTOR MANUEL ROMERO RODRIGUEZ <vi...@fintecheando.mx>.
@Adam Monsen <am...@mifos.org> I found that the testing on binaryDistTar
task is taking my JVM locale (which is es-MX), so then changing the locale
to en-US fixes it.
Caused by: PlatformApiDataValidationException{errors=[The parameter
`startDate` is invalid based on the dateFormat: *`dd MMMM yyyy` and
locale: `en` provided*:]}
at app//org.apache.fineract.portfolio.loanaccount.service.reaging.LoanReAgingValidatorTest.lambda$testValidateReAge_ShouldThrowException_WhenLoanIsNotActive$13(LoanReAgingValidatorTest.java:361)
Caused by: java.time.format.DateTimeParseException: Text '*08 abril 2025*'
El lun, 3 mar 2025 a las 11:36, Adam Monsen (<am...@mifos.org>) escribió:
> Hi Victor, thank you for helping me with this!
>
> Others: *we need help* *from at least two more people* to get this
> release out the door. Please:
>
> 1. download the release candidate artifacts and verify their integrity
> 2. run a build using only the source tarball and the recommended JDK
> 3. start up a Fineract server using the war in the binary tarball
>
> These are just suggestions and I apologize for being brief/vague, I'm
> looking forward to helping out with documenting and detailing this process.
> If you have feedback on the best way to perform these steps, please share.
>
> Victor wrote:
>
>> The attached file contains the commands executed and shows checksum error
>> verification for the KEYS file.
>
>
> Good catch! I was able to reproduce this. The "invalid armor header" /
> "cabecera de armadura inválida", "CRC error" / "Error en suma de
> comprobación", and "[don't know]: invalid packet (ctb=40)" messages are all
> due to *one missing newline in the last key*. I hadn't run into this
> error previously because I think James gave me that key directly when we
> were able to do a mini keysigning party in person and it was properly
> formatted. But yeah, that's an invalid key there. Probably a copy/paste
> error or something.
>
> I'd like to improve this KEYS file to fix the broken key, add some
> documentation at the top, and use consistent formatting. James or Aleks,
> will you please review, apply and commit the attached patch against
> https://dist.apache.org/repos/dist/dev/fineract/KEYS at r71016?
>
> Regarding verifying the release candidate, I don't think there's much
> value in running the srcDistTar task, but I suppose it doesn't hurt. The
> binaryDistTar task is a bit more useful since it does build the code and
> run some basic tests. I'm not sure exactly what failed there but I'd say
> start with the recommended JDK version and try running the build from a
> *very* clean environment. For example, I've found I need to sometimes run
> `git clean -fdx` remove all of ~/.gradle to get a successful Fineract build
> and/or test run. I think this helps get rid of cached artifacts or old/bad
> dependencies or something.
>
> I wrote:
>
>> The help I'm seeking is for PMC members to fetch and verify these
>> artifacts are valid, following "Step 9: Verify Distribution Staging" from
>> the official docs (current-enough copy at
>> https://fineract.apache.org/docs/current/ ) and
>> https://www.apache.org/legal/release-policy.html . Additionally, my
>> unofficial suggestions are currently living at
>> https://github.com/meonkeys/fineract-asf-release-checklist/ (there's
>> some overlap and it's a work in progress, but I've got some good ideas
>> there).
>>
>> I'm working on updates to the docs to reflect what worked and didn't for
>> us today.
>
>
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by Adam Monsen <am...@mifos.org>.
Hi Victor, thank you for helping me with this!
Others: *we need help* *from at least two more people* to get this release
out the door. Please:
1. download the release candidate artifacts and verify their integrity
2. run a build using only the source tarball and the recommended JDK
3. start up a Fineract server using the war in the binary tarball
These are just suggestions and I apologize for being brief/vague, I'm
looking forward to helping out with documenting and detailing this process.
If you have feedback on the best way to perform these steps, please share.
Victor wrote:
> The attached file contains the commands executed and shows checksum error
> verification for the KEYS file.
Good catch! I was able to reproduce this. The "invalid armor header" /
"cabecera de armadura inválida", "CRC error" / "Error en suma de
comprobación", and "[don't know]: invalid packet (ctb=40)" messages are all
due to *one missing newline in the last key*. I hadn't run into this error
previously because I think James gave me that key directly when we were
able to do a mini keysigning party in person and it was properly formatted.
But yeah, that's an invalid key there. Probably a copy/paste error or
something.
I'd like to improve this KEYS file to fix the broken key, add some
documentation at the top, and use consistent formatting. James or Aleks,
will you please review, apply and commit the attached patch against
https://dist.apache.org/repos/dist/dev/fineract/KEYS at r71016?
Regarding verifying the release candidate, I don't think there's much value
in running the srcDistTar task, but I suppose it doesn't hurt. The
binaryDistTar task is a bit more useful since it does build the code and
run some basic tests. I'm not sure exactly what failed there but I'd say
start with the recommended JDK version and try running the build from a
*very* clean environment. For example, I've found I need to sometimes run
`git clean -fdx` remove all of ~/.gradle to get a successful Fineract build
and/or test run. I think this helps get rid of cached artifacts or old/bad
dependencies or something.
I wrote:
> The help I'm seeking is for PMC members to fetch and verify these
> artifacts are valid, following "Step 9: Verify Distribution Staging" from
> the official docs (current-enough copy at
> https://fineract.apache.org/docs/current/ ) and
> https://www.apache.org/legal/release-policy.html . Additionally, my
> unofficial suggestions are currently living at
> https://github.com/meonkeys/fineract-asf-release-checklist/ (there's some
> overlap and it's a work in progress, but I've got some good ideas there).
>
> I'm working on updates to the docs to reflect what worked and didn't for
> us today.
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by VICTOR MANUEL ROMERO RODRIGUEZ <vi...@fintecheando.mx>.
Hello,
Before doing the signature verification I am trying to import this KEYS
file https://downloads.apache.org/fineract/KEYS
The attached file contains the commands executed and shows checksum error
verification for the KEYS file.
El dom, 2 mar 2025 a las 1:01, VICTOR MANUEL ROMERO RODRIGUEZ (<
victor.romero@fintecheando.mx>) escribió:
> Hello,
>
> I have tested the branch, the checksum and the signatures.
>
> Using https://github.com/apache/fineract/tree/maintenance/1.11 and
> https://dist.apache.org/repos/dist/dev/fineract/1.11.0
>
> The output of the commands for the branch:
>
> ./gradlew srcDistTar - OK
> ./gradlew binaryDistTar - FAILURE: Executed 714 tests in 3m 13s (15
> failed) - testing02032025.txt
>
> - Checksum is Ok for tar and binary files.
>
> - I cannot verify the signature and it seems that there are some issues
> with the KEYS files available for Apache Fineract - signatures.txt
>
> Regards
>
> Victor Romero
>
>
>
>
> El vie, 28 feb 2025 a las 15:45, James Dailey (<jd...@apache.org>)
> escribió:
>
>> Devs - Please see this request from Adam and do the verification step he
>> mentions.
>> https://dist.apache.org/repos/dist/dev/fineract/1.11.0 Which now
>> includes the binary files he built and signed.
>>
>> There's a lot involved in doing a release of an ASF project. To learn
>> more, see also:
>> https://infra.apache.org/release-distribution.html
>> https://infra.apache.org/release-publishing.html
>>
>> I will also note that we're going to revise some of the release documents
>> as we go along. All release practices will comply with the ASF
>> expectations and requirements.
>>
>> As a note, formally, the ASF does not *require* built artifacts as part
>> of the release, those are provided as a convenience. But, we treat the
>> process at Fineract as important because if someone cannot verify that the
>> build works and matches what we have in the release code, then we have
>> something broken.... and we should not release that.
>>
>> Thanks Adam for assisting the "Release manager". Hopefully these notes
>> and the documentation will help the next Release Manager.
>>
>> James
>>
>>
>> On Fri, Feb 28, 2025 at 12:22 PM Adam Monsen <am...@mifos.org> wrote:
>>
>>> We've got a 1.11.0 release candidate ready and we'd like help making
>>> sure it's good to go.
>>>
>>> The maintenance/1.11 branch was created off commit 843b279 and tagged
>>> 1.11.0. James ran ./gradlew srcDistTar to create the source tarball
>>> from that commit. He then manually created checksum and signature files and
>>> used svn to upload all that to
>>> https://dist.apache.org/repos/dist/dev/fineract/1.11.0 . The srcDistTar
>>> task took a few seconds to run.
>>>
>>> We couldn't get the binaryDistTar task to succeed on his computer, so I
>>> ran that on mine. gradle binaryDistTar took 7min 5sec to run and
>>> succeeded, but confusingly threw one NoClassDefFoundError exception. I'm
>>> not sure if seeing this exception should block the release--please review
>>> the attached log snippet and let me know what you think. Note that this
>>> task was initially breaking for me--I also only got it to work from a very
>>> clean clone. I think git clean -fdx helped with that, and perhaps also
>>> that I manually cleaned out some gradle/maven/cargo caches I was able to
>>> find. I could also have just done this in a fresh container or VM but it
>>> seemed like overkill and if something is polluting a build I want to
>>> understand what and why. Anyway, James will upload the binary, its
>>> checksum, and signatures for same. Temporary home for these is:
>>>
>>> https://adammonsen.com/tmp/apache-fineract-1.11.0-binary.tar.gz
>>> https://adammonsen.com/tmp/apache-fineract-1.11.0-binary.tar.gz.sha512
>>>
>>> And here's the actual SHA-512 checksum, just in case:
>>> 0ebe4e13d778e5d6d56f6b472e6304c17a34ebaea67742ac968ffcde2c787559442981de453b1360eb0b7adcc78a0a1fd1c6d4a3f51ed0ee18e759bfa2546992
>>> . That should be one 128-character hex string (in case it got broken into
>>> separate lines somewhere along the way to your eyeballs).
>>>
>>> *The help I'm seeking is for PMC members to fetch and verify these
>>> artifacts are valid*, following "Step 9: Verify Distribution Staging"
>>> from the official docs (current-enough copy at
>>> https://fineract.apache.org/docs/current/ ) and
>>> https://www.apache.org/legal/release-policy.html . Additionally, my
>>> unofficial suggestions are currently living at
>>> https://github.com/meonkeys/fineract-asf-release-checklist/ (there's
>>> some overlap and it's a work in progress, but I've got some good ideas
>>> there).
>>>
>>> I'm working on updates to the docs to reflect what worked and didn't for
>>> us today.
>>>
>>> Thanks!
>>> -Adam
>>>
>>
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by VICTOR MANUEL ROMERO RODRIGUEZ <vi...@fintecheando.mx>.
Hello,
I have tested the branch, the checksum and the signatures.
Using https://github.com/apache/fineract/tree/maintenance/1.11 and
https://dist.apache.org/repos/dist/dev/fineract/1.11.0
The output of the commands for the branch:
./gradlew srcDistTar - OK
./gradlew binaryDistTar - FAILURE: Executed 714 tests in 3m 13s (15 failed)
- testing02032025.txt
- Checksum is Ok for tar and binary files.
- I cannot verify the signature and it seems that there are some issues
with the KEYS files available for Apache Fineract - signatures.txt
Regards
Victor Romero
El vie, 28 feb 2025 a las 15:45, James Dailey (<jd...@apache.org>)
escribió:
> Devs - Please see this request from Adam and do the verification step he
> mentions.
> https://dist.apache.org/repos/dist/dev/fineract/1.11.0 Which now
> includes the binary files he built and signed.
>
> There's a lot involved in doing a release of an ASF project. To learn
> more, see also:
> https://infra.apache.org/release-distribution.html
> https://infra.apache.org/release-publishing.html
>
> I will also note that we're going to revise some of the release documents
> as we go along. All release practices will comply with the ASF
> expectations and requirements.
>
> As a note, formally, the ASF does not *require* built artifacts as part of
> the release, those are provided as a convenience. But, we treat the
> process at Fineract as important because if someone cannot verify that the
> build works and matches what we have in the release code, then we have
> something broken.... and we should not release that.
>
> Thanks Adam for assisting the "Release manager". Hopefully these notes
> and the documentation will help the next Release Manager.
>
> James
>
>
> On Fri, Feb 28, 2025 at 12:22 PM Adam Monsen <am...@mifos.org> wrote:
>
>> We've got a 1.11.0 release candidate ready and we'd like help making sure
>> it's good to go.
>>
>> The maintenance/1.11 branch was created off commit 843b279 and tagged
>> 1.11.0. James ran ./gradlew srcDistTar to create the source tarball from
>> that commit. He then manually created checksum and signature files and used
>> svn to upload all that to
>> https://dist.apache.org/repos/dist/dev/fineract/1.11.0 . The srcDistTar
>> task took a few seconds to run.
>>
>> We couldn't get the binaryDistTar task to succeed on his computer, so I
>> ran that on mine. gradle binaryDistTar took 7min 5sec to run and
>> succeeded, but confusingly threw one NoClassDefFoundError exception. I'm
>> not sure if seeing this exception should block the release--please review
>> the attached log snippet and let me know what you think. Note that this
>> task was initially breaking for me--I also only got it to work from a very
>> clean clone. I think git clean -fdx helped with that, and perhaps also
>> that I manually cleaned out some gradle/maven/cargo caches I was able to
>> find. I could also have just done this in a fresh container or VM but it
>> seemed like overkill and if something is polluting a build I want to
>> understand what and why. Anyway, James will upload the binary, its
>> checksum, and signatures for same. Temporary home for these is:
>>
>> https://adammonsen.com/tmp/apache-fineract-1.11.0-binary.tar.gz
>> https://adammonsen.com/tmp/apache-fineract-1.11.0-binary.tar.gz.sha512
>>
>> And here's the actual SHA-512 checksum, just in case:
>> 0ebe4e13d778e5d6d56f6b472e6304c17a34ebaea67742ac968ffcde2c787559442981de453b1360eb0b7adcc78a0a1fd1c6d4a3f51ed0ee18e759bfa2546992
>> . That should be one 128-character hex string (in case it got broken into
>> separate lines somewhere along the way to your eyeballs).
>>
>> *The help I'm seeking is for PMC members to fetch and verify these
>> artifacts are valid*, following "Step 9: Verify Distribution Staging"
>> from the official docs (current-enough copy at
>> https://fineract.apache.org/docs/current/ ) and
>> https://www.apache.org/legal/release-policy.html . Additionally, my
>> unofficial suggestions are currently living at
>> https://github.com/meonkeys/fineract-asf-release-checklist/ (there's
>> some overlap and it's a work in progress, but I've got some good ideas
>> there).
>>
>> I'm working on updates to the docs to reflect what worked and didn't for
>> us today.
>>
>> Thanks!
>> -Adam
>>
>
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by James Dailey <jd...@apache.org>.
Devs - Please see this request from Adam and do the verification step he
mentions.
https://dist.apache.org/repos/dist/dev/fineract/1.11.0 Which now includes
the binary files he built and signed.
There's a lot involved in doing a release of an ASF project. To learn
more, see also:
https://infra.apache.org/release-distribution.html
https://infra.apache.org/release-publishing.html
I will also note that we're going to revise some of the release documents
as we go along. All release practices will comply with the ASF
expectations and requirements.
As a note, formally, the ASF does not *require* built artifacts as part of
the release, those are provided as a convenience. But, we treat the
process at Fineract as important because if someone cannot verify that the
build works and matches what we have in the release code, then we have
something broken.... and we should not release that.
Thanks Adam for assisting the "Release manager". Hopefully these notes and
the documentation will help the next Release Manager.
James
On Fri, Feb 28, 2025 at 12:22 PM Adam Monsen <am...@mifos.org> wrote:
> We've got a 1.11.0 release candidate ready and we'd like help making sure
> it's good to go.
>
> The maintenance/1.11 branch was created off commit 843b279 and tagged
> 1.11.0. James ran ./gradlew srcDistTar to create the source tarball from
> that commit. He then manually created checksum and signature files and used
> svn to upload all that to
> https://dist.apache.org/repos/dist/dev/fineract/1.11.0 . The srcDistTar
> task took a few seconds to run.
>
> We couldn't get the binaryDistTar task to succeed on his computer, so I
> ran that on mine. gradle binaryDistTar took 7min 5sec to run and
> succeeded, but confusingly threw one NoClassDefFoundError exception. I'm
> not sure if seeing this exception should block the release--please review
> the attached log snippet and let me know what you think. Note that this
> task was initially breaking for me--I also only got it to work from a very
> clean clone. I think git clean -fdx helped with that, and perhaps also
> that I manually cleaned out some gradle/maven/cargo caches I was able to
> find. I could also have just done this in a fresh container or VM but it
> seemed like overkill and if something is polluting a build I want to
> understand what and why. Anyway, James will upload the binary, its
> checksum, and signatures for same. Temporary home for these is:
>
> https://adammonsen.com/tmp/apache-fineract-1.11.0-binary.tar.gz
> https://adammonsen.com/tmp/apache-fineract-1.11.0-binary.tar.gz.sha512
>
> And here's the actual SHA-512 checksum, just in case:
> 0ebe4e13d778e5d6d56f6b472e6304c17a34ebaea67742ac968ffcde2c787559442981de453b1360eb0b7adcc78a0a1fd1c6d4a3f51ed0ee18e759bfa2546992
> . That should be one 128-character hex string (in case it got broken into
> separate lines somewhere along the way to your eyeballs).
>
> *The help I'm seeking is for PMC members to fetch and verify these
> artifacts are valid*, following "Step 9: Verify Distribution Staging"
> from the official docs (current-enough copy at
> https://fineract.apache.org/docs/current/ ) and
> https://www.apache.org/legal/release-policy.html . Additionally, my
> unofficial suggestions are currently living at
> https://github.com/meonkeys/fineract-asf-release-checklist/ (there's some
> overlap and it's a work in progress, but I've got some good ideas there).
>
> I'm working on updates to the docs to reflect what worked and didn't for
> us today.
>
> Thanks!
> -Adam
>
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by Adam Monsen <am...@mifos.org>.
We've got a 1.11.0 release candidate ready and we'd like help making sure
it's good to go.
The maintenance/1.11 branch was created off commit 843b279 and tagged
1.11.0. James ran ./gradlew srcDistTar to create the source tarball from
that commit. He then manually created checksum and signature files and used
svn to upload all that to
https://dist.apache.org/repos/dist/dev/fineract/1.11.0 . The srcDistTar
task took a few seconds to run.
We couldn't get the binaryDistTar task to succeed on his computer, so I ran
that on mine. gradle binaryDistTar took 7min 5sec to run and succeeded, but
confusingly threw one NoClassDefFoundError exception. I'm not sure if
seeing this exception should block the release--please review the attached
log snippet and let me know what you think. Note that this task was
initially breaking for me--I also only got it to work from a very clean
clone. I think git clean -fdx helped with that, and perhaps also that I
manually cleaned out some gradle/maven/cargo caches I was able to find. I
could also have just done this in a fresh container or VM but it seemed
like overkill and if something is polluting a build I want to understand
what and why. Anyway, James will upload the binary, its checksum, and
signatures for same. Temporary home for these is:
https://adammonsen.com/tmp/apache-fineract-1.11.0-binary.tar.gz
https://adammonsen.com/tmp/apache-fineract-1.11.0-binary.tar.gz.sha512
And here's the actual SHA-512 checksum, just in case:
0ebe4e13d778e5d6d56f6b472e6304c17a34ebaea67742ac968ffcde2c787559442981de453b1360eb0b7adcc78a0a1fd1c6d4a3f51ed0ee18e759bfa2546992
. That should be one 128-character hex string (in case it got broken into
separate lines somewhere along the way to your eyeballs).
*The help I'm seeking is for PMC members to fetch and verify these
artifacts are valid*, following "Step 9: Verify Distribution Staging" from
the official docs (current-enough copy at
https://fineract.apache.org/docs/current/ ) and
https://www.apache.org/legal/release-policy.html . Additionally, my
unofficial suggestions are currently living at
https://github.com/meonkeys/fineract-asf-release-checklist/ (there's some
overlap and it's a work in progress, but I've got some good ideas there).
I'm working on updates to the docs to reflect what worked and didn't for us
today.
Thanks!
-Adam
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by Adam Monsen <am...@mifos.org>.
I'll be assisting James with tech/git/svn support for the release. 👋
First to clarify, James's point about ticket hygiene and traceability
stands, but I believe we're talking about PRs, not commits?
I see 458 commits from the last release to the tip of develop (presumably
where we'll branch for v1.11 today) using:
git log --oneline 1.10.0...develop | wc
(someone please correct me if that's the wrong query)
As for PRs, I'm seeing roughly 376 using this naive query:
git log 1.10.0...develop | grep FINERACT | wc
I don't recommend specifically limiting/restricting commits.
On Thu, Feb 27, 2025 at 8:01 PM James Dailey <jd...@apache.org> wrote:
> All - Update: We are still working on this release. I anticipate looking
> for a stable checkpoint, which likely be Friday, Feb 28th at 9am PST.
>
> While I would like to have a better result, it appears that we are unable
> to use the time machine to go back and do the needful thing.
>
> We did not enforce a one ticket means one commit or one ticket means no
> more than four commits. Going forward, let's try to have the tickets
> reflect what the commit is doing.
>
> So, we have 35 tickets and 350 commits, which is not a good way to have
> traceability from tickets to commits, but at least all commits should have
> a reference (still verifying that), and we will work to provide "pretty
> good" release notes. We will also endeavor to have - this time around -
> the documentation to be generated for the release.
>
> So, please stay tuned.
>
> Again, please see below for the official notice of this upcoming
> release... I am the release manager.
>
Re: [PROPOSAL] New Release 1.11 (one point eleven)
Posted by James Dailey <jd...@apache.org>.
All - Update: We are still working on this release. I anticipate looking
for a stable checkpoint, which likely be Friday, Feb 28th at 9am PST.
While I would like to have a better result, it appears that we are unable
to use the time machine to go back and do the needful thing.
We did not enforce a one ticket means one commit or one ticket means no
more than four commits. Going forward, let's try to have the tickets
reflect what the commit is doing.
So, we have 35 tickets and 350 commits, which is not a good way to have
traceability from tickets to commits, but at least all commits should have
a reference (still verifying that), and we will work to provide "pretty
good" release notes. We will also endeavor to have - this time around -
the documentation to be generated for the release.
So, please stay tuned.
Again, please see below for the official notice of this upcoming release...
I am the release manager.
Thanks,
James
On Wed, Feb 5, 2025 at 5:18 PM James Dailey <jd...@apache.org> wrote:
> Devs - I started the release process but became aware of a blocker to that
> - so we are delayed.
> *Please help to stabilize the code base by Friday, Feb 21st.*
>
> AND, looking at the commit log and the Jira tickets, what am I to make of
> only 35 tickets in Jira (fixVersion = 1.11.0) and roughly 350 commits and
> PRs in the GitHub log?
>
> See
> https://cwiki.apache.org/confluence/display/FINERACT/1.11.0+%28Pre-+Release+work%29+-+Apache+Fineract
> .
>
> It cannot be the job of the Release Manager to make sure that the
> processes are being followed. The project needs everyone to follow good
> project hygiene so that it can be maintained and understood. Can we please
> discuss how to improve that?
>
> My starting point was "Please make sure your tickets that were closed
> between May 1st, 2024 and February 5th, 2025 (NOW) are tagged with
> FixVersion=1.11.0."
>
> But, I think the problem is probably deeper than that. Comment.
>
> James
>
>
> On Sun, Jan 26, 2025 at 6:44 PM James Dailey <jd...@apache.org> wrote:
>
>> Hello everyone,
>>
>> I am the Release Manager for this next release.
>>
>> Based on our "How to Release Apache Fineract" process documented at
>> https://cwiki.apache.org/confluence/x/DRwIB, I will create a Release
>> 1.11 branch off develop in our git repository at
>> https://github.com/apache/fineract on
>>
>> ==> FEBRUARY 5th, 2025
>>
>> The release tracking umbrella issue for tracking all activity in JIRA is
>> https://issues.apache.org/jira/browse/FINERACT-2172
>> <https://issues.apache.org/jira/browse/FINERACT-2172>
>>
>> If you have any work in progress that you would like to see included in
>> this release, please add "blocking" links to the release JIRA issue.
>>
>> I'll add that as far as I know, this is a good moment with key features
>> reaching some maturity and a lot of development happening since the release
>> 1.10.1 (which was a branch freeze around May 1, 2024). This is not a
>> request to stop development, but please be aware of the branch being
>> created on February 5th, 2025 at 1700 GMT.
>>
>> Cheers,
>> James
>>
>>