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

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

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

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

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

На этой диаграмме у нас четыре роли. Мейнтейнеры (также известные как Fellows) обычно принимают участие во всех из них, но любой член сообщества Django может участвовать в любой роли, кроме слияния. Роль по слиянию предоставляется путем голосования Руководящего совета.

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

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

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

• Слияния: люди с доступом к фиксации, которые принимают окончательное решение о слиянии изменений.

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

Например, вот типичный жизненный цикл билета:

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

• Боб просматривает запрос на включение, помечает заявку как «Принятую», устанавливает флаги «требуется тестирование» и «исправление требует улучшения» и оставляет комментарий, объясняющий, как Алиса может улучшить исправление. При этом заявка автоматически помещается в очередь «ожидания автора» на этапе «принято».

• Алиса обновляет запрос на включение, добавляя тесты (но еще не исправляя реализацию) и удаляет два флага. Заявка перемещается в очередь «требуется PR-проверка».

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

• Алиса снова обновляет запрос на включение, на этот раз исправляя реализацию, и удаляет флаг «патч требует улучшения». Заявка снова перемещается в очередь «требуется PR-проверка».

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

• Джейкоб, merger, проверяет и объединяет запрос на включение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Закрытие «Непросмотренных» заявок как «требуется информация», если описание слишком скудное, чтобы можно было предпринять какие-либо действия.

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