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

[Aleksey Novodvorsky]

Андрей,
инициатива наказуема. :)
Представьте план-проспект работ, за которые Вы могли бы взяться, с
описанием светлого будущего по завершении.


Rgrds, Алексей

чт, 21 марта 2019 г., 10:59 Andrey Savchenko <bircoph на altlinux.org>:

> 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
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20190321/61116626/attachment.html>