[Anthy-dev 1312] Re: uim: リリース体制変更の提案

Back to archive index

TOKUNAGA Hiroyuki tkng****@xem*****
2004年 11月 2日 (火) 02:58:30 JST


返事がずいぶんと遅くなってしまいました。すいません。

On Sun, 17 Oct 2004 13:05:38 +0900
Hiroyuki Ikezoe <poinc****@ikezo*****> wrote:

> On Sun, 17 Oct 2004 08:16:59 +0900
> TOKUNAGA Hiroyuki <tkng****@xem*****> wrote:
> 
> >  結局zoeさんの意見は「問題は徳永の頑張りが足りない(テストが足りな
> > い、コードの把握ができてない)事である」という事になると思います。
> 
> テストが足りてないのは、徳永さんだけの問題ではなくて、全開発者の
> 問題だと思ってます。なので、徳永さんが特別責任を感じる必要はないかと思
> ってます。もちろん、「みんなのテストが甘いのは俺がしっかりしてないから
> だ」と思うのは素晴らしいことですが。

 これまでのリリースタイミングが読みにくい状況では、他の人はいつテストし
てよいかわからなかったでしょう。そういう指摘は受けていたのですが、ここま
でずるずる来てしまいました。あと、コミッタは別にテスト要員ではないので、
テストをする義務はないと思っています。(自分のコミット分に関してはある程
度テストしておいてもらいたいですが。)

 他にも変えた方がいいだろうにずるずるやってる部分はあると思うのですが、
自分ではわかりにくいので、指摘がある方は是非メールを下さい。


> 徳永さんに頑張って欲しいのは、コードを把握してみんなをもっとまとめて欲
> しい、ということでしょうか。なんとなくリーダー不在な雰囲気があって、ユ
> ーザーとしては結構不安です。

 私とzoeさんで「まとめる」という言葉に関するイメージが違うのかもしれま
せんが、私にはコミッタの方々をまとめていくつもりはありません。コミッタは
仕事でやってる訳ではなく(期限つきで仕事でやってる人もいますけど)、いわ
ば善意に頼っている状態です。私にはお願いはできますが拘束はできませんし、
するつもりもありません。これまで通り、各自好きな時にコミットする、不安が
あればMLかBTSに流す、という緩やかな形で開発をしていきたいと思います。(
変更点を追うための仕組みの整備やリリースシステムの変更など、できるところ
は改善していきますが。)

 uimの将来に関しては正直私もどうなるかわかりませんが、リーダー不在だか
ら不安というのはよくわからないです。私にとってはソフトウェアの開発が継続
されるか、正しい方向に開発されていくかが問題であって、開発の方針のひとつ
として強力なリーダーシップで誰かがまとめていくというのはアリだと思います
が、全てのプロジェクトがそうである必要は無いと思っています。


> さらにいうと、コミッタの方々についても、全体を把握してる人物がいなくて
> 不安にならないのが不思議なんですが。

 全体を把握している人物がいなくても、プロジェクトがうまく回っていれば問
題ないんじゃないでしょうか。例えばLinuxではLinusは全てを把握していないで
しょう。(プロジェクトの規模が違いすぎますが。)
 ただ、一部を把握している人間が1人しかいないという状況は避けたいと思っ
ているので、そこら辺はどうにかできないかと考えています。


> そういうわけで、とにもかくにも、
> 
> >  コードの把握が出来ていないことにより起こる問題点は、今回の
> > uim-ximでUTF-8ロケールの存在の仮定のような仕様の変更(仕様バグとでも
> > 呼ぶべきですかね)を許してしまう事であり、これに関しては
> > 
> >  * 把握可能な体制を作る、具体的には仕様変更を記録するドキュメントを
> >  作る
> > 
> > 事により解決できると考えています。どのような仕様変更を記録していくか
> > に関してはこれから基準を詰めないといけません。
> 
> この辺に関してすごく期待してます。

 全ての変更を記録していってはただのコミットログになってしまうので、基準
の設定は難しいところです。正直まだ私の中では考えがまとまっていませんし、
これから議論と検討が必要でしょう。これに関しての議論はまたuim @ fdoの方に
振るつもりです。


1. 許容不可能な仕様変更を見付けることが可能
2. 許容可能な仕様変更は見つけられなくても良い
3. できるだけ手間がかからない(コミッタのモチベーションを下げない)

 という条件を踏まえて、

1. 複数ファイルに渡る仕様変更は記録する
2. 複数の関数に使われる関数の仕様変更は記録する

 などを考えてみましたが、どうもまだ粒度が細かすぎるような気がします。す
るのですが、粒度が大きい基準をなかなか思い付けません。結局のところ、この
変更どうよ?と気軽に振る場所がないというのが問題だと思いますが、それをど
う解決すればいいのかはまだ見えてません。


-- 
徳永拓之
http://kodou.net/



Anthy-dev メーリングリストの案内
Back to archive index