번역 루비에 컨트리뷰트 했다.

원문: http://www.hanach.in/post/2015/01/09/contribute-to-ruby.html

태어나서 처음으로 루비를 적었다. ChangeLog에 내 이름이 올랐다. 기쁘다.

경위

Refinement근처에서 SEGV로 떨어지는 현상을 발견했다.

정월에 밑조사를 해봤더니 vm_method.c 근처에서 떨어지는 코드예를 여러개 발견해서 엉성하게 고쳐봤다. 엉성하게 고친결과, 여러 버그를 고치는 코드가 하나로 줄었다. 새해가 밝을 즈음에 패치를 보내는 것을 목표로 일단 정리했다. 각각 테스트를 적고, 버그를 고치고, 컨트리뷰트할 준비. 수요일의 Okinawa.rb의 날에 Ruby Issue Tracking System에 계정을 등록해 보고했다.

다음날, nobu님이 패치를 받아주었다. :tada:

이슈만드는 법, 패치의 작성법

구체적인 이슈만드는 법과 패치의 작성법은 시바타님의 RubyKaigi의 발표와 공식 페이지의 HowToReportJa를 참고했다. 구체적인 패치의 작성법이라던가, 이슈를 만들때 주의해야 할 점이 적혀있어 매우 참고가 돼었다.

던진 패치를 그대로 적용한것이 아니라 보다 적당한 곳으로 고쳐져있었다. 어디를 고치면 좋을지 고민스러운 경우에도 일단 던지는 것이 좋겠다고 생각했다. 그리고 ChangeLog의 문장에 추가되는 것은 매우 고맙다.

테스트를 적었다

Ruby Issue Tracking System에 보고된 버그는 ruby-core나 ruby-dev에 메일이 간다. bugs에 이슈가 만들어진 경우, 밑에 보이는 것처럼 assert의 메세지에 ruby-core의 번호와, bugs의 티켓번호를 쓰는것이 관례처럼 보였다.

bug10707 = '[ruby-core:67389] [Bug #10707]'
module RefinementBug
  refine BasicObject do
    def foo
    end
  end
end
assert(methods, bug10707)
assert_raise(NameError, bug10707) {method(:foo)}

좋았던 점

루비에 공헌했다.
짧은 코드를 실행하면 반드시 SEGV가 일어나서 문제가 쉬웠다.
- 재현되므로 패치를 적기 쉬웠다.
SEGV를 고치는것에 집중할 수 있었다.
- 루비의 구조 ^1 와 RHG를 전에 대충 읽었기 때문에, 디버그나 CRuby의 구조등, SEGV이외에 대해서도 어느정도 이해되었다.
- 가끔 CRuby의 소스를 읽었었다.
- 루비의 구조를 읽기 위해 디버그 환경을 준비해, 연습삼아 고쳐보았다.
- 비슷한 문제의 이전 bugs가 있어서 참고했다.
루비가 SEGV했을 때 디버깅을 해본 경험이 있기 때문에, 다음에 SEGV가 일어나도 무섭지 않다.

그밖에도 여러가지 일이 있었지만, gdb의 매크로가 ruby/ruby에 첨부되어있어 디버그가 편리해보여서, gdb로 디버그 할껄같은 시시한 것도 있다.

감사

아주 조금 루비를 고쳐보기에 도전했는데 힘들었다.

루비의 코어 커미터분들은 이런 버그를 보고받아 매일 고치는 것은 좀 대단하다. 보고를 받아 조사해, 패치가 있으면 패치를 보고 리뷰를 해서 적용해서…(자기가 고치는것보다 힘들지 않을까)

루비 개발자분들에의 감사하는 마음이 더욱 커졌다. 감사합니다.

루비의 구조 와 RHG 덕분에 루비의 구조를 조금 볼수 있게 됐다. 이 책이 없었으면 공헌할 수 없었을 것이다. 감사합니다.

1: 루비를 깨우치다의 일본어 판.