Yep. Those are all valid concerns and I will look into how we could handle those complexities. Hopefully there will be only a handful of various cases :D
On Sun, Nov 7, 2021 at 9:17 PM Craig Russell <apache....@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
