オープンソースソフトウェアはリリースサイクルを合わせるべき？ 65
ストーリー by nabeshin
しょっちゅうリリースではダメ？ 部門より
しょっちゅうリリースではダメ？ 部門より
theinsiderman 曰く、
（つづく）Ubuntuの創始者であるMark Shuttleworth氏が、主要なオープンソースソフトウェアやLinuxディストリビューションの開発者に対し、「お互いに開発サイクルやリリースサイクルを合わせるべきだ」と主張したことが話題になっている（ars technicaの記事、Mark Shuttleworth氏のブログ）。開発/リリースサイクルを合わせることで、それぞれのプロジェクト間でのコラボレーションを促進できるほか、ユーザーが主要アプリケーションの新機能を利用しやすくなり、また商用ソフトウェアベンダーにとっても、Linuxプラットフォームの動向が分かりやすくなるために利用しやすくなるといったメリットがある、というのがShuttleworth氏の主張だ。
一方でリリースサイクルを合わせることは、オープンソースソフトウェアコミュニティにとっては非常に困難なうえ、成功したとしてもその見返りは非常に少ない。また、リリース期限を厳守しようとするあまり、バグが残ったままソフトウェアがリリースされてしまう可能性もある（KDEの開発者であるAaron Seigo氏による反論）。ただ、リリース期限を設定して開発を行うことによってうまくいったプロジェクトも多くあり、たとえばGNOMEでは、実装する機能が本当に重要かどうか、より慎重に判断するようになったそうだ。LinuxやLinuxディストリビューションを含むOSSはいつリリースされるか分からないのが当然のような雰囲気だったが、企業内での利用が進んだことで、このような雰囲気は変わりつつあるのかもしれない。
日本では導入済み (スコア:4, 興味深い)
http://srad.jp/developers/article.pl?sid=04/03/01/0634215 [srad.jp]
* Geckoをレンダリングエンジンに利用したWeb Browser風博士(kazehakase-0.1.3)
* 優れた操作性を持つGUIのメールクライアントSylpheed(sylpheed-0.9.10)
* GTK+を利用した画像viewer GImageView(gimageview-0.2.25)
* Qtを利用した2ch viewer kita(kita-0.102.1)
* GTK+を利用した2ch viewer ochusha(ochusha-0.5)
* Windows版GTK+でWindowsのIMEを利用するためのimmodule imime(imime-0.1.1)
* 入力ライブラリuim(uim-0.3.1)
* かな漢字変換エンジンanthy (anthy-5100)
* 予測入力システムprime(prime-0.7.a, prime-el-1.4.0, prime-dict-0.6.8, suikyo-1.3.2)
* Windows互換の操作性を持つGTK+ベースのテキストエディタText maid(tmaid-2.3.4)
* GTK+を用いたAVIファイルエディタVideo maid(vmaid-1.8.15)
* Rubyで作成されたWikiエンジンhiki(hiki-0.6)
* Perlで作成されたWikiエンジンFree Style Wiki(wiki-3.5.3dev4)
* Zopeを用いたBBSシステムMindMapBBS(mindmapbbs-0.2.23)
さぁ、世界に "The meat day" を広めよう！
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo（月友）
Firefoxですね (スコア:3, すばらしい洞察)
Re: (スコア:0)
何がこたえるんでしょうか？
現実に可能なのか? (スコア:3, すばらしい洞察)
私が尊敬するプロジェクトマネージャ曰く, 実行不可能なルールを設けることはルールを設けないより悪いんだとか.
Re:現実に可能なのか? (スコア:1)
埋め込まれたバグを発見してつぶすのはとても大変ですが、それを100日以内に済ませようとするのでさらに大騒ぎになります。
しかし、落ち着いた状態ではそもそも出るバグの量が減ります。なのでデバッグサイクルが回る頻度が下がり、結果として300日の内225日ぐらいが開発に割けることになります。稼いだ25日を Nightly Build などの構築コストに投入すると、テストの一部が自動化できるようになり結果としてますます人がぶっ倒れることが無くなり…
.
他にも USB memory を使うなと言うが… [srad.jp]で、「1としてまじめに考慮しておいた分」(その後2でネタをかます前に、ちゃんと真剣に考えるべき部分は切り離しておいたはずなのに、この『ネタ』をネタと理解しなかった人たちが完全に無視した部分)なんかもそうですね。
.
私は上記の例しかしりませんが、そのプロジェクトマネージャーは正しいと思います。
fjの教祖様
Linux Kernelも (スコア:2, 参考になる)
程度にもよるんですが、それなりに目標日時を立てるほうがよいこともあるでしょうね。
# KY(Kernelにあわせてヤりやがれ)とか...言われるようになる?
## 自戒を込めて
M-FalconSky (暑いか寒い)
本当に便利になるのかなあ (スコア:2, すばらしい洞察)
署名スパムがウザい？アカウント作って非表示に設定すればスッキリさ。
適用範囲が気になるね (スコア:1, 興味深い)
それなりの運用ノウハウがあるはず。
まずは、そのノウハウの共有とそれとその運用ができる規模と体制は
どんなものかを示してもらえると面白い。
でかいプロジェクトだと、まあスケジュールを握ってる人がいるだろうから
リリースに乗せる案件のしぼり方で何とかいくとか、
一人でやってるプロジェクトは、身軽だし、
そんなに大きな規模のソフトでもないから、意外と簡単だったり
(でも、その人が風邪引いただけで遅れたりね)
みんなでやるてのは、やったらどうなるかは興味はある。
もちろん、メリット受ける側はディストリビュータ側だろうから
Ubuntuのサポートがあって、の話で。
# 編集担当みたいに、Ubuntuのリリース担当が付いて
# 「先生、そろそろ次のリリースの時期なんですが、作品の仕上がりいかがでしょう」
Re:適用範囲が気になるね (スコア:3, おもしろおかしい)
># 「先生、そろそろ次のリリースの時期なんですが、作品の仕上がりいかがでしょう」
「先生、最近DL数が減ってきてますよ。やはりここはわかりやすくバトル物にしましょう」
「トーナメント形式とかどうです？準々決勝で中ボス：Apple、準決勝で大ボス：MS、
そして決勝のラスボスはまさかの実の生みの親とかいうのはどうでしょう？」
「いや、SCOが敵に回ったってのは別に『まさかの』でもなんでもないから」
ソースマスターヤマト (スコア:3, おもしろおかしい)
#タイトルだけ思い浮かんだが内容は思い浮かばなかった
Re:ソースマスターヤマト (スコア:2, おもしろおかしい)
ヤマト「な 何だって！？」
バグ「そしてお前の試験環境のメモリはやせてきたので仕様通りに解放しておいた あとは私を倒すだけだなクックック…」
（ゴゴゴゴ）
ヤマト「フ…上等だ…オレも一つ言っておくことがある 今回のリリースには画期的な新機能が盛り込まれるような気がしていたが別にそんなことはなかったぜ！」
バグ「そうか」
ヤマト「ウオオオいくぞオオオ！」
バグ「さあ来いヤマト！」
ヤマトの勇気がプロジェクトを救うと信じて…！ ご愛読ありがとうございました！
Re:適用範囲が気になるね (スコア:1)
Re:適用範囲、身柄の確保まで。 (スコア:0)
一斉にバージョンアップして、不具合が起きないように、Ubuntu が、
ベータ版やリリース候補を使って、組み合わせテストを行って開発に
フィードバックしてくれるとか。
さらに、〆切に間に合うように、開発者を缶詰にしてくれると。
Re: (スコア:0)
#あげあしとりなのでAC
Re: (スコア:0)
遅れちゃったりしたDebianのリリースのタイミングに合わせて
くれるなら問題ないんじゃないかな。
＃引抜じゃなくて「自由意志」で移った？
Re: (スコア:0)
＃そして「出るときに出る」のがDebianではないかと
Re: (スコア:0)
>それなりの運用ノウハウがあるはず。
半年に一度のリリース自体がubuntuそのもので、
それを厳守するのがcanonical社の仕事ってことでないかい？
※何よりもそのスケジュールに追い付いてるJapaneseチームに感謝。
Re: (スコア:0)
動作が重たいモッサリなubuntuで、ここだけ見るとどこがWinと違う？と思わず
不思議に陥るけど、それなりに楽しんでる身ではありますが、なんでそう
見た目、MSを思わず連想してしまうようなこと考えてしまうかなと思うの
ですが。 ubuntuはubuntuで、リリース揃ってようが揃ってまいが、それで
いーんじゃまいか
依存関係があるからなぁ (スコア:1)
それにあわせてライブラリを更新して、
ライブラリの更新結果を使ってアプリケーションに新機能を追加して…
それぞれを同じタイミングで実行するなんて…そんなパイプラインみたいなこと、できるんでしょうか?
さらに言うと、同期できるように1段あたりの時間を長くすると、結果として多段パイプラインを抜け切ったときにはとんでもなく時間がかかっている…なんてことにもなりかねない。
はて…価値があるのかなぁ。判らない。
fjの教祖様
Re:依存関係があるからなぁ (スコア:2, 参考になる)
3つの "wave" を考えているみたいですよ。
カーネル、システムライブラリの first wave。
アプリケーションの second wave。
ディストリビューションの third wave。
まあ、本人も議論のたたき台のようなものとしての提案のようなので、
議論されることに意義があるんじゃないでしょうか。
でも確かに、ある程度リリースが揃うとうれしいかもしれませんね。
例えば、主要なアプリケーションは 3月、6月、9月、12月のどれかで
リリースされるというスケジュールがあればリリースのチェックが楽になる。
1つのアプリケーションが年4回リリースされるわけじゃなくていいから、
アプリケーションのリリース時期がこの 4 つにまとまればいいなと思います。
Re:依存関係があるからなぁ (スコア:1, すばらしい洞察)
まあ「リリース日を揃えろ」というよりは、リリースをある指定日にすると
「一緒に通知しますよ」というメリット方式の運用を考えた方がより推進的かな？
それが毎月なのか四半期ごとなのかは検討の余地はあるだろうけど。
Re:依存関係があるからなぁ (スコア:1)
Re:依存関係があるからなぁ (スコア:1, フレームのもと)
--
使い物になるのはSP1以降です。
隗より始めよ (スコア:1, 興味深い)
まずはUbuntuとdebianのリリースサイクルを合わせてくれ。話はそれからだ。
個々のパッケージレベルでの連携も上手く行ってない事例がある [srad.jp]ようじゃ、リリースサイクルの同期なんて夢のまた夢のような気がするが。
Re: (スコア:0)
そういや、Vistaだったかと記憶にありますが、焦った結果、Vistaがビルドできない
とかいうニュースが飛び交ったかつての日々がありませんでしたっけ？
Re: (スコア:0)
手近なところから始めろとか、言いだしっぺがやれって意味で使われてると思うけど。
もしかして、故事成語の由来となった故事で、隗が言った言葉を、そのまま故事成語の意味だと勘違いしてる？
Re:隗より始めよ (スコア:1)
スナップショット (スコア:1)
日付を合わせろと言われたら、 version 1.0.1.20080527 のような、日付番号になるだけのような・・・。
宿題ならば提出期限を設けた方がはかどるでしょうけど、趣味で開発しているものに日付の区切りをつけるのは、開発者にもユーザにも利益はないように思えます・・・。
Re:スナップショット (スコア:1)
私は開発チームの一員ではないので、実情は違っていたらごめんなさい。
メリットねえ (スコア:1, 興味深い)
どうもどの理由も胡散臭いというか後付けっぽく聞こえる。
開発者側からの視点で見ると、まあ全部が全部リリース時期を合わせろって話ではないとは思うんだけど、プロジェクトの大小関係なく同じ日にちにっていうのは小回りが聞かなくなったりするだろうし、個人的にはリリースサイクル云々よりもまずfeature planningとかreviewとかQAがちゃんとできる体制を作ることの方が先なんではないかと思うけど。
デイリー、ウィークリー、マンスリー (スコア:1)
メジャーバージョンアップは月末だけ可能
とか、スタンダードリリースルールのような取り決めだけ作っておけば、
これに従おうと宣言して開発するスタイルみたいなのが出来て
ほんのり揃ったりしないかしら。
３桁バージョンで、a.b.c なら
a３の倍数月末.b月末.c週末 ぐらいでもいいかも。
デイリーはビルド番号
権力闘争ですよね。判ります。 (スコア:1)
回りくどく言っているだけでは？
そんな瑣末な事を気にするような クリチカルなバグばかり今あるんだっけ？
そういう例もあるというだけで、数は限られてるのでは無いのかな？
例を示そうとして 最近権利ばかり主張して、さっぱり新作を見かけない作者を
思い出したので ID
週刊リナックス (スコア:1, おもしろおかしい)
お盆休み進行があるのは、日本だけだな。
オープンソースのソフトウェアって (スコア:0)
Re:オープンソースのソフトウェアって (スコア:3, すばらしい洞察)
Re:オープンソースのソフトウェアって (スコア:1, おもしろおかしい)
Re: (スコア:0)
Re: (スコア:0)
# この都市伝説もほんと根強いね。
Re: (スコア:0)
Re: (スコア:0)
＃例：SP1、SP2、SP3、その他の修整パッチetc
あえていうなら会社が潰れれば消滅するプロプライエタリなソフトウエアと、
会社が潰れても消滅するとは限らないオープンソースの違いか。
Re: (スコア:0, すばらしい洞察)
Re:オープンソースのソフトウェアって (スコア:1, おもしろおかしい)
○かっこうがわるい
Version 1.0.0 が一応の完成なんだろうな (スコア:0)
Eclipse (スコア:0)
Re: (スコア:0)
あと、Eclipse.orgはMozilla.orgと違って、期限を完璧に守りますよね。
マイルストーン表示 (スコア:0)
OSS情報は登録制でどんどん増やしていって、表示はフィルタリングできるといいね。
誰か作らない？
Re:マイルストーン表示 (スコア:1)
あとはSourceForgeのRSSなんかを受け取ってうまく加工するとか。
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo（月友）
Re:マイルストーン表示 (スコア:1)
そうそう、必要なら RSS なり何なりでヲチできるわけだから、エンドユーザの立場では一斉リリースのメリットが見えにくいのですよ。
だいたい、最新版を（入れたい｜入れなきゃならない）人はすでに自発的に情報を追いかけてるんじゃないのかね。
逆に「リリース予定日は固定だ」という意識が根付いて、セキュリティホール潰し緊急リリースの浸透が遅れたりせんだろうか、とかちょっと思った。
[わかってもらうことは難しい。わかってあげることは、もっと難しい。]
なんか反論してる開発者は勘違いしてるが (スコア:0)
ってことじゃなくて、むしろ
「リリースできないなら他のソフトも合わせてリリースを待って(デバッグの協力でもしろ)」
「商売じぇねえんだからそんなに競争みたいに急いでリリースすること無いだろ」
だと思う。
そもそもなんでこういう意見が出てくるか、元発言を見てないから推測でしかないけど、
要はリリースタイミングがばらばらだとディストリビュータも開発者も個々のユーザーも
何かの新バージョンが出るたびに物凄く無駄な検証コストが費やされてるって事だと思う。
せめて主なソフトだけでも一変に入れ替えを検証できればそのソフトの数だけ劇的に相性検証のコストが軽減されるじゃん？
確かに、ソフト開発側は他ソフトの最新状況まで意識しないといけないしリリースは遅れるしで嫌なのかもしれないけど、
それって逆を言えばそれが負担になるなんて言ってるような開発者は他ソフトの最新版との相性の検証を蔑ろにしてるってことでしょ？
一言で言うと「お前ら落ち着いてもっと協力しろ」ってことなのかな。
Re:なんか反論してる開発者は勘違いしてるが (スコア:1)
しかし、"stableな奴にバグパッチを当てたもの"にこだわりすぎるのも良くないと思います。
先日あった、DebianのOpenSSLの問題のような例もありますし。