[devel] [JT] I: Sisyphus-20041027 unmets

[Andrey Orlov]

On Monday 01 November 2004 11:43, you wrote:
> On Sun, Oct 31, 2004 at 08:53:38PM +0300, Andrey Orlov wrote:
>  AO> Денис, это так и было, практически. Только вместо SRPMS.incoming был дедал.
> Пожалуйста, ткните меня носом в полиси где об этом сказано.

А вы ее не читали? :)

> Если полиси нет, то я далеко не единственный кто не знает об этой
> практике, 

Поднимите архивы переписки со старой версией полиси и "планом перехода". Все
это неоднократно публиковалось и доносилось до сведенья. Переход на "пайтон полиси"
был разовым, поэтому именно план перехода туда не включен. А вот переход на новую версию
питона описан достаточно подробно, правда, прецедента такого перехода еще не было. Должен
отметить, что прецедент имеет место сейчас и так как ситуация очень напоминает то, что было весной -
т.е. призывы опубликованы, откликов нет, то, подозреваю, что развиваться все будет тоже как в прошлый раз.

> и эта самая практика уже давно не действует, насколько я понял
> :-(

Действует. Например, в точном соответствии с полиси в дедал направлена сборка
python2.3.4, python2.4b & rpm-build-python > 0.16. Мантейнеры пакетов были оповещены о возможных проблемах
с rbp > 0.16 через список рассылки девел. Вообще-то лично я практически всегда подозрительные сборки кладу в дедал ;).

> И кто тестировал влияение пакета на остальные? IMHO это можно сделать
> только скриптом вокруг hasher'а.

ИИХО, это могут сделать только мантейнеры пакетов, достав пакет из дедала и приведя свои в соответствие с ним.
А так, например, по состоянию пакета rpm-build-python 0.16 (а ща в дедале уже 0.18) я вам без всякого скрипта
вокруг хашера скажу, что все пакеты, содержащие python, имеют шанс осыпаться, если будет сделано то, о чем
я писал в рассылке месяц назад (подробности, например, http://www.neural.ru/Products/Python/FAQ, Q29). 
Тогда же я просил проверить / пофиксить. Что-то я не заметил __никаких__ движений в этом направлении.

Кроме того, новая версия python 2.4 уже на подходе. Пакет лежит в дедале. Что написано в полиси по этому поводу, 
можно прочитать в полиси (в неофициальную копию я любезно ткну: http://www.neural.ru/Products/Python/Policy, 
официальная в пакете rpm-build-python). Опять же никаких движений в области тестирования ни на python-2.3.4, ни
на python-2.4b1 я не вижу. На днях я столкну в сизиф 2.3.4 (так как у меня последняя сборка нареканий не вызывает),
кто не спрятался - я не виноват. 2.3.4 считается bug fix release, но некоторые проекты уже имели трудности с переходом :),
хотя собиратся-то конечно, все скорее всего будет.

Кроме того, полиси-то у нас есть, но весенне-летний эпизод продемонстровал то, что народ не удосуживается 
прочитать не только полиси, но даже FAQ. Хорошо, что хоть мылом вопросы задают. Так что ссылаться на отсутствие 
полиси и недокументированность планов перехода, в случае питона, пожалуста, не надо: это не тот случай. Это тот 
случай, когда полиси и все необходимые документы были, но не были востребованы. Разумеется, там описано не 
все - но вот вы конкретно хоть раз задали вопрос или предложили поправку к полиси?  Вы конкретно приняли 
участие в ее обсуждении? Вообще, прежде чем рассуждать о полиси, очень посоветовал бы изучить конкретный
действующий пример - python-policy. Не без шкурног интереса, посоветовал бы: может, предложите что улучшить или 
посоветуете как избежать.... ;))

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray на neural.ru, jid: cray на altlinux.org ---
----------------------------------------