Please note this โ> https://news.apache.org/foundation/entry/apache-trusted-releases-platform-begins-second-alpha
This is the ATR project I previously prepared. Rather than creating our own, we should piggyback on this. On Tue, Oct 21, 2025 at 7:33โฏAM Terence Monteiro <[email protected]> wrote: > Hi Adam, > > Thanks for your detailed explanation and thoughts on the release process > and verification part and process for Committers and PMC members to vote on > the release. I'm interested in discussing how we can automate and > streamline the release process. My own approach this time was instead of > using one of my existing machines, spawn a VM specifically to build > fineract. Everything I did to build and verify the release involved > commands and zero mouse clicks. So I can see a path where by documenting > these steps and writing scripts, the process can be streamlined. If you > want to schedule a call, I'm interested. > > Regards, > Terence Monteiro. > > > On Tue, Oct 21, 2025 at 5:00โฏAM Adam Monsen <[email protected]> wrote: > >> Hi Arnold, >> >> Good questions/feedback, thank you. I want to leverage your insight here >> to improve the release process. I'll go into detail for posterity. I >> imagine given your tenure on the project some of this will be review. >> >> Here's specifically what I've asked folks to do while voting on a rc >> (release candidate): >> >> 1. verify rc checksums and signatures >> 2. build Fineract from rc src artifact >> 3. run Fineract from the compiled rc bin artifact >> >> This is detailed in our docs >> <https://fineract.apache.org/docs/1.13.0/#_artifact_verification>. It >> stems from ASF release approval policy >> <https://www.apache.org/legal/release-policy.html#release-approval>: >> >> *Before casting +1 binding votes, individuals are REQUIRED to download >> all signed source code packages onto their own hardware, verify that they >> meet all requirements of ASF policy on releases as described below, >> validate all cryptographic signatures, compile as provided, and test the >> result on their own platform.* >> >> We started formalizing all this about 7 months ago -- for 1.10.1rc >> <https://lists.apache.org/thread/cs5t0ho39ktg2jxr74dqd7fg9nyfcz3k> because >> I had the exact same question you did: What does *test* mean in this >> context? >> >> First can we agree that verifying rc checksums and signatures and >> building rc src artifact are all straightforward requirements? >> >> If so, then we're back to the ambiguous: *test*. I read *test* as: *Make >> sure the binary rc artifact works*, for you, as you understand it >> should. To be painfully explicit: Anticipate someone else will download and >> run the binary once/if it is promoted to a release and do yourself what >> they'll do, taking into account known issues. Not: Repeat what we do in CI. >> We're not expecting voters do any functional testing against the rc. >> >> Hence, the new-ish "Tested: YES/NO/PARTIAL" section in rc vote emails. *It's >> my interpretation of what the ASF says its projects must do*. And I >> agree with James: "Tested" is not the right word here. "Verified" would be >> better. I'll change that. >> >> But I want to change more. >> >> *Overall I think our release process is inefficient and robust*. >> Especially when we all vote. It's one thing for a release manager to go >> through the steps and it's not hard once you get the hang of it, but I >> don't love the parts of the rc vote beyond everyone just sending their >> +1/-1. *I'm confident we can make it more efficient and just as robust*, >> still meeting ASF policy with less of, e.g., the manual rc verification we >> now do and just a more sensible release process overall. Maybe with some >> simple automation, but maybe not just that. >> >> I want to have a meeting to gather ideas to streamline releases, because >> y'all know things I don't and policy affects us all. >> >> I'm not looking forward to onboarding the next release manager. I don't >> want them to have to just repeat what I've done. I'd rather hand them >> something wonderfully improved and say "hey look how easy we made your job! >> just click RELEASE and you're good" or something like that. Heck, maybe we >> won't need a release manager at all if we judo this creatively. Plenty of >> projects ship robust releases far more often than we do. >> >> Thoughts? Wanna meet up? >> >> -Adam >> On 10/20/25 12:16, Arnold Galovics wrote: >> >> +1 from me too, but when people say "tested", do we know what kind of >> testing is supposed to happen? I feel like we just have this feeling of the >> package being tested, but in reality it cannot be considered actual >> functional verification (if that's what's supposed to happen). >> >> In my mind, functional testing is part of the pipeline and every commit >> making into the develop branch has to pass all the tests, it's a quality >> gate. Therefore by logic, whatever commit we pick for releasing is passing >> the quality gates hence no need for manual testing. What am I missing? >> >> ( original "[FINERACT] [VOTE] ๐ณ 1.13.0 for release" thread >> <https://lists.apache.org/thread/bm9cynvrvvb1mvp7pc05v1zy5zo4h0hs> ) >> >> ( original "release process improvement" thread >> <https://lists.apache.org/thread/f99mhvxg9l3wz17thmwonvgn6vyz05vq> ) >> >
