ruby-list

永井@知能．九工大です．

From: take_tk <ggb03124@nifty.ne.jp>
Subject: [ruby-list:40273] Re: 「標準ライブラリ選定委員会」なんてのは？
Date: Thu, 11 Nov 2004 18:04:58 +0900
Message-ID: <20041111144421.BA1D.GGB03124@nifty.ne.jp>
> > 標準ライブラリ化すれば追加インストールの手間を必要としなくなるし，
> > ユーザも増える可能性が高いのですが，それなりの責任が伴いますよね．

> 標準ライブラリ化に伴う責任を、ruby開発者が負担するか、標準ライブラリだけ
> に責任を負う「選定委員会」が責任を負うか、という問題です。

あぁ，ディストリビューターというのは，単に配布パッケージを構築する人の
ことだったですか．
標準とされたライブラリを作成，管理し source tree に提供する人のことかと
勝手に思い込んでました．
ごめんなさい．

# 追加するのしないのという流れの中で読んじゃったので，つい．．．(^_^;

ですので，前のメールでの私の記述はライブラリ開発者についての課題として
読み替えてください．

その意味で考えた上で，選定委員会がディストリビューターに強制する
ということは，間接的にライブラリ開発者にも添付を強制していること
になるとしか思えないです．

# ディストリビューターは選定委員会とライブラリ開発者との間で
# 板挟みになりそうな気もします．

なお，私の書き方が悪かったのでしょうけれど，私の批判は主として
委員会の「強制権」についての話であることに注意いただけると幸いです．

で，わからなくなったのが「標準」の意味合いなのですが，
この「標準」というのは

(1) 現在の標準ライブラリと同じで source archive には必ず含まれて
    いるもの

のことでしょうか．それとも

(2) 現在の標準ライブラリに加えて，配布用バイナリパッケージ(?)には
    必ず含まれるようにするもの

のことでしょうか．
前者と後者とでは意味が違ってきます．

前者 (1) であるとすれば，委員会はライブラリ開発者に前メールのような
負担を強制することになります．
後者 (2) であるならば，配布パッケージには「標準」に加えて
これとこれが加えてあると明示すればいいことになりますから，
問題は大きく減少します．

# 「標準」以外で追加されていると認識されるものについては
# 前メールに書いたほどには制約は強くないでしょうから．

以下では上記の (1) か (2) かは区別しないで (どちらかと言えば (1) だっ
たケースを想定して) 書いています．
したがって，(2) であった場合には文面よりももう少し軽い意味での批判と
解釈ください．

> > 少なくともリリース版で動かないなんてことでは困るし，
> > 従来との互換性の維持にも神経を使わねばならない．
> > 見えないユーザのためにも，互換性を持って移行するのが可能でない限り，
> > 「や〜めた」などと標準添付をやめてほおり出すなど絶対に許されないと
> > 私は考えます．
> > もし自分は使わなくなったとしても，使える状態を維持し続けるのは
> > 義務と言ってもよいかもしれません．
> 
> これらは、当該ライブラリを開発した人と、ライブラリを選定した人の責任であっ
> て、ruby開発者が神経を使うべきことではない。

「ruby開発者が神経を使うべきことではない」には同意します．
「ライブラリを選定した人の責任」もいいでしょう．
ですが，ある意味巻き込まれた形であるライブラリ開発者にも
責任を被せるのは是していいものでしょうか？
委員会委員の任期をどう考えておられるのかはわかりませんが，
選定した委員が委員をやめてしまっても，ライブラリ開発者には
責任が残り続けるわけですよね？

> > とはいうものの，まぁ，皆ボランティア的にやっているわけですから
> > ある程度の融通はきかせてよいと思います．(^_^)
> > ですが，標準添付ライブラリでは，そのくらいの覚悟を持つつもりで
> > 取り組む必要があるでしょう．
> 
> まつもとさんもボランティア的にやっているわけですから（推測）、負担を分担
> しようということだと思うのですが・・。

私が元メールの意図を読み違えていたせいで話が食い違ってしまってますが，
まつもとさんの負担を減らすようにすべきだという点はもちろん同意します．

で，前メールは標準添付とされたライブラリ作者に求められるものという
つもりで書いていましたので，申し訳ありませんが↓の「ディストリビュー
タ」は「ライブラリ開発者」として読み替えてください．

> > にもかかわらず，委員会で決めたライブラリは「添付しなければならない」
> > ということになっています．
> > これは上記のような覚悟をディストリビュータに無理強いしていることに
> > なります．
> 
> むしろ、選定委員会の方に覚悟が必要ですね。
> 
> 添付の強制の度合、添付しなかった場合の扱いについては検討の余地ありです。

委員会の「覚悟して行わねばならないこと」というのは何でしょう？
単に「非難される」ということではないのですよね？

引用の順番が前後しますが，

> 対象ライブラリが維持できなくなった場合には、委員会から参加者に「維持でき
> なくなったので廃止予定である。メンテナを募集する。」といった案内を出して、
> 駄目なら廃止するほかないでしょう。使えなくなったライブラリは付けてもしょ
> うがない。
> 
> 委員会の役割としては、メンテナの確保、連絡、募集、といった作業になると思
> います。

というのだとすると，強制してまで加えることの責任は果たしきれていない
のではないでしょうか．

廃止してしまうと，「標準だから」と思って使っていたユーザを
その時点で置き去りにしてしまうことになります．
私にはそれは簡単には許されて良いものではないと思えるのです．

・代りのメンテナが見つかるまでは委員会がメンテを代行する．

・メンテナが見つかりそうにないときは，代換となるライブラリを
  添付できるように手配する．

・廃止の前にその代換ライブラリへの移行がゆっくりと行えるだけの
  十分な期間のメンテは (将来の廃止を警告しつつ) 継続する．

という程度は必要に感じます．

> > 委員会はそれだけの権限を持つことになりますが，誰がその委員会の
> > メンバーを選ぶのでしょうか．
> 
> 人選の方法までは考えていませんが、自然に決まるか、選挙か、まつもとさんに
> 決めてもらうか、その他の方法か、いろいろあると思います。現状の引継という
> 意味ではまつもとさんが選任するという方法もありかも。
> 
> むしろ、ライブラリの選定の仕方を「ユーザが求めるモノであって」「品質等に
> 問題がない」ものに決まっていくようにする仕組みを考える必要があると思いま
> す。

提案されているような強制権を持った委員会ではなく，
まつもとさんから標準添付の是非を決定権を委譲された人 (選挙で選ぶでも
もちろんかまいません) が ML 上での議論を経て最終決定するという程度の
形態ではダメですか？

添付を希望するなら，効能や価値，ユーザが安心して継続利用できることを
きちんとに説明して，理解してもらい，広くコンセンサスを得るようにすると
いうのは当然のことでしょう．

コンセンサスが得られないなら標準添付は避けるべきでしょうし，
得られるようなら標準添付は問題ないはずです．
決定権保有者はそれに従って最終決定を下すだけのことです．

決定権保有者が添付反対の意見を持つなら，当然，反対意見で
議論に参加していたでしょうから，勝手に引っくり返すことは
考えなくてもよいと思います．

もしそんなことをしたり，進行中の堂々巡りではない議論を勝手に
打ち切ったりするようなら，決定権者のリコールという話になるだけです．

> 基本的にはWeb投票で候補を決めて、選定委員会のほうで、品質、一貫性、メン
> テナンス可能性、などを検討する形を考えています。
> 
> Web投票のシステムは自動化できそうな気がする。標準ライブラリについて要望
> がある人がメールアドレスとパスワードの登録だけで参加できるようにする。

組織票の問題は委員会での検討で回避するということですね？
ML 上のオープンな議論ではいけない理由というのがわからないのですが．．．

# フレームになるかもしれないから？
-- 
                                         永井 秀利 （九工大 知能情報）
                                             nagai@ai.kyutech.ac.jp

Thread

Prev Next

In This Thread

Prev Next

[#40151] vrubyとyamlを組み合わせて使ったときの問題 — "Keisuke Minami" <keisuke@...>

[#40162] Ruby/Tk 講習会のご案内 — Hidetoshi NAGAI <nagai@...>

[#40163] [ANN] RSS Parser 0.1.0 — Kouhei Sutou <kou@...>

[#40164] Class内Classの定義と差分ベースモジュール — Nowake <nowake@...>

[#40169] Re: — "Yun" <yun@...>

[#40171] [ANN] RDtool-0.6.15 — MoonWolf <moonwolf@...>

[#40178] [ANN] Ruby-GetText-Package-0.8.0 — Masao Mutoh <mutoh@...>

[#40189] [ANN]プログラミングのチュートリアル — Shin Nishiyama <shin@...>

[#40196] [ANN] RDtool-0.6.16 — MoonWolf <moonwolf@...>

[#40252] [ANN] report-bug 0.1.0 — MoonWolf <moonwolf@...>

[#40262] www.ruby-lang.orgの見直し — MoonWolf <moonwolf@...>

[#40266] まつもとさんの負担を減らすために、何ができるだろう — 卜部昌平 <s-urabe@...>

[#40272] RDtool の標準添付希望 — dan <dango@...>

[#40295] Ruby/Tk講習会のための ML — Hidetoshi NAGAI <nagai@...>

[#40305] [ANN] Ruby-GNOME2-0.11.0 — Masao Mutoh <mutoh@...>

[#40306] [ANN] Rubyist Magazine 0003 — SASADA Koichi <ko1@...>

[#40309] extconf.rb's problem? — Takahiro Kambe <taca@...>

[#40311] [ANN] rem: a Ruby debugger — "YAMASITA, Yuu" <subterranean.homesick@...>

[#40315] Ruby/Tk 講習会への Windows での参加 — Hidetoshi NAGAI <nagai@...>

[#40318] 関西地区勉強会のご案内 — Hideo Konami <konami@...>

[#40319] [ann] htmlsplit, htmlrepair — 堀川 久 <vzw00011@...>

[#40320] Windows 環境への net/telnet — 井沢 一夫 <isawa_kz@...>

[#40323] [ANN] rem 0.0.7 released. — yyuu <subterranean.homesick@...>

[#40326] Which is latest rttool? — Takahiro Kambe <taca@...>

[#40329] Proc オブジェクトを文字列に戻す方法はありますか？ — take_tk <ggb03124@...>

[#40332] CGI::Sessionを利用してクッキーを secure モードで発行したい — 永井 圭 <nagai@...>

[#40333] リファレンスマニュアル — 堀川 久 <vzw00011@...>

[#40344] [ANN] RSS Parser 0.1.1 — Kouhei Sutou <kou@...>

[ruby-list:40278] Re: 「標準ライブラリ選定委員会」なんてのは？

Thread

In This Thread

[#40319] [ann] htmlsplit, htmlrepair — 堀川久 <vzw00011@...>

[#40320] Windows 環境への net/telnet — 井沢一夫 <isawa_kz@...>

[#40332] CGI::Sessionを利用してクッキーを secure モードで発行したい — 永井　圭 <nagai@...>

[#40333] リファレンスマニュアル — 堀川久 <vzw00011@...>