[devel] ACL in branches

[Alexey Tourbin]

On Sat, Mar 07, 2009 at 12:17:49PM +0300, Dmitriy M. Maslennikov wrote:
> 2009/3/6 Alexey Tourbin <at на altlinux.ru>:
> > Во-вторых, что можно противопоставить автоматике?  Только
> > квалифицированное тестирование вручную.  А квалифицированные тестеры
> > которые хорошо разбираются во всякой специфике это либо сами
> > разработчики либо прикладные специалисты.  Их просто не получится по
> > количеству и по времени запрячь в какое-то предварительное тестирование
> > перед выкладываением пакетов в сизиф.  Можно через какое-то время
> > надеяться на feedback.  А автоматика работает достаточно быстро,
> > и её легко запрячь на проверку предварительных условий.
> >
> > Ну я и говорю что стабильность это скорее демагогия.  Она вроде бы
> > поддерживается на плохо формализуемом конвенциональном принципе "в
> > бранчи не следует заливать экспериментальный софт".  Но его туда всё
> > равно заливают.  Потому что каждый думает, что его пакет хороший и в
> > проблемах не виноват.  Что тогда даёт этот бранч?  Если все эти
> > конвенциональные соображения трудно сформулировать и трудно проверить.
> >
> > И что тогда можно придумать, чтобы всем было хорошо?
> >
> > И какого же рода вещи таким образом можно протестировать?  И важно
> > чтобы проверка не лажалась, то есть чтобы уровень false positives был
> > не больше 0.1%.  Иначе мы просто будем зарубать нормальные пакеты.
> >
> > Возможна ли такая протестированность в предварительном режиме, перед
> > тем, как пакеты попадают в Сизиф?  У нас как процесс устроен:
> > предварительное тестирование, попадание пакета в сизиф, дальше широкое
> > тестирование (всем миром).  Вопрос в том что можно сделать на первой
> > стадии за конечное время.  Ответ в том что тут впрягается автоматика
> > которая отлавливает грубые нарушения.
> Вот вам все и говорят здесь, что процесс не правильно устроен. Удобнее
> было бы, если сначала собранные пакеты попадали в созданный специально
> под задачу (например, обновление X-сервера) box или pocket, и
> появлялся анонс: "тестируем X-сервер все, кому он интересен".

Желание тестировать пакеты перед выкладыванием конечно похвальное,
но это как бы слишком круто что ли.  У нас в день прходит около 100
пакетов (в сизиф).  В пиковые рабочие часы мы просто не успеваем их
собирать, несмотря на неплохие в целом показатели производительности
сборочнцы.  То есть всё равно очередь накапливается на час вперёд,
это если не брать очень сложных пакетов/заданий, которые появляются
относительно редко.

И сколько реально нужно свободных человеко-часов, чтобы говорить
о предварительном тестировании вручную хотя бы энной части этих 100
пакетов?  Получается не то чтобы утопия, но, короче, очень круто.

А что касается X-сервера, то мейнтейнер вроде бы не очень комплексует,
когда выкладывает новые сборки, в которых есть известные проблемы по
сравнению с предыдущими сборками.  Эти проблемы ему даже обычно известны
заранее.  Не похоже, чтобы дополнительные возможности предварительного
тестирования могли радикально повлиять на политику мейнтейнера.  Он
вроде сам немного тестирует перед выкладыванием.

> Это
> коренным образом отличается от дедала, так как в специальном покете
> нет "мусора" из пакетов не относящихсяк делу. Если никто тестировать
> не захотел, то это проблемы коммунити, если же выявлены проблемы, то
> пакеты не принимаются и ничего ни у кого неожиданно не портят. Сейчас
> мы просто пропускаем этап тестирования вообще. И даже не планируем его
> в будущем, а просто пытаемся убедить все, что такой этап не нужен/не
> возможен/бесполезен.

Я считаю, что это действительно с трудом возможно и отчасти бесполезно.
Потому что пакеты работают не изолированно.  В рантайме собственный код
пакета комбинируется с кодом зависимостей пакета (причем транзитивно,
то есть с зависимостями зависимостей и т.д.).  Пока Вы тестировали
что-то одно, кто-то залил что-то другое.  И это может сделать Ваши
усилия если не бесполезными, то лишенными гарантии.

Кстати, поэтому имеет смысл налаживать автоматическое тестирование 
при сборке пакета, что-то типа 'make test'.  Пусть кто-то хочет
разломать Ваш пакет, но у Вас при сборке выполняется 'make test'.
Тогда облом 'make test' при тестовой пересборке является индикатором,
что новый входящий пакет не согласуется с Вашим существующим пакетом.

А вручную получается что каждый день надо всё заново тестировать, потому
что мало ли что где изменилось.

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

Есть соображения насчёт модели репозитария, которые лишают карманную
инфраструктуру привлекательности.  Соображения следующие:

1) Репозитарий пакетов в каждый момент времени может находится только
в одном состоянии.
2) Возможны строго последовательные (сериализованные) переходы, при
которых репозитарий переходит из одного состояния в другое состояние.
3) Каждый переход должен быть подготовлен на текущем состоянии
репозитария.

Последнее условие, в частности, запрещает копировать пакеты из одного
бранча в другой.

Карманы почему плохо согласуются с моделью?  Потому что карманы дают
множество параллельных состояний.  Не факт, что эти параллельные
состояния удастся "состыковать" и привести к виду последовательных
согласовнных транзакций.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20090307/ff675a2e/attachment-0001.bin>