プロジェクト管理
Namazu Project の場合
2002/8/30
野首貴嗣
knok@namazu.org
takatsugu.nokubi@toppan.co.jp
(page 1)
開発者となるまで
初期から開発に関わっていたわけではない
熱心な利用者というわけでもなかった
開発に関わり、リリース管理をするに至るまでの道のり
(page 2)
全文検索エンジンとの関わり
freeWAIS-SF
http://ls6-www.informatik.uni-dortmund.de/ir/projects/freeWAIS-sf/
単語単位のインデックス
位置情報を保持
検索ライブラリの整備
perl binding
複数の日本語化パッチ
馬場氏によるパッチ
石田氏によるパッチ
利用者の一人
(page 3)
全文検索エンジンとの関わり
FAQ-O-Matic
http://faqomatic.sourceforge.net/
分散協調型情報入力
Wiki のようなもの
web ベース
認証あり
全文検索機能を内蔵
単語単位のインデックス
英語ベースの単純なもの
日本語化を決意
(page 4)
全文検索エンジンとの関わり
単語分割を行なうソフトウェア
KAKASI + わかち書きパッチ
ChaSen
ChaSen にはライブラリがある
perl binding を作成
FAQ-O-Matic に応用 (1999/01)
この段階である程度全文検索の実装に触れていた
(page 5)
Namazu との関わり
perl binding を Namazu に適用してみた
純粋な興味から
劇的な速度向上があった
実行時間が約1/5に
ref.
http://www.namazu.org/ml/avocado/msg01619.html
その機会に開発へ参加
(page 6)
作業遍歴
filter の module 化
mknmz からフィルタに関するコードを分離
より modulable に
さまざまな種類のファイルに対応可能
client の library 化
namazu.cgi を library 化
検索クライアントを内蔵できるように
perl binding も作成
これらを通して全体をある程度把握できるようになった
プロジェクト管理も交代可能な状態に
(page 7)
管理体制の変遷
初期
Linux 的モデル
パッチのとりまとめ
コードの整合性
リリース
これらを一人で
CVS の導入
複数人で同時にコードを保守
main trunk しか利用しない
(page 8)
管理体制の変遷
branch の導入
他のプロジェクトを参考に
Linux
versioning
FreeBSD/NetBSD
HEAD を開発版に
stable 用 branch を作成
機能拡張は HEAD へ
bugfix は HEAD, branch へ
(page 9)
メーリングリスト
namazu-devel-ja
183 subscribers
1 mail/day
namazu-devel-en
39 subscribers
1 mail/month
参考
namazu-users-ja
1049 subscribers, 2 mail/day
namazu-users-en
65 subscribers, 1 mail/day
namazu-win32-users-ja
611 subscribers, 1 mail/day
(page 10)
コード量の推移
(page 11)
コード量の推移
(page 12)
コード量の推移
(page 13)
コード量の推移
(page 14)
リリースマネージメント
リリースのタイミング
bug 修正が完了するまで待つか
告知
web
mail
freshmeat/slashdot
gpg sign
改竄防止
個人の鍵で sign
Debian Project member 数人に sign されている
(page 15)
協調作業
HACKING(-ja)
コーディング規則の明文化
完全徹底とまではいかない
CVS
stable-2-0 branch
安定版
bug 修正が主
HEAD
開発版
機能拡張はこちら
ML での調停
commit 前にレビュー
(page 16)
現状の問題(技術層)
停滞傾向
ほぼ bug 修正のみ
実用上の問題はあまりない
根本的な問題
多言語化
single byte なら現状でもなんとか?
非ファイル対応
入出力の抽象化が必要
(page 17)
現状の問題(政治層)
停滞傾向
みんなもう飽きた?
MIA (Men In Absence) 問題
連絡のとれない人が committer にいる
21人
ここ半年でcommitしたのは6人
(page 18)
今後について
2.0 branch の維持
bug 修正
securify fix
remoteから影響のあるものは重点的に
2.1/2.2
リファクタリング
ファイル入出力の抽象化
3
完全に rewrite
scalability の確保
多言語対応
... 妄想で終わるかも?
(page 19)
教訓
security の重要性
注意深くコーディング
流行は押さえる
buffer overflow
format string bug
special character
cross site scripting
SQL injection
周知徹底
announce ML の作成
未だ古い version が使われている
(page 20)
教訓
根本的な修正の必要性
ad-hoc patch は長期的にはマイナス
Windows 対応に悩まされる...
リリースのバランス
使えることが重要
変化への追従
filter application
興味のない hack は苦痛
興味のある hack に逃避
自分が欲しい機能を実装
(page 21)
なぜ続けるのか
ソフトウェア職人気質
自己研鑽
責任
評価
(page 22)