Re: [devel] ACL in branches

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 6343 bytes --]

On Fri, Mar 06, 2009 at 07:19:46PM +0300, Денис Смирнов wrote:
> >> Это плохо. Для выпуска дистрибутивов нужна стабильность.
> AT> Стабильность -- это демагогия.
> AT> Впрочем, когда это понятие уточняют, как сейчас, то есть о чем говорить.
> 
> Сферической стабильности в вакууме на коде сложнее hello world добиться
> вообще очень сложно. Но можно убедиться что с большой степенью вероятности
> уровень надежности удовлетворительный (перевожу -- админа за apt-get
> install этого пакета не уволят).

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

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

То есть существует стык между формальными условиями и содержательными
требованиями.  И на этом стыке можно реализовать полезную автоматику.

Во-вторых, что можно противопоставить автоматике?  Только
квалифицированное тестирование вручную.  А квалифицированные тестеры
которые хорошо разбираются во всякой специфике это либо сами
разработчики либо прикладные специалисты.  Их просто не получится по
количеству и по времени запрячь в какое-то предварительное тестирование
перед выкладываением пакетов в сизиф.  Можно через какое-то время
надеяться на feedback.  А автоматика работает достаточно быстро,
и её легко запрячь на проверку предварительных условий.

> AT> С одной стороны, никто никому не мешает писать анонсы.  Мейнтейнерам
> AT> надо взять за правило, что при любых глобальных/ значительных изменениях
> AT> надо писать в sisyphus (если это касается в основном пользователей), а
> AT> также в devel (если это касается и разработчиков).
> 
> Хорошо бы анонс видеть _за некоторое время_ до изменения. А не "все
> сломали давайте чинить".

Ну а зачем всё сломать а потом давайте всё чинить?

> Поясняю -- я теперь стараюсь держать у себя срез 5.0 за определенное
> время. Потому как я месяц готовил дистр под клиента к релизу, и за два дня
> до этого самого релиза оказалось что разломали нафиг alterator-lilo,
> datetime. При этом где-то несовместимые изменения (лечится обновлением
> профиля), а где-то -- страшные баги, уровня "это даже не пытались
> запустить". И это -- в стабильном бранче.

Ну я и говорю что стабильность это скорее демагогия.  Она вроде бы
поддерживается на плохо формализуемом конвенциональном принципе "в
бранчи не следует заливать экспериментальный софт".  Но его туда всё
равно заливают.  Потому что каждый думает, что его пакет хороший и в
проблемах не виноват.  Что тогда даёт этот бранч?  Если все эти
конвенциональные соображения трудно сформулировать и трудно проверить.

> Мне этот эксперимент с использованием инсталлера в работе стоил очень
> много нервов.

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

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

И какого же рода вещи таким образом можно протестировать?  И важно
чтобы проверка не лажалась, то есть чтобы уровень false positives был
не больше 0.1%.  Иначе мы просто будем зарубать нормальные пакеты.

> Другой пласт решается тем самым предлагаемым мной полиси на тему "если
> изменился soname -- поменяйте имя пакета, и не создавайте, пожалуйста,
> геморроя пользователю".

Такого рода прикладную логику как раз реализовать несколько легче.
Но и тут есть некоторые проблемы.  Нельзя четко отделить системные
библиотеки от как бы вспомогательных библиотек.  Если у вспомогательной
библиотеки меняется сонейм, и у этой библиотеки среди пакетов всего
два-три клиента, тогда имя пакета можно не менять.  А если у библиотеки
100 или более клиентов, тогда менять имя пакета нужно практически
безусловно.  А четкого критерия нет.

> >> - ручная протестированность;
> AT> Что такое ручная протестированность?  Есть смысл что-то тестировать
> AT> вручную когда есть рельные специфические задачи и когда человек
> AT> заинтересован и понимает что там к чему происходит.
> 
> Именно такая протестированность и нужна. То есть не просто "Вася Пупкин
> взял и поигрался". А "некто поставил и пользуется в своей работе этим
> пакетом, и при этом количество мата в адрес этой сборки пакета меньше чем
> количество мата в адрес предыдущей сборки пакета".

Возможна ли такая протестированность в предварительном режиме, перед
тем, как пакеты попадают в Сизиф?  У нас как процесс устроен:
предварительное тестирование, попадание пакета в сизиф, дальше широкое
тестирование (всем миром).  Вопрос в том что можно сделать на первой
стадии за конечное время.  Ответ в том что тут впрягается автоматика
которая отлавливает грубые нарушения.

> AT> А если сидит один человек и вручную тестирует всё сразу, то это имеет
> AT> мало смысла.  Это человек это получается такая умная обезьяна.  Обезьяна
> AT> сможет поверхностно убедиться в работоспособности лишь небольшого числа
> AT> вещей, которые на виду.
> 
> Вещи которые может сделать обезъяна должен делать робот.

Не всегда.  Графические приложения сложно протестировать автоматически,
даже на минимальном уровне.  Иксовый протокол очень дубовый.  Грубо
говоря, можно лишь передавать нажатия клавиш в окно, и больше сделать
ничего нельзя.  Всякие там объекты, меню и т.п. существуют уже на уровне
тулкитов.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]