フィーリング訳（？）です
鵜呑みは危険!?
Welcome to the Mozilla development roadmap. This is the third major roadmap
revision since the original roadmap that set Mozilla on a new course for standards compliance, modularity,
and portability in 1998. The previous roadmap documented milestones and rules of development through Mozilla 1.3, and
contains links to older roadmaps.
この新しいロードマップでは、標準準拠・モジュラー化・ポータビリティを重視して開発を行いますよ？ としたためた最初のロードマップ
(1998 年) 以来、２回目の方向転換をお知らせします。なお、Mozilla 1.3 までのロードマップは別のページへ移動しました。
We have come a long way. We have achieved a Mozilla 1.0 milestone that satisfies the criteria put forth in the Mozilla 1.0 manifesto, giving the community and the wider world a high-quality release, and
a stable branch for conservative development and derivative product releases.
See the Mozilla Hall of Fame for a list of Mozilla-based projects and products that benefited from
1.0.
1.0 をひとつの区切りとして、その後 Mozilla の開発がどのように続けられてきたのかは、これを読まれている大多数の方がご存じでしょうから省略。Mozilla
殿堂ページには、以下略。
Since 1.0, on the main-line "trunk" development path continuing
up to 1.3, we have improved on the footprint and performance work begun
during the 0.9.x milestones, fixing many longstanding flaws in the standards-compliant,
modular, and portable codebase begun in 1998. We've seen the emergence
of great features such as tabbed browsing, popup blocking, and http://paulgraham.com-inspired
Bayesian spam filtering, along with faster, more focused browser projects
such as Phoenix and Camino (formerly Chimera).
1998 年のあの日からねばり強く続けられてきた開発作業は、最近の例ではタブ
ブラウズの実現やポップアップ ブロック、スパム フィルタの追加のように、機能豊富なブラウザ
スイートを作り上げるという目標の下 (やもすると行き過ぎなほど) 順調に進み、それとは別に、Phoenix
や Camino (以前は Chimera と呼ばれていました) のような単独のブラウザを作り上げるプロジェクトもスタートしました。
But incremental development of the kind we've had since 1.0 is not enough
for a healthy open source project. It's clear to us that Mozilla needs
a new roadmap, one that charts a path to an even better future. Below we
will propose a new application architecture based on the Gecko Runtime Environment (GRE), which can be shared between separate application processes. Before discussing
the rationales and trade-offs, here are the implications and key elements:
このまま開発を続けても良かったのですが、より効率的な方法を思いつきました。巨大で扱いにくくなってしまった
Mozilla を解体して、Gecko Runtime Environment (GRE) をベースとした、個別のアプリケーションに分けるのです！ GRE
は…細かい説明は省略しますが、簡単に説明すると以下のようになります:
The reasoning behind these new roadmap elements comes down to preferring
quality over quantity. We must do less, but better, and with sound extension
mechanisms, so that (for example) the community does not fight over user
interface pigeon-holes such as the main menu items.
（よくわかりません）
Another, non-UI, extensibility example: Gecko needs to support emerging
XML and related standards, some experimentally and conditionally, without
everyone having to hack into nsCSSFrameConstructor.cpp (and that enormous file should be eliminated or greatly simplified by
incremental change, during 1.5, 1.6, and probably beyond). It should be
possible, using good primitives (HTML and XUL widgets, SVG) and styling
and composition tools (CSS, XBL) to avoid an explosion of new C++ code
and rendering object bloat.
Gecko は新しい標準を精力的にサポートしていきます。また、巨大で複雑なコードをメンテナンスしやすくするため、1.5
を目処に単純化され、1.6 以降では…とにかく！ 悪い部分は直さなければなりません。
When Netscape released its original browser codebase as open source on
March 31, 1998, the expectation, product plans, checkin rights, and indeed,
code structure, all militated toward a continuation of the big suite of
applications (browser, mail, editor) first heavily promoted as "Communicator"
in the Netscape 4 days. This "swiss army knife" approach continued
when we reset Mozilla around Gecko, XPFE, and scriptable XPCOM interfaces in late 1998. Along the way, of course, Mozilla has received very generous
support from Netscape, mainly in the form of paid contributors and infrastructure.
Netscape が 1998 年 3 月 31 日にソース コードを公開して以来、ブラウザ・メール
クライアント・HTML エディタをワンセットで提供するという基本方針は今まで変わりませんでした。1998
年後半に古いコードのほとんどを捨て、Gecko ベースの新しいもの作ろうという重大な決断を下したときにも、この「十徳ナイフ」アプローチを変えることはありませんでした。
The result has been a rich and complex application suite with a large set
of back-end modules for the user-interface front ends. Many very good things
have come from this ambitious integration, including XUL and XBL.
その結果はご存じの通り。XUL を代表とする様々な素晴らしい特徴と同時に、複雑でめちゃくちゃでぐちゃぐちゃで何をどうしたいのかすら判然としない、Mozilla
ですね。
Yet, if the goal were merely to "rewrite the browser", XUL would
have been a false economy. True, as intended, it allowed us to write a cross-platform application front end once, instead
of writing native-OS-toolkit-based front ends for at least three platforms.
But we ended up spending at least as many people and as much time on the
various applications in the suite, and on integrating those application
components, as we would have spent developing native browser-only front
ends and one browser back end.
私たちが「ブラウザを書き直すこと」のみを目標としていたとしたら、XUL という仕組みは無駄以外の何物でもありません。では、何故
XUL を作ろうと思い立ったのか？ それは、私たちがクロス プラットフォームで動作するツールキットを
(アプリケーションの移植を早く楽に行えるようにするため) 必要としていたからです。XUL
は現在一応の完成をみており、Mozilla 以外の製品にも活用されるほど成熟しています。
This critique supposes that Mozilla and major contributors such as Netscape
might have been content to develop only a browser, and not a mail user
agent, news reader, HTML editor, and application framework. Even in hindsight,
it seems unlikely that "just a browser" would have sufficed.
Beyond the worthy cross-platform mail and composer applications it enabled,
XUL has been a huge win (a "true economy") for customizers, localizers,
distributors, and portable application developers. Without making it our
primary focus, we've developed a fairly high quality, web-oriented cross-platform
application framework: Mozilla-the-platform.
XUL に価値を見出せない方は、「ブラウザとしての性能向上にのみ力を注いでいたら、もっと良いものになっていただろうに！」と依然それを批判し続けているようですが。もっと現実を見てください。私たちのツールキットは、クロス
プラットフォームで動作し、インターフェースの翻訳も簡単で、と他にないとても素晴らしい特徴をもっています。ツールキットだけでも十分に自慢できる出来ですが、それが基礎としているウェブ指向のフレームワークはもはや、Mozilla
プラットフォームと表現できるほどのものに成長しています。
Nevertheless, ignoring the valuable user-interface itch-scratching, and
considering only the minimal set of goals for each application in Mozilla-the-application-suite,
the cost of integration has been high. Unintegrated applications tend to
be faster to load, smaller on average in dynamic memory consumption, and
more robust and crashproof.
自慢はこれくらいにして。今までの開発方針にも欠点はありました。例えば、ブラウザ・メール
クライアント・HTML エディタその他のものを統合した巨大な Mozilla スイートは、単体のアプリケーションを作成・改良するよりも多くの労力が必要で、動作させる際に消費するメモリも多く、しかもクラッシュするときは一蓮托生です。
Another example of the high cost of app-suite integration is the inherently
overloaded and complicated user interface (just one example out of too
many: the File / New sub-menu). The target audience of the suite was never clear, and seemed
to shift back and forth with prevailing business- and voluntary-contributor-driven
winds. Hyatt's blog is an effective summary of the case against this approach. Simply put:
great applications cannot be managed as common land, with whoever is most
motivated in a particular area, or just the last to check in, determining
the piecewise look and feel of the application.
アプリケーション スイートは一般にごちゃごちゃしており、作る方もややこしいものです。それに関わるおのおのが
(良かれと思って) 多種多様な変更を加え、さらに複雑になりがちです。実際、今の
Mozilla は…見ての通りですね。
Gecko also suffered from over-reach. Not because too many integrated applications
were built on top of it -- those helped shake out many design and implementation
bugs -- but because it was naively quite "modular" without actually
being easy to extend. At the same time, parts of Gecko are still baroque due to early design limitations and an accumulation of code to patch around
core problems.
Gecko 自体はいい感じなので、その長所は今後も活かしていきます。短所は、順次改善が予定されています。
In short, and in the same order as the roadmap element list above, the
reasons for this new plan are:
説明 (言い訳？) が長くなってしまいましたが、今までの反省を活かして訂正された開発計画は以下の通りです:
The last point is controversial. Let's dwell on it for a moment, and try
to clarify it by exclusion.
これから、大変重要な事柄について説明します。以下を理解せず議論に参加しようとする場合、話がかみ合わずにしんどい思いをするのはあなたです。
Having knocked down all those straw men, the important point that remains
standing is this: it is almost always better to have a competent owner
who rules decisively, than to have no owner and live in a state of indecision
(N.B.: a committee of more than one or two is not an effective owner).
This point is especially true for top-down application design and policy
setting, particularly for user-interface design. For coherent UI within
an application, there is no substitute for leadership by an "application
czar". For cross-application consistency where it is needed, we expect
such czars to communicate, cooperate, and consolidate things such as common
default keybindings.
私たちは、これまでにない強力なリーダ シップを発動しようとしていますが、これはそれほど悪いことではないはずです。誰もが自由であることを求めますが、有能な為政者は国民が失う自由を最小に、その代わりに最大限のサービスを提供します。この例だと実感としてつかみにくいかも知れませんが、こう考えてみてください。ちょっとだけ自由を失う代わりに、見た目や操作感に一貫性がある一連のアプリケーション群が手に入るとしたら？ マウスやキーボードによる操作体系に幾ばくの違和感もなく、それが別のプラットフォームでも守られるとしたら？
It is time for Mozilla to "return to normalcy": great software
is originated by one or a few hackers building up and leading a larger
team of people who test, clean up, extend, and grow to join or replace
the first few. Code review, like testing, is an auditing procedure that
cannot make excellent code from mediocre input.
今こそ、肥大化してしまった Mozilla をダイエットさせるのに適当な時期です。優秀なソフトウェアは良き指導者の下に、優秀なスタッフが結集して作成される場合が多いものです。この原則に立ち返ることにより、最終的には
Mozilla の確実な改良品を得ることができるでしょう。…えっと、今まで貢献してくださった皆様を追い返そうというのではありません。ただ、ご協力頂く際の心構えを、ちょっとだけ変えて頂きたいのです。それだけです。
Therefore we will promote strong ownership by relieving vigilant owners,
on a case-by-case basis, of mandatory super-review requirements, for modules
that the super-reviewers deem sufficiently well-owned. And where ownership
is weak or missing, we will take steps to find an owner, or absent any
candidates, to reduce our dependencies on the under-owned or unowned code.
If we can "limp" along for a while without an owner for some
crucial module, we will do so -- but experience has shown that almost always
leads to a much more serious condition than a limp.
私たちは、適当な範囲でコードの修正に制限を加えることとしました。あくまで最低限のものです。Mozilla
をダメにしたいのではなく、間違いなく良くしたいと考えていることを忘れないでください。
In the same vein of clarifying by counter-example, here is a list of more
things that we are not proposing:
以下は、私たちの方針変更について誤解されたら困ると考えていることのリストです:
以下、機械訳@エキサイト翻訳
Let's begin the new application architecture proposal by recapitulating
the relevant facts and defining some terms.
適切な事実の概説およびいくつかの用語の定義により新しい適用アーキテクチャー提案を始めましょう。
There are currently two major classes of applications being built using
Mozilla's technology. The first class of applications are embedding applications. They use Mozilla's layout engine, but write their own code
for user interface features that exists outside of the laid-out HTML or
XML document view. The second class of applications are toolkit applications. They are built on top of Mozilla itself and designed to
be cross-platform. The user interface elements are defined in XUL and rendered
by Gecko itself.
Mozillaの技術を使用して構築されている適用の2つの主なクラスが現在あります。適用の第1のクラスは適用を埋め込んでいます。それらはMozillaのレイアウト・エンジンを使用するが、置かれたHTMLあるいはXMLドキュメント視界の外部で存在する、ユーザ・インターフェース特徴のための自分のコードを書きます。適用の第2のクラスはツールキット適用です。それらはMozilla自体の上に構築され、クロス・プラットフォームであるつもりでした。ユーザ・インターフェース要素はXULに定義され、ヤモリ自体によって与えられます。
Both classes of applications will be able to make use of the Gecko Runtime
Environment ( GRE) to enable the sharing of a single installation of Gecko. Applications
may even share profiles, although the inter-process communication work
to support sharing profiles among applications running in separate processes
is not done yet (as of 1.4alpha).
アプリケーションの両方のクラスは、ヤモリの単一の装置の共有を可能にするためにヤモリ・ランタイム環境(GRE)を利用することができるでしょう。個別のプロセスで走るアプリケーション中の共有するプロファイルをサポートする相互プロセスコミュニケーション仕事は、まだ(1.4alphaの時点で)行われませんが、アプリケーションはプロファイルをさらに共有するかもしれません。
Toolkit applications will also support extensions, specially designed add-ons
that can be layered on top of the core application to provide additional
functionality. In the case of the browser application, examples of such
add-ons include mouse gestures, the site navigation toolbar, the DOM inspector,
and the JavaScript debugger.
ツールキット適用はさらに拡張(補足機能性を提供するために中核適用の上に層になることができる、特に計画的な付属品)を支援するでしょう。ブラウザー・アプリケーションの場合には、そのような付属品の例がマウス身振り、サイト操縦ツールバー、DOM検査官およびJavaScriptデバッガを含んでいます。
In addition, we propose that certain toolkit applications should themselves
be extensions, meaning that they can be built both as standalone applications
and as add-ons installed into other applications. An example of such an
application is Thunderbird, a.k.a. Mozilla Mail, which will be capable
of either running as a standalone application or being installed directly
into Phoenix, a.k.a. the Mozilla Browser, as an extension.
さらに、私たちはそのあるツールキットを提案します、アプリケーション、万一スタンド・アロンのアプリケーションとして、および他のアプリケーションへインストールされた付属品としてそれらを構築することができることを意味して、それら自身が拡張ならば。そのようなアプリケーションの例はサンダーバード(別名、Mozillaメイル)(それはスタンド・アロンのアプリケーションとして走ることができるだろうか、拡張としてフェニックス(別名、Mozillaブラウザー)へ直接インストールされることができて)です。
(We expect many fans of the current, integrated browser/mail application
to demand such an add-on, and we will work to provide it before switching
the default-built browser.)
(私たちは、流れの多くのファンを期待します、要求する統合ブラウザー/メイル適用、そのような、1つの、アドオン、また、私たちはデフォルトに構築されたブラウザーを切り替える前にそれを提供するために働くでしょう。)
The idea is to move from the over-integrated application suite to simpler
toolkit applications, to remove more advanced functionality from the default
configurations, but to provide robust tools for building your own browser
by layering those extensions that you want to use on top of the base. In
an attempt to avoid an explosion of unique builds that have to be supported
by mozilla.org, we will likely ship with all of the popular extensions
installed but disabled, so that they can be easily turned on by those who
wish to use them, and uninstalled by those who don't.
目的はデフォルト配置からもっと高度な機能性を取り除くために過度に統合された適用組からより単純なツールキット適用まで移ることです、しかし、提供するために、望む拡張を層にすることにより自分のブラウザーを構築するための強健なツールは、基礎の上に使用します。mozilla.orgに支援されなければならないユニークな構造の爆発を回避する試みでは、私たちが、恐らくポピュラーな拡張のすべてで船で行くでしょう、インストールされたが無効になった、その結果、それらを使用したい人々はそれらを容易につけて、しない人々によってインストール解除することができます。
A picture should make this architecture clear.
絵はこのアーキテクチャーを明らかにするべきです。
（画像省略）
This picture shows Mail as both an Application (inside a square) and an
Extension (the circle with an arrow pointing to the Browser application
that Mail extends). The pure extensions, which are never applications as
well, are shown at the top.
この、絵画展は両方として適用(正方形の内部の)、および拡張(メイルが拡張するブラウザー適用を指す矢を備えた円)を郵送します。純粋な拡張(それらは同様に適用でない)はトップで示されます。
This roadmap is a proposal. We are pointing in a direction toward which
we think the Mozilla project should move. To get from where we are today
(1.4alpha) to that better place, at least the following things need to
be done:
この道路地図は提案です。私たちは、Mozillaプロジェクトが移動するべきであると思う方角へ指しています。私たちが今日(1.4alpha)そのよりよい場所へいる場所から得るために、少なくとも次のものが終わる必要があります:
Again, we're only pointing the way here. The detailed plan of attack should
be developed in the newsgroups and via Bugzilla. Whether we'll be able
to switch to Phoenix by the Mozilla 1.5 final milestone remains to be seen.
We invite your comments, preferably in the mozilla.seamonkey newsgroup.
再び、私たちはその方法をここで示しているだけです。攻撃の詳細な計画は、ニュースグループの中で、およびBugzillaによって展開されているべきです。私たちは最終マイルストーンが残るMozilla
1.5によってフェニックスへ変わることができるでしょうか、見られます。私たちは、mozilla.seamonkeyの中であなたのコメントをむしろ招待します。ニュースグループ。
As the previous roadmap documented, the Mozilla project has been following a quarterly milestone plan that
emphasizes regular delivery of stable new-feature releases, ideally with
risky changes pushed into an "alpha" minor milestone, followed
by stabilization during a "beta" period, then a shorter freeze
during which only "stop-ship" bugs are found and fixed.
前の道路地図として、ドキュメント化された、Mozillaプロジェクト、四半期のマイルストーン計画に続いていた、それ、安定した新しい特徴リリースの通常受渡しを強調する、理想的に、危険な変更で「アルファ」に押し込まれた、小さなマイルストーン、「ベータ」期間中の安定化によって続いた、その後、より短い凍結、に、どれ「停止船」バグだけ、見つかり固定す??a固定
Many in the community have asked for a longer alpha period. But with too
long an alpha, we fail to collect and act on feedback including automatic crash reports from a sufficiently large group
of testers. Still, we're convinced that a longer alpha than beta makes
sense, so we have moved one week from beta to alpha. Here is the updated
milestone schedule:
コミュニティーの多数がより長いアルファ期間を求めています。しかし、長すぎるアルファで、私たちは、試験装置の十分に大きなグループからの自動的な衝突報告書を含むフィードバックを徴収せず作用します。まだ、私たちは、ベータより長いアルファが意味をなすと確信しています。したがって、私たちは、ベータからアルファまで1週移りました。ここに、最新のマイルストーン・スケジュールがあります:
（画像省略）
Tabulating the milestones to show the proposed dates, with trunk freeze,
branch creation, and milestone release dates distinguished from one another
(the next milestone's start date is the previous one's branch date), yields:
幹凍結、枝生成、および、互い(次のマイルストーンのスタート期日は前の人の枝期日です)と相違を示されたマイルストーン・リリース期日と共に、提案された期日を示すためにマイルストーンを作表することは、産出します:
| milestone マイルストーン |
start スタート |
freeze 凍結 |
branch 枝 |
ideal release 理想的リリース |
actual release 実際のリリース |
|---|---|---|---|---|---|
| 1.3alpha 1.3alpha |
01-Nov-2002 01-11月-2002 |
04-Dec-2002 04-12月-2002 |
n/a n/a |
06-Dec-2002 06-12月-2002 |
13-Dec-2002 13-12月-2002 |
| 1.3beta 1.3beta |
06-Dec-2002 06-12月-2002 |
22-Jan-2003 22-1月-2003 |
n/a n/a |
24-Jan-2003 24-1月-2003 |
10-Feb-2003 10-2月-2003 |
| 1.3 1.3 |
24-Jan-2003 24-1月-2003 |
12-Feb-2003 12-2月-2003 |
14-Feb-2003 14-2月-2003 |
21-Feb-2003 21-2月-2003 |
13-Mar-2003 13-3月-2003 |
| 1.4alpha 1.4alpha |
14-Feb-2003 14-2月-2003 |
26-Mar-2003 26-3月-2003 |
n/a n/a |
28-Mar-2003 28-3月-2003 |
? ? |
| 1.4beta 1.4beta |
26-Mar-2003 26-3月-2003 |
23-Apr-2003 23-4月-2003 |
n/a n/a |
25-Apr-2003 25-4月-2003 |
? ? |
| 1.4 1.4 |
25-Apr-2003 25-4月-2003 |
14-May-2003 14-5月-2003 |
16-May-2003 16-5月-2003 |
21-May-2003 21-5月-2003 |
? ? |
| 1.5alpha 1.5alpha |
16-May-2003 16-5月-2003 |
25-Jun-2003 25-6月-2003 |
n/a n/a |
27-Jun-2003 27-6月-2003 |
? ? |
| 1.5beta 1.5beta |
27-Jun-2003 27-6月-2003 |
23-Jul-2003 23-7月-2003 |
n/a n/a |
25-Jul-2003 25-7月-2003 |
? ? |
| 1.5 1.5 |
25-Jul-2003 25-7月-2003 |
13-Aug-2003 13-8月-2003 |
15-Aug-2003 15-8月-2003 |
20-Aug-2003 20-8月-2003 |
? ? |
As always, the milestone freeze time is 11:59 P.M. Pacific Time (see the
tinderbox page for notices) on a Tuesday.
常に、マイルストーン凍結時間が太平洋の時間(火口箱を参照)午後11:59であるとともに火曜日に通知のためにページをつけてください。
If you are planning a Mozilla-based product release whose schedule does
not jibe well with the above milestones, we welcome your feedback (we will keep confidential information to ourselves, and will take appropriate
safeguards as necessary).
あなたがそのスケジュールが上記のマイルストーンとよく調和しない、Mozillaに基づいた製品発売を計画していれば、私たちはあなたのフィードバック(私たちは、私たち自身への機密情報を維持し、必要なときに適切な安全装置をとるでしょう)を歓迎します。どのように支援することができるか
C and C++ hackers: tinderbox now measures code footprint, so let's start working to reduce it rather than increase it. Resist the
all-too-common tendency to add more code. Try to remove code, simplify
over-complicated code, undo premature optimizations, and purge gratuitous
use of XPCOM and its not-quite-XPCOM precursors. If you have to add a new
feature, make sure it's bundled in the right library, which may mean adding
a new library. All additions to modules linked into the minimal embedding browser builds must be approved by drivers.
CとC++のハッカー:火口箱は今コード足跡を測定します。したがって、それを増加させるのではなくそれを縮小するために働き始めよう。あまりにも共通の傾向に抵抗してくださるので、より多くのコードを加えないことができましてください。コードを削除しようとし、過度に複雑なコードを単純化し、時期尚早の最適化を取消し、XPCOMおよびそのない全く-XPCOM先駆者の無料の使用を除去します。新しい特徴を加えなければならない場合は、正しい図書館(それは新しい図書館を加えることを意味してもよい)でそれが束ねられることを確かめてください。ドライバーは、最小の埋め込むブラウザー構造へリンクしたモジュールへの追加をすべてを承認しなけ?黷ﾎなりません。
Mozilla embedders: we need your input to Bugzilla, marking bugs with embed, footprint, mlk, perf, and other relevant keywords. Use Bugzilla's new request-tracking capabilities
to nominate bugs as blocking upcoming milestones (e.g., blocking1.4b?), and please comment in the bug with a convincing argument for why you
require the fix by that milestone. Mozilla project management will help ensure that bugs are assigned to hackers who can target their
fixes so as to satisfy as many milestone-keyword nominations as possible.
Mozilla embedders:私たちは、Bugzillaへのあなたの入力を必要とします、バグのマーク、で、埋め込む、足跡、mlk、perfおよび他の適切なキーワード。近く起こるマイルストーン(例えばblocking1.4b?)を閉鎖するとしてバグを指名するBugzillaの新しいリクエストトラッキング能力を使用して、なぜあなたがそのマイルストーンによって位置を要求するかに対する説得力のある議論を備えたバグの中でコメントしてください。Mozillaプロジェクト管理は、できるだけ多くのマイルス?gーンキーワード指名を満たすために彼らの位置を目標とすることができるハッカーにバグが割り当てられることを保証することを支援するでしょう。
Bug assignees, and especially helpers who can offload Futured or untargeted bugs from their nominal assignees and fix those bugs: please
make a pass at targeting your assigned bugs across the mozilla1.4 and mozilla1.5 milestones, using the criteria of stability for 1.4, and application and
layout re-architecture for 1.5, as your guides. Please try to offload bugs
to helpers, pinging drivers@mozilla.org if you cannot find anyone to help fix futured or untargeted bugs that
you believe should be fixed soon.
将来のdの荷を降ろすことができるか、それらの名目上の譲受人からのバグをuntargetし、それらのバグを直すバグ譲受人および特に助手:あなたのガイドとして、1.5のためにmozilla1.4とmozilla1.5のマイルストーンを横切ってあなたの割り当てられたバグを目標とし、1.4の安定の基準を使用すること適用を攻撃して、レイアウト再アーキテクチャー。助手にバグの荷を降ろそうとしてくださ?｢、ぴんと飛ぶドライバー@mozilla.org、futuredされて固定することを支援するためには誰かを見つけることができないか、すぐに固定するべきであると信じるバグをuntargetした場合。
Community members: please use Bugzilla's milestone nomination feature wisely, and do not
change the Target Milestone of anyone else's bug without the assignee's
consent. You may of course vote for bugs also to help inform prioritization
(but remember that patching beats voting). Finally, please help keep advocacy
and "me-too" comments out of the bug system.
コミュニティー・メンバー:Bugzillaのマイルストーン指名特徴を賢明に使用して、誰か他の人の譲受人の同意のないバグの目標マイルストーンを変更しないでください。さらに優先順位(しかしパッチングが投票して打つことを思い出す)に通知すること??aをためにバグをもちろん支持してもよい。最後に、バグ・システムから擁護および「他人の成功などを模倣する」コメントを維持することを支援してください。
To drive developers looking to help toward bugs needing assistance in a
timely fashion, to moderate risk, and to aid commercial projects based
on Mozilla in managing their product releases, mozilla.org has created
a group of project managers, drivers@mozilla.org.
適度な危険に、適時の方法の中で援助を必要とするバグの方へ支援し、かつそれらの製品発売を管理する際にMozillaに基づいた商用プロジェクトを援助することを期待する開発者を運転するために、mozilla.orgは1グループのプロジェクト・マネージャーを作りました、ドライバー@mozilla.org。
The current drivers are:
現在のドライバーは次のとおりです:
Copyright © 1998-2003 The Mozilla Organization.
Last modified April 2, 2003.
Document History.
Edit this Page.