Things to keep in mind when committing to CRuby

Notes

** The content of this article may not be "all this". Read the community air before committing **

motivation

I wanted to commit to CRuby, but unfortunately the information is discrete and a little difficult to do. I felt that, so for those who want to commit to CRuby, this article is about summarizing information as much as possible.

Basic official information

CONTRIBUTING.md included in the source is as follows.

Please see the official issue tracker and wiki HowToContribute.

Issue tracker is a normal Redmine, and new tickets are added after registering an account. The content of HowToContribute is very simple, and when translated ... (It may become old in the future. ** Please read the content of CONTRIBUTING.md directly before posting the patch! **)

Before sending the patch --Only Ruby 2.2 can add new features. 1.9 / 2.0 / 2.1 will not accept new feature additions, and maintenance branches like 2.1 will not merge new feature additions. --Search for previous discussions in ruby-core. --Be sure to agree that your code will be distributed or modified under a Ruby license. The license may change in the future, but if you disagree with the license change, be sure to participate in the discussion.

What is requested by the patch --Most of the time you should send it to the Ruby 2.2 trunk. (Otherwise, only when sending bugfix patches for bugs that exist at the time of the maintenance branch) --Please be sure to send in unified diff format. (diff -pu is preferable. git or svn diff is also good.) --Be careful not to make any changes to the appearance of your code. (Follow the coding style of the original code) --Do not include multiple changes in one commit

How to send --Create a Redmine ticket as a Bug or Feature. Then it will be transferred to ruby-core (and ruby-dev) --Pull Request on Github is also accepted for minor corrections. However, Pull Requests that contain controversial content are simply ignored.

After sending --Tickets may be ignored in an accident. (For example, the reviewer is busy, so.) In that case, please ping with a ticket.

License --Be sure to agree that your patch will be handled under a Ruby license. Also, when you change the license, unless you object to it, we will consider that you have agreed to the license change.

Discussion on the ticket

But it's not just this information. Let's follow the contents of ruby-dev and other discussions of Redmine tickets For example, https://bugs.ruby-lang.org/issues/10032 There is such a discussion (although it is a ticket with a slight frame ...), so here

Github is ancillary --For those that require a review, it is recommended to post the patch first to Redmine, the official Issue Tracker. -(This itself is also written in HowToContribute, but reading this clearly shows that Github is ancillary.)
Maintenance of the standard attached library of Ruby is handled by the maintainer of each library. ――It's up to the maintainer what to do with the patch ――So what to do with the patch should be negotiated with the maintainer ――It is also a good idea to create a gem first to make it easier to talk. ――If the maintainer is busy, acceptance may be delayed (in the case of this ticket, it is a unit of several months or more). ――But in that case, please send a ping without worrying about it on the ticket.
I want you to contribute, not just criticize ――Everyone is volunteering, so I want them to contribute, not just criticize them. -(It is desirable to increase "hospitality".)

Etc. can be read.

There is a problem that the work is overwhelmed, it is also to get the latest atmosphere of the community, and I think that it is good to read the tickets of other patches first.

To not change the appearance

I'd like to make a correction so as not to change the coding style, If you don't read the original coding style well, you may destroy it. I sent a patch to iseq.c the other day (not accepted), but I stepped on it.

At that time, it seemed to me that the original code was a mixture of tabs and spaces, the if indent was not indented, and the function scope was indented. And I tried to match it as much as possible, but there was no common sense. The tabs should look like 8 tabs, indented every 4 spaces, but replace them with tabs when they reach 8 spaces. It was the style.

Use common sense and read the code properly. I think it can be avoided if you think about something better and act rather than obey the rules and formats strangely. (It's a Rubyist.)

Other notes

The important thing is probably hospitality. Keep in mind that everyone is a volunteer.