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

[Andrey Savchenko <bircoph@altlinux.org>]

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

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.

Best regards,
Andrew Savchenko

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