search

gelisam / frp-zoo

Comparing many FRP implementations by reimplementing the same toy app in each.
490 stars 31 forks source link

Add last commit shields. #60

Open kindaro opened 2 years ago

kindaro commented 2 years ago

An important criterion for the evaluation of a library is whether it is kept up to date. So I thought it would be good to add the badges that show when the last commit (to a repository mentioned in the description on Hackage) happened.

gelisam commented 2 years ago

Hmm, I am thorn.

One one hand, many frp libraries seem abandoned, and so I agree that it would be useful to clarify where along the actively-maintained to abandonware axis each library is located.

On the other hand, I personally find it very upsetting when people use the date of the last commit as way to evaluate that information. When I maintain a package, I put mechanisms in place (monthly CI runs) which alert me if my package no longer works with the latest version of its dependencies, including ghc. As a result, if my dependencies are stable, I don't need to make any changes, my code still works fine, but my latest commit happens to become older and older. I would even say it's an insulting metric, because it scores more highly the packages in poorly-thought ecosystems where everything breaks all the time and maintainers constantly have to update their code just to keep the existing feature set working as-is. My feelings in regard to that metric are extreme enough that I've considered writing a script which pushes no-op commits to all my repositories every day, just to game that metric!

(deep breath)

So... is there perhaps a different proxy than the last commit date we could use? I really don't want to propagate the use of that metric if I can help it.

kindaro commented 2 years ago

I understand you and I could not say it better than you have.

  1. Theoretically we can try to build each package with a range of GHC and put green dots where it builds and red dots where it does not. This would be a better proxy for a package being up to date. This means forking each package, bolting continuous integration onto it (perhaps haskell-ci can help), and writing a reporting script.

  2. We can also do some statistics on tickets — something that would amount to «are there many neglected issues and stale pull requests relative to the total flow of tickets». But this is a whole research project.

I cannot commit to either at this time.

If Hackage wanted to have something like №1 above built in, so that it would work for all packages out of the box, then it would have made sense. It is sufficient to type check the code, so the run does not have to be resource intensive. Then Hackage would provide us with those beautiful theoretical badges.

gelisam commented 2 years ago

If Hackage wanted to have something like №1 above built in, so that it would work for all packages out of the box, then it would have made sense.

Good news, Hackage actually does have this built-in! It's called Hackage Matrix Builder, and it's one of the sources of breakage I check automatically every month. It seems to be down right now for some reason, so here's a ticket which has some screenshots, to give you a flavor of what the tool looks like.