[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[freewnn:00274] Re: cvs server for freewnn.org
- To: freewnn@tomo.tomo.gr.jp
- Subject: [freewnn:00274] Re: cvs server for freewnn.org
- From: Tatsuo Furukawa <frkwtto@XXXX>
- Date: Sat, 15 Jan 2000 04:10:41 +0900
- In-Reply-To: <20000114111947O.ura@hiru.aoba.yokohama.jp> (message from URAHiroshi on Fri, 14 Jan 2000 11:19:47 +0900)
- Reply-To: freewnn@tomo.gr.jp
古川竜雄です。
cvs については名前しか知りませんでした。数年前に fj で一時期話題になっ
たことがあって、そのときは「RCS はファイル単位だが cvs はディレクトリ
単位でバージョン管理ができる」というような話だったと思います。
よしださんが書かれていた URL を少し読んで、「cvs の最大の売りは多人数、
しかも物理的にはなれたところで協力して開発ができるシステム」なのだとい
うことがわかりました。
uraさん> なんで、cvsを使って開発をする場合はどうやってやるかを(誰かの
uraさん> 独断と偏見でもいいから)明確にしておいた方がよいです。
了解しました。んじゃ、「なぜ cvs を使うのか」というところから行きましょ
う。
私は逆説的(?)ないい方が好きなのでこんなことをいってしまいます :-)。
「FreeWnn Project では FreeWnn の開発をおこなっておりません」
では FreeWnn Project がなにをやっているかというと、「FreeWnn の面倒を
見ている」のです。これは LC99 でよしださんが発表されたスライドにはっき
り書いてあります。
http://www.tomo.gr.jp/FreeWnn/lc99/mgp00007.html
「面倒を見る」とは、具体的には ML の運営とか、Web ページのメンテナンス
とか、雑誌の宣伝とか、講演とか、パッチのとりまとめとか、そんなことです。
では「開発は誰がやっているのか」という質問が当然出てくると思いますが、
それは ML に参加されている皆さんなんですね〜。パッチの取りまとめは私が
行なっておりますが、基本的に ML に流れたものをまとめて、適当にバージョ
ン番号をつけて ftp サイトにおいているだけです。
＃ ただ、私も開発に参加したいので、私が独自に加えたコードも入っていま
＃ す。でもこれは私も ML のメンバーだし〜 という立場で行なってます。
FreeWnn 1.1.1 (リリース予定)の開発に参加したひとのリストが
CONTRIBUTORS というファイル名で FreeWnn のアーカイブにありますが、ここ
に名前を連ねている人が、まさに ML でパッチを流したひとなのです。(厳密
にいえば「パッチを ML に流していない」ひとも含まれていますが、それは、
「開発に参加した」という基準を使っているからです)
というわけで、FreeWnn の開発に参加したいと思ったら、単に ML に加入して、
議論に参加し、パッチをバンバン流せばいいのです。「ソースコードを直接い
じる権限を得るには FreeWnn Project のメンバーになる必要がある」という
ことはありません。これぞオープンソースの開発スタイル! (自画自賛)
cvs 導入の背景にはこういった考え方があります。現在の、
私がパッチを取りまとめて、少なくとも私の環境(Linux/SlackWare 3.2
もしかしたら 3.1 だったかも?)でコンパイルエラーが出ないことを確認
した後に ftp サイトに置く。
というやりかたは、安定版の開発手法です。それなりにうまく動くバージョン
を供給するというには適していますが、今後、FreeWnn が新たな機能を採り入
れて、意欲的に進化を始めるためには、このやりかたではおそらくうまく行か
ないでしょう。
＃ 実は結婚と引越しで全然時間がとれなくて…。最近ようやく安定してきま
＃ した。こんな理由で最新版のリリースが遅れるのは不本意なのですが…
開発版では、誰かが「こんなことをしてみたい」と思った時にすぐにそれがソー
スコードに反映できるような開発スタイルが理想だと思います。極端な話、
「こんなことをしようと思ったのですが、手に負えなくなってしまいました。
あとだれかよろしく」というようなものでも誰かが引き継いでくれるとか。
(さすがにこれは無理か…)
------------------------------------------------------------------------------
uraさん> それで、cvsでの共同開発もbranchの持ち方にそれぞのprojectで各
uraさん> 種違っていて、どうするかが悩みところですね。
私もcvsでの共同開発の経験はありません。が、勤務先で ClearCase という構
成管理ツールを使って共同開発を行なった経験はあります。
uraさん> FreeBSD場合
uraさん> 開発は、HEAD-branchで行なう。stable branchは、bugfixの他に
uraさん> current branchに入った機能でstableにたるものは取り込んでいく。
この方式は是非採り入れたいです。つまり、開発ブランチで好き勝手に試して
みて、うまく動くものを安定版に採り入れてリリースしていく。
uraさん> HEAD ----------o---------------------------------------> 4.0-current
uraさん> \
uraさん> \
uraさん> o---o--------o--------o--------o----> 3-stable
uraさん> 3.1 3.2 3.3 3.4
質問です。これは ura さんが示された FreeBSD の図ですが、この場合、3.4
がリリースされた時点で 3.1〜3.3 は開発終了ということですよね? つまり、
3.3 でバグが見つかった場合、「3.4 を使ってくれ」ってことになり、3.3.1
というバージョンは出さないという理解でいいでしょうか?
となると、いつまでたっても安定しないような気もしますが…… もしくは次
の安定版を出すのをすごく慎重にしないといけない。
uraさん> NetBSD場合
uraさん> HEAD ----------o----------------------------------> NetBSD-current
uraさん> \
uraさん> \
uraさん> o--o--------o--------> 1-4-branch
uraさん> 1.4 1.4.1
uraさん> 開発は、HEAD branchで行なう。stable branchは、bugfixのみで
uraさん> 機能追加はしない。
ということでしたら、次のバージョンを出す場合は
1.5
o--o
/
/
HEAD ----------o--------------------o---> NetBSD-current
\
\
o--o--------o--------> 1-4-branch
1.4 1.4.1
となるわけですね? これだと安全ですね。「安定版 1.5 を作るべく頑張った
が収拾がつかなくなったどうしよう?」というとき運悪く 1.4.1 にバグが見つ
かっても 1.4.2 をすぐにリリースできますから。
uraさん> OpenBSD場合
uraさん>
uraさん> HEAD ----------o--------------o---------------> OpenSD-current
uraさん> \ \
uraさん> \ \
uraさん> o o
uraさん> 2.5 2.6
uraさん>
uraさん> 開発は、HEAD branchで行なう。release versionはsecurity
uraさん> patchのみを個別に出して、stable branchは変更しない
これって、真の安定版は cvs のソースツリーから作成することはできないっ
て意味ですか? ちょっと信じられないです…。
あと開発版というのはブランチが1本しかないのでしょうか? となると、実験
的な実装は cvs にどう反映しているのでしょうか? 例えば、現在の FreeWnn
の状況でいえば、
1. 今すぐにでも安定版を出したい。
2. shared library バージョンを作りたい。でも今回の安定版には含めない。
というところです。この場合、
HEAD ----------o------------------------> 開発ブランチ。sheard library
\
\
o--o--------o--------> 1.1 安定版ブランチ
1.1 1.1.1
となりそうですが、これだと shared library 対応の作業が一段落するまで開
発ブランチの作業ができないと思います。なぜなら、sheard library の作業
を A さんが Linux で行なっていて、B さんが HP-UX で動作確認したいとい
う場合、とりあえず A さんが Linux でちゃんと動くようになった状態で cvs
に戻す(commit する)必要がありますが、
Linux 対応
HEAD ----------o------------o-----------> 開発ブランチ。sheard library
\
\
o--o--------o--------> 1.1 安定版ブランチ
1.1 1.1.1
この時点で開発ブランチの最新版が HP-UX では動かなくなります。となると、
他の人の開発ブランチの作業に支障がでると思います。
あと、安定版でバグフィックスを行なった場合、そのバグフィックスを開発版
に反映させる必要がありますが、そういう作業は上記のFreeBSDや NetBSD で
はどのようにしているのでしょう?
ちなみにこういう場合、勤務先ではこんな感じにしていました。
Linux 対応 HP-UX 対応
o-------------o sheard library 開発ブランチ
/ \
/ \
HEAD ---O---O-----------O-------O----> メインブランチ
\ /
\ /
o--o------o--------> 1.1 安定版ブランチ
1.1 1.1.1
1. 安定版の作成の基準になる点、および新機能追加を行なう点をベースラ
インとよぶことにする。
2. ベースラインは必ずメインブランチからとる。他のブランチからはとら
ない。
3. メインブランチには、最新でかつ安定したものを置く。
4. 何か作業を行なう時は、その作業の単位毎にブランチを作り、そこで作
業する。メインブランチと異なり、安定した状態で commmit する義務
はない。
5. 作業が完了した時点でメインブランチにマージする。
6. メインブランチにマージしたらその作業ブランチは消して良い。
(但し、6 には異論もありました。)
------------------------------------------------------------------------------
戸村さん> 私自身はローテクなもので(^_^);;;、cvs による共同開発について
戸村さん> は運用上の経験がありません。一方で read only cvs server であ
戸村さん> れば、すぐにでも運用をはじめられるかと思います。
素晴らしいです。(^_^)
戸村さん> 開発方法として cvs による管理を行うかどうかは FreeWnn の管理
戸村さん> 者(maintaner) である古川さんの開発環境にも依存するところかと
戸村さん> 思います。
わたしも少しだけですが、資料を読んで勉強しているところです。
戸村さん> 古川さんはどのようにされるのが良いでしょうか?
そうですね、読み出し(checkout)はだれでも OK で、書き込み権(commit)は限
定された人である必要がありますが、早いうちにやりかたを決めて、1.1.1 移
行から cvs 管理でいきたいと思います。
＃ もっと早い方がいいかな?
--
古川竜雄 (frkwtto@osk3.3web.ne.jp) / FreeWnn Project