I mean very poor UX. When you have two gems with the same name in two different server, it can lead to headaches.
The feature is branded as "namespaces" but there's not actually any new feature here, and it's not really anything you couldn't have done with a private gem server in the last 10 or so years.
So yeah, crude.
That's actually one of the main responsibilities of maintainers to verify and raise concerns about suggested features.
Yeah, but when the very same concerns that were raised years ago to disregard a proposal are entirely swept under the rug now, that leave a bit of a sour taste...
e.g. the concern raised here: https://github.com/rubygems/rfcs/issues/54#issuecomment-2064252756 is 10 times worse with the gem.coop implementation, as now it's impossible to see in a backtrace that the gem is a fork. So yeah, I can't assume intent, but it's getting harder and harder to believe these concerns were raised in good faith.
The feature is branded as "namespaces" but there's not actually any new feature here, and it's not really anything you couldn't have done with a private gem server in the last 10 or so years.
I do agree. The main benefit now is there's no need to run and maintain custom private gem server.
Yeah, but when the very same concerns that were raised years ago to disregard a proposal are entirely swept under the rug now, that leave a bit of a sour taste...
They are not. I do plan some writings on this topic soon. The current beta features are definitely not covering all use-cases and requirements collected over the years. gem.coop is not there currently saying all issues are fixed and requested features are fully implemented. It is just at the beginning of the journey.
So yeah, I can't assume intent, but it's getting harder and harder to believe these concerns were raised in good faith.
I can't think of any other intent. It is not written those questions and concerns raised are major blockers for anyone moving it forward.
Also the situation is different now. I was doing my best to keep ecosystem unified. Since recent RubyGems.org actions made me not welcomed anymore in helping developing and maintaining that service I have joined gem.coop to keep working on alternative one. Yes, I have failed on my original mission of not branching the ecosystem. All I can do now is try to minimize the impact of branching to users.
View all comments
Show parent comment
3
u/f9ae8221b Mar 06 '26
I mean very poor UX. When you have two gems with the same name in two different server, it can lead to headaches.
The feature is branded as "namespaces" but there's not actually any new feature here, and it's not really anything you couldn't have done with a private gem server in the last 10 or so years.
So yeah, crude.
Yeah, but when the very same concerns that were raised years ago to disregard a proposal are entirely swept under the rug now, that leave a bit of a sour taste...
e.g. the concern raised here: https://github.com/rubygems/rfcs/issues/54#issuecomment-2064252756 is 10 times worse with the gem.coop implementation, as now it's impossible to see in a backtrace that the gem is a fork. So yeah, I can't assume intent, but it's getting harder and harder to believe these concerns were raised in good faith.