21 апреля 2011 в 2:35
На мой взгляд произошно очень важное событие в мире разработки Друпал - предложена великолепная стратегия для дальнейшего развития кода с более качественным подходом к внесению изменений в ядро и модули окружения вместе с темами оформления.
15-ти минутный подкаст lullabot.com излагает основные возможности и области применения персональных "песочниц" кода.
Например:
- можно сделать свой форк(клон) ядра и дорабатывать для определенных целей (улучшения локализации, оптимизации для конкретных применений mysql pgsql sqlite, национальные сборки)
- собственные версии и релизы модулей и тем оформления для поддержки обслуживаемых сайтов, тем самым действительно полезные изменения быстрее станут официальными.
Интересно получить отзывы и дополнительные идеи по применению "песочниц"
Опрос, думаю, будет интересен всем разработчикам!!!
ЗЫЖ пытаюсь реанимировать свой блог http://prodrupal.ru/ru/node/88
Комментарии
А при чем тут безопасность?
в английском не силён, поэтому вопрос - каким образом они быстрее станут официальными?
Имхо, идея провалилась.
Песочницы задумывались как средство для первоначального размещения модулей и тем перед их дальнейшей публикацией в качестве полноценных проектов. Т.е. предполагалась, что разработчик публикует свой код в песочнице, а добровольцы-волонтеры тестируют его, делают так сказать аудит и после устранения всех недочётов создается issue для придания этому проекту статуса full project.
Поэтому казалось, что использовать песочницы вместо github предпочтительней.
Реально, оказалось что тестировать чужой код в песочницах некому.
Даже те проекты, которые находятся в очереди на утверждение могут валятся там месяцами, без какого либо шанса быть рассмотренными.
see Module Approval Process will KILL Drupal
Это одна из причин, не удачи #D7CX. Многие популярные модули до сих пор не портированы на 7-ку из-за того, что их разработчикам некогда этим заниматься или они уже потеряли интерес к этому. В тоже время опубликовать модуль с похожим функционалом для Д7 не реально, потому что это противоречит политике исключения дублирования модулей (collaboration rather than competition). Поэтому, для того чтобы портировать какой нибудь модуль на 7-ку нужно связаться и получить согласие на это у предыдущего разработчика. Такая вот
.
демократиябюрократия--
P.S. Друпал на git это конечно удобней и перспективней.
Безопасность - непосредственно связана с кодом и управлением его изменениями. Грамотно организованный процесс значительно повысит безопасность.
По большей части это так, кроме авторов, которые умеют донести сообществу полезность своих разработок. Как пример подобного процесса drupal.org/project/dbtng_migrator
Здесь скорее виноваты пользователи, которые занимают выжидательную позицию.
Создание форков-клонов и ссылка на "песочницу" из issue портирования решает и эту проблему. И если модуль действительно популярный, то никто не будет возбранять создание форка, да и сделать ко-мэйнтейнером активиста нет проблем. как пример модуль metatags_quick