[devel] Unary number system is inefficient.

[devel] Unary number system is inefficient.

[Igor Vlasenko]

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

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

Re: [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

Re: [devel] Unary number system is inefficient.

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

05.11.2009 00:03, Igor Vlasenko пишет:
> Уважаемые коллеги!
> 
> В нашем 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.

  А не лучше ли использовать суффиксы вида alt<M>{,.n}, где <M> релиз
выставленный мантейнером, а n -- цифра инкрементируемая при NMU и/или
сборке роботом?

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]

Re: [devel] Unary number system is inefficient.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

On Wed, Nov 04, 2009 at 11:03:33PM +0200, Igor Vlasenko wrote:

IV> Одним словом, единичная система счисления имеет ряд недостатков,
IV> так что во избежание зубочисток .1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
IV> прошу разрешить суффикс .qaN для пакетов, собранных @qa наравне с .1

Если релиз попадает под шаблон /^(alt.*\.)(\d+)$/
_и_ предыдущий сборщик был робот QA
_то_ -> новый релиз $1.($2+1)

Это:
а) избавит от .1.1.1.1.1.1.1
б) будет красиво и не будет противоречить эстетическим чувствам
мантейнеров :)
в) оставит тот же уровень информативности что и шаблон с qa\d+

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Unary number system is inefficient.

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

В Срд, 04/11/2009 в 23:03 +0200, Igor Vlasenko пишет:
> Уважаемые коллеги!
> 
> В нашем 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
> 
> я ее предлагаю сохранять и поддерживать.
А я уже давно предпочитаю увеличивать вторую цифру на единицу при
пересборках, вместо того, чтобы добавлять ещё одну точку с единицей.
Например, сейчас в Сизифе лежит anjuta2-2.26.2.1-alt2.3

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Unary number system is inefficient.

[Igor Vlasenko]

On Wed, Nov 04, 2009 at 11:03:33PM +0200, Igor Vlasenko wrote:
> Одним словом, единичная система счисления имеет ряд недостатков,
> так что во избежание зубочисток .1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
> прошу разрешить суффикс .qaN для пакетов, собранных @qa наравне с .1

Спасибо всем высказавшимся в дискуссии!

Суммируя, способ, предложенный Алексеем Авдеевым <solo@>

>   А не лучше ли использовать суффиксы вида alt<M>{,.n}, где <M> релиз
> выставленный мантейнером, а n -- цифра инкрементируемая при NMU и/или
> сборке роботом?

Не вызывает возражений 

Alexey "Ktirf" Rusakov >

> А я уже давно предпочитаю увеличивать вторую цифру на единицу при
> пересборках, вместо того, чтобы добавлять ещё одну точку с единицей.

и потихоньку используется.
Предлагаю добавить его как допустимый вариант в NMU policy.

по предложениям упразднить .1
> _и_ предыдущий сборщик был робот QA
выскажу мнение против: 
не надо усложнять жизнь потенциальным скриптописателям.
Нарастить релиз на .1 --- хоть и тривиальный алгоритм,
но сэкономит время тому, кому нужно срочно сделать NMU.

Таперь о .qaN.

С одной стороны, уже есть вариант alt<M>{,.n}, 
который никого не раздражает и его можно записать в NMU policy.

Могу перейти на этот вариант. 

Но вопрос. Почему я прошу допустить для меня 
еще одно исключение в NMU policy с этим суффиксом .qa?

Потому что я человек;)

И также планирую чинить алгоритмически не разрешимые баги
вручную. Следовательно, как человек, в процессе ошибаться.
Суффикс .qa поможет мне легче отслеживать ошибки
наподобие такой, как неумышленное подхватывание пакета из 
@nobody.

Таким образом, это не игрушка, а средство самоконтроля.
Напомню, на мне числится почти 1000 исходных пакетов,
ручной счет им давно потерян, все обрабатывается списками, 
сортировкой и автоматами.

Поддерживаю вариант alt<M>{,.n}, предлагаю добавить в policy,
но прошу разрешить и вариант с .qa,
как помогающий бороться с ошибками борцов с ошибками ;)

-- 

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

Re: [devel] Unary number system is inefficient.

[Led]

On Thursday 05 November 2009 18:46:12 Igor Vlasenko wrote:
> On Wed, Nov 04, 2009 at 11:03:33PM +0200, Igor Vlasenko wrote:
> > Одним словом, единичная система счисления имеет ряд недостатков,
> > так что во избежание зубочисток .1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
> > прошу разрешить суффикс .qaN для пакетов, собранных @qa наравне с .1
>
> Спасибо всем высказавшимся в дискуссии!
>
> Суммируя, способ, предложенный Алексеем Авдеевым <solo@>
>
> >   А не лучше ли использовать суффиксы вида alt<M>{,.n}, где <M> релиз
> > выставленный мантейнером, а n -- цифра инкрементируемая при NMU и/или
> > сборке роботом?
>
> Не вызывает возражений
>
> Alexey "Ktirf" Rusakov >
>
> > А я уже давно предпочитаю увеличивать вторую цифру на единицу при
> > пересборках, вместо того, чтобы добавлять ещё одну точку с единицей.
>
> и потихоньку используется.
> Предлагаю добавить его как допустимый вариант в NMU policy.
>
> по предложениям упразднить .1
>
> > _и_ предыдущий сборщик был робот QA
>
> выскажу мнение против:
> не надо усложнять жизнь потенциальным скриптописателям.
> Нарастить релиз на .1 --- хоть и тривиальный алгоритм,
> но сэкономит время тому, кому нужно срочно сделать NMU.
>
> Таперь о .qaN.
>
> С одной стороны, уже есть вариант alt<M>{,.n},
> который никого не раздражает и его можно записать в NMU policy.
>
> Могу перейти на этот вариант.
>
> Но вопрос. Почему я прошу допустить для меня
> еще одно исключение в NMU policy с этим суффиксом .qa?
>
> Потому что я человек;)

А давайте все мейнтейнеры в релизе будут ставить свой никнейм? или вобще: 
префиксом к пакету - ник мейнтейнера? Они ведь живые люди, им так "удобнее 
будет":)

>
> И также планирую чинить алгоритмически не разрешимые баги
> вручную. Следовательно, как человек, в процессе ошибаться.
> Суффикс .qa поможет мне легче отслеживать ошибки
> наподобие такой, как неумышленное подхватывание пакета из
> @nobody.
>
> Таким образом, это не игрушка, а средство самоконтроля.
> Напомню, на мне числится почти 1000 исходных пакетов,
> ручной счет им давно потерян, все обрабатывается списками,
> сортировкой и автоматами.
>
> Поддерживаю вариант alt<M>{,.n}, предлагаю добавить в policy,
> но прошу разрешить и вариант с .qa,
> как помогающий бороться с ошибками борцов с ошибками ;)



-- 
Led

Re: [devel] Unary number system is inefficient.

[Igor Vlasenko]

On Thu, Nov 05, 2009 at 06:58:20PM +0200, Led wrote:
> А давайте все мейнтейнеры в релизе будут ставить свой никнейм? или вобще: 
> префиксом к пакету - ник мейнтейнера? Они ведь живые люди, им так "удобнее 
> будет":)

Все не захотят, думаю. Но если ник в релизе 
вдохновит человека качественно собрать какой-нибудь
заброшеный пакет, я только за.

Кроме того, у апстрима есть привилегия 
назвать свое творение libcaca, или brainfuck,
или в честь любимой собаки, или вставить в About
фотогалерею любимой супруги.

Почему у майнтайнеров не должно быть своих маленьких 
привилегий?
Еще раз повторяю. Если этот ник человека вдохновит,
я только обрадуюсь.

-- 

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

Re: [devel] Unary number system is inefficient.

[Michael Shigorin]

On Thu, Nov 05, 2009 at 06:58:20PM +0200, Led wrote:
> > Но вопрос. Почему я прошу допустить для меня еще одно
> > исключение в NMU policy с этим суффиксом .qa?
> > Потому что я человек;)
> А давайте все мейнтейнеры в релизе будут ставить свой никнейм?
> или вобще: префиксом к пакету - ник мейнтейнера? Они ведь живые
> люди, им так "удобнее будет":)

Мне -- нет.  А Игоря -- понимаю.  Не бузи :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Unary number system is inefficient.

[Led]

On Thursday 05 November 2009 19:12:14 Michael Shigorin wrote:
> On Thu, Nov 05, 2009 at 06:58:20PM +0200, Led wrote:
> > > Но вопрос. Почему я прошу допустить для меня еще одно
> > > исключение в NMU policy с этим суффиксом .qa?
> > > Потому что я человек;)
> >
> > А давайте все мейнтейнеры в релизе будут ставить свой никнейм?
> > или вобще: префиксом к пакету - ник мейнтейнера? Они ведь живые
> > люди, им так "удобнее будет":)
>
> Мне -- нет.  А Игоря -- понимаю.  Не бузи :)

Я тоже прекрасно понимаю тех, кто пытается на^Wобмануть судьбу. Но это не 
значит, что я разделяю их точку зрения:)

-- 
Led

Re: [devel] Unary number system is inefficient.

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Thu, Nov 05, 2009 at 06:58:20PM +0200, Led wrote:
> А давайте все мейнтейнеры в релизе будут ставить свой никнейм? или вобще: 
> префиксом к пакету - ник мейнтейнера? Они ведь живые люди, им так "удобнее 
> будет":)
http://gems.github.com/

"""
Installing a RubyGem from GitHub

Update to RubyGems 1.2.0 or greater before proceeding!!

  $ gem sources -a http://gems.github.com (you only have to do this once)
  $ sudo gem install username-projectname
"""

I LOL'd.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Unary number system is inefficient.

[Michael Shigorin]

On Thu, Nov 05, 2009 at 06:46:12PM +0200, Igor Vlasenko wrote:
> > А я уже давно предпочитаю увеличивать вторую цифру на единицу при
> > пересборках, вместо того, чтобы добавлять ещё одну точку с единицей.
> Предлагаю добавить его как допустимый вариант в NMU policy.

Угу.

> не надо усложнять жизнь потенциальным скриптописателям.
> Нарастить релиз на .1 --- хоть и тривиальный алгоритм,
> но сэкономит время тому, кому нужно срочно сделать NMU.

Иметь два варианта на выбор тут кажется совершенно не страшным.

> Поддерживаю вариант alt<M>{,.n}, предлагаю добавить в policy,
> но прошу разрешить и вариант с .qa, как помогающий бороться с
> ошибками борцов с ошибками ;)

Мне глаз не режет. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/