Re: [devel] release process (especially for physical media)

["Alexander Bokovoy" <ab@altlinux.org>]

On 11/4/08, Alexey Tourbin <at@altlinux.ru> wrote:
> > > Но тогда не будет нужны в партхозактиве^W нас с вами.
> > Практика показывает, что разделение труда все-таки требуется.
> > Программист не всегда архитектор, тем более крупных блоков. Архитектор
> > не всегда может обеспечить реализацию того, что он смог придумать и
> > изложить систематизированно и крайне редко может гарантировать
> > полноценное проведение всего процесса
> > проектирования-реализации-внедрения. Любые исключения лишь
> > подтверждают правило.
>
> Ну конечно, каждый занимается тем в чём он понимает и не лезет туда,
> куда он не понимает.  Каким тогда должен быть авторитетный лидер?
> Который, выходит, никуда не понимает.  И он будет формулировать
> технологические задачи: создать отдел тестирования, выпекать болванки,
> очистить Сизиф от бродячих котов.
Это технологические задачи конкретных организаций, нужные для решения
их конкретных задач в области собственной жизнедеятельности. К проекту
они имеют очень опосредованное отношение.

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

> Это всё очень шаткие рассуждения.  С одной стороны, менеджеры не нужны,
> с другой стороны, менеджеры нужны.  С одной стороны, интересы проекта
> не сводятся к интересам участников, с другой стороны, сумма интересов
> участников составляет интересы проекта.  Единство и борьба
> противоположностей.  Тема для лидера, в принципе говоря.
Понимаешь, Леша, либо ты отвечаешь за свой труд, либо это не твой
труд. К тому, что ты делаешь в "нерабочее" (по отношению к тому, за
что кормишь семью) время нельзя относиться тяп-ляп. К тому же,
свободные проекты не имеют иных средств борьбы с перекосами, кроме
собственных организаторов и участников. В любом мало-мальски успешном
проекте будет появляться кто-то, кто хочет монетизировать его. И тут
уже надо задаваться вопросом -- насколько действия монетизатора идут в
русле целей самого проекта. Эти диллемы решаются постоянно и везде. С
Samba Team, например, то же самое, с той разницей, что компании,
вкладывающие в разработку Samba, на рынке активно борются с друг
другом. И порой предлагают своим сотрудникам-членам проекта такие
направления развития, которые не очень полезны проекту. Это
классическая борьба и ответственность.

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

Кто будет лидером в такой ситуации? Все, кто может своей деятельностью
доказать, что его технологические и организационные решения идут на
пользу проекту и сможет провести их без разрушения проекта. Таких
людей может быть на самом деле много, а статус и функции их не есть
константа. Например, Samba была начата Эндрю Триджеллом, затем к
разработке подключились Джереми Эллисон и Фолькер Лендеке. Они до сих
пор играют важную роль, но в вопросе функционала, который должен быть
в том или ином релизе ветки 3.0, у них меньше голосов, чем у Джерри
Картера, а в 3.2 -- меньше, чем у Каролин Сигер. Последние два --
релиз-менеджеры. И они могут "зарубить" благие намерения любых
разработчиков, если они приведут к дестабилизации кода в конкретном
релизе. С другой стороны, представительские функции есть у всех и
принятие действительно важных технических решений осуществляется путем
обсуждения и голосования всех. В этом случае лидеры выступают наравне
с остальными в попытках обоснования той или иной позиции.

> Мне кажется, что интерес к выпеканию болванок и созданию *не*
> специализированных решений перегрет.  Достаточно иметь минимальный
> инсталлятор Сизифа (или бранча), дальше самому ставить нужные
> компоненты.  Большая часть реальных усилий всегда будет направлена
> на пакетную базу.
Я полностью согласен. Это именно то, что я называю задачами конкретных
организаций.

У нас есть масса других общепроектных проблем, которые необходимо решать.
-- 
/ Alexander Bokovoy