[devel] I: gyle --test-only by default

[Anton Farygin]

21.03.2019 10:59, Andrey Savchenko пишет:
> On Thu, 21 Mar 2019 07:50:43 +0300 Anton Farygin wrote:
>> 20.03.2019 16:14, Igor Vlasenko пишет:
>>> On Wed, Mar 20, 2019 at 04:08:07PM +0400, Sergey Afonin wrote:
>>>> On Wednesday 20 March 2019, Igor Vlasenko wrote:
>>>>
>>>>> А "влияние" ?
>>>>> Сколько я видел ненужных и бесполезных AVAITING 1.12, AVAITING 1.18 ...
>>>>    
>>>> Тут момент такой, что если задание не будет задержано другим заданием
>>>> _этого_же_  мантейнера, вероятность того, что кто-то успеет повлиять
>>>> очень сильно уменьшается. Я только об этом. В качестве примера, цепочка
>>>> из POSTPONED даже сейчас, если ничего больше не делать, соберётся заметно
>>>> быстрее.
>>> Это вы альтернатив не распробовали.
>>> Я вот разбалован хорошим, и для меня это "быстрее"
>>> звучит как 700 лет пройдет быстрее, чем 1000.
>>> Для сравнения, я сегодня обновлял autoimports/cpanbuilder.
>> Игорь, проблема автоматических пакетов в том, что неизвестно, какие
>> изменения в них идут с апстримов и неизвестно, какое влияние они окажут
>> на систему в целом.
>> Неизвестно это ровно до того момента, пока данный пакет не будет
>> установлен в живую систему пользователя и проверен в интеграции с
>> окружением.
>>
>>
>> Нам от такой автоматизации как у нас надо уходить к системе, в которой
>> после сборки каждого пакета запускаются интеграционные и функциональные
>> тесты, не дающие сборочнице выполнить коммит до того момента, пока
>> ошибки выполнения этих тестов не будут исправлены ментейнером (или его
>> скриптами).
>>
>> Да, это заметно снизит скорость прохождения автоматически собранных
>> пакетов в репозиторий, но при этом так же заметно повысит качество
>> результата.
>>
>> Для примера - можно посмотреть схему принятия изменений в такие проекты
>> как LibreOffice или FreeIPA.
>>
>> Да, часто можно уповать на разработанные апстримом тесты, но во многих
>> случаях такого тестирования недостаточно и требуется проверка на
>> функционирование пакета в составе более серьёзного стенда.
>>
>> Грубо говоря - цена ошибки, пойманной на стороне сборочницы намного ниже
>> цены ошибки, пойманной ручным тестированием дистрибутива у нас или, что
>> ещё хуже - на стороне пользователя.
> Это можно реализовать лишь точечно для наиболее важных пакетов.
> Если проводить такую политику для всех пакетов в репозитории, то
> или разработка встанет (что будет ещё хуже для пользователей —
> у них просто не будет новых версий), или количество пакетов
> в репозитории сократится до 300.

Базовые проверки можно делать для всех.

Например, так можно было бы поймать проблему с сегодняшним dist-upgrade.