[devel] Распараллеливание incoming.

[Igor Vlasenko <vlasenko@imath.kiev.ua>]

Несколько в сторону, по поводу incoming.

DVL> Если кому-то нужно устроить continuous integration для каких-то проектов,
DVL> то [...] сборочница вряд ли справится с такой нагрузкой.

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

Это поведение является защитой от появления unmets.
Но надо понимать, что это достаточная защита, но, на самом деле,
не необходимая.

Для многих пакетов, те же moodle*-lang-* пакеты, к примеру,
такое поведение не нужно. 
Для таких пакетов заведомо ничего страшного не случится,
если они будут собраны на позавчерашнем сизифе, проверены на устанавливаемость
на вчерашнем сизифе, включены в сегодняшний сизиф.

Почему так? Трюк здесь в том, что у этих пакетов зависимости новой версии
и старой версии не отличаются.

Поэтому для такого класса пакетов сборку можно оптимизировать.
Если мы собрали пакет, и оказалось, что 
- его requires зависимости не изменились,
то 
1) пересобирать такой пакет уже не нужно, пусть Сизиф себе обновляется,
тесты останутся релевантными.
2) если при этом на provides такого пакета нет жесткой зависимости,
вида = или =set:
то такой пакет обладает свойством, что он не мешает сборке других пакетов.
Т.е. если во время сборки другого пакета B в Сизифе обновился пакет C из сборочного окружения В, и у этого С зависимости инвариантны,
то при сборке и тестировании В на обновление пакета С 
можно не обращать внимания. Unmets не будет.

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

имело бы смысл сборочнице распознавать такие пакеты.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.