On Thu, Mar 25, 2010 at 09:45:00AM +0200, Igor Vlasenko wrote:
> Новая заповель для 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.
> 
> Проблема в том, что от этих проверок нельзя уклониться.
> 
> Если уже встраивать всякие разные,
> давайте уже только с механизмом их отключения.