I created https://github.com/apache/tooling-trusted-releases/issues/340
I have used the ATR just now to validate a draft release for Apache POI and it did some useful checks that a reviewer of a source release would benefit from. But you would still hope that that reviewer would do more checks (like run builds, read the license file, etc). And they still need to review the convenience binaries with no tooling currently available to assist in this. On Sat, 22 Nov 2025 at 12:26, PJ Fanning <[email protected]> wrote: > > I'm sure the Trusted Release tool is great but it doesn't solve many > of the problems that I highlighted. > It seems to be oriented at producing RCs, not at reviewing them. > Unless we are going to do away with reviews because the Trusted > Release checks everything for us. > > I haven't looked at the internals but does the Trusted Release tool > check jars for whether they have the license/notice/disclaimer and > check the pom for if the incubator disclaimer appears in it - or that > the license is set? > > Does it check the Docker images? > > Does it check the pypi releases? > > > On Sat, 22 Nov 2025 at 12:15, Jarek Potiuk <[email protected]> wrote: > > > > More about it here > > https://news.apache.org/foundation/entry/apache-trusted-releases-platform-begins-second-alpha > > - and anyone can sign up for Alpha 2 phase (Airflow is happily one of the > > test projects and it is going to simplify A LOT of all our verification > > phase). > > > > On Sat, Nov 22, 2025 at 12:12 PM Jarek Potiuk <[email protected]> wrote: > > > > > ATR is going to do it all for all of us https://release-test.apache.org/ > > > > > > J, > > > > > > > > > On Sat, Nov 22, 2025 at 11:23 AM PJ Fanning <[email protected]> wrote: > > > > > >> Hi everyone, > > >> > > >> The discussion on the HugeGraph release vote [1] highlights to me that > > >> having automated tools to validate the release candidates would be a > > >> good thing. > > >> > > >> I think it is fair to say that we would still require that different > > >> reviewers run the tools independently. There would probably be some > > >> benefit to having a few copies of the tools - some reviewers might > > >> prefer Java to Python or vice versa or some other language/toolset to > > >> run the checks. Even if the rulesets in the copies diverge, it could > > >> be that one has a check that is missing from the other. > > >> > > >> The idea would be to have separate tools for different jobs but maybe > > >> some way to run to them altogether. > > >> > > >> It would be useful if the tools could run the additional checks that > > >> the Incubator PMC requires when you come to validate Incubator podling > > >> RCs. > > >> > > >> I won't go into the exact rules validated for each tool but we could have > > >> * Source Release Validation - validates name and signing and checksum > > >> and license/notice being present and integrates with Apache Rat to do > > >> source header and binary file reporting - I will approach the Rat team > > >> to see if they will be amenable to having collaboration on an extended > > >> source release checker > > >> * Jar Validation - checks pom and jar itself for license and notice > > >> details - Incubator requires pom to have the disclaimer text in the > > >> description field, etc > > >> * Pypi Validation - Incubator team have requirements [2] > > >> * Docker Validation - Incubator team have requirements [2] > > >> * General Convenience Binary Tarball/Zip validation - some teams have > > >> such an archive (or more than one) that contain multiple binaries but > > >> need to have LICENSE and NOTICE > > >> * We may even need to validate the email for the vote because we > > >> regularly get teams using the wrong KEYS location and other issues > > >> like this > > >> > > >> This stuff is not going to build itself and won't be built in one go > > >> or even quickly but if we could get some volunteers together that > > >> would be great. If people could share what they might have already > > >> that would be great too. > > >> > > >> I'm sure some podlings try hard to meet the requirements but there are > > >> definitely a few that don't run all the checks. Some focus on the need > > >> to get the convenience binaries released and don't worry too much > > >> about ASF and Incubator specific requirements. > > >> > > >> What do people think about trying to pool our efforts into automating > > >> some of the checks? > > >> > > >> PJ > > >> > > >> [1] https://lists.apache.org/thread/0xnsx6w78yp2dsbfzm8p23hjm2g18x2y > > >> [2] https://incubator.apache.org/guides/distribution.html > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
