Project

General

Profile

Actions

Feature #15605

closed

json library needs more frequent releases

Added by headius (Charles Nutter) almost 6 years ago. Updated almost 5 years ago.

Status:
Closed
Target version:
-
[ruby-core:91550]

Description

There has not been a release of the json gem since April 2017.

Unfortunately there's a long backlog of bugs and pull requests that have been sitting there, including some that prevent users from upgrading JRuby.

I think most of us who have been working on Ruby for any length of time knows that it has been difficult to get json changes released, and it's now starting to really hold back other development.

I propose that we start looking for an alternative maintainer of the library, find a way to get them push rights, and end this bottleneck.

FWIW only flori and I currently have push rights for the gem, but I do not have push rights for the repository.

Updated by headius (Charles Nutter) almost 6 years ago

There are five open pull requests relating to JRuby: https://github.com/flori/json/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+jruby

There are 26 open pull requests in total.

Updated by headius (Charles Nutter) almost 6 years ago

I want to be clear that we are very thankful for the work that flori has put in over the years. I understand people don't always have time to work on OSS, or move on to other things, but this is a critical, core Ruby standard library...we need to be able to spin versions much more frequently.

Actions #3

Updated by headius (Charles Nutter) almost 6 years ago

  • Subject changed from json library needs a more responsive maintainer to json library needs more frequent releases

Updated by shevegen (Robert A. Heiler) almost 6 years ago

I think this can be "abstracted" out in the sense of a general mechanism in place when
it comes to gems that are part of the official ruby distribution, and maintainers that
become inactive or at the least less active.

In particular when it comes to pull requests, aka code that already exists but is
not merged in, I agree completely with Charles. (Let's assume here that these
changes all work fine, without breaking stuff, just to simplify the argument.)

Perhaps a better general solution may be to allow the ruby main team to decide
who is co-owner of gems IF these gems are part of the official ruby distribution.
That way e. g. Charles or other folks (decided by core devs) could at the least
add in the patches. Alternatively things could always be forked anyway and then
merged in.

Since Charles mention it ("find a way to get them push rights"), what would be a
simple way to get others into the position to have push rights? Could that work
on rubygems/gems + rubygems.org alone or does this have to include github-hosted
code? For the latter it may be feasible to have it all under the main ruby
site on github. (Ideally of course, everything could be managed in-ruby, without
having to depend on any external source, but I also understand that github made
some feature/access simpler.)

IMO this may be something for the next developer meeting - this can happen to
other gems too, so it seems more general to me.

Edit: May fit better into "Misc" than "Bugs" per se, but it's not really that
important in which category it is.

Updated by naruse (Yui NARUSE) almost 6 years ago

You may know hsbt and I get write access to repo recently.
So for those JRuby issues, you can ask us to merge after you review it.
And also you can push gem, we can handle fix an issue and push a gem if there's a emergency.

Anyway we also worried about json.gem..

Updated by Eregon (Benoit Daloze) almost 6 years ago

Would it make sense to move the repository under the ruby organization, since it is a default gem maintained by ruby-core now?

Updated by headius (Charles Nutter) almost 6 years ago

Perhaps a better general solution may be to allow the ruby main team to decide who is co-owner of gems IF these gems are part of the official ruby distribution.

This seems like a good rule of thumb. I know we've had trouble finding maintainers for some libraries, but anything that lives as an external gem should have at least two maintainers always in case one gets pulled away. The json gem has for too long had only the one maintainer, other than partial support from JRuby team for our version of the extension.

You may know hsbt and I get write access to repo recently.

That's great! We'll ping you from the relevant PRs we need merged and we can talk about a release.

I'm not sure whether I can (or should) add naruse or hsbt as a gem pusher...but I think we need someone (other than flori) from the C side to also be able to push the gem when there's fixes.

Would it make sense to move the repository under the ruby organization, since it is a default gem maintained by ruby-core now?

I think it would be worthwhile to do this for every gem that's included as part of stdlib. The racc library has similar issues, not because of unresponsive maintainers but because nobody really wants to own it anymore. I've been trying to get some fixes in there and released too (working with tenderlove on and off this month to do that).

Updated by headius (Charles Nutter) almost 6 years ago

FWIW we did just get a json 2.2.0 release. The base problem stands, however.

Actions #9

Updated by jeremyevans0 (Jeremy Evans) over 5 years ago

  • Tracker changed from Bug to Misc
  • ruby -v deleted (all)
  • Backport deleted (2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN)

Updated by hsbt (Hiroshi SHIBATA) about 5 years ago

  • Tracker changed from Misc to Feature
  • Status changed from Open to Assigned
  • Assignee set to hsbt (Hiroshi SHIBATA)

I submit the backport changes from ruby core to flori/json at https://github.com/flori/json/pull/388

We need to bump version to ruby repository like 2.2.1 because the same version of flori/json and ruby core confuse ruby users.

I hope to merge the above pull request, bump version and cut off a new release by flori. When there is no response from flori, We should release 2.2.1 ourselves.

@headius (Charles Nutter) Can you help me for pushing json gem?

Updated by headius (Charles Nutter) about 5 years ago

I can build and push the json gem for JRuby any time. I'm on the ruby-lang slack today, just tell me what repo/branch needs to be pushed out!

Updated by hsbt (Hiroshi SHIBATA) almost 5 years ago

  • Status changed from Assigned to Closed

naruse did release json-2.3.0 from the current master branch of ruby/ruby.

We will handle the new feature of JSON with ruby/ruby repo in the future.

Updated by Eregon (Benoit Daloze) almost 5 years ago

hsbt (Hiroshi SHIBATA) wrote:

We will handle the new feature of JSON with ruby/ruby repo in the future.

I'm not sure what you mean, could you clarify?

Is it that releases of the json gem will be done from the ruby/ruby repository?

Updated by hsbt (Hiroshi SHIBATA) almost 5 years ago

s it that releases of the json gem will be done from the ruby/ruby repository?

No. We can merge commits from ruby/ruby to flori/json and release it.

Updated by byroot (Jean Boussier) almost 5 years ago

What's the status on this ?

I understand that a part of the gem is now edited from ruby/ruby, but that exclude the pure and java implementations. So this doesn't sounds like a good long term solution, and more like a temporary workaround.

If the gem needs new maintainers, I'm confident that it can be solved (I and other folks at Shopify can surely step in), but it first require a clarification on the repo and gem ownership.

Updated by Eregon (Benoit Daloze) almost 5 years ago

I tried to make a step in that direction 2 weeks ago in https://github.com/flori/json/pull/402#issuecomment-586585888
But no answer yet from flori (even on such a trivial PR).

The current maintainer doesn't answer frequently enough for such an important part of the stdlib, I believe we need additional maintainers.

Updated by byroot (Jean Boussier) almost 5 years ago

I tried to make a step in that direction 2 weeks ago

Thanks for the link, I had no idea. I suppose I'll subscribe there and wait.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0