[devel] pockets

[Alexander Bokovoy]

2010/4/2 Evgeny Sinelnikov <sin на altlinux.ru>:
>>> Индивидуальный girar-builder не решает вопрос, когда перелопатить
>>> надо слишком тяжёлый для двух рук / слишком развесистый для одной
>>> головы кусок сизифа.
>>
>> Индивидуально развёртываемый girar-builder не обязательно означает
>> индивидуальный girar-builder.  Разумеется, в распределённой системе
>
> А можно уточнить разницу между "индивидуально развёртываемым
> girar-builder'ом" и "индивидуальным girar-builder'ом"? Мне эта разница
> кажется важной, но, что имеется в виду, непонятно.
Тут нужно уточнить, что то, о чем пишет Дима, обсуждалось неделю назад
в офисе ALT, когда мне удалось оказаться в Москве. Вот небольшая
выдержка-резюме:

0. Успешная совместная деятельность возможна при хотя бы частичном
совпадении интересов и совпадении ритма деятельности.

1. Возможности совпадения ритма деятельности ограничиваются
коммуникационными возможностями взаимодействующих сторон. Лет десять
назад практическая возможность быстро реагировать на изменения
пакетной базы и устранение проблем в пакетах была ограничена
пропускной способностью каналов связи, за которыми находились члены
команды, а также их возможностью быстро обмениваться сообщениями "в
реальном времени". "Реальное время" конца 90-х -- несколько дней для
географически распределенных участников. "Реальное время" для ученых
XVII-XVIII веков -- месяцы, для сравнения.

2. В то время, когда сдерживающим фактором являются каналы связи,
крайне важно выполнять свою часть работы так, чтобы она не затрагивала
с отрицательной стороны других членов команды, коммуникация с которыми
затруднена. Фактически, увеличение стоимости того или иного пути за
счет ошибки в пакетировании/программе прямо пропорционально времени,
затраченному на коммуникацию сообщения об ошибке, разработку
исправления и доставку его корреспонденту. В этом контексте важным
становится возможность проведения локального эксперимента, не
затрагивающего других. В дискуссии в пятницу я назвал эту возможность
"what if", правом на независимый эксперимент.

3. Способы устранения сдерживающих фактором разнообразны. К сожалению,
технические возможности не всегда позволяют масштабировать эти способы
на реальные команды. В 2001-2002 году в SaM Solutions был разработан
способ поддержания разработки репозитория пакетов, позволявший
локальные эксперименты отдельных разработчиков -- sandman. Исходная
информация о пакетах хранилась в CVS, с возможностью построения
локального среза репозитория по ветке из CVS для конкретного пакета. В
таком локальном срезе можно было пересобирать разные пакеты, не
затрагивая основной репозитарий, а затем "сливать" изменения в
основную ветку, перемещая их в основной репозитарий. CVS не
масштабируется для географически распределенных команд, но в случае
SaM Solutions решение работало для приблизительно полусотни
разработчиков, размещенных в одном офисе. Результат локального
эксперимента дальше "сливался" с основным Сизифом традиционным
образом. Поскольку взаимодействующие команды, работавшие над общей
группой пакетов, были практически всегда локализованы в рамках одного
офиса, коммуникационные ограничения были сведены до минимума, а темп
взаимодействия с другими группами был ограничен каналами связи.
Поскольку результат, сливавшийся с основным Сизифом был уже
относительно протестирован в рамках локальных экспериментов, то каналы
связи не накладывали очень сильных ограничений на темп взаимодействия
при ошибках (количество ошибок было естественным образом меньше).

4. Нужно отметить, что Sandman+CVS не подходит для географически
распределенной группы команд и это ограничило его внедрение для всех в
team.

5. Когда в 2005 году появился hasher, независимо от него изменились
коммуникационные условия для многих участников team. Каналы связи
стали быстрее, а во многих случаях и неограничены по трафику. Hasher
реализовал часть функционала Sandman по автоматизации возможности
локального эксперимента, а появление git в том же году дало
возможность распределенной работы над исходником одного пакета. То
есть, появление git позволило решить проблему, которая препятствовала
внедрению Sandman для всей команды.

6. К сожалению, одна часть Sandman по-прежнему осталась не охваченной.
Локальный эксперимент хорош тогда, когда пакет или группу пакетов
ведет один человек или группа, имеющая физический доступ к общему
хранилищу, фактически, "географически нераспределенная команда". Такой
можно представить отдельных разработчиков и, например, всю комнату
разработчиков в ООО "ALT Linux". Если команда на самом деле
географически распределена, промежуточный результат необходимо
разделять между всеми ее участниками, а это как раз сейчас и
отсутствует. Фактически, отсутствует возможность подстройки ритма
деятельности географически распределенной команды при совпадении
интересов.

7. Результатом такого неритмичного взаимодействия стала
"монополизация" пакетных блоков. Она может быть решена только одним
способом -- возможностью эксперимента внутри такой группы
разработчиков, вне зависимости от ее географической распределенности.
Сегодня мы имеем один способ совместного эксперимента -- помещение
промежуточных версий разрабатываемых пакетов в Сизиф. Побочный эффект
-- дестабилизация Сизифа выше определенного ожидаемого уровня,
дестабилизация связана с разными ожиданиями к промежуточным
результатам со стороны группы и команды целиком. Для группы
промежуточные нерабочие версии составляют неотъемлемую часть
локального эксперимента (локального для группы), но результатом
становится принудительное расширение этой группы на всю команду, что
ведет к очевидным конфликтам.

8. Решение конфликтов -- локализация процесса эксперимента, но уже не
по географическому признаку, как было в случае Sandman+CVS, а путем
построения временных срезов, контроль над состоянием которых полностью
в рамках рабочей группы, а принятие результатов ее эксперимента
осуществляется в рамках стандартного процесса пересборки относительно
текущего Сизифа. Если мы используем терминологию git, то это означает
регулярное ветвление репозитария с возможностью совместного коммита в
получаемые ветки и использование механизма проверок при слиянии
обратно в основную ветку разработки.

9. К сожалению, текущая инфраструктура проекта не содержит некоторых
критичных для реализации этого подхода компонент:
- возможность делать дешевые срезы репозитария (требует дисковое
пространство, в пятницу выяснилось, что этой проблемы больше нет на
обозримый горизонт планирования, а на этой неделе переезд git.alt
завершил и стадию нехватки дискового пространства сейчас) и
периодически перебазировать срезы на текущий сизиф
- возможность переопределения прав доступа на пакеты внутри среза
(перекрытие ACL пакетов внутри среза на ACL работающей над
срезом/пакетами группы), с тем, чтобы группа могла модифицировать
любой пакет в срезе, пока идет локальный эксперимент
- возможность выборочного отключения ряда проверок при сборке пакетов,
которые имеют смысл только при слиянии с основной веткой разработки
(Сизифом)
- разграничение прав доступа по записи в различные срезы между группами
- установление временных ограничений на существование локального
группового эксперимента с целью поощрения более быстрого темпа работы
и слияния с основной веткой разработки.

10. Последний момент крайне важен. Чаще всего локальный эксперимент не
занимает продолжительное время, для определенности -- двух недель.
Если позволить жить эксперименту вечно, то он рискует превратиться в
форк, без реального поощрения слияний с основным руслом разработки.
Для более сложных локальных групповых экспериментов может
потребоваться более продолжительный срок жизни, однако и здесь я бы
ограничился месяцем. За месяц можно синхронизировать большинство
ритмов взаимодействия, а если потребуется дополнительное время, то
расширение срока жизни эксперимента должно быть сопряжено с четким
планированием группой своей работы и может служить хорошим поводом
оценить свои достижения.

-- 
/ Alexander Bokovoy