On Mon, 06 May 2019, Evan Phoenix wrote:
> Putting the additional burden on the admin team of rubygems.org
to run this
> unknown component is a hard sell.
I am a maintainer of the Jenkins project's infrastructure, so I definitely know
the feeling :)
> I'm also confused how rubygems.org
running it would solve the problems
> you've indicated, other than it wouldn't be you dealing with them. :D
> If it were written in Ruby itself and we could add it to our canonical 
app that would be a much easier sell (but still comes with
> understanding the performance implications given our reliance on fastly
> Can you tell us more?
Running the service under rubygems.org
would help address the challenges we
have depending on some third-party service run by somebody somewhere with an
undefined level of service. I don't mean to suggest that I wouldn't be dealing
with the service issues, that is not my intent. Rather I would be able to help
operate/deploy the service as part of an group which maintains other open
The thought of implementing some verison which can go into the rubygems.org
application is really an interesting idea that I had not considered before.
Really all Gradle, Maven, and any other Java-land tool which may want to
consume Ruby dependencies just needs to speak Maven formatted XMLs. Adding that
might actually be a fair bit simpler than rubygems-servlets
which can act as a caching mutable gem repo.
If the idea of teaching rubygems.org
how to emit Maven XML is agreeable, then I
can take a whack at creating a pull request. I wouldn't want to spend the time
if the idea is abhorrent to the maintainers of the rubygems.org