[devel] Unary number system is inefficient.
Igor Vlasenko
vlasenko at imath.kiev.ua
Wed Nov 4 21:03:33 UTC 2009
Уважаемые коллеги!
В нашем NMU policy есть правило нумерации
NMU релизов
"Если исправление можно сделать в рамках той же upstream-версии пакета, что находится в репозитории, то в значение тэга Release пакета необходимо добавить дополнительное число, отделённое точкой и по нумерации начинающееся с единицы, чтобы не пересечься с обычной нумерацией версий и релизов у основного мейнтейнера.
Например, пакет, собранный ранее мейнтейнером с релизом alt3 и автоматически пересобранный ранее QA Team Robot с релизом alt3.1, при NMU должен получить релиз alt3.1.1."
Это древняя и уважаемая традиция, иногда, правда,
порождающие релизы на релизы вида
python-module-ClientCookie-1.0.2-alt0.1.1.1.1.src.rpm
python-module-OpenSSL-0.6-alt2.1.1.1.1.src.rpm
я ее предлагаю сохранять и поддерживать.
Но! для пакетов, собранных в рамках @qa,
хочу использовать вместо суффикса .1.1 ... .1 (N times)
суффикс .qaN.
Причины понятны:
Я, как уже рассказывал, пишу qa-repocop робот, который будет
делать NMU не раз в год, а на постоянной основе.
Учитывая скорость изменений, реально получить для
nobody пакетов релизы вида
python-module-ClientCookie-1.0.2-alt0.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.src.rpm
Что и уродливо,
сравнивая с
python-module-ClientCookie-1.0.2-alt0.1.qa14
и чревато переполнениями колонок в старом движке prometeus.
Одним словом, единичная система счисления имеет ряд недостатков,
так что во избежание зубочисток .1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
прошу разрешить суффикс .qaN для пакетов, собранных @qa наравне с .1
--
Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine
More information about the Devel
mailing list