Good, it seems people can't stand it if software just exists and does its job and doesn't get new commits each month.

I mostly care if projects don't accept bugfixes. For example "inotify feature longer works with the latest glibc release due to subtle API change" might be an easy 10 line pull request to fix.

But if the maintainer doesn't take the pull request and make a release, then the effort of fixing it is wasted, and every single user has to workaround/suffer from that bug into the future.

There are loads of projects in that state - unmerged PR's from years ago with sensible fixes, no new release, and no forks that are distributed to users.

londons_explore

I wish github and other code hosters made it easier to "just make a release".

Next to the "Download zip" button on github, they should add a "Download built .deb" and "Download built .exe" - and those buttons should work on any fork, branch, PR, etc. And they should add all the necessary build infrastructure to achieve that.

It turns out that at scale, build infrastructure is pretty cheap to run, since caching is so incredibly effective and there is only a need to rebuild a file once per (human) edit to a file or its dependencies.

_joel

Making a .deb isn't as simple as it might seem. If you want to use shared libraries, especially so. Which version of Ubuntu/Debian/Mint/... whatever are you targetting? You can tools like FPM[1] (which is awesome btw, used it for some great hacks in the past), but that won't make you .debs that are necessarily done to the debian guidelines but usable.

There are a load os SaaS companies that do that allow you to make multiple targets though, so perhaps some integrations there would work.

[1]https://github.com/jordansissel/fpm