Re: [devel] ACL in branches

["Денис Смирнов" <mithraen@altlinux.ru>]

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

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
----------------------------------------------------------------------------

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