Учет заявок¶

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

К сожалению, не все сообщения об ошибках и запросы функций в тикет-трекере обеспечивают все 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

  Используется, когда кто-то решает, что запрос не подходит для рассмотрения в Django. Иногда тикет закрывается как «wontfix» с просьбой к автору начать обсуждение в списке рассылки django-developers, если его мнение отличается от обоснования, предоставленного человеком, закрывшим тикет. В других случаях обсуждение в списке рассылки предшествует решению о закрытии тикета. Всегда используйте список рассылки для достижения консенсуса перед повторным открытием тикетов, закрытых как «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.
• Проверьте правильность исправлений, представленных другими пользователями. Если они корректны, а также содержат соответствующую документацию и тесты, переведите их в стадию «Готов к проверке». Если они некорректны, оставьте комментарий с объяснением причин и установите соответствующие флаги («Патч требует доработки», «Требует проверки» и т.д.).

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

• Пожалуйста, не не продвигайте свои собственные билеты до «Готов к проверке». Вы можете пометить чужие билеты, которые вы просмотрели, как «Готов к проверке», но вы должны попросить как минимум еще одного члена сообщества просмотреть патч, который вы отправляете.
• Пожалуйста, не отменяйте решение, не опубликовав сообщение django-developers для поиска консенсуса.
• Если вы не уверены, стоит ли вносить изменение, не вносите его, а оставьте комментарий со своими опасениями в тикете или напишите сообщение на django-developers. Это нормально - быть неуверенным, но ваш вклад все равно ценен.

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

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

Начните с написания регрессионного теста для набора тестов Django для данной проблемы. Например, мы представим, что отлаживаем регрессию в миграциях. После того, как вы написали тест и убедились, что он не работает на последней основной ветке, поместите его в отдельный файл, который можно запустить отдельно. Для нашего примера мы представим, что создали tests/migrations/test_regression.py, который можно запустить с помощью:

$ ./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

Теперь нам нужно найти точку в истории git до появления регрессии (т.е. точку, в которой тест проходит). Используйте что-то вроде git checkout HEAD~100 для проверки более ранней ревизии (в данном случае на 100 коммитов раньше). Проверьте, не прошла ли проверка. Если да, отметьте эту точку как «плохую» (git bisect bad), затем проверьте более раннюю ревизию и перепроверьте. Как только вы найдете ревизию, в которой тест пройдет, пометьте ее как «хорошую»:

$ 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 и, пожалуйста, включите регрессионный тест в качестве приложения. Когда кто-нибудь напишет исправление ошибки, у него уже будет ваш тест в качестве отправной точки.