Слияние репозитория

Предыстория

Во вторник 6 декабря 2016 года Команда Ansible Core повторно слила репозитории модулей обратно в ansible/ansible на GitHub. Два репозитория модулей будут фактически заблокированы, хотя они будут сохранены для существующих зависимостей 2.1 и 2.2. После того, как поддержка 2.2 будет прекращена (начало 2018 года), эти репозитории будут полностью доступны только для чтения для всех ветвей. До тех пор любые проблемы/запросы на вытягивание (PR), открытые там, будут автоматически закрыты с примечанием об открытии их на ansible/ansible.

Почему мы это делаем (снова...)?

Для тех, кто достаточно долго использует Ansible, вы знаете, что первоначально мы начинали с одного репозитория. Первоначальное намерение разделения ядра и дополнительных модулей заключалось в том, чтобы ядро получило лучшую поддержку/тестирование и т.д. Дополнительные модули должны были стать чем-то вроде «Дикого Запада» для модулей, чтобы новые модули могли быстрее интегрироваться в дистрибутив. К сожалению, это никогда по-настоящему не работало, а также по следующим причинам:

1. Многие модули в репозитории ядра также были фактически «унаследованными», несмотря на отсутствие хорошего набора тестов или выделенных хранителей из сообщества.
2. Время ожидания для слияния модулей в дополнительные модули фактически не отличалось от времени слияния модулей в ядро.
3. Разделение создало несколько других проблем для авторов, таких как необходимость отправки нескольких связанных PR для модулей с тестами или для тех, которые полагаются на плагины действий.
4. Git-субмодули известны своей сложностью, даже для авторов с хорошим опытом работы с git. Постоянная необходимость обновления указателей Git-субмодулей для devel и каждой стабильной ветви может привести к неожиданным результатам тестирования и не приносит нам никакой гибкости.
5. Пользователи уже могут испытывать трудности с тем, где открыть проблемы, особенно когда проблема, кажется, связана с модулем, но на самом деле является плагином действия (например, шаблоном) или чем-то более фундаментальным, таким как включения. Наличие всего в одном репозитории упрощает привязку проблем, и вы всегда уверены, что открываете отчет об ошибке в нужном месте.

Метаданные - поддержка/владение и статус модуля

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

1. Статус поддержки: Это поле указывает, кто поддерживает модуль, является ли это командой ядра, сообществом, автором или это заброшенный модуль, который не получает регулярных обновлений. Команда Ansible изучила список модулей и отметила около 100 из них как «Поддерживаемые ядром», что означает, что член команды Ansible Core должен активно исправлять ошибки в этих модулях. Большая часть остальных будет поддерживаться сообществом. Это не принципиально новое изменение, это просто делает ситуацию более понятной.
2. Статус модуля: Это поле указывает, насколько хорошо может быть поддержан данный модуль. Это обычно относится к зрелости параметров модуля, но не обязательно к статусу его ошибок.

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

Перенос проблем и запросов на вытягивание в новый репозиторий

Был разработан инструмент для переноса PR из старых репозиториев в ansible/ansible его можно найти по адресу инструмент prmover

Перед использованием prmover убедитесь, что у вас есть форк репозитория Ansible.

Для переноса проблем используйте GitHub Issue Mover

Если у вас возникнут любые проблемы с обновлением вашего PR, обратитесь за помощью в #ansible-devel

Для получения поддержки используйте #ansible-devel в канале Freenode IRC