[#112457] [Ruby master Feature#19443] Cache `Process.pid` — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Issue #19443 has been reported by byroot (Jean Boussier).
16 messages
2023/02/16
[#112584] [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system — "normalperson (Eric Wong) via ruby-core" <ruby-core@...>
Issue #19465 has been reported by normalperson (Eric Wong).
9 messages
2023/02/25
[#112595] [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@...>
2023/02/25
SXNzdWUgIzE5NDY1IGhhcyBiZWVuIHVwZGF0ZWQgYnkgbm9idSAoTm9idXlvc2hpIE5ha2FkYSku
[#112613] Re: [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— Eric Wong via ruby-core <ruby-core@...>
2023/02/26
"nobu (Nobuyoshi Nakada) via ruby-core" <[email protected]> wrote:
[#112615] Re: [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— SHIBATA Hiroshi via ruby-core <ruby-core@...>
2023/02/27
MzUxMzZlMWU5YzIzMmFkN2EwMzQwN2I5OTJiMmU4NmI2ZGY0M2Y2MyBpcyBicm9rZW4gd2l0aCBg
[#112626] Re: [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— Eric Wong via ruby-core <ruby-core@...>
2023/02/28
```
[ruby-core:112276] [Ruby master Bug#18169] Local copies of gemified libraries are being released out of sync with their gems
From:
"hsbt (Hiroshi SHIBATA) via ruby-core" <ruby-core@...>
Date:
2023-02-08 06:34:44 UTC
List:
ruby-core #112276
Issue #18169 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed In Ruby 3.2, I completely sync default gems and ruby release code. But Ruby 3.1 and 3.0 are still work in progress. I'll working to fix out-of-sync statuses with @headius on each repository. ---------------------------------------- Bug #18169: Local copies of gemified libraries are being released out of sync with their gems https://bugs.ruby-lang.org/issues/18169#change-101706 * Author: headius (Charles Nutter) * Status: Closed * 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/ ______________________________________________ ruby-core mailing list -- [email protected] To unsubscribe send an email to [email protected] ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/