Перед тем как начать собирать ssh-ключи, хочу обсудить Вариант полиси и шаблонов при работе с git.etersoft<br><br>Черновик полиси:<br>&nbsp;<br>Разработчики:<br>1) У каждого разработчика и мейнтейнера есть свой набор репозиториев, аналогично тому как это организовано в <a href="http://git.altlinux.ru/people">git.altlinux.ru/people</a>.<br>
Этот набор репозиториев - сфера отвественности одного человека, его промежуточные и конечные результататы.<br>2) Результат деятельности по отдельному пакету фиксируется по заданной ветке репозитория того, кто является ведущим этого проекта (в данном случае я несколько вольно употребляю слова пакет и проект как синонимы, обычно проект может в себя вкпючать более одного пакета).<br>
3) При необходимости совместно вести работу разработчики синхронизируются по репозитарию ведущего, но могут самостоятельно вести работу в своём репозитории.<br><br>Роботы:<br>1) Центральный репозитарий пакетов компании собирает робот, в настройках которого указаны разработчики и пакеты, за которые они отвечают.<br>
2) Робот регулярно (например ежедневно), проверяет наличие новых пакетов сравнением текущей версии пакета с самой старшей версией тега (вида пакета-версия-релиз) в репозиории.<br>3.1) После получения списка пакетов на пересборку произодится процесс пресборки с учётом зависимостей<br>

3.2) Для принудительной сборки пакета сущствует скрипт, которым пользуется Робот - скрипт позволяет, по имени пакета и соответствию пакетов разработчикам, найти и выбрать нужный репозитарий и собрать пакет последней или заданной версии.<br>
4) После сборки пакета робот отправляет лог сборки разработчику - с успехом или ошибкой.<br>5) Каждая успешная сборка импортируется, с помощью gear-srpmimport, в отдельный репозиторий результирующих сборок - аналог <a href="http://git.altlinux.org/archive/">http://git.altlinux.org/archive/</a><br>
<br>Что позволяет делать такая схема?<br>Задачи:<br>1) Отдельные задачи можно легко передавать от одного разработчику, не задаваясь вопросом о правах. Каждый вновь получающий пакет, выписывает его у последнего.<br>Например, я веду пакет Package1. Потом его передают Диме, затем над ним продолжает работу Сергей.<br>
2) Можно проводить аудит и коррекцию работы, а также помогать не мешая работе основного разработчика.<br>Например, Сергей ведёт пакет Pаckage2. Я выписываю его текущий результат, однаруживаю недочёт и сообщаю ему об этом. Он выписывает мои испраления к себе в основной код или отдельную ветку. Последнее тоже важно. Мои изменения могут показаться среею недостаточными, но он сможет посмотреть их не внося изменения в свой основной код.<br>
3) Можно качественно проводить совместную работу удалёнными друг от друга разработчиками. Отвественным за сбор конечного пакета является один человек - ведущий. Именно из его репозитория собирается результат в репозиторях доступных обновлений.<br>
Например, Я веду пакет Package3, со мной вместе его ведут ещё два человека. При необходимости они всегда могут получить мои изменения, но могут вести свои работы отдельно. Моя отетственность состоит в том,чтобы согласовать ветку в которой я получаю результаты их работ. Между тем они сами могут брать измнения друг у друга, а могут доверять мне и регулярно ообщая мне о своих результатах, могут обмениваться изменениями через меня.<br>
<br>Хочу заметить, что никаких прав на общие репозитарии назначать в этой схеме не нужно. Достаточно выбрать ответственного и прописать роботу и его скриптам брать результаты у него. При смене ведущего, новому отвественному достаточно выписать у старого последнюю версию, а роботу исправить имя при поиске собираемого пакета.<br>
<br clear="all"><br>-- <br>Sin (Sinelnikov Evgeny)