[Devel] Git-Policy

[Evgeny Sinelnikov]

Перед тем как начать собирать ssh-ключи, хочу обсудить Вариант полиси и
шаблонов при работе с git.etersoft

Черновик полиси:

Разработчики:
1) У каждого разработчика и мейнтейнера есть свой набор репозиториев,
аналогично тому как это организовано в git.altlinux.ru/people.
Этот набор репозиториев - сфера отвественности одного человека, его
промежуточные и конечные результататы.
2) Результат деятельности по отдельному пакету фиксируется по заданной ветке
репозитория того, кто является ведущим этого проекта (в данном случае я
несколько вольно употребляю слова пакет и проект как синонимы, обычно проект
может в себя вкпючать более одного пакета).
3) При необходимости совместно вести работу разработчики синхронизируются по
репозитарию ведущего, но могут самостоятельно вести работу в своём
репозитории.

Роботы:
1) Центральный репозитарий пакетов компании собирает робот, в настройках
которого указаны разработчики и пакеты, за которые они отвечают.
2) Робот регулярно (например ежедневно), проверяет наличие новых пакетов
сравнением текущей версии пакета с самой старшей версией тега (вида
пакета-версия-релиз) в репозиории.
3.1) После получения списка пакетов на пересборку произодится процесс
пресборки с учётом зависимостей
3.2) Для принудительной сборки пакета сущствует скрипт, которым пользуется
Робот - скрипт позволяет, по имени пакета и соответствию пакетов
разработчикам, найти и выбрать нужный репозитарий и собрать пакет последней
или заданной версии.
4) После сборки пакета робот отправляет лог сборки разработчику - с успехом
или ошибкой.
5) Каждая успешная сборка импортируется, с помощью gear-srpmimport, в
отдельный репозиторий результирующих сборок - аналог
http://git.altlinux.org/archive/

Что позволяет делать такая схема?
Задачи:
1) Отдельные задачи можно легко передавать от одного разработчику, не
задаваясь вопросом о правах. Каждый вновь получающий пакет, выписывает его у
последнего.
Например, я веду пакет Package1. Потом его передают Диме, затем над ним
продолжает работу Сергей.
2) Можно проводить аудит и коррекцию работы, а также помогать не мешая
работе основного разработчика.
Например, Сергей ведёт пакет Pаckage2. Я выписываю его текущий результат,
однаруживаю недочёт и сообщаю ему об этом. Он выписывает мои испраления к
себе в основной код или отдельную ветку. Последнее тоже важно. Мои изменения
могут показаться среею недостаточными, но он сможет посмотреть их не внося
изменения в свой основной код.
3) Можно качественно проводить совместную работу удалёнными друг от друга
разработчиками. Отвественным за сбор конечного пакета является один человек
- ведущий. Именно из его репозитория собирается результат в репозиторях
доступных обновлений.
Например, Я веду пакет Package3, со мной вместе его ведут ещё два человека.
При необходимости они всегда могут получить мои изменения, но могут вести
свои работы отдельно. Моя отетственность состоит в том,чтобы согласовать
ветку в которой я получаю результаты их работ. Между тем они сами могут
брать измнения друг у друга, а могут доверять мне и регулярно ообщая мне о
своих результатах, могут обмениваться изменениями через меня.

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


-- 
Sin (Sinelnikov Evgeny)
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: http://lists.etersoft.ru/pipermail/devel/attachments/20080220/e42f6297/attachment.html