This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution. Visit SpiderMonkey.dev for more up to date information. Tracked Projects We have long-term inchoate plans for how SpiderMonkey will technically evolve. Historically these plans have been "tribal" knowledge, communicated during the design pr
Moving bug history out of the primary display of a bug report I've been thinking through my past complaints about Bugzilla, such as my post about bug summaries and my post about having separate categories of content in Bugzilla, and various poor interactions I've had with others in Bugzilla (such as having missed key details in comment 27 and later in comment 14 when discussing Bug 823989), and I'
Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. OSSじゃなくても、大規模なソフトウェアだと、バグトラッカーシステム (BTS) は導入されているんだけど、BTSに登録したから、誰かが見てくれると思っているのは間違い。 ゴミくずのようなバグが増えていく 昔勤めていた会社は大規模なソフトウェア会社だったためBTSはあったんだけど普通にバグを登録しても放置される状態になる。それは、そのバグ登録等については誰でもできたため、ゴミくずのようなバグだらけになるからという原因がある。（実際問題、原因がソフトウェアに関するものではなかったり、違うバグ修正で直っているものだったり、過去のバージョンで直したものだったり！)。 またその時の一番の問題は、バグを登録した際にアサインがデフォルトでなしという状態だったのが、
FirefoxなどMozillaの製品はBugzillaというシステムでバグを管理しているのだが、そのBugzilla@Mozillaではバグのステータスとして、次のようなものを割り当てている。 UNCONFIRMED NEW ASSIGNED RESOLVED VERIFIED REOPENED 詳細を知りたい方は、MDCの『バグのライフサイクル』を参照してほしい。とりあえず、今までは「未確認→新規→担当者に割り当て→解決→検証済み→再開」という流れがあったことだけ押さえておけば足りる。 このステータスに変更を加えようという話が、mozilla.dev.planningで持ち上がっていて、現在も「bugzilla.mozilla.org workflow changes」と「Complete workflow reorganization」という二つのスレッドで、活発な議論が交わされてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く