Hi

Such an effort existe at apache, it is named creadur:
https://creadur.apache.org/

Doesn't cover 100% of the needs nor totally incubator requirements but
seems natural to contribute there from my windows since it is the goal of
the project.


Romain Manni-Bucau
@rmannibucau <https://x.com/rmannibucau> | .NET Blog
<https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old
Blog <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>
Javaccino founder (Java/.NET service - contact via linkedin)

Le sam. 22 nov. 2025, 13:23, PJ Fanning <[email protected]> a écrit :

> 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]
>
>

Reply via email to