Hello Everyone @devcom, I am following up after the discussion at users@infra.a.o: https://lists.apache.org/thread/skswflvf0q8lbgkmxo18v19s62hkqf3j. This is not a public mailing list and maybe not everyone here is subscribed so let me summarise the context and the proposal. BTW. That's my view on the state of the discussion we had and conclusions/proposals I drew from that.
Context: We seem to have some of the projects that do not follow all the important requirements when it comes to publishing GA releases for their projects. The requirements are pretty firm and documented here: https://www.apache.org/legal/release-policy.html#host-GA and in the following paragraphs. They boil down to : a) have an installation page where you can verify releases with: * signatures and checksums (links to those should be directly do downloads.apache.org * packages - links to those should use closer.lua scripts (which are then automatically mapped to CDN currently - previously to mirroring sites) b) Have they releases archived appropriately (i.e. only last version from the development "branch" should remain in downloads@a.o Proposal: I think the best way to get this solved permanently (rather than sending reminder emails to everyone) is to add a check in the reporter tool ( https://reporter.apache.org/about.html) to verify those two aspects, so that they could be verified by projects themselves and the board - seems that this is a very important aspect that ASF is very concerned about, so making it part of the board review makes sense and gives the opportunity of individual flagging when the project does not follow it, It has happened with our project - Airflow at the last board review, and we fixed all that, but the idea is that the ASF has an easy to use tool that will add such checks and flags Point b) is quite easy it seems. Airflow already has simple Python script that does that can be adjusted or rewritten to handle multiple "lines" of development (with some per-project specifics likely) : https://github.com/apache/airflow/blob/main/dev/provider_packages/remove_old_releases.py. It can also be used to actually help with clean-up (we use it for that purpose as we have ~40/50 packages to release every month). Point a) also should not be difficult as long as each project will submit their installation page links, we can scrape them and see if the pages contain signature/ascii direct links and closer.lua links for packages. Do you think it is a good idea? I just wanted to run it by the community to see what you think of it, whether you see any potential problems/limitations/concerns? Just one request please - without yet getting into technical details and discussing HOWs. We will have time for that. If there is a community (and board :) buy-in, I am happy to implement/lead/introduce it. It would dramatically help if others - especially people from various projects that might have some special cases - could help with testing/piloting it. J.
