[devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 05:16:52PM +0300, Alexey Shabalin wrote:
> Локальная сборочница, как отдельный продукт - это хорошо.
> Но я не понял как она влияет на ускорение централизованной сборочницы для
> сизифа и p8,p9,...

Действительно, в зачинателе темы, письме # Мухи и котлеты: ...
https://lists.altlinux.org/pipermail/devel/2020-August/211678.html
я писал о боттлнеке в алгоритме на серверной стороне
(пример с поварами и официантками).

Тему ускорения работы именно локальной сборочницы я упомянул
в письме # incoming/girar: проблема производительности.
https://lists.altlinux.org/pipermail/devel/2020-August/211601.html
но подробно не развивал.

У меня есть несколько нароботок на эту тему.
Одна из них связана с изменениями в hasher
для повторного использования hasher's 
initroot-only workdir, при условии, если сборка
происходит относительно неизменного репозитория
(скажем, дневное зеркало Сизифа).

Вторая описана на
https://www.altlinux.org/Girar/Parallel#VII._Алгоритмы_ускорения_сборки_Больших_Транзакций.

Есть и еще наметки, но без локальной сборочницы
как их пробовать и тестировать?

> Как можно доверять результатам какой-то локальной сборочницы безоговорочно?

Как раз локальная сборочница и позволяет не слепо доверять
тому, что творится на стороне сервера, а проверять
предложенные изменения самому.

Установить страндартный пакет локальной сборочницы, 
сформировать тестовый таск, запустить на сборку, 
провести бенчмарки времени, CPU, IO.

Посмотреть патчи кандидата на улучшение сборки.
Самому убедиться, не сжульничал ли, не отключил
ли проверки. Самому собрать и установить его
код, самому получить бенчмарки нового кода
и самому убедиться, есть ли в итоге ускорение
сборочницы.

-- 

I V