From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: ALT Linux Team development discussions , Igor Vlasenko References: <85241227-de96-235f-fb40-8c6aa64fa023@altlinux.org> <201903201434.21462.asy@altlinux.org> <20190320105556.GA12131@dad.imath.kiev.ua> <201903201608.07642.asy@altlinux.org> <20190320131406.GA24790@dad.imath.kiev.ua> From: Anton Farygin Organization: BaseALT Message-ID: <144378c8-e8be-6aff-7f7c-26a317db8432@basealt.ru> Date: Thu, 21 Mar 2019 07:50:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <20190320131406.GA24790@dad.imath.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [devel] I: gyle --test-only by default X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 04:50:44 -0000 Archived-At: List-Archive: List-Post: 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. Да, часто можно уповать на разработанные апстримом тесты, но во многих случаях такого тестирования недостаточно и требуется проверка на функционирование пакета в составе более серьёзного стенда. Грубо говоря - цена ошибки, пойманной на стороне сборочницы намного ниже цены ошибки, пойманной ручным тестированием дистрибутива у нас или, что ещё хуже - на стороне пользователя.