ShvetsGroup

 

5 правил эффективной работы в Issue queues

  • neochief's picture
0 comments

5 правил эффективной работы в Issue queues

Статья эвакуирована с DrupalDance.com

Этот пост посвящен проблемам общения разработчиков в очередях проблем на drupal.org (Issue queues). Если в начале своего пути, друпаллер не так часто там появляется, то, по мере профессионального роста, вам все чаще придется сообщать об ошибках, постить свои патчи и помогать другим.

Далее мы рассмотрим некоторые сценарии и пути их эффективного разрешения.

#1 Я нашел ошибку в ядре!

Друпал не идеален. Каждый новый релиз приносит с собой 2-3 серьезных исправления и до дюжины мелких.

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

Цикл разработки Drupal

Все дороги ведут в HEAD

HEAD-веткой ядра называется ветка, которая в данный момент находится в активной разработке. На сегодняшний день это Drupal 7. Для остальных версий выходят сервис-релизы, в которых лишь латаются дыры и ошибки. Исходя из этого, ваш «патч, с улучшением системы кеширования для шестерки» в лучшем случае переназначат в HEAD.

Теперь вернемся к исправлениям. Почти все баги, которые вы можете найти в системе — наследственны. Это означает, что если баг есть в Drupal 6, он наверняка присуствует и в Drupal 7. Вот почему, если вы запостите заплатку для более ранней версии, вас попросят сперва портировать ее для HEAD, а затем уже каскадно спускать это исправление вниз по версиям.

В остальном же, исправление ошибок в ядре сходно с процессом исправления ошибок в модулях.

#2 Я нашел ошибку в стороннем модуле!

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

Действие Эффективность Комментарий
Отказаться от модуля 1% Плюсы: В некоторых случаях это хорошее решение (см. модуль Gmap).
Минусы: Можно оставить за бортом хороший функционал.
Смириться с ошибкой 5% Плюсы: Если ошибка некритичная, то пусть себе живет, когда-нибудь да исправят.
Минусы: Могут никогда и не исправить.
Запостить баг-репорт на drupal.ru 5% Плюсы: Если с английским вообще туго, то единственная надежда.
Минусы: Решение чужих проблем никого не интересует.
Написать автору модуля об ошибке 5% Плюсы: Очень редко, но можно получить вразумительную и толковую помочь от автора.
Минусы: Автору будет лень даже читать такое письмо. Для ошибок есть Issues queue.
Пропатчить модуль и жить с этим 10% Плюсы: Ошибка исправлена.
Минусы: Ошибка будет присутствовать в официальной версии и будоражить вас всякий раз, когда вы захотите проапдейтится.
Запостить баг-репорт на drupal.org 75% Плюсы: Правильно составленный багрепорт на drupal.org может быть гарантией решения.
Минусы: Не панацея, если автор модуля занят/ленив.

Максимально эффективный способ решения проблем с модулями:

Плюсы:

  • 100% решение проблемы.
  • Отсутствие проблемы в следующих версиях.
  • Помощь сообществу.

Минусы:

  • Нужно потратить время на все шаги.

#3 Я отправил bug-репорт, но мне никто не отвечает!

Такое бывает в двух случаях — или ваш bug-репорт составлен неправильно и на него никто не удосужился ответить, или вам просто некому ответить (бывает в случае модулей).

Правильный bug-репорт

Начнем с правильного bug-репорта. Он должен состоять из 4 частей — Описания, Шагов повторения, Ожидаемых результатов, Фактических результатов. Вот пример правильного bug-репорт:

Описание:
В многоязычных сайтах при отображении одноязычных нод, блок переключения языков показывает языки, перевод которых недоступен.

Шаги повторения:
1. Настроить многоязычный сайт с двумя языками (en+ru).
2. Вынести блок переключения языков на экран.
3. Создать ноду на английском (без перевода).
4. Зайти в эту надо и посмотреть что отображается в блоке переключения языков.

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

Фактический результат:
В блоке присутствуют обе ссылки.

По мотивам #518364.

Прекрасным дополнением к такому bug-репорту мог бы быть патч, исправляющий проблему.

Если никто не отвечает, а исправить нужно срочно

Вы можете не получать ответы и по другим причинам:

  • Баг может быть некритичным, а у автора много других дел.
  • Автор может отдыхать на Мальдивах.
  • Автор мог возненавидеть Друпал и перейти на руби.

В любом случае, вы можете стать ко-майнтейнером, получить доступ в CVS-ветку этого модуля и исправить все самостоятельно. Для этого нужно создать тему "Co-maintainership" в issue queue модуля, и если в течение двух недель вам никто не ответит, вы сможете перенести эту ветку в раздел Drupal.org webmasters и администрация drupal.org сама одобрит ваше "усыновление" модуля.

#4 Помогайте решать проблемы

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

#5 Будьте вежливыми

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

Got anything to add?