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

[Dmitry V. Levin]

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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 801 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20180220/2758c6c7/attachment.bin>