[devel] I: gyle --test-only by default
Andrey Savchenko
bircoph на altlinux.org
Чт Мар 21 10:59:40 MSK 2019
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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : отсутствует
Тип : application/pgp-signature
Размер : 833 байтов
Описание: отсутствует
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20190321/3b8a87ff/attachment.bin>
Подробная информация о списке рассылки Devel