hogeとはワイルドカードのようなものです。日々起こった、さまざまなこと −すなわちワイルドカード− を取り上げて日記を書く、という意味で名付けたのかというとそうでもありません。適当に決めたらこんな理由が浮かんできました。
10/15/2003 うは
■ [Gentoo] うは
GentooJP のメーリングリストに流そうと思ってたんだけど何やらusataさんからのつっこみやなかのさんからのつっこみが先に来てしまったようなのでこちらに…．
えーと，まずmanページというのは portage 関連のmanページのことです．これについては既に GentooJP の方で翻訳作業が行われているようなので気長に待ってはいるのですが(ごめんなさい)．
また，翻訳にしても査読にしても管理にしても，ML でも何名かの方が言ってらしたように，具体的に何をすれば良いのか分からない，という方が多いと思います．かくいう僕もその一人です．翻訳などのように「宣言する→翻訳する→できたよー」という簡単に想像できる流れのものであれば良いのですが(それに，この流れについては GentooJP の Web サイトに記述がありますね)，査読，管理のことについてはよく分からない*1というのが正直なところです．これは僕の個人的なことですが，何をするのかよく分からないのに手を挙げることにはちょっと抵抗があります．ebuild にしても翻訳関係にしても，具体的なものやガイドラインみたいなもの(あくまで JP 内での)があると良いのかも知れません．
あと，GentooJP に活気がないように見えるのは，Web サイトの更新頻度が低いからであるように思えます．ML で桜本さんがおっしゃっていたように，Gentoo 関連の皆さんの日記を読んだり航海日誌を読んでいると，別に活気がないわけではないと分かります(そういう意味でも航海日誌を GentooJP 上でやると良いと思ったわけなんですが)．そういった水面下の活動を表に出す役割を GentooJP の Web サイトが担うと良いのではないでしょうか．ただ，それには Web サイト管理の他に，活動報告のようなものが必要になってしまいますが…．
ついでに言うと，現状の GentooJP は，メンバーの皆さんがまとまって動いているように見えないです．これも一因となってるように思えます．これは「GentooJP としての」活動ではなく個人単位で皆さんが活動しているからだと思うのですが，いかがでしょうか．
ebuild の commit のする／しないは，そういうことであれば，
本家 ←→ コミッタ ←→ JP 内部の ebuild 開発者
という形を取れると JP のコミッタの負担を減らせると思います．例えば，
- JP に投稿された ebuild をコミッタ(必要であれば複数ででも)が査読し，問題なさそうであればコミット
- 問題が出た
- コミッタが投稿者に問題解決を振る
- 解決したらコミッタに連絡
- コミッタがコミット
もちろんこの簡単なプロセスのどこかにテスト段階が入ると思いますが．
また，このモデルは投稿の場合だけでなく，普通に割り当てられたバグ解決にも役立つと思います．長い目で見ると開発者を育てることにも繋がると思いますし．:-) コミッタが本家と JP の二つの場所に気を配らなければならないという点がありますが，現状の wiki も似たものがあると思いますが，いかがでしょう．幸い ebuild に興味を持っている人は結構多いと思いますので，そういった人を広く集めて…という感じですか．
そういえば wiki の方の雑談で Bugzilla の話が出ていましたが，Bugzilla でこれをやるというのもいいかもしれません．
あ，これは全然関係ないけど JP の ML の方で「本家 ML でこんな話題が上がってるけど，どうよ？」みたいな話合いも有益かも．
なんか全然まとまってないですけど，僕の考えとしてはこんなもんです．
*1 まぁ，管理については実際に作業に携わったことのある人がやるべきだと思いますが
10/15/2005 むう
10/15/2006 むー
■ [日記] むー
ffmpeg のオプション多すぎてすぐ忘れるので適当なスクリプトにしといた．
#!/bin/sh
IN="${1}"
TITLE="${2:-${IN}}"
OUT="${3:-${TITLE}.avi}"
nice -n 10 \
ffmpeg -i "${IN}" -title "${TITLE}" -s 640x480 -ac 2 -f avi \
-b 1200 -aspect 4:3 -vcodec mpeg4 -nr 150 -qns 3 \
-acodec mp3 -ab 192 -vol 13107 \
"${OUT}"
ボリュームがやたら巨大なのは ivtv の不具合への涙ぐましい対処．しかしノイズがひでー．
10/15/2009 あー
■ [日記] やはり眠れん
ので何か書くか．
故あって python 自体のコードを一部読んでいるのだけれど，Py_BEGIN_ALLOW_THREADS と Py_END_ALLOW_THREADS マクロがなかなかアレゲだなあとおもいました まる
ところで file#readline って getc/getc_unlocked で一文字ずつ読んで改行コード判別してたのね． file#tell のためとかかなー． file#next は 8192 バイトざっくり読み進めるから file#tell が腐るんだよね．
いかんせんマクロが多いコードを読むスキルが低くてしんどい．cpp 通して読む方がよかったりするんかなー．
へー
Python の GIL は POSIX 環境の場合 Semaphore なのか．
□ なかの [MLに書いてもらえると嬉しいです。改めてそれに返信しますので・・。 ]
□ atzm [投稿しました．よろしくお願いします．:-) ]