How to motivate (Re: Bug#JP/1023: Debian-JP maintainer is not accepted)

[Taketoshi Sano <xlj06203@nifty.ne.jp>]

佐野＠浜松です。

In article <14330.14514.722297.8570I@lavender.ukai.org>
 Fumitoshi UKAI <ukai@debian.or.jp> さん writes:

> At 01 Oct 1999 22:30:41 +0900,
> Taketoshi Sano <xlj06203@nifty.ne.jp> wrote:

> > 私自身も、ある程度そういう「練習台」としての場所を JP Project が
> > 提供する、ということがあってもいいんじゃないか、と思ったりもしてます。
> 
> 練習ならいいですけど、現状では作りっぱなしなパッケージが多くありませんか?

「多く」かどうかわかりませんが、JP Package の中にも Bug を集めていて
 Close していないものがあるのかも。

と思って、今 http://www.debian.or.jp/Bugs/ を見てみましたが、
 <http://www.debian.or.jp/Bugs/db/ix/packages.html> にある report を
 Bug の数が多い順に sort すると

   debbugs-jp 5
   linuxdoc-sgml-ja 3
   jnethack 3
   gs-ja 3
   gs-aladdin-vflib 3
   ftpmirror 3
   xperfmon 2
   xbatstat 2
   www.debian.or.jp 2
   webmin 2
   tknamazu 2
   libjcode1-dev 2
   grub98 2
   ftp.debian.or.jp 2
   fml 2
   dyna2 2
   doc-debian-ja 2

ですね。これ以外には Bug の数 1 なパッケージが 57 個。

# ページの内容をテキストに落して
#   awk '{print $1, $2}' chk.bug.jp |sed -e 's/(//' -e 's/no/0/'| \
#   sort -n -k 2 -r |head -20 
# でソートしました。

Debian のように「驚異的にバグを集めまくっている」といった
パッケージは JP には無いようです。

ただし、Report は出ていなくても

> あと debian にもっていこうとした時の作業量がまだまだかなりあるような
> 印象があります(== 現状のJP Packageの品質はよいとはいえない)
>
>  * copyright check が杜撰
>  * manpage がない
>  * lintian free じゃない
>  * 簡単に fix できるようなバグでも fix してない
> 
> などなど

こういった問題はあるかもしれません。ただ、これについては

>  Debian に ITP されないパッケージは みなしごパッケージとしてあつかう。
>  最初に packaging した以外誰でも早いもの勝ち (Debian で ITP する)で
>  maintainer になれる。それまでは QA team がメンテしている扱い。
>  (debian-qa@debian.or.jp を作るべきかな…)

こういった対処方法がベストの選択なのか、という点には疑問が
あったりします。

もちろん、JP Package はすべて Debian に merge していくのが
目標であり、そのための布石は打っていく必要があるでしょう。

こうやって公開された ML で議論していくことも、認識を共有していくための
ひとつの方法であると思います。

ただ、現在の方法だと Official Maintainers に負担のかかっていくだけで、
 JP Only な人がどうやって作業を分担していけばいいのか、明確になって
いないのではないかという気もするのです。

Debian の QA reconstruction は「やる気のある人がどんどん NMU できる
体制を作ろう」ということだけではなくて、「時間や skill の問題で
あまり QA に貢献できていなかったメンバーに対して、もっと手軽に
 QA 作業に参加できる体制を作ろう」ということでもあると思います。

この後者のほうについても、何か対策を考えていくべきではないかと
考えています。

JP に upload されたパッケージは、何がなんでも Debian に
持っていかなければならぬ、というのでは負担が増え過ぎだと思うので、

   "easy to include, easy to remove" 

を原則に、

>  * copyright check が杜撰
>  * manpage がない
>  * lintian free じゃない
>  * 簡単に fix できるようなバグでも fix してない

これらの問題について気がついたらどんどん Bug Report する、
そして一定期間 (半年 ?) Bug Report に反応が無い場合は
自動的に orphan/remove とする、というほうがいいんじゃないかと
思います。

反応はしたけれど、どうやって対処したら良いかわからないという場合には
 -devel@JP なり -devel@Org なり、あるいは -mentor@Org なりで質問して
いくことを奨励し、もちろんその活動中は最大 1 年 orphan/remove しない
ということにします。

またどうしても解決できない場合は NMU を依頼するか、あるいは自分で
 orphan/remove することを選択できるようにする、ということも選択
できるようにしましょう。

要は「ふっと思いついた時にすぐ (NMU の形で sponsored して)
 Debian に持っていける状態」な JP Package が増えていけば良いわけで、
そのためにはより多くの人の力を集められるようにするべきだと思います。

また、おそらく最初にパッケージを作って JP に持ってきた人は、自分の
パッケージにそれなりに愛着があるはずだから、Bug Report にもちゃんと
対応しようとしてくれるんじゃないだろうか、という期待が上記の提案の
背景にあります。

Bug Report に対してまったく反応しない、それこそ「作りっぱなし」な
パッケージは remove しても問題無いでしょう。そういう場合はもう
パッケージのメンテナンスに興味を失なっているのでしょうから。

技術が未熟でも、知識が不足でも、やる気さえあれば、後は何とかなる
ものだと考えています。「やる気」があるかどうか、という点が最大の
問題であって、 official member であるかどうかという点は実はあまり
問題じゃないと思ってます。

> > 一方、今回の JP Merge でも、今まで (すくなくとも私は) あまり考えて
> > いなかったような upstream へのフィードバックとか、日本語パッチを
> > 分類整理して Debian パッケージに当てやすくする作業とか、Debian の
> > メンテナーが出してきたコードのチェックとバグ出しとか、このへんの
> > 作業が手薄だなあ、という感じを受けたりしてるので、そういう方向に
> > もっと振っていくためにはどうしたらいいかな、とか考えたりすると
> 
> そうですねぇ、このあたりがかなり手薄だと思っています。

このへんの作業に焦点を当てていくためには、 sub project というか
タスクチームを編成していったほうが良いかもしれません。

# 問題は、やろうという人が不足していて、おそらくほとんどの分野で
# 個人作業が主体となってしまっていることだと思う。

> > Debian の New Maintainer や keyring の作業が今すごく遅れているのは
> 
> これはそろそろ状況がかわりそうですね。

今はいろいろと激しい動きがありますが、どっちに振れるかまだわからない
という気もしています。

 Marcus Brinkmann <brinkmd@debian.org> や
 Raphael Hertzog <rhertzog@hrnet.fr> は信用できそうですが、、、

-- 
     ＃ 11/13 に何かが起きる? > "http://www.szlug.factory.to"
     ＃ (わたしのおうちは浜松市、「夜のお菓子」で有名さ。)
    <xlj06203@nifty.ne.jp> : Taketoshi Sano (佐野　武俊)