The discussion in Airflow leads to conclusion that we've been doing "cargo cult" there https://lists.apache.org/thread/wc49rx24j09r87mgs2t6vpf1rtbtr6gf -> pretty much no-one wants those releases there :D....
I am removing them now. However, there is one set of comments—which I will investigate—that can be done) - that while "release assets" (i.e. packages) is not a good idea to have them, possibly keeping release notes there (and maybe even updating them with links to ASF reelases in SVN) might be a good idea. I will see if that can be done and report here. On Sun, May 3, 2026 at 11:13 AM Jarek Potiuk <[email protected]> wrote: > > The Release MCP I’m working on now checks for this. Really nice. > > Cool :). > > Suggestion / experience sharing (Justin): I also worked on and built MCPs > first, but I found that for cases you can run as an "agentic check," SKILL > is often a much better solution ;) . You should try it out - pure English > description of what you want to do, with embedded snippets of example code > to run - and you can run them straight after checking out your repo with > agentic CLI - without installing MCP at all. Once you have it in your repo, > it will be visible as the /NNNN command (say > /check-repo-for-asf-compliance). And you will be able to give your agent > prompts like, "Check all IPMCs for compliance with ASF and print nice > report about it." - as prompted in your agent. And you can provide all > kinds of selection criteria, or focus on only one project and get more > detailed report etc. - by just prompting the agent with yor intentions. > > Both work. MCP has the drawback that you must "trust" it to install it; > SKILL will run locally without installation. > > This is what I used in "Apache Steward (to be renamed)" - > https://github.com/apache/airflow-steward/tree/main/.claude/skills - and > it works like a charm. > > You can even ask your agent to convert your MCP to SKILL to speed it up. > > J. > > > > > > > > On Sun, May 3, 2026 at 2:32 AM Justin Mclean <[email protected]> > wrote: > >> Hi, >> >> > It always also bothers me when you say "things should never happen" but >> > fail to take action to ensure it does not happen and ask people to fix >> it. >> > That sounds a bit like "I have strong opinion, but I know it does and I >> > can't do anything about - so Iit am closing a blind eye on it”, >> >> The Release MCP I’m working on now checks for this. >> >> An example question: >> Check Burr releases for compliance with ASF guidelines and policy >> >> The final output: >> >> Burr Compliance Check >> I checked Burr live against Apache dist/archive, GitHub releases, and >> Docker Hub, using the ASF Incubator distribution guidelines. >> Overall: Burr has ASF release artifacts in the Apache release system with >> signatures and SHA-512 checksums, which is good. There are a few follow-up >> compliance concerns around GitHub release pages and convenience artifacts. >> Looks OK >> • dist.apache.org is available: >> https://dist.apache.org/repos/dist/release/incubator/burr/ >> • archive.apache.org is available: >> https://archive.apache.org/dist/incubator/burr/ >> • Latest observed Apache release date: 2026-01-11 >> • Source-ish artifacts include incubating in their filenames: >> • apache-burr-0.41.0-incubating.tar.gz >> • apache-burr-0.41.0-incubating-sdist.tar.gz >> • Each observed artifact has detached .asc signatures and .sha512 >> checksums. >> • KEYS is present. >> Needs Review >> • GitHub has 30 releases at https://github.com/apache/burr/releases, >> and the tool found no visible incubation disclaimer text in those release >> bodies. The Incubator guide says GitHub releases need to include the >> incubation disclaimer. >> • Docker Hub default ASF locations were not found: >> • apache/burr returned 404 >> • apacheburr/burr returned 404 >> That is fine if Burr does not publish Docker images, but if it does, the >> image location may need a custom check. >> • The Apache dist/archive listing includes a Python wheel: >> apache_burr-0.41.0-py3-none-any.whl. As a convenience binary, it should be >> made from an IPMC-approved ASF release, follow licensing policy, and have >> signatures/hashes. It does have .asc and .sha512, but its filename does not >> include incubating, so I’d manually review whether the distribution surface >> clearly displays the incubating disclaimer. >> • Remote source archive contents were not inspected, so I could not >> confirm DISCLAIMER files inside the source archives. >> Verdict >> No hard failure from the basic ASF release-system evidence: Burr has >> release artifacts, signatures, checksums, archive presence, and incubating >> names for the source archives. >> The main compliance gap to fix or verify is GitHub release metadata: add >> the incubation disclaimer to the GitHub release descriptions, especially >> because the guide explicitly calls that out. The wheel/convenience binary >> also deserves a manual check against ASF binary distribution policy. >> >> Kind Regards, >> Justin >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
