From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: devel@lists.altlinux.org References: <20191014215312.GA1422683@portlab> <389be035-2465-8c54-5cb3-93eadbc94267@basealt.ru> <20191015061954.GA2061077@portlab> <20191015073206.GH18867@imap.altlinux.org> <194fdb47-10a6-42d1-467c-f6ddd77b6638@basealt.ru> <20191015190620.GA2576259@portlab> <5d39f15d-bef4-0799-2f03-357763d76ab4@basealt.ru> <20191018004029.GB170066@portlab> <2b3d1d0c-96e3-22e9-93a4-8192ff302dca@basealt.ru> <20191018174358.GB625811@portlab> From: Anton Farygin X-Opacus-Archived: none Organization: BaseALT Message-ID: <6340d87b-ed4a-ef28-e0e7-b62623855484@basealt.ru> Date: Sat, 19 Oct 2019 08:16:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191018174358.GB625811@portlab> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [devel] [I] rpm-build-vm: vm-run 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: Sat, 19 Oct 2019 05:16:59 -0000 Archived-At: List-Archive: List-Post: On 18.10.2019 20:43, Vladimir D. Seleznev wrote: > On Fri, Oct 18, 2019 at 07:48:30AM +0300, Anton Farygin wrote: >> On 18.10.2019 3:40, Vladimir D. Seleznev wrote: >>> On Wed, Oct 16, 2019 at 08:05:51AM +0300, Anton Farygin wrote: >>>> On 15.10.2019 22:06, Vladimir D. Seleznev wrote: >>>>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote: >>>>>> On 15.10.2019 10:32, Michael Shigorin wrote: >>>>>>> Зачем это тащить в hasher, особенно если на сборочнице? >>>>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты. >>>>>> Есть цель сделать автоматическое тестирование воспроизводимым образом и >>>>>> сразу в процессе сборки пакета. >>>>> Если воспроизводимым образом, то прокидывать репозитории в сборочную >>>>> среду не нужно: все требуемые пакеты нужно указать в BuildRequires. >>>>> >>>>> Тестирование пакетов — это безусловно важно, однако нет задачи проводить >>>>> всеобъемлющее тестирование всевозможного поведения каждого пакета. От >>>>> репозитория пакетов программного обеспечения в первую очередь ожидают >>>>> других качеств: корректную доставку программного обеспечения, >>>>> т.е. корректную установку пакетов, удаление и бесшовного обновления, >>>>> консистентность самого репозитория. Консистентность репозитория по >>>>> большей части у нас проверяется сборочной системой, корректность >>>>> установки также тестируется в процессе сборки. Тестировать корректность >>>>> обновления сложнее, и тут уже больше требуется внимательность и >>>>> ответственность мейнтейнеров пакетов. >>>> Тестирование консистентности установки в нашей сборочнице явно не >>>> покрывает тех сложных случаев, когда пакетная база обновляемой системы >>>> ощутимо влияет на  инструменты обновления. >>> Поэтому я и написал по большей части, а тестирование обновляемости >>> сборочницой вообще не проводится. >> Именно, и в этом месте чаще всего взрывается. > Я не спорю, наоборот: я изначально написал, что именно это и надо лучше > тестировать. Но это не задача сборочницы. Более того, практически > невозможно формализовать автоматическое тестирование такого на стороне > сборочницы. Почему ? Очень даже хорошо формализуется. > >>> [...] >>> Тестировать apt, конечно же, нужно, но не в самом сборочном задании. >> Я не вижу причин это делать не в сборочном задании. И не только apt. > Сборочница для этого не предназначена. Ну это же не проблема. > >>>>> [...] >>>> Я не знаю дистрибутивов Linux, в которых замораживается 100% версий >>>> стабильного дистрибутива и идёт только бэкпорт патчей. >>> Вроде бы по крайней мере раньше Debian делал очень близкое к этому, но >>> опять-таки, я не говорю про 100% пакетов. >> Не 100% пакетов у нас часто замораживаются даже между стабильными >> релизами. Это не показатель. > Эти "не 100% пакетов" — о-малое, не надо переиначивать мою мысль. Если > называете бранчи стабильными, то нужно, чтобы они были стабильными. Тогда надо начинать с описания формулы стабильности бранча. Т.е. - каких целей мы хотим достигнуть в "стабильности" ?