[devel] Unary number system is inefficient.

[Led]

On Wednesday, 04 November 2009 23:03:33 Igor Vlasenko wrote:
> Уважаемые коллеги!
>
> В нашем 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

IMHO глупо: ещё и всякие "q" в релиз приплетать. Мало расплодившися (непонятно 
зачем) "svn", "cvs", "beta/alpha/pre" в релизах?
С "зубочистками" нужно по другому бороться, ане придумывать очередные костыли.

-- 
Led