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

Аватар пользователя neochief neochief 24 июля 2009 в 14:44

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

via drupaldance.com

0 Thanks

Комментарии

Аватар пользователя gorr gorr 24 июля 2009 в 15:07

(Прошу прощения за оффтопик)
Вопрос: картинку с блок-схемой в стандартном графическом редакторе (фотошоп, файрфокс,..) делали или что-то более специфическое именно для этой цели?

Аватар пользователя vadbars@drupal.org vadbars@drupal.org 24 июля 2009 в 15:08
"neochief" wrote:

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

Спасибо за четкую и грамотную заметку!

У меня сейчас как раз ситуация с передачей модуля. Ветка "Drupal.org infrastructure" объявлена deprecated (не рекомендуется). Из оставшегося я нашел более-менее подходящую ветку Modules development. Но админы там молчат как рыба об лед. То ли у них объявлено лето, то ли я что-то делаю не так.

Аватар пользователя neochief neochief 24 июля 2009 в 15:29
"gorr" wrote:

Вопрос: картинку с блок-схемой в стандартном графическом редакторе

Вся графика делалась в Visio.

"<a href="mailto:vadbars@drupal.org">vadbars@drupal.org</a>" wrote:

Ветка "Drupal.org infrastructure" объявлена deprecated (не рекомендуется)

Ветка форума — да. Но ветка issues жива-здорова — http://drupal.org/project/issues/infrastructure (обратите внимание на активность).

Аватар пользователя alergi@drupal.org alergi@drupal.org 24 июля 2009 в 16:52

Вопрос патчи надо делать для последней версии семёрки из CVS?
А если баг только для шестёрки?

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

Кстати, а что это за failed testing и вообще что это за сайт http://testing.drupal.org?

Аватар пользователя alergi@drupal.org alergi@drupal.org 24 июля 2009 в 16:56

ой-ой-ой, что я там не то сделал, нажал "Request re-test" и подвердил, я то думал тест автоматический, а он похоже какой-то запрос на повторное тестирование оставил
и ваш первый патч стал желтым...

Сорри, надеюсь я там ничего не сломал)

Аватар пользователя neochief neochief 24 июля 2009 в 17:13

Порядок коммита в ядро такой — 7.x, 6.x, 5.x.

Патчи для ядра в реальной жизни делаются в последовательности:

  1. Вы находите ошибку в шестерке, с которой работаете каждый день.
  2. Делаете для нее исправление и патч.
  3. Создаете issue, цепляете патч туда, с пометкой 6.x. С этого момента страждущие могут получить хоть какое-то решение проблемы, а вы — фидбек от разработчиков, касательно вашего решения.
  4. Если вам важна проблема, вы делаете патч для 7.x, его утверждают и комитят. На это иногда уходит довольно много времени, вот например как здесь (обратите внимание на даты).
  5. Потом очередь приходит к вашему патчу для шестерки. Он обновляется, если нужно, и потом коммитится в шестую ветку.
  6. Если что-то критическое, то потом исправляют и в 5.x.

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

Патч делать обязательно, если вам действительно важна судьба проблемы. Говорю это как майнтейнер. Чтобы проверить патч мне надо кликнуть мышкой два раза. Еще один клик — и исправление уже в CVS. С другой стороны, смотреть что и где вы там поменяли занимает время. К тому же, буквально со второго раза, вам самим быстрее делать патчи, чем объяснять на словах. Тем более, я уже делал мануал процесса патчинга, хотя судя по всему, его надо будет переснять по-человечески.

Статья по тестам — comming soon.

Аватар пользователя neochief neochief 24 июля 2009 в 19:54
"volocuga" wrote:

А что,с gmap всё так плохо?

Я имел с ним опыт полгода назад. Опыт закончился самостоятельной реализацией. На сколько я знаю, это довольно популярное решение в отношении GMap. Может быть сейчас что-нибудь уже поменялось.

Аватар пользователя Guide Guide 26 июля 2009 в 21:39

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

"neochief" wrote:

Я имел с ним опыт полгода назад. Опыт закончился самостоятельной реализацией. На сколько я знаю, это довольно популярное решение в отношении GMap. Может быть сейчас что-нибудь уже поменялось.

Вы писали модуль с нуля или по образу и подобию GMap? В моём случае, после долгих мучений при исправлении модуля была предпринята попытка написать с нуля. Получилось без глючно, но менее функционально. Например, так и не получилось добавить возможность загрузки в ShadowBox.

Аватар пользователя inc inc 27 июля 2009 в 10:49

Спасибо за полезную статью!
Добавьте, пожалуйста, ссылки на drupal.org, где размещается самая свежая информация о правилах участия в разработке.

Аватар пользователя seaji seaji 7 августа 2009 в 16:31

Мне понравилась фраза: "Убедитесь, что проблема действительно имеет место".

Это не баг, это фича :)))