Процесс отслеживания ошибок

From Joomla! Documentation

This page is a translated version of the page Bug Tracking Process and the translation is 35% complete.

Outdated translations are marked like this.
Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎日本語 • ‎русский • ‎svenska

Эта статья описывает текущий процесс отслеживания ошибок Joomla! с момента уведомления о новой ошибке до момента её устранения.

Ошибки Joomla! отслеживаются в Joomla! Issue Tracker, этот Трекер для описания проблем с поддержкой Joomla Versions. Рекомендуемая версия J3.9.

Помощь

Вам "не" нужно быть членом отряда Joomla! Bug Squad, чтобы оказывать помощь в исправлении ошибок в Joomla. Любой может сообщить об ошибке, тестировать заплатки, отправлять заплатки. Если вы хотите оказать помощь в исправлении ошибок, перейдите в Трекер. Вы можете помочь в решении Открытых проблем, изложенных в Трекере. Вы можете Создать и отправить заплатку для Подтвержденных проблем. Или вы можете оказать помощь в тестировании Ожидаемых решений. Чтобы сообщить о том, что вы сделали, войдите с помощью аккаунта GitHub и добавьте комментарий. Вы удивитесь, какое влияние вы можете оказать и насколько замечательно ощущать свой вклад в проект Joomla!. Если у вас есть вопросы, или вы хотите присоединиться к JBS, пожалуйста, свяжитесь с Координаторами отряда Bug Squad.

Тестирование пре-релизов

Перед выпуском стабильного релиза Joomla, последний нуждается в тестировании. Это простой процесс:

  1. Установить текущий стабильный релиз Joomla в поддиректорию или на локальный компьютер (вы можете использовать копию рабочего сайта, но никогда не тестируйте на работающем сайте в продакшене).
  2. Перейдите в настройки Компонента Обновление Joomla! и установите параметр 'Сервер обновления' в 'Тестовые дистрибутивы Joomla'. Components Joomla Update
  3. Когда пре-релиз Joomla будет готов к тестированию, войдите в свой тестовый сайт и установите обновления. Затем протестируйте работу тестового сайта так, как ожидается, он должен работать. Сообщайте о любых ошибках/багах в Joomla! Issue Tracker.

Сообщения о проблемах

ReportingIssues.png

Обычно процесс начинается в одном из двух направлений: баг добавляется в соответствующий трекер, или пользователь сообщает об ошибке на Joomla! Bug Forum для поддержки определенного релиза.


Вопросы, сообщаемые на форуме

Члены отряда Joomla Bug Squad (JBS) отслеживают форумы, чтобы найти ошибки, которые необходимо отправить в Трекер. Если ошибка воспроизводима и является явным багом, есть инструкция, как этот баг воспроизвести шаг за шагом, то она помещается в Трекер со статусом "Подтверждена". Если ошибка не так ясна, она помещается в Трекер со статусом "Открыта, чтобы другие члены отряда знали, что нужно дополнительное исследование.

Вопросы, непосредственно отправленные в трекер

Когда ошибка помещается в Трекер, ей устанавливается статус, в зависимости от ситуации:

  1. Новая
  2. Подтверждена
  3. В ожидании

Если ошибка нуждается в дополнительном исследовании, то ей устанавливается статус "Новая". Если ошибка (1) баг и (2) воспроизводима и (3) имеет хорошие инструкции для тестирования, ей устанавливают статус "Подтверждена". Если ошибка соответствует трем подтвержденным критериям, а также имеет хорошую заплатку (патч), то ей присваивается статус "В ожидании".

Issue Priorities

Why most issues are priority 3, or Medium. The artifacts are prioritized according to the following characteristics:

Critical (1): The trunk is not working at all. Significant parts of the source are broken preventing key operations. Examples would be login, installation, extension installers, javascript errors that prevent you from moving a save or similar action, etc. Also includes the generation of Fatal PHP errors and major security issues in a prerelease (Security issues for a stable release should NOT be reported in the tracker but instead reported to the security team security@joomla.org).

Urgent (2): Parts of the source are obstructing operation in a serious way or causing a major loss in advertised function. Examples would includes PHP notices and warnings and reported javascript errors. Major issues will also typically prevent the release cycle from moving from Beta to Release Candidate (RC), or Release Candidate to General Availability (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.

Resolving Issues

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.


The flowchart below provides a visual guide to how the process for resolving bugs works.

ResolvingIssues.png