[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[freewnn:00275] Re: cvs server for freewnn.org
>> On Sat, 15 Jan 2000 04:10:41 +0900, Tatsuo Furukawa <frkwtto@osk3.3web.ne.jp> said:
> ＃ ただ、私も開発に参加したいので、私が独自に加えたコードも入っていま
> ＃ す。でもこれは私も ML のメンバーだし〜 という立場で行なってます。
いえいえ、メンテナーとしての古川さんと開発者としての古川さんはきちんと
分かれていると思います。開発者としては新しい機能を入れたいけど、それは
リリースを遅らすからメンテナーとしてはcommitしないとかありますしね。
> uraさん> FreeBSD場合
> uraさん> 開発は、HEAD-branchで行なう。stable branchは、bugfixの他に
> uraさん> current branchに入った機能でstableにたるものは取り込んでいく。
> この方式は是非採り入れたいです。つまり、開発ブランチで好き勝手に試して
> みて、うまく動くものを安定版に採り入れてリリースしていく。
わたしは、どのbranchにどういうfeatureがあるかが分かりやすいことから
FreeBSD方式よりNetBSD方式の方が好きだったりします(ふだんNetBSDだけで
生活していることもあるので、非常に偏りがある意見ですが(^^;;)
> > HEAD ----------o---------------------------------------> 4.0-current
> > \
> > \
> > o---o--------o--------o--------o----> 3-stable
> > 3.1 3.2 3.3 3.4
> 質問です。これは ura さんが示された FreeBSD の図ですが、この場合、3.4
> がリリースされた時点で 3.1〜3.3 は開発終了ということですよね? つまり、
> 3.3 でバグが見つかった場合、「3.4 を使ってくれ」ってことになり、3.3.1
> というバージョンは出さないという理解でいいでしょうか?
>
> となると、いつまでたっても安定しないような気もしますが…… もしくは次
> の安定版を出すのをすごく慎重にしないといけない。
そういうことになっていると思います。ですから、3-stableには怪しいcodeを
入れてはいけないということです。
3.1が出る前後で、FreeBSDは2.2系と3.x系以降ではリリース番号の付け方が
変わって、3.x系以降では、3番目の番号は、bug fix番号に使うという話を
聞いた覚えがあります(この話が違っていたらごめんなさい)。ですから、
3.2.1とか3.3.1とかもでるのか思っていたのですが、実際のところ使われて
いないのですよね。
> 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 をすぐにリリースできますから。
そうなりますが、NetBSDの場合は新しいstable branchを作った段階で、前の
stable branchの開発は終了します。ですから、1.5 branchが切られた後に
1.4 branchからreleaseされることはないです。
> > OpenBSD場合
> >
> > HEAD ----------o--------------o---------------> OpenSD-current
> > \ \
> > \ \
> > o o
> > 2.5 2.6
> >
> > 開発は、HEAD branchで行なう。release versionはsecurity
> > patchのみを個別に出して、stable branchは変更しない
> これって、真の安定版は cvs のソースツリーから作成することはできないっ
> て意味ですか? ちょっと信じられないです…。
いえ、OpenBSDはrelease直前にHEAD branchをfeature freezeしてbug取りに
専念する形で開発を取っています。ですから、2.5や2.6は十分に安定版と
考えてよいです。しかし、security holeなんかは年がら年中出てくるので
security holeを塞ぐためのpatchをrelease用に出すわけです。-currentは
HEAD branchにcommitすればいいわけですから。
使っているuserが全てCVSでcodeを取るわけではないですから、リリース用に
security patchを出すことに関してはOpenBSDが一番きちんとしていると
思いますよ。
これらのFreeBSD,NetBSD,OpenBSDの違いは、そのOSを使っている and/or
開発している人の数とか、それぞれのOSを使っている人達の欲しているもの
違いとかが反映されていると思います。
> あと開発版というのはブランチが1本しかないのでしょうか? となると、実験
> 的な実装は cvs にどう反映しているのでしょうか?
先の図は実験用branchとかの余計なbranch、HEAD branchとrelease branch
の説明に特化していましたので、もちろんHEAD brach以外に作業branchは
たくさんあります。たとえば、NetBSD場合はsoftupdateをmergeするための
brachですとか、VMとbuffer cacheを統合するためのbranchですとかです。
下記URLを見るとbranchが切られていることが分かります。
http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/uvm/uvm_km.c
> あと、安定版でバグフィックスを行なった場合、そのバグフィックスを開発版
> に反映させる必要がありますが、そういう作業は上記のFreeBSDや NetBSD で
> はどのようにしているのでしょう?
NetBSDは、currentでbugを潰してその結果をreleaseに反映するという、常に
current → releaseの流れです。エンバグを抑えるためにこうなっていると
勝手に思っています。FreeBSDは細かく追っていないのでわかりません。すい
ません。
> 3. メインブランチには、最新でかつ安定したものを置く。
>
> 4. 何か作業を行なう時は、その作業の単位毎にブランチを作り、そこで作
> 業する。メインブランチと異なり、安定した状態で commmit する義務
> はない。
NetBSDだとmain branchこそが開発の先端ですから、main branchを安定である
必要がないのです。もちろん、不安定だと開発に支障ができますから、同じ
原因で不安定であることはわずかな間だけです。それぞれの人がbranchを
切って、それを各々がmain branchにmergeするなると、source codeが膨大です
から、mergeする時に泣きを見る気がしますね。
> 5. 作業が完了した時点でメインブランチにマージする。
>
> 6. メインブランチにマージしたらその作業ブランチは消して良い。
> (但し、6 には異論もありました。)
CVSは消さなくとも、mergeしたあとは作業branchを放置してしまってよいので、
6.は必要ないですね。そうえいば、CVSでbranchを消す技ってありましたっけ?
あと、聞いた話ではcronとかで毎日毎日最新のsourceを使ってmakeをしてみる
ことは開発に有効だそうです。不安定なcodeを突っ込んだ時には翌日には分かり
ますから。
--
ura