[devel] Чисто конкретно по лимитам сборочницы.

[Igor Vlasenko]

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

Уважаемый Дмитрий,
хотел бы пояснить, почему я считаю вашу принципиальную позицию
по лимитам сборочницы неверной.

В статистике есть такое понятие, как нормальное, или Гауссовское,
распределение. Его плотность - характерная колоколообразная кривая.
Ваша позиция была бы корректной, если бы разброс параметров сборки
подчинялся бы нормальному распределению.
Для него действительно легко указать компактную область (лимиты),
выход за которые -- вероятность слишком ничтожная, чтобы ее учитывать.

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

К примеру, сейчас, если тесты при сборке пакета сорвутся в
цикл, что-то понемногу выводя (не провоцируя wlimit_time_idle),
то для пакета, собирающегося 3-5 мин. придется ждать 10 часов,
чтобы сработал wlimit_time_elapsed.
Если бы wlimit_time_elapsed коррелировал со временем сборки пакета,
то время ожидания падения сборки было бы более человекоориентированным.

Если же цикл активно выводит, то сработает wlimit_bytes_written.
Я сталкивался с такими логами сборки в процессе разработки
logoved. Лог в пол гигабайта, где первые 50-100 килобайт - осмысленный
лог сборки, затем 500 мегабайт мусора, затем сообщение, что наконец
сработал wlimit_bytes_written.

Логовед такой лог парсил десятки минут. Да и лишний трафик напрягает.
Если бы wlimit_bytes_written коррелировал с размером нормального лога пакета,
то логи FTBFS были бы гораздо более человеко- и машинно- читабельными.

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

Ранее вы могли бы отмахиваться от моих проблем, в духе
"viy@ - исключение, и пакеты у него неправильные".
Хотя опять же, по статистике, наибольшая вероятность первым нарваться
на проблемы у пользователя с наибольшей и наиболее разнообразной
по типам и системам сборки пакетной базой.

Стоило уже тогда не игнорировать проблему.

Сейчас же проблемы уже начали расползаться по все большему кругу
пользователей. Я только сейчас осознал, что теперь к клубу
униженных и угнетенных (viy@, zerg@,...) прибавился и cas@,
ведь он взялся за java-1.8.0-openjdk.
Судя по success-логам пересборки, для пакета
azure-sdk-for-ruby-20200316-alt1.2
считанные доли процента отделяют его от срабатывания wlimit_bytes_written.

еще больше пакетов превысили порог времени сборки в 4 часа на x86_64,
их майнтайнерам приготовиться к нежданчикам с wlimit_time_elapsed на armh.

И хотел бы сказать, Дмитрий, что и у вас самих далеко не нулевая
вероятность самому вступить в "клуб униженных и угнетенных лимитами".
Во всяком случае, в прошлом письме, когда я привел 4 примера пакетов,
которые не вписывались в wlimit_time_elapsed,
я забыл про пример cross-gcc, который я в свое время по просьбе уважаемых
коллег импортировал в Сизиф. Тогда cross-gcc тоже не вписывался в
wlimit_time_elapsed, и по согласованию с уважаемым заказчиком сборки,
я кастрировал сборку, выбросив часть cross-архитектур, которые
заказчику были не нужны. Получается, уже gcc5 был не так уж далек от
лимита, а последние gcc всего в 4 раза меньше лимита.

Хотелось бы понять, Дмитрий, если новый LibreOffice 8 или gcc13
не впишется в лимиты сборочницы, сохраните ли вы свою принципиальную
позицию, будете вы резать gcc на подпакеты, или тихо сдвинете лимиты,
поскольку "это другое, понимать надо"?


-- 

I V