Impact of mass copying specs on sync process

[headius]

I am trying to wrap up the major Ruby 4.0 features in JRuby and there have been a number of spec updates over the past month I'd like to pull down. Given the strict requirements of syncing the repositories, I am not comfortable doing it myself.

What impact would it have on syncing if I were to manually copy the specs from CRuby master into my ruby-4.0 branch, which will eventually merge to JRuby's master branch?

This seems like more of a discussion, but discussions are not enabled and I did not want to be the one to enable them.

[eregon]

What impact would it have on syncing if I were to manually copy the specs from CRuby master into my ruby-4.0 branch, which will eventually merge to JRuby's master branch?

If it's done in one commit, we'd need to manually remove that commit during sync'ing, which is messy but maybe possible. It might also cause issues for future syncs.
The bigger problem is if you make changes to specs on top then, or before to those specs, then they might conflict with newer changes in ruby/spec, and then it can become a significant overhead/headache.

If it's just about one file then I would say just copy it over and make sure there haven't been changes to it since the last sync. I have done that a couple times in TruffleRuby.

Given the strict requirements of syncing the repositories, I am not comfortable doing it myself.

Since we spent quite some time to improve the docs I think it should be easier now, though it's always good to at least coordinate who syncs specs with me and @andrykonchin (can do that on the GraalVM Slack).

@andrykonchin did the last sync 3 weeks ago (jruby/jruby#9043) though, do you need something more recent?
In general as said in the README the sync happens once a month.
If you want more often then indeed it'd be nice if you share the workload to sync them.

Though for Ruby 4.0 features, the first step would be to create the tracking issue, there isn't one currently.
Feel free to do that, following the template of previous versions like #1265

[eregon]

One thought if you want to make it easier to get the latest specs in JRuby would be to make spec/ruby a git submodule again in the jruby repo. Given there isn't a huge amount of specs added in the jruby repo it might a good trade-off.

[headius]

do you need something more recent?

There have been a number of changes since 3.5 became 4.0. A rough diff copying from CRuby master to my 4.0 branch is here: https://gist.github.com/headius/0d4a5e08663176302574eada59fa7c2e

Given there isn't a huge amount of specs added in the jruby repo

We have made an effort to add more specs from the JRuby side (about 25 commits in the last six months), and we have always encouraged our users to submit spec updates when they file bugs.

make spec/ruby a git submodule again

This would not solve the problem, since I currently need updates that are only in CRuby's copy of the specs. Adding all of CRuby as a submodule would not be ideal.

If all implementations were using submodules and making spec changes directly to ruby/spec, that would solve this challenge, but I don't see that happening.

[eregon]

This would not solve the problem, since I currently need updates that are only in CRuby's copy of the specs. Adding all of CRuby as a submodule would not be ideal.

Ah true.

Concretely I plan to do the next monthly sync beginning of December or maybe end of November.
If you'd like the sync before that, then please give it a try with https://github.com/ruby/spec/wiki/Merging-specs-from-CRuby%2C-JRuby-and-TruffleRuby and let me know so I can check everything is right after.

[eregon]

Links for convenience:
#1303
ruby/ruby#15239
jruby/jruby#9081
truffleruby/truffleruby#4019

[headius]

Closing the loop...

• Doing a copy of specs over the existing ones is possible but could lead to problems when syncing (as suspected).
• I have done a full sync using the process created by @eregon and made some documentation updates as needed.

I think there's improvements possible to the syncing process, but I'll work with @eregon and @andrykonchin separately to address them.