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

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

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

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

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

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

• Мерджеры: люди с правом на внесение изменений, которые отвечают за принятие окончательного решения об вливании изменений в кодовую базу.

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

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

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

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

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

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

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

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

• Джейкоб, мерджер, просматривает запрос и мерджит его.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Используется, когда кто-то решает, что запрос не подходит для рассмотрения в Django. Иногда тикет закрывается как «wontfix» с запросом к репортеру начать обсуждение на Форуме Django, если они считают, что запрос, сделанный репортером, не требует изменений в коде. В других случаях обсуждение предшествует решению закрыть тикет. Всегда используйте форум, чтобы достичь консенсуса, прежде чем повторно открывать тикеты, закрытые как «wontfix».

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

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

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

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

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

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

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

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

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

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

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

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

• Закрытие «Unreviewed» тикетов как «needsinfo», если описание слишком разреженное, чтобы быть применимым, или если это запросы функций, требующие обсуждения на Форуме Django.

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

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

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

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

• Определение тенденций и тем в тикетах. Если в определенной части Django много сообщений об ошибках, это может означать, что нам следует рассмотреть возможность рефакторинга этой части кода. Если намечается тенденция, вам следует поднять ее на обсуждение (со ссылкой на соответствующие тикеты) на форуме Django`_.

• Проверьте, верны ли решения, представленные другими. Если они верны и также содержат соответствующую документацию и тесты, то переместите их на стадию «Ready for Checkin». Если они неверны, то оставьте комментарий, чтобы объяснить причину и установить соответствующие флаги («Patch needs improvement», «Needs tests» и т. д.).

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

• Пожалуйста, не продвигайте свои собственные тикеты как «Ready for checkin». Вы можете отмечать чужие тикеты, которые вы просмотрели, как «Ready for checkin», но вы должны попросить как минимум одного другого члена сообщества просмотреть патч, который вы отправляете.

• Пожалуйста, не меняйте решение, не опубликовав сообщение на форуме `Django““ для поиска консенсуса.

• Если вы не уверены, следует ли вносить изменения, не вносите их, а вместо этого оставьте комментарий с вашими опасениями в тикете или отправьте сообщение на Форум Django. Неуверенность — это нормально, но ваш вклад все равно ценен.

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

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