Учет билетов¶

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

К сожалению, не все сообщения об ошибках и запросы функций в тикет-трекере обеспечивают все required details. В ряде тикетов есть исправления, но эти исправления не отвечают всем требованиям good patch.

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

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

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

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

• Mergers: people with commit access who are responsible for making the final decision to merge a patch.
• Триггеры тикетов: все члены сообщества Django, которые хотят участвовать в процессе разработки Django. Наша установка Trac намеренно оставлена открытой для публики, и любой может заниматься сортировкой тикетов. Django - это проект сообщества, и мы поощряем triage by the community.

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

• Алиса создает тикет и отправляет неполный запрос (нет тестов, неправильная реализация).
• Боб просматривает запрос на притяжение, отмечает билет как «принят», «нужны тесты» и «патч нуждается в улучшении», а также оставляет комментарий, в котором сообщает Алисе, как можно улучшить патч.
• Алиса обновляет запрос на притяжение, добавляя тесты (но не меняя реализацию). Она удаляет два флага.
• Чарли просматривает заявку на исправление и сбрасывает флаг «патч нуждается в улучшении», добавляя еще один комментарий об улучшении реализации.
• Алиса обновляет запрос на исправление, исправляя реализацию. Она снимает флаг «патч нуждается в доработке».
• Дэйзи просматривает запрос и помечает билет как «Готов к проверке».
• Jacob, a merger, reviews the pull request and merges it.

Некоторые билеты требуют гораздо меньше отзывов, чем эти, но, опять же, некоторые билеты требуют гораздо больше.

Этапы подготовки¶

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

Другие атрибуты сортировки¶

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

Билеты на закрытие¶

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

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

• Убедитесь, что вопрос решен.
• Оставьте комментарий, объясняющий решение о закрытии билета.
• Если есть способ улучшить билет, чтобы его снова открыть, сообщите им об этом.
• Если билет является дубликатом, ссылайтесь на оригинальный билет. Также сделайте перекрестную ссылку на закрытый тикет, оставив комментарий в оригинальном тикете - это позволит получить доступ к дополнительной информации о заявленной ошибке или запрошенной функции.
• Будьте вежливы. Никому не нравится, когда его билет закрывают. Это может расстроить или даже обескуражить. Лучший способ не оттолкнуть людей от участия в Django - быть вежливым и дружелюбным и предлагать предложения о том, как они могут улучшить этот билет и другие билеты в будущем.

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

• исправлено

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

• недействительный

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

• wontfix

  Used when 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».

• дубликат

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

• worksforme

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

• needsinfo

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

Если вы считаете, что билет был закрыт по ошибке - потому что у вас все еще есть проблема, или она всплыла в другом месте, или триггеры допустили ошибку - пожалуйста, откройте билет заново и предоставьте дополнительную информацию. Опять же, пожалуйста, не открывайте повторно тикеты, которые были помечены как «wontfix», и вместо этого доведите проблему до django-developers.

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

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

Чтобы принять участие, начните с creating an account on Trac. Если у вас есть аккаунт, но вы забыли пароль, вы можете восстановить его с помощью password reset page.

Тогда вы можете оказать помощь:

• Закрытие билетов «Unreviewed» как «invalid», «worksforme», или «duplicate», или «wontfix».
• Закрытие тикетов «Unreviewed» как «needsinfo», когда описание слишком скудное, чтобы можно было принять меры, или когда это запросы функций, требующие обсуждения на django-developers.
• Исправление флагов «Нужны тесты», «Нужна документация» или «Есть патч» для билетов, в которых они установлены неверно.
• Установка флага «Easy pickings» для билетов, которые являются небольшими и относительно простыми.
• Установите тип билетов, которые еще не классифицированы.
• Проверка того, что старые билеты все еще действительны. Если в билете давно не было активности, возможно, проблема была устранена, но билет еще не закрыт.
• Выявление тенденций и тем в тикетах. Если есть много сообщений об ошибках в конкретной части Django, это может указывать на то, что мы должны рассмотреть возможность рефакторинга этой части кода. Если наметилась тенденция, вам следует поднять ее для обсуждения (со ссылкой на соответствующие тикеты) на django-developers.
• Проверьте правильность исправлений, представленных другими пользователями. Если они корректны, а также содержат соответствующую документацию и тесты, переведите их в стадию «Готов к проверке». Если они некорректны, оставьте комментарий с объяснением причин и установите соответствующие флаги («Патч требует доработки», «Требует проверки» и т.д.).

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

• Please don’t promote your own tickets to «Ready for checkin». You may mark other people’s tickets that you’ve reviewed as «Ready for checkin», but you should get at minimum one other community member to review a patch that you submit.
• Пожалуйста, не отменяйте решение, не опубликовав сообщение django-developers для поиска консенсуса.
• Если вы не уверены, стоит ли вносить изменение, не вносите его, а оставьте комментарий со своими опасениями в тикете или напишите сообщение на django-developers. Это нормально - быть неуверенным, но ваш вклад все равно ценен.

Биссектриса регрессии¶

Регрессия - это ошибка, которая присутствует в более новой версии 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 main branch, 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

Далее, мы помечаем текущий момент истории как «плохой», поскольку тест не прошел:

$ 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 check out 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 check out 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)
...

Теперь мы готовы к самому интересному: использованию git bisect run для автоматизации остальной части процесса:

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

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

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