Roadmap (ロードマップ)

CPAN Testers is a complex ecosystem of tools and the complexity keeps growing as one tool or another adds features. This page is intended for discussion and brainstorming about current issues and challenges and how to manage complexity over time. Please add issues or comment on existing ones.
The roadmap is currently divided into "version 1" and "version 2" plans.

CPAN Testers は ツールの複雑なエコシステムで その複雑さは増え続けます ひとつツールやその他のものが 機能を追加することで. このページは目的としています 現在の問題についての議論とブレインストーミングそれからチャレンジとどのように複雑さを管理するか 時間とともに. 追加してください 既存の問題やコメントを.
ロードマップは現在分かれています "version1" と "version2" のプランに.

Version 1.0

The current CPAN Testers infrastructure:

現在の CPAN Testers のインフラ:

・CPANPLUS or CPAN::Reporter support manual or automated testing
・Test::Reporter used for low-level report creation and transport
・Reports received at cpan-testers mailing list
・Reports archived on NNTP
・Websites generated from statistics mined from NNTP

・CPANPLUS または CPAN::Reporter はサポートします 手動または自動化テストを
・Test::Reporter は使われます 低レベルのリポート作成と転送に
・受信したリポート cpan-testers メーリングリストで
・アーカイブされたリポート NNTP で
・生成されたウェブサイト NNTP から採掘された統計から

With authenticated SMTP transport now provided in Test::Reporter, there are few plans for the 1.0 roadmap beyond critical bug fixes.

認証された SMTP トランスポートによって 現在 Test::Reporter で提供されている, ほとんどありません 1.0 ロードマップの計画は 致命的なバグフィックスの他には.

Open issues:

未解決の問題:

・HTTP transport: A simple HTTP-to-email gateway is available via Test-Reporter-HTTPGateway and Test-Reporter-Transport-HTTPGateway, but this requires one to host their own HTTP gateway. No centralized gateway has been established.

・HTTP トランスポート: シンプルな HTTP-to-email ゲートウェイは利用可能です Test-Reporter-HTTPGateway と Test-Reporter-Transport-HTTPGateway を介して, しかしこれは必要とします ホストするものを 独自の HTTP ゲートウェイを. 中央集権化されたゲートウェイは確立されていません.

Version 2.0

Version 2.0 is a proposed future architecture to address current limitations. Some desired features for 2.0:

Version 2.0 は提案された将来のアーキテクチャです 現在の制限に対処するために. いくつかの望まれた機能 2.0 で:

・Consistent grading logic across all tools
・Reports sent via HTTP instead of email
・Reports stored in a central database instead of NNTP
・Author notification via a centralized service instead of by each individual tester
・Reports with structured data instead of plain text (e.g. prereqs found)

・一貫したグレーディング (格付け) ロジック すべてのツールにわたる
・HTTP を介して送られるリポート email の代わりに
・中央データベースに格納されるリポート NNTP の代わりに
・中央化されたサービスを介した Author (作者への) 通知 それぞれ個別の tester によるものの代わりに
・構造化データによるリポート プレーンテキストの代わりに (e.g. prereqs found)

The CPAN-Testers namespace was reserved for this next generation and some initial work on a database component was done as part of the Oslo QA Hackathon 2008.

CPAN-Testers の名前空間は予約されています この次世代のために それと いくつかの初期作業は データベースコンポーネントの 一部として行われました Oslo QA Hackathon 2008 で.

Design notes (デザインノート)

Testing components (テストのコンポーネント)

These will be used by CPAN, CPANPLUS and/or smoke programs to create reports and submit them to a central database.

これらは使われます CPAN, CPANPLUS, それと/または スモークプログラムによって リポートの作成やそれらを中央データベースに投稿するために.

・Harness to run tests and capture output
・CPAN Testers report object
・Grader to generate a report
・Editor to let user edit or comment (text or GUI)
・Transporter to submit report

・テストの実行と出力をキャプチャするためのハーネス
・CPAN Testers リポートオブジェクト
・リポートを作成するためのグレーダー (評価者)
・ユーザが編集やコメントするためのエディタ (テキストまたは GUI)
・リポートを投稿するためのトランスポータ

These should live under the CPAN::Testers::* namespace. Most functions can be taken from either CPAN::Reporter or Test::Reporter with some refactoring.

これらはあるべきです CPAN::Testers::* の名前空間にの下に. ほとんどの機能は取れます それぞれ CPAN::Reporter や Test::Reporter から いくつかのリファクタリングで.

See the CPAN Testers Client page for more.

参照します CPAN Testers Client ページを 詳細のために.

Database components (データベースコンポーネント)

This needs to support both current reports (just text) and future reports (structured data). In Oslo, the consensus was to focus on an object database, with the side benefit of supporting other projects that create or provide information about CPAN Distributions (e.g. CPANTS). Components include:

これはサポートする必要があります 両方を 現在のリポート (ただのテキスト) と将来のリポート (構造化データ). Oslo では, コンセンサスはオブジェクトデータベースに着目することでした, 副次的な利点とともに 他のプロジェクトをサポートすることの CPAN Distributions (e.g. CPANTS) に関する情報の作成や提供をする. コンポーネントは含みます:

・Generic data object classes
・Database for central storage of data objects
・Client library to query, submit to or retrieve from the database
・Web server to receive CPAN Testers reports via HTTP
・Web server to query central database of reports (for analysis or reporting)

・汎用データオブジェクトクラス
・データオブジェクトの中央ストレージのためのデータベース
・問い合わせ, 投稿またはデータベースからの取得をするためのクライアントライブラリ
・HTTP を介して CPAN Testers リポートを受信するための Web サーバ
・リポートの中央データベース (分析やリポート用) に問い合わせをするための Web サーバ

See the CPAN Metabase page for more.

参照します CPAN Metabase ページを 詳細のために.

Statistics/reporting components (統計/リポート コンポーネント)

Downstream web servers or daemon services to analyze and/or act on reports submitted.

下流の Web サーバまたはデーモンサービスです 解析 and/or 作用するための 投稿されたリポートを.

These should live under the CPAN::Testers::WWW::* namespace. Although there are currently distributions under the CPAN::WWW::Testers namespace, the plan is to move these to the newer namespace in future releases.

これらはあるべきです CPAN::Testers::WWW::* 名前空間の下に. 現在は CPAN::WWW::Testers 名前空間の下にありますが, 計画ではこれらを移動します 新しい名前空間に 将来のリリースで.

Author Notification System (作者通知システム)

・Centralized notifications service for authors (e.g. email, RSS)
  ・Should have a way to honor author preferences about notification, either through a web interface or through an AUTHOR.yml file on CPAN
  ・A distribution YAML file would be too much of a load on the central server, as it would require continual CGI requests.

・authors のための中央化された通知サービス (e.g. email, RSS)
  ・通知に関する author の設定を尊重する方法を持つ, web インタフェイスを通じた または CPAN の AUTHOR.yml ファイルを通じて
    ・ディストリビューション YAML ファイルは 負荷が大きくなりすぎる 中央サーバでの, それは継続的な CGI リクエストをするので.

・Some possible preferences to offer authors are: to opt out entirely, to only get reports about the most current version of their module, to only get one failure report per module version, perl version, or OS.
・potentially allow people to sign up for reports about modules they don't own
  ・This might be better to do via the RSS feeds.

・authors に提供するいくつかの可能な設定は: すべてオプトアウトにする, リポートを取得するだけにする そのモジュールの最新のバージョンに関する, 1 つの失敗リポートを取得するだけにする モジュールバージョン, perl バージョン, または OS ごとの.
・人々がサインアップすることを可能にするかもしれない 彼らが所有していないモジュールに関するリポートに
  ・これは良いかもしれない RSS フィードを介して行うのが.

The notifications system prototype is being based on a simple database, and looks to be the right way to go. It enables faster lookups and when there are around 10,000 reports to be reviewed in a single run, a quick lookup is important to allow the server to concentrate on other parts of the system.

通知システムのプロトタイプは シンプルなデータベースに基づいています, それと 正しい方法であるように見えます. それはより高速な検索を可能にします それと 約 10,000 のリポートをレビューする場合があるときは, クイックな検索が重要です サーバが集中できるように システムの他の部分に.

TODO List:
・set default to only notify on the latest version of a distribution
・Include distribution name/version in subject line (suggested by Mark Stosberg)
  ・Only works if one instance included in message
  ・Could reference how many distributions listed in notifications if multiple distributions

・include preferences for osname, perl version and distribution version
  ・distribution version could be tricky, unless latest version is automatically included

TODO List:
・セットする ディストビューションの最新のバージョンの通知のみに
・含める サブジェクトラインにディストリビューション名/バージョンを (Mark Stosberg による提案)
  ・メッセージに 1 つのインスタンスが含まれる場合のみ機能する
  ・通知にいくつのディストリビューションがリストされているかを参照できる 複数のディストリビューションの場合に

・設定を含む osname, perl バージョン それと ディストリビューションのバージョンのための
  ・ディストリビューションのバージョンはトリッキーかもしれない, 最新のバージョンが自動的に含まれない限り

Author Preferences Website (作者の設定 Web サイト)

・Website to display report summaries (and drill down to individual reports) by author or distribution
  ・this should be possible with the dynamic version of the Reports website.

・Web サイト リポートのサマリを表示する (それと個々のリポートにドリルダウンする) author またはディストリビューションによる
  ・これはリポート Web サイトの動的バージョンで可能になるはず

Ohter tools

・Legacy gateway to capture reports submitted to perl.cpan.testers into new database

・perl.cpan.testers に投稿されたレポートをキャプチャするレガシーゲートウェイを 新しいデータベースに

Implementation notes (実装ノート)

・Need to find hosting for database and notification service
  ・currently being hosted by Birmingham.pm, plans are afoot to move to a new RAID enabled server.

・Old reports need to be ported into the new database
  ・extra field in the database to indicate the submission method, SMTP or HTTP, which together with the report id forms the primary key.

・CPAN, CPANPLUS and smoking tools need to be rewritten to use new client tools
・Existing stats/analytics sites will need to be ported to use new database
  ・a minor change, as it should still be able to use the same SQL, assuming there will still be parsing of the reports into a metadata table.

・見つける必要がある データベースのホスティングサービスと通知サービスを
  ・現在は Birmingham.pm によってホストされていて, 新しい RAID 対応サーバへ移動する計画が進行中

・古いリポートを移植する必要がある 新しいデータベースに.
  ・データベースの拡張フィールド サブミッションメソッドを示すための, SMTP or HTTP, それはリポート ID とともにプライマリキーを形成する.

・CPAN, CPANPLUS とスモーキングツールを書き直すひつようがある 新しいクライアントツールを使うために
・既存の統計/分析サイトを移植する必要がある 新しいデータベースを使うために
  ・マイナーチェンジ, 同じ SQL はまだ使えるはず, 依然としてリポートの解析がされると想定して メタデータテーブルへの.

Open issue (未解決の問題)

・What mechanism should identify/authenticate testers?
  ・Could leverage an existing mechanism (e.g. PAUSE) or could be a new service to manage API keys
    ・PAUSE is only for CPAN Authors, there are many hundreds of testers who are not authors. We want to encourage almost anyone to be able to submit reports, however we do need to ensure that testers acknowledge their potential involvement. Some use unreachable email addresses, some are just regular users who are installing modules occasionally. Need to differentiate these testers from the high volume and/or responsive testers.

・Disputing and/or withdrawing reports is a common request by some CPAN authors and testers
  ・dynamic reports site should have a button that authors/testers can raise as an issue. This can then be reviewed by an admin to mark the report as incorrect. The report is not deleted, to avoid reparsing by accident or being deleted by accident, but marked in someway that the Reports, Statistics and any other site knows not to include that report.
  ・Authors should not be able to delete reports, there needs to be a review process.
  ・Testers should be asked to confirm a marked report.

・何のメカニズムで識別/認証するべきか testers を ?
  ・既存のメカニズム (e.g. PAUSE) を活用する または API keys を管理する新しいサービスにする
    ・PAUSE は CPAN Authors だけのためのもの, author でない testers は何百人もいる. 私たちは奨励しています ほとんど誰もがリポートを投稿できるように, しかしながら私たちは確認する必要がある testers が関与する可能性を受け入れるかを. 到達しない email アドレスを使うものがいて, 時折モジュールをインストールする普通のものもいる. 区別する必要がある これらの testers を ハイボリューム and/or 応答する testers と.

・リポートへの異議 and/or 取り下げは いくつかの CPAN author と testrs による一般的な要求
  ・動的リポートサイトはボタンを持つべき authors/testers が問題を提起できる. これで 管理者が見直すことができる リポートを誤ったものとしてマークして. リポートは削除されない, アクシデントによる再解析やアクシデントによる削除を避けるために, しかし 何らかの方法でマークする そのリポート, 解析それと他のサイトがそのリポートを含まないことを知っていると.
  ・Author はリポートを削除できないはず, レビュープロセスが必要になる.
  ・Testers はマークされたリポートを確認するように求められるはず.

NEXT

次回は、Future Development の「 Wishlist 」を確認します。



参考情報は書籍「 続・初めての Perl 改訂版 」, 「 Effective Perl 第 2 版 」を中心に perldoc, Wikipedia および各 Web サイト。それと詳しい先輩。

目次 - Perl Index