<div dir="auto">Андрей,<div dir="auto">инициатива наказуема. :)</div><div dir="auto">Представьте план-проспект работ, за которые Вы могли бы взяться, с описанием светлого будущего по завершении. </div><div dir="auto"><br></div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">Rgrds, Алексей</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 21 марта 2019 г., 10:59 Andrey Savchenko <<a href="mailto:bircoph@altlinux.org">bircoph@altlinux.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 21 Mar 2019 07:50:43 +0300 Anton Farygin wrote:<br>
> 20.03.2019 16:14, Igor Vlasenko пишет:<br>
> > On Wed, Mar 20, 2019 at 04:08:07PM +0400, Sergey Afonin wrote:<br>
> >> On Wednesday 20 March 2019, Igor Vlasenko wrote:<br>
> >><br>
> >>> А "влияние" ?<br>
> >>> Сколько я видел ненужных и бесполезных AVAITING 1.12, AVAITING 1.18 ...<br>
> >> <br>
> >> Тут момент такой, что если задание не будет задержано другим заданием<br>
> >> _этого_же_ мантейнера, вероятность того, что кто-то успеет повлиять<br>
> >> очень сильно уменьшается. Я только об этом. В качестве примера, цепочка<br>
> >> из POSTPONED даже сейчас, если ничего больше не делать, соберётся заметно<br>
> >> быстрее.<br>
> > Это вы альтернатив не распробовали.<br>
> > Я вот разбалован хорошим, и для меня это "быстрее"<br>
> > звучит как 700 лет пройдет быстрее, чем 1000.<br>
> > Для сравнения, я сегодня обновлял autoimports/cpanbuilder.<br>
> <br>
> Игорь, проблема автоматических пакетов в том, что неизвестно, какие <br>
> изменения в них идут с апстримов и неизвестно, какое влияние они окажут <br>
> на систему в целом.<br>
> Неизвестно это ровно до того момента, пока данный пакет не будет <br>
> установлен в живую систему пользователя и проверен в интеграции с <br>
> окружением.<br>
> <br>
> <br>
> Нам от такой автоматизации как у нас надо уходить к системе, в которой <br>
> после сборки каждого пакета запускаются интеграционные и функциональные <br>
> тесты, не дающие сборочнице выполнить коммит до того момента, пока <br>
> ошибки выполнения этих тестов не будут исправлены ментейнером (или его <br>
> скриптами).<br>
> <br>
> Да, это заметно снизит скорость прохождения автоматически собранных <br>
> пакетов в репозиторий, но при этом так же заметно повысит качество <br>
> результата.<br>
> <br>
> Для примера - можно посмотреть схему принятия изменений в такие проекты <br>
> как LibreOffice или FreeIPA.<br>
> <br>
> Да, часто можно уповать на разработанные апстримом тесты, но во многих <br>
> случаях такого тестирования недостаточно и требуется проверка на <br>
> функционирование пакета в составе более серьёзного стенда.<br>
> <br>
> Грубо говоря - цена ошибки, пойманной на стороне сборочницы намного ниже <br>
> цены ошибки, пойманной ручным тестированием дистрибутива у нас или, что <br>
> ещё хуже - на стороне пользователя.<br>
<br>
Это можно реализовать лишь точечно для наиболее важных пакетов.<br>
Если проводить такую политику для всех пакетов в репозитории, то<br>
или разработка встанет (что будет ещё хуже для пользователей —<br>
у них просто не будет новых версий), или количество пакетов<br>
в репозитории сократится до 300.<br>
<br>
Best regards,<br>
Andrew Savchenko<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.altlinux.org" target="_blank" rel="noreferrer">Devel@lists.altlinux.org</a><br>
<a href="https://lists.altlinux.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">https://lists.altlinux.org/mailman/listinfo/devel</a></blockquote></div>