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