AIDA Shinra
aida-****@jcom*****
2002年 10月 21日 (月) 20:35:57 JST
相田です。 > 狩野と申します。9 年半『かんな』を使い続けている一ユーザです。 > > 使い始めた頃は文法ファイルや辞書の改良をいろいろ行っておりました > が、ここ 5 年ほどはほとんど手をつけておりません。個人的な関心が > 文字コードやフォントの方に向いていたせいもありますが、アルゴリズム > の変更無しで可能な変更はすべてやり尽したと感じたのが主要な原因です。 > > とはいえ、いくつかやり残した仕事も残っています。 > 例えば、辞書の誤字などは早急に修正する必要があります。1994 年頃に > pubdic+ という別プロジェクトを立ち上げて辞書全体を分担してチェック > したのですが、それでも「脳硬塞」「飛抹」のような誤字が残っています。 誤字の類なら、パッチを投稿していただければcommitします。すぐに用意でき る分だけでも構いません。また、狩野さんは日本語処理にも詳しいようなので、 アルゴリズムのアイデアや現状の問題点など、どんどん指摘してください。 > > 新しく開発を始めるにあたって、まず、バグ報告やパッチなどの手順を > どのような物にするか、方針決定をどのように行うかというプロジェクト > の運営方針についてお聞かせ願えないでしょうか。 > > 参加者が全員 sourceforge.jp に登録して各自 commit するとか、 > ML にパッチを投稿してプロジェクト管理者が一元的に commit するとか > さまざまなスタイルがあり得ますが。 3.6は保守的にやりたいので、私が一元的にcommitします。その後のことにつ いては、人も集まり始めているので、きちんと検討する必要があるでしょう。 私の案としては、安定版、開発版を分けて、 1. 基本的には各自でcommitしていく。 2. 開発版はほぼ何でもあり。ただし、非常に大きいもの、互換性のないもの はMLに一回流し、他の開発者から異論が無いようならcommitする。 3. 安定版は、開発版で実験して大丈夫そうなもの、互換性を損なわないもの を入れる。これも、大きいものは確認を取る。 4. ただし、文法データ、辞書、ドキュメント、セキュリティ修正はいきなり 安定版に入れてもよい。 5. 確認を取る必要があるかどうか等は各自の判断に任せる。 6. リリースはこまめに行い、特にfreezeなどは行わない。 7. 同じところを修正している、ということが無いよう、大仕事は作業を始め る前に一応言っておいた方がいいかもしれない。 というスタイルを考えています。ただ、私はオープンソースのプロジェクト運 営などの経験はないので、甘い部分もあると思います。経験者のアドバイスを お願いします。 あと、狩野さん、いぎさん、もし良ければ開発者に登録しますので、アカウン トを取ったら教えて下さい。いぎさんはプログラミングの知識がない、という ことですが、腐ったmanページを始末したり、まともなwebページを作ったり、 おまけのスクリプトを書いたり、仕事はいくらでもあると思います。取り敢え ず、-inet,-uオプションの記述、「今後wcKanji*系関数は外から使わないでく れ」という記述の追加をお願いします。 ---------- AIDA Shinra
