hogeとはワイルドカードのようなものです。日々起こった、さまざまなこと −すなわちワイルドカード− を取り上げて日記を書く、という意味で名付けたのかというとそうでもありません。適当に決めたらこんな理由が浮かんできました。
10/18/2003 む [長年日記]
■ [Gentoo] Re: 本家と GentooJP
usataさんが日記の方で考えをまとめて下さっていた．
Bugzilla では簡単にテスト中 ebuild の配布ができない，というのはその通りですよね．現状の wiki の方でも，「めんどくせーからちょっと」という人も多かったのではないでしょうか．
ちょっとよく分からなかったのですが，usata さんのモデルをもう少し詳しく書くと，こんな感じでしょうか？(画像でかくてごめんなさい)
(ここで，「本家開発者」は本家にコミット権を持つ GentooJP 内開発者，「GentooJP 内部開発者」は本家にコミット権を持たない，あくまで GentooJP 内部での開発者とする．便宜上「GentooJP テスター」と書いたが，テストは誰でもできる)
このような感じになると，「本家開発者」である usata さんや yakina さん，matsuu さん，なかのさんの負担がグッと減る気がします．
あと問題点として挙がっている
- メンテ場所増加
- Bugzilla 立ち上げの負担
- 配布方法(上記モデルのステップ５)
ですが，２と３については現在進行形で作業が進められているので問題なしとして，１については現状の wiki (というか BugTrack) を完全に移行してしまえば良いと思います．もちろん移行期間は必要だと思いますが．
GentooJP 内部開発者がどこまで増えるか，というのはもちろん問題なのですが，これ，本家と同じように，バグ報告をドンドンやってくれてる人(もちろん個人単位で)に「開発者やってみない？」って振ってみると良いと思うんですが．GentooJP の今までの感じを見てると，不特定多数に呼びかけて，誰かが自発的に「俺がやる！」って言ってくれるのを待ってる気がするんですよね．GentooJP 側からも積極的にアプローチしてみると随分変わるのではないでしょうか．
■ しかし
なんかやっぱり少人数で盛り上がっちゃってる感がするんだよなー．俺だって単なる１ユーザだし，どんな人でもどんな意見でも，参加してくれないかなー．
まとめ直してくださってありがとうございました。あの図の下部については
その図のとおりです。たとえば「本家 Portage の中に入っているソフトウェア
で、日本語パッチがあるけど、他の言語で使っている人(USE="cjk" フラグだけ
では大雑把すぎる)には悪影響があるので本家には入れられない」というような
ebuild があるとして、こういうのを GentooJP の CVS ツリーで保持すればいい
のではないかと思います。本家のバージョンが上がるのに追従するのは GentooJP
開発者が当たると。
GentooJP Bugzilla が動いてくれれば、本家で bug-wranglers がやっている
ように GentooJP の bug-wranglers も作って、たとえば atzm さんが、GentooJP
の bug-wranglers に入って GentooJP Bugzilla に投稿されたバグの報告メール
を受け取り、GentooJP 内でそのバグを担当できそうな人に振ったり、GentooJP
内でテストされた解決策を本家に入れてもらいたいのであれば適当な本家開発者
の人にそのバグを assign する、といった感じで運用できるようになると思って
います。いまの Wiki だと誰が担当しているのか、どの bug を本家に持って
いってほしいのか、全然判断がつきかねるので、Bugzilla 導入を強く要望します。
(Bugzilla じゃなくてもいいのですが、少なくとも誰が担当者なのか分かるシステム
にしてほしい)
もっと声をかけて開発者を集める、というの、自分は本家のほうでは実践して
いるのですが、GentooJP ではやってないですね(GentooJP に呼んでもいまのと
ころアカウントが発行できるわけでもなし、なんと言ってよいやら)。
基本的にそのモデルでいいのですが、4,5の部分は、ebuild uploader(仮称・製作中)を使えればと思っています。
どういうものかと言うと、誰もが修正、登録が可能はuploaderです。で、GentooJPのデベロッパーはそれに対する「承認」の権限を与えたらどうか、と考えてます。
で、承認されたebuildは自動でGentooJPのPortage treeへ入ると。そのPortage treeの配布方法はまだ考えてないですが、とりあえずtar ballでいいですかね。
後usataさんのツッコミに対するツッコミ(^^;なのですが、アカウントの発行で現在できないのはシェルアカウントの発行だけです。メールアドレスやwebの発行はできます。シェルアカウントって実際必要ですか？もちろんサーバメンテナンスをする人には必要ですが、GentooJPのebuild開発者みたいな人には特に必要ないと思っています。専用サーバーになってもそんな多くの人に発行するつもりないです。
4の部分には ebuild uploader が適任だと思いますが、5はどうですかね。
どこかに行って取ってこないといけない、というのはかなりアクティブな
テスターでないとやってくれないと思うのです。emerge sync だと、別に
特別なことを考えなくても全部の ebuild が更新され、それで恩恵を受け
る人もいると思うのです。これが、全部自分で gentoo.org のサイトに行っ
て GLSA をチェックして(あとほしい ebuild が更新されているかどうか
調べて)持ってこい、というのだとかなり疲れそうだなと。emerge sync
とまでは行かなくても、make update くらいで全部最新になってくれる、
くらいならよいと思います。
別のところでも書きましたが、「本家にも入っているあるパッケージの
日本語パッチがあるのだけど、これを当てた ebuild を GentooJP で
メンテナンスする」という場合、手動で持ってくる方式だと、そのパッ
ケージが本家でアップデートされると、それを自分で知ってわざわざ
アップローダ(ダウンローダ?)で持ってきて所定の場所に置かないと、
パッチが当たっていないものが emerge されてしまうことになります。
この部分、あまり意識せず make update くらいで更新されるなら、
GentooJP 開発者の人が適宜 ebuild を本家と sync するように面倒
見ていてくれるのなら、テスターの人はあまり気にせず使えるんじゃ
ないかと思っています。
シェルアカウントに関しては、自分がシェルアカウントほしい人なので、
これがあるとないとではけっこうやる気が違います。まあどうしても
出したくないと言われればそこまでほしいとは言いませんが……。
５の部分，usataさんと全く同じ意見です．先に言われてしまった(^^;
5の部分は、
>で、承認されたebuildは自動でGentooJPのPortage treeへ入ると。そのPortage treeの配布方法はまだ考えてないですが、とりあえずtar ballでいいですかね。
と言いました。まあ、先頭の行がいけなかったですね。そのバックエンドまで含めて僕の中ではebuild uploaderだったんです(^^;
それで、もちろんtar ballを取得して、自分のportage treeへ展開するような、shellスクリプト作ってもいいですね。プロトコロはftpでもhttpでもrsyncでも、まあそれは後で考えましょう。昔jemerge(emergeのwrapper)っての作ったから(ただちょっと都合によりボツ)、そんなのをまた作ってもいいですね。
で、そもそもebuild uploaderを作っている理由はここにあるんです。
wikiとかbugzillaだと添付形式がフリーすぎるので、なかなか自動化が難しい。(自動化せずに開発者が配布まで考えるならいいですが、そこまでは今の人的リソースだと難しいと思うんです)