[#41531] [Bug #3385] ext/dbm: accept various version of db — Takahiro Kambe <redmine@...>

Bug #3385: ext/dbm: accept various version of db

10 messages 2010/06/03

[#41600] 質問・提案:cgi.rbの後継となるライブラリについて — Dice <tetradice@...>

Diceです。cgi.rbの後継ライブラリについて質問させてください。

16 messages 2010/06/13
[#41606] Re: 質問・提案:cgi.rbの後継となるライブラリについて — Fujioka <fuj@...> 2010/06/14

藤岡です。

[#41607] Re: 質問・提案:cgi.rbの後継となるライブラリについて — KAKUTANI Shintaro <shintaro.kakutani@...> 2010/06/14

かくたにです。

[#41616] Re: 質問・提案:cgi.rbの後継となるライブラリについて — Dice <tetradice@...> 2010/06/15

藤岡さん、かくたにさん、返信ありがとうございます。

[#41617] Re: 質問・提案:cgi.rbの後継となるライブラリについて — Fujioka <fuj@...> 2010/06/16

藤岡です。

[#41656] Re: 質問・提案:cgi.rbの後継となるライブラリについて — Dice <tetradice@...> 2010/06/20

Diceです。藤岡さん、返信ありがとうございます。

[#41623] [Feature:trunk] argument delegation — Nobuyoshi Nakada <nobu@...>

なかだです。

23 messages 2010/06/16
[#41625] Re: [Feature:trunk] argument delegation — Yusuke ENDOH <mame@...> 2010/06/16

遠藤です。

[#41627] Re: [Feature:trunk] argument delegation — Yukihiro Matsumoto <matz@...> 2010/06/16

まつもと ゆきひろです

[#41702] WIN32OLE_METHOD offset_vtbl — kuwamoto shintaro <beuniv@...>

こんばんわ

16 messages 2010/06/23
[#41712] Re: WIN32OLE_METHOD offset_vtbl — Masaki Suketa <masaki.suketa@...> 2010/06/24

助田です。

[ruby-dev:41686] Re: 質問・提案:cgi.rbの後継となるライブラリについて

From: "NARUSE, Yui" <naruse@...>
Date: 2010-06-23 08:52:44 UTC
List: ruby-dev #41686
成瀬です。

2010年6月22日15:44 NAKAMURA, Hiroshi <nakahiro@gmail.com>:
>>> ですが、Rubyを使う初心者が幸せになるのであれば
>>> (そして初心者以外の人を不幸にするのでなければ)
>>> 改善するだけの価値はあると思います。
>
> ↑は正しいですね。あとはバランスかな。
>
>> Ruby 開発陣が不幸になる可能性を忘れていませんか。
>
> こう極端に返してしまうと、では全て標準添付するなということにならないですか。
> そうじゃなくて、どこかでバランスを取る必要がある、ということでしょう。
>
>> 標準添付ライブラリのメンテナが消えた場合、泣きながらメンテナンス
>> するのは Ruby 開発陣です。
>
> 消えたのか消したのか消えるものなのかわかりませんが、とりあえず
> 「標準添付ライブラリのメンテナがいない」という現象は今後も起こるでしょう。
> 泣きながらメンテナンスするより、よい方法を探しましょう。
>
>
> で、ruby-osslの時にも言いましたが、標準添付ライブラリをgemにすることを
> まじめに考えてみませんか。「Ruby開発陣」として、標準添付ライブラリをgemに
> して追い出すための障壁は何ですか。たとえば遠藤さんが上げられた「重症」
> または「重症になる可能性が高い」ものをgemにして、
>
> 1. 標準添付ライブラリから単純になくしてさようなら。
> 2. リリース時に最新gemを取ってきて同梱する手順を整え、
>    make installでgem installまでやっちゃう。
> 3. 同じくmake install-gemでgem installできるようにする。
>
> などをした時の、メリットデメリットを挙げてみませんか。

gem にしてもリリース時に同梱するならば結局我々がメンテしないと
いけないんじゃないでしょうか。
どうせするなら標準添付にしておいたほうが本体の影響でバグッたときに
気づきやすいので現状の方がいいでしょう。

make install で勝手に入るのにバグッたままで良いというのは
ちょっとわたしの感覚ではありえませんし、
make install でこけるという最悪のパターンも考えると gem 化に
何がしかのメリットを見出すことができません。

いっそさくっと削除してしまったほうがヤル気のある人が gem を
作るだろうのでいいようにすら思います。

> ちなみに最初にgem化する例として、loggerあたりを実験に使う、というのが
> よいと思ってます。ファイルひとつなのでインパクト小さいから。

gem 化まではこれやるだけでいいのでしょうけれど、
最終的なインパクトはリリースして、各種パッケージの人々が
パッケージング作業を行う際に初めて気づくだろうので、
その辺おっかないですねぇ。

-- 
NARUSE, Yui
naruse@airemix.jp

In This Thread