[devel] I: Sisyphus-20041027 unmets

[devel] I: Sisyphus-20041027 unmets

[Dmitry V. Levin]

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

Hi,

Что-то давно этот список никто сюда не отправлял.

Пакет ocaml-postgres-runtime версии 20010808-alt14.1 имеет неудовлетворенные зависимости:
 Требует: ocaml-runtime (= 3.07-alt6.1)
Пакет kernel-modules-cdfs-std26-up версии 2.6.3-alt3.9 имеет неудовлетворенные зависимости:
 Для установки требует: kernel-image-std26-up (= 2.6.8-alt9)
 Для установки требует: kernel-image-std26-up (= 2.6.8-alt9)
Пакет ocamlcl версии 0.3-alt12 имеет неудовлетворенные зависимости:
 Требует: ocaml (= 3.07-alt6)
 Требует: camlp4 (= 3.07-alt6)
Пакет pixieplus версии 0.5.4-alt2 имеет неудовлетворенные зависимости:
 Требует: libtiff.so.3
Пакет qvcd версии 0.21-alt2 имеет неудовлетворенные зависимости:
 Требует: libqt3-gcc_compiled (= 3.3)
Пакет ocamlgsl версии 0.2.2-alt5.1 имеет неудовлетворенные зависимости:
 Требует: ocaml (= 3.07-alt6.1)
 Требует: camlp4 (= 3.07)
Пакет kernel-modules-amedyn-std-up версии 2003.10.29-alt3 имеет неудовлетворенные зависимости:
 Для установки требует: kernel-image-std-up (= 2.4.26-alt6)
 Для установки требует: kernel-image-std-up (= 2.4.26-alt6)
Пакет python-module-serial-jython версии 2.1-alt1 имеет неудовлетворенные зависимости:
 Требует: python2.3(javax)
 Требует: python2.3(serialutil)
Пакет prelude-lml версии 0.8.6-alt4.1 имеет неудовлетворенные зависимости:
 Требует: libpcre
Пакет j2se1.5-sun-demo версии 1.5.0-alt2 имеет неудовлетворенные зависимости:
 Требует: libjava_crw_demo_g.so
Пакет ocamlgsl-runtime версии 0.2.2-alt5.1 имеет неудовлетворенные зависимости:
 Требует: ocaml-runtime (= 3.07-alt6.1)
 Требует: /usr/lib/ocaml/bigarray.so
Пакет FCM версии 2.0.r1-alt1 имеет неудовлетворенные зависимости:
 Требует: python2.3(objects)
 Требует: python2.3(tools)
Пакет kernel-modules-cdfs-std26-smp версии 2.6.3-alt3.9 имеет неудовлетворенные зависимости:
 Для установки требует: kernel-image-std26-smp (= 2.6.8-alt9)
 Для установки требует: kernel-image-std26-smp (= 2.6.8-alt9)
Пакет kemuconfig версии 0.2-alt0.8 имеет неудовлетворенные зависимости:
 Требует: emu10k1-tools (>= 20021121-alt1)
Пакет pam2-config версии 1.1.7-alt1 имеет неудовлетворенные зависимости:
 Требует: pam_limits.so.2
 Требует: pam_tcb.so.2
Пакет ocaml-postgres версии 20010808-alt14.1 имеет неудовлетворенные зависимости:
 Требует: ocaml (= 3.07-alt6.1)
Пакет coq версии 8.0beta-alt1.1 имеет неудовлетворенные зависимости:
 Требует: ocaml (= 3.07-alt6.1)
 Требует: camlp4 (= 3.07-alt6.1)
Пакет rpm-build-tcl версии 0.1-alt0.1 имеет неудовлетворенные зависимости:
 Для установки требует: rpm-build (>= 4.0.4-alt40.1)
Пакет ocaml-mysql версии 1.0.2-alt4.1 имеет неудовлетворенные зависимости:
 Требует: ocaml (= 3.07-alt6.1)
Пакет python-module-pychecker-tk версии 0.8.14-alt1 имеет неудовлетворенные зависимости:
 Требует: pychecker-0.8.14
 Требует: python2.3(Config)
Пакет gtk1-themes-extras версии 0.8.0-alt1 имеет неудовлетворенные зависимости:
 Требует: gtk1-themes-smooth
Пакет alsa-patch-bay-ui-gtk версии 1.0.0-alt0.6 имеет неудовлетворенные зависимости:
 Требует: libatkmm-1.0.so.1
 Требует: libgdkmm-2.0.so.1
 Требует: libglibmm-2.0.so.1
 Требует: libgtkmm-2.0.so.1
 Требует: libpangomm-1.0.so.1
Пакет kernel-modules-ovlfs-std-up версии 2.0.1-alt4 имеет неудовлетворенные зависимости:
 Для установки требует: kernel-image-std-up (= 2.4.26-alt6)
 Для установки требует: kernel-image-std-up (= 2.4.26-alt6)
Пакет postgresql-python версии 7.4.5-alt1 имеет неудовлетворенные зависимости:
 Требует: egenix-mx-base (>= 2.0.3)
Пакет kernel-modules-cdfs-vs-smp версии 2.6.3-alt2.6.1 имеет неудовлетворенные зависимости:
 Для установки требует: kernel-image-vs-smp (= 2.4.26-alt6.1)
 Для установки требует: kernel-image-vs-smp (= 2.4.26-alt6.1)
Пакет gtk2-themes-extras версии 0.8.0-alt1 имеет неудовлетворенные зависимости:
 Требует: gtk2-themes-smooth
Пакет bsddb3Storage версии 1.0beta5-alt3 имеет неудовлетворенные зависимости:
 Требует: bsddb3
Пакет advi версии 20031217-alt4.1 имеет неудовлетворенные зависимости:
 Требует: camlimages-runtime (= 2.11-alt8.1)
 Требует: libtiff.so.3
Пакет gda-postgres версии 0.2.96-alt5 имеет неудовлетворенные зависимости:
 Требует: postgresql-libs (>= 7.2.2-alt2)
Пакет tuxvsclippy версии 0.2.3-alt2.1 имеет неудовлетворенные зависимости:
 Требует: libauxil.so.0
 Требует: libinp.so.0
 Требует: libmath.so.0
 Требует: libpres.so.0
 Требует: librot.so.0
 Требует: libsnd.so.0
 Требует: libwld.so.0


-- 
ldv

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

Re: [devel] I: Sisyphus-20041027 unmets

[Anton Farygin]

Dmitry V. Levin пишет:
> Hi,
> 
> Что-то давно этот список никто сюда не отправлял.
> Пакет kernel-modules-cdfs-std26-up версии 2.6.3-alt3.9 имеет неудовлетворенные зависимости:
>  Для установки требует: kernel-image-std26-up (= 2.6.8-alt9)
>  Для установки требует: kernel-image-std26-up (= 2.6.8-alt9)

Это безобразие было выложено вместе с ядром 2.6.9. Мне непонятно, почему 
его все еще нет в Sisyphus (новые версии до сих пор валяются в out'е)
> Пакет kernel-modules-cdfs-std26-smp версии 2.6.3-alt3.9 имеет неудовлетворенные зависимости:
>  Для установки требует: kernel-image-std26-smp (= 2.6.8-alt9)
>  Для установки требует: kernel-image-std26-smp (= 2.6.8-alt9)

Аналогично.



> Пакет kernel-modules-cdfs-vs-smp версии 2.6.3-alt2.6.1 имеет неудовлетворенные зависимости:
>  Для установки требует: kernel-image-vs-smp (= 2.4.26-alt6.1)
>  Для установки требует: kernel-image-vs-smp (= 2.4.26-alt6.1)

Аналогично.

Rgds,
Rider

P.S.
Писем с отлупами я не получал.

Re: [devel] I: Sisyphus-20041027 unmets

[Alexey Gladkov]

Anton Farygin wrote:
> Dmitry V. Levin пишет:
> 
>> Hi,
>>
>> Что-то давно этот список никто сюда не отправлял.
>> Пакет kernel-modules-cdfs-std26-up версии 2.6.3-alt3.9 имеет 
>> неудовлетворенные зависимости:
>>  Для установки требует: kernel-image-std26-up (= 2.6.8-alt9)
>>  Для установки требует: kernel-image-std26-up (= 2.6.8-alt9)
> 
> 
> Это безобразие было выложено вместе с ядром 2.6.9. Мне непонятно, почему 
> его все еще нет в Sisyphus (новые версии до сих пор валяются в out'е)

Не вот это ли вот ты имеешь ввиду:
Sisyphus/2004-10-21.1:Sisyphus/RPMS/kernel-modules-cdfs-std26-up-2.6.3-alt2.10.i586.rpm

?
Это единственное что я нашел в инкоминге.

А в сизифе у нас:
kernel-modules-cdfs-std26-up-2.6.3-alt3.9.i586.rpm

$ rpmvercmp kernel-modules-cdfs-std26-up-2.6.3-alt3.9.src.rpm 
kernel-modules-cdfs-std26-up-2.6.3-alt2.10.src.rpm
1

Таких вещей я не отслеживаю (пока).

-- 
Rgrds, legion

Re: [devel] I: Sisyphus-20041027 unmets

[Dmitry V. Levin]

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

On Thu, Oct 28, 2004 at 10:49:31AM +0400, Anton Farygin wrote:
> >Пакет kernel-modules-cdfs-std26-up версии 2.6.3-alt3.9 имеет 
> >неудовлетворенные зависимости:
> > Для установки требует: kernel-image-std26-up (= 2.6.8-alt9)
> > Для установки требует: kernel-image-std26-up (= 2.6.8-alt9)
> 
> Это безобразие было выложено вместе с ядром 2.6.9. Мне непонятно, почему 
> его все еще нет в Sisyphus (новые версии до сих пор валяются в out'е)

В Сизифе есть одноимённый пакет более новой сборки.

> >Пакет kernel-modules-cdfs-std26-smp версии 2.6.3-alt3.9 имеет 
> >неудовлетворенные зависимости:
> > Для установки требует: kernel-image-std26-smp (= 2.6.8-alt9)
> > Для установки требует: kernel-image-std26-smp (= 2.6.8-alt9)
> 
> Аналогично.

Аналогично.

> >Пакет kernel-modules-cdfs-vs-smp версии 2.6.3-alt2.6.1 имеет 
> >неудовлетворенные зависимости:
> > Для установки требует: kernel-image-vs-smp (= 2.4.26-alt6.1)
> > Для установки требует: kernel-image-vs-smp (= 2.4.26-alt6.1)
> 
> Аналогично.

Аналогично.

> P.S.
> Писем с отлупами я не получал.

Нынешняя система подготовки Сизифа устроена так, что:
пакет более старой сборки по сравнению с той, что находится в Сизифе,
будучи залитым в incoming, удаляется молча на той стадии, когда уже
невозможно отличить свежесобранное от собранного ранее.


-- 
ldv

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

Re: [devel] I: Sisyphus-20041027 unmets

[Вячеслав Диконов]

On Чтв, 2004-10-28 at 02:01 +0400, Dmitry V. Levin wrote:
> Hi,
> 
> Что-то давно этот список никто сюда не отправлял.
> 
> Пакет gtk1-themes-extras версии 0.8.0-alt1 имеет неудовлетворенные зависимости:
>  Требует: gtk1-themes-smooth

> Пакет gtk2-themes-extras версии 0.8.0-alt1 имеет неудовлетворенные зависимости:
>  Требует: gtk2-themes-smooth
Это последствия того, что я не закончил проект перепаковки тем. Нужно
было готовиться к сдаче третьего кандидатского экзамена, писать реферат
и пр.. Кстати, экзамен сдал "отлично" :) . 

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

-- 
Вячеслав Диконов <sdiconov@mail.ru>

Re: [devel] I: Sisyphus-20041027 unmets

[Alexey Morozov]

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

On Thu, Oct 28, 2004 at 02:01:43AM +0400, Dmitry V. Levin wrote:
> Пакет python-module-serial-jython версии 2.1-alt1 имеет неудовлетворенные зависимости:
>  Требует: python2.3(javax)
>  Требует: python2.3(serialutil)
Насколько я понимаю, jython у нас все равно никто собирать не будет?
В следующей сборке исключу jython'овский подмодуль.

> Пакет python-module-pychecker-tk версии 0.8.14-alt1 имеет неудовлетворенные зависимости:
>  Требует: pychecker-0.8.14
>  Требует: python2.3(Config)
Оп... поправлю

> Пакет gtk1-themes-extras версии 0.8.0-alt1 имеет неудовлетворенные зависимости:
>  Требует: gtk1-themes-smooth
Ну, это Слава там чего-то такого страшного хотел от тем, пускай он и
разбирается :-)



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

Re: [devel] I: Sisyphus-20041027 unmets

[Vladimir Lettiev]

Alexey Morozov пишет:
> On Thu, Oct 28, 2004 at 02:01:43AM +0400, Dmitry V. Levin wrote:
> 
>>Пакет python-module-serial-jython версии 2.1-alt1 имеет неудовлетворенные зависимости:
>> Требует: python2.3(javax)
>> Требует: python2.3(serialutil)
> 
> Насколько я понимаю, jython у нас все равно никто собирать не будет?

я хотел собрать (думал прикрутить его для mx4j). Только не знаю как к 
нему подступиться, он пребывает в каком-то заброшенном состоянии и хочет 
python22.


-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

Re: [devel] I: Sisyphus-20041027 unmets

[Alexey Morozov]

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

On Thu, Oct 28, 2004 at 03:50:58PM +0400, Vladimir Lettiev wrote:
> >>Пакет python-module-serial-jython версии 2.1-alt1 имеет неудовлетворенные 
> >>зависимости:
> >>Требует: python2.3(javax)
> >>Требует: python2.3(serialutil)
> >Насколько я понимаю, jython у нас все равно никто собирать не будет?
> я хотел собрать (думал прикрутить его для mx4j). Только не знаю как к 
> нему подступиться, он пребывает в каком-то заброшенном состоянии и хочет 
> python22.
Ух-х... "Доктор сказал в морг, значит, в морг!" :-).
Но, на самом деле, если правда надо, то текущая схема вполне
допускает наличие python2.2 и набора модулей к нему.
Даже особенно конфликтовать не должно ничего...


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

Re: [devel] I: Sisyphus-20041027 unmets

[Andrey Orlov]

On Thursday 28 October 2004 16:14, Alexey Morozov wrote:
> Но, на самом деле, если правда надо, то текущая схема вполне
> допускает наличие python2.2 и набора модулей к нему.
> Даже особенно конфликтовать не должно ничего...

Ну его в баню. Если проект до сих пор не собирается с py2.3 - то он однозначно 
музейный экспонат, который на хрен никому не нужен. У нас и 2.3то последние недели доживает.

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

Re: [devel] I: Sisyphus-20041027 unmets

[Ivan Fedorov]

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

Andrey Orlov пишет:
> On Thursday 28 October 2004 16:14, Alexey Morozov wrote:
> 
>>Но, на самом деле, если правда надо, то текущая схема вполне
>>допускает наличие python2.2 и набора модулей к нему.
>>Даже особенно конфликтовать не должно ничего...
> 
> 
> Ну его в баню. Если проект до сих пор не собирается с py2.3 - то он однозначно 
> музейный экспонат, который на хрен никому не нужен. У нас и 2.3то последние недели доживает.
> 
Ну не факт... или вы думаете, что python 2.4 выйдет прямо завтра?..

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

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

[Alexey Morozov]

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

On Fri, Oct 29, 2004 at 09:21:34AM +0900, Ivan Fedorov wrote:
> > Ну его в баню. Если проект до сих пор не собирается с py2.3 - то он однозначно

Ну, натурально, не собирается. По крайней мере, один из его авторов
сейчас пишет IronPython, работает в MS и доволен как слон (и еще
народ зазывает). Санки за 7 лет заигрываний с коммьюнити, так и не
сподобились сделать хоть что-нибудь официально работающее и аппрувнутое.

> > музейный экспонат, который на хрен никому не нужен. У нас и 2.3то последние недели доживает.
> > 
> Ну не факт... или вы думаете, что python 2.4 выйдет прямо завтра?..
Знаете, я бы посмотрел на то, _куда_ мы пишем, и не стал бы так
однозначно связывать выход python 2.4 с уничтожением python-2.3 в
репозитории :-)


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

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

[Andrey Orlov]

On Friday 29 October 2004 08:58, Alexey Morozov wrote:
> On Fri, Oct 29, 2004 at 09:21:34AM +0900, Ivan Fedorov wrote:
> > > Ну его в баню. Если проект до сих пор не собирается с py2.3 - то он однозначно
> Ну, натурально, не собирается. По крайней мере, один из его авторов
> сейчас пишет IronPython, работает в MS и доволен как слон (и еще

В утиль. Тем более что ниша, которую мог бы занять этот продукт для меня осталась
загадкой. Некая таинственная платформа, на которой не пашет ничего, кроме
жабы, но при этом существует значимое количество программистов на питоне: видимо, их
жаба в конец достала ;)

> > > музейный экспонат, который на хрен никому не нужен. У нас и 2.3то последние недели доживает.
> > Ну не факт... или вы думаете, что python 2.4 выйдет прямо завтра?..

В дедале будет, надеюсь, в понедельник.

> Знаете, я бы посмотрел на то, _куда_ мы пишем, и не стал бы так
> однозначно связывать выход python 2.4 с уничтожением python-2.3 в
> репозитории :-)

Этот тезис я не понял. А то, что после выхода 2.4., я стану горячим противником
наличия 2.2, я вам обещаю ;). Кстати, в моей конторе ощутимое кол-во программеров всячески
поддерживает скорейший переход на 2.4. Т.е. я с трудом сдерживаю попытки перейти прям сейчас.

Кстати, Z2.8 собран с ZODB3.3. И без extensionclass. Я уже в пути - даже переписал наш менеджер
транзакций. Вернее, наш выкинул - поставил вместо него штатный, раз уж он так кстати появился.
Z2.8 должен уже лежать в дедале.

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

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

[Alexey Morozov]

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

On Fri, Oct 29, 2004 at 11:43:28PM +0400, Andrey Orlov wrote:
> В утиль. Тем более что ниша, которую мог бы занять этот продукт для меня
> осталась загадкой. Некая таинственная платформа, на которой не пашет
> ничего, кроме жабы, но при этом существует значимое количество
> программистов на питоне: видимо, их жаба в конец достала ;)
На самом деле, скриптовый (или, по крайней мере, "сильно managed") язык для
_платформы_ - это хорошо. И санки это, вроде как понимали (причем,
давно, еще во времена взлета популярности тикля, то есть, году в 96),
но сделать толком так ничего и не сделали...

А MS, в то же самое время, имела у себя на платформе целый спектр языков
для "простых [индийских] парней и (в особенности, хе-хе) девчонок", начиная
от VB, и заканчивая каким-нибудь FoxPro, на котором оффшорно колбасили мои
знакомцы, по крайней мере, до позапрошлого года.

И сейчас они с дот-нетом со своим делают примерно то же самое - двигают
_платформу_. И хотя, скорее всего, основная масса этих самых
.NET-программистов будет сидеть на "C с четырьмя крестами", меньшая
- на VB.NET, найдется место и для всяких "шибко умных" - StandardML.NET
и прочие их заигрывания с функциональными языками, и для "шибко ленивых"-
IronPython.

> > Знаете, я бы посмотрел на то, _куда_ мы пишем, и не стал бы так
> > однозначно связывать выход python 2.4 с уничтожением python-2.3 в
> > репозитории :-)
> Этот тезис я не понял.
:-)) Для осознания этого тезиса советую проследить работоспособность
и/или собираемость последних версий Zope, samba и ocaml _в Сизифе_...
;-)

Хотя, конечно, мне стоило вместо "выход python 2.4" выразиться
"НЕвыход [стабильного] python 2.4" :-)

> А то, что после выхода 2.4., я стану горячим противником наличия 2.2,
> я вам обещаю ;). Кстати, в моей конторе ощутимое кол-во программеров
> всячески поддерживает скорейший переход на 2.4. Т.е. я с трудом сдерживаю
> попытки перейти прям сейчас.
Медом намазано? ;-)

> Кстати, Z2.8 собран с ZODB3.3. И без extensionclass. Я уже в пути -
:-) И вспомнив наш предыдущий разговор на эту тему:

There should be laughter after pain
There will be sunshine after rain
These things have always been the same
So why worry now

> Z2.8 должен уже лежать в дедале.
Ну, хорошо. Сейчас, взлетим уже на старом (неделя осталась), и я
буду его смотреть :-)


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

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

[Alexander Bokovoy]

On Sat, Oct 30, 2004 at 11:55:19AM +0700, Alexey Morozov wrote:
> > > Знаете, я бы посмотрел на то, _куда_ мы пишем, и не стал бы так
> > > однозначно связывать выход python 2.4 с уничтожением python-2.3 в
> > > репозитории :-)
> > Этот тезис я не понял.
> :-)) Для осознания этого тезиса советую проследить работоспособность
> и/или собираемость последних версий Zope, samba и ocaml _в Сизифе_...
> ;-)
В отношении Самбы не принимаю, ибо этот пакет пересобирается, будучи
написанным практически исключительно на C. Вопрос скорее в том, что ряд
пакетов обновляется без проверки на то, сломаются ли использующие его
пакеты или нет.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

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

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

On Sat, Oct 30, 2004 at 10:07:57PM +0400, Alexander Bokovoy wrote:

 AB> В отношении Самбы не принимаю, ибо этот пакет пересобирается, будучи
 AB> написанным практически исключительно на C. Вопрос скорее в том, что ряд
 AB> пакетов обновляется без проверки на то, сломаются ли использующие его
 AB> пакеты или нет.

По прошествию чёрт-знает-какого количества времени опять заведём разговор
на тему "автоматичиеская проверка пакета, попадающего в Сизиф, не
сломается ли из-за него что-нибудь"?

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

http://freesource.info

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

[Andrey Orlov]

On Saturday 30 October 2004 22:19, Денис Смирнов wrote:
> On Sat, Oct 30, 2004 at 10:07:57PM +0400, Alexander Bokovoy wrote:
>  AB> пакетов обновляется без проверки на то, сломаются ли использующие его
>  AB> пакеты или нет.
> По прошествию чёрт-знает-какого количества времени опять заведём разговор
> на тему "автоматичиеская проверка пакета, попадающего в Сизиф, не
> сломается ли из-за него что-нибудь"?

Сдается мне, что это спор не о том, о чем надо. Ибо не так важно знать, что сломается,
сколь важно иметь стандартизованную политику, определяющую, что делать, если сломалось.
По моему сильно предвзятому мнению, до  сих пор де-факто вся политика сводилась
к оппортунистическим заявлениям типа: "зачем нам делать как лучше, если раньше 
кое-как работало, а теперь надо репу напрягать, как починить". 

Я очень рад, что среди нас есть люди, которые почти всегда в такой ситуации дают один и 
тот же ответ (грубо говоря, "вперед!"), в принципе, именно поэтому я остаюсь здесь, но, к сожалению,
это не является общей тенденцией, во многих случаях желание достигнуть маленькой сиюминутной
цели ("ну пусть мой маленький пакетик опять заработает") преподносится как более важное, чем попытки
улучшения общих характеристик  дистрибутива или сборочного инструментария.

Как близкий сердцу пример - rpm-build-python. Новая версия лежит в дедале почти месяц. Кто-то проверил
свой пакет? 

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

[devel] subteams? (was: I: Sisyphus-20041027 unmets)

[Michael Shigorin]

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

On Sun, Oct 31, 2004 at 01:11:50AM +0400, Andrey Orlov wrote:
> Как близкий сердцу пример - rpm-build-python. Новая версия
> лежит в дедале почти месяц. Кто-то проверил свой пакет? 

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

Вообще говоря, это всё к тем же вопросам о мотивации и
специализации, а также "режимам" поддержки.

Потому как одно дело -- опакетить (особенно _хорошо_) что-либо,
другое -- писать рекомендации по тому, как поверх и около этого
пакетить что-либо ещё, третье -- по оным или сообразно здравому
смыслу (и имеющимся примерам, если уже) пакетить эти масые
сателлитные пакеты, и при этом всегда остаётся поддержка, которая
тоже бывает разной -- от активной (фактически разработки
спека/патчей/обвязки) до пассивной ("о, уже две версии пропустил
-- что ли собрать").

И требования к умениям и складу характера у этих ролей достаточно
разные, чтобы совмещать их исполнение "в одном флаконе" было если
не проблематично, то напряжно.

Например, initial packaging и прочие policy -- это скорее
"молотобойцам", для которых проламывание стен лбом и ровняние
всего подряд в порядке вещей.

Активная поддержка -- где-то не очень далеко, т.к. по сути
практически всегда, насколько могу судить, сопряжена с тем, что
на этом что-то зарабатывается (а зачастую и в разработке апстрима
человек участвует, или сам её же и возглавляет).

Пассивная -- может производиться из соображений от ностальгии
("когда-то это было интересно, но не напрягает -- можно и сейчас
поподдерживать") до "мы в ответе за тех, кого приручили".
И, в общем, требует скорее админского склада характера ("чтоб
работало"), чем разработческого ("сейчас мы всё это безобразие
разломаем нафиг, зато когда починим -- будет в 2.718, нет, в
3.142 раз лучше!").

Соответственно трения чаще всего возникают, когда разработчики
ломают или крепко цепляют базу, на которой строят админы.

Т.е. если пытаться это разруливать (не уверен, что возможно) --
то именно с такой позиции и понимая мотивацию каждой стороны, как
мне кажется.

Потому что мне, например -- действительно будет проще дампнуть
solfege и getmail, которыми я не пользуюсь (собраны для других),
чем ради двух пакетов напрягаться и отслеживать изменения в
атмосфере.  Соответственно тебе, например, не более интересно
отслеживать и фиксить всё это барахлишко за каждым таким "ленивым
пакаджером" (про FAQ помню, читал и оценил).

И вот тут вспоминается один из эпизодов в жизни того же
solfege.spec, когда Юра Седунов взял и прислал его же, но уже с
выровненным хребтом, причём по крайней мере по паре пунктов таким
образом, до которого я бы тогда точно не додумался.

Соответственно есть такое соображение, что для _удачных_
перемещений _платформы_ в пространстве нужен не только человек
(всегда лучше -- несколько), который обдумает и провешит
собственно траекторию и конечную точку в этот раз, а и команда
разработчиков, которые помогут оперативно (а не затягивая на
полгода с перебранками "сломали! -- так лучше!") перетащить то,
что на старой платформе собиралось, а после переезда -- хорошо,
если запускается.

Здесь есть одна проблемка -- мотивация.  Это работа даже не
janitors, а скорее tiger team, где знания, умения, да и время,
требуемые для успешного выполнения такой задачи -- довольно
существенны.

При двух предыдущих "больших переездах" (initscripts и *.la) было
подумал, что мотивации для волонтеров не видно настолько, что это
действительно дело QA.

Потом начал понимать, что QA does not scale и вообще говоря --
должно-то scale в рамках того, что компания, которая платит
зряплату, считает оправданным.

Посему возвращаемся опять же в сообщество разработчиков -- но по
крайней мере с мыслями по поводу таких вот ролей.

Собственно, что-то подобное я когда-то пытался изложить здесь:
http://wiki.atmsk.ru/index.html/AltPolicy (зачем-то назвав "alt
policy", хотя ни разу -- это попытка констатация, а не
регламентирования).

В общем, господа team, что думаете по поводу более явного
выделения в оной team таких вот "родов войск"?

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

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

Re: [devel] subteams? (was: I: Sisyphus-20041027 unmets)

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

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

On Sun, Oct 31, 2004 at 08:45:29AM +0200, Michael Shigorin wrote:

 MS> В общем, господа team, что думаете по поводу более явного
 MS> выделения в оной team таких вот "родов войск"?

Думаю что если ты сможешь решить эту задачу неэкономическими методами, то
станешь в один ряд со Столлманом, Рэймондом и Линусом.

Такая tiger team должна:

1. обладать очень высокой квалификацией
2. иметь в своём составе хотя бы 1-2 "универсалов" (знающих "почти всё",
и способных помочь остальным в интеграции) плюс специалистов в отдельных
секторах (таких как языки программирования, отдельные платформы типа
KDE/Gnome со всей их инфраструктурой, или kernel team).
3. (ключевое) иметь очень жёсткую дисциплину и организованность действий.

Эдакий "мантейнерский спецназ".

Проблемы:

1. чем выше квалификация, тем выше загруженность (читай тяжелее
мотивировать, особенно на срочную работу)

2. организовать _чёткое_ взаимодействие между людьми не являющимися
сотрудниками одной организации весьма сложно.

Соответственно основной вопрос -- как мотивировать?

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

http://freesource.info


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

[devel] Re: subteams? (was: I: Sisyphus-20041027 unmets)

[Michael Shigorin]

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

On Sun, Oct 31, 2004 at 08:06:49PM +0300, Денис Смирнов wrote:
>  MS> В общем, господа team, что думаете по поводу более явного
>  MS> выделения в оной team таких вот "родов войск"?
> Думаю что если ты сможешь решить эту задачу неэкономическими
> методами, то станешь в один ряд со Столлманом, Рэймондом и
> Линусом.

Не претендую (тем паче только что посмотрев "Revolution OS" :)
К тому же подозреваю, что частично она решена.

> Такая tiger team должна:
> 1. обладать очень высокой квалификацией

Да.  Но кое-кто тут в своё время и был замечен ровно за
высказыванием вида "уровень разработчиков в команде существенно
выше уровня разработчиков в мире" года два-три тому.

> 2. иметь в своём составе хотя бы 1-2 "универсалов" (знающих
> "почти всё", и способных помочь остальным в интеграции) плюс
> специалистов в отдельных секторах (таких как языки
> программирования, отдельные платформы типа KDE/Gnome со всей их
> инфраструктурой, или kernel team).

Скорее да.

Ты упустил ещё одно качество (или включил в универсальность?) --
кругозор по дистрибутивам.  Бишь "а как это делается в ...",
что может способствовать стабилизации (вместо бурного роста)
отечественного велосипедостроения и улучшению стратегической
интероперабельности на разных уровнях, от конфигурации и опыта
до пакетов и их "гроздей" (последнее и для портирования спеков
довольно важно).

> 3. (ключевое) иметь очень жёсткую дисциплину и организованность
> действий.

Ты только не путай второе с первым.  Вместо первого кажется более
полезным задокументированная методология и нечто вроде бОльших
полномочий (например, на NMU по оговоренному алгоритму -- см.,
например, Debian Policy про дырки и критические баги).

> Эдакий "мантейнерский спецназ".

Ну, в общем, да.  Только формализованный.  За счёт чего меньше
времени и сил должно уходить в каждом конкретном случае на
переливание из пустого в порожнее и больше -- на собственно дело.

> Проблемы:
> 1. чем выше квалификация, тем выше загруженность (читай тяжелее
> мотивировать, особенно на срочную работу)

Дело не столько в срочности, сколько в предсказуемости.

Например, что-то предвидится изменить в том же rpm-build-python
или initscripts.  Люди, которые составляют такую команду, могут
выработать рекомендации по прохождению изменения, помогать
индивидуальным майнтейнерам, пакеты которых оно цепляет,
управлять желающими помочь, но имеющими ещё недостаточно опыта
для самостоятельного создания или портирования спеков (это к
слову о janitors / junior jobs и, пожалуй, студентах -- наверное,
и мне было бы интересно с чего-то _полезного_ начать, заодно
посмотрев на то, как какое-либо инфраструктурное изменение
проходит по _разным_ спекам и как на что влияет -- это же
разносторонний опыт!).

И это может быть та же пара недель, а не "на позавчера", да и
"час X" обычно вполне сдвигаем.

> 2. организовать _чёткое_ взаимодействие между людьми не
> являющимися сотрудниками одной организации весьма сложно.

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

> Соответственно основной вопрос -- как мотивировать?

Ну, когда-то можно поиграться и во что-то вроде slashdot ratings
("этот человек знаменит тем, что ведёт NN пакетов, пишет NNN
полезных писем в рассылки в средний месяц и помог N пакаджерам с
их M пакетами").

Но неохота на такие фантики размениваться.

Посему остаётся банальная экономия времени при достижении
индивидуальных целей (ведь у каждого из нас они есть, и обсудить,
почему мы тратим время на Sisyphus -- было бы отдельно интересной
темой; но пусть для начала newsletter стартует).

Например, автору (инициатору) подобного изменения участие в
подобной team по своему направлению может экономить вполне
заметное время, которое иначе придётся потратить на рассеивание
непонимания и всё то же решение предвиденных и не очень, но
возникающих у коллег проблем.

Соответственно, у сочувствующих ему профи (указуя перстом на
Лёшу Морозова, который крайне непредусмотрительно засветился как
оный эксперт и в случае с autotools, и в случае с питоном)
мотивация может быть также схожей -- если есть заинтересованность
в том, чтобы изменение произошло, то может быть смысл и в том,
чтобы оно произошло в разумные сроки с разумной полнотой, а не
зависло между небом и землёй на полгода.

Возвращаясь к началу -- мерой, по которой можно судить об
удачности такого проекта, может быть то, будет ли получаться эта
самая экономия времени.  Вообще говоря, она зависит от:

- количества изменений, требующих такого разбирательства,
  в единицу времени;
- количества пакетов, задеваемых изменением;
- объёма нестандартных (и нескриптуемых) действий над спеками,
  которые необходимы для изменения заданного пакета;
- времени, которое уходит на непродуктивные (социальные,
  снимающие напряжённость etc) обсуждения результатов принятия
  какого-либо изменения (особенно при задержках между изменением
  базы и мигрированием пакетов);
- количества таких вот людей.

Как по мне -- так тот же проект "по питоньей части" был
достаточно грамотно организован (не путать с "идеально") и можно
попробовать это формализовать для использования в будущем.

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

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

[devel] Re: subteams? (was: I: Sisyphus-20041027 unmets)

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

On Sun, Oct 31, 2004 at 08:03:34PM +0200, Michael Shigorin wrote:

 MS> Не претендую (тем паче только что посмотрев "Revolution OS" :)
 MS> К тому же подозреваю, что частично она решена.

Решить её полностью, и задокументировать результат слабо? ;-) 

>> Такая tiger team должна:
>> 1. обладать очень высокой квалификацией
 MS> Да.  Но кое-кто тут в своё время и был замечен ровно за
 MS> высказыванием вида "уровень разработчиков в команде существенно
 MS> выше уровня разработчиков в мире" года два-три тому.

Сие есть факт.

Я бы сказал _много_ выше, ибо средний уровень разработчиков в мире, мягко
скажем, низковат, и за сравнение "просто выше" и обидеться можно :)

Но тут не относительные величины нужны а абсолютные. Человек либо может
решить какие-то проблемы, либо нет.

>> 2. иметь в своём составе хотя бы 1-2 "универсалов" (знающих
>> "почти всё", и способных помочь остальным в интеграции) плюс
>> специалистов в отдельных секторах (таких как языки
>> программирования, отдельные платформы типа KDE/Gnome со всей их
>> инфраструктурой, или kernel team).
 MS> Скорее да.
 MS> Ты упустил ещё одно качество (или включил в универсальность?) --
 MS> кругозор по дистрибутивам.  Бишь "а как это делается в ...",
 MS> что может способствовать стабилизации (вместо бурного роста)
 MS> отечественного велосипедостроения и улучшению стратегической
 MS> интероперабельности на разных уровнях, от конфигурации и опыта
 MS> до пакетов и их "гроздей" (последнее и для портирования спеков
 MS> довольно важно).

Я это действительно упустил.

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

>> 3. (ключевое) иметь очень жёсткую дисциплину и организованность
>> действий.
 MS> Ты только не путай второе с первым.  Вместо первого кажется более
 MS> полезным задокументированная методология и нечто вроде бОльших
 MS> полномочий (например, на NMU по оговоренному алгоритму -- см.,
 MS> например, Debian Policy про дырки и критические баги).

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

Насчёт NMU -- Блин-Ну-Когда-Же-Спеки-Будут-Лежать-В-CVS?

>> Эдакий "мантейнерский спецназ".
MS> Ну, в общем, да.  Только формализованный.  За счёт чего меньше
MS> времени и сил должно уходить в каждом конкретном случае на
MS> переливание из пустого в порожнее и больше -- на собственно дело.

Разумеется.

>> Проблемы:
>> 1. чем выше квалификация, тем выше загруженность (читай тяжелее
>> мотивировать, особенно на срочную работу)
 MS> Дело не столько в срочности, сколько в предсказуемости.
 MS> Например, что-то предвидится изменить в том же rpm-build-python
 MS> или initscripts.  Люди, которые составляют такую команду, могут
 MS> выработать рекомендации по прохождению изменения, помогать
 MS> индивидуальным майнтейнерам, пакеты которых оно цепляет,
 MS> управлять желающими помочь, но имеющими ещё недостаточно опыта
 MS> для самостоятельного создания или портирования спеков (это к
 MS> слову о janitors / junior jobs и, пожалуй, студентах -- наверное,
 MS> и мне было бы интересно с чего-то _полезного_ начать, заодно
 MS> посмотрев на то, как какое-либо инфраструктурное изменение
 MS> проходит по _разным_ спекам и как на что влияет -- это же
 MS> разносторонний опыт!).
 MS> И это может быть та же пара недель, а не "на позавчера", да и
 MS> "час X" обычно вполне сдвигаем.

Опять же, в этом случае у нас получается в центре команды как минимум один
человек специальностей "Хакер" и "Менеджер", который периодами практически
целиком выбывает из деятельности кроме управления/обучения/пинания остальных
членов этой команды.

Такую модель я вижу реализуемой только если ядро этой команды будет сидеть
на зарплате.

>> 2. организовать _чёткое_ взаимодействие между людьми не
>> являющимися сотрудниками одной организации весьма сложно.
 MS> Ну почему, насколько могу судить -- в рамках того же lkml бывают
 MS> достаточно чёткие взаимодействия и без этого условия.

Естественно это возможно. Естественно это часто встречается. Нам этого
мало. Нам нужно чёткий способ воспроизводить некоторый уровень качества
взаимодейства по первой необходимости.
 
>> Соответственно основной вопрос -- как мотивировать?
 MS> Ну, когда-то можно поиграться и во что-то вроде slashdot ratings
 MS> ("этот человек знаменит тем, что ведёт NN пакетов, пишет NNN
 MS> полезных писем в рассылки в средний месяц и помог N пакаджерам с
 MS> их M пакетами").
 MS> Но неохота на такие фантики размениваться.

Угу. С другой стороны как раз для начинающих это, вместе с работой под
руководством более опытного специалиста и может являться хорошим стимулом.
Фактически при таких рейтингах ему проще будет в будущем трудоустроиться.

 MS> Посему остаётся банальная экономия времени при достижении
 MS> индивидуальных целей (ведь у каждого из нас они есть, и обсудить,
 MS> почему мы тратим время на Sisyphus -- было бы отдельно интересной
 MS> темой; но пусть для начала newsletter стартует).
 MS> Например, автору (инициатору) подобного изменения участие в
 MS> подобной team по своему направлению может экономить вполне
 MS> заметное время, которое иначе придётся потратить на рассеивание
 MS> непонимания и всё то же решение предвиденных и не очень, но
 MS> возникающих у коллег проблем.

Понымаешь в чём фишка... Есть навыки, которые ближе уже к менеджерским чем
программерским -- списаться с кем надо, кого-то пнуть по мыло, кого-то
выловить в IM, на кого-то багу повесить. Это надо не только уметь
(научиться этому легко), надо этим _хотеть_ заниматься. Опять же вопрос
мотивации.

Скажем несколько лет назад для меня проще было потратить пару дней на
разбирании и правке чужого кода, чем пару часов на переписку с автором
кода, который может решить проблему, возможно, за несколько минут. И
никакие вопросы эффективности ни могли с этим справится.

Дык вот такому человеку гораздо проще решать вопросы коммуникации если он
входит в официальную team, у которой сейчас есть конкретная
(общеизвестная) задача на текущий момент.

Если кто-то из team напишет мне "нужно поправить такой-то пакет", я,
естественно, скажу "Ok, как время будет". И положу в папочку "сделать в
ближайшие дни". Если же, скажем, мне прийдёт письмо "эти 3 дня посвящены
такому-то изменению в репозитории, и моё торможение будет задерживать весь
процесс или вынуждать других делать моё дело", то обработка этой просьбы у
меня ляжет в папочку "сделать срочно".

 MS> Возвращаясь к началу -- мерой, по которой можно судить об
 MS> удачности такого проекта, может быть то, будет ли получаться эта
 MS> самая экономия времени.  Вообще говоря, она зависит от:
 MS> - количества изменений, требующих такого разбирательства,
 MS>   в единицу времени;
 MS> - количества пакетов, задеваемых изменением;
 MS> - объёма нестандартных (и нескриптуемых) действий над спеками,
 MS>   которые необходимы для изменения заданного пакета;
 MS> - времени, которое уходит на непродуктивные (социальные,
 MS>   снимающие напряжённость etc) обсуждения результатов принятия
 MS>   какого-либо изменения (особенно при задержках между изменением
 MS>   базы и мигрированием пакетов);
 MS> - количества таких вот людей.
 MS> Как по мне -- так тот же проект "по питоньей части" был
 MS> достаточно грамотно организован (не путать с "идеально") и можно
 MS> попробовать это формализовать для использования в будущем.

К сожалению я не наблюдал за процессами происходящими с питоном, потому
как всё руки не доходят его изучить :)

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

http://freesource.info

Re: [devel] Re: subteams? (was: I: Sisyphus-20041027 unmets)

[Alex Ott]

>On Sun, Oct 31, 2004 at 08:03:34PM +0200, Michael Shigorin wrote:
>
> MS> Не претендую (тем паче только что посмотрев "Revolution OS" :)
> MS> К тому же подозреваю, что частично она решена.
>А дисциплина в проектах масштаба больше "полтора человека за одним
>ноутбуком в гараже" и может быть, IMHO, реализована исключительно
>написанием полиси на каждый чих и непрерывной их модификацией под текущие
>реалии.
>
>Насчёт NMU -- Блин-Ну-Когда-Же-Спеки-Будут-Лежать-В-CVS?

это должно касаться не только спеков, но и патчей, и может быть исходников (может конечно не в cvs, но где-то рядом).  Плюс я бы не хотел использовать CVS, а что-нибудь более приспособленное к offline-работе - arch, darcs, monotone и т.п.

Re: [devel] Re: subteams? (was: I: Sisyphus-20041027 unmets)

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

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

On Mon, Nov 01, 2004 at 02:00:26PM +0300, Alex Ott wrote:

 AO> это должно касаться не только спеков, но и патчей, и может быть исходников (может конечно не в cvs, но где-то рядом).  Плюс я бы не хотел использовать CVS, а что-нибудь более приспособленное к offline-работе - arch, darcs, monotone и т.п.

Кто-нибудь хорошо знакомый с этим средствами может дать ссылку на
качественное сравнение между этими средствами?

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

http://freesource.info


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

Re: [devel] Re: subteams? (was: I: Sisyphus-20041027 unmets)

[Alex Ott]

>On Mon, Nov 01, 2004 at 02:00:26PM +0300, Alex Ott wrote:
>
> AO> это должно касаться не только спеков, но и патчей, и может быть исходников (может конечно не в cvs, но где-то рядом).  Плюс я бы не хотел использовать CVS, а что-нибудь более приспособленное к offline-работе - arch, darcs, monotone и т.п.
>
>Кто-нибудь хорошо знакомый с этим средствами может дать ссылку на
>качественное сравнение между этими средствами?

http://better-scm.berlios.de/comparison/
http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison

Re: [devel] Re: subteams? (was: I: Sisyphus-20041027 unmets)

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

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

On Mon, Nov 01, 2004 at 04:17:07PM +0300, Alex Ott wrote:
> AO>> это должно касаться не только спеков, но и патчей, и может быть исходников (может конечно не в cvs, но где-то рядом).  Плюс я бы не хотел использовать CVS, а что-нибудь более приспособленное к offline-работе - arch, darcs, monotone и т.п.
>>Кто-нибудь хорошо знакомый с этим средствами может дать ссылку на
>>качественное сравнение между этими средствами?
 AO> http://better-scm.berlios.de/comparison/
 AO> http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison

Спасибо.

Только svn VS cvs это уже не так интересно, cvs для меня уже давно нечто
obsolete, not recemmended, deprecated и всё такое :) Ибо svn я вопринимаю
как "CVS только лучше".

А вот тот же arch это что-то совсем-совсем другое, в том числе по
workflow. И darcs, и monotone, насколько я понимаю, тоже.

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

http://freesource.info


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

Re: [devel] Re: subteams? (was: I: Sisyphus-20041027 unmets)

[Alex Ott]

>On Mon, Nov 01, 2004 at 04:17:07PM +0300, Alex Ott wrote:
>> AO>> это должно касаться не только спеков, но и патчей, и может быть исходников (может конечно не в cvs, но где-то рядом).  Плюс я бы не хотел использовать CVS, а что-нибудь более приспособленное к offline-работе - arch, darcs, monotone и т.п.
>>>Кто-нибудь хорошо знакомый с этим средствами может дать ссылку на
>>>качественное сравнение между этими средствами?
> AO> http://better-scm.berlios.de/comparison/
> AO> http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison
>
>Спасибо.
>
>Только svn VS cvs это уже не так интересно, cvs для меня уже давно нечто
>obsolete, not recemmended, deprecated и всё такое :) Ибо svn я вопринимаю
>как "CVS только лучше".
>
>А вот тот же arch это что-то совсем-совсем другое, в том числе по
>workflow. И darcs, и monotone, насколько я понимаю, тоже.

да - darcs & arch - очень похожи по назначению, monotone я еще не пробовал.  для меня еще важно, что к arch есть нормальный интерфейс из емакса, под названием xtla

[devel] Re: subteams? (was: I: Sisyphus-20041027 unmets)

[Michael Shigorin]

On Mon, Nov 01, 2004 at 02:00:26PM +0300, Alex Ott wrote:
> >Насчёт NMU -- Блин-Ну-Когда-Же-Спеки-Будут-Лежать-В-CVS?

Ну, это, не поняв, какого фига CVS делает новую версию при commit
файла с тем же содержанием (но другим инодом) -- добавил rsync,
чтоб у него вообще аргументов для выпендрёжа не оставалось.

Но это меньшая сторона проблемы -- r/o repository (циклы доводки
автомата получаются по 2--4 недели -- как не будет спамить, так
хоть будет смысл довешивать анализ и раздачу помимо давно
существующей по http).

> это должно касаться не только спеков, но и патчей, и может быть
> исходников (может конечно не в cvs, но где-то рядом).  Плюс я
> бы не хотел использовать CVS, а что-нибудь более
> приспособленное к offline-работе - arch, darcs, monotone и т.п.

Вчера читал вступления в arch и darcs.  Осталось больше интереса
к последнему, но решил допинать хоть что есть, а не пытаться ещё
раз дойти с нуля до 50%...

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

[devel] [JT] arch, darcs, monotone

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

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

On Mon, Nov 01, 2004 at 09:44:44PM +0200, Michael Shigorin wrote:

 MS> Вчера читал вступления в arch и darcs.  Осталось больше интереса
 MS> к последнему, но решил допинать хоть что есть, а не пытаться ещё
 MS> раз дойти с нуля до 50%...

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

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

http://freesource.info


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

Re: [devel] [JT] Re: subteams?

[Alexey Morozov]

On Mon, Nov 01, 2004 at 02:00:26PM +0300, Alex Ott wrote:
> это должно касаться не только спеков, но и патчей, и может быть
> исходников (может конечно не в cvs, но где-то рядом).  Плюс я бы
> не хотел использовать CVS, а что-нибудь более приспособленное к
> offline-работе - arch, darcs, monotone и т.п.

Перефразируя Терминатора:

He's been back!

Ура!

P.S. По такому случаю не грех и tla завести? ;-)

Re: [devel] Re: subteams? (was: I: Sisyphus-20041027 unmets)

[Alexey Borovskoy]

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

* Понедельник 01 Ноябрь 2004 23:00 "Alex Ott" <ottalex@narod.ru>

> >On Sun, Oct 31, 2004 at 08:03:34PM +0200, Michael Shigorin
> > wrote:
> >
> > MS> Не претендую (тем паче только что посмотрев "Revolution
> > OS" :) MS> К тому же подозреваю, что частично она решена.
> >А дисциплина в проектах масштаба больше "полтора человека за
> > одним ноутбуком в гараже" и может быть, IMHO, реализована
> > исключительно написанием полиси на каждый чих и непрерывной
> > их модификацией под текущие реалии.
> >
> >Насчёт NMU -- Блин-Ну-Когда-Же-Спеки-Будут-Лежать-В-CVS?
>
> это должно касаться не только спеков, но и патчей, и может
> быть исходников (может конечно не в cvs, но где-то рядом). 
> Плюс я бы не хотел использовать CVS, а что-нибудь более
> приспособленное к offline-работе - arch, darcs, monotone и
> т.п.

А subversion здесь не подходит?

-- 
Алексей.
GPG key fingerprint
DBB3 1832 13C6 5C96 4A58  4AFF 78F7 159F 66AD 8D7E

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

Re: [devel] Re: subteams?

[Ivan Fedorov]

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

Alexey Borovskoy пишет:

>>>MS> Не претендую (тем паче только что посмотрев "Revolution
>>>OS" :) MS> К тому же подозреваю, что частично она решена.
>>>А дисциплина в проектах масштаба больше "полтора человека за
>>>одним ноутбуком в гараже" и может быть, IMHO, реализована
>>>исключительно написанием полиси на каждый чих и непрерывной
>>>их модификацией под текущие реалии.
>>>
>>>Насчёт NMU -- Блин-Ну-Когда-Же-Спеки-Будут-Лежать-В-CVS?
>>
>>это должно касаться не только спеков, но и патчей, и может
>>быть исходников (может конечно не в cvs, но где-то рядом). 
>>Плюс я бы не хотел использовать CVS, а что-нибудь более
>>приспособленное к offline-работе - arch, darcs, monotone и
>>т.п.
> 
> А subversion здесь не подходит?

Нет, но на базе svn, есть какая-то поделка svk...
Все хочу ее поглядеть, но некогда.

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

Re: [devel] Re: subteams? (was: I: Sisyphus-20041027 unmets)

[Alex Ott]

>* Понедельник 01 Ноябрь 2004 23:00 "Alex Ott" <ottalex@narod.ru>
>> это должно касаться не только спеков, но и патчей, и может
>> быть исходников (может конечно не в cvs, но где-то рядом). 
>> Плюс я бы не хотел использовать CVS, а что-нибудь более
>> приспособленное к offline-работе - arch, darcs, monotone и
>> т.п.
>
>А subversion здесь не подходит?

нет - svn --- это cvs на стероидах, он подразумевает наличие центрального репозитория. есть правда примочка для организации распределенной работы, но это так - не особо правильно, поскольку распределенная работа не учитывалась сразу при проектировании системы, в отличии от перечисленных выше систем

[devel] Re: subteams?

[Vitaly Ostanin]

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

Alex Ott пишет:

>>* Понедельник 01 Ноябрь 2004 23:00 "Alex Ott" <ottalex@narod.ru>
>>    
>>
>>>это должно касаться не только спеков, но и патчей, и может
>>>быть исходников (может конечно не в cvs, но где-то рядом). 
>>>Плюс я бы не хотел использовать CVS, а что-нибудь более
>>>приспособленное к offline-работе - arch, darcs, monotone и
>>>т.п.
>>>      
>>>
>>А subversion здесь не подходит?
>>    
>>
>
>нет - svn --- это cvs на стероидах, он подразумевает наличие центрального репозитория. есть правда примочка для организации распределенной работы, но это так - не особо правильно, поскольку распределенная работа не учитывалась сразу при проектировании системы, в отличии от перечисленных выше систем
>  
>

А можно пальцем ткнуть - с кем из вышеперечисленных стоит поковыряться 
для начала? Взялся за subversion, а он, оказывается, "не особо правильно"...

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


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

Re: [devel] Re: subteams?

[Ivan Fedorov]

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

Vitaly Ostanin пишет:

>>>> это должно касаться не только спеков, но и патчей, и может
>>>> быть исходников (может конечно не в cvs, но где-то рядом). Плюс я бы
>>>> не хотел использовать CVS, а что-нибудь более
>>>> приспособленное к offline-работе - arch, darcs, monotone и
>>>> т.п.
>>>
>>> А subversion здесь не подходит?
>>
>> нет - svn --- это cvs на стероидах, он подразумевает наличие
>> центрального репозитория. есть правда примочка для организации
>> распределенной работы, но это так - не особо правильно, поскольку
>> распределенная работа не учитывалась сразу при проектировании системы,
>> в отличии от перечисленных выше систем
>>  
> А можно пальцем ткнуть - с кем из вышеперечисленных стоит поковыряться
> для начала? Взялся за subversion, а он, оказывается, "не особо
> правильно"...
Ну вообще-то оно вполне правильно... просто для других задач... я вот
пользуюсь, и не жалуюсь. Для него в сизифе есть GUI - eSvn.

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

Re: [devel] Re: subteams?

[Alex Ott]

>Alex Ott пишет:
>>>>это должно касаться не только спеков, но и патчей, и может
>>>>быть исходников (может конечно не в cvs, но где-то рядом). 
>>>>Плюс я бы не хотел использовать CVS, а что-нибудь более
>>>>приспособленное к offline-работе - arch, darcs, monotone и
>>>>т.п.
>>>>      
>>>>
>>>А subversion здесь не подходит?
>>>    
>>>
>>
>>нет - svn --- это cvs на стероидах, он подразумевает наличие центрального репозитория. есть правда примочка для организации распределенной работы, но это так - не особо правильно, поскольку распределенная работа не учитывалась сразу при проектировании системы, в отличии от перечисленных выше систем
>>  
>>
>
>А можно пальцем ткнуть - с кем из вышеперечисленных стоит поковыряться 
>для начала? Взялся за subversion, а он, оказывается, "не особо правильно"...

я пользуюсь tla, но его достаточно тяжело осваивать
посмотрите на darcs

но честно предупреждаю -= они отличаются по идеологии, так что может быть непривычно при начале работы с ними

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

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

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

On Sun, Oct 31, 2004 at 01:11:50AM +0400, Andrey Orlov wrote:

>> По прошествию чёрт-знает-какого количества времени опять заведём разговор
>> на тему "автоматичиеская проверка пакета, попадающего в Сизиф, не
>> сломается ли из-за него что-нибудь"?

AO> Сдается мне, что это спор не о том, о чем надо. Ибо не так важно знать, что сломается,
AO> сколь важно иметь стандартизованную политику, определяющую, что делать, если сломалось.

Политика должна быть простой -- пакет не пропускается в Сизиф (как
общедоступный репозиторий) и ожидает того момента, когда он таки сможет
туда попасть. Естественно автоматически.

[skip]

С вышескпинутым согласен.

 AO> Как близкий сердцу пример - rpm-build-python. Новая версия лежит в дедале почти месяц. Кто-то проверил
 AO> свой пакет? 

IMHO в подобное ситуации проще тебе написать скриптик-тест, и прогнать
через него все пакеты. В данном случае ты вносишь изменения, которые могут
привести к тому, что сломаются чьи-то пакеты.

Этот подход плох только в одном -- давит инициативу глобальных улучшизмов.

В идеале я вижу процесс таким -- заливается новый пакет в Сизиф. В ответ
присылается отлуп "пакет ломает сборку такого-то списка пакетов", и сам
пакет остаётся в SRPMS.incoming. Если в течении суток не залит изменённый
пакет, то пинки рассылаются всем авторам сломаных пакетов (с URL на лог
сборки). И до тех, пока все они не пересоберут свои пакеты, новый пакет из
.incoming в .classic не переползёт.

А через две недели после начала этого процесса начинается выяснение
отношений с мантейнерами, виноватыми в блокировании обновления. И, в
большинстве случаев, проблема может быть решена NMU.

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

http://freesource.info


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

[devel] .incoming revisited

[Michael Shigorin]

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

On Sun, Oct 31, 2004 at 07:54:57PM +0300, Денис Смирнов wrote:
> >> сломается ли из-за него что-нибудь"?
> > Сдается мне, что это спор не о том, о чем надо. Ибо не так
> > важно знать, что сломается, сколь важно иметь
> > стандартизованную политику, определяющую, что делать, если
> > сломалось.

Вообще-то для неё это знание является prerequisite.

> Политика должна быть простой -- пакет не пропускается в Сизиф
> (как общедоступный репозиторий) и ожидает того момента, когда
> он таки сможет туда попасть. Естественно автоматически.

Насколько понимаю ситуацию -- это недопустимо категорично.
А tradeoff -- штука тяжкая и неавтоматизируемая в общем случае.

> В идеале я вижу процесс таким -- заливается новый пакет в
> Сизиф. В ответ присылается отлуп "пакет ломает сборку такого-то
> списка пакетов", и сам пакет остаётся в SRPMS.incoming. Если в
> течении суток не залит изменённый пакет, то пинки рассылаются
> всем авторам сломаных пакетов (с URL на лог сборки). И до тех,
> пока все они не пересоберут свои пакеты, новый пакет из
> .incoming в .classic не переползёт.

Ну, об этом уже два круга пройдено, но пока удалось только
разъяснить Диме собственно суть предложения (и то за чаем).
А от этого до реализации ещё пилить и пилить.  Поможем legion@?

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

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

[devel] Re: .incoming revisited

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

On Sun, Oct 31, 2004 at 07:00:41PM +0200, Michael Shigorin wrote:

>> Политика должна быть простой -- пакет не пропускается в Сизиф
>> (как общедоступный репозиторий) и ожидает того момента, когда
>> он таки сможет туда попасть. Естественно автоматически.
 MS> Насколько понимаю ситуацию -- это недопустимо категорично.
 MS> А tradeoff -- штука тяжкая и неавтоматизируемая в общем случае.

Сейчас пакет пропускается ручками.
Кроме того сейчас не выполняется тестов "чью сборку сломает этот пакет".
Почему задержка в неделю-две недопустима категорично?

>> В идеале я вижу процесс таким -- заливается новый пакет в
>> Сизиф. В ответ присылается отлуп "пакет ломает сборку такого-то
>> списка пакетов", и сам пакет остаётся в SRPMS.incoming. Если в
>> течении суток не залит изменённый пакет, то пинки рассылаются
>> всем авторам сломаных пакетов (с URL на лог сборки). И до тех,
>> пока все они не пересоберут свои пакеты, новый пакет из
>> .incoming в .classic не переползёт.
 MS> Ну, об этом уже два круга пройдено, но пока удалось только
 MS> разъяснить Диме собственно суть предложения (и то за чаем).
 MS> А от этого до реализации ещё пилить и пилить.  Поможем legion@?

Поможем. Чем сможем :)

Только вот пока удаётся объяснить суть лишь за чаем -- это означает что
сама мысль сформулирована неидеально. Меня не хватет написать на эту тему
какое-то чётко сформулированое и обоснованое нечто.

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

http://freesource.info

[devel] Re: .incoming revisited

[Michael Shigorin]

On Sun, Oct 31, 2004 at 08:21:38PM +0300, Денис Смирнов wrote:
> Сейчас пакет пропускается ручками.  Кроме того сейчас не
> выполняется тестов "чью сборку сломает этот пакет".

С чего ты взял?

ldv@ если не здесь, то в sisyphus@ летом, кажется, излагал
обычную процедуру, а также точки ветвления при возникающих (и
проверяемых на "офисном Sisyphus", который "впереди планеты
всей") unmets.

> Почему задержка в неделю-две недопустима категорично?

Потому что замкнутый круг.  В Daedalus ходоки немноги (насколько
могу судить), соответственно шорох начинается, когда петух таки
клюнет.

> Только вот пока удаётся объяснить суть лишь за чаем -- это
> означает что сама мысль сформулирована неидеально.

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

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

[devel] Re: .incoming revisited

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

On Sun, Oct 31, 2004 at 08:08:48PM +0200, Michael Shigorin wrote:
>> Сейчас пакет пропускается ручками.  Кроме того сейчас не
>> выполняется тестов "чью сборку сломает этот пакет".
 MS> С чего ты взял?
 MS> ldv@ если не здесь, то в sisyphus@ летом, кажется, излагал
 MS> обычную процедуру, а также точки ветвления при возникающих (и
 MS> проверяемых на "офисном Sisyphus", который "впереди планеты
 MS> всей") unmets.

Вот в упор не видел там "добавить пакет во временный репозиторий и
попытаться пересобрать все напрямую зависящие от него пакеты". Может
просто не увидел :(

>> Почему задержка в неделю-две недопустима категорично?
 MS> Потому что замкнутый круг.  В Daedalus ходоки немноги (насколько
 MS> могу судить), соответственно шорох начинается, когда петух таки
 MS> клюнет.

Дык вопрос-то не в тестировании установки, вопрос в тестировании сборки.
Автоматической. С рассылкой уведомлений.

>> Только вот пока удаётся объяснить суть лишь за чаем -- это
>> означает что сама мысль сформулирована неидеально.
 MS> Увы, нет.  Впрочем, в ходе конкретно того обсуждения всплыли и
 MS> дополнительные детали, о которых не подумал заранее, но главная
 MS> проблема была не в них.  (что самое паршивое -- и не помню уж)

:(

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

http://freesource.info

[devel] Re: .incoming revisited

[Michael Shigorin]

On Mon, Nov 01, 2004 at 02:58:15PM +0300, Денис Смирнов wrote:
>  MS> ldv@ если не здесь, то в sisyphus@ летом, кажется, излагал
>  MS> обычную процедуру, а также точки ветвления при возникающих (и
>  MS> проверяемых на "офисном Sisyphus", который "впереди планеты
>  MS> всей") unmets.
> Вот в упор не видел там "добавить пакет во временный
> репозиторий и попытаться пересобрать все напрямую зависящие от
> него пакеты". Может просто не увидел :(

Прямо или косвенно, но это звучало. (примерно в форме
"попробовать пересобрать то, что сломалось")

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

[devel] Re: .incoming revisited

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

On Mon, Nov 01, 2004 at 09:11:27PM +0200, Michael Shigorin wrote:
>  MS>> ldv@ если не здесь, то в sisyphus@ летом, кажется, излагал
>  MS>> обычную процедуру, а также точки ветвления при возникающих (и
>  MS>> проверяемых на "офисном Sisyphus", который "впереди планеты
>  MS>> всей") unmets.
>> Вот в упор не видел там "добавить пакет во временный
>> репозиторий и попытаться пересобрать все напрямую зависящие от
>> него пакеты". Может просто не увидел :(
 MS> Прямо или косвенно, но это звучало. (примерно в форме
 MS> "попробовать пересобрать то, что сломалось")

Сломалась _установка_ и сломалась _сборка_ это две большие разницы.

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

http://freesource.info

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

[Andrey Orlov]

On Sunday 31 October 2004 19:54, Денис Смирнов wrote:
> В идеале я вижу процесс таким -- заливается новый пакет в Сизиф. В ответ
> присылается отлуп "пакет ломает сборку такого-то списка пакетов", и сам
> пакет остаётся в SRPMS.incoming. Если в течении суток не залит изменённый
> пакет, то пинки рассылаются всем авторам сломаных пакетов (с URL на лог
> сборки). И до тех, пока все они не пересоберут свои пакеты, новый пакет из
> .incoming в .classic не переползёт.
> 
> А через две недели после начала этого процесса начинается выяснение
> отношений с мантейнерами, виноватыми в блокировании обновления. И, в
> большинстве случаев, проблема может быть решена NMU.

Денис, это так и было, практически. Только вместо SRPMS.incoming был дедал.

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

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

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

[Alexey I. Froloff]

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

* Andrey Orlov <cray@> [041101 15:31]:
> Кроме того, новая версия python 2.4 уже на подходе. Пакет лежит
> в дедале.
О, кстати!  Как в новом питоне обстоит дело с libpython2.4.{so,a} ?

-- 
Regards, Sir Raorn.
-------------------
Мне это имя [ALT], знаете ли, дорого. Почти как свое собственное.
		-- aen in talk-room@

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

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

[Andrey Orlov]

On Monday 01 November 2004 16:05, Alexey I. Froloff wrote:
> * Andrey Orlov <cray@> [041101 15:31]:
> > Кроме того, новая версия python 2.4 уже на подходе. Пакет лежит
> > в дедале.
> О, кстати!  Как в новом питоне обстоит дело с libpython2.4.{so,a} ?

В ченжлоге написано, кажется. Если кратко - то как договаривались. Кстати в 2.3.4 тоже.
Как только последний переедет в сизиф - можно закрывать вопрос.

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

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

[Dmitry V. Levin]

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

On Sat, Oct 30, 2004 at 10:19:14PM +0400, Денис Смирнов wrote:
> On Sat, Oct 30, 2004 at 10:07:57PM +0400, Alexander Bokovoy wrote:
> 
>  AB> В отношении Самбы не принимаю, ибо этот пакет пересобирается, будучи
>  AB> написанным практически исключительно на C. Вопрос скорее в том, что ряд
>  AB> пакетов обновляется без проверки на то, сломаются ли использующие его
>  AB> пакеты или нет.
> 
> По прошествию чёрт-знает-какого количества времени опять заведём разговор
> на тему "автоматичиеская проверка пакета, попадающего в Сизиф, не
> сломается ли из-за него что-нибудь"?

Что касается ocaml, то ещё до сборки было ясно, что всё сломается.


-- 
ldv

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

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

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

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

On Sun, Oct 31, 2004 at 01:11:52PM +0300, Dmitry V. Levin wrote:

 AB>>> В отношении Самбы не принимаю, ибо этот пакет пересобирается, будучи
 AB>>> написанным практически исключительно на C. Вопрос скорее в том, что ряд
 AB>>> пакетов обновляется без проверки на то, сломаются ли использующие его
 AB>>> пакеты или нет.
 >> По прошествию чёрт-знает-какого количества времени опять заведём разговор
 >> на тему "автоматичиеская проверка пакета, попадающего в Сизиф, не
 >> сломается ли из-за него что-нибудь"?
 DVL> Что касается ocaml, то ещё до сборки было ясно, что всё сломается.

Вот я и мечтаю о том, чтобы пакет автоматически придерживался до тех пор,
пока не будет обновлено всё, что он ломает.

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

http://freesource.info


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

[devel] .incoming revisited

[Michael Shigorin]

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

On Sun, Oct 31, 2004 at 08:07:59PM +0300, Денис Смирнов wrote:
> Вот я и мечтаю о том, чтобы пакет автоматически придерживался
> до тех пор, пока не будет обновлено всё, что он ломает.

Иными словами, "форева"...  Собственно, я потому и предлагал
.incoming как "буфер для пересборки кластеров пакетов", что
размышления по теме не показали иных разумных и дешёвых
вариантов.  Правда, на полный охват не претендую :-)

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

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

[devel] Re: .incoming revisited

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

On Sun, Oct 31, 2004 at 07:09:06PM +0200, Michael Shigorin wrote:
>> Вот я и мечтаю о том, чтобы пакет автоматически придерживался
>> до тех пор, пока не будет обновлено всё, что он ломает.
 MS> Иными словами, "форева"...  Собственно, я потому и предлагал
 MS> .incoming как "буфер для пересборки кластеров пакетов", что
 MS> размышления по теме не показали иных разумных и дешёвых
 MS> вариантов.  Правда, на полный охват не претендую :-)

Дык я ту же идею и пропагандирую :)

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

http://freesource.info

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

[Andrey Orlov]

On Saturday 30 October 2004 08:55, Alexey Morozov wrote:
> На самом деле, скриптовый (или, по крайней мере, "сильно managed") язык для
> _платформы_ - это хорошо. И санки это, вроде как понимали (причем,
> давно, еще во времена взлета популярности тикля, то есть, году в 96),
> но сделать толком так ничего и не сделали...

Я, может быть, что-то путаю, но сдается мне, что санки  к тиклю имеют только то
отношение, что одно время там работал дядька Астернаут, который свалил оттуда сразу,
как понял что санкам его эксперименты & великие идеи как зайцу стоп сигнал на хвосте 
(собственно так же, как и опенсорсе). И, опять же насколько я помню, Астернаут & Тикль - 
не единственный случай, имевший местро примерно в это же время и в том же месте.

> А MS, в то же самое время, имела у себя на платформе целый спектр языков
> для "простых [индийских] парней и (в особенности, хе-хе) девчонок", начиная
> от VB, и заканчивая каким-нибудь FoxPro, на котором оффшорно колбасили мои
> знакомцы, по крайней мере, до позапрошлого года.

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

> И сейчас они с дот-нетом со своим делают примерно то же самое - двигают
> _платформу_. И хотя, скорее всего, основная масса этих самых

Ладно, сдается мне что этот спор построенный на утверждениях типа "а сейчас они делают
то же самое что и раньше, а раньше они делали правильнее, чем те, кто делал неправильно" мне
скучен по определению.

> > > однозначно связывать выход python 2.4 с уничтожением python-2.3 в
> > Этот тезис я не понял.
> :-)) Для осознания этого тезиса советую проследить работоспособность
> и/или собираемость последних версий Zope, samba и ocaml _в Сизифе_...
> Хотя, конечно, мне стоило вместо "выход python 2.4" выразиться
> "НЕвыход [стабильного] python 2.4" :-)

Тезис все равно не понятен. Zope 2.8b1 лежит в инкоминге дедала. Питон 2.4 - в работе.
rpm-build-python ждет в настоящий момент твоего участия, если честно.
Может быть стоило бы приложить силу ума на выработку общей стратегии,
под названием "чего мы хотим от питона в дистрибутиве", но чгря я даже не знаю,
с чего бы это начать. Может ты знаешь? 

> > А то, что после выхода 2.4., я стану горячим противником наличия 2.2,
> > я вам обещаю ;). Кстати, в моей конторе ощутимое кол-во программеров
> Медом намазано? ;-)

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

> > Кстати, Z2.8 собран с ZODB3.3. И без extensionclass. Я уже в пути -
> :-) И вспомнив наш предыдущий разговор на эту тему:
> There should be laughter after pain

Я лирику и по-русски-то не понимаю ;), а уж по английски....

Так что предпочел бы увидеть какие-то явные пожелания / предложения, 
а не выражение эмоций, посредством цитирования малопонятных виршей 
неизвестного мне автора на языке вероятного противника.

> > Z2.8 должен уже лежать в дедале.
> Ну, хорошо. Сейчас, взлетим уже на старом (неделя осталась), и я
> буду его смотреть :-)

Давай. Чгря, мне его "как Zope" тяжело смотреть, я сам Zope не пользуюсь,
а компании, которые оплачивают его поддержку плотно застряли на 2.6 - 2.7.
Во всяком случае, пока плон не поднимется на 2.8 - им пользоваться не будут.

А вот ZODB3.3 это, конечно, большой шаг вперед. Прощай ExtensionClass ;). 
Я уже начал перепирать свои коды туда.

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

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

[Michael Shigorin]

On Sun, Oct 31, 2004 at 12:52:42AM +0400, Andrey Orlov wrote:
> Астернаут

Остерхут. :)

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

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

[Andrey Orlov]

On Sunday 31 October 2004 09:14, Michael Shigorin wrote:
> On Sun, Oct 31, 2004 at 12:52:42AM +0400, Andrey Orlov wrote:
> > Астернаут
> Остерхут. :)

Да. Похоже на то. Но суть не в произношении.

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

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

[Andrey Orlov]

On Sunday 31 October 2004 09:14, Michael Shigorin wrote:
> On Sun, Oct 31, 2004 at 12:52:42AM +0400, Andrey Orlov wrote:
> > Астернаут
> Остерхут. :)

Да. Похоже на то. А по остальным вопросам, я  так понимаю, разногласий нет.

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

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

[Alexey Morozov]

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

On Sun, Oct 31, 2004 at 12:52:42AM +0400, Andrey Orlov wrote:
> > _платформы_ - это хорошо. И санки это, вроде как понимали (причем,
> > давно, еще во времена взлета популярности тикля, то есть, году в 96),
> > но сделать толком так ничего и не сделали...
> Я, может быть, что-то путаю, но сдается мне, что санки  к тиклю имеют
> только то > отношение, что одно время там работал дядька Астернаут,
> который свалил оттуда сразу,
Вот в это, романтическое время тикль [пытался] называться санскрипт,
и, натурально, продвигался [санками] как "language for the rest of us"
;-)


> как понял что санкам его эксперименты & великие идеи как зайцу стоп
> сигнал на хвосте  (собственно так же, как и опенсорсе). И, опять же
> насколько я помню, Астернаут & Тикль - не единственный случай, имевший
> местро примерно в это же время и в том же месте.
Ну, вот я про это и говорю :-)

> > А MS, в то же самое время, имела у себя на платформе целый спектр языков
> > для "простых [индийских] парней и (в особенности, хе-хе) девчонок", начиная
> > от VB, и заканчивая каким-нибудь FoxPro, на котором оффшорно колбасили мои
> > знакомцы, по крайней мере, до позапрошлого года.
> По-моему все имели "целый спектр" языков. В т.ч. юниксы, и даже в
> особенности юниксы.

> Году эдак в 95ом, когда я сильно увлекался сравнительным изучением разных
> языков, в особенности скриптовых, я на линухе перепробовал их несколько
> десятков, а вот на МС, кроме неск.  "промышленных" платформ, исковерканных
> до полного разрушения идеологии какими-то тупыми усовершенствованиями,
> не было ни чего. 
Речь как раз о том, что в MS это было промышленной платформой, со всеми
плюсами и минусами, а в линуксе - state of the art для господина Wall'а
с сотоварищи. Но для линукса этот just for fun - естественный, и,
вероятно, самый разумный подход. А санки все время упирали на
"промышленность".


> скучен по определению.
Ok ;-)

> > Хотя, конечно, мне стоило вместо "выход python 2.4" выразиться
> > "НЕвыход [стабильного] python 2.4" :-)
> 
> Тезис все равно не понятен. Zope 2.8b1 лежит в инкоминге дедала.
> Питон 2.4 - в работе.
Проехали. Объяснять шутки - тупое и неблагодарное занятие :-)

> rpm-build-python ждет в настоящий момент твоего участия, если честно.
Ok.

> под названием "чего мы хотим от питона в дистрибутиве", но чгря я даже не знаю,
> с чего бы это начать. Может ты знаешь?
Я хотел бы его в бэйзсистем, собственно, и пытался тут некоторое время
назад митинговать, но, вероятно, достаточно бестолково и бессистемно.

Впрочем, для себя я его туда даже занес :-) Не без пользы для себя :-)

> > > А то, что после выхода 2.4., я стану горячим противником наличия 2.2,
> > > я вам обещаю ;). Кстати, в моей конторе ощутимое кол-во программеров
> > Медом намазано? ;-)
> 
> По их утверждениям - ощутимый прорыв вперед по производительности (в т.ч.
> благодаря тому, что ощутимую часть кода переперли на C), плюс некие
Лучше бы JIT улучшали :-/

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

> > > Кстати, Z2.8 собран с ZODB3.3. И без extensionclass. Я уже в пути -
> > :-) И вспомнив наш предыдущий разговор на эту тему:
> > There should be laughter after pain
> Я лирику и по-русски-то не понимаю ;), а уж по английски....
В общем, я попытаюсь НЕлирикой и, э-э-э, по-рус^H^H^H, на языке,
которым разговаривают в Москве:

Все будет хАрАшо, все будет хАрАшо,
все будет хАрАшо, я это знаю...


> Так что предпочел бы увидеть какие-то явные пожелания / предложения, 
> а не выражение эмоций, посредством цитирования малопонятных виршей 
> неизвестного мне автора на языке вероятного противника.
:-)) Пессимисты учат китайский, вообще-то :-).
Автор - вероятно, Марк Ноппфлер (Mark Knoppfler / Dire Straits).
Возможно, тебе больше понравился бы Боб Марли, но вряд ли :-)
А ничего лучшего в тот момент не всплыло...

> > Ну, хорошо. Сейчас, взлетим уже на старом (неделя осталась), и я
> > буду его смотреть :-)
> Давай. Чгря, мне его "как Zope" тяжело смотреть, я сам Zope не пользуюсь,
> а компании, которые оплачивают его поддержку плотно застряли на 2.6 - 2.7.
> Во всяком случае, пока плон не поднимется на 2.8 - им пользоваться не будут.
:-) Ну, мне проще, у меня есть еще твистед, а там все... прозрачнее.


> А вот ZODB3.3 это, конечно, большой шаг вперед. Прощай ExtensionClass ;). 
> Я уже начал перепирать свои коды туда.
:-)


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

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

[Andrey Orlov]

On Monday 01 November 2004 09:45, Alexey Morozov wrote:
> Вот в это, романтическое время тикль [пытался] называться санскрипт,
> и, натурально, продвигался [санками] как "language for the rest of us"
> ;-)

У меня тоже было романтическое время, когда склепанный для личного интереса
продукт я пытался называть <название конторы><продукт>. Дальше было как у Остерхута,
только масштабы поменьше да и кушать раньше захотелось :).

Больше я так не поступаю, и хотя свои разработки веду, но с работодателями 
веду уже другие переговоры.

> > Тезис все равно не понятен. Zope 2.8b1 лежит в инкоминге дедала.
> > Питон 2.4 - в работе.
> Проехали. Объяснять шутки - тупое и неблагодарное занятие :-)

Ну извини. Серъезная я сегодня Ж;)

> > под названием "чего мы хотим от питона в дистрибутиве", но чгря я даже не знаю,
> > с чего бы это начать. Может ты знаешь?
> Я хотел бы его в бэйзсистем, собственно, и пытался тут некоторое время
> назад митинговать, но, вероятно, достаточно бестолково и бессистемно.

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

> > По их утверждениям - ощутимый прорыв вперед по производительности (в т.ч.
> > благодаря тому, что ощутимую часть кода переперли на C), плюс некие
> Лучше бы JIT улучшали :-/

Это в пайтон-дев ;)

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

Пыль в глаза - это мы можем ;)

> > Так что предпочел бы увидеть какие-то явные пожелания / предложения, 
> > а не выражение эмоций, посредством цитирования малопонятных виршей 
> > неизвестного мне автора на языке вероятного противника.
> :-)) Пессимисты учат китайский, вообще-то :-).

Причем уже лет двести ;). 

> Автор - вероятно, Марк Ноппфлер (Mark Knoppfler / Dire Straits).
> Возможно, тебе больше понравился бы Боб Марли, но вряд ли :-)
> А ничего лучшего в тот момент не всплыло...

Мндя. Ты обо мне очень высокого мнения. Я ничего интеллектуальнее 
"Anal Cunt" и "Casualties" не слушаю ;) (поклонникам Dire Straits искать 
треки не советую ;) )

> > А вот ZODB3.3 это, конечно, большой шаг вперед. Прощай ExtensionClass ;). 
> > Я уже начал перепирать свои коды туда.
> :-)

Stay Alive! ;)

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

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

[Ivan Fedorov]

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

Andrey Orlov пишет:
>>>под названием "чего мы хотим от питона в дистрибутиве", но чгря я даже не знаю,
>>>с чего бы это начать. Может ты знаешь?
>>
>>Я хотел бы его в бэйзсистем, собственно, и пытался тут некоторое время
>>назад митинговать, но, вероятно, достаточно бестолково и бессистемно.
> 
> 
> Я тоже был бы за, но более ценным представляется выковырять оттуда перл
> и поддерживать в обезперленном состоянии. Если ради этого надо пожертвовать
> питоном - что делать, тут я политику партии одобряю: отсутствующий питон, если понадобится, я поставлю, 
> а вот присутствующий перл, если его не выковырять, я не снесу.
Ну давайте, как только появятся действия к удалению perl, вносить
насильно python... ;)

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

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

[Andrey Orlov]

On Monday 01 November 2004 16:27, Ivan Fedorov wrote:
> > Я тоже был бы за, но более ценным представляется выковырять оттуда перл
> > и поддерживать в обезперленном состоянии. Если ради этого надо пожертвовать
> > питоном - что делать, тут я политику партии одобряю: отсутствующий питон, если понадобится, я поставлю, 
> > а вот присутствующий перл, если его не выковырять, я не снесу.
> Ну давайте, как только появятся действия к удалению perl, вносить
> насильно python... ;)

Лучше объеденить усилия - т.е. удалять оттуда все, что там появляется, и наше и ваше. Убей их всех.

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Alexey Morozov]

On Mon, Nov 01, 2004 at 04:13:41PM +0300, Andrey Orlov wrote:
> Больше я так не поступаю, и хотя свои разработки веду, но с работодателями 
> веду уже другие переговоры.
:-)

> > Я хотел бы его в бэйзсистем, собственно, и пытался тут некоторое время
> > назад митинговать, но, вероятно, достаточно бестолково и бессистемно.
> Я тоже был бы за, но более ценным представляется выковырять оттуда перл
> и поддерживать в обезперленном состоянии. Если ради этого надо пожертвовать
> питоном - что делать, тут я политику партии одобряю: отсутствующий питон,
> если понадобится, я поставлю, а вот присутствующий перл, если его не
> выковырять, я не снесу.
Идея была гораздо проще: все эти околосистемные скрипты (hotplug, sys.
maintainance) сейчас надо писать или на sh или на C(возможно с
крестами). И для того, и для другого лично я, н-р, достаточно ленив и,
к тому же, мне такая деятельность кажется контрпродуктивной. Но поскольку 
остальные думают иначе, то и разговаривать, вероятно, не о чем. А выбор
конкретного языка - дело десятое, вон в дебиане используется перл на всю
катушку, и ничего, живые до сих пор...

> > Лучше бы JIT улучшали :-/
> Это в пайтон-дев ;)
:-)

> Пыль в глаза - это мы можем ;)
:-)

> > > неизвестного мне автора на языке вероятного противника.
> > :-)) Пессимисты учат китайский, вообще-то :-).
> Причем уже лет двести ;). 
Господь миловал от двухсот лет изучения китайского.

> Мндя. Ты обо мне очень высокого мнения. Я ничего интеллектуальнее 
> "Anal Cunt" и "Casualties" не слушаю ;) (поклонникам Dire Straits искать 
> треки не советую ;) )
Мне сложно сказать, чей я поклонник. Не далее как вчера человек
опознавал мой стол, как "тот, на котором лежат почти все записи Tull'а"
;-). Правда, должен сказать, что мое ...знакомство с ..."брутальной"
музыкой практически ограничивается совместным концертом, если это можно так
назвать, Моррисона и Хендрикса, на котором пьяный в дым Моррисон, когда
ему удавалось доползти до микрофона, орал <вырезано цензурой> оскорбления
слушателям, Хендрикс выхватывал микрофон, и быстро-быстро, пока Моррисон
опять не добрался до микрофона, чего-то наигрывал. Слушатели были в
восторге :-). А, ну и знакомец в фэмэша ГО орал после отбоя, и незадолго
до по подъема, но это уже очень давно все было :-). And when Harry was a
young man, well, he could walk on air...

Теперь пару слов по существу вопроса ;-): я тут уже переговаривал с
Иваном Федоровым относительно "будущего python-полиси". Собственно
говоря, в данный момент меня практически полностью устраивает нынешнее
положение (только вот разобраться с аккуратным насчетом зависимостей, и
закрыть те вопросы, которые ты описал в давешнем TODO). Если хочется
двигаться куда-то еще, пусть заинтересованные выскажут, чего бы им
хотелось.

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Andrey Orlov]

On Tuesday 02 November 2004 10:27, Alexey Morozov wrote:
> к тому же, мне такая деятельность кажется контрпродуктивной. Но поскольку 
> остальные думают иначе, то и разговаривать, вероятно, не о чем. А выбор
> конкретного языка - дело десятое, вон в дебиане используется перл на всю
> катушку, и ничего, живые до сих пор...

Да, но я не понимаю, почему если я пишу на питоне, я должен ставить перл ;)?
Я полагаю, что будь наоборот, аналогичное недоумение выскажут перлисты.
А вариант sh+awk+sed является нейтральной територией и устраивает всех.

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

> Теперь пару слов по существу вопроса ;-): я тут уже переговаривал с
> Иваном Федоровым относительно "будущего python-полиси". Собственно
> говоря, в данный момент меня практически полностью устраивает нынешнее
> положение (только вот разобраться с аккуратным насчетом зависимостей, и
> закрыть те вопросы, которые ты описал в давешнем TODO). Если хочется
> двигаться куда-то еще, пусть заинтересованные выскажут, чего бы им
> хотелось.

Призрак бродит по сизифу ;), ты не чувствуешь его скользкий и холодный хвост?

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Anton Farygin]

Andrey Orlov пишет:
> On Tuesday 02 November 2004 10:27, Alexey Morozov wrote:
> 
>>к тому же, мне такая деятельность кажется контрпродуктивной. Но поскольку 
>>остальные думают иначе, то и разговаривать, вероятно, не о чем. А выбор
>>конкретного языка - дело десятое, вон в дебиане используется перл на всю
>>катушку, и ничего, живые до сих пор...
> 
> 
> Да, но я не понимаю, почему если я пишу на питоне, я должен ставить перл ;)?
> Я полагаю, что будь наоборот, аналогичное недоумение выскажут перлисты.
> А вариант sh+awk+sed является нейтральной територией и устраивает всех.
> 
> Переписывание хотплугов и sysv-init - задача интресная, но, как и любое переписывание,
> только в том случае, если рождается что-то принципиально новое. А те же скрипты только на питоне -
> как-то это, гм, смахивает на тупик программера.

А зачем переписывать хотплуг, если он вполне справляется со своей задачей?

А вот расширять его функциональность - это да. Нужно.

Rgds,
Rider

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Alexey Morozov]

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

On Tue, Nov 02, 2004 at 12:52:35PM +0300, Anton Farygin wrote:
> >Переписывание хотплугов и sysv-init - задача интресная, но, как и любое 
> >переписывание,
> >только в том случае, если рождается что-то принципиально новое. А те же 
> >скрипты только на питоне -
> >как-то это, гм, смахивает на тупик программера.
> А зачем переписывать хотплуг, если он вполне справляется со своей задачей?
Там есть чего дописывать. Причем, отчасти это уже сделано. На, гы-гы,
питоне.

> А вот расширять его функциональность - это да. Нужно.


P.S. _Похвалите_ мне 2.6, я его на рабочую машину поставлю. Да,
_необходимо_ писать CD'шки.


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Anton Farygin]

Alexey Morozov пишет:
> On Tue, Nov 02, 2004 at 12:52:35PM +0300, Anton Farygin wrote:
> 
>>>Переписывание хотплугов и sysv-init - задача интресная, но, как и любое 
>>>переписывание,
>>>только в том случае, если рождается что-то принципиально новое. А те же 
>>>скрипты только на питоне -
>>>как-то это, гм, смахивает на тупик программера.
>>
>>А зачем переписывать хотплуг, если он вполне справляется со своей задачей?
> 
> Там есть чего дописывать. Причем, отчасти это уже сделано. На, гы-гы,
> питоне.

Да, при чем отчасти это уже действительно сделано.. На sh/coreutils/c++ ;-)

> 
> 
>>А вот расширять его функциональность - это да. Нужно.
> 
> 
> 
> P.S. _Похвалите_ мне 2.6, я его на рабочую машину поставлю. Да,
> _необходимо_ писать CD'шки.

Хвалю.

Пишите ;-)

Rgds,
Rider

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Alexey Morozov]

On Tue, Nov 02, 2004 at 01:44:00PM +0300, Anton Farygin wrote:
> >>А зачем переписывать хотплуг, если он вполне справляется со своей задачей?
> >Там есть чего дописывать. Причем, отчасти это уже сделано. На, гы-гы,
> >питоне.
> Да, при чем отчасти это уже действительно сделано.. На sh/coreutils/c++ ;-)
Увы. Ловить dbus'овские события на sh - тот еще геморрой, вероятно. Но,
разумеется, "Возможно Все" (TM), спорить не буду. Только боюсь, "русский
будет дисквалифицирован", как в том анекдоте.

> >P.S. _Похвалите_ мне 2.6, я его на рабочую машину поставлю. Да,
> >_необходимо_ писать CD'шки.
> Хвалю.
> Пишите ;-)
Какие-то у вас с wRAR'ом противоречивые данные :-)

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Anton Farygin]

Alexey Morozov пишет:
> On Tue, Nov 02, 2004 at 01:44:00PM +0300, Anton Farygin wrote:
> 
>>>>А зачем переписывать хотплуг, если он вполне справляется со своей задачей?
>>>
>>>Там есть чего дописывать. Причем, отчасти это уже сделано. На, гы-гы,
>>>питоне.
>>
>>Да, при чем отчасти это уже действительно сделано.. На sh/coreutils/c++ ;-)
> 
> Увы. Ловить dbus'овские события на sh - тот еще геморрой, вероятно. Но,
> разумеется, "Возможно Все" (TM), спорить не буду. Только боюсь, "русский
> будет дисквалифицирован", как в том анекдоте.

Зачем в hotplug'е ловить события ?

Может быть их там стоит только генерить ?

> 
> 
>>>P.S. _Похвалите_ мне 2.6, я его на рабочую машину поставлю. Да,
>>>_необходимо_ писать CD'шки.
>>
>>Хвалю.
>>Пишите ;-)
> 
> Какие-то у вас с wRAR'ом противоречивые данные :-)

смотрите ошибки на std26 ядрах. Дело в том, что само ядро в общем-то не 
противоречит идеи записи CD, а cdrdao пишет без проблем.

Rgds,
Rider

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Alexey Morozov]

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

On Wed, Nov 03, 2004 at 01:56:14PM +0300, Anton Farygin wrote:
> >Увы. Ловить dbus'овские события на sh - тот еще геморрой, вероятно. Но,
> >разумеется, "Возможно Все" (TM), спорить не буду. Только боюсь, "русский
> >будет дисквалифицирован", как в том анекдоте.
> 
> Зачем в hotplug'е ловить события ?
> Может быть их там стоит только генерить ?
Ух. Во-первых, я говорил про обвязку хотплага. Во-вторых, по здравому
размышлению, периодически требуется взаимодействие с пользователем.
В смысле, иногда только он может выбрать, скажем, подходящий драйвер для
только что вставленной железки, благо, он _точно_ знает, что за железку
он только что воткнул. Так что, насчет отсутствия необходимости обратной
связи я бы не был бы так уверен (хотя, вероятно, эта ситуация
разруливается разделением хотплага на несколько уровней обработки
события)

> >Какие-то у вас с wRAR'ом противоречивые данные :-)
> смотрите ошибки на std26 ядрах. Дело в том, что само ядро в общем-то не 
> противоречит идеи записи CD, а cdrdao пишет без проблем.
Я читал lklm на этот повод (в период 2.6.8). По всему там выходило, что
на тот момент самый разумный вариант для end-luser'а - отпатчить ядро
взад, чтобы оно снова пускало не рута до тех пор, пока не будет написать
приличествующий новой схеме секьюрити-модуль.


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Anton Farygin]

Alexey Morozov пишет:
> On Wed, Nov 03, 2004 at 01:56:14PM +0300, Anton Farygin wrote:
> 
>>>Увы. Ловить dbus'овские события на sh - тот еще геморрой, вероятно. Но,
>>>разумеется, "Возможно Все" (TM), спорить не буду. Только боюсь, "русский
>>>будет дисквалифицирован", как в том анекдоте.
>>
>>Зачем в hotplug'е ловить события ?
>>Может быть их там стоит только генерить ?
> 
> Ух. Во-первых, я говорил про обвязку хотплага. Во-вторых, по здравому
> размышлению, периодически требуется взаимодействие с пользователем.
> В смысле, иногда только он может выбрать, скажем, подходящий драйвер для
> только что вставленной железки, благо, он _точно_ знает, что за железку
> он только что воткнул. Так что, насчет отсутствия необходимости обратной
> связи я бы не был бы так уверен (хотя, вероятно, эта ситуация
> разруливается разделением хотплага на несколько уровней обработки
> события)

Нет. Эта ситуация разруливается совершенно другим способом.
Для этих целей будет конфигурационный файл для libhw, в котором 
пользователь будет указывать драйвера для того что воткнул.

> 
> 
>>>Какие-то у вас с wRAR'ом противоречивые данные :-)
>>
>>смотрите ошибки на std26 ядрах. Дело в том, что само ядро в общем-то не 
>>противоречит идеи записи CD, а cdrdao пишет без проблем.
> 
> Я читал lklm на этот повод (в период 2.6.8). По всему там выходило, что
> на тот момент самый разумный вариант для end-luser'а - отпатчить ядро
> взад, чтобы оно снова пускало не рута до тех пор, пока не будет написать
> приличествующий новой схеме секьюрити-модуль.

я говорю про 2.6.9.

Rgds,
Rider

Re: [devel] Не такой уж и [JT]. Про hotplug и ядро 2.6.9 vs burning CDs

[Alexey Morozov]

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

On Wed, Nov 03, 2004 at 05:01:38PM +0300, Anton Farygin wrote:
> >он только что воткнул. Так что, насчет отсутствия необходимости обратной
> >связи я бы не был бы так уверен (хотя, вероятно, эта ситуация
> >разруливается разделением хотплага на несколько уровней обработки
> >события)
> Нет. Эта ситуация разруливается совершенно другим способом.
> Для этих целей будет конфигурационный файл для libhw, в котором 
> пользователь будет указывать драйвера для того что воткнул.
А хотплаговские события для этой только что воткнутой железки _после_
определения её типа кто проигрывать будет? Или, "а теперь вы должны
выйти и снова зайти"?

> >>смотрите ошибки на std26 ядрах. Дело в том, что само ядро в общем-то не 
> >>противоречит идеи записи CD, а cdrdao пишет без проблем.
> >Я читал lklm на этот повод (в период 2.6.8). По всему там выходило, что
> >на тот момент самый разумный вариант для end-luser'а - отпатчить ядро
> >взад, чтобы оно снова пускало не рута до тех пор, пока не будет написать
> >приличествующий новой схеме секьюрити-модуль.
> я говорю про 2.6.9.
А что, ситуация улучшилась с тех пор? (Я знаю, что несколько программ
были запатчены для исправления выявленных недостатков (открытия дивайсов
в r/o режиме и последующего использования команд, относящихся по типу к
"write" итп). Но новая схема принципиально не позволяет вернуться к
предыдущему status quo. Или я ошибаюсь? Ладно, похоже, надо самому
пробовать... Эх... Старость не радость...


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

Re: [devel] Не такой уж и [JT]. Про hotplug и ядро 2.6.9 vs burning CDs

[Anton Farygin]

Alexey Morozov пишет:
> On Wed, Nov 03, 2004 at 05:01:38PM +0300, Anton Farygin wrote:
> 
>>>он только что воткнул. Так что, насчет отсутствия необходимости обратной
>>>связи я бы не был бы так уверен (хотя, вероятно, эта ситуация
>>>разруливается разделением хотплага на несколько уровней обработки
>>>события)
>>
>>Нет. Эта ситуация разруливается совершенно другим способом.
>>Для этих целей будет конфигурационный файл для libhw, в котором 
>>пользователь будет указывать драйвера для того что воткнул.
> 
> А хотплаговские события для этой только что воткнутой железки _после_
> определения её типа кто проигрывать будет? Или, "а теперь вы должны
> выйти и снова зайти"?

Нет.

hotplug передает сообщение утилите настройки, пользователь настраивает, 
hotplug загружает драйвер. Пока пользователь не настроит - процесс будет 
ждать.

Это для тех устройств, которые _необходимо_ настраивать _руками_. Хотя я 
таких не знаю.

Для остальных можно сделать так, что после настройки драйвер будет 
изменяться.


> 
> 
>>>>смотрите ошибки на std26 ядрах. Дело в том, что само ядро в общем-то не 
>>>>противоречит идеи записи CD, а cdrdao пишет без проблем.
>>>
>>>Я читал lklm на этот повод (в период 2.6.8). По всему там выходило, что
>>>на тот момент самый разумный вариант для end-luser'а - отпатчить ядро
>>>взад, чтобы оно снова пускало не рута до тех пор, пока не будет написать
>>>приличествующий новой схеме секьюрити-модуль.
>>
>>я говорю про 2.6.9.
> 
> А что, ситуация улучшилась с тех пор? (Я знаю, что несколько программ
> были запатчены для исправления выявленных недостатков (открытия дивайсов
> в r/o режиме и последующего использования команд, относящихся по типу к
> "write" итп). Но новая схема принципиально не позволяет вернуться к
> предыдущему status quo. Или я ошибаюсь? Ладно, похоже, надо самому
> пробовать... Эх... Старость не радость...

Посмотрите в bugzilla - там это подробно описано.

Rgds,
Rider

[devel] Re: Не такой уж и [JT]. Про hotplug и ядро 2.6.9 vs burning CDs

[Michael Shigorin]

On Wed, Nov 03, 2004 at 05:54:35PM +0300, Anton Farygin wrote:
> hotplug передает сообщение утилите настройки, пользователь
> настраивает, hotplug загружает драйвер. Пока пользователь не
> настроит - процесс будет ждать.

Кста!

Идиотский вопрос, но пока помню (на днях в synce-devel@
пролетало).

Как сейчас принято определять _активного_ _консольного_
пользователя, с действиями которого разумно соотносить всовывание
разных железок?

Права на /dev/console -- не рассматриваются :-)

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

Re: [devel] Re: Не такой уж и [JT]. Про hotplug и ядро 2.6.9 vs burning CDs

[Alexey Morozov]

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

On Wed, Nov 03, 2004 at 10:42:40PM +0200, Michael Shigorin wrote:
> Как сейчас принято определять _активного_ _консольного_
> пользователя, с действиями которого разумно соотносить всовывание
> разных железок?
> 
> Права на /dev/console -- не рассматриваются :-)
dbus, вероятно.


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

Re: [devel] Re: Не такой уж и [JT]. Про hotplug и ядро 2.6.9 vs burning CDs

[Anton Farygin]

Alexey Morozov пишет:
> On Wed, Nov 03, 2004 at 10:42:40PM +0200, Michael Shigorin wrote:
> 
>>Как сейчас принято определять _активного_ _консольного_
>>пользователя, с действиями которого разумно соотносить всовывание
>>разных железок?
>>
>>Права на /dev/console -- не рассматриваются :-)
> 
> dbus, вероятно.

Да, здесь только dbus.

Rgds,
Rider

Re: [devel] Re: Не такой уж и [JT]. Про hotplug и ядро 2.6.9 vs burning CDs

[Alexey Borovskoy]

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

* Четверг 04 Ноябрь 2004 19:28 Anton Farygin <rider@altlinux.com>

> Alexey Morozov пишет:
> > On Wed, Nov 03, 2004 at 10:42:40PM +0200, Michael Shigorin 
wrote:
> >>Как сейчас принято определять _активного_ _консольного_
> >>пользователя, с действиями которого разумно соотносить
> >> всовывание разных железок?
> >>
> >>Права на /dev/console -- не рассматриваются :-)
> >
> > dbus, вероятно.
>
> Да, здесь только dbus.

А что такое dbus?

-- 
Алексей.
GPG key fingerprint
DBB3 1832 13C6 5C96 4A58  4AFF 78F7 159F 66AD 8D7E

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

Re: [devel] Re: Не такой уж и [JT]. Про hotplug и ядро 2.6.9 vs burning CDs

[Alexey Morozov]

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

On Mon, Nov 08, 2004 at 02:10:31PM +1200, Alexey Borovskoy wrote:
> > >>Права на /dev/console -- не рассматриваются :-)
> > > dbus, вероятно.
> > Да, здесь только dbus.
> А что такое dbus?
apt-cache show dbus? ;-)



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

Re: [devel] Re: Не такой уж и [JT]. Про hotplug и ядро 2.6.9 vs burning CDs

[Alexey Borovskoy]

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

* Вторник 09 Ноябрь 2004 22:06 Alexey Morozov 
<alex-altlinux@idisys.iae.nsk.su>

> On Mon, Nov 08, 2004 at 02:10:31PM +1200, Alexey Borovskoy 
wrote:
> > > >>Права на /dev/console -- не рассматриваются :-)
> > > >
> > > > dbus, вероятно.
> > >
> > > Да, здесь только dbus.
> >
> > А что такое dbus?
>
> apt-cache show dbus? ;-)

Там только фикс на ядро нашелся.
ALM 2.4 DVD.

-- 
Алексей.
GPG key fingerprint
DBB3 1832 13C6 5C96 4A58  4AFF 78F7 159F 66AD 8D7E

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

Re: [devel] Не такой уж и [JT]. Про hotplug и ядро 2.6.9 vs burning CDs

[Alexey Morozov]

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

On Wed, Nov 03, 2004 at 05:54:35PM +0300, Anton Farygin wrote:
> >А хотплаговские события для этой только что воткнутой железки _после_
> >определения её типа кто проигрывать будет? Или, "а теперь вы должны
> >выйти и снова зайти"?
> hotplug передает сообщение утилите настройки, пользователь настраивает, 
> hotplug загружает драйвер. Пока пользователь не настроит - процесс будет 
> ждать.
А, ну, то есть, уровень конфигурирования уже вынесен и может в этом
месте нормально принимать те же самые dbus'ные сообщения? ЧТУ.

> Посмотрите в bugzilla - там это подробно описано.
Ok.


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

Re: [devel] Не такой уж и [JT]. Про hotplug и ядро 2.6.9 vs burning CDs

[Anton Farygin]

Alexey Morozov пишет:
> On Wed, Nov 03, 2004 at 05:54:35PM +0300, Anton Farygin wrote:
> 
>>>А хотплаговские события для этой только что воткнутой железки _после_
>>>определения её типа кто проигрывать будет? Или, "а теперь вы должны
>>>выйти и снова зайти"?
>>
>>hotplug передает сообщение утилите настройки, пользователь настраивает, 
>>hotplug загружает драйвер. Пока пользователь не настроит - процесс будет 
>>ждать.
> 
> А, ну, то есть, уровень конфигурирования уже вынесен и может в этом
> месте нормально принимать те же самые dbus'ные сообщения? ЧТУ.

Это сейчас в процессе разработки. Но вообще так и будет.

Rgds,
Rider

Re: [devel] Не такой уж и [JT]. Про hotplug и ядро 2.6.9 vs burning CDs

[Alexey Morozov]

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

On Thu, Nov 04, 2004 at 10:29:14AM +0300, Anton Farygin wrote:
> >А, ну, то есть, уровень конфигурирования уже вынесен и может в этом
> >месте нормально принимать те же самые dbus'ные сообщения? ЧТУ.
> Это сейчас в процессе разработки. Но вообще так и будет.
Здорово.

"Эх, какая жизнь тогда начнётся!.." (Из советских кинофильмов 30-60х
годов).


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

[devel] [JT] Re: [JT]^[JT] О судьбах... в том числе и о hotplug

[Michael Shigorin]

On Wed, Nov 03, 2004 at 05:01:38PM +0300, Anton Farygin wrote:
> Для этих целей будет конфигурационный файл для libhw, в котором
> пользователь будет указывать драйвера для того что воткнул.

/me почему-то взгрустнулось и подумалось, что сузешники какие
навряд ли пошлют пользователей в безальтернативные конфиги...

Правда, по сути вопроса пойти и посмотеть -- до конца осени точно
не выйдет. :-(

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

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

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

On Tue, Nov 02, 2004 at 04:22:19PM +0600, Alexey Morozov wrote:

 AM> P.S. _Похвалите_ мне 2.6, я его на рабочую машину поставлю. Да,
 AM> _необходимо_ писать CD'шки.

У меня на домашней, рабочей, и ноутбуке стоит именно он. Если сделать
alias ide-scsi off, то вполне себе успешно делает вид что работает. Причём
я иногда даже в это верю. А на 2.4 хотплаг можно сказать и не делает вид
что работает, вот самая главная похвала 2.6 :)

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

http://freesource.info


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Andrey Rahmatullin]

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

On Tue, Nov 02, 2004 at 06:05:06PM +0300, Денис Смирнов wrote:
>  AM> P.S. _Похвалите_ мне 2.6, я его на рабочую машину поставлю. Да,
>  AM> _необходимо_ писать CD'шки.
> У меня на домашней, рабочей, и ноутбуке стоит именно он. Если сделать
> alias ide-scsi off, то вполне себе успешно делает вид что работает.
Вообще-то на 2.6.8+ довольно сложно писать CD не рутом.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> Вот такой вопрос - а ядро у Вас какое?  Оригинальное c
> kernel.org или нет?
А что, тут есть самоубийцы, готовые сидеть на этой бочке??
		-- mike in sisyphus@

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Anton Farygin]

Andrey Rahmatullin пишет:
> On Tue, Nov 02, 2004 at 06:05:06PM +0300, Денис Смирнов wrote:
> 
>> AM> P.S. _Похвалите_ мне 2.6, я его на рабочую машину поставлю. Да,
>> AM> _необходимо_ писать CD'шки.
>>У меня на домашней, рабочей, и ноутбуке стоит именно он. Если сделать
>>alias ide-scsi off, то вполне себе успешно делает вид что работает.
> 
> Вообще-то на 2.6.8+ довольно сложно писать CD не рутом.

Да ну ?

Rgds,
Rider

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Andrey Rahmatullin]

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

On Tue, Nov 02, 2004 at 08:53:48PM +0300, Anton Farygin wrote:
> >Вообще-то на 2.6.8+ довольно сложно писать CD не рутом.
> Да ну ?
Угу.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Никогда не меняйте uid вручную, пользуйтесь usermod(8).
		-- ldv in community@

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Anton Farygin]

Andrey Rahmatullin пишет:
> On Tue, Nov 02, 2004 at 08:53:48PM +0300, Anton Farygin wrote:
> 
>>>Вообще-то на 2.6.8+ довольно сложно писать CD не рутом.
>>
>>Да ну ?
> 
> Угу.

Ко мне поступает ровно другая информация.

А бага на cdrecord уже висит.

Попробуйте вместо него cdrdao.

Rgds,
Rider

2ldv: может быть выложишь патченный cdrecord в Sisyphus ?

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Andrey Rahmatullin]

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

On Wed, Nov 03, 2004 at 01:57:24PM +0300, Anton Farygin wrote:
> Попробуйте вместо него cdrdao.
Решил попробовать и заодно перейти на k3b.
Последний не видит от юзера ни один из сидюков. От рута, ессно, видит и
пишет.
Т.е. один хрен :(

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

В mysql chroot'изация всегда была сделана из рук вон плохо, и реакция от
upstream на мои патчи была невразумительной.  Как следствие, у меня есть
основание полагать, что в этой области там не все сделано правильно, вне
зависимости от того, что написано в документации.
		-- ldv in devel@

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и о hotplug

[Anton Farygin]

Andrey Rahmatullin пишет:
> On Wed, Nov 03, 2004 at 01:57:24PM +0300, Anton Farygin wrote:
> 
>>Попробуйте вместо него cdrdao.
> 
> Решил попробовать и заодно перейти на k3b.
> Последний не видит от юзера ни один из сидюков. От рута, ессно, видит и
> пишет.
> Т.е. один хрен :(

А вот это уже бага k3b.

И собственно мантейнер вкурсе и должен исправить эту ошибку.

Rgds,
Rider

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

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

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

On Tue, Nov 02, 2004 at 11:09:27AM +0300, Andrey Orlov wrote:

AO> Да, но я не понимаю, почему если я пишу на питоне, я должен ставить перл ;)?
AO> Я полагаю, что будь наоборот, аналогичное недоумение выскажут перлисты.
AO> А вариант sh+awk+sed является нейтральной територией и устраивает всех.

Есть ещё один вариант, который самый геморройный, но для
системообразующего ПО вполне логичный. На Python или Perl пишутся
генераторы кода на C, коий и компилируется. Результат -- код писать
просто, исполняемый код получается компактный, проще обеспечить
"правильный" (безопасный) результирующий код. И править такой
метагенератор часто проще, чем результирующий код.

AO> Переписывание хотплугов и sysv-init - задача интресная, но, как и любое переписывание,
AO> только в том случае, если рождается что-то принципиально новое. А те же скрипты только на питоне -
AO> как-то это, гм, смахивает на тупик программера.

Полностью согласен.

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

http://freesource.info


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Andrey Orlov]

On Tuesday 02 November 2004 18:03, Денис Смирнов wrote:
> Есть ещё один вариант, который самый геморройный, но для
> системообразующего ПО вполне логичный. На Python или Perl пишутся
> генераторы кода на C, коий и компилируется. Результат -- код писать
> просто, исполняемый код получается компактный, проще обеспечить
> "правильный" (безопасный) результирующий код. И править такой
> метагенератор часто проще, чем результирующий код.

Что-то мне кажется, что наименее геморойный - нафигачить все сразу на си или плюсах. По крайней
мере нормальные full featured языки, а не какие-то AWK-мутанты. Чгря, за десять лет программирования на си,
единственная сложность, которую я встречал - понимание моих великих кодов другими.

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Aleksey Avdeev]

Andrey Orlov пишет:
> On Tuesday 02 November 2004 18:03, Денис Смирнов wrote:
> 
>>Есть ещё один вариант, который самый геморройный, но для
>>системообразующего ПО вполне логичный. На Python или Perl пишутся
>>генераторы кода на C, коий и компилируется. Результат -- код писать
>>просто, исполняемый код получается компактный, проще обеспечить
>>"правильный" (безопасный) результирующий код. И править такой
>>метагенератор часто проще, чем результирующий код.
> 
> 
> Что-то мне кажется, что наименее геморойный - нафигачить все сразу на си или плюсах. По крайней
> мере нормальные full featured языки, а не какие-то AWK-мутанты. Чгря, за десять лет программирования на си,
> единственная сложность, которую я встречал - понимание моих великих кодов другими.

   Не факт: сейчас, если что-то не совсем понятно как и где 
настраивать - можно код глянуть и разобраться (и/или по месту 
подрихтовать, при необходимости)... Если же скрипты будут заменены 
на бинарники - этот путь будет закрыт.

-- 

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Dmitry V. Levin]

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

Hi,

On Tue, Nov 02, 2004 at 10:53:20PM +0300, Aleksey Avdeev wrote:
[...]
>   Не факт: сейчас, если что-то не совсем понятно как и где 
> настраивать - можно код глянуть и разобраться (и/или по месту 
> подрихтовать, при необходимости)... Если же скрипты будут заменены 
> на бинарники - этот путь будет закрыт.

В таком случае путь уже давно закрыт, поскольку init(8) - самый что ни на
есть бинарник, да ещё местами глючный.

P.S. [JT]^[JT] == 0


-- 
ldv

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Aleksey Avdeev]

Dmitry V. Levin пишет:
> Hi,
> 
> On Tue, Nov 02, 2004 at 10:53:20PM +0300, Aleksey Avdeev wrote:
> [...]
> 
>>  Не факт: сейчас, если что-то не совсем понятно как и где 
>>настраивать - можно код глянуть и разобраться (и/или по месту 
>>подрихтовать, при необходимости)... Если же скрипты будут заменены 
>>на бинарники - этот путь будет закрыт.
> 
> 
> В таком случае путь уже давно закрыт, поскольку init(8) - самый что ни на
> есть бинарник, да ещё местами глючный.

   Такие глубины мне пока не требовались. ;-)

   А вот разобраться, как добиться требуемого через /etc/sysconfig/* 
- стартовые скрипты помогали неоднократно. Возможность редактировать 
rc.sysinit тоже была не лишний, когда lvm поверх raid из коробки не 
работал. :-)

-- 

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

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

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

On Wed, Nov 03, 2004 at 10:58:39AM +0300, Aleksey Avdeev wrote:
 AA>   А вот разобраться, как добиться требуемого через /etc/sysconfig/* 
 AA> - стартовые скрипты помогали неоднократно. Возможность редактировать 
 AA> rc.sysinit тоже была не лишний, когда lvm поверх raid из коробки не 
 AA> работал. :-)

Лишней, иначе вам бы _пришлось_ поправить RPM-пакет. А после этого
отослать изменения мантейнеру было бы элементарно :)
 
-- 
С уважением, Денис

http://freesource.info


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Aleksey Avdeev]

Денис Смирнов пишет:
> On Wed, Nov 03, 2004 at 10:58:39AM +0300, Aleksey Avdeev wrote:
>  AA>   А вот разобраться, как добиться требуемого через /etc/sysconfig/* 
>  AA> - стартовые скрипты помогали неоднократно. Возможность редактировать 
>  AA> rc.sysinit тоже была не лишний, когда lvm поверх raid из коробки не 
>  AA> работал. :-)
> 
> Лишней, иначе вам бы _пришлось_ поправить RPM-пакет. А после этого
> отослать изменения мантейнеру было бы элементарно :)

   Логично. (И правильно.) Но в те времена я ещё незнал _как_ 
подступится к данному зверю (RPM-пакету), а скрипт (основа для 
правок) - был из рассылки взят. :-)

-- 

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

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

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

On Wed, Nov 03, 2004 at 03:30:48PM +0300, Aleksey Avdeev wrote:

AA>   Логично. (И правильно.) Но в те времена я ещё незнал _как_ 
AA> подступится к данному зверю (RPM-пакету), а скрипт (основа для 
AA> правок) - был из рассылки взят. :-)

Помнится документация у Мастера на тему RPM-пакетов вполне вменяемая.

Я пару месяцев боялся к этим зверям подступиться. А потом сел, и за 10
минут разобрался :)

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

http://freesource.info


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

[devel] Re: [JT]^[JT] О судьбах... в том числе и питона.

[Michael Shigorin]

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

On Wed, Nov 03, 2004 at 02:29:40PM +0300, Денис Смирнов wrote:
>  AA> - стартовые скрипты помогали неоднократно. Возможность редактировать 
>  AA> rc.sysinit тоже была не лишний, когда lvm поверх raid из коробки не 
>  AA> работал. :-)
> Лишней, иначе вам бы _пришлось_ поправить RPM-пакет. А после
> этого отослать изменения мантейнеру было бы элементарно :)

Вот только суммарная вероятность этого события при таком варианте
стремится к нулю.

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

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

[devel] Re: [JT]^[JT] О судьбах... в том числе и питона.

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

On Wed, Nov 03, 2004 at 10:45:21PM +0200, Michael Shigorin wrote:

 >> Лишней, иначе вам бы _пришлось_ поправить RPM-пакет. А после
 >> этого отослать изменения мантейнеру было бы элементарно :)
 MS> Вот только суммарная вероятность этого события при таком варианте
 MS> стремится к нулю.

Если процесс сборки отлажен, то это даже удобнее. Я всё что только можно в
виде RPM-пакетов держу. У меня даже конфигурация частенько так хранится --
для удобства воспроизведения, так сказать.

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

http://freesource.info

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Andrey Orlov]

On Tuesday 02 November 2004 22:53, Aleksey Avdeev wrote:
>    Не факт: сейчас, если что-то не совсем понятно как и где 
> настраивать - можно код глянуть и разобраться (и/или по месту 
> подрихтовать, при необходимости)... Если же скрипты будут заменены 
> на бинарники - этот путь будет закрыт.

Я вам приоткрою его обратно:

apt-get source $(rpm -qf <РИХТУЕМЫЙ ФАЙЛ>); 
cd <...>
vi <РИХТУЕМЫЙ ФАЙЛ>.c;
 rpm --ba <...>; 
diff <...> |mail "$(rpm -qf <РИХТУЕМЫЙ ФАЙЛ> --qf "%{PACKAGER}")" -s "я отрихтовал <РИХТУЕМЫЙ ФАЙЛ>"

А вот доступность на редактирование скриптов, лежащих на диске - на самом деле та еще подлянка, 

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Aleksey Avdeev]

Andrey Orlov пишет:
> On Tuesday 02 November 2004 22:53, Aleksey Avdeev wrote:
> 
>>   Не факт: сейчас, если что-то не совсем понятно как и где 
>>настраивать - можно код глянуть и разобраться (и/или по месту 
>>подрихтовать, при необходимости)... Если же скрипты будут заменены 
>>на бинарники - этот путь будет закрыт.
> 
> 
> Я вам приоткрою его обратно:
> 
> apt-get source $(rpm -qf <РИХТУЕМЫЙ ФАЙЛ>); 
> cd <...>
> vi <РИХТУЕМЫЙ ФАЙЛ>.c;
>  rpm --ba <...>; 
> diff <...> |mail "$(rpm -qf <РИХТУЕМЫЙ ФАЙЛ> --qf "%{PACKAGER}")" -s "я отрихтовал <РИХТУЕМЫЙ ФАЙЛ>"

   Это вопрос умений, навыков и опыта: разобраться и отрихтовать 
скрипт на sh для меня сейчас проще, чем код на С (не мой ;-)). (Хотя 
есть очевидный +: C быстрее освою...)

> 
> А вот доступность на редактирование скриптов, лежащих на диске - на самом деле та еще подлянка, 

   Да, правки могут быть вынесены после очередного обновления... Но 
_иногда_ это оправданный риск.

-- 

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

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

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

On Wed, Nov 03, 2004 at 11:09:56AM +0300, Aleksey Avdeev wrote:

 AA>   Да, правки могут быть вынесены после очередного обновления... Но 
 AA> _иногда_ это оправданный риск.

Никогда, ибо все исполняемые файлы должны лежать в RPM. Делаете свою
сборку, где будет приложен ваш патч, и сразу видно что и где поменяли.
 
-- 
С уважением, Денис

http://freesource.info


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Alexey Morozov]

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

On Wed, Nov 03, 2004 at 02:28:34PM +0300, Денис Смирнов wrote:
> On Wed, Nov 03, 2004 at 11:09:56AM +0300, Aleksey Avdeev wrote:
>  AA>   Да, правки могут быть вынесены после очередного обновления... Но 
>  AA> _иногда_ это оправданный риск.
> Никогда, ибо все исполняемые файлы должны лежать в RPM. Делаете свою
> сборку, где будет приложен ваш патч, и сразу видно что и где поменяли.
Это оправданное упрощение внесения правок на этапе проработки решения.
То есть, скрипт можно поправить as-is, а для компилируемого бинарника
придется еще тучу совсем немаленьких инструментов дотягивать.


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Andrey Orlov]

On Wednesday 03 November 2004 13:32, Alexey Morozov wrote:
> Это оправданное упрощение внесения правок на этапе проработки решения.
> То есть, скрипт можно поправить as-is, а для компилируемого бинарника
> придется еще тучу совсем немаленьких инструментов дотягивать.

Основной инструмент, который вам потребуется, называется ln -s ;)


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Alexey Morozov]

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

On Wed, Nov 03, 2004 at 03:39:30PM +0300, Andrey Orlov wrote:
> On Wednesday 03 November 2004 13:32, Alexey Morozov wrote:
> > Это оправданное упрощение внесения правок на этапе проработки решения.
> > То есть, скрипт можно поправить as-is, а для компилируемого бинарника
> > придется еще тучу совсем немаленьких инструментов дотягивать.
> Основной инструмент, который вам потребуется, называется ln -s ;)
"Н-н-ни поэл"


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

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

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

On Wed, Nov 03, 2004 at 04:32:36PM +0600, Alexey Morozov wrote:
>  AA>>   Да, правки могут быть вынесены после очередного обновления... Но 
>  AA>> _иногда_ это оправданный риск.
>> Никогда, ибо все исполняемые файлы должны лежать в RPM. Делаете свою
>> сборку, где будет приложен ваш патч, и сразу видно что и где поменяли.
 AM> Это оправданное упрощение внесения правок на этапе проработки решения.
 AM> То есть, скрипт можно поправить as-is, а для компилируемого бинарника
 AM> придется еще тучу совсем немаленьких инструментов дотягивать.

Вопрос в том, что нужно править, а что нет. Патчик на ядро без gcc тоже
вряд ли наложить удастся.

IMHO частенько возможность легко поправить используется как оправдание
недоделок и кривизны конфигурации и документации.

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

http://freesource.info


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Andrey Orlov]

On Wednesday 03 November 2004 15:46, Денис Смирнов wrote:
> IMHO частенько возможность легко поправить используется как оправдание
> недоделок и кривизны конфигурации и документации.

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

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Ivan Fedorov]

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

Andrey Orlov пишет:
> On Wednesday 03 November 2004 15:46, Денис Смирнов wrote:
> 
>>IMHO частенько возможность легко поправить используется как оправдание
>>недоделок и кривизны конфигурации и документации.
> 
> 
> Вот-вот. А часто это служит оправданием более высокой оплаты. Поправить параметр в конфиге -
> это грамотный оператор, дешево. А отредактировать исходный код - это мы типа программист и платите мне
> в два раза больше. Я не один канкретный случай знаю ;), когда разработчик принципиально отказывается вынести конфигурацию
> из исходного кода во внешнюю подсистему, а потом для каждого изменения (буквально - скопировать файлы в другое место и заново
> запустить) ему приходится платить как за "программирование"
> 
Ну ты знаешь это нормально, учитывая, что народ думает что если
программист может все за пять минут, то это ему просто. Следовательно
платить ему много не надо... ;(

Я могу работать очень быстро... только пусть это мне оплатят
соответсвующе... А то мне тут предложили сделать сайт за $50... я едой
подавился, когда прочитал это предложение...

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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

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

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

On Tue, Nov 02, 2004 at 10:21:09PM +0300, Andrey Orlov wrote:
 
AO> Что-то мне кажется, что наименее геморойный - нафигачить все сразу на си или плюсах. По крайней
AO> мере нормальные full featured языки, а не какие-то AWK-мутанты. Чгря, за десять лет программирования на си,
AO> единственная сложность, которую я встречал - понимание моих великих кодов другими.

С++ плюс doxygen позволяет даже приличную документацию кода легко делать.
Только вот многое можно и на sh+awk сделать :)

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

http://freesource.info


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Alexey Morozov]

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

On Tue, Nov 02, 2004 at 10:21:09PM +0300, Andrey Orlov wrote:
> > Есть ещё один вариант, который самый геморройный, но для
> > системообразующего ПО вполне логичный. На Python или Perl пишутся
> > генераторы кода на C, коий и компилируется. Результат -- код писать
> > просто, исполняемый код получается компактный, проще обеспечить
> > "правильный" (безопасный) результирующий код. И править такой
> > метагенератор часто проще, чем результирующий код.
> Что-то мне кажется, что наименее геморойный - нафигачить все сразу на
> си или плюсах. По крайней
Язык _обязан_ быть скриптовым. Это вполне может быть интерпретируемый
C, но интерпретируемость - важнейший из критериев. Собственно, перл
довольно хорошо подходит на роль интерпретируемого C при соблюдении
соответствующей культуры девелопмента.

> мере нормальные full featured языки, а не какие-то AWK-мутанты.
> Чгря, за десять лет программирования на си, единственная сложность,
> которую я встречал - понимание моих великих кодов другими.
:-))) В биореактор, как кричит один наш экзальтированный друг ;-)))


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

Re: [devel] [JT]^[JT] О судьбах... в том числе и питона.

[Andrey Orlov]

On Wednesday 03 November 2004 13:29, Alexey Morozov wrote:
> > мере нормальные full featured языки, а не какие-то AWK-мутанты.
> > Чгря, за десять лет программирования на си, единственная сложность,
> > которую я встречал - понимание моих великих кодов другими.
> :-))) В биореактор, как кричит один наш экзальтированный друг ;-)))

Я бы их давно туда отправил, но одному скучно.

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

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

[Andrey Orlov]

Hi!,

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

On Monday 01 November 2004 16:16, you wrote:
>  AO> Вообще, прежде чем рассуждать о полиси, очень посоветовал бы изучить конкретный
>  AO> действующий пример - python-policy. Не без шкурног интереса, посоветовал бы: может, предложите что улучшить или 
>  AO> посоветуете как избежать.... ;))
> 
> Андрей, я не имел в виду Python, ни в коем случае.

А я ни в коем случае не имел ввиду лично вас.

> > Я говорил об 
> универсальном решении для ситуаций, когда не получается внести глобальное
> изменение из-за глобального торможения.

Давайте попробуем реализовать хотя бы один хороший частный случай? ;) 
А там, глядишь, остальные подтянутся. А то размышления об универсальном решении, 
к сожалению, так же бесконечны как и универсум.

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

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

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

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

On Mon, Nov 01, 2004 at 03:45:16PM +0300, Andrey Orlov wrote:
 AO> а вроде с меня началось... Надеюсь, уважаемый соразмысленник не обидется, если я верну размышления в рассылку ;)

Ничуть.

> >> Я говорил об 
>> универсальном решении для ситуаций, когда не получается внести глобальное
>> изменение из-за глобального торможения.
 AO> Давайте попробуем реализовать хотя бы один хороший частный случай? ;) 
 AO> А там, глядишь, остальные подтянутся. А то размышления об универсальном решении, 
 AO> к сожалению, так же бесконечны как и универсум.

IMHO хороший == полностью автоматизированый (читать -- "человеческий
фактор сведён к минимуму"). В свободных проектах, IMHO, вопрос
автоатизации QA стоит чуть ли не на первом месте. Особенно с учётом того,
что incominger@ таки don't scale.

Вот сегодня я залил новый avfs-fuse. После ближайшего же обновления у
пользователей SieFS он накроется медным тазом. Способа спасти от этого
пользователей в принципе не существует (не считая сговориться с
мантейнером о заливке обновлений в один день). Я бы предпочёл чтобы это
всё происходило автоматом.

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

http://freesource.info


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