[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /about/ROADMAP



三輪です。

2009年11月25日14:50 Yuji Yamano <yyamano@kt.rim.or.jp>:
> On Wed, 25 Nov 2009 12:22:14 +0900, 三輪晋( Miwa Susumu ) <miwarin@gmail.com> wrote:
>
>> /about/ROADMAP を翻訳しようと思いますが、よいでしょうか。
>> http://www.jp.netbsd.org/about/ROADMAP
>
> はい、よろしくお願いします。

ROADMAP を翻訳しました。
長いので対訳にしてあります。
どうにも分からない部分には「※」を書きました。

>>ここから
#	%NetBSD: ROADMAP,v 1.23 2008/08/04 15:37:05 simonb Exp %

A high-level roadmap for NetBSD
NetBSD の上位概念ロードマップ


This file contains a general map of where we would like to take
NetBSD over the next N years.  It is not highly detailed or overly
specific about each item.  There are several different "TODO" files
and "NetBSD Projects" lists in various places that contain some
more detailed plans.  This is the framework in which those projects
and plans are expected to fit.
このファイルは次の N 年間で NetBSD をどのようにしたいかというロードマップを含んでいます。
このロードマップの各項目は、まったく詳細に書かれていないか、またはあまりはっきりと書いていません。
いくつかの異なった "TODO" ファイルと "NetBSDプロジェクト" のリストが別の場所にあり、それらにはより詳細な計画が含まれています。
このロードマップは、それらのプロジェクトと計画に合うことが期待できるフレームワークです。


As this is a volunteer project, there are no specific dates beside
these items.  These items may or may not get picked up in any order,
and the roadmap may change as technologies and perceived needs
change.
これはボランティアプロジェクトなので、これらの項目に期日はありません。
これらの項目は順不同に着手されるかもしれないし、着手されないかもしれません。
そして、技術とニーズの変化に応じて、ロードマップは変化するかもしれません。


The roadmap, of course, is constructed in the context of the
Project's (broad) goals:
もちろんロードマップは NetBSD プロジェクトの幅広い目標にあわせて構成されます:

	* clean design		* stable		* fast
	* きれいな設計		* 堅牢性		* 速さ
	* clean licensing	* portable		* interoperable
	* きれいなライセンス	* 移植性		* 運用性
	* conformant		* commercial-ready	* research-ready
	* 適合性		* 商用での利用	* 研究での利用
	* hobby-ready
	* 趣味での利用

In general, we are headed for:
一般的に、私たちのゴールは以下のようなものです。

	* "State of the art" tools (current (and stable) GNU tools,
	  addition of Solaris's dtrace or similar functionality, kernel
	  core dumps on all platforms and post-mortem analysis tools,
	  performance analysis tools with support for hardware assists
	  like PMCs)
	* 最高水準のツール (currentの (そしてstableの) GNUツール、Solaris の dtrace
または同程度の機能性の追加、すべてのプラットフォームのカーネルコアダンプと事後分析ツール、PMC
のようにハードウェアを用いたパフォーマンス分析ツール)

	* Support for all devices without encumbered code
	* ソース管理上注意が必要なコード無しにすべてのデバイスのサポートすること
	(※「encumbered code」はFreeBSDと同じ意味でいいのでしょうか?→ソース管理上注意が必要なファイル
(Encumbered files)
http://docs.freebsd.org/doc/3.5-RELEASE/usr/share/doc/ja/books/handbook/policies-encumbered.html)

	* Managed growth of the base system
	* 基本システムの成長管理
	
	* Minimal GPL / LGPL code in the base system
	* 基本システムの最小量のGPL / LGPLコード
	
	* Maximal performance without compromising portability
	* 移植性を損なうことのない最高性能

	* "State of the art" technology in the kernel and userland
	* 最高水準のカーネルとユーザーランド

	* No bugs, no security vulnerabilities
	* バグなし、セキュリティ脆弱性なし

	* In combination with pkgsrc, a complete system for a variety
	  of users, administrators, and researchers: desktops, embedded
	  devices, servers, workstations, and portables
	* pkgsrc (様々なユーザー、管理者、研究者のための完全なシステム) と結合して: デスクトップ、組込デバイス、サーバー、ワークステーション、ポータブル


This is, by no means, a comprehensive list, and purposefully aggressive.
One of the many challenges will be to achieve excellence in each arena
we tackle and not settle for being a "jack of all trades, master of none."
これは、決してでなく、包括的なリストで、目的を持って積極的です。
多くの挑戦のうちの1つは、優秀さを我々が取り組む各々の土俵において成し遂げることになっていて、「器用貧乏」であることを受け入れることになっていません。
(※解読不能... )


The following, more specific, items are divided into rough categories:
	1. Platform independent kernel
	2. Platform independent userland
	3. Platform dependent kernel
	4. Platform dependent userland
	5. Other
後述する具体的な項目は、おおざっぱなカテゴリーに分けられます:
	1. プラットフォームから独立したカーネル
	2. プラットフォームから独立したユーザーランド
	3. プラットフォームに依存するカーネル
	4. プラットフォームに依存するユーザーランド
	5. その他

If you'd like to take on a project, please record your name/email,
the date that you're claiming a project (or part of a project--if
a part, please specify the part), and an expected completion date.
This will hopefully avoid both duplication of effort and too many
or too-extended stalls.

あなたがプロジェクトを引き受けたいと思うならば、あなたの名前/電子メール (あなたが主張しているプロジェクト
(プロジェクトの一部部分ならば、その部分を指定してください) の日付) と期待される完成日を記録してください。
これは、重複した作業と、あまりに多すぎるか、または拡張されすぎた stalls ( ※解読不能 ) を避けるためです。


PLEASE NOTE THAT THIS IS A VOLUNTEER PROJECT, AND THAT NONE OF THESE
RELEASE VERSIONS, OR NAMES, IS A GUARANTEE OF THE FUNCTIONALITY BEING
COMPLETE OR EVEN STARTED.  INTERESTED PARTIES SHOULD CONTACT

        core@NetBSD.org

これがボランティアプロジェクトであり、どのリリースバージョン (または名前)
も、完全であるか、または着手されている、ということを保証しているわけではないことに注意してください。興味がある方は以下に連絡してください。

        core@NetBSD.org


FOR MORE INFORMATION.
詳細な情報。

1. Platform independent kernel
1. プラットフォームから独立したカーネル
==============================
aa. Scheduler works
    Separation of context switching and thread scheduling.
	Responsible: yamt
	ETA: 5.0 (yamt-idlelwp branch)
    Generic scheduler API for modular implementations.
	Responsible: dsieger
	ETA: 5.0 (merged in yamt-idlelwp branch)
    New scheduler supporting POSIX Real-time features, CPU affinity and
    having a better support for MP systems.
	Responsible: rmind
	ETA: 5.0
aa. スケジューラ機能
	コンテキストスイッチの分離とスレッドのスケジューリング。
	責任者: yamt
	ETA: 5.0 (yamt-idlelwp ブランチ)
	モジュール実装のための汎用スケジューラ API。
	責任者: dsieger
	ETA: 5.0 (yamt-idlelwp ブランチにマージ)
	新しいスケジューラ (POSIX リアルタイム機能と、CPU 親和性と、MP システムのためのより良いサポート)
	責任者: rmind
	ETA: 5.0

ab. Reduction of the giant lock
    There are several proposals for the best way forward on this, but
    we really need a couple of people with time to step forward and
    lead us here.
	Responsible: ad
	ETA: 5.0 (vmlocking2 branch)
ab. ジャイアントロックの短縮( ※縮小? )
	このための最善の方法がいくつか提案されています。我々は本当に少数のひとたちとともに前進し、ここに導く時間を必要としています。( ※直訳 )
	責任者: ad
	aETA: 5.0 (vmlocking2 ブランチ)


ac. Expansion of wedge support
    Complete the development of wedges and retire disklabels except
    where needed for compatibility.
	Responsible: thorpej (possibly)
	ETA: 5.0
ac. wedge サポートの拡大 ( ※ wedge は英語のまま? )
	wedge の開発は完了しました。そして、互換性に必要があるのを除いて disklabels を引退させてください。
	責任者: thorpej (おそらく)
	ETA: 5.0


ad. Volume management
    Allow us to grow, shrink, and move partitions (and, where possible,
    filesystems).
	Responsible: TBD
	ETA: ?
ad. ボリューム管理
	パーティションを拡張、縮小、移動できるようにしてください (可能な限りファイルシステムがおこなうのがいいでしょう)
	責任者: TBD
	ETA: ?


ae. High-performance, maybe log-based, journalled fs w/ snapshot support
    Addition of logs, journals, and snapshots to FFS is a lot, another
    filesystem could be cleaner and faster.
	Responsible: simonb
	ETA: 5.0 (journaling + snapshots don't work together yet though)
ae. スナップサポートがある高性能の、そして、たぶんログベースのジャーナルファイルシステム
	FFS への追加するログ機能、ジャーナリング機能、スナップショット機能はたくさんあります。別のファイルシステムではもっと綺麗で速いかもしれません。
	責任者: simonb
	ETA: 5.0 (もっとも、ジャーナリングとスナップの組み合わせは、まだ同時に機能していません)


af. Expansion of ieee1394 support
    Where possible, fully support DV, disk, and network devices.
	Responsible: TBD
	ETA: Preliminary firewire support is in 4.0
af. ieee1394サポートの拡張
	可能な限り DV、ディスク、ネットワークデバイスをサポートします。
	責任者: TBD
	ETA: 4.0 では Preliminary FireWire をサポートしています。

ag. Generic device hotplug support
    Support hotplug of all devices and busses that support it.  This
    should be divided into subcategories and does cross over some into
    platform-dependent areas.  SATA, SCSI, FC, USB, Firewire,
    PCI (PCI-X, and PCI-Express), etc.  There is some rudimentary
    support present, but it is far from comprehensive.
	Responsible: bouyer
	ETA: ?
ag. 汎用デバイス hotplug サポート
	すべてのデバイスとそのバスの hotplug をサポートしています。
	これは、サブカテゴリに分割されるべきであり、いくつかのプラットフォームに依存する領域を超えません。
	SATA、SCSI、FC、USB、FireWire、PCI (PCI X と PCI-Express)
など、いくつかの初歩的なサポートがありますが、それは全く包括的ではありません。
	責任者: bouyer
	ETA: ?

ah. Suspend and resume support
    We should be able to fully use suspend and resume on PCs, macppc,
    and anyone else who supports it in hardware (sparc, hpcsh, hpcarm, etc).
	Responsible: jmcneill, joerg
	ETA: 5.0
ah. サスペンドとリジュームサポート
	PC、MacPPC、そしてサスペンドとリジュームをサポートしているハードウェア (sparc、hpcsh、hpcarmなど) ならば完全に使用できるはずです。
	責任者: jmcneill、joerg
	ETA: 5.0

ai. Complete support for LWPs
    There are still vestiges of the kernel that predate LWPification
    and should be updated.  [ What other than ktrace? ]
	Responsible: darrenr, skrll, christos did ktrace-lwp
	ETA: 4.0
ai. LWP の完全なサポート
	LWPification のころの名残りがまだカーネルにあるので、アップデートすべきです(ktrace 以外?)
	責任者: darrenr、skrll、christos は ktrace-lwp をしました。
	ETA: 4.0

aj. PTHREAD_CONCURRENCY > 1 support
    A single process that uses threads should be able to reliably
    use more than one CPU.
	Responsible: ad
	ETA: 5.0  (1:1 pthread come with newlock2)
aj. PTHREAD_CONCURRENCY > 1 サポート
	1 プロセスが確実に 1 つ以上の CPU を使用できるようにする必要があります。
	責任者: ad
	ETA: 5.0 (1:1 pthreadには、newlock2 はついて来ます)


ak. AIO support
    POSIX aio_*() with full support for Asynchronous I/O (AIO) in the
    kernel.
	Responsible: rmind
	ETA: 5.0
ak. AIO サポート
	POSIX aio_*() によるカーネルでの完全な非同期 I/O (AIO) サポート
	責任者: rmind
	ETA: 5.0


al. Modern parallel port support
    Complete support for bidirectional and "advanced" functionality
    from parallel ports.
	Responsible: jdolecek
	ETA: ?
al. モダンなパラレルポートサポート
	双方向パラレルポートと、先進的パラレルポートは完全にサポートしています。( ※ advanced とはなんぞや? )
	責任者: jdolecek
	ETA: ?


am. NFSv4
    Bring our NFS up to current standards.
	Responsible: TBD
	ETA: ?
am. NFSv4
	現在の NFS の基準まで上げてください。
	責任者: TBD
	ETA: ?

an. Update the locking mechanisms in the kernel
    This requires some platform support.  A good bit of work is on the
    now-archaic "newlock" branch, from thorpej.  It requires some
    overhaul of cpu_switch/scheduler so that mutex_*(9) and ltsleep(9)
    can interlock.
	Responsible: ad
	ETA: 5.0  (newlock2)
an. カーネルのロック機構をアップデートしてください
	これはいくつかのプラットフォームサポートを必要とします。
	thorpej による "newlock" ブランチでずっと作業しています。
	mutex_*(9) と ltsleep(9) が連動するために cpu_switch/scheduler のオーバーホールがいくつか必要です。
	責任者: ad
	ETA: 5.0 (newlock2)


ao. Review TCP/IP developments
    Fix NewReno
	Responsible: mycroft
	ETA: 3.0
    Add SACK support to the kernel.
	Responsible: kurahone
	ETA: 3.0
    Add ECN support to the kernel.
	Responsible: rpaulo
	ETA: 5.0
    Look into other "recent" and current TCP/IP research. Adapt our stack
    to the more modern world.
	Responsible: TBD
	ETA: ?
ao. TCP/IP 開発のレビュー
	NewReno はフィックスされました。
	責任者: mycroft
	ETA: 3.0
	aSACK サポートがカーネルに追加されました。
	責任者: kurahone
	ETA: 3.0
	ECN サポートがカーネルに追加されました。
	責任者: rpaulo
	ETA: 5.0
	"recent" と現在の TCP/IP 研究を調べてください。 よりモダンな世界へスタックを対応させてください。 ( ※ なんのこと? )
	責任者: TBD
	ETA: ?

ap. Kernel linker (ala FreeBSD's kld)
	Responsible: TBD
	ETA: ?
ap. カーネルリンカ (FreeBSD 由来の kld)
	責任者: TBD
	ETA: ?


aq. CARP/VRRP
    Functionality is great, but there might be some concern here over
    Cisco patents.
	Responsible: liamfoy
	ETA: 4.0
aq. CARP/VRRP
	機能は素晴らしいですが、シスコの特許による懸念がいくつかあります。
	責任者: liamfoy
	ETA: 4.0

ar. UDF filesystem support
    OpenBSD has recently added this.
	Responsible: reinoud
	ETA: 4.0
ar. UDF ファイルシステムサポート
	最近 OpenBSD が対応しました。
	責任者: reinoud
	ETA: 4.0


as. RAIDFrame support for 3-way RAID 1
	Responsible: TBD
	ETA: ?
as. 3-way RAID 1 のための RAIDFrame
	責任者: TBD
	ETA: ?


at. RAIDFrame support for RAID 6
	Responsible: oster
	ETA: 5.0?
at. RAID6 のための RAIDFrame サポート
	責任者: oster
	ETA: 5.0?


au. More modern drivers
    We lack support for a number of more modern devices (PCI-Express,
    RAID cards, etc.) that are supported on other open source OSes.
	Responsible: TBD
	ETA: ?
au. もっと多くのモダンなドライバー
	多くの他のオープンソース OS でサポートされているモダンなデバイス (PCI-Express、RAIDカードなど) がサポートされていません。
	責任者: TBD
	ETA: ?


av. iSCSI initiator support
    We should be able to use iSCSI volumes.
	Responsible: agc
	ETA: 5.0
av. iSCSI イニシエーターサポート
	iSCSI ボリュームを使用できるはずです。
	責任者: agc
	ETA: 5.0


aw. Run-time changeable limits to SysV IPC
    Some of the limits for SysV IPC are hardcoded in the kernel
    configuration--these should be changable via sysctl.
	Responsible: rmind
	ETA: 4.0
aw. 実行時に SysV IPC の設定値を変更する
	SysV IPC のいくつかの設定値がカーネルコンフィギュレーションでハードコードされています。─これらはsysctlで変更可能なはずです。
	責任者: rmind
	ETA: 4.0


ax. NUMA support
    To achieve this goal, the CPU scheduler should be modified to take into
    account the distances and grouping of CPUs.  Also, support of memory
    blocks should be implemented in the VM subsystem.
	Responsible: TBD
	ETA: ?
ax. NUMA サポート
	この目標を達成するなら、CPU スケジューラは、CPU の距離とグルーピングを考慮に入れるように変更されるべきです。
	また、メモリブロックのサポートは VM サブシステムで実装されるべきです。
	責任者: TBD
	ETA: ?


2. Platform independent userland
2. プラットフォームから独立したユーザーランド
================================
aa. Keep up with the X world
    Track X.org progress.  Maintain existing XFree86.
	Responsible: a cast of thousands
	ETA: ongoing
aa. X の保持
	X.org の進捗を追ってください。既存の XFree86 を維持してください。
	責任者: 数千人のキャスト
	ETA: 進行中

ab. Reentrant libraries
    Make sure that all libraries are re-entrant and usable for threaded
    applications.
	Responsible: ginsbach and others
	ETA: 5.0?
ab. リエントラントライブラリ
	スレッド化されたアプリケーションにすべてのライブラリが確実にリエントラントできるようにしてください。
	責任者: ginsbach 他
	ETA: 5.0?


ac. gcc updates
    This requires some work to rework the gcc4 builds to work with BSD
    make(1) or update BSD make(1) or consider the unthinkable.
	Responsible: mrg, matt
	ETA: 4.0
ac. gcc アップデート
	gcc4 を BSD make(1) で動作するようにするか、BSD make(1) をアップデートするか、または想像を絶する作業が必要です。
	責任者: mrg, matt
	ETA: 4.0


ad. gdb updates
	Responsible: skrll
	ETA: 5.0
ad. gdb アップデート
	責任者: skrll
	ETA: 5.0


ae. binutils updates
    Probably go along with gdb updates.
	Responsible: skrll
	ETA: 4.0
ae. binutils アップデート
	おそらく gdb アップデートと協力して作業します。
	責任者: skrll
	ETA: 4.0


af. Better post-mortem debugging tools
    It would be useful to have something between ps/*stat/etc. and
    gdb with a core file.  Something, perhaps, like SysV(?) crash(8).
	Responsible: TBD
	ETA: ?
af. より良い検死用デバッグツール
	ps, *stat, etc の間に何かあると便利です。あと gdb とコアファイルも。おそらく SysV(?) の crash(8) のようなものです。
	責任者: TBD
	ETA: ?


ag. Better 802.11 utilities and support
    To truly support mobile users, we need better support for scanning
    for base stations and affiliating with them.
	Responsible: dyoung, skrll, scw and others
	ETA: 4.0
ag. より良い 802.11 ユーティリティとサポート
	本当に、モバイルユーザをサポートするためには、基地局をスキャンしてそれらに加入することが必要です。( ※ 加入とはなんぞや? )
	責任者: dyoung、skrll、scw、他
	ETA: 4.0

ah. Internationalization
    Citrus, wide-char curses (SoC integration?), collation, localized
    printf with positional parameter support, time & currency
    support, etc.  NetBSD has a global user and developer base and
    our i18n support should reflect that.
        (a) Support cond. printf fmt. 4.0 will have vfwprintf with
	    positional parameter support; 5.0 will have vfprintf with
	    positional parameter support.
		Responsible: christos
		ETA: 5.0
        (b) Support LC_COLLATE
        (c) mklocale(1) -> localedef(1)
        (d) wchar_t in C++
        (e) i18nize userland commands
        (f) in-kernel iconv
		Responsible: TBD
		ETA: ?
ah. 国際化
	Citrus、ワイド文字対応 curses(SoC に統合?)、文字照合、位置パラメーター対応のローカライズされた printfサポート(
※ もっと簡潔な表現はないか? )、時刻と通貨サポート、そのほか。NetBSD にはグローバルなユーザーと開発者ベースがあり、そして
i18n はそれらを反映すべきです。
		(a) Support cond. printf fmt: 4.0 には、位置パラメタサポート対応 vfwprintf があるでしょう。
5.0 には、位置パラメタサポートがある vfprintf があるでしょう。
		責任者: christos
		ETA: 5.0
		(b) LC_COLLATEサポート
		(c) mklocale(1) -> localedef(1)
		(d) C++ における wchar_t
		(e) i18n 化されたユーザーランドコマンド
		(f) カーネルにおける iconv
		責任者: TBD
		ETA: ?


ai. System packages
    In some fashion, we need to support system packages.  This is at
    least to allow for sane binary audits and binary patches.
	Responsible: apb
	ETA: 4.0
ai. システムパッケージ
	いくつかの流儀によりシステムパッケージをサポートする必要があります。これは、少なくともまともなバイナリ監査およびバイナリ形式のパッチを可能にします。
	責任者: apb
	ETA: 4.0

aj. Provide support for binary packages in install
    We should have an integrated install that can install a desktop as
    functional as other free operating systems.  Without sacrificing
    the quick and clean basic installs that we have now.  An extension
    of sysinst might fit the bill.  Or a tool that's both invoked by
    sysinst and available on a running system, e.g. pkgsrc-wip/pkg_select.
	Responsible: agc and others
	ETA: 4.0
aj. インストール時におけるバイナリパッケージの提供
	現在の迅速で美しい( ※ the が付いてるけどどういうこと?
)基本的なインストール環境を犠牲にせずに、他のフリーのオペレーティングシステムと同じくらい機能的なデスクトップをインストールできる統合インストールがあるべきです。sysinst
の拡張はこの要望を満たすかもしれません。または sysinst によって呼び出されるツールや、実行中のシステムで利用可能なツールです(例えば
pkgsrc-wip/pkg_select)。
	責任者: agc 他
	ETA: 4.0

ak. Native signing/privacy software
    This could be BPG (from SoC) or openpgp-sdk.
	Responsible: agc, cjs and others
	ETA: 4.0?
ak. ネイティブの署名/秘匿性ソフトウェア
	これは BPG(SoC からの) または openpgp-sdk かもしれません。
	責任者: agc、cjs、他
	ETA: 4.0?

al. Userland version identification
    What binaries are installed?  Who really knows?  This relates at
    least somewhat to (ai).
	Responsible: TBD
	ETA: ?
al. ユーザーランドバージョン識別
	どんなバイナリがインストールされていますか?だれが本当に知っていますか? 少なくともこれは ai. にいくらか関連します。
	責任者: TBD
	ETA: ?

3. Platform dependent kernel
3. プラットフォームに依存するカーネル
============================
aa. Move evb ports to evb* if they're not already there (sandpoint)
    The existing evb* ports are kind of catch-all ports for eval boards.
    Some of the existing non-evb* ports really belong in the evb* category.
	Responsible: TBD
	ETA: ?

aa. evb ポートがすでに sandpoint ポートに無いならば、evb ポート を evb* の方へ動かしてください(sandpoint)
	既存の evb* ポートは、どんな種類の評価ボードにも対応します。既存の非 evb* ポートのいくつかは、本当は evb* カテゴリーに入ります。
	責任者: TBD
	ETA: ?

ab. m68k ports need to share more code
    Some progress has been made here in recent years, but there is more
    work to be done.
	Responsible: TBD
	ETA: ?
ab. m68k ポートは、より多くのコードを共有する必要があります
	近年いくつかの進歩が見られましたが、まだまだやるべき仕事があります。
	責任者: TBD
	ETA: ?

ac. Kernel core dump support for all platforms
    Some platforms (PowerPC ports, ARM ports, etc.) don't have full
    support for kernel core dumps and post-mortem debugging through
    libkvm.  This should be updated.
	Responsible: TBD
	ETA: ?
ac. すべてのプラットフォームのカーネルコアダンプサポート
	いくつかのプラットフォーム (PowerPC ポート、ARM ポートなど) は、カーネルコアダンプや libkvm
を使った検死デバッグを完全にはサポートしていません。これをアップデートすべきです。
	責任者: TBD
	ETA: ?

ad. NDIS
    Support for binary network drivers on x86 platforms.
	Responsible: rittera
	ETA: 4.0
ad. NDIS
	x86 プラットフォーム上のバイナリーネットワークドライバーのサポート
	責任者: rittera
	ETA: 4.0

4. Platform dependent userland
4. プラットフォームに依存するユーザーランド
==============================
ab. m68k should be able to share sets
    Some progress has been made here in recent years, but there is more
    work to be done.
	Responsible: TBD
	ETA: ?
ab. m68k は sets を共有できるはずです
	近年いくつかの進歩が見られましたが、まだまだやるべき仕事があります。
	責任者: TBD
	aETA: ?


5. Other
5. その他
========
aa. More and better regression tests
    The suite of tests that we have now is limited.  We should expand
    these and provide systems (or manage a volunteer pool?) to run the
    tests on -current and release branches on a variety of platforms.
    We also need to migrate all the tests that currently live in
    'regress' to 'tests' so that they can make use of ATF.
    ( Need to virtualize some with qemu or similar? )
	Responsible: jmmv
	ETA: 5.0 should have most of regress converted

aa. より多くのより良い回帰テスト
	現在持っているテストスイートは限られています。さまざまなプラットフォームの current と
リリースのブランチ用のテストを運用するために、システムを提供するするべきです (またはボランティアプールを管理する? )。また、ATF
を利用できるようにするために現在の 'regress' から 'tests' の環境( ※ live とは?
)のすべてをテストできるようにする必要があります。(qemu か同様の物を仮想化するためにも必要です)
	責任者: jmmv
	ETA: 5.0 には、変換された回帰が最も多くあります。

ab. Native Java on multiple platforms
    Getting i386, amd64, sparc64, and PowerPC would be a good start,
    although PowerPC will require more work.  We have the go-ahead,
    but we need the people to work on it.
	Responsible: the Java porting crew
	ETA: ?

ab. 複数プラットフォームのネイティブ Java
	i386、amd64、sparc64、PowerPC を入手すれば好調にスタートできるでしょう。PowerPC
は、より多くの仕事を必要とするでしょうけれど。スタートできますが、利用者がこれに取り組む必要があります。
	責任者: Java 移植作業員
	ETA: ?

ac. Power control framework
    Related to suspend/resume support, we should have some framework
    for dynamically stepping processor speed, controlling fans, shutting
    down and/or powering subsystems to conserve power and keep the system
    with thermal limits.
	Responsible: TBD
	ETA: ?
ac. 電源制御装置フレームワーク
	サスペンド/リジュームに関連して、プロセッサーの動的ステップスピード、ファン制御、シャットダウンや省電力のための電源サブシステム、熱制限値使用によるシステム維持、といういくつかのフレームワークがあります。
	責任者: TBD
	ETA: ?
<<ここまで

-- 
みわ