On Fri, Mar 06, 2009 at 08:20:09PM +0300, Алексей Турбин wrote: AT> С помощью автоматики убедиться в "стабильности", надежности и AT> работоспособности очень сложно. Автоматика может проверять лишь AT> некоторые заранее известные формальные условия. Да. AT> Но не всё так безнадёжно. Во-первых, формальные условия в значительной AT> степени отражают некоторые важные характеристики работоспособности. AT> Например, анметы означают, что какой-то пакет просто не удастся AT> установить без нарушений. А "нарушение" связано с тем что пакету AT> чего-то не хватает, и работать он не будет. Если бы анметы означали AT> что-то ещё, то просто были бы менее полезной информацией. AT> То есть существует стык между формальными условиями и содержательными AT> требованиями. И на этом стыке можно реализовать полезную автоматику. Да. AT> Во-вторых, что можно противопоставить автоматике? Только AT> квалифицированное тестирование вручную. А квалифицированные тестеры AT> которые хорошо разбираются во всякой специфике это либо сами AT> разработчики либо прикладные специалисты. Их просто не получится по AT> количеству и по времени запрячь в какое-то предварительное тестирование AT> перед выкладываением пакетов в сизиф. Можно через какое-то время AT> надеяться на feedback. А автоматика работает достаточно быстро, AT> и её легко запрячь на проверку предварительных условий. Еще ее можно запрячь на действия по событиям от пользователей. Т.е. баг в багтрекере -- тоже ценная информация. >> Хорошо бы анонс видеть _за некоторое время_ до изменения. А не "все >> сломали давайте чинить". AT> Ну а зачем всё сломать а потом давайте всё чинить? Спроси это у тех кто так поступает :) >> Поясняю -- я теперь стараюсь держать у себя срез 5.0 за определенное >> время. Потому как я месяц готовил дистр под клиента к релизу, и за два дня >> до этого самого релиза оказалось что разломали нафиг alterator-lilo, >> datetime. При этом где-то несовместимые изменения (лечится обновлением >> профиля), а где-то -- страшные баги, уровня "это даже не пытались >> запустить". И это -- в стабильном бранче. AT> Ну я и говорю что стабильность это скорее демагогия. Она вроде бы AT> поддерживается на плохо формализуемом конвенциональном принципе "в AT> бранчи не следует заливать экспериментальный софт". Но его туда всё AT> равно заливают. Потому что каждый думает, что его пакет хороший и в AT> проблемах не виноват. Что тогда даёт этот бранч? Если все эти AT> конвенциональные соображения трудно сформулировать и трудно проверить. Вот о том и речь, что сейчас бранч -- это непонятно чем отличающееся от Сизифа добро. >> Мне этот эксперимент с использованием инсталлера в работе стоил очень >> много нервов. AT> И что тогда можно придумать, чтобы всем было хорошо? AT> Если в бранче оказался такой же кривоватый инсталлер как в сизифе. То что он оказался в Сизифе -- нормально. Но в бранч он должен попасть только после прохождения тестирования в Сизифе. >> Некоторые вещи можно тестировать автоматически и по поводу предсказуемости >> обновлений. Для этого нужна полная история всех пакетов, включая их >> зависимости и содержащиеся в них файлы. Целый ряд стандартных проблем при >> обновлении этим решается. AT> И какого же рода вещи таким образом можно протестировать? И важно AT> чтобы проверка не лажалась, то есть чтобы уровень false positives был AT> не больше 0.1%. Иначе мы просто будем зарубать нормальные пакеты. Например -- пересечения по файлам между пакетами и отсутствие при этом конфликтов на уровне rpm. Сейчас это проверяется repocop'ом, но это не проверяется с учетом _истории_ пакета. >> Другой пласт решается тем самым предлагаемым мной полиси на тему "если >> изменился soname -- поменяйте имя пакета, и не создавайте, пожалуйста, >> геморроя пользователю". AT> Такого рода прикладную логику как раз реализовать несколько легче. AT> Но и тут есть некоторые проблемы. Нельзя четко отделить системные AT> библиотеки от как бы вспомогательных библиотек. Если у вспомогательной AT> библиотеки меняется сонейм, и у этой библиотеки среди пакетов всего AT> два-три клиента, тогда имя пакета можно не менять. А если у библиотеки AT> 100 или более клиентов, тогда менять имя пакета нужно практически AT> безусловно. А четкого критерия нет. Есть случае когда точно менять можно -- если все пакеты которые requires этот soname собираются из того же srpm. Есть случаи когда точно менять нельзя -- если пакеты которые requires собираются разными мантейнерами (что говорит о том, что это разные проекты которые люди могут хотеть обновлять неодновременно). >> Именно такая протестированность и нужна. То есть не просто "Вася Пупкин >> взял и поигрался". А "некто поставил и пользуется в своей работе этим >> пакетом, и при этом количество мата в адрес этой сборки пакета меньше чем >> количество мата в адрес предыдущей сборки пакета". AT> Возможна ли такая протестированность в предварительном режиме, перед AT> тем, как пакеты попадают в Сизиф? У нас как процесс устроен: AT> предварительное тестирование, попадание пакета в сизиф, дальше широкое AT> тестирование (всем миром). Вопрос в том что можно сделать на первой AT> стадии за конечное время. Ответ в том что тут впрягается автоматика AT> которая отлавливает грубые нарушения. Увы нет. Эти тесты должны проходить когда пакет уже в Сизифе или любом другом публичном репозитории. >> Вещи которые может сделать обезъяна должен делать робот. AT> Не всегда. Графические приложения сложно протестировать автоматически, AT> даже на минимальном уровне. Иксовый протокол очень дубовый. Грубо AT> говоря, можно лишь передавать нажатия клавиш в окно, и больше сделать AT> ничего нельзя. Всякие там объекты, меню и т.п. существуют уже на уровне AT> тулкитов. :( -- С уважением, Денис http://freesource.info ----------------------------------------------------------------------------