[devel] Unary number system is inefficient.

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

Уважаемые коллеги!

В нашем 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