[devel] ACL in branches

[Dmitriy M. Maslennikov]

3 марта 2009 г. 21:47 пользователь Alexey Tourbin <at на altlinux.ru> написал:
> Он сегодня у них заработал, а завтра они сделали dist-upgrade и у них
> всё отвалилось.  При том, что вроде бы ничего специфического у них не
> обновилось.  Вы всё ещё не понимаете, что в момент сборки пакета
> существовала специфическая build-time комбинация потенциально влияющих
> компонентов; а в момент запуска существует уже иная специфическая
> runtime комбинация влияющих компонентов?
Следовательно те компоненты, которые портят работоспособность других
после обновления не пройдут тестирование. Скажем так, если у меня есть
работающий apache, а завтра вышло обновление openssl, которое его
ломает, то вероятность, что за месяц это заметять и повесят баг на
openssl довольно высока. В этом случае такое плохое обновление не
должно попасть в стабильный бранч, что всем и надо. Сейчас же в бранч
попадет, что угодно, лишь бы удовлетворяло довольно слабым (но тем не
менее весьма полезным) проверкам, лишь бы не поломалась обновляемость.
А у мне сервера не гарантированно обновлять надо, а надо, чтобы они
работали. Вот и думай, что лучше - критическая уязвимость в openssl
или никем не проверенное обновление, которое, спасибо конечно,
гарантированно произойдет, но вот заработает ли то, что обновилось -
это дело десятое, ведь математически работоспособность проверить
нельзя, так и пытаться не стоит по вашем рассуждениям.

> Вам кажется что если админы протестировали то это уже стопудово
> как минимум на месяц или два?
Если они будут тестировать все обновления, то навсегда.

> Мне тогда не понятно, что именно Вы хотите протестировать.
Что следующая партия пакетов, которая попадет в бранч ничего там не
ломает, по крайней мере, что экстплуатация этого хозяйства на
некритических станциях в течение некоторого времени проблем не
выявила. Все-таки это лучше, чем ничего.

>> Постулат: установка и эксплуатация пакета в течение месяца на 50
>> рабочих станциях гарантированно выявляет не меньше ошибок, чем все
>> наши автоматические тесты. Кроме того, сочетание двух методик
>> (автоматическое и ручное тестирование добровольцами) математически
>> точно выявляет не меньше ошибок, чем одно только автоматическое
>> тестирование.
>
> Тестируйте вручную, как я Вам сказал.
> Лушче ничего не будет.
Только один я протестировать все не могу. А тестировать всем
сообществом не получается: пакеты попадают в основные репозитарии
сразу после сборки. Сейчас пакеты тестироет только мантейнер у себя.
Зачастую невнимательно и недолго. Некоторый отстойник для тестирования
кандидатов на поступление в репозитарий был бы очень уместен. Кроме
того, как уже писалось в эту рассылку это не портит вашей идеи о
атомарной операции сборки-выкладывания пакета, если после тестовой
сборки пакета сохранить его сборочную среду, а перед выкладыванием
произвести пересборку и убедиться, что она не изменилась за время
тестирования - иначе пересборка и повторное тестирование.

-- 
Dmitriy M. Maslennikov
rlz на etersoft.ru
rlz на altlinux.org
maslennikovdm на gmail.com
master на armory.ru