Daisuke Kameda
kamin****@cc*****
2002年 12月 12日 (木) 23:24:07 JST
Daisukeです。 Masaharu Goto <magot****@fubys*****> wrote: > > あと、方針的に本家マージを目指すのと、先進ブランチを分け > > るかどうかも。議論の余地があるような。 > > この点悩んでますが、何をベースとするか、成果物をどうフィードバックするか、 > あんまり今の時点で煮詰めた議論は意味がないかも知れません。 > 議論のための議論に終始したら不毛ですし。 本家の開発体系が分からないとなんとも言えないですね。 > とりあえずのルール(?)としては、次のようなモノでどうでしょう。 > > ・リポジトリ直下には、最終的に形となるコンポーネントの名前でディレクトリ > を掘る > ex) knx-hd-install-jp > knx-templates-jp > hwsetup > mkknoppix...etc > ・本家のファイル群について、弄る必要が出た場合は、それらのファイル名を > 考慮したディレクトリを作成して作業 少なくとも現時点では、それで十分だと思います。 #KDEとかの個々のパッケージはまた別の話になりますし。 > で・・・議論すべきだと思う点についてコメントします。 > 産総研版についてはどのような単位でコンポーネントを管理しているのか > 不詳なのですが、どちらかといえばKnopper氏の作成されている本家成果物 > に対するフィードバック（これまた大変な作業ですが）を指向した方が > 最終的な手数の減少になるのではないかと思います。オリジナルのソースが > 日本を視野に入れたモノになってくれれば、産総研さんの作業は減りますし > 派生先進ブランチとはいえ、本家に容認されていないモノが多い状態では > 結局は本家のリビジョンアップに大して多数の労力を割いて追随するだけに > なってしまいそうです。このあたり、KDE/Qtで切ない局面を経験された > 塙さんやDaicikiさんにもご意見いただきたいと思います。 #「Daicikiって誰？」 ってのは置いといて（笑） 私は初期のころは知らないですし、大した事はやっておりませんが、 経験した範囲内で考えますと、方向性としては Maxさんのおっしゃる通り、本家へのマージを目指す方がロスは少ないと思います。 ただ、例えばKDE/Qtも本家の開発速度が早いので、 パッチを作ったりするのに時間がかかりそうな場合、バグ報告だけしてしまう という手段をとることもありますが、knoppixはそれが難しそうなのが難点かなと。 #バグ報告しておいてあまり反応が無い場合は、やる人が他にいない可能性が大なので、 #時間ができたら作業するとかってこともありますね。 そういう意味でも、ここらでいったん切って、 最初のknx-hdinstallベースのCD-ROM等を出した方が良いのではないかと思います。 > #と、いうわけで、hwsetupの改良に戻ります。 何かと思ったら、自動検出の部分なんですね。 興味あるので、何か分かったらお教えくださいませ。 #私は、CD-ROMのUSB対応方法を考えよう ##KDEパッケージは・・・bug fixリリースまで待ってくださいませ。 -- Daisuke Kameda <kamin****@cc*****>
