CommunityCooperation

PreScriptum: просьба НЕ типографить этот текст с тем, чтобы легче было копипастить куски в mutt при необходимости.

Взаимодействие с сообществом

Поскольку обсуждения этого вопроса в рассылках @altlinux обычно приводят к высказыванию ценных и не очень мыслей, "+1/-1" под ними, а также распуханию соответствующих тредов и невозможности отжать сухой остаток -- попробую перевести в чуть другой режим и заодно сформулировать ряд соображений, которые мне (mike@) как участнику сообщества с 2001 года и относительно неплохо знакомому с многими людьми в ООО Альт Линукс наконец пришли в голову, пока сегодня просыпался.

Просьба редактировать текст только после полного прочтения существующего, а при желании поддержать какое-либо утверждение -- поставить после него [+1] (или увеличить число на единицу). Если утверждение пришлось скорректировать по смыслу, такую пометку следует убрать.

Введение

Я не считаю, что у компаний бывает мнение -- оно бывает у людей, а в компаниях бывают люди, мнение которых и работает в качестве мнения компании. Применительно к рассматриваемой грани деятельности ООО Альт Линукс {,Текнолоджи} (дальше для простоты ООО) такими людьми считаю ldv@ по технико-организационным вопросам и aen@ по политическим и отчасти социальным.

Здесь под сообществом подразумеваю как людей вне каких-либо компаний, так и людей в различных коммерческих компаниях, занимающихся ИТ-тематикой с активным применением свободных программ (к каковым и сам отношусь). Это разработчики, внедренцы, суппортеры, пользователи... Разницы между ними особой не делаю в силу того, что по большей части разницу вижу в степени взаимного доверия, а это определяется иными факторами, нежели формальная принадлежность одной организации.

Смысл

Мне кажется, что для успешного взаимодействия у сторон должно быть нечто общее в качестве почвы для работы -- и нечто, что каждая сторона может дать другой, не имеющей [в такой степени] того.

В случае ООО и сообщества общей (NB: речь не о противопоставлении никоим образом!) видится цель получения технической базы для более удобного решения своих частных задач: выпуска дистрибутивов, поддержки серверов на работе и десктопов где угодно, (расширяйте список).

Тем, что сообщество может дать ООО, видится:

• общественную поддержку
• тестирование, отзывы, реже багрепорты, ещё реже патчи
• сопровождение до того отсутствовавших или неухоженных пакетов
• выпуск производных и оригинальных дистрибутивов
• создание и улучшение инфраструктуры

Что ООО может дать сообществу:

• системную поддержку внедренцев (точка входа и процесс предсказуемого решения проблем)
• предсказуемые выпуски основных дистрибутивов
• время людей на ставке для решения непопулярных/долговременных вопросов (xorg, kernel; QA бранчей...)
• инфраструктуру сопровождения пакетной базы
• стратегическое планирование

Проблемы

NB: Точка зрения ldv@ на вопросы, обозначенные в этом разделе, коренным образом отличается от высказанной ниже.

NB: я (mike@) старался констатировать, а не указывать.

На данный момент (начало лета 2009) скопился ряд проблем взаимодействия (давайте ограничимся здесь только ими), затрудняющих плодотворную работу как сообщества, так и ООО. К ним относятся:

• растущий ряд технических мер по обеспечению качества пакетной базы, отягощающий бремя пакаджеров (при этом потенциально облегчая бремя внедренцев)
• невнятность или невыполнение существенной части высказываемых планов ООО, что затрудняет ориентирование
• неочевидность распределения ответственности и его изменений, приводящая к конфликтам и разочарованиям

В какой-то момент экземпляр sisyphus_check, используемый для проверки пакетов, приходящих через incoming, оказался инструментом навязывания ООО ldv@ своего видения допустимой степени качества пакетов сообществу; при этом советоваться заранее по факту оказалось не принято, а обсуждение оправданности добавляемых проверок в лучшем случае имело место после их введения. (FIXME: проблема не в самом повышении планки, а во взаимодействии; экземпляр при этом является тем же пакетным sisyphus_check из Sisyphus)

Таким образом возникла ситуация, когда неочевидные и, как правило, выходящие далеко за рамки исходного ALT Packaging Policy требования оказались навязываемыми принудительно на основании рассуждения небольшой группы внутри ООО -- и их список непредсказуемо расширялся.

Это привело к уходу из проекта ряда ценных людей высокой квалификации (например, ott@) и соответственно недостаточного свободного времени, а также потере заметного количества работающих пакетов по формальным придиркам.

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

Это привело к затруднительности взаимовыручки и резкой потере динамики разработки и улучшения пакетов.

Также по техническим соображениям (time genbasedir) было произведено слияние компонент репозитория (base, main, contrib...) в единый classic.

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

Далее по своим, безусловно, благим соображениям был продуман и проведён процесс перевода сборки на git/gear, что привело к прыжку порога вхождения (попросту говоря, вводившие сместили баланс удобства майнтейнеров-разработчиков и майнтейнеров-админов существенным образом в сторону первых, не посоветовавшись заранее и почти не внимая аргументам в данном вопросе по ходу дела). При этом процесс переезда пакета на сборку из git является односторонним (за исключением удаления из репозитория и заливания src.rpm).

Это привело к более ярко выраженной кастовости, возможности фактической изоляции "своего хозяйства" запутанным сознательно или по неопытности устроением git-репозитория, ограничению "админской" части репозитория (релизы+патчи без особого вмешательства в код, но с целью использования в production), а также спровоцировало "разработческую" часть к режиму работы "собираем каждый коммит в апстримном гите".

Как если бы этого было мало, релиз-менеджмент бранчей был также свален на сообщество путём предоставления ему возможности копировать пакеты в последний стабильный бранч из нестабильного Sisyphus без особого участия в этом процессе хотя бы одного живого квалифицированного человека, лично заинтересованного в пригодности результата. При этом не был практически учтён тот давно известный факт, что опыт и квалификация участников команды сильно варьируются; цели же и критерии качества бранча в сообществе либо неочевидны, либо не высказаны вообще, либо не подлежат автоматической проверке при замене человека таковой.

В бранч стало лететь всё подряд без надлежащего тестирования в Sisyphus и главное -- обоснования в свете целей существования бранча и согласия бранч-менеджера (за упразднением роли такового).

В качестве одной из попыток повысить качество была реализована схема автоматической публикации пакетов с запретом добавления unmet'ов, которая получила существенное количество критики как за техническую неэффективность в SMP-окружении (однопоточная сборка всех пакетов), так и за организационную несостоятельность при разработке unstable (в отличие от stable).

В частности, изменение soname библиотек стало ближе к коллективной пытке.

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

В сумме стабильность Sisyphus и предполагавшегося дистрибутивным 5.0/branch с осени 2008 по весну 2009 года можно назвать беспрецедентно низкой, а бранч был официально объявлен непригодным.

Возможности

NB: к этому месту малость выдохся и изложение нестройное -- просьба комментировать на странице обсуждения и улучшать

Кажется разумным озвучить правила игры заранее: например, "мы будем повышать требования по части вашей квалификации и качества собираемых вами пакетов по своему разумению, не советуясь с вами и не принимая в расчёт ваши интересы; не нравится -- идите" в районе Join смотрелось бы честнее, чем невнятное упоминание sisyphus_check где-нибудь.

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

Из прикладных мер кажется разумным продолжить начатые процессы документирования "тайного знания" как по сборке, так и по нетехническим вопросам вроде освещённых выше, а также трезво оценивать вводимые при участии сообщества полиси и при нежелании их соблюдать -- высказываться вовремя, а не откладывать до времени фактических нарушений.

Из обсуждавшегося уже не один год считаю важными следующее:

• автоматика не чинит пакеты, пакеты чинят люди; поэтому автоматика должна им помогать, а не мешать -- "не навреди"
  • математика -- это хорошо, но не самоцель: живые люди важнее красоты модели
  • роботы -- тоже не самоцель: это они должны обслуживать человека, а не человек -- их
• перед фактическим введением новых ограничений следует документировать и обсудить их (возможно, введение в режиме warning порой более практично); перевод в ограничивающий режим допустим либо при согласии существенной части сообщества, либо при выделении ООО своих ресурсов на реализацию необходимых для соответствия изменений
• с ростом разнообразия пакетной базы, опыта команды и вместе с тем проверок однокомпонентный репозиторий оказывается несостоятелен, причём решение давно известно и когда-то использовалось -- многокомпонентный репозиторий
• упор в обеспечении качества обязателен для базовой части репозиториев (как нестабильного, так и стабильного), но для нестабильного неприемлемы ограничения, создающие существенные формальные помехи в исправлении проблем функциональности живыми людьми
  • т.е. для unstable допустим временный рост количества unmets, в отличие от stable
  • и для unstable его можно избежать введением т.н. "карманов" (pockets) -- оверлейных репозиториев, в которых подготавливаются изменения, задевающие пакеты более чем одного майнтейнера и требующие координированного выпуска
• не следует думать за других, с кем решили работать
  • не следует взваливать на себя всё бремя ответственности, и опытнейшему человеку свойственно ошибаться
  • следует слушать и других, они могут быть и правы

TODO

• предоставление на суд общественности
• исправление и дополнение
• расстановка ссылок на обсуждения
• мир, дружба, семечки ;-)