[devel] senseless check in 5.1 backporting (missing last changelog entry)

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

Новая заповель для incoming --
"навреди ближнему своему".

Столкнулся с тем, что task 22332 не прошел
http://git.altlinux.org/tasks/22332/task/log
по причине "missing last changelog entry".

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

По логике этой проверки, например, пусть
разработчик вел разработку foo в trunk. в какой-то момент
он форкнул стабильную ветку foo5. внес несколько изменений
и готовится выпустить foo5. А вот не выйдет!
Слишком умная система сборки заявляет:
а почему это вы не смержились с прошлогодней протухшей
веткой foo3? Без мержа мы вас не выпустим!

А есть ли в этом мерже СМЫСЛ? да, можно обойти эту проверку.
сделать в git merge -s ours, сфабриковать в srpm нужный
changelog, но СМЫСЛ?

Более того, обойти указанные проверки подделкой changelog
-- значит сломать очень для меня важный инвариант --
бинарную идентичность java пакетов в Сизифе и 5.1.
Я _не_ собираю пакеты в бранче, а перекладываю их 
туда стабильными срезами. 

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

И еще раз подниму старую тему ---
не надо спешить встраивать сомнительные
и "почти правильные" проверки в incoming.

Проблема в том, что от этих проверок нельзя уклониться.

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

-- 

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