Bug #5094: Supported platforms of Ruby 1.9.3

• Status: Closed
• Assignee: naruse (Yui NARUSE)
• Target version: 1.9.3
• ruby -v: -

[naruse (Yui NARUSE)]

はい、リリース前恒例！ サポートプラットフォーム決めのお時間がやって参りました。

前回は 1.9.1 リリース時だったわけですが、あれからずいぶんと経ったので、
改めてサポートするプラットフォームを決めましょう。

== これまでのあらすじ

http://redmine.ruby-lang.org/projects/ruby-19/wiki/SupportedPlatformsJa

== 決め方

サポートしたいプラットフォームがある方は宣言してください。
ただし、当該プラットフォーム固有っぽいバグがあった場合、そのチケットをアサインする事があるので、
覚悟を決めてから宣言してください。

いつでも「サポート終了！」は宣言できるので [要出典] お気軽にご応募くださいませ。

なお、1.9.3 のリリースのちょっと前あたりで一度締めとする予定です。

== 成瀬の提案

さて、前回のサポートプラットフォーム決めでいくつか反省があるので、ここに一つ提案を行います。

なお、「メンテナがいる」とは明確なプラットフォームメンテナがいるもの(mswin32など)のほかに、「日々その環境でRubyを開発しているコミッタがいるもの」を含む。

この後半を削ることを提案します。
例として、Debian はいまだに lenny 32bit が対象になってしまっています。
ようするに切るタイミングが決まらなかったという話で、
こういうのはえいやで決める人がいるべきだろうと思うわけです。

== 現在のメンテナ

ちなみに現在のメンテナは以下の通りです。

mswin32, mswin64 (Microsoft Windows):
NAKAMURA Usaku (usa)
mingw32 (Minimalist GNU for Windows):
Nobuyoshi Nakada (nobu)
IA-64 (Debian GNU/Linux):
TAKANO Mitsuhiro (takano32)
Symbian OS:
Alexander Zavorine (azov)
AIX:
Yutaka Kanemoto (kanemoto)
FreeBSD:
Akinori MUSHA (knu)
Solaris:
Naohisa Goto

逆にメンテナがいない主なプラットフォーム（と備考）は以下の通りです。

• Debian
• Ubuntu
• CentOS
• Mac OS X (LLVM絡みが微妙)
• cygwin (動かない)
• NetBSD (動く)
• OpenBSD (動かない気がする)
• DragonFlyBSD (動かない)

[usa (Usaku NAKAMURA)]

かねてからの予告どおり、mswin32とmswin64は1.9.3では私がメンテを継続します。

つか失敗したな。1.9.3が死ぬまでメンテしないといけないじゃん……。

[kanemoto (Yutaka Kanemoto)]

• ruby -v changed from 1.9.3 to -

[kanemoto (Yutaka Kanemoto)]

金本と申します。

Best Effortレベルですが、AIX環境での調査・対応は引き続き担当させていただきたいです。
よろしくお願いします。

2011年7月26日0:15 Yui NARUSE [e-mail]:
…

サポートしたいプラットフォームがある方は宣言してください。
ただし、当該プラットフォーム固有っぽいバグがあった場合、そのチケットをアサインする事があるので、
覚悟を決めてから宣言してください。

いつでも「サポート終了！」は宣言できるので [要出典] お気軽にご応募くださいませ。
--
Yutaka KANEMOTO
http://d.hatena.ne.jp/kinpoco/

[kosaki (Motohiro KOSAKI)]

逆にメンテナがいない主なプラットフォーム（と備考）は以下の通りです。

• Debian
• Ubuntu
• CentOS
• Mac OS X (LLVM絡みが微妙)
• cygwin (動かない)
• NetBSD (動く)
• OpenBSD (動かない気がする)
• DragonFlyBSD (動かない)

Best Effortレベルですが RHEL/CentOSは僕がやろうかと思っています。Rubyのひとって全員Debian使ってると
思っていたのだけど、そういうわけでもないことがだんだん分かってきたので。

[kosaki (Motohiro KOSAKI)]

== 成瀬の提案

さて、前回のサポートプラットフォーム決めでいくつか反省があるので、ここに一つ提案を行います。

なお、「メンテナがいる」とは明確なプラットフォームメンテナがいるもの(mswin32など)のほかに、「日々その環境でRubyを開発しているコミッタがいるもの」を含む。

この後半を削ることを提案します。
例として、Debian はいまだに lenny 32bit が対象になってしまっています。
ようするに切るタイミングが決まらなかったという話で、
こういうのはえいやで決める人がいるべきだろうと思うわけです。

逆に Debian 4.0 をperhapsに落とすことを提案します。Windowsのサービスパックだって要求ハードウェアのレベルが
上がったりするぐらいなんだからゆるされると思います。
Debian 4.0は「誰も確認してないけど、非互換いれてないからたぶん動きます」という状態でこれはperhaps以外の何者でもないと思います。

5 or 6はSupport or Best-effortに入れるべきだと思うのですが、誰かメンテしてる人が必要だと思います。現在 Debian使ってる人は
誰なんでしょうか？なんかみんなUbuntuに移行してしまったイメージがあるのですが。

それから、OpenSolarisはOracleの方針転換によりディストリごと消えたのでリストから削除したい。Solarisについてはメンテナが
いるけれども、約１年放置されつづけたプラットフォームが先月メンテナがみつかったからサポートしてるぜ、ってのはあまりに
面の皮が厚すぎるので2.0 (1.9.4?)まではPerhapsにとどめる事を提案します。だって、1.9.3のリリースマネジメントで全然ケアしてなかったんですよ？

あと、OS X Lionはllvm-gccでは動かない事が確認できているので、llvm-gccはダメだとどこかに書きたい。絶対バグレポートを
沢山貰うので、このURLでアナウンス済みじゃー。といいたい。

[shyouhei (Shyouhei Urabe)]

卜部です

サポートとかやめましょう。無意味。どうせ俺らただのボランティアだし。
「がんばります」以上に実効性のあることは言えないでしょ。
それperhapsと何がどう違うん。

、という主張はつねづね申し上げている話であってべつに新規性はございません
が今回も一応申し上げておく次第です。言葉遊び楽しいけど、それ以上になって
ないですよ。現状は。

[naruse (Yui NARUSE)]

成瀬です。

2011年7月26日9:57 Urabe Shyouhei [e-mail]:

サポートとかやめましょう。無意味。どうせ俺らただのボランティアだし。
「がんばります」以上に実効性のあることは言えないでしょ。
それperhapsと何がどう違うん。

チケットの押し付け先があるかどうかが主たる違いです。
言い換えれば、直らないバグがあった場合に、誰かに assign された状態になるか、
Feedback/low になるかが目に見える違いですね。

、という主張はつねづね申し上げている話であってべつに新規性はございません
が今回も一応申し上げておく次第です。言葉遊び楽しいけど、それ以上になって
ないですよ。現状は。

Supported と Best Effort の違い、Perhaps と Not Supported の違いは言葉遊びの面が
大きいのは否定しませんが、メンテナの有無は最初のアクション以降を、
わたしがハンドリングするかメンテナがするかにつながるので、その辺ちょっと違います。

--
NARUSE, Yui [e-mail]

[naruse (Yui NARUSE)]

成瀬です。

2011年7月26日9:57 Urabe Shyouhei [e-mail]:

サポートとかやめましょう。無意味。どうせ俺らただのボランティアだし。
「がんばります」以上に実効性のあることは言えないでしょ。
それperhapsと何がどう違うん。

チケットの押し付け先があるかどうかが主たる違いです。
言い換えれば、直らないバグがあった場合に、誰かに assign された状態になるか、
Feedback/low になるかが目に見える違いですね。

、という主張はつねづね申し上げている話であってべつに新規性はございません
が今回も一応申し上げておく次第です。言葉遊び楽しいけど、それ以上になって
ないですよ。現状は。

Supported と Best Effort の違い、Perhaps と Not Supported の違いは言葉遊びの面が
大きいのは否定しませんが、メンテナの有無は最初のアクション以降を、
わたしがハンドリングするかメンテナがするかにつながるので、その辺ちょっと違います。

--
NARUSE, Yui [e-mail]

[naruse (Yui NARUSE)]

2011年7月26日8:45 KOSAKI Motohiro [e-mail]:

逆に Debian 4.0 をperhapsに落とすことを提案します。Windowsのサービスパックだって要求ハードウェアのレベルが
上がったりするぐらいなんだからゆるされると思います。
Debian 4.0は「誰も確認してないけど、非互換いれてないからたぶん動きます」という状態でこれはperhaps以外の何者でもないと思います。

5 or 6はSupport or Best-effortに入れるべきだと思うのですが、誰かメンテしてる人が必要だと思います。現在 Debian使ってる人は
誰なんでしょうか？なんかみんなUbuntuに移行してしまったイメージがあるのですが。

それは Debian のメンテナが決めることだと思います。
なお、どのバージョンをサポートしているか曖昧なプラットフォームも多いので、
Debian もそうした形になる可能性はありますね。

それから、OpenSolarisはOracleの方針転換によりディストリごと消えたのでリストから削除したい。Solarisについてはメンテナが
いるけれども、約１年放置されつづけたプラットフォームが先月メンテナがみつかったからサポートしてるぜ、ってのはあまりに
面の皮が厚すぎるので2.0 (1.9.4?)まではPerhapsにとどめる事を提案します。だって、1.9.3のリリースマネジメントで全然ケアしてなかったんですよ？

Best Effort/Perhaps は、がんばります/がんばりません の違いなので、
install すらできないとかでない限りいいんじゃないですかねぇ。
で、Solaris は現状そこまでボロボロではないと理解しています。
まぁ、この辺もメンテナの判断かと思います。

あと、OS X Lionはllvm-gccでは動かない事が確認できているので、llvm-gccはダメだとどこかに書きたい。絶対バグレポートを
沢山貰うので、このURLでアナウンス済みじゃー。といいたい。

Supported Platforms のページに動かないことが確認されていてかつやる気のない環境の
リストでも作ればいいんですかね、というわけでとりあえず書いてみました。

http://redmine.ruby-lang.org/projects/ruby-19/wiki/SupportedPlatformsJa

--
NARUSE, Yui [e-mail]

[naruse (Yui NARUSE)]

2011年7月26日8:45 KOSAKI Motohiro [e-mail]:

逆に Debian 4.0 をperhapsに落とすことを提案します。Windowsのサービスパックだって要求ハードウェアのレベルが
上がったりするぐらいなんだからゆるされると思います。
Debian 4.0は「誰も確認してないけど、非互換いれてないからたぶん動きます」という状態でこれはperhaps以外の何者でもないと思います。

5 or 6はSupport or Best-effortに入れるべきだと思うのですが、誰かメンテしてる人が必要だと思います。現在 Debian使ってる人は
誰なんでしょうか？なんかみんなUbuntuに移行してしまったイメージがあるのですが。

それは Debian のメンテナが決めることだと思います。
なお、どのバージョンをサポートしているか曖昧なプラットフォームも多いので、
Debian もそうした形になる可能性はありますね。

それから、OpenSolarisはOracleの方針転換によりディストリごと消えたのでリストから削除したい。Solarisについてはメンテナが
いるけれども、約１年放置されつづけたプラットフォームが先月メンテナがみつかったからサポートしてるぜ、ってのはあまりに
面の皮が厚すぎるので2.0 (1.9.4?)まではPerhapsにとどめる事を提案します。だって、1.9.3のリリースマネジメントで全然ケアしてなかったんですよ？

Best Effort/Perhaps は、がんばります/がんばりません の違いなので、
install すらできないとかでない限りいいんじゃないですかねぇ。
で、Solaris は現状そこまでボロボロではないと理解しています。
まぁ、この辺もメンテナの判断かと思います。

あと、OS X Lionはllvm-gccでは動かない事が確認できているので、llvm-gccはダメだとどこかに書きたい。絶対バグレポートを
沢山貰うので、このURLでアナウンス済みじゃー。といいたい。

Supported Platforms のページに動かないことが確認されていてかつやる気のない環境の
リストでも作ればいいんですかね、というわけでとりあえず書いてみました。

http://redmine.ruby-lang.org/projects/ruby-19/wiki/SupportedPlatformsJa

--
NARUSE, Yui [e-mail]

[mrkn (Kenta Murata)]

Yui NARUSE wrote:

• Mac OS X (LLVM絡みが微妙)

引き取ります。
そして、1.9.3, 1.9.2, 1.8.7 は llvm-gcc には非対応であると公式アナウンスしましょう。

と言いつつも、まだ chkbuild を復活できていないのですが・・・

些細な疑問ですが、このスレは日本語でいいの？

[mrkn (Kenta Murata)]

あ、今見たら8分前に英語版が追加されている・・・

[mame (Yusuke Endoh)]

遠藤です。

2011年7月26日9:57 Urabe Shyouhei [e-mail]:

サポートとかやめましょう。無意味。どうせ俺らただのボランティアだし。
「がんばります」以上に実効性のあることは言えないでしょ。
それperhapsと何がどう違うん。

サポートプランは「この環境でテストが動かないならリリースできない」
という基準として、1.9.2 リリースの際は重宝しましたよ。
best effort 以下の違いはあんまりなかった気もしますが。

ただそれは、「サポートプラン」とか "supported" とか "best effort"
とかいう語感からユーザが期待するものとは確かに違うんですよね。
名前が悪いから「言葉遊び」と感じるんじゃないかと思います。
もっといい名前があれば変えるといいと思います。まさに言葉遊びですが。

--
Yusuke Endoh [e-mail]

[mame (Yusuke Endoh)]

遠藤です。

2011年7月26日9:57 Urabe Shyouhei [e-mail]:

サポートとかやめましょう。無意味。どうせ俺らただのボランティアだし。
「がんばります」以上に実効性のあることは言えないでしょ。
それperhapsと何がどう違うん。

サポートプランは「この環境でテストが動かないならリリースできない」
という基準として、1.9.2 リリースの際は重宝しましたよ。
best effort 以下の違いはあんまりなかった気もしますが。

ただそれは、「サポートプラン」とか "supported" とか "best effort"
とかいう語感からユーザが期待するものとは確かに違うんですよね。
名前が悪いから「言葉遊び」と感じるんじゃないかと思います。
もっといい名前があれば変えるといいと思います。まさに言葉遊びですが。

--
Yusuke Endoh [e-mail]

[naruse (Yui NARUSE)]

(2011/07/26 12:38), Yusuke ENDOH wrote:

ただそれは、「サポートプラン」とか "supported" とか "best effort"
とかいう語感からユーザが期待するものとは確かに違うんですよね。
名前が悪いから「言葉遊び」と感じるんじゃないかと思います。
もっといい名前があれば変えるといいと思います。まさに言葉遊びですが。

わたしは Support Level 1 とか Tier 1 とか、単体では意味のわからない名前派ですね
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html

NetBSD の以下のような三段階はわかりやすいかなって気はしてますが
http://www.netbsd.org/ports/
(I) まじめにがんばる
(II) てきとうにがんばる
(III) だめぽ

というような基準だと以下のような感じですか
== CPU
i386: I
x64: I
arm: II
pcc: II
sparc:II

== コンパイラ
gcc: I
VC6: II?
VC7,8,9: II
VC10: I
clang: II
llvm-gcc: III

--
NARUSE, Yui [e-mail]

[naruse (Yui NARUSE)]

(2011/07/26 12:38), Yusuke ENDOH wrote:

ただそれは、「サポートプラン」とか "supported" とか "best effort"
とかいう語感からユーザが期待するものとは確かに違うんですよね。
名前が悪いから「言葉遊び」と感じるんじゃないかと思います。
もっといい名前があれば変えるといいと思います。まさに言葉遊びですが。

わたしは Support Level 1 とか Tier 1 とか、単体では意味のわからない名前派ですね
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html

NetBSD の以下のような三段階はわかりやすいかなって気はしてますが
http://www.netbsd.org/ports/
(I) まじめにがんばる
(II) てきとうにがんばる
(III) だめぽ

というような基準だと以下のような感じですか
== CPU
i386: I
x64: I
arm: II
pcc: II
sparc:II

== コンパイラ
gcc: I
VC6: II?
VC7,8,9: II
VC10: I
clang: II
llvm-gcc: III

--
NARUSE, Yui [e-mail]

[shyouhei (Shyouhei Urabe)]

(07/26/2011 12:38 PM), Yusuke ENDOH wrote:

遠藤です。

2011年7月26日9:57 Urabe Shyouhei [e-mail]:

サポートとかやめましょう。無意味。どうせ俺らただのボランティアだし。
「がんばります」以上に実効性のあることは言えないでしょ。
それperhapsと何がどう違うん。

サポートプランは「この環境でテストが動かないならリリースできない」
という基準として、1.9.2 リリースの際は重宝しましたよ。
best effort 以下の違いはあんまりなかった気もしますが。

べつにどこで動かなかろうが関係ないって言ってリリースすりゃよかったんですよ。

、というのも私は前から言ってる話なので新規性はございませんが。なん
でしょうね、なぜ、たとえばDebianで動かなければリリースできないのか?
とかちょっと自覚的になってみてはどうでしょう。

個人的な結論としてはリリースは「したいからする」ものであって、それ
以上の理由をつけるのはおためごかしだなあと思っている次第ですので、
そりゃ、世に出す以上はよいものを出したいのは私もよーく共感しますけ
ども、いまだかつて完璧なリリースなどあった試しもなく、結局、どの水
準で妥協かって話にしかならないし、なら、水準を満たす努力をするより
も、とっとと出しちゃったほうがいいと思うんですよね。Macで動かないと
かSolarisで動かないとかとかに責任持つべきなのはAppleとかOracleなわ
けで、それをポートメンテナに押し付けて「動くまでリリースしません」
みたいに言うのは、違うと思う。努力の方向を間違えている。

[shyouhei (Shyouhei Urabe)]

(07/26/2011 12:38 PM), Yusuke ENDOH wrote:

遠藤です。

2011年7月26日9:57 Urabe Shyouhei [e-mail]:

サポートとかやめましょう。無意味。どうせ俺らただのボランティアだし。
「がんばります」以上に実効性のあることは言えないでしょ。
それperhapsと何がどう違うん。

サポートプランは「この環境でテストが動かないならリリースできない」
という基準として、1.9.2 リリースの際は重宝しましたよ。
best effort 以下の違いはあんまりなかった気もしますが。

べつにどこで動かなかろうが関係ないって言ってリリースすりゃよかったんですよ。

、というのも私は前から言ってる話なので新規性はございませんが。なん
でしょうね、なぜ、たとえばDebianで動かなければリリースできないのか?
とかちょっと自覚的になってみてはどうでしょう。

個人的な結論としてはリリースは「したいからする」ものであって、それ
以上の理由をつけるのはおためごかしだなあと思っている次第ですので、
そりゃ、世に出す以上はよいものを出したいのは私もよーく共感しますけ
ども、いまだかつて完璧なリリースなどあった試しもなく、結局、どの水
準で妥協かって話にしかならないし、なら、水準を満たす努力をするより
も、とっとと出しちゃったほうがいいと思うんですよね。Macで動かないと
かSolarisで動かないとかとかに責任持つべきなのはAppleとかOracleなわ
けで、それをポートメンテナに押し付けて「動くまでリリースしません」
みたいに言うのは、違うと思う。努力の方向を間違えている。

[mame (Yusuke Endoh)]

遠藤です。

2011年7月26日20:49 Urabe Shyouhei [e-mail]:

個人的な結論としてはリリースは「したいからする」ものであって、それ
以上の理由をつけるのはおためごかしだなあと思っている次第ですので、

おためごかし = 表面は人のためにするように見せかけて、実は自分の利益を図ること。

よく意味がわかりませんでした。自分の利益？
自己満足ってことかな。ボランティアでのリリースって自己満足ですよね。

そりゃ、世に出す以上はよいものを出したいのは私もよーく共感しますけ
ども、いまだかつて完璧なリリースなどあった試しもなく、結局、どの水
準で妥協かって話にしかならないし、なら、水準を満たす努力をするより
も、とっとと出しちゃったほうがいいと思うんですよね。

「完璧なリリース」or「バグバグリリース」の 2 択なんでしょうか。
「これこれのプラットフォームでここまで動くこと」というのはそれなりに
いい妥協点だと思うんですが。

というか、全くルール無しだとリリースのやりがいがないと思う。
何事もルールがあるから面白い。

Macで動かないと
かSolarisで動かないとかとかに責任持つべきなのはAppleとかOracleなわ
けで、それをポートメンテナに押し付けて「動くまでリリースしません」
みたいに言うのは、違うと思う。努力の方向を間違えている。

そういう考えもあるかなとは思いますが、どういう努力が正しいと思います？

--
Yusuke Endoh [e-mail]

[mame (Yusuke Endoh)]

遠藤です。

2011年7月26日20:49 Urabe Shyouhei [e-mail]:

個人的な結論としてはリリースは「したいからする」ものであって、それ
以上の理由をつけるのはおためごかしだなあと思っている次第ですので、

おためごかし = 表面は人のためにするように見せかけて、実は自分の利益を図ること。

よく意味がわかりませんでした。自分の利益？
自己満足ってことかな。ボランティアでのリリースって自己満足ですよね。

そりゃ、世に出す以上はよいものを出したいのは私もよーく共感しますけ
ども、いまだかつて完璧なリリースなどあった試しもなく、結局、どの水
準で妥協かって話にしかならないし、なら、水準を満たす努力をするより
も、とっとと出しちゃったほうがいいと思うんですよね。

「完璧なリリース」or「バグバグリリース」の 2 択なんでしょうか。
「これこれのプラットフォームでここまで動くこと」というのはそれなりに
いい妥協点だと思うんですが。

というか、全くルール無しだとリリースのやりがいがないと思う。
何事もルールがあるから面白い。

Macで動かないと
かSolarisで動かないとかとかに責任持つべきなのはAppleとかOracleなわ
けで、それをポートメンテナに押し付けて「動くまでリリースしません」
みたいに言うのは、違うと思う。努力の方向を間違えている。

そういう考えもあるかなとは思いますが、どういう努力が正しいと思います？

--
Yusuke Endoh [e-mail]

[mame (Yusuke Endoh)]

遠藤です。

2011年7月26日19:48 NARUSE, Yui [e-mail]:

(2011/07/26 12:38), Yusuke ENDOH wrote:

ただそれは、「サポートプラン」とか "supported" とか "best effort"
とかいう語感からユーザが期待するものとは確かに違うんですよね。
名前が悪いから「言葉遊び」と感じるんじゃないかと思います。
もっといい名前があれば変えるといいと思います。まさに言葉遊びですが。

わたしは Support Level 1 とか Tier 1 とか、単体では意味のわからない名前派ですね

それなら言葉がひとり歩きしなくていいですね。賛成。

私が考えていたのは、"Tested Platforms" です。

Well Tested: リリースパッケージの make check が 0F0E
Tested: リリースパッケージの make check が完走し、F+E が 30 以下
Not Tested: それ以外

みたいな。客観的に判定できるのがいいですよね。

プラットフォームメンテナとサポートプラン (?) を結びつけて考えるのが
いいのかな。「そのプラットホームは非サポートです」と言えるのがいい？

--
Yusuke Endoh [e-mail]

[mame (Yusuke Endoh)]

遠藤です。

2011年7月26日19:48 NARUSE, Yui [e-mail]:

(2011/07/26 12:38), Yusuke ENDOH wrote:

ただそれは、「サポートプラン」とか "supported" とか "best effort"
とかいう語感からユーザが期待するものとは確かに違うんですよね。
名前が悪いから「言葉遊び」と感じるんじゃないかと思います。
もっといい名前があれば変えるといいと思います。まさに言葉遊びですが。

わたしは Support Level 1 とか Tier 1 とか、単体では意味のわからない名前派ですね

それなら言葉がひとり歩きしなくていいですね。賛成。

私が考えていたのは、"Tested Platforms" です。

Well Tested: リリースパッケージの make check が 0F0E
Tested: リリースパッケージの make check が完走し、F+E が 30 以下
Not Tested: それ以外

みたいな。客観的に判定できるのがいいですよね。

プラットフォームメンテナとサポートプラン (?) を結びつけて考えるのが
いいのかな。「そのプラットホームは非サポートです」と言えるのがいい？

--
Yusuke Endoh [e-mail]

[shyouhei (Shyouhei Urabe)]

卜部で、前回のメールに書き忘れたことがあったとすれば、べつに192のク
オリティに不満があったとかでは全然なくて、えんどうさんは偉い。そこ
は書き漏らすべきではありませんでした。えんどうさんには感謝してます。

(07/26/2011 09:07 PM), Yusuke ENDOH wrote:

2011年7月26日20:49 Urabe Shyouhei [e-mail]:

個人的な結論としてはリリースは「したいからする」ものであって、それ
以上の理由をつけるのはおためごかしだなあと思っている次第ですので、

おためごかし = 表面は人のためにするように見せかけて、実は自分の利益を図ること。

よく意味がわかりませんでした。自分の利益？
自己満足ってことかな。ボランティアでのリリースって自己満足ですよね。

そうです。まさにそのとおり。

で、自己満足とサポートってのはあんまり馴染まない概念だろうと思います。

Macで動かないと
かSolarisで動かないとかとかに責任持つべきなのはAppleとかOracleなわ
けで、それをポートメンテナに押し付けて「動くまでリリースしません」
みたいに言うのは、違うと思う。努力の方向を間違えている。

そういう考えもあるかなとは思いますが、どういう努力が正しいと思います？

努力しないのが正しいと思います。もっというと、努力「を必要としない」
べき。努力しないとリリースできないような状況は、ゆがんでいる。

努力自体は、しちゃったものを否定するほどじゃないと思いますが、それ
がないと回らないようになっちゃってるのはおかしいです。てかえんどう
さんも192やってみてお分かりかと思いますが、リリースってすごい負担
かかりますよね。ただでさえ。それを、制度化して負担から逃れられない
ような方向に持っていくのは違うと思いませんか? プログラマなんだから
ちょっと鬱にかかって半年くらい何もできなくなるとか、誰にでも起こり
うる話でしょ? そんとき、たまたまリリースが重なってたら? 努力しない
とリリースできなかったら? たぶん、辛いだけの結果になる気がしますよ。

どうせ自己満足なんだから楽して満足する方向に持っていきましょうよ。

[shyouhei (Shyouhei Urabe)]

卜部で、前回のメールに書き忘れたことがあったとすれば、べつに192のク
オリティに不満があったとかでは全然なくて、えんどうさんは偉い。そこ
は書き漏らすべきではありませんでした。えんどうさんには感謝してます。

(07/26/2011 09:07 PM), Yusuke ENDOH wrote:

2011年7月26日20:49 Urabe Shyouhei [e-mail]:

個人的な結論としてはリリースは「したいからする」ものであって、それ
以上の理由をつけるのはおためごかしだなあと思っている次第ですので、

おためごかし = 表面は人のためにするように見せかけて、実は自分の利益を図ること。

よく意味がわかりませんでした。自分の利益？
自己満足ってことかな。ボランティアでのリリースって自己満足ですよね。

そうです。まさにそのとおり。

で、自己満足とサポートってのはあんまり馴染まない概念だろうと思います。

Macで動かないと
かSolarisで動かないとかとかに責任持つべきなのはAppleとかOracleなわ
けで、それをポートメンテナに押し付けて「動くまでリリースしません」
みたいに言うのは、違うと思う。努力の方向を間違えている。

そういう考えもあるかなとは思いますが、どういう努力が正しいと思います？

努力しないのが正しいと思います。もっというと、努力「を必要としない」
べき。努力しないとリリースできないような状況は、ゆがんでいる。

努力自体は、しちゃったものを否定するほどじゃないと思いますが、それ
がないと回らないようになっちゃってるのはおかしいです。てかえんどう
さんも192やってみてお分かりかと思いますが、リリースってすごい負担
かかりますよね。ただでさえ。それを、制度化して負担から逃れられない
ような方向に持っていくのは違うと思いませんか? プログラマなんだから
ちょっと鬱にかかって半年くらい何もできなくなるとか、誰にでも起こり
うる話でしょ? そんとき、たまたまリリースが重なってたら? 努力しない
とリリースできなかったら? たぶん、辛いだけの結果になる気がしますよ。

どうせ自己満足なんだから楽して満足する方向に持っていきましょうよ。

[mame (Yusuke Endoh)]

遠藤です。

2011年7月26日21:56 Urabe Shyouhei [e-mail]:

(07/26/2011 09:07 PM), Yusuke ENDOH wrote:

自己満足ってことかな。ボランティアでのリリースって自己満足ですよね。

そうです。まさにそのとおり。

で、自己満足とサポートってのはあんまり馴染まない概念だろうと思います。

粛々とパッケージ化して ftp サーバに置くだけの作業では、自己満足は
得られないと思うんですよね。しかもそれがバグバグで批判されたら、
モチベーションだだ下がりの悪循環かと。かつての matz のように。

なので、適度な基準を定めるのは自己満足のためでもあると思うのです。

ただ 1.9.2 のときは、さすがにきつすぎた気はしてます。チケット残数 0
とか言いましたからね。結局「優先度 Normal 以上のチケットは 0」に下方
修正しましたが、それでもハードル高すぎた。

制度化して負担から逃れられない
ような方向に持っていくのは違うと思いませんか? プログラマなんだから
ちょっと鬱にかかって半年くらい何もできなくなるとか、誰にでも起こり
うる話でしょ? そんとき、たまたまリリースが重なってたら? 努力しない
とリリースできなかったら? たぶん、辛いだけの結果になる気がしますよ。

うーん。他の人がやればいいんじゃないですかね。

ただ、「制度化」する必要はない、というのは賛成かも。
「このパッケージは以下のプラットフォームでテストが通ることを確認して
います」というリストさえつければいいと思う。
その後のサポートなんて知らないし、実際やられてる気がしないし、パッチ
リリースも期間あきまくりでいい加減ですよね。
ということで [ruby-dev:44242] の提案につながります。

今決めてるのを「1.9.3 がテストをパス しなければならない プラット
フォーム一覧」と考えるのではなく、「パス させたい プラットフォーム
一覧」と考えて、ダメなら最終リストから削ればいいのではないかしら。

成瀬さんのいうチケットの割り振り先 (プラットフォームメンテナ) は別に
考えればいいと思う。

--
Yusuke Endoh [e-mail]

[mame (Yusuke Endoh)]

遠藤です。

2011年7月26日21:56 Urabe Shyouhei [e-mail]:

(07/26/2011 09:07 PM), Yusuke ENDOH wrote:

自己満足ってことかな。ボランティアでのリリースって自己満足ですよね。

そうです。まさにそのとおり。

で、自己満足とサポートってのはあんまり馴染まない概念だろうと思います。

粛々とパッケージ化して ftp サーバに置くだけの作業では、自己満足は
得られないと思うんですよね。しかもそれがバグバグで批判されたら、
モチベーションだだ下がりの悪循環かと。かつての matz のように。

なので、適度な基準を定めるのは自己満足のためでもあると思うのです。

ただ 1.9.2 のときは、さすがにきつすぎた気はしてます。チケット残数 0
とか言いましたからね。結局「優先度 Normal 以上のチケットは 0」に下方
修正しましたが、それでもハードル高すぎた。

制度化して負担から逃れられない
ような方向に持っていくのは違うと思いませんか? プログラマなんだから
ちょっと鬱にかかって半年くらい何もできなくなるとか、誰にでも起こり
うる話でしょ? そんとき、たまたまリリースが重なってたら? 努力しない
とリリースできなかったら? たぶん、辛いだけの結果になる気がしますよ。

うーん。他の人がやればいいんじゃないですかね。

ただ、「制度化」する必要はない、というのは賛成かも。
「このパッケージは以下のプラットフォームでテストが通ることを確認して
います」というリストさえつければいいと思う。
その後のサポートなんて知らないし、実際やられてる気がしないし、パッチ
リリースも期間あきまくりでいい加減ですよね。
ということで [ruby-dev:44242] の提案につながります。

今決めてるのを「1.9.3 がテストをパス しなければならない プラット
フォーム一覧」と考えるのではなく、「パス させたい プラットフォーム
一覧」と考えて、ダメなら最終リストから削ればいいのではないかしら。

成瀬さんのいうチケットの割り振り先 (プラットフォームメンテナ) は別に
考えればいいと思う。

--
Yusuke Endoh [e-mail]

[naruse (Yui NARUSE)]

2011年7月26日22:39 Yusuke ENDOH [e-mail]:

今決めてるのを「1.9.3 がテストをパス しなければならない プラット
フォーム一覧」と考えるのではなく

わたしはそんなことは一言も言ってませんよ。

「パス させたい プラットフォーム
一覧」と考えて、ダメなら最終リストから削ればいいのではないかしら。

今決めているのは Best Effort のつもりです。
それは遠藤さんのいう「パス させたい プラットフォーム一覧」でしょう。
で、そのようなプラットフォームの例は 1.9.2 では IA64 とかがあります。

成瀬さんのいうチケットの割り振り先 (プラットフォームメンテナ) は別に
考えればいいと思う。

Best Effort にはメンテナが必須なんで、という現在の定義での話と、
わたしのニーズとの2つの理由からメンテナは考える必要があるんじゃないですかね。

--
NARUSE, Yui [e-mail]

[naruse (Yui NARUSE)]

2011年7月26日22:39 Yusuke ENDOH [e-mail]:

今決めてるのを「1.9.3 がテストをパス しなければならない プラット
フォーム一覧」と考えるのではなく

わたしはそんなことは一言も言ってませんよ。

「パス させたい プラットフォーム
一覧」と考えて、ダメなら最終リストから削ればいいのではないかしら。

今決めているのは Best Effort のつもりです。
それは遠藤さんのいう「パス させたい プラットフォーム一覧」でしょう。
で、そのようなプラットフォームの例は 1.9.2 では IA64 とかがあります。

成瀬さんのいうチケットの割り振り先 (プラットフォームメンテナ) は別に
考えればいいと思う。

Best Effort にはメンテナが必須なんで、という現在の定義での話と、
わたしのニーズとの2つの理由からメンテナは考える必要があるんじゃないですかね。

--
NARUSE, Yui [e-mail]

[mame (Yusuke Endoh)]

2011年7月27日10:20 NARUSE, Yui [e-mail]:

「パス させたい プラットフォーム
一覧」と考えて、ダメなら最終リストから削ればいいのではないかしら。

今決めているのは Best Effort のつもりです。
それは遠藤さんのいう「パス させたい プラットフォーム一覧」でしょう。

いえ、違います。今 Best Effort であると決める、ということは、
そのプラットフォームをリリース時までに「make test-allがある程度
通るが恒常的なエラーも残っている」状態にまで持っていく (すでに
そういう状態になっている場合は、リリース時まで維持する) ことを
決定するということです。

そうでないなら、「今決めてるのは Best Effort 候補であって、今後
状態次第では外れることも十分ありうる」とコンセンサスをとっといた
方がいいですね。少なくとも私はそうは思ってなかったです。

成瀬さんのいうチケットの割り振り先 (プラットフォームメンテナ) は別に
考えればいいと思う。

Best Effort にはメンテナが必須なんで、という現在の定義での話と、
わたしのニーズとの2つの理由からメンテナは考える必要があるんじゃないですかね。

今はプラットフォームメンテナだけ決めておいて、リリースの直前に
なったときの各プラットフォームでの状態を見て、「動作確認済みの
プラットフォーム一覧」にいれるかどうか決めたらいいのでは。

--
Yusuke Endoh [e-mail]

[mame (Yusuke Endoh)]

2011年7月27日10:20 NARUSE, Yui [e-mail]:

「パス させたい プラットフォーム
一覧」と考えて、ダメなら最終リストから削ればいいのではないかしら。

今決めているのは Best Effort のつもりです。
それは遠藤さんのいう「パス させたい プラットフォーム一覧」でしょう。

いえ、違います。今 Best Effort であると決める、ということは、
そのプラットフォームをリリース時までに「make test-allがある程度
通るが恒常的なエラーも残っている」状態にまで持っていく (すでに
そういう状態になっている場合は、リリース時まで維持する) ことを
決定するということです。

そうでないなら、「今決めてるのは Best Effort 候補であって、今後
状態次第では外れることも十分ありうる」とコンセンサスをとっといた
方がいいですね。少なくとも私はそうは思ってなかったです。

成瀬さんのいうチケットの割り振り先 (プラットフォームメンテナ) は別に
考えればいいと思う。

Best Effort にはメンテナが必須なんで、という現在の定義での話と、
わたしのニーズとの2つの理由からメンテナは考える必要があるんじゃないですかね。

今はプラットフォームメンテナだけ決めておいて、リリースの直前に
なったときの各プラットフォームでの状態を見て、「動作確認済みの
プラットフォーム一覧」にいれるかどうか決めたらいいのでは。

--
Yusuke Endoh [e-mail]

[naruse (Yui NARUSE)]

2011年7月27日12:25 Yusuke ENDOH [e-mail]:

2011年7月27日10:20 NARUSE, Yui [e-mail]:

「パス させたい プラットフォーム
一覧」と考えて、ダメなら最終リストから削ればいいのではないかしら。

今決めているのは Best Effort のつもりです。
それは遠藤さんのいう「パス させたい プラットフォーム一覧」でしょう。

いえ、違います。今 Best Effort であると決める、ということは、
そのプラットフォームをリリース時までに「make test-allがある程度
通るが恒常的なエラーも残っている」状態にまで持っていく (すでに
そういう状態になっている場合は、リリース時まで維持する) ことを
決定するということです。

そうでないなら、「今決めてるのは Best Effort 候補であって、今後
状態次第では外れることも十分ありうる」とコンセンサスをとっといた
方がいいですね。少なくとも私はそうは思ってなかったです。

最初の投稿で「なお、1.9.3 のリリースのちょっと前あたりで一度締めとする予定です」
とある通り、決まるのは1.9.3 リリースの直前であって、今は「決めている」状態です。

成瀬さんのいうチケットの割り振り先 (プラットフォームメンテナ) は別に
考えればいいと思う。

Best Effort にはメンテナが必須なんで、という現在の定義での話と、
わたしのニーズとの2つの理由からメンテナは考える必要があるんじゃないですかね。

今はプラットフォームメンテナだけ決めておいて、リリースの直前に
なったときの各プラットフォームでの状態を見て、「動作確認済みの
プラットフォーム一覧」にいれるかどうか決めたらいいのでは。

「動作確認済みのプラットフォーム一覧」にすべきという提案に対しては、
わたしは特に意見はありません。

--
NARUSE, Yui [e-mail]

[naruse (Yui NARUSE)]

2011年7月27日12:25 Yusuke ENDOH [e-mail]:

2011年7月27日10:20 NARUSE, Yui [e-mail]:

「パス させたい プラットフォーム
一覧」と考えて、ダメなら最終リストから削ればいいのではないかしら。

今決めているのは Best Effort のつもりです。
それは遠藤さんのいう「パス させたい プラットフォーム一覧」でしょう。

いえ、違います。今 Best Effort であると決める、ということは、
そのプラットフォームをリリース時までに「make test-allがある程度
通るが恒常的なエラーも残っている」状態にまで持っていく (すでに
そういう状態になっている場合は、リリース時まで維持する) ことを
決定するということです。

そうでないなら、「今決めてるのは Best Effort 候補であって、今後
状態次第では外れることも十分ありうる」とコンセンサスをとっといた
方がいいですね。少なくとも私はそうは思ってなかったです。

最初の投稿で「なお、1.9.3 のリリースのちょっと前あたりで一度締めとする予定です」
とある通り、決まるのは1.9.3 リリースの直前であって、今は「決めている」状態です。

成瀬さんのいうチケットの割り振り先 (プラットフォームメンテナ) は別に
考えればいいと思う。

Best Effort にはメンテナが必須なんで、という現在の定義での話と、
わたしのニーズとの2つの理由からメンテナは考える必要があるんじゃないですかね。

今はプラットフォームメンテナだけ決めておいて、リリースの直前に
なったときの各プラットフォームでの状態を見て、「動作確認済みの
プラットフォーム一覧」にいれるかどうか決めたらいいのでは。

「動作確認済みのプラットフォーム一覧」にすべきという提案に対しては、
わたしは特に意見はありません。

--
NARUSE, Yui [e-mail]

[naruse (Yui NARUSE)]

• Status changed from Assigned to Closed