[#66126] Creation/Conversion methods/functions table for Ruby types — SASADA Koichi <ko1@...>
Hi,
5 messages
2014/11/07
[#66248] [ruby-trunk - Feature #10423] [PATCH] opt_str_lit*: avoid literal string allocations — normalperson@...
Issue #10423 has been updated by Eric Wong.
3 messages
2014/11/13
[#66595] [ruby-trunk - Bug #10557] [Open] Block not given when the argument is a string — bartosz@...
Issue #10557 has been reported by Bartosz Kopinski.
3 messages
2014/11/30
[ruby-core:66513] [Ruby - Feature #2033] Move Core Development to Git
From:
naruse@...
Date:
2014-11-27 05:07:24 UTC
List:
ruby-core #66513
Issue #2033 has been updated by Yui NARUSE. Related to misc #10547: How to move the ruby project to git added ---------------------------------------- Feature #2033: Move Core Development to Git https://bugs.ruby-lang.org/issues/2033#change-50125 * Author: Run Paint Run Run * Status: Closed * Priority: Normal * Assignee: Yuki Sonoda * Category: * Target version: ---------------------------------------- =begin Following from [ruby-core:21039], I formally propose that core development switches to Git. The obvious benefits include: * Opens Ruby development to a wider range of contributors. Ruby- and non-Ruby-based projects alike have shown a dramatic upswing in contributions after moving to Git. * Allows tickets to be handled by de facto topic branch maintainers. A contributor interested in improving documentation, for example, could review the documentation tickets, apply the relevant patches to his 'doc' branch, then propose it be merged periodically. The core team could, and should, still monitor this branch's progress, and intercede where necessary. Ultimately, development would suffer less from the current bottleneck effect, allowing contributers to play a larger role. * Complicated feature proposals would take the form of branches. This solves the current problem of patches rotting in Redmine because `rebase` and Git's superior merging capability allow the patch to be kept in step with the trunk. Further, this allows parties interested in the feature to collaborate on the branch; only submitting a pull request when they deem it mature. * Experimentation is encouraged because now anybody can branch, and contribute back that branch, with impunity. * Working with the trunk becomes more pleasurable due to Git's advanced toolset and significant performance benefits. Etcetera. I am particularly excited about the options that Git would give us to decentralize development: spreading the workload over a wider number of contributors, while still retaining the core team's vital role as gatekeepers. Redmine tickets alone suggest that the current path is not maintainable; the sooner we change our course, the easier the process will be. In the previous ruby-core thread on this matter matz's sole objection was that certain scripts exist for the SVN workflow that would need porting to Git. If this is still the case, perhaps the scripts could be posted publicly so interested parties could port them? What objections remain? =end -- https://bugs.ruby-lang.org/