卜部昌平のあまりreblogしないtumblr RSS

Archive

Jun
10th
Thu
permalink

Ruby 1.8.7 リリース方針まとめ

そろそろリリースするから今の方針をまとめておくよ

無保証の大前提

本音と建前を華麗に使い分けるおまえらのためにこれは建前だとあらかじめ宣言しておくけれど、 Ruby 本体がなんらかの保証を行ったことは過去にもないし将来の予定もない。おまえらの用途にあうかも (fitness for a particular purpose)、商用利用の可能性についても (merchantability)、明確に COPYING で保証しないことを記しているし、それ以外のあらゆる保証もやはりない。だから社会的責任(笑)とかも、ない。

ともかく少なくとも表面上は俺がやってるのはただのおせっかいに過ぎないことをおまえらは注意しておく必要がある。たとえば最近の俺はかなり注意深く「サポート」という単語を回避する傾向にあるけど、それはなぜかというと COPYING の範囲を逸脱する状況に陥ると俺の手に余るからだ。Ruby コアメンバーはあくまでスタンドプレーが結果としてチームワークを発生させているだけなので、最終的に各自がケツを持てることまでしかやらないしできない。そのへんをまず理解すること。

ちなみに脱線するけどサポートが必要な人は適切なコストを払えばいいんじゃないでしょうか。コミッター雇うとか。今回のリリースでも俺が隣の席の同僚に指摘されたバグの修正が実際入ってることですし。

リリースの種類と頻度

まあ以上が建前だが本音の所としてはサポートする意志というやつはある。あくまでできる範囲でだけどね。で、俺が提供できるサポートというのは何かというと、ときどき Ruby に対する修正をまとめてリリースを作るということなわけだな。

ここで「まとめて」というのがポイントで、修正がある度にリリースをしているわけではない。少なくとも現在は。これは微妙な点で、というかべつにやっても俺は困らなくて、やれと言われれば手元でスクリプトちょろっと修正するだけで対応可能なのだ。が、じゃあ一日に何十回もリリースがあるのは本当におまえらのためなのか?という疑問があるわけな。Ruby は 1.8.5 が最終的に 235 回、1.8.6 が現在 400 回以上、1.8.7 が約 300 回のコミットをこれまでやってきたわけで、これが毎回リリースされるというのは便利というよりは嫌がらせの域なんじゃないのか?というのが現在の判断である。

そういうわけで現在の俺のリリースというのは以下の二種類

  • まとめて出す普通のリリース
  • 単発で出る普通じゃないリリース

普通じゃないというのはようするに緊急度の高い修正で、有り体に言うとセキュリティ問題の対応だ。まあ本当はセキュリティって何さ?とかは本質的に難しい領域を含んでいるので、そこを考え出すとまた長い話になるわけだが、あまり実りのある議論にはならないのが目に見えているので、「俺が緊急だと思ったものが緊急です」ということにとりあえずしておく。緊急だと思う脆弱性を見つけた人は俺を説得してください。日本語でのお問い合わせは security hyphen ja at ruby hyphen lang dot org まで。

んで、おまえらが気になってるであろういつ出るかという話は、緊急時は緊急であるが故に随時としか言いようがない。これは本当に計画とか立てようなくて、出るときは出る。脆弱性の公開というのは国際協調体制なのでタイムゾーンが日本とも限らないし、当然予告もできない。まあ、諦めて。

そうじゃない普通のリリースをいつ出すかというのは、現状だと3月くらいに出そうと思い立って6月末くらいに出るシーケンスと9月くらいに思い立って12月末くらいに出るシーケンスの2パターンがあって、ようするに年 2 回。これはなぜかというのは歴史的事情によるものなので若干話が長いが、まあ事情を知ってる年寄りがちゃんと言語化して記録に残さないと散逸しちゃうから、今から書くので読め。

まず、副読本として 過去のリリース履歴を調査した結果がある ので目を通すとよいが、一見して明らかなように 12 月のリリースはかれこれ 15 年来の伝統である。これはかつてリリースが不安視されるなか 1.8.2 を 鉄の意志で出し切った ことからも明らかなように、12 月という日付はかなり重視されている。そこで 12 月の時点で形のあるものを出すというのが一つの目標として毎年あって、そこへ向けての作業が9月からの四半期だ。

その一方6月のリリースというのはなんとなく、そろそろ出しとくとよくね? という雰囲気が醸成されてきたときに出すという結果この時期になっているものだ。本来は理想を言うと 3 ヶ月に 1 回(都合年 4 回)という話が昔はあって、実際努力していたのだけれど、他はともかく 3 月にリリースを出すというのは年度末とかぶってしまうので日本で従業員やってる俺には無理があったので、早々に 3 月のリリースがドロップし、そうすると9月にリリースするのはアンバランスなので9月もドロップした。実際にリリース作業をやるとちゃんとした準備には3ヶ月くらいは欲しいところで、年 4 回リリース出すことにすると、どっかで一回破綻するともう修正不可能になってしまって、色々無理だった。すいません。俺がもう一人いて交代制にすれば多分実現可能と思われる。

というわけでまとめると現在のところ次回のリリースは今月、次々回のリリースは 12 月を予定しております、が、緊急時にはそうとも限らない。

なにをリリースするか

バグ修正です。以上。

なのだがまあ、これもねえ。バグって何さ?とか本質的に難しい領域を含んでいるため、そこを考え出すとまたしても長い話になる上に、やっぱり実りのある議論にはならない。

★「バグの定義」。俺がそうだと思うものがバグです。
  ただし、他人の同意を得られるとは限りません。知ったことか。

というのが俺の心の平穏を保つために重要だと思っています。あしからずご了承ください。

とりあえず今までのところ「卜部はバグ修正かどうかは判定しているが修正がどれだけ重要かを判定していない」という、まことに正しい批判があって、個人的にもこれはそのとおりと思う。重要なバグ修正も、重要でないバグ修正も、同じようにまとめてリリースしているだけだからな。俺の行動はある意味無差別だから、特別扱いのようなものが欲しい人からは気にくわないことも多かろう。あるいは無差別すぎてバグではないものまで取り込んでいるという主張もあるだろう。いいんじゃないですかね。おまえらには俺を批判する権利があり俺には批判をスルーする自由があるということで。

と、まあ、原理原則を唱えた上で、実務上の話をすると、やっぱり俺には本音としてはサポートする意思というものはあるわけだ。これはバグなんじゃねえのとか、これは違うんじゃねえのとか、そういうお話はいただけるととてもありがたい。お問い合わせは http colon slash slash redmine dot ruby hyphen lang dot org まで。特に見落としは相当数あるはずなのに指摘されたのは結構少ないので、そういうの見つけたらぜひおねがいします。

  1. ukar reblogged this from shyouhei
  2. suchi reblogged this from shyouhei
  3. layzie313 reblogged this from shyouhei
  4. ftnk reblogged this from shyouhei
  5. max747 reblogged this from shyouhei
  6. ekumetoteroesu reblogged this from shyouhei
  7. zunda reblogged this from shyouhei
  8. tamoot reblogged this from shyouhei
  9. arccosine reblogged this from shyouhei
  10. lugecy reblogged this from shyouhei
  11. kakutani reblogged this from shyouhei
  12. atm09td reblogged this from shyouhei
  13. shinnya reblogged this from shyouhei
  14. eban reblogged this from shyouhei
  15. tyru-tech reblogged this from shyouhei
  16. nuna reblogged this from shyouhei
  17. hsbt reblogged this from shyouhei
  18. noplans reblogged this from shyouhei
  19. shyouhei posted this