ToDo:
なにやら大変面白い話が。
http://d.hatena.ne.jp/IwamotoTakashi/20091006/p1
http://d.hatena.ne.jp/ku-ma-me/20091010/p1
http://akimoto.jp/blog/2009/10/08/bug-report-in-foreign-language/
個人的な感覚では、オリジナルの報告者の方も 最初に close した PHP の人も、 その後のいやこれは dup じゃないんだという主張も、 その後の直してくれるまでのやりとりもごく問題ないように見えるかなぁ。
なんか気になるとしても本当に細かい点で。
指摘されてる通り、 オリジナルの報告者が謙譲しすぎっていう点については、 これ要するにパッチには自信無いけどたぶんこんな感じでいいよね、 って言いたいってことなんだと思うんだけど、 まぁそいうのはよくあるからきちんとそう書いた方が 良かったかなぁというかんじはする。 これだとレポート自体に不穏な空気を出してしまうのはそうだし。 でも本当にこんなのは細かい点で。
あとは最初の php.net の人の応対だけど、 まぁどれと dup してるかくらいは言ってよ、 って感じではあるけど、 これもこの対応見るだけで判断すると、 そんなにひどい応対とは思えないなぁ。 仮にこのバグを reopen して、もう一度理由を示されず close されてたとしたら それはひどい人だと思うけど、 この程度だったらまぁ忙しいプロジェクトの バグ管理とか多少雑になっちゃうのはしょうがないと思う。
バグの数が50000とかになってるプロジェクトなんだから (10年やってるわけだけど単純計算で1日10個とかだよねえ…)、 多少ミスがあるかもしれないけど適当に バグの dup 判定とかをざっとやって、 それでお前それ違うヨ! って言われたら もうちょっとちゃんと判断する、みたいな 雑なスキームになっちゃうのはしょうがないように思う。
だからこの応対だけではこれはひどいとは思えないかなぁ。 懇切丁寧な方がそりゃいいんだけど。
でまぁ、エスパーじゃあるまいし実際そいう事情があるかは知らんので、 報告者の方がそのへんを察するべきだった! とかいう主張をする気も全くなくて、 絶望した! とか思っちゃうのもしょうがないと思う。 それでもちゃんといやこれ dup じゃない気がするんだ と言ってるのもすごくいいと思う。
そんなこんなで僕的にはごく普通の bug repot → fix の流れのひとつに見えたようにおもう。
ちょっと改善できたらいいかなぁと思ったのは はてぶとかしてる人で実際に PHP のそのバグを 困るものとわかってる人は、 バグに対して賛意を示してあげたりすると目立つからいいと思うんだよな。 できれば補足説明とかしてあげられるといいけど、 "+1 for this bug" とかだけでもいいように思う。
あと個人的には秋元さんの意見には 一般論としてはあまり同調できないなぁ。 そういう(すごく丁寧に説明する)やりかたも アリっちゃアリだとは思うんだけど、 個人個人のリソースは限られてるんだし、 適当に短いバグレポートをほってみて、 それだけで直してくれたらラッキーだし、 反応が無いようなら重要度に応じてあきらめてみたり ping してみたり、 伝わってない部分があればそこを細かく説明してみたり、 という感じで適当にやればいいんじゃないかなぁ。 伝えるのが難しそうなら日本語でブログ書いて応援求めるとかも すごくいいように思う。
例えば英語とか書きたくなければ、 there is a bug: <再現するコード>, expected: <hoge>, actual: <bug!>、 とかだけでもたぶん良いわけで。 実際 WebKit のバグとか見てる感じでは、 最悪再現する URL だけでも良くて、 できれば再現する最小の html なりなんなりにしてくれると良くて、 さらにそのまま test として使える程度にわかりやすい html だと (緑になるべきだけど赤くなるとかそういうやつ) なおよい感じかな。
直す側に回る時はそのバグの深刻度とかは 正直どうでもいい情報でしかなくて、 開発者側の priority 見積りは信用できないから 急いでなおして欲しい! と思うなら書く、 くらいでもまぁいいんじゃないかなぁ
そいう意味で秋元さんご自身のバグレポートの例それ自体は、 これはこれでこの事情ならこのくらいきちんと説明しないと ドコモのほげほげの事情とか知らんだろうし、 丁寧に説明しておられたのはそれはそれで適切な気がした。 普通に考えるとそんなよくわからんバグに priority あげられないからねえ。
(17:59)
| 前 | 2009年 10月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
んー、雑になるくらいならやらなきゃいいのにって思っちゃうんですね。仕事じゃないんだし。
雑なスキームをとるとしても、反論の材料も与えず、「お前それ違うんじゃない」とも言われたのに無視、というのはひどいと思いました。
しかも今回は security reasons とか言われているので、もっと慎重に扱うべきかと。
それをあの対応で、しかも他に誰も反応しないのは、PHP ってやっぱり……とか思っちゃいました。
ただぼくが言いたかったのは、contributor をむやみに discourage すんなよ、という方なので、そっちはまあどうでもよかったりします。
うーんまぁ書いたように雑でも放置バグ大量に残ってるよりは処理してく方が良い気がしますねぇ。
あと僕メールを1ヶ月程度忘れたりとかよくしますし、正直3日置いとかれたくらいなら無視とかいう感じもしないんじゃないかなぁ…とか思います。いや contributor 側としては自分の提案がどうなるかどうか気が気じゃならないとかそいうのはわかるんですけど、まぁ相手もなんか急ぎの用とかあるかもしれないわけですし。
あ、あと僕のイメージでは ruby-core も patch 放置 and/or 遅い反応を結構見るような…! あとなかださん以外の日本人を全然見ないとか。いや ruby を責めたいわけじゃなくて、まぁ、開発者も忙しいんだし、ある程度 discourage しょうがないんじゃね? とか思っちゃう感じですかね。
わたしもほっとくよりはrejectって感じかなぁ。
ruby でも仕様変更のパッチは高確率で放置じゃないかな。
後は大物の混在パッチとか。
たまに分割してパッチを作り直せってコメントとともに reject してまわってます。
Rubyは議論して仕様を固めないと−、
Google だと design docs とか言うんですっけ、
まずそっちが先なので、いきなりパッチ投げてもダメなんですが、
それが分かってないとたいてい泣くよね。
あーなんかその手の contributor が知ってるとトクなプロジェクトごとの文化みたいなのはお互い難しいですよね。プロジェクト側としては簡単なガイドみたいなのがあるといいんでしょうけど、簡単なガイドでは細かいところはわからんし、細かいと読むのめんどうなんですよね…
3 日くらい、とは最初ぼくも思いましたが、よく見てみると、報告があって 30 分で「重複すんな」といい、さらに 30 分後に「どの番号ですか」といわれ、彼はその後も他のチケットに返事つけてるとか活動してるので、無視と思われてもしょうがない態度だなーと。もし PHP のあのバグトラッカーがコメント追加に気がつきにくい残念なシステムだったら申し訳ないです。
報告者が粘り強い人とは限らないですよね。security 関係といわれてるバグ報告を無検証で reject して、報告者が諦めてしまった場合、クラッカーが攻撃の方法だけ知ってる状態になって最悪クラック祭り開催です。というか、security 関係のバグ報告を分けてないのかな。ぱっと見では見つからない。
あと「否定だけすぐして放置」と「最初から放置」なら後者の方が多少マシと思っています。拒絶されたわけではなく忘れられたんだとわかるので。「訴状を読んでいないのでコメントできない」みたいな。
でも重要度の低そうなバグや新機能の話とかなら、ある程度雑なスキームもありかなと思うようになってきました。
http://bugs.php.net/report.php
に太字で
If you feel this bug concerns a security issue, eg a buffer overflow, weak encryption, etc, then email security@php.net who will assess the situation.
と書いてありますね。
おお。http://www.php.net/mailing-lists.php と http://bugs.php.net/ の辺りまで見て、そこまでたどり着けてませんでした。
そっちに送るのが最善だったかもですね。