開発業務で trac を使う場合の問題点

議論の要旨．まずは，id 問題．

nym

id 詐称が容易に可能な状態だと，情報の信頼性が落ちる．

ex. 信頼できそうな人の名前で情報の書き換えができる．＜ぱっとみで正しい情報化どうかが判別できない．＜最悪，その情報に基づいてプロダクトにそのまま反映されてしまう危険性．

某氏

wiki ってそもそもそういうもの．個を特定することも重要ではない．

閉じたメンバーでの開発業務ならなおさらで，性善説に基づけばよい．

某氏の意見も分かるには分かるのだが，nym のポリシーとは少し相容れない部分がある．宗教問題をはらむ気がするので，あまり深入りせずに容易に解決できる問題かどうかを nym が調査する．＜個人的に．ticket を簡単なワークフロー業務に適用できないかなと思っていたけど，このままだと使えないし．

次．グローバルな設定について．Debian だと，trac/siteconfig.py がパッケージをアップデートする度に書き換えられてしまうのがいや〜んなところ．

nym

システム全体のメンテナンスは，基本的に apt で行っているため，別のオペレーションは極力避けたい．アップデートでも影響されない設定方法があれば，それを採用することは問題ない．

某氏

別オペレーションが発生したとしても，実現させたい．

これも nym が検討．

以下，調査状況のメモ．まず，id 問題．

• POST パラメータを横取りして上書き．＜コンテンツハンドラの前とか，一段かませて trac のハンドラを呼ぶ前とか．
  • メリット
    • 実装が楽．
    • パラメータ author, reporter を常に書き換えれば良さげ．
  • デメリット
    • 美しくない．
    • 前ページが authen handler による認証を通っていない場合は，ちょっと面倒．＜セッション情報を引っ張ってこないといけない．
    • 実行時の処理が冗長になる．
• インストールパッケージを自前で作る．
  • メリット
    • がっつりと手を入れるならよいかも．
  • デメリット
    • 面倒くさい．
    • パッケージの作り方が良く分かっていない．
• WikiModule 等のコンポーネントを乗っ取る．
  • メリット
    • 美しい．
  • デメリット
    • インターフェイスの変更に注意しなければならない．
    • 継承したクラスの登録って可能?
• プラグインとして実装できないかなぁ．
  • 無理っぽい．＜コンポーネントを作る(つまり前項の話)のであれば可能だけど．
• テンプレいぢって，当該のフォーム要素を delete or disable
  • 論外なので，却下．

グローバル設定．

• 独自のパッケージを作る
  • 面倒くさい．
• trac コンテンツハンドラを一段深くして，手前で trac.siteconfig を書き換え
  • よさげ?

今のところはこんな感じ．