この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2007年2月)

2007年2月3日

Bug 5526 [Cairo][Mac] font-size-adjustのサポート 初回投稿日時: 2007年02月03日01時41分42秒
最終更新日時: 2007年02月03日02時11分40秒
カテゴリ: CSS Mozilla Core
固定リンク: id=2007020300
リンク元: 0件
SNS: (list)

Macでも実装完了。

しかし、どうも私の実装は間違っているのではないだろうかという感じがしてきた。仕様書の文言をイマイチ完璧に理解できていないのだが、

This property allows authors to specify an aspect value for an element that will preserve the x-height of the first choice font in the substitute font.

とある。どうも、font-familyの最初のフォント(ただしシステムに存在するもの)に対して調整を行って、二つめ以降のフォントには一つ目の算出結果と同じフォントサイズを適用すべきであるように読み取れる。(今のtrunkの実装はフォント毎にx-heightを調査して、別々のフォントサイズがフォント毎に設定されてしまう。)

the first choice fontは最初のフォントじゃなくて、コンテンツ作者が想定したフォントを意味するようだ。(他の段落の文章を読んでいるとそう読み取れる。しかしややこしい。)

2007年2月8日

Re: httpsだと思ってたらhttpで通信することになるような場合、Firefoxはキャンセルできないことが多い 初回投稿日時: 2007年02月08日05時10分36秒
カテゴリ: Mozilla Core
固定リンク: id=2007020800
リンク元: 11件
SNS: (list)

なんかまた変な記事が出ているぞという話を見かけたので。

詳しく検証していませんけど、ざっと読んだ限りではhttpsのページからhttpで何か情報が送信されるとまずいという話のようですが、HTML中の何らかのリンク(例えば画像)等でGETのパラメータ等で何かを投げようとしているのであれば、送信前に警告が出るようにしていれば警告が出ると思います。(多くの人はこの設定を初回の警告時にオフにしちゃってるでしょうけれど。)

それ以外の方法(リライトを利用したりとか)での送信は防ぎようが無いですけど、それってhttpのページでも結局同じ事が言える訳で、そこまで気にするならフル機能のモダンブラウザって、そもそもその人には向かないものなんだと思います。(つまり、多機能なブラウザを使う上では仕方のないリスクだと思います。また、そう考えるとURIのリライトって危ない仕様ですね。)

そもそも、httpsで情報の送信を全て暗号化しておいて欲しい(そういう必要がある)ようなサイトでhttp通信を使っちゃっているというのは、UAに過失が無いとは言いませんけど、どちらかというとコンテンツ提供者に過失があるように思えるんですけど、そういう根本的な話は無視されているようで。

その後のhttpsからhttpへのリンクでの移動をキャンセルできないという話は言いがかりにしか思えません。そこまで気にする人なのに、リンクをクリックする前にステータスバーを見てないんでしょうか? また、普段はhttpなサイトではリンクはいっさいクリックしないような運用をしている人なのでしょうか? これではケチをつけたいがために書いた文章のように見えます。

最後に画像の件ですが、セキュリティバグのままではありますが、bugzilla-jpにも報告あがってます。また、本家では公開済みのセキュリティバグとして登録されています(bug-org 135007)。

これは本家のバグが公開されているので、世間的に既知の問題なので良かったのですが、それへのリンクが無いところを見るとどうも問題のblogの作者さんは、そのこと自体を知らないようにみうけられます。もしそうであるなら、セキュリティに関する話を適切に報告せずに世間にいきなり喧伝するという行動が感心できません。プロダクトへの批判は良いんですけど、セキュリティに関わる話題の場合は、それを使っているユーザがいるわけですから、そのへんのことももう少し考えて気を使って欲しいなぁと思います。

Bug 5571 [cairo][pango] 一部の文字が表示されないことがある 初回投稿日時: 2007年02月08日05時18分49秒
カテゴリ: Mozilla Core
固定リンク: id=2007020801
リンク元: 0件
SNS: (list)

Linuxで文字が表示時にのみ消えることがあるというバグ。修正済み。

原因は単に複数回走る可能性のあるコードで適切に変数の初期化を行えていなかったのが原因。a2には間に合っているので安心して欲しい。

Re: 感性で動く 初回投稿日時: 2007年02月08日17時01分25秒
カテゴリ: 雑談
固定リンク: id=2007020802
リンク元: 0件
SNS: (list)

Piroさんの言いたいことは理解はできるんですけど、発言した内容を「生理的に」嫌われるのはどうしようも無いかと思います。(以下、ただの愚痴。)

身分を明かしてblogやるってのは、メリットもありますけど、それ以上にリスクが異様に大きい訳です。Piroさんのいつぞやのエントリにもあった気がしますが。

昨日の件も、書く必要が無かったと言われりゃ、そうなのかもしれないです。怠惰な発想をするなら、自分にリスクが無い道を選んだ方が利口なのかもしれません。でもやめてしまうと、今度は情報発信する気が無いとか、閉鎖的だとかそういう話になってくるんでしょう。(私も外部から見たらそう思いそうです。) つまり、黙ってりゃケチがつかないとは限らない。

かといって、何らかの行動を起こすと賛同する人も居りゃ、ケチを付ける人もやっぱりいます。各種イベント、フォクすけ、例のビデオ等々考えてもらえれれば分かるかと思います。でも、ケチを恐れてたら何もできない訳で、前に進みたけりゃリスクを冒さないといけない。ケチの内容によっては反省すべきものもあるでしょうけど、大抵は織り込み済みというか、想定できたものだったりしますし。(ケチを付ける人は万人受けするという前提で行動を起こしているかのように錯覚しているところが興味深いところなのかもしれませんけど。)

何かをやろうとする場合、万人受けなんてのは幻想で非常識な発想でしか無いということを前提に、ある程度の割り切りは必要です。そのバランス取りに失敗した場合に初めてその行動が失敗だったと言える訳ですが、そうじゃない場合は成功なんだと私は思います。

2007年2月9日

Re: Re: Re: httpsだと思っt(ry 初回投稿日時: 2007年02月09日03時14分43秒
最終更新日時: 2007年02月09日06時47分34秒
カテゴリ: 雑談
固定リンク: id=2007020900
リンク元: 5件
SNS: (list)

リライトって何ですか。Apacheでmod_writeを使って行われるあの処理のことでしょうか。それが何か今回の話に関係してるんですか。

おっとすいません。一般的な呼称じゃないんですかね。mod_rewriteのことです。

で、前回のエントリでは、「httpsのサイトからhttpで通信が行える、なおかつFirefoxはそれを通知するのみで中止できないのは問題だ」という論調から、セキュリティの問題を論じているようにしか私には読み取れません。そして、中止できないのはセキュリティ上マズイと考えた場合、ぱっと思いついた情報の送信方法がgetによる送信と、mod-rewriteを利用してgetの内容を普通のURIと見た目変わらなくしての送信です。getは明らかにデータを送信しようとしているのでUAが警告を出すことは可能ですが、後者は防ぎようが無いという話です。

httpsのページの中にhttpのコンテンツは埋め込まない方がいいとは個人的には思います。でも、仮に埋め込んだとして、それがコンテンツ提供者の過失かどうかはまだわからないと思います。

私はコンテンツ提供者の過失だと言って良いと思います。断り書きがなければ許されるというのは好ましいことではありません。

それはさておき、Firefoxが通信をキャンセルできたとしても許されることじゃないし。とのことですが、前のエントリのページ自体はhttpsでも、その中にhttpのコンテンツが埋め込まれる場合があります。という文言からそれは読み取れません。あたかもそういうことが当たり前のようにあり、それを中止できないのは非常にまずいことであるかのように書かれているように読み取れます。(中止できた方が良いということには私も賛成ですが。)

あなたの今回のエントリには中立的な視点での文章が散見されますが、前回のエントリはそうは見えません。一方的にFirefoxのセキュリティは駄目だという結論の元に、わざわざ侮蔑をこめた言葉(例えばイエスマン)を選んでいる文章だと感じます。

それに、「リンクをクリックした後の遷移先は常にステータスバーに見えているとは限らない」ということを知ってて触れないのはいいのですか。

おっしゃるようにステータスバーの情報は常に信頼できるものではありません。(Bug-org 229050)

まあFirefoxがもし私専用のソフトなのであれば、私はステータスバーを見るタイプなのでケチを付けないかも知れません。でもそうじゃないので。

で、このコメントに戻りますが、もし、一般的な(大多数の)ユーザを想定して書いた文章なのであれば、そういうユーザで「いいえ」が押せないことを不思議、もしくは不満に思うユーザはごく少数でしょう。また、その人たちはおそらくあなたが指摘するようにステータスバーを見ないでしょう。

逆にセキュリティに対するリテラシが高いユーザであればステータスバーの確認や、「いいえ」が無いことへの不満にも納得がいきます。

私はこの件をUIの問題だと思ってました。さらに言えば「問題」よりも、「IEとFirefoxのUIの差」ですね。もっと厳密に言えば「IEと、一般にIEよりも安全だとされるFirefoxのUIの差」。

(中略)

なので、この事象(警告が出ないこと)がバグだったとしても、それセキュリティ上のバグではなくUIのバグなんだと思いました。

何故セキュリティ上の問題とUIのバグとを分離しようとされるのか理解できないのですが、結果的にあなたは前のエントリの最後でIEとFirefoxのどちらが安全であるかという不毛な議論の結論を導こうとしています。セキュリティに関係の無いUIの話でFirefoxは安全では無いという話だったのでしょうか?

私には未だに前回のあなたのエントリはセキュリティに関する話題を提供しているようにしか読み取れません。あなた自身もそのことを一考されたようですし。ならば何故そのまま情報の公開に至ったのかその経緯があなたの説明を読んでも理解できません。より良いアイデア(IEと同様にYesNoの問い合わせをすべき)と、imgの問題を知り得た訳ですから、やはりベンダかIPAに問い合わせるべきだったと私は思います。(結果的に既知の問題のみでしたが、もし、未知の問題であれば、あなたはすごい人数のユーザを危険にさらしていたかもしれません。)

Bug 5585 プライマリディスプレイ以外ではメニューが正しい位置に表示されない 初回投稿日時: 2007年02月09日03時27分07秒
カテゴリ: Mozilla Core
固定リンク: id=2007020901
リンク元: 2件
SNS: (list)

既に知っている人も多いかもしれないが、昨日、ツリーが閉じている間にかなり大きいランディングが発生している。(パッチのサイズは700kB!)

Bug-org 177805で、簡単に言うと長らく設定だけあって(UIはFirefoxでは削除されていたが)使えなかったdpi値への本格的な対応だ。

そしてサマリにあるようにマルチディスプレイではメニューの表示がおかしくなっている。はっきり言って、マルチディスプレイ環境で、プライマリディスプレイ以外でFxを使う人には使えないビルドになってしまっているので要注意。

イージーミスだったようなので既にパッチを提出してあるので早ければ明日のビルドで修正できているかもしれない。

tinderbox大炎上 初回投稿日時: 2007年02月09日08時18分56秒
最終更新日時: 2007年02月09日08時28分58秒
カテゴリ: 雑談
固定リンク: id=2007020902
リンク元: 0件
SNS: (list)

といっても私の責任ではないのですが。

Stuartの14:54のコメントに吹いた。そんだけ。

2007年2月11日

Bug 5589 [Cairo] リンクの下線位置が高すぎる 初回投稿日時: 2007年02月11日04時46分57秒
最終更新日時: 2007年02月11日04時47分14秒
カテゴリ: Mozilla Core
固定リンク: id=2007021100
リンク元: 1件
SNS: (list)

報告を機にMacでのテキストレンダリングの検証をしてみると色々と鬱陶しい事実が。(以下、cairoの仕様かもしれないが、たぶんATSUIの仕様だと思う。)

Macはテキストのサブピクセルレンダリングをサポートしているので、例えば15pxとも16pxとも違う、15.5pxのテキストのレンダリングができる模様。

EEEEEEEEEEEE

でも、テキストのY軸方向へのサブピクセルレンダリングはサポートしていないようだ。

EEEEEEEEEEEEEEEE

今回は関係無いが、X軸方向。

EEEE
EEEE
EEEE
EEEE

metricsはdoubleで扱わないと駄目なのに、下線の処理はデバイスピクセルに丸め込まないといけないというのが実に鬱陶しい。

2007年2月18日

Bug 4876 日本語もしくは長いファイル名の添付ファイルを送信した場合、Outlook/Outlook Express で att00xxx.xxx として表示される 初回投稿日時: 2007年02月18日02時22分34秒
カテゴリ: Mozilla Core Thunderbird
固定リンク: id=2007021800
リンク元: 0件
SNS: (list)

とりあえず修正完了(のつもり)。tb2向けの1.8branchにもチェックインしている。

デフォルト設定をまた変更し、RFC 2231でfilenameパラメータを出力しつつ、RFC 2047形式でnameパラメータに従来通りに出力するようにしている。妥当かどうかはさせておき、RFC違反は無いのではないかと思う形に落ち着いている。(一行998文字以内という制限は考慮していないコードに見えたが、現実問題としてそれは発生しないと思う。少なくともWindows版ではたぶん無理だ。)

バグがない限り、RFC 2231をサポートしていないMUAがTb 1.0の時よりも問題が発生する、ということは無いのではないかと思うが、そこはregressionを出すことで有名な(?)私の仕事なので、是非Tb2 finalがリリースされるまでにテストしてみて欲しい。

2007年2月21日

Vistaの環境作りに苦戦中 初回投稿日時: 2007年02月21日03時32分42秒
カテゴリ: 雑談
固定リンク: id=2007022100
リンク元: 0件
SNS: (list)

暇って言うのもなんですが、仕事があるけどできない状況なのでWindows Vistaの環境作りにチャレンジ中。

ビルド環境は作ってみたものの、どうにもcygwinが不安定。ビルド中に(ランダムに?)何かがクラッシュしたり、dup_proc_pipe DuplicateHandle faildというエラーが出まくったり(このエラーが出てもビルドには成功する)。あと、スペックの割には(XP環境に比べて)ビルドの速度が遅い感じが。

ソースをホーム以下にCVSで取得すると共有フォルダとして作成されてしまうので削除が面倒になったり、wintoolsのnsinstall.exeがインストーラと誤認識されて、実行に管理者権限が必要になるので、ビルドするためのバッチファイルを管理者権限で走らせないといけないとか、やたらとExplorerがクラッシュするとか、なんか疲れた。

VMWare6もはやくリリースされないかな。

2007年2月24日

Re: 久しぶりにバグ登録だけど・・・ 初回投稿日時: 2007年02月24日05時54分49秒
最終更新日時: 2007年02月24日06時00分47秒
カテゴリ: Bugzilla-jp
固定リンク: id=2007022400
リンク元: 2件
SNS: (list)

報告しづらい。いちいち、説明やら手順やら多すぎる。管理する人は良いんでしょうけれど、ただ報告したい人にははっきりいって苦痛

あれでも必要最小限の情報です(現実にはあれでも情報不足の時すらあります)。あれより少ない情報量で済まそうとするなら、なんらかの権限を持っている人が報告しているパターンのように、他の開発者(テスタ含む)がその人の常用環境を有る程度知っている必要があります。

バグ報告というものを誰でもできると考えているのであればそれは間違いです。バグ報告をするにはそれなりの知識が必要です。知識がなければバグなのかどうかも分かりません。例えば件の問題をバグだと考えるには、CSSの知識が必要です。Fx2では期待通りの表示だった、では根拠になりえないのです。崩れた表示の方が仕様通りという可能性もあるわけですから。また根本的な問題として、開発者がどのような情報を必要としているかも理解できないでしょう。そして現実問題として、クオリティの高いバグを報告しないと、よりクオリティの高いバグから検証が行われるために、せっかくのバグ報告が埋もれていく可能性が高いです(特に本家)。それは報告者の望むことではないでしょう。(私がbugzilla-jpへの報告を推したのはこれが理由です。あれだけ大量のバグがある中で、現象だけ報告してもおそらく放置されるだけです。)

もし、報告された内容が不十分でさらなる情報が必要な場合、スタッフが確認や問いかけを行います。ですが、それへの返答率というのは案外低いものです。Bugzilla-jpではメールすら配信しているはずなのに、です。

メールを配信していないシステムではFirefox 2 問題報告センターがあります。こちらを見ると、その返答率の悪さに驚かれるかもしれませんが、こんなものです。間口を広げて報告者にクオリティを要求するのは愚行です。

さらに酷いことに、報告した直後の問いかけの時点でメールの配信に失敗することもあります。アカウント作成用にメールアドレスを作成して、それをすぐに破棄したりしているんでしょう。ここまで行くと問題外ですが、現実にそういうケースがあってる訳です。

おそらくamiさんはこのFirefox 2 問題報告センターのような手軽な報告がしたいんでしょうけど、問題報告センターを見て貰えれれば、そのような形態ではbugzilla本来の目的であるバグのデータベース化には問題があることが分かると思います。も組のフォーラムでもよく、過去ログを検索していないことを批判する人が居ますが、フォーラムはデータベースとしての質が悪いということも考慮すべきです。(実際問題としてそれ以前のケースが多いのは認めますが。)

データベースとしての質を高めようとすると、クオリティの高いコンテンツで構成していく必要がありますが、それは書き込む人間にそのクオリティを要求することに他なりません。クオリティを求めるには有る程度の敷居は必要です。そのバランスは重要ですが、意外と答えは簡単です。開発者の求めるレベルに設定すれば良いんです。何故なら、開発者の処理能力は報告者の報告する物量より絶対に少ないからです。開発者自身が報告者も兼ねているのですから当然です。(もっとバグの少ないシンプルなプロダクトならこの前提は崩れる可能性がありますが、大規模なプロダクトでは間違いなくこうだと思います。)

自分たちさえ良ければ主義と揶揄されていますが、それはbugzillaをサポートとして見ている証拠ではないでしょうか? 前から何度も書いていますが、bugzillaは開発現場です。その場がオープンになった途端、サポートとして機能しないのはおかしいという発想は間違いであると私は信じています。そして、多くの企業がbugzillaのようなオープンなバグ報告システムを採用しないのは、その誤解を懸念しているということが少なからずあるのではないか、という気がします。

という訳で、新しいバグは一部の「超」固定メンバーですることがお望みらしい!というのは全面的に否定しておきます。開発現場は純粋にクオリティが低くないバグ報告を望んでいます。バグ報告のクオリティによって処理を選択することはありますが、報告者を見てそれを選択するようなことはありません。

テストケースを作る人が居ない 初回投稿日時: 2007年02月24日06時58分06秒
カテゴリ: Bugzilla-jp
固定リンク: id=2007022401
リンク元: 0件
SNS: (list)

ついでにbugzilla-jpの現状の問題として考えてるポイントを一つ。

私はパッチを書き出す前は報告されたバグのテストケースを作り込んだり、HTML/CSSを個人的にがしがしとコード書きまくってバグを報告したりしていた。(レイアウト/描画のバグ件数が774件で、うち203件が私の報告。意外と割合が高い。もちろんこれはよくない傾向だ。)

で、共に後継者が不在なのであまり問題は表には出ていなかったが、reflowリファクタリングでregressionが多いにも関わらずbugzilla-jpにはほとんどその報告が無いというのは問題だと思う。またあったとしてもそのテストケースを作って再現状況を絞り込む人も居ない。

再現状況を絞り込もうとすると、処理を知らなくても仕様を熟知して、コードの有る程度の設計を推測してバグが発生する条件としない条件の境目を考えなくてはいけない(それを推測できない場合は当たりが付けられない分、テストケースの作成が難しくなる)。また、出来る限り一目で理解可能なシンプルで有用なソースを書くコツがあるのだが、それを掴まなくてはいけない。だが、考えてみればこれって結構特殊な能力かもしれない。だって、そもそもそんな能力、bugzillaでしか役に立たない訳だから。

一応、参考のために作成のコツを列挙しておくと、

  • 再現するために必要な要素、プロパティを徹底的に必要最小限まで絞り込む。無駄があればそれは原因推測の邪魔になる。
  • ボックスモデルのバグの場合、borderを利用して分かりやすく作る。ボックス毎に色やスタイルを変える等。もちろん、インラインボックスのテストの場合テキストの色を変えるのも手。ただし、目が痛くなるようなきつい配色にはならないようにだけ注意。
  • 複数示したい状態がある場合、可能な限りスクロールせずに比較できるようにコンパクトにまとめる。
  • テストケースに関する説明を丁寧にする。理想はテストケース内に見出しで入れれること。もしくは、テストの内容によってはボックスのコンテンツとして。また、仕様上どうあるべきかをシンプルに説明する。説明が長い場合は素直にテストケースを添付する際にコメントとして付け加える。
  • zip圧縮のようにブラウザから手軽に見ることのできない形式では添付しない。
  • コメント欄にソースを貼り付けるというのも駄目。
  • とことんシンプルなテストケースで済むならURL欄にdataスキームで書き込むのもアリ。

過去の私の添付したテストケースがこれに従っていないものも多いが、そこはそれ。そういった失敗から学んでのことである。進歩するから黒歴史があるということで。

Bugzilla-jpは回っていない訳ではない 初回投稿日時: 2007年02月24日08時02分26秒
カテゴリ: Bugzilla-jp
固定リンク: id=2007022402
リンク元: 0件
SNS: (list)

あまり、人手が足りないというような話ばかりしていると外野からbugzilla-jpなんて役にたってないんではないか、なんていう誤解を受けると嫌なのでフォローを。

そもそも、もしbugzilla-jpが役に立っていないなら、私は既に見捨てているだろうし、Mozilla Japan主導で何かやるべきなんだと思う。でもそれをやらないのはbugzilla-jpというコミュニティが機能しているということだ。ここで書いたかどうか忘れたが、Mozilla Japanが出来たときにMozilla Japanでbugzillaを運用すべきかどうかという話があり、そのときに私は必要無いと答えた(当時はMozilla Japanのメンバーでは無かった)。ユーザコミュニティと違って、情報が集約されるべき開発コミュニティの分散は好ましく無いからだ。

私がbugzilla-jpが有用だと考えている点は、開発者に都合の良い日本語で運用されているバグの管理システムが他には無いということだ。英語を読み書きするのはやはりしんどい。相手が日本語の通じない相手だと仕方がないという考え方になるが、相手が日本人だとその労力は無駄でしかない。また、コミュニケーションに失敗する可能性も高くなる。ネイティブな言語で仕事をするのが一番楽なのは確かだ。

それに、私以外にも実際にパッチを書いてくれている日本人とコンタクトがとりやすくなる。本家bugzillaのバグの件数はとにかく尋常ではない。日本人でこっそり活躍されている方がいても、フルタイムで関わっている私すら、まずそれに気づくことは無いだろう。それでは支援も何もあったものではない。バグの内容によってはオール野党な状況下で話をしていかないといけないこともあるからだ(それでいて勝利しなくてはならないことも多い)。

また、パッチを書くレベルになると本家でのレビューの際に英語でのコミュニケーション能力が必要になる。だが、パッチを書く能力と、英語の能力は全く別物なので、共に無い限り開発に参加できないという状況は間口を無駄に狭めてしまうため、良くない。いくつかのバグで実際に行ったように、それを代行することが可能になるという点で、bugzilla-jpというワンクッションは非常に重要だ。

そして日本語で運用されているので、本家とは違うバグで盛り上がったりする。日本語処理固有のバグだったり、日本のメジャーサイトでの問題だったり、民族性の違いだったり、理由は多々あるだろうが、実際にパッチを書く者にとっては修正の優先順位の参考としてこれは非常に重要な情報となる。

最後にそのシステムが非常に良くできているという点。バグを愚痴のように書いているだけのコミュニティがあったとしても、それでは何の役にも立たない。バグの存在を知ることは大切だが、存在だけが分かってもそれを検証したり管理したりする機能が無いとただのノイズでしかない。そういう点でbugzillaは非常に出来がよく、使いやすいシステムである。それを更に優秀な管理者がメンテナンスしてくれているという点も見逃せない。おかげで私は不満を言える立場にあるぐらい、その作業には関わらなくて済んでいる。

Re: もずはっく日記への解答 初回投稿日時: 2007年02月24日19時28分30秒
カテゴリ: Bugzilla-jp
固定リンク: id=2007022403
リンク元: 5件
SNS: (list)

もずはっく日記にはコメントもトラックバックも機能を実装していません。スパム対策やるのが面倒なのと、主張したいことがあるならなりすましが容易なコメント欄ではなくblogでも使って主張して欲しいと考えているからです。同様に重要な主張を私は余所のコメント欄で済まそうとは考えていませんのであしからず。それはさておき本題へ。

Bugzilla が開発現場だからといって開発者だけに門を開くというのは何とも誤った論理だと思います。

前提として書いておきますが、先のレスの中で開発者と書いた部分は原則的にbugzilla-jpで検証作業等を行っているテスタの方々も含めてのことです。パッチを書く人だけをbugzillaでの開発者と言うつもりはありません。

私だって開発者ではありません。

ですから、報告に来られた時点で開発者だと考えています。そして開発者には一定のクオリティを要求したい訳です。

重要なことは『「バグと思しき物」を見つけるのは開発者とは限らない』ということです。

おっしゃるとおりです。でもそれは有用な報告がbugzillaを通してあった場合にのみ価値が出てくることです。不満に思った、どこかのフォーラムで愚痴った、bugzillaにクオリティの低い報告をしたために理解してもらえなかった、この状態ではその事実に価値は無い訳です。

Amiさんの理屈だと、その価値が出るように開発者が努力すべきだとおっしゃるようですが、それにあたる私たちの活動は、報告者に対して不明な点を問いかけたりする、という行為がそれにあたると思います。もちろん、それは実行されています。しかし現実問題としてそのような処理を現在報告されている全てのバグにおいて完全に完了できている訳ではありません(UNCOのバグがあるということはそういうことです)。では、これ以上何をすべきでしょうか?

本当に重要なバグを見つけた人までも城の周りのお堀に落としていないか。私は何回か報告ないしコメントしましたけれど毎回、思ってきたことがこれなわけです。と、理想は高いところを示されています。そんなことは当然分かっています。ですが実行できない理想はただの妄想でしかありません。

それに、私以外の方々はbugzilla-jpでの活動を生業としている訳ではありません。ボランティアとして活動されています。しかし、もっと今以上に努力と呼べる、ユーザへの無償での奉仕活動を行えという要求だと思います。ですが、その発想はbugzilla-jpをサポートとして考えているとしか思えません。開発者はユーザの奴隷ではないのです。

私もMozilla Japanのメンバーになるまではボランティアとしてbugzilla-jpで活動していました。本業の残業で22時、23時に帰ってきて、それから作業を行って寝るという日々を繰り返していましたが、決して楽ではありませんでした。好きでやっていたこととはいえ、その過酷さは身にしみて分かっています。でも好きでやっていたから出来たことだと思います。ですので、ボランティアの方々が自発的にそれを必要だと考え、行動をおこさない限り、誰にもその活動内容が不十分だなどとは言って欲しくはありません。

Bugzilla-jpの運営がベストの状況であるとは私も思いません。問題は多々あるでしょう。しかし、出来ることを可能な限り続けていると思います。もし改善したい点、すべき点があるなら是非中からそれを改善してもらいたいです。それが出来ないというのであれば、自分が出来ないことを他人に押しつけるべきではないと私は思います。

2007年2月28日

ビルド環境をi-RAMへ 初回投稿日時: 2007年02月28日02時43分13秒
カテゴリ: Mozilla Core
固定リンク: id=2007022800
リンク元: 0件
SNS: (list)

この前、ワゴンセールで見かけて、調子に乗って買ってしまったi-RAMにcygwinを入れてビルド時間の短縮を図ってみた。

既にソースとビルド先はi-RAMに移行していたのだが、make.exeやsh.exeが大量に起動と終了を繰り返しているようなので、cygwin自体をi-RAMに移動したらさらに高速化できそう、というのでやってみた。(vista環境だと高価なi-RAM使わなくても安価にReadyBoostで高速化できるかも?)

まず、既存のcygwinを手でアンインストール(アンインストーラなどという生やさしいものは存在しない)。そしてi-RAMに最新版をインストールして、make.exeだけひとつ前のバージョンに戻す。これであとは素直に動作するはずだった。だが、実際にやってみると、:No such file or directory: mozilla/mail/config/mozconfigなエラーが出てビルドが始まらない。もちろん、該当のファイルは存在するし、catで表示することもできる。

結局原因は自前のmozconfigがCRLFだったことだった。今までいくつか作ったビルド環境では問題無かったし、同じバージョンが入っているVista環境でも問題が無いので謎。

実際に高速化するかどうかは分からないが(新しいcygwinは遅くなってるという書き込みをmozillazineで発見)、かなり無音に近いビルド環境になってきた。Visual Studioもi-RAMに入れられれば良いんだと思うが、そこまでの予算などもちろん無い。

Bug 5615 文字化けメールを受け取ると(?)エラーがでる (Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIScriptableUnicodeConverter.ConvertToUnicode]) 初回投稿日時: 2007年02月28日02時49分07秒
カテゴリ: Mozilla Core SeaMonkey Thunderbird
固定リンク: id=2007022801
リンク元: 0件
SNS: (list)

どういう状況下で発生するバグなのかイマイチ分からないのだが、とりあえず修正完了。単に問題の箇所をtryで包んだだけなのだが。

長時間Thunderbirdを使っていると、通知ウインドウが出てこなくなる(1pxの高さで画面下にゴミとして残る?)現象はおそらくこれが原因ではないかと思われる(コードから推測)。一応、このパッチを当てた状態で半日メールを受信し続けても通知ウインドウは動いていた。