[devel] ACL in branches

[Денис Смирнов]

On Tue, Mar 03, 2009 at 06:16:36PM +0300, Алексей Турбин wrote:

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

И это -- очень хорошо.

AT> Тестовая пересборка пакетов пока не реализована.  Она может брать очень
AT> много времени (=бесконечно с точки зрения наших реалий).  Можно как-то
AT> справиться и с этим.

Да, и это -- тоже очень хорошо.

>> Это плохо. Для выпуска дистрибутивов нужна стабильность.
AT> Стабильность -- это демагогия.
AT> Впрочем, когда это понятие уточняют, как сейчас, то есть о чем говорить.

Сферической стабильности в вакууме на коде сложнее hello world добиться
вообще очень сложно. Но можно убедиться что с большой степенью вероятности
уровень надежности удовлетворительный (перевожу -- админа за apt-get
install этого пакета не уволят).

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

Хорошо бы анонс видеть _за некоторое время_ до изменения. А не "все
сломали давайте чинить".

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

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

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

Некоторые вещи можно тестировать автоматически и по поводу предсказуемости
обновлений. Для этого нужна полная история всех пакетов, включая их
зависимости и содержащиеся в них файлы. Целый ряд стандартных проблем при
обновлении этим решается.

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

>> - ручная протестированность;
AT> Что такое ручная протестированность?  Есть смысл что-то тестировать
AT> вручную когда есть рельные специфические задачи и когда человек
AT> заинтересован и понимает что там к чему происходит.

Именно такая протестированность и нужна. То есть не просто "Вася Пупкин
взял и поигрался". А "некто поставил и пользуется в своей работе этим
пакетом, и при этом количество мата в адрес этой сборки пакета меньше чем
количество мата в адрес предыдущей сборки пакета".

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

Вещи которые может сделать обезъяна должен делать робот.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20090306/31cb1497/attachment.bin>