[devel] Параллельная сборочница. Алгоритмы.

[devel] Параллельная сборочница. Алгоритмы.

[Igor Vlasenko]

Господа!

Вместо экстремистских призывов не выкладывать пакеты в Сизиф,
предлагаю все же обратить внимание на сборочницу.

Сборочница и сейчас тормозит, а с учетом
скорого включения arm ее скорость еще упадет.

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


Итак, 
Параллельная сборочница.

----
Обозначения.
Tb (build time) - время, потраченное на сборку 
Tt (testing time) - время, потраченное на тестирование
Tm (merge time) - время, потраченное на интеграцию в репозиторий.

Однопоточная сборочница.

По порядку транзакций собираем пакеты, проверяем, сливаем в репозиторий.
По дизайну производительность такой сборочницы ограничена
1/(среднее(Tb+Tt)+Tm) транзакций за единицу времени.
Далее ускорить ее могут только вложения в железо, дающие diminishing
return на затраченные суммы.

Сборочница с параллельной сборкой и последовательной интеграцией.

Пример реализации - girar.
Если у нас много потоков выполнения, сборку и тестирование (часть) можно
вынести в параллельные потоки выполнения.
Соответственно, к окончанию интеграции одной транзакции уже должна
найтись собранная и проверенная другая транзакция, соответственно,
масксимальная скорость работы такой сборочницы 1/Tm.

Отсюда сразу ряд рецептов как можно ускорить наш girar --
выбросить из Tm (merge time) все лишнее.

* Вынести все тесты в сборочные процессы.

некоторые из них придется повторить на этапе merge,
чтобы обеспечить целостность репозитория,
но раз они будут выполнены повторно на той же транзакции,
то существенную часть данных для тестов можно закешировать в
сборочно-тестировочных потоках выполнения и повторно использовать,
чтобы не затягивать Tm

* Выбросить планировщик в отдельный процесс выполнения.
Пусть берет AVAITING и раздает сборочным потокам.
а сборочно-тестировочные потоки пусть переводят транзакцию
либо в статус FAILED, либо в статус BUILT(TESTED?)
(добавить статус).
А процесс, занятый выполнением мержа, будет брать из очереди
транзакции в статусе BUILT(TESTED?) и мержить.

* Выбросить из мержа все тесты, не связанные с поддержанием
  целостности репозитория.
Предлагаю оставить
** (кешированный) тест на наследование
** (кешированный) тест на символы в бинарниках
** тест на unmets

Все это может ускорить производительность в несколько раз.

Однако все это паллатив.
Из Tm (merge time) не выкинуть перегенерацию индексов и проверку на unmets,
которые в зависимости от железа занимают 20-40 сек.
что дает верхний теоретический потолок производительности
сборочницы с последовательной интеграцией
в 2000-3000 транзакций в сутки.
По сравнению с текущими (500?) транзакций в сутки
это хорошо, тем, что и в старой схеме есть куда расти,

однако за счет смены алгоритма работы сборочницы можно
добиться гораздо большего.

Параллельная сборочница.

Прототип параллельной сборочницы я реализовал для себя в autorepo-scripts.

Какой основной недостаток сборочницы с последовательной интеграцией?
Ее скорость принудительно ограничена скоростью шага интеграции.
Соответственно, она плохо распараллеливается. Добавляя аппаратный
ресурс для параллельных сборочно-тестировочных процессов (ПСБП)
выше определенного числа, мы не получим прирост в скорости.

В сегодняшнем girar лишние ПСБП либо простаивают, либо по нескольку раз
пересобирают транзакцию, пока наконец подойдет
ее очередь для интеграции. 
В оптимизированном рецептами выше girar при увеличении ПСБП
лишние ПСБП только простаивают.
Транзакции быстро пройдут фазы сборки и тестирования,
но явно встанут в очередь на интеграцию.

Сейчас в процессорах ядер как грязи. Как это использовать?
Чтобы не создавать пробку для ПСБП, мерж тоже нужно
делать параллельно.
Другими словами, не интегрировать из очереди на мерж
по одной транзакции,
а объединять все транзакции, накопившиеся к этому времени в очереди на
мерж, в одну мега-транзакцию, которую и пытаться интегрировать.
Дополнительная сложность здесь в алгоритме обработке ситуации, когда
мерж мега-транзакции не удался, но там тоже ничего заумного (см. далее).

Преимущество же --- полностью загруженные ПСБП и почти линейная
масштабируемость на независимых транзакциях.
Масксимальная скорость работы такой сборочницы уже не 1/Tm,
а пропорциональна (количество ПСБП)/Tm.

К примеру, ту же мегатранзакцию на удаление python*setuptools-tests,
которую наш girar обрабатывал трое суток,
girar на 128 ядрах (сервер на 4 процессора по 32 ядра) обработал бы
за 15 минут,
а на 256 ядрах --- еще быстрее, но, естественно, не быстрее, чем
сборка и тестирвание самого медленного пакета из мегатранзакции.
Я уже писал, что на altair на 32 ядрах удавалось получить на
прототипе скорость в 50.000 транзакций в сутки.

Вот что дает разница в алгоритмах на том же железе.

Алгоритм обработки ситуации, когда
мерж мега-транзакции не удался, тоже не так сложен.
Я предполагаю, что мы уже выбросили из мержа все тесты,
не связанные с поддержанием целостности репозитория.
Я предлагал оставить
* тест на наследование
* тест на символы в бинарниках
* тест на unmets

исключение по тесту на наследование просто,
там кто первый встал, того и тапки, остальные транзакции в FAILED.
с тестом на unmets и тестом на символы в бинарниках есть два пути
(можно совместить).
Либо генерировать в ПСБП доп. кеши по транзакциям,
по которым разбирать, какие транзакции вызвали проблемы,
и отправлять их на пересборку (желательно по итогам
прописывать зависимости (аналог task deps)
еще желательно, чтобы планировщик FAIL'ил циклические зависимости)

либо (или как fallback)
искать сбойную транзакцию методом половинного деления:

Накопилось в очереди на мерж от ПСБП 128 транзакций -
не получилось смержить 128 -- мержим 64, 32, 16 ...
опять же метод половинного деления можно распараллелить,
если под рукой много ядер.
Сразу пускаем log_2(N)+1 процессов
(в примере --- на мерж уйдет 8 ядер -- пытаемся смержить
128, 64, 32, 16, 8, 4, 2, 1 транзакцию, и называем
следующим репозиторием самый крупный мерж из удавшихся).

К слову, поскольку пакеты перед мега-мержем проходят независимую
проверку в ПСБП, то чтобы мега-мерж не сошелся со второй попытки
(после выноса unmets), надо постараться.

В autoimports я с таким сталкивался раза 2 или 3 за всю жизнь.
Так что можно ожидать, что очередей в incoming больше ек будет,
кроме последовательностей, вызванных необходимостью порядка сборки.


-- 

I V

Re: [devel] Задачи для сборочницы следующего поколения (was: Параллельная сборочница. Алгоритмы.)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 4126 bytes --]

On Fri, Feb 16, 2018 at 12:33:20AM +0200, Igor Vlasenko wrote:
> Господа!
> 
> Вместо экстремистских призывов не выкладывать пакеты в Сизиф,

Попрошу воздержаться от развешивания ярлыков.

Очевидно, что публиковать якобы новые сборки пакетов, в которых
ничего не меняется, не просто не нужно, но и вредно.

Слепо пересобирать чужие сборки из-за записи в %changelog'е вида
- Rebuilt for https://fedoraproject.org/wiki/Fedora_NN_Mass_Rebuild
не просто не нужно, но и вредно.

> предлагаю все же обратить внимание на сборочницу.
> 
> Сборочница и сейчас тормозит, а с учетом
> скорого включения arm ее скорость еще упадет.

girar разрабатывался лет 9 назад для решения задач, которые были тогда
актуальны, на том оборудовании, которое было доступно в то время.

Очевидно, что сейчас мы хотим решать более ресурсоёмкие задачи, и можем
рассчитывать на доступность более производительного оборудования.

> Хочу вынести на обсуждение, как можно без вложений в железо
> добиться существенного увеличения скорости работы
> нашей сборочницы путем оптимизации ее алгоритмов.

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

Вряд ли мы хотим решать задачу принимать в Сизиф 60*60*24/2==43200
транзакций в сутки (в среднем по 2 секунды на транзакцию), это число
более чем в 2 раза превышает число исходных пакетов в нынешнем Сизифе.
Такая задача сама по себе не выглядит осмысленной.

Одна из задач, которую мы хотели решать ещё 9 лет назад - оперативно
выявлять регрессии собираемости/устанавливаемости пакетов репозитория
и на этом основании (полу)автоматически принимать решения об окончательном
коммите транзакций.

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

Нам нужен инструмент оперативного создания новых бранчей под разные задачи,
см. напр. https://bugzilla.altlinux.org/show_bug.cgi?id=23935

Нам нужен инструмент создания и обслуживания репозиториев-дополнений
к базовым репозиториям, включая автоматическую пересборку дополнений
по мере обновления базовых репозиториев,
см. напр. https://bugzilla.altlinux.org/show_bug.cgi?id=23936

Далее несколько комментариев про оборудование и алгоритмы применения
транзакций.

[...]
> Сейчас в процессорах ядер как грязи.

Не стоит преувеличивать.  В более-менее доступных серверных процессорах,
работающих на более-менее разумных частотах, сейчас около 32 ядер на
сервер (если не считать ht).

Разумеется, серверов может быть много, но для того, чтобы от этого была
польза, архитектура сборочной системы должна предусматривать
масштабирование стадии интеграции транзакций на множество серверов.

> Как это использовать?
> Чтобы не создавать пробку для ПСБП, мерж тоже нужно
> делать параллельно.
> Другими словами, не интегрировать из очереди на мерж
> по одной транзакции,
> а объединять все транзакции, накопившиеся к этому времени в очереди на
> мерж, в одну мега-транзакцию, которую и пытаться интегрировать.
> Дополнительная сложность здесь в алгоритме обработке ситуации, когда
> мерж мега-транзакции не удался, но там тоже ничего заумного (см. далее).

Наша традиционная сборочная система обладает следующим полезным свойством:
каждое следующее состояние репозитория получается в результате применения
транзакции к предыдущему состоянию.

Такой детерминизм позволяет воспроизводимо получать новое состояние
репозитория из старого путём последовательного применения транзакций.

Это свойство полезно для реализации вторичных догоняющих сборочных систем
для медленных архитектур.

К чему привело бы применение нескольких транзакций одновременно?  В общем
случае к тому, что результат применения отличался бы от результата
последовательного применения.  Не лучше ли вместо этого (спекулятивно)
объединять множество транзакций, готовых к применению, в полноценные
мега-транзакции, обрабатываемые как обычные транзакции?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Задачи для сборочницы следующего поколения (was: Параллельная сборочница. Алгоритмы.)

[Igor Vlasenko]

On Fri, Feb 16, 2018 at 04:33:23AM +0300, Dmitry V. Levin wrote:
[...]

> girar разрабатывался лет 9 назад для решения задач, которые были тогда
> актуальны, на том оборудовании, которое было доступно в то время.
> 
> Очевидно, что сейчас мы хотим решать более ресурсоёмкие задачи, и можем
> рассчитывать на доступность более производительного оборудования.
На этом бы и хотелось сосредоточить обсуждение.
 
Дмитрий,
Большое спасибо за обстоятельное письмо.
В вашем письме вы подняли сразу несколько важных тем,
Сразу ответить на все затронутые вопросы не получится,
поэтому попробую писать по письму на каждую тему.

Заранее прошу прощения за медлительнось,
письмо на тему о сборочнице я обдумывал три недели,
и то результаты пошли в devel@ с интервалом в неделю.
https://lists.altlinux.org/pipermail/devel/2018-February/203907.html
https://lists.altlinux.org/pipermail/devel/2018-February/203923.html

Продолжение отдельным письмом.

-- 

I V

Re: [devel] Задачи для сборочницы следующего поколения (was: Параллельная сборочница. Алгоритмы.)

[Igor Vlasenko]

On Fri, Feb 16, 2018 at 04:33:23AM +0300, Dmitry V. Levin wrote:

Хотел бы начать с этого, как наиболее важного.

> Наша традиционная сборочная система обладает следующим полезным свойством:
> каждое следующее состояние репозитория получается в результате применения
> транзакции к предыдущему состоянию.
>
> Такой детерминизм позволяет воспроизводимо получать новое состояние
> репозитория из старого путём последовательного применения транзакций.
> 
> Это свойство полезно для реализации вторичных догоняющих сборочных систем
> для медленных архитектур.
  
Хотел бы отметить, что параллельная сборочница, описанная ранее,
так же обладает воспроизводимым детерминизмом.
И алгоритм воспроизводимого получения нового состояния
репозитория из старого не настолько сложнее.
Последовательность репозиториев R_i восстанавливается по начальному
репозиторию R_0, последовательности транзакций T_j и
последовательности операций
MERGE_l( BuildTest(R_{l_1},T_{l_1}),..., BuildTest(R_{l_k},T_{l_k}))

> К чему привело бы применение нескольких транзакций одновременно?  В общем
> случае к тому, что результат применения отличался бы от результата
> последовательного применения.  

А к чему приводит применение нескольких транзакций последовательно?
В общем случае к тому, что результат применения отличается, в
зависимости от случайного выбора сборочницы.
Например, я залил транзакции 111222 и 111221.
Последовательная сборочница может смержить сначала 111222, потом
111221, может сначала 111221, потом 111222.
Параллельная еще добавляет 3-й вариант - 111222 и 111221 в одном
мерже.

Теоретически все три варианта могут отличаться. На практике так бывает
настолько редко, что проще либо пренебречь совсем, либо реализовать
постсборочное тестирование, чтобы не тормозить сотни тысяч ради одного.

> Не лучше ли вместо этого (спекулятивно)
> объединять множество транзакций, готовых к применению, в полноценные
> мега-транзакции, обрабатываемые как обычные транзакции?

"мега-транзакции" нельзя обрабатывать как обычные транзакции.
Иначе ими никто пользоваться не будет.
Отличие "мега-транзакций" в том, что несборка части ее пакетов
не блокирует мерж удачно собравшихся.
В транзакции наоборот, несборка хоть одного пакета FAILит всю транзакцию.

Т.е. внедрение их поддержки в сборчницу было бы хорошим, полезным шагом.
Но, думаю, ровно столько же усилий понадобилось бы и для реализации
параллельной сборочницы внутри. Параллельная сборочница --- это те же
"мега-транзакции", но включеные по умолчанию и прозрачно для пользователя.

-- 

I V

Re: [devel] Задачи для сборочницы следующего поколения (was: Параллельная сборочница. Алгоритмы.)

[Igor Vlasenko]

On Fri, Feb 16, 2018 at 04:33:23AM +0300, Dmitry V. Levin wrote:
> Предлагаю начинать разговор не с алгоритмов оптимизации сборочницы,
> а с задач, которые мы хотим решать с помощью сборочной системы
> следующего поколения.
 
[...]

Надо еще добавить модульность.
Хорошо бы выпилить внутренние интерфейсы,
при чем так,
чтобы можно было сборочные ноды использовать
параллельно со сборочницей, не конфликтуя с ней,
с меньшим приоритетом,  для других задач.

к примеру

* супербихайв: пересборка + тестирование пакетов из Сизифа,
отдача результатов в агрегатор супербихайва

* подключение к autoimports внешней сборочницы



-- 

I V

Re: [devel] Задачи для сборочницы следующего поколения

[Leonid Krivoshein]

16.02.2018 04:33, Dmitry V. Levin пишет:
> Разумеется, серверов может быть много, но для того, чтобы от этого была
> польза, архитектура сборочной системы должна предусматривать
> масштабирование стадии интеграции транзакций на множество серверов.

Предлагать изначально отталкиваться от аппаратно-зависимых фич IB/RDMA, 
наверное, архитектурно неверно. Тем не менее, это широко используется 
при создании суперкомпьютеров и HPC, которым задачи параллельной 
обработки не чужды. К тому же, на американских развалах б/у железо можно 
купить по сходной цене, например:

https://www.amazon.com/Mellanox-ConnectX-Express-InfiniBand-MHGH28-XTC/dp/B016WZU9ZW/

К тому же, вроде как хорошо дружим с Mellanox'ом.

https://www.osp.ru/os/2008/07/5478314/
https://ru.wikipedia.org/wiki/InfiniBand

Если что, мой спич был не про конкретное железо, а про алгоритмы. :)


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Параллельная сборочница. Алгоритмы.

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

On Fri, Feb 16, 2018 at 12:33:20AM +0200, Igor Vlasenko wrote:
[...]
> * Выбросить из мержа все тесты, не связанные с поддержанием
>   целостности репозитория.
> Предлагаю оставить
> ** (кешированный) тест на наследование
> ** (кешированный) тест на символы в бинарниках
> ** тест на unmets

Неочевидный выбор.  По идее, все тесты, выполняемые на новом состоянии
репозитория (после создания индексов для нового состояния репозитория) - 
это тесты на целостность репозитория.  Возьмём, например, install check.
Если его выбросить из мержа, то мы даже не протестируем устанавливаемость
собранных пакетов в том репозитории, в который мы их отправляем.

P.S. К сожалению, я сейчас вынужденно занимаюсь другой темой, из-за чего
участвовать в обсуждении сборочной системы следующего поколения могу
только эпизодически.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Параллельная сборочница. Алгоритмы.

[Igor Vlasenko]

On Sun, Feb 18, 2018 at 02:44:43AM +0300, Dmitry V. Levin wrote:
> Неочевидный выбор.  По идее, все тесты, выполняемые на новом состоянии
> репозитория (после создания индексов для нового состояния репозитория) - 
> это тесты на целостность репозитория.  Возьмём, например, install check.
> Если его выбросить из мержа, то мы даже не протестируем устанавливаемость
> собранных пакетов в том репозитории, в который мы их отправляем.

Это важный вопрос, я его попробовал осветить в отдельном письме.
 
> P.S. К сожалению, я сейчас вынужденно занимаюсь другой темой, из-за чего
> участвовать в обсуждении сборочной системы следующего поколения могу
> только эпизодически.

Понял, хорошо.
Спешить не надо, надо все хорошо обдумать.

-- 

I V

Re: [devel] Задачи для сборочницы следующего поколения

[Leonid Krivoshein]

Можно тут рядышком постоять? Иначе для чего ещё эта рассылка...


16.02.2018 04:33, Dmitry V. Levin пишет:
> Предлагаю начинать разговор не с алгоритмов оптимизации сборочницы,
> а с задач, которые мы хотим решать с помощью сборочной системы
> следующего поколения.
>
> ...
>
> Одна из задач, которую мы хотели решать ещё 9 лет назад - оперативно
> выявлять регрессии собираемости/устанавливаемости пакетов репозитория
> и на этом основании (полу)автоматически принимать решения об окончательном
> коммите транзакций.

Правильно понимаю, что полуавтоматическое принятие решения позволяет, в 
числе прочего, условно модератору репозитория откатывать мержи вручную? 
Если да, то какова (обычно) судьба всех последующих мержей, следующих за 
выкинутым(и)?

> Мы хотим не только автоматически выявлять анметы, порождаемые транзакцией,
> но и...
> Наша традиционная сборочная система обладает следующим полезным свойством:
> каждое следующее состояние репозитория получается в результате применения
> транзакции к предыдущему состоянию.
>
> Такой детерминизм позволяет воспроизводимо получать новое состояние
> репозитория из старого путём последовательного применения транзакций.
>

Для разработчиков, госадминов и регуляторов большой интерес представляет 
репозиторий с исходниками (git, .src.rpm). Для большинства конечных 
пользователей куда важнее работоспособность производного -- бинарного 
репозитория. Очень хорошо, что сборочница позволяет автоматически 
выявлять и пресекать многие проблемы "на подлёте". Но мы же понимаем, 
что выявить все проблемы автоматически нельзя. И со всеми успешно 
прошедшими тестами, случается, возникают регрессии, больше проявляющиеся 
даже не в части сборки/установки, а уже в процессе эксплуатации.

Конечно важно мерило, определяющее качество исходного репозитория, в 
целом, полученного в результате очередной (мега) транзакции. Но также 
важно иметь возможность отката отдельных изменений с автоматическим 
применением последующих изменений. Тогда фаза тестирования может 
отставать (то бишь не быть тормозящим фактором), но при необходимости, 
бить по мержу вдогонку. А все последующие (мега) транзакции в случае 
такого фейла могут быть объединены в ещё более крупную супер-(мега) 
транзакцию.

> К чему привело бы применение нескольких транзакций одновременно?  В общем
> случае к тому, что результат применения отличался бы от результата
> последовательного применения.  Не лучше ли вместо этого (спекулятивно)
> объединять множество транзакций, готовых к применению, в полноценные
> мега-транзакции, обрабатываемые как обычные транзакции?

Если одна обычная транзакция -- изменения репозитория в результате 
одобрения задания из одного и более исходных пакетов, то мега-транзакция 
-- это, если не весь репозиторий, то, по крайней мере, оба графа 
зависимостей с каждым из пакетов накопившихся к текущему моменту заданий 
(сборочными и установочными), верно?

Мне кажется, если преодолеть зависимость мержа от предыдущего мержа не в 
ущерб воспроизводимой сборке, мы как раз-таки получим параллельную 
сборочницу нового поколения. Очерёдность безусловно важна. Но ведь если 
кому-то в очереди становится плохо, очередь от этого не аннулируется.

Можно гонять сборочницу несколько раз в сутки по всем необходимым 
пакетам по мере их поступления, но публиковать только те состояния 
репозитория, при которых мерило показывает приемлемый результат. То есть 
мега-транзакция может допускать фейлы отдельных пакетов. Но такое 
состояние не публикуется, а учитывается на следующих кругах.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Задачи для сборочницы следующего поколения

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]

On Tue, Feb 20, 2018 at 03:03:55AM +0300, Leonid Krivoshein wrote:
> 16.02.2018 04:33, Dmitry V. Levin пишет:
[...]
> > Одна из задач, которую мы хотели решать ещё 9 лет назад - оперативно
> > выявлять регрессии собираемости/устанавливаемости пакетов репозитория
> > и на этом основании (полу)автоматически принимать решения об окончательном
> > коммите транзакций.
> 
> Правильно понимаю, что полуавтоматическое принятие решения позволяет, в 
> числе прочего, условно модератору репозитория откатывать мержи вручную? 
> Если да, то какова (обычно) судьба всех последующих мержей, следующих за 
> выкинутым(и)?

Автоматическая повторная обработка, в некотором смысле rebase.

> > Мы хотим не только автоматически выявлять анметы, порождаемые транзакцией,
> > но и...
> > Наша традиционная сборочная система обладает следующим полезным свойством:
> > каждое следующее состояние репозитория получается в результате применения
> > транзакции к предыдущему состоянию.
> >
> > Такой детерминизм позволяет воспроизводимо получать новое состояние
> > репозитория из старого путём последовательного применения транзакций.
> 
> Для разработчиков, госадминов и регуляторов большой интерес представляет 
> репозиторий с исходниками (git, .src.rpm). Для большинства конечных 
> пользователей куда важнее работоспособность производного -- бинарного 
> репозитория. Очень хорошо, что сборочница позволяет автоматически 
> выявлять и пресекать многие проблемы "на подлёте". Но мы же понимаем, 
> что выявить все проблемы автоматически нельзя. И со всеми успешно 
> прошедшими тестами, случается, возникают регрессии, больше проявляющиеся 
> даже не в части сборки/установки, а уже в процессе эксплуатации.
> 
> Конечно важно мерило, определяющее качество исходного репозитория, в 
> целом, полученного в результате очередной (мега) транзакции. Но также 
> важно иметь возможность отката отдельных изменений с автоматическим 
> применением последующих изменений. Тогда фаза тестирования может 
> отставать (то бишь не быть тормозящим фактором), но при необходимости, 
> бить по мержу вдогонку. А все последующие (мега) транзакции в случае 
> такого фейла могут быть объединены в ещё более крупную супер-(мега) 
> транзакцию.

В какой-то момент становится проще накатить фикс, чем откатывать
и пересобирать заново.

> > К чему привело бы применение нескольких транзакций одновременно?  В общем
> > случае к тому, что результат применения отличался бы от результата
> > последовательного применения.  Не лучше ли вместо этого (спекулятивно)
> > объединять множество транзакций, готовых к применению, в полноценные
> > мега-транзакции, обрабатываемые как обычные транзакции?
> 
> Если одна обычная транзакция -- изменения репозитория в результате 
> одобрения задания из одного и более исходных пакетов, то мега-транзакция 
> -- это, если не весь репозиторий, то, по крайней мере, оба графа 
> зависимостей с каждым из пакетов накопившихся к текущему моменту заданий 
> (сборочными и установочными), верно?

мега-транзакция -- это просто объединение нескольких транзакций, которое само
по себе тоже является транзакцией.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]