Project

General

Profile

Bug #5094

Supported platforms of Ruby 1.9.3

Added by naruse (Yui NARUSE) almost 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Target version:
ruby -v:
-
Backport:
[ruby-dev:44223]

Description

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

前回は 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 (動かない)

Related issues

Related to Ruby master - Feature #5097: Supported platforms of Ruby 1.9.3Closed07/26/2011Actions

History

Updated by usa (Usaku NAKAMURA) almost 8 years ago

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

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

Updated by kanemoto (Yutaka Kanemoto) almost 8 years ago

  • ruby -v changed from 1.9.3 to -

Updated by kanemoto (Yutaka Kanemoto) almost 8 years ago

金本と申します。

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

2011年7月26日0:15 Yui NARUSE naruse@airemix.jp:

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

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

Updated by kosaki (Motohiro KOSAKI) almost 8 years ago

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

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

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

Updated by kosaki (Motohiro KOSAKI) almost 8 years ago

== 成瀬の提案

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

なお、「メンテナがいる」とは明確なプラットフォームメンテナがいるもの(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についてはメンテナが
いるけれども、約1年放置されつづけたプラットフォームが先月メンテナがみつかったからサポートしてるぜ、ってのはあまりに
面の皮が厚すぎるので2.0 (1.9.4?)まではPerhapsにとどめる事を提案します。だって、1.9.3のリリースマネジメントで全然ケアしてなかったんですよ?

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

Updated by shyouhei (Shyouhei Urabe) almost 8 years ago

卜部です

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

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

Updated by naruse (Yui NARUSE) almost 8 years ago

成瀬です。

2011年7月26日9:57 Urabe Shyouhei shyouhei@ruby-lang.org:

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

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

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

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

--
NARUSE, Yui naruse@airemix.jp

Updated by naruse (Yui NARUSE) almost 8 years ago

成瀬です。

2011年7月26日9:57 Urabe Shyouhei shyouhei@ruby-lang.org:

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

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

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

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

--
NARUSE, Yui naruse@airemix.jp

Updated by naruse (Yui NARUSE) almost 8 years ago

2011年7月26日8:45 KOSAKI Motohiro kosaki.motohiro@gmail.com:

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

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

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

それから、OpenSolarisはOracleの方針転換によりディストリごと消えたのでリストから削除したい。Solarisについてはメンテナが
いるけれども、約1年放置されつづけたプラットフォームが先月メンテナがみつかったからサポートしてるぜ、ってのはあまりに
面の皮が厚すぎるので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 naruse@airemix.jp

Updated by naruse (Yui NARUSE) almost 8 years ago

2011年7月26日8:45 KOSAKI Motohiro kosaki.motohiro@gmail.com:

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

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

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

それから、OpenSolarisはOracleの方針転換によりディストリごと消えたのでリストから削除したい。Solarisについてはメンテナが
いるけれども、約1年放置されつづけたプラットフォームが先月メンテナがみつかったからサポートしてるぜ、ってのはあまりに
面の皮が厚すぎるので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 naruse@airemix.jp

Updated by mrkn (Kenta Murata) almost 8 years ago

Yui NARUSE wrote:

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

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

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

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

Updated by mrkn (Kenta Murata) almost 8 years ago

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

Updated by mame (Yusuke Endoh) almost 8 years ago

遠藤です。

2011年7月26日9:57 Urabe Shyouhei shyouhei@ruby-lang.org:

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

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

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

--
Yusuke Endoh mame@tsg.ne.jp

Updated by mame (Yusuke Endoh) almost 8 years ago

遠藤です。

2011年7月26日9:57 Urabe Shyouhei shyouhei@ruby-lang.org:

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

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

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

--
Yusuke Endoh mame@tsg.ne.jp

Updated by naruse (Yui NARUSE) almost 8 years ago

(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 naruse@airemix.jp

Updated by naruse (Yui NARUSE) almost 8 years ago

(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 naruse@airemix.jp

Updated by shyouhei (Shyouhei Urabe) almost 8 years ago

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

遠藤です。

2011年7月26日9:57 Urabe Shyouhei shyouhei@ruby-lang.org:

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

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

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

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

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

Updated by shyouhei (Shyouhei Urabe) almost 8 years ago

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

遠藤です。

2011年7月26日9:57 Urabe Shyouhei shyouhei@ruby-lang.org:

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

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

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

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

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

Updated by mame (Yusuke Endoh) almost 8 years ago

遠藤です。

2011年7月26日20:49 Urabe Shyouhei shyouhei@ruby-lang.org:

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

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

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

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

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

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

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

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

--
Yusuke Endoh mame@tsg.ne.jp

Updated by mame (Yusuke Endoh) almost 8 years ago

遠藤です。

2011年7月26日20:49 Urabe Shyouhei shyouhei@ruby-lang.org:

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

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

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

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

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

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

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

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

--
Yusuke Endoh mame@tsg.ne.jp

Updated by mame (Yusuke Endoh) almost 8 years ago

遠藤です。

2011年7月26日19:48 NARUSE, Yui naruse@airemix.jp:

(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 mame@tsg.ne.jp

Updated by mame (Yusuke Endoh) almost 8 years ago

遠藤です。

2011年7月26日19:48 NARUSE, Yui naruse@airemix.jp:

(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 mame@tsg.ne.jp

Updated by shyouhei (Shyouhei Urabe) almost 8 years ago

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

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

2011年7月26日20:49 Urabe Shyouhei shyouhei@ruby-lang.org:

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

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

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

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

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

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

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

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

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

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

Updated by shyouhei (Shyouhei Urabe) almost 8 years ago

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

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

2011年7月26日20:49 Urabe Shyouhei shyouhei@ruby-lang.org:

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

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

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

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

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

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

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

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

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

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

Updated by mame (Yusuke Endoh) almost 8 years ago

遠藤です。

2011年7月26日21:56 Urabe Shyouhei shyouhei@ruby-lang.org:

(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 mame@tsg.ne.jp

Updated by mame (Yusuke Endoh) almost 8 years ago

遠藤です。

2011年7月26日21:56 Urabe Shyouhei shyouhei@ruby-lang.org:

(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 mame@tsg.ne.jp

Updated by naruse (Yui NARUSE) almost 8 years ago

2011年7月26日22:39 Yusuke ENDOH mame@tsg.ne.jp:

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

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

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

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

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

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

--
NARUSE, Yui naruse@airemix.jp

Updated by naruse (Yui NARUSE) almost 8 years ago

2011年7月26日22:39 Yusuke ENDOH mame@tsg.ne.jp:

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

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

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

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

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

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

--
NARUSE, Yui naruse@airemix.jp

Updated by mame (Yusuke Endoh) almost 8 years ago

2011年7月27日10:20 NARUSE, Yui naruse@airemix.jp:

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

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

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

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

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

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

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

--
Yusuke Endoh mame@tsg.ne.jp

Updated by mame (Yusuke Endoh) almost 8 years ago

2011年7月27日10:20 NARUSE, Yui naruse@airemix.jp:

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

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

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

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

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

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

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

--
Yusuke Endoh mame@tsg.ne.jp

Updated by naruse (Yui NARUSE) almost 8 years ago

2011年7月27日12:25 Yusuke ENDOH mame@tsg.ne.jp:

2011年7月27日10:20 NARUSE, Yui naruse@airemix.jp:

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

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

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

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

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

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

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

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

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

--
NARUSE, Yui naruse@airemix.jp

Updated by naruse (Yui NARUSE) almost 8 years ago

2011年7月27日12:25 Yusuke ENDOH mame@tsg.ne.jp:

2011年7月27日10:20 NARUSE, Yui naruse@airemix.jp:

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

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

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

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

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

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

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

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

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

--
NARUSE, Yui naruse@airemix.jp

Updated by naruse (Yui NARUSE) over 7 years ago

  • Status changed from Assigned to Closed

Also available in: Atom PDF