Joomla! Documentation™

この記事は新しいバグが報告されてからそれが解決されるまでのJoomla! バグトラッキングの過程について書かれています。

Joomla! のバグは Joomla! 課題トラッカーで追跡され、このトラッカーは、サポートされているJoomlaのバージョンに関する問題を対象としています。推奨バージョンは J3.10 です。

手助け

Joomlaのバグを修正するために、Joomla バグスクワッドのメンバーである必要はありません。誰でもバグを報告し、パッチをテストしたり、パッチを提出することができます。あなたがバグを解決するのを手助けしたいのであれば、トラッカーへどうぞ。下記のような未解決問題の解決にを手助けください。確認済みの問題のパッチを作成して提出することができます。または、保留中の問題のテストを手伝うこともできます。あなたが行ったことについて報告するには、Githubアカウントでログインし、コメントを追加してください。Joomlaプロジェクトに貢献することがどのくらいのインパクトがあるか、どれほど気分が良いか驚くことでしょう。 JBSへの参加についてご不明な点または興味がある場合は、バグスクワッドコーディネータまでお問い合わせください。

プレリリースのテスト

Joomlaの安定したリリースがリリースされる前に、更新プログラムのテストが必要です。 これは簡単なプロセスです：

1. 現在の安定版のJoomlaをサブフォルダまたはlocalhostにインストールします（本番サイトのコピーを使用できますが、実稼動サイトでは絶対にテストしないでください）
2. Joomla! 更新コンポーネントのオプションに移動し、「更新するサーバ」を「テスト」に設定します。コンポーネントJoomlaの更新
3. Joomlaのプレリリースがテストの準備ができたら、テストサイトにログインしてアップデートをインストールしてください。 次に、サイトが正常に動作するかどうかをテストします。エラー/バグを Joomla! 課題トラッカーで報告してください。

問題の報告

プロセスは通常、次の2つの方法のいずれかで開始されます。バグがそれぞれのトラッカーに追加されるか、ユーザーがバグをJoomla! バグフォーラム で所定のメンテナンスリリースについて報告します。

フォーラムで報告された問題

JBSのメンバーはフォーラムをスキャンし、いつ問題をトラッカーに入れる必要があるのかを判断します。 問題が再現可能で、明らかにバグであり、それを再現する方法についての段階的な指示がある場合は、確認済みの状態でトラッカーに入力することができます。それが明確でない場合、「オープン」のステータスで入力することができるので、他のJBSメンバーはさらなる調査が必要になってきます。

トラッカーに直接報告される問題

トラッカーに問題が追加されると、ステータスは状況に応じて変化します;

1. 新規
2. 確認済
3. 保留中

問題の調査がさらに必要な場合は、「新規」に設定する必要があります。問題が (1) バグであり (2) 再現可能であり (3) わかりやすいテスト指示がある場合は、それは「確認済」に設定する必要があります。 3つの確認基準を満たし、良好なパッチが添付されている場合は、[保留中]に設定する必要があります。 ステータスコードの詳細については、以下を参照してください。

問題の優先度

なぜほとんどの問題が優先度3または中なのか。成果物は、以下の特性に応じて優先順位付けされます。

極めて重要 (1): 主要部分がまったく動作していない。ソースの重要な部分が破損し、キー操作ができない場合。例としては、ログイン、インストール、エクステンションインストーラ、javascriptエラーなど、保存や類似のアクションの移動を妨げるものがあります。また、致命的なPHPエラーの発生やプレリリースでの主要なセキュリティ問題も含まれます。（安定版のセキュリティ問題はトラッカーに報告されるべきではなく、セキュリティチーム security@joomla.org に報告されるべきです）

緊急 (2): ソースの一部が、重大な方法で操作を妨げているか、または宣伝された機能に大きな損失を引き起こしている場合。例には、PHPの通知や警告、および報告されたJavaScriptエラーが含まれます。主な問題は、ベータからリリース候補（RC）に、またはリリース候補が一般アベイラビリティ（GA）へ移行するリリースサイクルを妨げることもあります。

Medium (3): Issues that are hindering advertised behavior but the application is still workable. Examples would include parameters not working as advertised, language files not loading as expected, etc.

Low (4): Minor loss of function and generally annoying behavior. May include less common platform or browser specific problems that while they may be technically major in those environments, they represent a minority. Also include missing translation strings.

Very low (5): Cosmetic problems, misspelled words, graphically misaligned object, less common issues with parameters, etc.

問題の解決

The bug squad takes care of the Joomla releases. For example, that means getting the 3.4, 3.5, ... etc releases ready by fixing problems that come up. The idea is to make the release increasingly stable and take care of issues that come up. At the same time, it is vitally important not to break anything that is working. That's called software regression and it's not something you want at this stage. In the trackers there are several common statuses, mainly: new, confirmed, pending, ready to commit.

• New means it's reported, but it hasn't been determined for sure whether it is a real bug or not. Many Open issues are not actually bugs. If the issue fits into one of the categories below, then the status is changed as indicated and the bug is closed:
  • Cannot be reproduced. We have tried the same thing the reported did but the software appears to work correctly. (In many cases, more information is needed to be able to reproduce a bug. See "Information Required" below.) Change status to Unconfirmed Report.
  • Has already been reported in a different issue number. Change status to Duplicate report and add the number on the duplicates tab.
  • Is a known limitation of the software. Change status to Known issue.
  • Is a feature request, a mistake made by a user, or is the way the software is intended to work. Change status to Expected Behaviour.
  • Is a bug with an extension or some other external program or a server issue that will not be addressed. Change status to Closed and leave a comment explaining the reason.
• Information Required is used if we need more information from the person who reported the issue to decide about the issue. For example, there are questions about how to reproduce the problem or other questions about the issue. If we get the information we need, then we can continue processing the issue. If we don't get the information within two weeks, then we can change the status to Unable to confirm (or another of the closed status codes if that is more applicable).
• Needs Review is used if we need a PLT Member or CMS Maintainer for a review / decision. This is different from Information Required, which means that we need more information from the person who reported the issue.
• Confirmed means that JBS has confirmed that this issue is a bug in Joomla! that should be fixed. That's when the JBS tries to solve it or consults with the development team about a solution. At this point there should be clear step-by-step test instructions that indicate how to reproduce the problem.
• Pending means that a patch has been submitted. Every Pending issue should have instructions that tell the tester how to reproduce the problem and make sure the patch fixes the problem.
• Ready to commit means that (in general) two separate people have successfully tested the same patch file, and it works correctly with the patch. Note that, for some issues that are more complex or higher impact, we may need more than two people to test or may need to test on multiple platforms. For simple issues, such as fixing typos in language strings or comments, one tester is enough.
• Fixed in Code Base means that, after reviewing the code, the JBS commit coordinators have determined that the patch is good and the change has been committed to the Joomla! code-base. At this point, it will be part of the next Joomla! maintenance release.

The Easy Test-mark is not a dedicated status, it is more a label to show Pending issues with easy test instructions.

以下のフローチャートは、バグを解決するプロセスがどのように機能するかを視覚的に示しています。