Рабочий процесс сортировки¶

Unfortunately, not all bug reports and feature requests in the ticket tracker provide all the required details. A number of tickets have patches, but those patches don’t meet all the requirements of a good patch.

Один из способов помочь — это отсортировать тикеты, созданные другими пользователями.

Большая часть рабочего процесса основана на концепции сортировки этапов тикета. Каждый этап описывает, где в своем жизненном цикле данный тикет находится в любой момент времени. Наряду с несколькими флагами этот атрибут легко сообщает нам, что и кого ожидает каждый тикет.

Поскольку картинка стоит тысячи слов, давайте начнем с этого:

На этой диаграмме у нас есть две роли:

• Committers: people with commit access who are responsible for making the final decision to merge a patch.

• Сортировщики тикетов: любой член сообщества Django, который решил участвовать в процессе разработки Django. Наша установка Trac намеренно открыта для публики, и любой может сортировать тикеты. Django является проектом сообщества, и мы поощряем сортировку.

В качестве примера, здесь мы видим жизненный цикл среднего тикета:

• Алиса создает тикет и отправляет неполный пул-реквест (нет тестов, неправильная реализация).

• Боб просматривает пул-реквест, отмечает тикет как «Accepted», «needs tests» и «patch needs improvement», и оставляет комментарий, сообщая Алисе, как можно улучшить патч.

• Алиса обновляет пул-реквест, добавляя тесты (но не изменяя реализацию). Она удаляет два флага.

• Чарли просматривает пул-реквест и сбрасывает флаг «патч требует улучшения» с другим комментарием об улучшении реализации.

• Алиса обновляет пул-реквест, исправляя реализацию. Она удаляет флаг «патч нуждается в улучшении».

• Дейзи просматривает пул реквест и отмечает тикет как «Готово к слиянию».

• Jacob, a committer, reviews the pull request and merges it.

Некоторые тикеты требуют гораздо меньше обратной связи, некоторые - гораздо больше.

Этапы сортировки¶

Ниже мы более подробно описываем различные этапы, которые может пройти тикет в течение своего жизненного цикла.

Другие атрибуты¶

В тикете можно установить ряд флагов, отображаемых в Trac:

Закрытие тикетов¶

Когда завершается работа над тикетом, его пора закрывать. Однако закрытие тикета — это большая ответственность. Вы должны быть уверены, что проблема действительно решена, и вам нужно помнить, что сообщивший о тикете может быть недоволен закрытием своего тикета (если только он не исправлен!). Если вы не уверены в том, что нужно закрыть тикет, оставьте комментарий со своими мыслями.

Если вы закрываете тикет, вам всегда следует убедиться в следующем:

• Убедитесь, что проблема решена.

• Оставьте комментарий, объясняющий решение закрыть тикет.

• Если есть возможность улучшить тикет и возобновить его рассмотрение, сообщите им об этом.

• Если тикет является дубликатом, сошлитесь на исходный тикет. Также сделайте перекрестную ссылку на закрытый тикет, оставив комментарий в исходном — это позволяет получить доступ к дополнительной информации об обнаруженной ошибке или запрошенной функции.

• Будьте вежливы. Никому не нравится, когда их тикет закрывают. Это может расстраивать или даже обескураживать. Лучший способ не отпугнуть людей от участия в Django — быть вежливым и дружелюбным и предлагать советы о том, как они могут улучшить этот тикет и другие тикеты в будущем.

Тикет можно разрешить решить несколькими способами:

• fixed (исправлено)

  Используется после установки патча в Django и устранения проблемы.

• invalid (неправильный)

  Используется, если тикет признан некорректным. Это означает, что проблема в тикете на самом деле является результатом ошибки пользователя или оказывается, что проблема не в Django, или тикет вообще не является отчетом об ошибке или запросом на функцию (например, некоторые новые пользователи отправляют запросы в службу поддержки в виде тикетов).

• wontfix (не будет исправлено)

  Used when a someone decides that the request isn’t appropriate for consideration in Django. Sometimes a ticket is closed as «wontfix» with a request for the reporter to start a discussion on the django-developers mailing list if they feel differently from the rationale provided by the person who closed the ticket. Other times, a mailing list discussion precedes the decision to close a ticket. Always use the mailing list to get a consensus before reopening tickets closed as «wontfix».

• duplicate (дубликат)

  Используется, когда другой тикет касается того же вопроса. Закрывая дублирующиеся тикеты, мы сохраняем все обсуждения в одном месте, что помогает всем.

• worksforme (у меня работает)

  Используется, когда тикет не содержит достаточно подробностей для воспроизведения ошибки.

• needsinfo (нужна дополнительная информация)

  Используется, когда тикет не содержит достаточно информации для воспроизведения сообщенной проблемы, но потенциально все еще корректен. Тикет следует открыть повторно, когда будет предоставлена ​​дополнительная информация.

If you believe that the ticket was closed in error – because you’re still having the issue, or it’s popped up somewhere else, or the triagers have made a mistake – please reopen the ticket and provide further information. Again, please do not reopen tickets that have been marked as «wontfix» and bring the issue to django-developers instead.

Как я могу помочь с сортировкой?¶

Процесс сортировки в первую очередь осуществляется членами сообщества. На самом деле, ЛЮБОЙ может помочь.

Чтобы принять участие, начните с создания учетной записи на Trac. Если у вас есть учетная запись, но вы забыли пароль, вы можете сбросить его, используя страницу сброса пароля.

Тогда вы можете помочь следующим образом:

• Закрытие «Unreviewed» заявок как «invalid», «worksforme» или «duplicate» или «wontfix».

• Closing «Unreviewed» tickets as «needsinfo» when the description is too sparse to be actionable, or when they’re feature requests requiring a discussion on django-developers.

• Исправление флагов «Needs tests», «Needs documentation» или «Has patch» для тикетов, где они установлены неправильно.

• Установка флага «Easy pickings» для билетов, которые являются небольшими и относительно простыми.

• Установите тип билетов, которые еще не отнесены к какой-либо категории.

• Проверка того, что старые тикеты все еще актуальны. Если тикет не видел никакой активности в течение длительного времени, возможно, проблема была устранена, но тикет еще не закрыт.

• Identifying trends and themes in the tickets. If there are a lot of bug reports about a particular part of Django, it may indicate we should consider refactoring that part of the code. If a trend is emerging, you should raise it for discussion (referencing the relevant tickets) on django-developers.

• Verify if patches submitted by other users are correct. If they are correct and also contain appropriate documentation and tests then move them to the «Ready for Checkin» stage. If they are not correct then leave a comment to explain why and set the corresponding flags («Patch needs improvement», «Needs tests» etc.).

Однако мы просим всех членов сообщества о следующем:

• Please don’t promote your own tickets to «Ready for checkin». You may mark other people’s tickets which you’ve reviewed as «Ready for checkin», but you should get at minimum one other community member to review a patch that you submit.

• Please don’t reverse a decision without posting a message to django-developers to find consensus.

• If you’re unsure if you should be making a change, don’t make the change but instead leave a comment with your concerns on the ticket, or post a message to django-developers. It’s okay to be unsure, but your input is still valuable.

Разделение регрессии¶

Регрессия — это ошибка, которая присутствует в какой-то новой версии Django, но отсутствует в старой. Чрезвычайно полезная информация — это коммит, который ввел регрессию. Знание коммита, который вызвал изменение в поведении, помогает определить, было ли изменение преднамеренным или это был непреднамеренный побочный эффект. Вот как это можно определить.

Begin by writing a regression test for Django’s test suite for the issue. For example, we’ll pretend we’re debugging a regression in migrations. After you’ve written the test and confirmed that it fails on the latest master, put it in a separate file that you can run standalone. For our example, we’ll pretend we created tests/migrations/test_regression.py, which can be run with:

$ ./runtests.py migrations.test_regression

Next, we mark the current point in history as being «bad» since the test fails:

$ git bisect bad
You need to start by "git bisect start"
Do you want me to do it for you [Y/n]? y

Now, we need to find a point in git history before the regression was introduced (i.e. a point where the test passes). Use something like git checkout HEAD~100 to checkout an earlier revision (100 commits earlier, in this case). Check if the test fails. If so, mark that point as «bad» (git bisect bad), then checkout an earlier revision and recheck. Once you find a revision where your test passes, mark it as «good»:

$ git bisect good
Bisecting: X revisions left to test after this (roughly Y steps)
...

Now we’re ready for the fun part: using git bisect run to automate the rest of the process:

$ git bisect run tests/runtests.py migrations.test_regression

Вы должны увидеть, как git bisect использует бинарный поиск для автоматической проверки ревизий между хорошими и плохими коммитами, пока не найдет первый «плохой» коммит, на котором тест не пройден.

Теперь сообщите о своих результатах в тикете Trac и, пожалуйста, включите регрессионный тест в качестве вложения. Когда кто-то напишет исправление ошибки, он уже будет иметь ваш тест в качестве отправной точки.