Mahara開発概要

作成中です - mits

このページではMaharaプロジェクトの開発プロセス全体に関して説明しています。コードに関する技術的詳細はDeveloper_Area/Mahara_Architecture_Introductionをご覧ください。

誰がMaharaを作っていますか?

• Catalyst IT (http://catalyst.net.nz) はMaharaを考案した法人であり、その開発を主導しています。Catalystはhttps://mahara.orgを運用しています。また、フルタイムの (小さな) Mahara開発チーム (「Mahara HQ」と呼ばれます) を保持しています。そして、現在、Maharaリリースサイクルの大部分を担当しています。

• Mahara貢献者 (Contributors) Maharaを改善する人、そしてコミュニティと改善点を共有する人を含みます。一部はMaharaを使用している学校または大学からの貢献者です。そのほかはMaharaインストレーションをサポートするCatalystのような法人です。それから、Maharaに熱心なユーザがいます。貢献の幅は個人によるバグ修正から、システム全体におよぶ機能増強まであります。
  • 一般の方の貢献も歓迎します。
  • LaunchpadにMahara貢献者チームもあります。どなたでもお気軽にご参加ください。
  • 他の貢献者のパッチを「+1 レビュー」済みおよび検証済みであるとマークするため、誰でも「Maharaテスター」グループに参加することもできます。IRCまたはmahara.orgフォーラムでお尋ねください。
• Maharaレビューア 「+2 レビュー」を持つユーザであり、Maharaコードレビューシステム ([1]) にコミットアクセスすることができるユーザです。Maharaコードの質を保証するため、すべての寄贈コードはコード作者ではない信頼できるレビューアによりレビューおよびコミットされます。
  • レビューアになるための手順は次をご覧ください: Developer_Area/Commit_Policy#Becoming_a_reviewer
  • 加えて、gerritグループ、LaunchpadでMaharaプロジェクトの権限を管理するLaunchpad「Maharaグループ」があります: https://launchpad.net/~mahara-reviewers

• Mahara セキュリティチームはMaharaレビューアの一部であり、セキュリティ問題をレビューします。
  • すべての承認Maharaレビューアにおいて、セキュリティに興味のある人、また信頼できる人は自由にaharaセキュリティチームに参加してください。

• Mahara翻訳者はMaharaの翻訳およびユーザマニュアルの翻訳をサポートしている人です。
  • Mahara翻訳者は参加している言語に関して、Launchpadの翻訳グループに招待されます。

Maharaバージョン

詳細は6MonthlyCycleをご覧ください。

Mahara 1.8から始まって、Maharaは4月および10月の新しい「メジャーリリース」を含む、6ヶ月ごとのリリースサイクルに従っています。メジャーリリースは0.1ずつ (1.5 -> 1.6 -> 1.7) バージョンナンバーが増分されます。また、重要な新しい機能を含みます。

Maharaマイナーリリースにはバグ修正およびセキュリティ修正のみ含みます。固定されないスケジュールに従って、必要に応じてマイナーリリースされます。マイナーリリースは0.0.1ずつ (1.7.0 -> 1.7.1 -> 1.7.2) バージョンナンバーが増分されます。

サポートライフタイム

詳細はSupportedVersionsをご覧ください。

現在、Maharaは最新の3メジャーバージョンに関して、アップデート (マイナーリリース) を提供しています。このドキュメントを執筆している現在、これには1.8、1.7および1.6が含まれます。 古いバージョンのコードベースを利用することはできます。また、オープンソースプロジェクトとして、修正およびバックポート (新しいバージョンの機能を古いバージョンに移植) も歓迎します。しかし、Maharaプロジェクトが古いバージョンに関してサポートできるのは、新しいサポートされているバージョンに古いバージョンをバージョンアップする場合のみです。

最新バージョンのMahara 1.8では1.1.0またはそれ以降のバージョンにアップグレードすることができます。まだMahara 1.0のインストレーションが存在する場合、あなたは1.8にアップグレードする前に1.1.0にアップグレードする必要があります。

バグ管理 (Issue tracking)

詳細はDeveloper Area/Bug Statusをご覧ください。

バグ管理は重要な継続的品質管理の一部です。これには問題 (バグ) の報告、改善のためのアイデア、新しい機能の提案を含みます。多くの専売権付きソフトウェアと異なり、Maharaの問題報告および追跡情報はすべての人に対してオープンにされています。MaharaバグはLaunchpad.netのMaharaプロジェクト (https://bugs.launchpad.net/mahara) を使用して報告および追跡されています。

すべてのMaharaユーザは自由にバグ追跡 (issue tracker) の積極的な参加者になることができます。Launchpadのアカウントを持っている人は誰でもバグ報告の作成、閲覧、コメント投稿および監視することができます。

コードの場所 (Where the code lives)

詳細はDeveloper_Area#Getting_set_upをご覧ください。

MaharaのZIPファイルはLaunchpadからダウンロードできるのに対して、Mahraの完全なコードベースはgitバージョンコントロールシステムで管理されています。「ライブ」コードベースはhttps://reviews.mahara.orgにある私たちのGerritコードレビューシステム内gitリポジトリに置かれています。そして、このリポジトリは同時にgitriousプロジェクトと同期されます: https://gitorious.org/mahara

コードブランチ (Code branches)

Maharaはそれぞれのメジャーリリースに関して、1.8_STABLE、1.7_STABLE、1.6_STABLEのような名称でgit「ブランチ」に分けられています。そして、すべてのブランチは1.0_STABLEに遡ることができます。加えて、次のメジャーリリースのための開発用の場所「master」があります。

あなたのコードがMaharaコアコードになるために (How your code becomes Mahara core code)

では、どのようにすれば、あなたのような寄贈者が自分のMaharaコードを次のMaharaリリースのために公式gitリポジトリに入れることができるのでしょうか?

コーディングガイドライン (Coding Guidelines)

詳細はDeveloper Area/Coding guidelinesをご覧ください。

最初に寄贈者がいくつかのコードを作成します。Maharaには緩いコーディングガイドラインがあり、通常、コードはPHPのベストプラクティスに従うよう期待されています: コードの取り囲みにより「調和 (blending in)」させること、Mahara既存のAPIを使用すること、コードを最大限再利用すること、そしてAPIの変更を最小限にすることにより、セキュリティ慣習に従っています。

コードを共有する (Sharing the code)

詳細はDeveloper Area/Contributing Codeをご覧ください。

そして、寄贈者はMaharaプロジェクトとコードを共有します。技術能力が適切なレベルにあるユーザにとって好ましい方法は私たちのGerritコードレビューシステムに直接コードを投稿することです。しかし、私たちはパッチファイル、PHPファイル、詳細を記述したLaunchpadのコメントでも歓迎します。これらの場合、Maharaレビューアは寄贈者に代わってGerrit Changeを作成することができます。In those cases, a Mahara reviewer can create a Gerrit Change on the contributor's behalf

コードレビュー (Code review)

See Developer Area/How to Review Code and Developer Area/Code Review

The submitted Change (aka "patch") in Gerrit is then reviewed and verified (tested). Each patch must receive a "+1" verified score, which means that someone tested it and found that it worked. It must also receive a "+2" reviewed score, which means that an approved Mahara Reviewer examined the code and saw no problems with it. If the patch fails testing or contains review problems, the tester or reviewer will leave a friendly comment explaining what the contributor needs to change and why. The contributor can then submit a revised version, which will be reviewed and tested anew.

Once the Change has been verified and reviewed, a Mahara Reviewer can then instruct gerrit to merge it into the appropriate branch. It will then be included in the next Mahara release.

セキュリティ問題 (Security issues)

See Security#How_to_report_a_security_issue?

There's a separate, parallel process for handling Mahara security issues, in order to ensure that they aren't disclosed to the public until after a patch is released.

プラグインおよびAPI (Plugins and APIs)

See Developer Area/Plugins

Although Mahara is open source and you can change anything you want, the best and most maintainable way to extend Mahara is to write a plugin. Plugins are a directory of code that can be simply "dropped" in to any Mahara installation and it will be detected, installed, and automatically made available as a tool within the Mahara interface.

Plugins can also easily be shared with other Mahara sites without having to go through the process of being "upstreamed" into Mahara core. There's even a page on the Mahara wiki for sharing "third-party" Mahara plugins: See プラグイン