[#100309] How to use backport custom field — Jun Aruga <jaruga@...>
Please allow my ignorance.
9 messages
2020/10/06
[#100310] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
"Backport custom field" is only available for tickets whose tracker is "Bug".
[#100311] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/06
On Tue, Oct 6, 2020 at 4:44 PM NARUSE, Yui <[email protected]> wrote:
[#100314] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
Thank you for confirmation.
[#100322] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Tue, Oct 6, 2020 at 7:25 PM NARUSE, Yui <[email protected]> wrote:
[#100326] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/07
I added you to "Reporter" role in the project
[#100327] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Wed, Oct 7, 2020 at 1:42 PM NARUSE, Yui <[email protected]> wrote:
[#100358] [BUG] ruby 2.6.6 warning with encdb.so — shiftag <shiftag@...>
Hello,
1 message
2020/10/10
[ruby-core:100613] [Ruby master Misc#16778] Should we stop vendoring default gems code?
From:
headius@...
Date:
2020-10-27 22:21:35 UTC
List:
ruby-core #100613
Issue #16778 has been updated by headius (Charles Nutter). > We can extract like matrix, prime and tracer as bundled gems from the default gems. That is not what I am looking for, nor what this issue is about. What I think we want (@deivid, me, and probably @eregon) is for the default gem sources to be removed from the CRuby repository, and instead retrieved from the released gems (ideally) or the ruby/* repositories (acceptable) so there's a *single copy of all gemified sources*. ---------------------------------------- Misc #16778: Should we stop vendoring default gems code? https://bugs.ruby-lang.org/issues/16778#change-88244 * Author: deivid (David Rodr刕uez) * Status: Rejected * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Currently ruby-core vendors all the code in default gems, and runs the tests for each of them. Also, ruby-core continuously updates the vendored code of default gems to sync with the upstream repos. That's overhead work, not only from syncronizing the code itself, but it also requires perfect syncronization of releases to avoid including versions of default gems that are different from released versions. Also, this causes confusion for contributors because the code lives "duplicated" in two different places. Some times contributors will open a PR in the ruby-core repo, only to find out that they need to go to the upstream repo and contribute it in there. And this rule is not even always followed and sometimes ruby-core contributors apply patches to the vendored code directly (many times to fix test-only issues inherent to the different structure of the core repository). These patches then need to be contributed back to the upstream repo. I believe that all of that kind of defeats the point of "gemification" of the standard library. Once some ruby code its gemified, it should be the new upstream's responsability to make sure the code works and it's properly tested, and ruby-core should be free'd from that responsability. Maybe ruby-core could do something along the following lines: * Remove all the vendored code from default gems. * When this code is needed for internal tests, manage it as a development dependency, clone it as necessary on non source controlled locations, and use it from there. * Maybe a file similar to `gems/bundled_gems` can be added for default gems indicating their versions and upstream repos, to ease things. * Upon `make install`, clone the proper version of each default library and get it installed in the default $LOAD_PATH. * Maybe add some bare high level CI checks to ensure that all default libraries can be properly required after `make install`, and that their executables (if they include any) can also be run. This should bring several benefits to the development process: * No more duplicated code. * No more syncronization from upstream to ruby-core. * No more syncronization from ruby-core to upstream. * No more confusion around the canonical place to contribute. * No more complexities derived from the different organization of the code depending on whether it lives in ruby-core or outside. I believe jruby already does something like this so it'd be interesting to get some input from them. If this is a direction the ruby-core team would like to take, I'm happy to help @hsbt with small steps towards slowly approaching to this high level goal. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>