Download, listen or read on:
- YouTube: youtube.com/playlist?lis...
- Apple Podcasts: podcasts.apple.com/gb/podcast/m...
- Spotify: open.spotify.com/show/2LgoStq...
- GitHub: github.com/Minimum-Viab...
- Podcast RSS Feed: api.riverside.fm/hosting/Ryz8...

Nope. Homebrew tends to be pretty "issue light". We prefer terrible draft PRs. Happy to discuss more in an easier medium as desired.

Oh, interesting. We're also revamping our API JSON format soon so it'll be much slimmer which may help with that. There's also possibly ways we can speedup our JSON parsing that we're not doing? Our bundling our own Ruby may help...

It "amazes" you because it's not at all what I've said.

I've been maintaining Homebrew for 16 years at a very regular cadence. It is used by a lot of people. I was asked to help out with governance, twice. I did. I have shared my very informed opinions about the topics of governance and access.

Ironically it's much faster in a failure case than a success case. It "fails fast" so the success case means it needs to verify that everything in your Brewfile is installed and upgraded.

It may be that `brew bundle check --no-upgrade` speeds things up a bit.

Are you doing `brew bundle check --verbose`? That will definitely be a lot slower than `brew bundle check` should be.

If the `brew ruby` case above is still too slow: it's probably work we have to do with load order/time/lazy-loading etc. in wider Homebrew which we'd love help with!

Definitely possible to make it faster. I don't think I can personally make it much faster. Given your experience, you probably can make it a decent bit faster!

`brew ruby -e 'puts :wget.f.any_version_installed?'` is a good comparison case; it is unlikely to get any faster than that.

I have no idea to what extent this is true. I certainly don't think it justified either what was done or how it was done.

They applied time and effort and learned: so can you.

If you don't want to or don't care enough: that's totally fine!

Just don't be surprised if others don't want to implement your pet projects for you when you don't care enough to do anything beyond asking "can haz" on social media or GitHub.

Like any question like this in open source the answer is "if you're personally willing to do the work: maybe, if you're not: probably not"

I have also spoken to Marty and Joel but not Ufuk. That you now know there's additional information that you don't know and others (including me) do should make you suspicious of throwing around accusations to people who have both done more to help and know more about the situation than you.

I actively encouraged gem.coop people to fork the bundler/rubygems clients but it was not high priority for them to do so, they are primarily concerned with the gem.coop (still private repository for now it seems?) server.

We now have two competing servers and one client bundled with Ruby itself.

Things were never going back to where they were 6 months ago. There were people unwilling to reconcile on both sides. It was either "RubyCentral maintains with current maintainers", "it's handed to gem.coop which doesn't include all current maintainers" or "it's handed to a third party".

hsbt was the second most active maintainer in the last year: mikemcquaid.com/rubygems-con...

the most active was removed by mistake, when reinvited, declined to rejoin. some other most active maintainers quit rather than were evicted.

It will be interesting to see what the Gem.coop folks do now (disclaimer: I helped them with their governance process). If there's some competition for rubygems.org as a server implementation that feels like a good thing for the community overall.

Good luck to all involved on all sides.

Ruby already provides a vendored version of RubyGems and (more recently) Bundler so this seems appropriate. It also separates the "running a web service" which has guaranteed hosting costs, requires on-call, etc. from "running an open source CLI/library" which has no guaranteed costs.

I've been working on Homebrew for 16 years and leading it for some proportion of that and this all "smells" like a more sustainable long-term solution than anything we've seen happen in the last year. Some proposals sounded nicer but were not going to be acceptable to one or more sides.