Накатал перевод продолжения вчерашней заметки Даниэла Кудвиена.
Оригинал тут: http://www.unleashedmind.com/en/blog/sun/crisis-conclusions
Далее перевод.
Кризис. Результаты и выводы
Скажу честно. Я ожидал и опасался массы эмоций, несогласия и даже ругани из-за поста «Кризис в Друпале». Но к моему удивлению, практически все, кто ответил на пост, в основном, согласились с большинством озвученных проблем, а еще больше — с взглядом на проблемную область в целом. И вообще, единственное снисходительное замечание было о том, что я «не конструктивен».
Поговори со мной, дорогуша
Было очень приятно наконец-то написать этот пост, снять груз с души. Исходя из личной переписки и открытых комментариев, заранее я знал только, что по крайней мере у моих друзей и товарищей по разработке ядра — catch и chx — практически такие же ощущения и преставления.
Впрочем, самое интересное — это что до меня никто в общем-то не ставил этих вопросов и не жаловался. Похоже, многие из нас глотали пилюлю за пилюлей, баг за багом, объявление за объявлением, в простой надежде, что может вот это — последнее.
Среда всей разработки (ядра?) Друпала и «культура» постоянного критиканства, флейма, обвинений и высеров на существующие проблемы в API и коде, конечно, сыграла здесь свою роль: все мы занимаемся этим постоянно; и когда еще одна пилюля попадает во входящие, велика вероятность, что ее тихо отправят в корзину. Ведь мы и так уже открыли кучу флеймов в обсуждении ядра о действительно раздражающих проблемах в коде. Так что нет ни времени, ни сил на еще один флейм, который к тому же 1) не связан с архитектурой ядра и 2) на первый взгляд, не так уж важен.
А проблемы копятся. В ретроспективе все мы, конечно, знали бы что делать и приняли бы иные решения. А вообще, у нас ведь нет никакой подходящей публичной площадки для обсуждения очень важного для проекта вопроса (и связанных с ним): оказывает ли Acquia неуместное влияние на ядро Друпала?
(даже этот маленький пост, учитывая размеры и количество групп на g.d.o, несмотря на важность, легко затеряется).
Нужно обсудить, есть ли у Aquia конфликт интересов, и в чем он.
Могу только аплодировать effulgentsia (он кстати работает в Acquia): мы только что очень долго разговаривали по скайпу, прокручивали каждый баг один за другим, проясняли, о чем же тут речь, чтобы потом рассказать об этом остальным. Алекс постоянно удивляет меня своей системностью, понятностью, креативностью и бесподобным качеством работы, будь то код или общение. Не работай он в Acquia, и не будь того же возможного конфликта интересов, я всеми руками голосовал бы за его назначение координатором по разработке ядра.
Ключевое выступление rfay на DrupalCon об эмоциональном выгорании связано с нашей проблемой: оно показало, что очень многие разработчики Друпала слишком долго молчали о своих личных переживаниях. Выходит, в нашем сообществе есть несколько критичных проблем общения на фундаментальные темы.
Нужно обсудить, как нам разрешить эти проблемы в общении и в то же время не принести в жертву разработчиков, не загнать их в угол.
Шоколад и мороженое, или Кнут и пряник.
Деталь, которую многие в первом посте не заметили: за два года появилось 8000+ новых сообщений о багах, и каждое из них должно быть: 1) создано, 2) проанализировано, 3) исправлено, 4) рассмотрено экспертом, 5) протестировано, 6) одобрено и, наконец, 7) добавлено в код. В среднем это означает, что через данный процесс должны проходить 320 багов в месяц или 10 багов в день.
И как уже отметил tsvenson, числа будут только расти, стремительные темпы мы наблюдаем уже сегодня. Да и само по себе количество сообщений о багах уже беспокоит. Ты ожидаешь, что объемы будут как-то снижаться со временем — хотя это наверное и спорно, так как части ядра намеренно изменяются — но тем не менее, количество багов растет. Некоторые из разработчиков ядра утверждают, что мы сможем справиться с этим ростом через привлечение новых разработчиков ядра Друпала.
Но больше всего смущает объем работы, необходимой для пунктов 2 и 4–7 в списке выше, которую должны выполнить именно опытные разработчики ядра. Смущает жизнеспособность этой модели в будущем.
Вот что меня на самом деле заботит:
sun: надо было мне четко расписать, какие вещи я согласен поддерживать, патчить и проверять чужие патчи в ядре. И какие — нет.
catch: это должен сделать каждый, кто хоть раз написал такой пост.
Похоже, не сделал никто.
По крайней мере, не думаю что видел хоть какое-то подобие анализа или предложения со стороны разработчика ядра, в котором указывалось бы, какие части ядра Друпала он/она на самом деле считает ядром. И что он/она хочет в ядре активно поддерживать. Вместо того чтобы вынужденно поддерживать что-то под влиянием текущего содержания, ностальгии и процесса разработки.
Нужно обсуждать, предлагать, договариваться и определять, что именно мы можем и хотим поддерживать в ядре Друпала.
Еще один очень длинный и напряженный разговор с chx и webchick прояснил, что все эти «основные функции» ядра Друпала де-факто попросту никем не поддерживаются. Чтобы улучшить, перенести или удалить их, нужны заинтересованные разработчики. Но нам не только пора прекратить искать людей,
Нужно обсудить, какие функции ядра на самом деле основные.
Большинство модулей с этими функциями — легкая мишень для новичков. Они не содержат сложного кода и логики, так что их баги — на совершенно ином уровне сложности, нежели, скажем, рефакторинг модуля System.
Но, очевидно, найти разработчиков для идиотских модулей типа Aggregator будет сложно. Чтобы этот функционал шел в ногу с 2012+ годом и архитектурой ядра, его проще полностью заменить модулем Feeds (или что там сейчас среди модулей лучше — извините, не следил за развитием).
Поиск людей, желающих заняться поддержкой основных функций и направлений займет немало времени, если сообщество Друпала не возьмет себя в руки. Сейчас на это можно только надеяться.
Многие люди уже ратовали в первом посте за «традиционный» open-source-процесс; то есть, убрать никем не поддерживаемый балласт из ядра в дополнительные модули, добавить в ядро новые, современные функции. Некоторые разработчики ядра, наоборот, высказывались против такого подхода, так как они изначально попали в разработку ядра через эти старые модули. К тому же некоторые из них служили в качестве неожиданных «регрессионных тестов» в Друпал 7. Но так или иначе, нет ни желающих взять на себя эти модули, ни кого-то с пониманием, что с ними делать.
Нужно обсудить крайние сроки на поиск разработчиков основных функций.
И после этого:
Нужно обсудить, что делать с теми частями, которые никто не хочет поддерживать.
Нам нужно определенное, небольшое число потребителей API ядра. Из них все еще можно составить отличную основу для продукта. Но нам не нужно поддерживать функции, которыми никто не пользуется, которые никому не нужны. Эти бессмысленные функции только отвлекают всех нас от нормальной разработки ядра, и в особенности — затрудняют рефакторинг API.
В этом плане, похоже, у нас странное понимание перемещения функций ядра в «дополнительные модули». Раньше мы перемещали из ядра только код, которым вообще никто не пользовался. А предложение отделить профиль стандартной инсталляции, включая модули с основным функционалом, в отдельные проекты (вероятно, все в один проект) пока не очень-то вызывает положительные отклики.
Даже несмотря на то, что этот самый проект, если нужно, теоретически мог бы поддерживать и Дрис. И несмотря на то, что тогда весь основной функционал мог бы развиваться гораздо быстрее, чем ядро Друпала. Что разумно в особенности для модулей, направленных исключительно на пользовательский интерфейс. У них нет зависимостей от изменений API, которые нужно было бы учитывать. И вообще, эти модули архитектурно устроены по тому же принципу, что и все дополнительные модули.
Нужно обсудить, можем и хотим ли мы переместить основные функции в отдельный проект в долгосрочной перспективе.
Чем могу служить, хозяин?
Первичная цель — собраться. Сейчас куча неважных вещей отвлекает нас от всего важного и сильно мешает заняться категорически необходимым рефакторингом. Каждый баг сосет из разработчика ядра энергию и время.
И не забудьте о времени координаторов разработки ядра. Чем меньше времени они потратят на какие-то баги, тем больше его будет на обсуждение и оценку архитектурных решений. Многие разработчики ядра неоднократно отмечали в прошлом, что было бы очень неплохо «вернуть» техническое руководство. Сейчас все взаимодействия координаторов разработки происходят в основном на одни и те же темы: контроль ошибок, обратная совместимость, изменения в API, стиль кода, документация, прочий треп. И практически никакого обсуждения, собственно, архитектуры. Текущая ситуация — случай исключительной дело-кратии. Сообщество Друпала ожидает, что координаторы проектов (и ядра, и остальных) будут вести вперед, делиться своими представлениями, направлять. В том числе и в ядре.
И еще:
Обязательно посмотрите доклад eaton на тему «Продукт, фреймворк или платформа?» с DrupalCon London. В нем автор глубоко анализирует историю того, как мы пришли к текущей ситуации. Доклад длится час, но этот час стоит того. Спасибо, eaton!
