[#105450] [Ruby master Feature#18228] Add a `timeout` option to `IO.copy_stream` — "byroot (Jean Boussier)" <noreply@...>
SXNzdWUgIzE4MjI4IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGJ5cm9vdCAoSmVhbiBCb3Vzc2llciku
11 messages
2021/09/27
[ruby-core:105308] [Ruby master Bug#18169] Local copies of gemified libraries are being released out of sync with their gems
From:
"headius (Charles Nutter)" <noreply@...>
Date:
2021-09-16 14:50:34 UTC
List:
ruby-core #105308
Issue #18169 has been updated by headius (Charles Nutter). > We should backport this changes to the upstream repo in github. Why not make the changes to the gem itself and be certain that all changes are already in the canonical repository? If it is a problem of testing in CRuby, you can release prerelease gems until the changes have stabilized, and have CRuby install those during the build. I do not see the benefit of having two repositories for every default gem and being forced to track both and sync both. It only seems to cause problems. Why is a copy of the default gems maintained in the CRuby repository? If you can explain that to me, perhaps we can come up with a better solution. > Copy the default gems from ruby_2_6 branch, don't care of versioning. We will only install the gems from released versions for the reasons I mention in the description. When we have local copies of the files, we get bug reports and pull requests against them, and they clutter up the repository with files we do not control and do not maintain. > Merge from the latest version of the default gems like fileutils-1.5.0 skipped 1.4.1+2.6 changes. Is there a listing of the supported Ruby versions for these newer gem releases? We are reluctant to use newer versions of the gems because there's no information about compatiblity. When we ship a JRuby that is compatible with 2.6.8 or 2.7.x we would prefer to ship the exact same version of the default gems. ---------------------------------------- Bug #18169: Local copies of gemified libraries are being released out of sync with their gems https://bugs.ruby-lang.org/issues/18169#change-93718 * Author: headius (Charles Nutter) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The CRuby codebase includes a number of libraries that have been gemified, more and more with each release. Unfortunately, these libraries are continually out of sync with both their home repositories and their released gems. The problem lies in the fact that CRuby keeps a local copy of these libraries within the CRuby git repository, and allows committers to make changes either in the CRuby repository or in the gem's home repository. This has led to many releases of Ruby shipping code that **does not correspond to any released version of the related gem**. I have filed several issues about this but the root cause has not been addressed: * https://github.com/ruby/ostruct/issues/11 * https://github.com/ruby/matrix/issues/12 * https://github.com/ruby/prime/issues/11 * https://github.com/ruby/webrick/issues/48 * https://github.com/ruby/rdoc/issues/835 * https://github.com/ruby/rexml/issues/79 * https://github.com/ruby/fileutils/issues/59 * https://github.com/ruby/ostruct/issues/31 If these gems are to live on their own as standalone libraries/gems then one of two things must happen: * All changes to them must go into their repositories. This would be the cleanest option. CRuby would, like JRuby, source these libraries directly from released gems, and no copies of their sources would be versioned in the CRuby git repository. OR * CRuby-local changes to these libraries must be prohibited from being released unless there is a corresponding gem release. This would require automated or manual auditing at release time, to ensure that the claimed gem version actually corresponds to the sources being shipped. In addition to making it impossible for external users of these gems to match CRuby releases, there are more serious implications: * These hybrid intra-version changes to these libraries cannot be audited to a specific gem release. This could affect stability and security when users attempt to sync their local gem sets to the ones that shipped in a given version of Ruby. * Security fixes have gone out in CRuby releases but no corresponding x.x.y or x.x.x.y security release of the gem was released. This prevents users from fixing the security issue locally without either upgrading CRuby or also including new functionality changes (which may or may not work on the current version of Ruby). See the rexml issue above for one example of the security problem. Until the gem was released, it was not possible to install any gem version with the security fix without upgrading functionality elsewhere in rexml. I believe it is time for CRuby to stop making changes to gemified libraries directly in the CRuby repository. These libraries have their own gems, repositories, and issue trackers, and that is where they should be maintained. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>