Hi Jarek, I think that updating the reporter tool to check for a conformant download(s) page is a great idea. I encourage you to see how to incorporate that check into the tool.
I agree with you that sending out mass mailings is probably not going to result in changes in behavior. Only targeted messages are likely to work. One challenge will be to handle projects with multiple "independent" sub-projects like db that has jdo and derby with not much in common. They have completely independent web sites. So the tool will have to be told about all of the projects. The tool also needs to handle projects like Airflow which IIUC has multiple sub-projects that share a few common download pages and scripts. Warm regards, Craig > On Nov 4, 2021, at 5:57 AM, Jarek Potiuk <ja...@potiuk.com> wrote: > > 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. Craig L Russell c...@apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
