[docs] Сизифов труд: глава про git/gear
Kirill Maslinsky
kirill на altlinux.ru
Пн Ноя 13 13:02:47 MSK 2006
Коллеги,
наконец сдвинулась с мертвой точки работа над книгой "Сизифов труд"
(https://heap.altlinux.ru/engine/Heap/Books/AltLibrary/Sisyphus2006)
В частности, Артем Золочевский (azol@) благородно согласился
взяться за написание главы про git/gear.
Самый нетривиальный, как оказалось, вопрос, в этой главе:
а зачем, собственно, весь этот сыр-бор нужен?
Я попробовал ответить на этот вопрос: см. примерный план
главы про git/gear ниже в письме -- там изложение начинается
от сравнения старого и нового способа организации репозитория.
Если есть комментарии и дополнения -- прошу не таить.
Этот план (и, видимо, последующий текст по нему) см. также на
git.alt:/people/kirill/packages/docs-distributed_sisyphus_development-azol.git
=== План главы про git/gear ===
==== Распределенная схема разработки репозитория пакетов ====
===== репозиторий старый и новый =====
зачем нужен репозиторий:
платформа для решений (интеграция)
сообщество -- взаимопомощь и совместная работа
традиционная схема устройства репозитория:
представлен в виде коллекции пакетов (файлов):
исходные/бинарные
?архив старых файлов репозитория (не всегда, не сначала и т. п.)
формальная иерархия:
изменения в пакет нельзя внести без участия мантейнера
наши условия:
большая нагрузка на многих мантейнеров
свободное участие (т. е. без гарантий, что вовремя будет налажено)
требования к выпускаемым на данной платформе продуктам
новая схема устройства репозитория:
исходные тексты в виде репозиториев исходного кода (контроль версий),
а не коллекции файлов
бонусы: экономия на хранении архива и зеркалировании
удобство работы с исходным кодом
распределенная разработка:
нецентрализованная публикация результатов разработки
(возможно внести изменения в пакет без участия мантейнера)
===== реализация новой схемы в Сизифе =====
задачи и решения:
выбрать систему контроля версий:
- распределенную, без центрального репозитория
- эффективно работающую с большими архивами
(git)
определить политику хранения исходных текстов пакетов в репозиториях
(1 пакет -- 1 репозиторий)
организовать технологию сборки пакетов из данных репозитория
(gear)
определить политику организации репозитория репозиториев
- возможность участия разных разработчиков
(git.alt:/people/*)
- единое информационное пространство
(email-оповещения)
- технология публикации изменений в Сизифе
(gear-release, git-incominger)
- гарантия неутраты данных
(new NMU policy)
сохранение обратной совместимости на период перехода
параллельная работа incoming
===== конкретные сценарии работы с пакетом =====
создание репозитория
импорт srpms из архива Сизифа
архив Сизифа
сортировка версий (index архива)
gear-srpmimport
импорт из upstream:
upstream в git
upstream в CVS
upstream в SVN
upstream в tarball'ах
работа с репозиторием:
gear:
.gear-rules
сбособы сборки из репозитория (gear --hasher; gear-hsh-build ...)
дисциплина ведения репозитория
хороший тон написания Changelog (gear-commit)
использование бранчей
публикация в "персональном" Сизифе:
git.alt:/people/PACKAGER
доступ на git.alt (join@)
основы работы на git.alt
публикация репозитория "из дома" на git.alt
совместная разработка в Сизифе:
неформальная иерархия разработчиков
мантейнер -- формально ответственный
клонирование репозиториев других разработчиков
к себе на git.alt
к себе "домой"
грабли при публикации клонированных репозиториев
информационное пространство совместной разработки:
email-оповещения
организация git-репозитория, ориентированного на совместную работу
дисциплина ведения бранчей
интеграция изменений, сделанных другими разработчиками
публикация в "официальном" Сизифе:
git.alt:Sisyphus (пока не существует)
релиз-теги как указание к публикации (gear-release)
публикация тега в своем репозитории на git.alt
вызывает процедуру сборки в Сизиф
политика NMU
по умолчанию разрешается всем публиковать пакет (релиз-тег),
с условиями:
более старшая версия
строгое наследование по отношению к предыдущей удачной сборке
работа с апстримом:
отправка патчей в upstream
возвращение твоих патчей из апстрима в новой версии
круговорот версий в природе
upstream -> packager -\
^ |
| V
\--------------- patches
|
V
repo
upstream в git
upstream в CVS
upstream в SVN
upstream в tarball'ах
===== основные понятия, без осознания которых не понять git/gear =====
# вероятно, это будет написано во вводном разделе
# поэтому на это нужно опираться как на известное
# и не пересказывать еще раз подробно, а только резюмировать,
# если это нужно в качестве отправной точки
две формы существования ПО:
исходный текст/бинарная
это верно для прототипического случая программы,
написанной на компилируемом языке
в более общем виде то же самое:
универсальная/зависимая от окружения, интегрированная
примеры: компиляция
линковка с динамическими библиотеками
раскладывание файлов по системе (make install)
и т. п.
ЛИРИЧЕСКОЕ ОТСТУПЛЕНИЕ: make, autotools
понятие пакет
зависимая форма, предназначенная специально для использования
в конкретном окружении
Пакет -- форма адаптации программы к конкретным условиям эксплуатации.
Например, для русскоязычных пользователей, для конкретного
дистрибутива, для определенного набора задач и т. п.
Пакет в рамках дистрибутива представляет удобный уровень
абстракции, который позволяет пользователю работать с
"функциональностью", а не кучей файлов и установочных процедур.
бинарный пакет: "переменные" заполнены конкретными значениями
скомпилировано, прописаны системные пути для файлов,
определены конкретные зависимости от других компонент системы
добавлены процедуры регистрации в системе при установке/удалении
короче говоря, готовое для работы некоторым образом "из коробки"
исходный пакет: контейнер всех исходных данных пакета
исходный код + разные конкретизации и добавления
патчи
конфиги по умолчанию
зачем нужен репозиторий:
платформа для решений (интеграция)
сообщество -- взаимопомощь и совместная работа
состав пакета:
две принципиальные части:
1) upstream -- исходный текст, пришедший от разработчиков
2) спек/патчи -- сумма изменений/дополнений, внесенных при упаковке
ЛИРИЧЕСКОЕ ОТСТУПЛЕНИЕ: что такое патч
формат пакета RPM (компонентый состав пакета)
спек
тарболлы
патчи
пакет и проект: роль и задачи мантейнера
понятие upstream: разработчики, оригинальный источник ПО
в рамках пакета должно быть понятно, что взялось из upstream,
а что добавлено мантейнером:
позволяет легко отслеживать отличия данного пакета от
других; упрощает поиск и возвращение патчей в апстрим.
отправка патчей в upstream --
(тут небольшой идеологический фрагмент, почему так надо делать)
принятые в upstream патчи возвращаются в пакет в новых версиях
ВРЕМЯ
теперь введем в эту картину еще одно измерение -- время
версии ПО:
обновление развитие ПО
ЛИРИЧЕСКОЕ ОТСТУПЛЕНИЕ: что такое контроль версий
живой/мертвый проект
почему живой хорошо:
компонентная система = зависимости / иначе устаревание
в том числе происходит обновление инструментария
(например, gcc)
ошибки = надежность/безопасность
развитие = расширение функциональности
новые версии программ в общем случае работают несколько лучше чем старые
===== отсюда начинается уже собственно глава про git/gear =====
# это несколько более многословное изложение первой части плана
# собственно про репозиторий
жизнь репозитория: (традиционная схема)
2 формы представления:
srpm/rpm
способ публикации:
закачка srpm в incoming по доверенному ключу
разделение ответственности:
право на публикацию у мантейнера или группы
для остальных политика default deny
особая процедура обращения в incoming для разрешения NMU
архив версий пакетов
необходимо хранить, потому что дистрибутивы, поддержка
старых пакетов и возможность отката к предыдущей (работоспособной)
версии в случае ошибок
куча файлов
задачи:
платформа для решений сроки
поддержка надежности и безопасности
наши условия:
свободная мотивация
1. проблема доступности мантейнера (проблема свободного времени)
если нам в этой ситуации необходима гарантия
своевременного участия, то мы должны дать легкие
и надежные средства для помощи другим разработчикам,
причем так, чтобы эти средства не приводили к потере
данных между разработчиками NMU
2. проблема утраты информации
вовремя неопубликованный результат может быть навсегда утрачен
для сообщества
никакой участник сообщества не обязан следить за всем
информационным полем.
задача сохранения кем-либо внесенных ценных данных (не потерять NMU)
3. вообще работа не связанных друг с другом людей
объединение усилий по разработке, обмен патчами и т. п.
идея: хранить исходный код не в srpm, а в системе контроля версий
разработчикам нужен исходный код, причем хочется иметь
возможность работать с исходным кодом в системе контроля версий
идея: использовать максимально децентрализованную схему разработки
должна быть возможность нецентрализованной _публикации_ любых
результатов разработки, сделанных любым участником сообщества
/ это необходимо при отсутствии гарантированного участия разработчиков /
(свободная мотивация)
ЛИРИЧЕСКОЕ ОСТУПЛЕНИЕ: те же принципы на примере WikiWiki
идея: политика default permit
задачи, вытекающие из этих идей:
выбрать систему контроля версий: (git)
- распределенную, без центрального репозитория
- эффективно работающую с большими архивами
определить политику хранения исходных текстов пакетов в репозиториях (1 пакет -- 1 репозиторий)
организовать технологию сборки пакетов из данных репозитория (gear)
определить политику организации репозитория репозиториев (Сизиф)
- возможность участия разных разработчиков (git.alt:/people/*)
- единое информационное пространство (email-оповещения)
- технология публикации изменений в Сизифе (git-incominger)
- гарантия неутраты данных (new NMU policy)
--
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.altlinux.org/pipermail/docs/attachments/20061113/be1507ba/attachment.bin
Подробная информация о списке рассылки docs