[devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[Michael Shigorin]

	Здравствуйте.
Понимаю, что к шапочному разбору, но...

а давайте перебранчуем 5.0/branch и дело с концом?
Что этому является противопоказанием?

On Fri, May 01, 2009 at 03:30:24PM +0400, Dmitry V. Levin wrote:
> > > Интересно, если уже мне бранч 5.0 стал не нужен, то зачем
> > > он нужен вам?
> > Серверных продуктов на бранче 5.0 не будет?
> Если за полгода ещё не было, то уже, наверное, не будет.
> Я решил, что т.н. office server уже проще готовить на Сизифе,
> с последующим бранчеванием под релиз (примерно так же, как было
> сделано под 4.0), вместо того, чтобы продолжать вытягивать
> бранч 5.0.

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

По-моему, это лучше, чем подвязываться на условности вида
"весенний-осенний", если они в данном разе просто не сработали.

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


On Fri, May 01, 2009 at 09:37:17PM +0400, Dmitry V. Levin wrote:
> Я думаю, что бранчи, на которых не выпущены продукты, быстро угасают.

Угу.

> Поскольку вся разработка ведётся на Сизифе, а на 5.0 продукты
> ещё не выпущены, я не вижу естественных причин, по которым
> бранч 5.0 будет развиваться.

Вы вообще планируете выпускать летом Desktop 5.0?
Судя по тому же xorg -- если и да, то не весной.


On Mon, May 04, 2009 at 03:50:50PM +0400, Dmitry V. Levin wrote:
> > Продолжается обсуждение выводов из неявных (даже для самого
> > себя) задач, которые ставятся перед Сизифом и бранчами.
> > Сформулируйте цели, и всё станет гораздо яснее.
> Я беру паузу.  Может быть, найдутся ещё желающие сформулировать.

В http://www.altlinux.org/Concepts/Context слово "Master"
отчасти заменимо на слово "branch", которого тогда не было.


On Tue, Apr 28, 2009 at 03:28:05PM +0400, Yuri N. Sedunov wrote:
> > Только у меня возникает ощущение, что уже дешевле Sisyphus
> > в 5.0 переименовать ? или 5.1
> Спросил бы у кого не возникает.

Так что именно мешает это сделать?

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

Re: [devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[Aleksey Novodvorsky]

15 мая 2009 г. 0:40 пользователь Michael Shigorin <mike@osdn.org.ua> написал:
> Вы вообще планируете выпускать летом Desktop 5.0?
> Судя по тому же xorg -- если и да, то не весной.

Частное мнение: нынешний xorg, особенно в части драйверов intel, --
нерабочий. Я не стал бы гнаться за Убунту и Мандривой, выпустившими
весенние кривульки. Нынешний апстрим xorg действительно очень крив и
это веская причина дял задержки. С другой стороны, середина июля,
скорее всего, -- действительно край. Потому нужно стабилизироваться к
концу мая и вносить изменения только в xorg и критические. Возможно,
стоит выпустить community release с подробным описанием проблем
апстрима раньше, в начале июня. Вопрос с KDE обсуждается, но ждать
релиза 4.3 нельзя.
У меня также есть  пожелания к релизу по взаимодействию с виндой:
1. Решить проблемы rdesktop.
2. Выкинуть отовсюду или починить putty.
3. Уважить неправильных юзеров и адаптировать likewise-open. ktirf его
собрал, но ввиду занятости на менеджерской работе, довести до ума вряд
ли сможет.

Темы Gnome и XFCE здесь не обсуждаю, хотя они важные. Замечу только,
что по Gnome, который мы имеем шанс спервые за долгое время сделать
нормальным, надо сравнивать с Убунту, где он так или иначе вылизан.
Это не образец, но ориентир.

Все это сугубо частные пожелания. В проблемы бранчевания  я не лезу.
Меня и интересует лишь школьный бранч 2009 года.

Про сервер сейчас тоже не буду, хотя считаю его выпуск приоритетной задачей.
Чуть позже.
Rgrds, Алексей

Re: [devel] перебранчуем 5.0/branch?

[REAL]

Aleksey Novodvorsky пишет:
> Про сервер сейчас тоже не буду, хотя считаю его выпуск приоритетной задачей.
> Чуть позже.

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

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[Michael Shigorin]

On Fri, May 15, 2009 at 01:10:55AM +0400, Aleksey Novodvorsky wrote:
> > Вы вообще планируете выпускать летом Desktop 5.0?
> > Судя по тому же xorg -- если и да, то не весной.
> Частное мнение: нынешний xorg, особенно в части драйверов
> intel, -- нерабочий.

Ещё не знаю, на intel у меня до сих пор xorg-drv-intel-2.4.3
периода ранневесеннего M50.  В основном нормально, хотя и не
без претензий (не живёт :1, тормозит отрисовка при повороте
xrandr'ом на 90).

> Я не стал бы гнаться за Убунту и Мандривой, выпустившими
> весенние кривульки.

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

> С другой стороны, середина июля, скорее всего, -- действительно
> край.

В смысле по выпускам десктопных дистрибутивов?

> Потому нужно стабилизироваться к концу мая и вносить изменения
> только в xorg и критические. Возможно, стоит выпустить
> community release с подробным описанием проблем апстрима
> раньше, в начале июня.

Кто-то грозился предложить release policy, помнится... ;-)
(да, всё так же слабо)

> У меня также есть  пожелания к релизу по взаимодействию с виндой:
> 1. Решить проблемы rdesktop.

Почитал тред в sisyphus@, огорчился раздутой стаей слонов
и вспомнил, как вообще-то был рождён патчик для -y -- сугубо
для решения практических проблем (правда, evdev тогда не было).

При таком отношении Димы к обсуждению всё-таки думаю, что решать
эти проблемы вам придётся самим.

> 2. Выкинуть отовсюду или починить putty.

Думаю, текущий и предыдущий майнтейнер удовольствуются наличием
в сизифе/бранчах/$HOME -- а что с ним?  Когда-то собирал ради
умения ходить через HTTP-прокси после того, как влип в интернет-
кафе без NAT; ну и не настаиваю, чтоб этот пакет попадал в
дистрибутивы.

> 3. Уважить неправильных юзеров и адаптировать likewise-open.

Давно уж пора.  Как и OpenMoveOver, мне кажется.

> ktirf его собрал, но ввиду занятости на менеджерской работе,
> довести до ума вряд ли сможет.

Аналогично.

> Темы Gnome и XFCE здесь не обсуждаю, хотя они важные. Замечу
> только, что по Gnome, который мы имеем шанс спервые за долгое
> время сделать нормальным, надо сравнивать с Убунту, где он так
> или иначе вылизан.  Это не образец, но ориентир.

Чем смог -- с GNOME помог, но поскольку не использую -- тут уж
вряд ли.  Разве что могу на глаз посравнивать с F10 по оказии.

> Все это сугубо частные пожелания. В проблемы бранчевания я не лезу.
> Меня и интересует лишь школьный бранч 2009 года.

Если интересует, значит, может понадобиться лезть.

Дело в том, что если Desktop 5.0 задерживается по тем или иным
причинам (а это именно то, что я вижу) -- то единственным
потенциально значимым потребителем этого бранча является школьный
бранч, а требовать его поддержки от команды (начиная с ldv@)
мне никак не получается.

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

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

Re: [devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[Andrey Rahmatullin]

On Fri, May 15, 2009 at 11:19:55AM +0300, Michael Shigorin wrote:
> > Частное мнение: нынешний xorg, особенно в части драйверов
> > intel, -- нерабочий.
> Ещё не знаю, на intel у меня до сих пор xorg-drv-intel-2.4.3
> периода ранневесеннего M50.  В основном нормально, хотя и не
> без претензий (не живёт :1, тормозит отрисовка при повороте
> xrandr'ом на 90).
У меня на eee901 и сизифный intel отлично живёт.

> > 2. Выкинуть отовсюду или починить putty.
> Думаю, текущий и предыдущий майнтейнер удовольствуются наличием
> в сизифе/бранчах/$HOME -- а что с ним?
С ним gtk1.
https://bugzilla.altlinux.org/show_bug.cgi?id=19630

Re: [devel] перебранчуем 5.0/branch?

[Anton Farygin]

Andrey Rahmatullin пишет:
> On Fri, May 15, 2009 at 11:19:55AM +0300, Michael Shigorin wrote:
>>> Частное мнение: нынешний xorg, особенно в части драйверов
>>> intel, -- нерабочий.
>> Ещё не знаю, на intel у меня до сих пор xorg-drv-intel-2.4.3
>> периода ранневесеннего M50.  В основном нормально, хотя и не
>> без претензий (не живёт :1, тормозит отрисовка при повороте
>> xrandr'ом на 90).
> У меня на eee901 и сизифный intel отлично живёт.
> 
>>> 2. Выкинуть отовсюду или починить putty.
>> Думаю, текущий и предыдущий майнтейнер удовольствуются наличием
>> в сизифе/бранчах/$HOME -- а что с ним?
> С ним gtk1.
> https://bugzilla.altlinux.org/show_bug.cgi?id=19630

А зачем он ?

Re: [devel] перебранчуем 5.0/branch?

[Andrey Rahmatullin]

On Fri, May 15, 2009 at 12:45:18PM +0400, Anton Farygin wrote:
>>> Думаю, текущий и предыдущий майнтейнер удовольствуются наличием
>>> в сизифе/бранчах/$HOME -- а что с ним?
>> С ним gtk1.
>> https://bugzilla.altlinux.org/show_bug.cgi?id=19630
> А зачем он ?
gtk1 или putty?
И кому?

Re: [devel] перебранчуем 5.0/branch?

[Anton Farygin]

Andrey Rahmatullin пишет:
> On Fri, May 15, 2009 at 12:45:18PM +0400, Anton Farygin wrote:
>>>> Думаю, текущий и предыдущий майнтейнер удовольствуются наличием
>>>> в сизифе/бранчах/$HOME -- а что с ним?
>>> С ним gtk1.
>>> https://bugzilla.altlinux.org/show_bug.cgi?id=19630
>> А зачем он ?
> gtk1 или putty?
> И кому?

putty - кому он нужен и зачем. Что это такое я знаю.

Re: [devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[Aleksey Novodvorsky]

15 мая 2009 г. 12:43 пользователь Andrey Rahmatullin <wrar@altlinux.ru> написал:
> On Fri, May 15, 2009 at 11:19:55AM +0300, Michael Shigorin wrote:
>> > Частное мнение: нынешний xorg, особенно в части драйверов
>> > intel, -- нерабочий.
>> Ещё не знаю, на intel у меня до сих пор xorg-drv-intel-2.4.3
>> периода ранневесеннего M50.  В основном нормально, хотя и не
>> без претензий (не живёт :1, тормозит отрисовка при повороте
>> xrandr'ом на 90).
> У меня на eee901 и сизифный intel отлично живёт.

Да, он иногда хорошо живет.
Проблема в частности в том, что UXA не доделали, а EXA сломали.
Часть проблем: https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
Там, где пишут о недостаточном тестировании следует обычно читать "не работает".

Rgrds, Алексей
>
>> > 2. Выкинуть отовсюду или починить putty.
>> Думаю, текущий и предыдущий майнтейнер удовольствуются наличием
>> в сизифе/бранчах/$HOME -- а что с ним?
> С ним gtk1.
> https://bugzilla.altlinux.org/show_bug.cgi?id=19630

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

Rgrds, Алексей

Re: [devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[Valery V. Inozemtsev]

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

[...]
> > У меня на eee901 и сизифный intel отлично живёт.
> 
> Да, он иногда хорошо живет.
> Проблема в частности в том, что UXA не доделали, а EXA сломали.

проблема не в UXA/EXA, а в древнем drm (читать в ядре 2.6.27 и
невозможности туда что то сбекпортить).

> Часть проблем: https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
> Там, где пишут о недостаточном тестировании следует обычно читать "не работает".

-- 
Valery V. Inozemtsev

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

Re: [devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[Aleksey Novodvorsky]

15 мая 2009 г. 12:57 пользователь Valery V. Inozemtsev
<shrek@altlinux.ru> написал:
> [...]
>> > У меня на eee901 и сизифный intel отлично живёт.
>>
>> Да, он иногда хорошо живет.
>> Проблема в частности в том, что UXA не доделали, а EXA сломали.
>
> проблема не в UXA/EXA, а в древнем drm (читать в ядре 2.6.27 и
> невозможности туда что то сбекпортить).

См. ссылку ниже. Там описаны проблемы со свежим ядром и это наши
проблемы. Это не отменяет необходимости нового ядра для десктопа.

>
>> Часть проблем: https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
>> Там, где пишут о недостаточном тестировании следует обычно читать "не работает".
>

Rgrds, Алексей

Re: [devel] перебранчуем 5.0/branch?

[Andrey Rahmatullin]

On Fri, May 15, 2009 at 12:49:14PM +0400, Anton Farygin wrote:
> putty - кому он нужен и зачем. 
Ну вон автор бага называет его "Самый популярный и необходимый системному
администратору SSH-клиент". Наверное, у него на это есть причины
(например, он других не видел и не знает).

Re: [devel] перебранчуем 5.0/branch?

[Alexey Shabalin]

15 мая 2009 г. 12:49 пользователь Anton Farygin написал:
> Andrey Rahmatullin пишет:
>>
>> On Fri, May 15, 2009 at 12:45:18PM +0400, Anton Farygin wrote:
>>>>>
>>>>> Думаю, текущий и предыдущий майнтейнер удовольствуются наличием
>>>>> в сизифе/бранчах/$HOME -- а что с ним?
>>>>
>>>> С ним gtk1.
>>>> https://bugzilla.altlinux.org/show_bug.cgi?id=19630
>>>
>>> А зачем он ?
>>
>> gtk1 или putty?
>> И кому?
>
> putty - кому он нужен и зачем. Что это такое я знаю.

Я могу расказать, зачем нужен putty :)
Для кого-то задача покажется надуманной, а вот мне пригодилось.
putty, точнее plink, удобно использовать для пакетных заданий с
ssh-серверами, которые не умеют авторизовывать по ключу. Это всякие
свичи и маршрутизаторы cisco(хотя в новых ios вроде добавили поддержку
ключей).
О существовании expect я знаю, но для его использования нужно на 100%
предсказать ответ сервера, что не удобно.

-- 
Alexey Shabalin

Re: [devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[Alexander Bokovoy]

2009/5/15 Valery V. Inozemtsev <shrek@altlinux.ru>:
> [...]
>> > У меня на eee901 и сизифный intel отлично живёт.
>>
>> Да, он иногда хорошо живет.
>> Проблема в частности в том, что UXA не доделали, а EXA сломали.
>
> проблема не в UXA/EXA, а в древнем drm (читать в ядре 2.6.27 и
> невозможности туда что то сбекпортить).

Описание Паккарда:
http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/

На самом деле, из 48 возможных комбинаций только часть зависит от drm
и значительная часть оставшихся от совсем другого. Риторический вопрос
о том, что надо бы либо прямо помогать апстриму исправлять находимые
ошибки, либо не заниматься пытками пользователей, пока пыточные машины
не будут приведены в работоспособное состояние, я оставлю за рамками.

-- 
/ Alexander Bokovoy

Re: [devel] перебранчуем 5.0/branch?

[Michael Shigorin]

On Fri, May 15, 2009 at 12:45:18PM +0400, Anton Farygin wrote:
> >>>2. Выкинуть отовсюду или починить putty.
> >>Думаю, текущий и предыдущий майнтейнер удовольствуются наличием
> >>в сизифе/бранчах/$HOME -- а что с ним?
> >С ним gtk1.

Странно, вроде 0.60 собирались переписывать на gtk2...
а, это в текущем svn появилось.

> >https://bugzilla.altlinux.org/show_bug.cgi?id=19630
> А зачем он ?

М-да.  Сдох бы уже LOR, что ли.  Как явление.

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

Re: [devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[Michael Shigorin]

On Fri, May 15, 2009 at 12:50:27PM +0400, Aleksey Novodvorsky wrote:
> >> > 2. Выкинуть отовсюду или починить putty.
> >> Думаю, текущий и предыдущий майнтейнер удовольствуются наличием
> >> в сизифе/бранчах/$HOME -- а что с ним?
> > С ним gtk1.
> > https://bugzilla.altlinux.org/show_bug.cgi?id=19630
> Мы его не кладем в дистрибутивы, но юзеры качают, -- привычка виндовая.

Это, простите, _их проблемы_.  При всей моей нелюбви к этому
выражению.  Иные вон и glibc-2.5 ставили под ядро 2.4.x, хотя
мы с sr@ угробили пару дней на то, чтоб это было нетривиально,
а Дима потом результат адаптировал и применил.

Другое дело, что можно попробовать сделать ещё один подход к gtk+,
если at@ не будет против.  В конце концов, кому он ещё нужен --
уж пусть на всякий вытянут и десяток метров шрифтов или придут
и сами предложат более элегантное дистрибутивное решение.

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

[devel] [JT] subsystem update policy (was: перебранчуем 5.0/branch?)

[Michael Shigorin]

On Fri, May 15, 2009 at 01:39:49PM +0300, Alexander Bokovoy wrote:
> Риторический вопрос о том, что надо бы либо прямо помогать
> апстриму исправлять находимые ошибки, либо не заниматься
> пытками пользователей, пока пыточные машины не будут приведены
> в работоспособное состояние, я оставлю за рамками.

Ну почему -- мне вообще кажется, что это хороший кандидат
в policy по обновлению жизненно важных подсистем: если ты можешь
физически обеспечить исправление проблем или хотя бы передачу
фидбэка апстриму -- только(!) тогда имеешь право обкатывать
заведомо сырой софт на живых людях.  Если нет -- не стоит
превращать их в заложников "УМВР" ради какого-то там прогресса.

(и то лучше сперва в сторонке, что для xorg*alt порой и бывало)

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

Re: [devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[Eugene Ostapets]

2009/5/15 Aleksey Novodvorsky <aen altlinux.ru>:
> 15 мая 2009 г. 0:40 пользователь Michael Shigorin <mike osdn.org.ua> написал:
> У меня также есть  пожелания к релизу по взаимодействию с виндой:
> 2. Выкинуть отовсюду или починить putty.
Зачем чинить то, что неполомано? И выкидывать то, что работает? Хотя
желающие могут поэкперементировать со сборкой putty из svn - там он
переехал на gtk2...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] [JT] subsystem update policy

[Anton Farygin]

Michael Shigorin пишет:
> On Fri, May 15, 2009 at 01:39:49PM +0300, Alexander Bokovoy wrote:
>> Риторический вопрос о том, что надо бы либо прямо помогать
>> апстриму исправлять находимые ошибки, либо не заниматься
>> пытками пользователей, пока пыточные машины не будут приведены
>> в работоспособное состояние, я оставлю за рамками.
> 
> Ну почему -- мне вообще кажется, что это хороший кандидат
> в policy по обновлению жизненно важных подсистем: если ты можешь
> физически обеспечить исправление проблем или хотя бы передачу
> фидбэка апстриму -- только(!) тогда имеешь право обкатывать
> заведомо сырой софт на живых людях.  Если нет -- не стоит
> превращать их в заложников "УМВР" ради какого-то там прогресса.
> 
> (и то лучше сперва в сторонке, что для xorg*alt порой и бывало)

Теперь осталось обкатать понятия - что такое "заведомо сырой софт", 
"жизненно важные подсистемы" и "живые люди".

Можно и Policy составить, но необходимо будет раскрыть эти термины.

Re: [devel] [JT] subsystem update policy

[Afanasov Dmitry]

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

On Fri, May 15, 2009 at 09:26:12PM +0400, Anton Farygin wrote:
> Michael Shigorin пишет:
> > On Fri, May 15, 2009 at 01:39:49PM +0300, Alexander Bokovoy wrote:
> Теперь осталось обкатать понятия - что такое "заведомо сырой софт", 
> "жизненно важные подсистемы" и "живые люди".
> 
> Можно и Policy составить, но необходимо будет раскрыть эти термины.
policy - это хорошо. но это не панацея. тут скорее общесловесный манифест
нужен с пониманием его каждым.

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

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

Re: [devel] [JT] subsystem update policy

[Valery V. Inozemtsev]

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

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

Дмитрий, а что у вас за видео карта?

-- 
Valery V. Inozemtsev

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

Re: [devel] [JT] subsystem update policy

[Anton Farygin]

Afanasov Dmitry пишет:
> On Fri, May 15, 2009 at 09:26:12PM +0400, Anton Farygin wrote:
>> Michael Shigorin пишет:
>>> On Fri, May 15, 2009 at 01:39:49PM +0300, Alexander Bokovoy wrote:
>> Теперь осталось обкатать понятия - что такое "заведомо сырой софт", 
>> "жизненно важные подсистемы" и "живые люди".
>>
>> Можно и Policy составить, но необходимо будет раскрыть эти термины.
> policy - это хорошо. но это не панацея. тут скорее общесловесный манифест
> нужен с пониманием его каждым.

А зачем нужен манифест, если его никто не будет читать ?

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

Не надо откатывать xorg _в сизифе_. Нужно его помогать _исправлять_, о 
чём очень правильно сказал Саша.

Но на это нужно значительные ресурсы. Может быть, как вариант, собирать 
xorg такой же как в Ubuntu/SlES/RheL ?

Re: [devel] [JT] subsystem update policy

[Michael Shigorin]

On Fri, May 15, 2009 at 09:26:12PM +0400, Anton Farygin wrote:
> Теперь осталось обкатать понятия - что такое "заведомо сырой софт", 
> "жизненно важные подсистемы" и "живые люди".

В нулевом приближении:

- заведомо сырой софт: содержащий уже известные апстриму
  критичные ошибки функциональности (например, "не работает
  на i965")

- жизненно важные подсистемы: kernel, glibc, x11

- живые люди: не заинтересованные специфически в тестировании/
  разработке компонента, о котором речь, участники team

> Можно и Policy составить, но необходимо будет раскрыть эти термины.

Вообще-то это уже [отчасти] делалось, но сейчас я отчасти
иронизировал.  Дело не в полиси, а в отношении просто.
Его полисями не изменишь.  И повторением особо тоже:

http://lists.altlinux.org/pipermail/devel/2008-September/160605.html
http://lists.altlinux.org/pipermail/devel/2008-September/160214.html
http://lists.altlinux.org/pipermail/devel/2007-October/145600.html
http://lists.altlinux.org/pipermail/sisyphus/2007-September/323392.html
и отчасти
http://lists.altlinux.org/pipermail/devel/2006-October/131377.html
http://lists.altlinux.org/pipermail/sisyphus/2006-January/296355.html
http://lists.altlinux.org/pipermail/sisyphus/2005-September/289453.html

Воз-то тяжёлый, он и ныне там.

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

Re: [devel] [JT] subsystem update policy

[Afanasov Dmitry]

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

On Fri, May 15, 2009 at 09:39:11PM +0400, Valery V. Inozemtsev wrote:
> > да и по хорошему полгода назад, когда стало ясно, что  xorg все плохо, его
> > стоило откатить назад административно. и так было бы, если бы задачей
> > проект и мантейнеров была бы работоспособность производимого.
> 
> Дмитрий, а что у вас за видео карта?
дома - nvidia, брал для предосвращения боев с ati. дома до'xorg'овский
сизиф от сентября.

на работе - ATI Technologies Inc RV630/M76 audio device [Radeon HD 2600 Series]

про запас:
на radeon, radeonhd, на ati не работает xv.
в dual режиме radeon со всем своим xrandr работает не столь адекватно, как
fglrx. требует включенного монитора при загрузке, на обоих не работает xv.

-- 
 С уважением
 Афанасов Дмитрий

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

Re: [devel] [JT] subsystem update policy

[Anton Farygin]

Michael Shigorin пишет:
> On Fri, May 15, 2009 at 09:26:12PM +0400, Anton Farygin wrote:
>> Теперь осталось обкатать понятия - что такое "заведомо сырой софт", 
>> "жизненно важные подсистемы" и "живые люди".
> 
> В нулевом приближении:
> 
> - заведомо сырой софт: содержащий уже известные апстриму
>   критичные ошибки функциональности (например, "не работает
>   на i965")

Миша, это не критично. Ну, понимаешь - если оно не работает на s3virge 
(или trident), то можно ли это считать критичным ?

> 
> - жизненно важные подсистемы: kernel, glibc, x11

А hal, udev, dbus, psi, kde, firefox ?

Понимаешь, я вот без openvpn,firefox и thunderbird - работать не могу... 
они для меня _жизненно_ важные. Пускай лучше будет сломан bluetooth в 
ядре -  я посижу без него.. но вот thunderbird, psi и firefox..

> 
> - живые люди: не заинтересованные специфически в тестировании/
>   разработке компонента, о котором речь, участники team

Т.е. - только участники team живые ? а пользователи ?

> 
>> Можно и Policy составить, но необходимо будет раскрыть эти термины.
> 
> Вообще-то это уже [отчасти] делалось, но сейчас я отчасти
> иронизировал.  Дело не в полиси, а в отношении просто.
> Его полисями не изменишь.  И повторением особо тоже:
> 
> http://lists.altlinux.org/pipermail/devel/2008-September/160605.html
> http://lists.altlinux.org/pipermail/devel/2008-September/160214.html
> http://lists.altlinux.org/pipermail/devel/2007-October/145600.html
> http://lists.altlinux.org/pipermail/sisyphus/2007-September/323392.html
> и отчасти
> http://lists.altlinux.org/pipermail/devel/2006-October/131377.html
> http://lists.altlinux.org/pipermail/sisyphus/2006-January/296355.html
> http://lists.altlinux.org/pipermail/sisyphus/2005-September/289453.html
> 
> Воз-то тяжёлый, он и ныне там.

Он там и будет, пока мы не определим круг - что можно класть в сизиф, а 
что нельзя. Что можно копировать в бранчи - а что нет.

К сожалению, эту нашу свободу надо ограничить.

Re: [devel] [JT] subsystem update policy

[Valery V. Inozemtsev]

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

В Птн, 15/05/2009 в 22:05 +0400, Afanasov Dmitry пишет:
> On Fri, May 15, 2009 at 09:39:11PM +0400, Valery V. Inozemtsev wrote:
> > > да и по хорошему полгода назад, когда стало ясно, что  xorg все плохо, его
> > > стоило откатить назад административно. и так было бы, если бы задачей
> > > проект и мантейнеров была бы работоспособность производимого.
> > 
> > Дмитрий, а что у вас за видео карта?
> дома - nvidia, брал для предосвращения боев с ati. дома до'xorg'овский
> сизиф от сентября.
> 
> на работе - ATI Technologies Inc RV630/M76 audio device [Radeon HD 2600 Series]
> 
> про запас:
> на radeon, radeonhd, на ati не работает xv.
> в dual режиме radeon со всем своим xrandr работает не столь адекватно, как
> fglrx. требует включенного монитора при загрузке, на обоих не работает xv.

у нас нет ни одного Radeon HD (fglrx других уже не поддерживает),
поэтому никто в компании ALT Linux не видел как они работают/неработают.
если вас так волнует судьба fglrx, займитесь им. там всего то ядерный
модуль поправить, что бы он правильно регистрировался в sysfs

-- 
Valery V. Inozemtsev

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

Re: [devel] [JT] subsystem update policy

[Michael Shigorin]

On Fri, May 15, 2009 at 10:07:24PM +0400, Anton Farygin wrote:
> >В нулевом приближении:
> >- заведомо сырой софт: содержащий уже известные апстриму
> >  критичные ошибки функциональности (например, "не работает
> >  на i965")
> Миша, это не критично. Ну, понимаешь - если оно не работает на
> s3virge (или trident), то можно ли это считать критичным ?

Регрессом, если раньше работало, но для настолько старого --
некритичным.  Да, я понимаю твой следующий вопрос :)

> >- жизненно важные подсистемы: kernel, glibc, x11
> А hal, udev, dbus, psi, kde, firefox ?

udev -- да; hal -- боюсь, да.  dbus -- не знаю.

> Понимаешь, я вот без openvpn,firefox и thunderbird - работать
> не могу...  они для меня _жизненно_ важные. Пускай лучше будет
> сломан bluetooth в ядре -  я посижу без него.. но вот
> thunderbird, psi и firefox..

Понимаю, потому и предлагаю ограничиться минимумом хотя бы.

> >- живые люди: не заинтересованные специфически в тестировании/
> >  разработке компонента, о котором речь, участники team
> Т.е. - только участники team живые ? а пользователи ?

Здесь бы хоть team сперва уважить, потом уж и до пользователей
может дойдёт щастье.

> >Воз-то тяжёлый, он и ныне там.
> Он там и будет, пока мы не определим круг - что можно класть в
> сизиф, а что нельзя. Что можно копировать в бранчи - а что нет.
> К сожалению, эту нашу свободу надо ограничить.

Угу, причём в первую очередь само-.

PS: боюсь, опять поговорили...

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

Re: [devel] [JT] subsystem update policy

[Led]

On Friday 15 May 2009 21:07:24 Anton Farygin wrote:
> Michael Shigorin пишет:
> > On Fri, May 15, 2009 at 09:26:12PM +0400, Anton Farygin wrote:
> >> Теперь осталось обкатать понятия - что такое "заведомо сырой софт",
> >> "жизненно важные подсистемы" и "живые люди".
> >
> > В нулевом приближении:
> >
> > - заведомо сырой софт: содержащий уже известные апстриму
> >   критичные ошибки функциональности (например, "не работает
> >   на i965")
>
> Миша, это не критично. Ну, понимаешь - если оно не работает на s3virge
> (или trident), то можно ли это считать критичным ?

ИМХО регресс - это всегда критично.

>
> > - жизненно важные подсистемы: kernel, glibc, x11
>
> А hal, udev, dbus, psi, kde, firefox ?

Возможно, udev, остльное - не настолько критично.

>
> Понимаешь, я вот без openvpn,firefox и thunderbird - работать не могу...
> они для меня _жизненно_ важные. Пускай лучше будет сломан bluetooth в
> ядре -  я посижу без него.. но вот thunderbird, psi и firefox..

Перечисленное выше "завязано" на "железо" (кроме glibc), остальное - нет. ИМХО 
регрессов с первым лучше не допускать.

-- 
Led

Re: [devel] [JT] subsystem update policy

[Aleksey Novodvorsky]

15.05.09, Anton Farygin<rider@altlinux.com> написал(а):
> Afanasov Dmitry пишет:
>
> > On Fri, May 15, 2009 at 09:26:12PM +0400, Anton Farygin wrote:
> >
> > > Michael Shigorin пишет:
> > >
> > > > On Fri, May 15, 2009 at 01:39:49PM +0300, Alexander Bokovoy wrote:
> > > >
> > > Теперь осталось обкатать понятия - что такое "заведомо сырой софт",
> "жизненно важные подсистемы" и "живые люди".
> > >
> > > Можно и Policy составить, но необходимо будет раскрыть эти термины.
> > >
> > policy - это хорошо. но это не панацея. тут скорее общесловесный манифест
> > нужен с пониманием его каждым.
> >
>
>  А зачем нужен манифест, если его никто не будет читать ?
>
>
> >
> > да и по хорошему полгода назад, когда стало ясно, что  xorg все плохо, его
> > стоило откатить назад административно. и так было бы, если бы задачей
> > проект и мантейнеров была бы работоспособность производимого.
> >
>
>  Не надо откатывать xorg _в сизифе_. Нужно его помогать _исправлять_, о чём
> очень правильно сказал Саша.
>
>  Но на это нужно значительные ресурсы. Может быть, как вариант, собирать
> xorg такой же как в Ubuntu/SlES/RheL ?

У них ровно те же проблемы с нынешним xorg.
Ошиблись мы тогда,  когда перенесли нынешний xorg в бранч. В нем были
некоторые улучшения  части новых карт и фич, но регрессия все же
слишком велика. Потому владельцы некоторых карт очень переживают и
считают во всем виноватым shrek@ и  ООО.
А виновата-то мировая закулиса!
Если серьезно, то к середине июля апстрим обещает починить. Надо
следить за их патчами постоянно.
Rgrds, Алексей




>
>
>  _______________________________________________
>  Devel mailing list
>  Devel@lists.altlinux.org
>  https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] [JT] subsystem update policy

[Anton Farygin]

Michael Shigorin пишет:
> On Fri, May 15, 2009 at 10:07:24PM +0400, Anton Farygin wrote:
>>> В нулевом приближении:
>>> - заведомо сырой софт: содержащий уже известные апстриму
>>>  критичные ошибки функциональности (например, "не работает
>>>  на i965")
>> Миша, это не критично. Ну, понимаешь - если оно не работает на
>> s3virge (или trident), то можно ли это считать критичным ?
> 
> Регрессом, если раньше работало, но для настолько старого --
> некритичным.  Да, я понимаю твой следующий вопрос :)

А у меня вот есть такое:
Cirrus CLGD 5446 PCI

> 
>>> - жизненно важные подсистемы: kernel, glibc, x11
>> А hal, udev, dbus, psi, kde, firefox ?
> 
> udev -- да; hal -- боюсь, да.  dbus -- не знаю.

Вот в том то и вопрос, что невозможно определить - что критично, а что 
не критично. Ровно эта же проблема стоит в ServerityPolicy - какая 
ошибка важна, а какая нет ?

> 
>> Понимаешь, я вот без openvpn,firefox и thunderbird - работать
>> не могу...  они для меня _жизненно_ важные. Пускай лучше будет
>> сломан bluetooth в ядре -  я посижу без него.. но вот
>> thunderbird, psi и firefox..
> 
> Понимаю, потому и предлагаю ограничиться минимумом хотя бы.

Да этот минимум никому не интересен.. ну, сломается звук в ядре - 
откатим, в следующей сборке исправят. Вот без xorg - да, тяжеловато.. но 
ты хоть раз видел _новые версии_ XFree86 или Xorg, такие, что бы 
_ничего_ не ломалось ?

> 
>>> - живые люди: не заинтересованные специфически в тестировании/
>>>  разработке компонента, о котором речь, участники team
>> Т.е. - только участники team живые ? а пользователи ?
> 
> Здесь бы хоть team сперва уважить, потом уж и до пользователей
> может дойдёт щастье.

Это дискриминация.. ;)

> 
>>> Воз-то тяжёлый, он и ныне там.
>> Он там и будет, пока мы не определим круг - что можно класть в
>> сизиф, а что нельзя. Что можно копировать в бранчи - а что нет.
>> К сожалению, эту нашу свободу надо ограничить.
> 
> Угу, причём в первую очередь само-.

Само - не получится. Для каждого из нас стабильность - понятие 
относительное. Вот по мне - GNOME стабильнее KDE. Ну не знаю, почему... 
просто стабильнее.

Или, для Legion'а - thunderbird3 показался хорошим. А я вот пока что 
опасаюсь и сижу на thunderbird2. Кто из нас прав ?

> 
> PS: боюсь, опять поговорили...

Миш, что случилось ? я не старался никого обидеть..

Re: [devel] [JT] subsystem update policy

[Anton Farygin]

Led пишет:
> On Friday 15 May 2009 21:07:24 Anton Farygin wrote:
>> Michael Shigorin пишет:
>>> On Fri, May 15, 2009 at 09:26:12PM +0400, Anton Farygin wrote:
>>>> Теперь осталось обкатать понятия - что такое "заведомо сырой софт",
>>>> "жизненно важные подсистемы" и "живые люди".
>>> В нулевом приближении:
>>>
>>> - заведомо сырой софт: содержащий уже известные апстриму
>>>   критичные ошибки функциональности (например, "не работает
>>>   на i965")
>> Миша, это не критично. Ну, понимаешь - если оно не работает на s3virge
>> (или trident), то можно ли это считать критичным ?
> 
> ИМХО регресс - это всегда критично.

А прогресс ? Что выбрать - регресс или прогресс ? Бывает ли прогресс без 
регресса ?

> 
>>> - жизненно важные подсистемы: kernel, glibc, x11
>> А hal, udev, dbus, psi, kde, firefox ?
> 
> Возможно, udev, остльное - не настолько критично.

А как без hal монтировать в KDE flash'ки ? Может быть у кого-то на 
монтировании флешек построен бизнес, и сломав hal мы лишим его семью 
куска хлеба ?

> 
>> Понимаешь, я вот без openvpn,firefox и thunderbird - работать не могу...
>> они для меня _жизненно_ важные. Пускай лучше будет сломан bluetooth в
>> ядре -  я посижу без него.. но вот thunderbird, psi и firefox..
> 
> Перечисленное выше "завязано" на "железо" (кроме glibc), остальное - нет. ИМХО 
> регрессов с первым лучше не допускать.

Для недопускания регрессов с железом - нужно каждую новую версию 
_тестировать_ на всём существующем железе...

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

Ты не поверишь - я больше года с нетерпением ждал свободных драйверов 
для Radeon X1400. Как думаешь, для меня лично - что было важнее ?

Re: [devel] [JT] subsystem update policy

[Led]

On Friday 15 May 2009 21:23:54 Anton Farygin wrote:
> >> Миша, это не критично. Ну, понимаешь - если оно не работает на
> >> s3virge (или trident), то можно ли это считать критичным ?
> >
> > Регрессом, если раньше работало, но для настолько старого --
> > некритичным.  Да, я понимаю твой следующий вопрос :)
>
> А у меня вот есть такое:
> Cirrus CLGD 5446 PCI

Этот как раз очень критичен: его всякие qemu/virtualbox'ы используют:)

-- 
Led

Re: [devel] [JT] subsystem update policy

[Afanasov Dmitry]

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

On Fri, May 15, 2009 at 10:13:23PM +0400, Valery V. Inozemtsev wrote:
> В Птн, 15/05/2009 в 22:05 +0400, Afanasov Dmitry пишет:
> > On Fri, May 15, 2009 at 09:39:11PM +0400, Valery V. Inozemtsev wrote:
> > > Дмитрий, а что у вас за видео карта?
> > на работе - ATI Technologies Inc RV630/M76 audio device [Radeon HD 2600 Series]
> 
> у нас нет ни одного Radeon HD (fglrx других уже не поддерживает),
> поэтому никто в компании ALT Linux не видел как они работают/неработают.
будем знать, что я уникум :) значит буду более внимательно тестить и
отчитываться.

> если вас так волнует судьба fglrx, займитесь им. там всего то ядерный
> модуль поправить, что бы он правильно регистрировался в sysfs
начиная с сентября, каждый месяц собираю очередной каталист. когда собирал
в апреле была нехватка символа, какого уже не упомню. также жаловался, что
собран под 7.4, а у нас 7.1.

уже успело изменится?

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


-- 
 С уважением
 Афанасов Дмитрий

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

Re: [devel] [JT] subsystem update policy

[Michael Shigorin]

On Fri, May 15, 2009 at 10:23:54PM +0400, Anton Farygin wrote:
> >Понимаю, потому и предлагаю ограничиться минимумом хотя бы.
> Да этот минимум никому не интересен..

Мне интересен, см. подборку ссылок за прошлые годы выше.

> ну, сломается звук в ядре - откатим, в следующей сборке
> исправят. Вот без xorg - да, тяжеловато.. но ты хоть раз видел
> _новые версии_ XFree86 или Xorg, такие, что бы _ничего_ не
> ломалось ?

Ну с XF86 ничего не ломалось как-то чаще, кроме 3.3.6->4.
Т.е. тогда сегодняшняя норма регрессов по иксам была скорее
ЧП.  Впрочем, что тут плакать -- жизнь рассудила.

> >>>- живые люди: не заинтересованные специфически в тестировании/
> >>> разработке компонента, о котором речь, участники team
> >>Т.е. - только участники team живые ? а пользователи ?
> >Здесь бы хоть team сперва уважить, потом уж и до пользователей
> >может дойдёт щастье.
> Это дискриминация.. ;)

Ага.  Если вон народ не сможет пилить gnome из-за сломанного xorg
(помнится, shaba@ как-то тоже бузил) -- пользователи пострадают
заведомо больше, чем только вследствие разлома xorg.

> >>>Воз-то тяжёлый, он и ныне там.
> >>Он там и будет, пока мы не определим круг - что можно класть в
> >>сизиф, а что нельзя. Что можно копировать в бранчи - а что нет.
> >>К сожалению, эту нашу свободу надо ограничить.
> >Угу, причём в первую очередь само-.
> Само - не получится.

В смысле "самоограничивать".

> >PS: боюсь, опять поговорили...
> Миш, что случилось ? я не старался никого обидеть..

Да не -- я к тому, что Валера это ну глянет и следующий xorg
свалится на голову по той же траектории. :)  А я его не против
тестить порой, когда получается/есть на чём/предсказуемо.

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

Re: [devel] [JT] subsystem update policy

[Anton Farygin]

Aleksey Novodvorsky пишет:
> 15.05.09, Anton Farygin<rider@altlinux.com> написал(а):
>> Afanasov Dmitry пишет:
>>
>>> On Fri, May 15, 2009 at 09:26:12PM +0400, Anton Farygin wrote:
>>>
>>>> Michael Shigorin пишет:
>>>>
>>>>> On Fri, May 15, 2009 at 01:39:49PM +0300, Alexander Bokovoy wrote:
>>>>>
>>>> Теперь осталось обкатать понятия - что такое "заведомо сырой софт",
>> "жизненно важные подсистемы" и "живые люди".
>>>> Можно и Policy составить, но необходимо будет раскрыть эти термины.
>>>>
>>> policy - это хорошо. но это не панацея. тут скорее общесловесный манифест
>>> нужен с пониманием его каждым.
>>>
>>  А зачем нужен манифест, если его никто не будет читать ?
>>
>>
>>> да и по хорошему полгода назад, когда стало ясно, что  xorg все плохо, его
>>> стоило откатить назад административно. и так было бы, если бы задачей
>>> проект и мантейнеров была бы работоспособность производимого.
>>>
>>  Не надо откатывать xorg _в сизифе_. Нужно его помогать _исправлять_, о чём
>> очень правильно сказал Саша.
>>
>>  Но на это нужно значительные ресурсы. Может быть, как вариант, собирать
>> xorg такой же как в Ubuntu/SlES/RheL ?
> 
> У них ровно те же проблемы с нынешним xorg.
Да, безусловно. Но просто меньше будет вопросов "куда спрыгнуть".

> Ошиблись мы тогда,  когда перенесли нынешний xorg в бранч. В нем были
> некоторые улучшения  части новых карт и фич, но регрессия все же
> слишком велика. Потому владельцы некоторых карт очень переживают и
> считают во всем виноватым shrek@ и  ООО.

Решение было действительно принято поспешно, при чём я лично и другие 
мои коллеги об этом неоднократно предупреждали в списке рассылки 
community. Может быть, иногда надо начинать прислушиваться к словам 
окружающих ?


> А виновата-то мировая закулиса!

Мировая закулиса тут не при чём.

> Если серьезно, то к середине июля апстрим обещает починить. Надо
> следить за их патчами постоянно.

Это ещё два месяца.

Re: [devel] [JT] subsystem update policy

[Anton Farygin]

Michael Shigorin пишет:
> On Fri, May 15, 2009 at 10:23:54PM +0400, Anton Farygin wrote:
>>> Понимаю, потому и предлагаю ограничиться минимумом хотя бы.
>> Да этот минимум никому не интересен..
> 
> Мне интересен, см. подборку ссылок за прошлые годы выше.

ну, точно такие же можно набрать по gcc, glibc, thunderbird, psi и тому 
подобному.. дело не в ссылках.

> 
>> ну, сломается звук в ядре - откатим, в следующей сборке
>> исправят. Вот без xorg - да, тяжеловато.. но ты хоть раз видел
>> _новые версии_ XFree86 или Xorg, такие, что бы _ничего_ не
>> ломалось ?
> 
> Ну с XF86 ничего не ломалось как-то чаще, кроме 3.3.6->4.
> Т.е. тогда сегодняшняя норма регрессов по иксам была скорее
> ЧП.  Впрочем, что тут плакать -- жизнь рассудила.

Да, но ты вспомни скорость разработки XF86 ...

> 
>>>>> - живые люди: не заинтересованные специфически в тестировании/
>>>>> разработке компонента, о котором речь, участники team
>>>> Т.е. - только участники team живые ? а пользователи ?
>>> Здесь бы хоть team сперва уважить, потом уж и до пользователей
>>> может дойдёт щастье.
>> Это дискриминация.. ;)
> 
> Ага.  Если вон народ не сможет пилить gnome из-за сломанного xorg
> (помнится, shaba@ как-то тоже бузил) -- пользователи пострадают
> заведомо больше, чем только вследствие разлома xorg.

А я вот самый хитрий, да ? Сижу себе на branch/5.0 и жужжу совсем мало 
мало..

Для сборки - рядом контейнер с сизифом, да и ssh git.alt когда там 
свободно (а контейнер недоступен)..

> 
>>>>> Воз-то тяжёлый, он и ныне там.
>>>> Он там и будет, пока мы не определим круг - что можно класть в
>>>> сизиф, а что нельзя. Что можно копировать в бранчи - а что нет.
>>>> К сожалению, эту нашу свободу надо ограничить.
>>> Угу, причём в первую очередь само-.
>> Само - не получится.
> 
> В смысле "самоограничивать".

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

Чьё мнение перевесит ?

> 
>>> PS: боюсь, опять поговорили...
>> Миш, что случилось ? я не старался никого обидеть..
> 
> Да не -- я к тому, что Валера это ну глянет и следующий xorg
> свалится на голову по той же траектории. :)  А я его не против
> тестить порой, когда получается/есть на чём/предсказуемо.

Так оно и свалится.. а куда деваться то ?

От камня не уйдёшь.. не свалится на нас, так свалится на бедных 
пользователей бубунты..

Re: [devel] [JT] subsystem update policy

[Michael Shigorin]

On Fri, May 15, 2009 at 10:42:46PM +0400, Anton Farygin wrote:
> >>>Понимаю, потому и предлагаю ограничиться минимумом хотя бы.
> >>Да этот минимум никому не интересен..
> >Мне интересен, см. подборку ссылок за прошлые годы выше.
> ну, точно такие же можно набрать по gcc, glibc, thunderbird,
> psi и тому подобному.. дело не в ссылках.

Да, но без этого минимума проблемы tb/psi тебя попросту
не взволнуют.

> А я вот самый хитрий, да ? Сижу себе на branch/5.0 и жужжу
> совсем мало мало..

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

> >>>>К сожалению, эту нашу свободу надо ограничить.
> >>>Угу, причём в первую очередь само-.
> >>Само - не получится.
> >В смысле "самоограничивать".
> А что делать, когда с одной стороны кричат "давай", а с другой
> "неззя" ?  Чьё мнение перевесит ?

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

> От камня не уйдёшь.. не свалится на нас, так свалится на бедных
> пользователей бубунты..

Их мне почему-то не так жалко, хоть это и неправильно, наверное.
Просто я их не вижу и главное -- ничем им в этом не могу помочь.

PS: пошли в team-policy@?

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

Re: [devel] [JT] subsystem update policy

[Anton Farygin]

Michael Shigorin пишет:
> 
> PS: пошли в team-policy@?
> 

Я лучше - спать.

Policy из этого всё равно пока что не вылезет. А вот обсудить то, что 
dottemag@ набросал - стоит.

Re: [devel] [JT] subsystem update policy

[Mikhail Gusarov]

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


Twas brillig at 22:16:51 15.05.2009 UTC+03 when mike@osdn.org.ua did gyre and gimble:

 MS> PS: пошли в team-policy@?

Нинада. Давайте бранчполиси уточнять :)

-- 

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

Re: [devel] [JT] subsystem update policy

[Aleksey Novodvorsky]

15 мая 2009 г. 22:35 пользователь Anton Farygin <rider@altlinux.com> написал:

>>>  Но на это нужно значительные ресурсы. Может быть, как вариант, собирать
>>> xorg такой же как в Ubuntu/SlES/RheL ?
>>
>> У них ровно те же проблемы с нынешним xorg.
>
> Да, безусловно. Но просто меньше будет вопросов "куда спрыгнуть".

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


>
>> Ошиблись мы тогда,  когда перенесли нынешний xorg в бранч. В нем были
>> некоторые улучшения  части новых карт и фич, но регрессия все же
>> слишком велика. Потому владельцы некоторых карт очень переживают и
>> считают во всем виноватым shrek@ и  ООО.
>
> Решение было действительно принято поспешно, при чём я лично и другие мои
> коллеги об этом неоднократно предупреждали в списке рассылки community.
> Может быть, иногда надо начинать прислушиваться к словам окружающих ?
>

RM имеет право на ошибку, как и любой из нас.

>
>> А виновата-то мировая закулиса!
>
> Мировая закулиса тут не при чём.


Да ну? :-)

>
>> Если серьезно, то к середине июля апстрим обещает починить. Надо
>> следить за их патчами постоянно.
>
> Это ещё два месяца.

community release можно раньше.

Rgrds, Алексей


> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] [JT] subsystem update policy

[Aleksey Novodvorsky]

15 мая 2009 г. 22:16 пользователь Led <ledest@gmail.com> написал:
> On Friday 15 May 2009 21:07:24 Anton Farygin wrote:
>> Michael Shigorin пишет:
>> > On Fri, May 15, 2009 at 09:26:12PM +0400, Anton Farygin wrote:
>> >> Теперь осталось обкатать понятия - что такое "заведомо сырой софт",
>> >> "жизненно важные подсистемы" и "живые люди".
>> >
>> > В нулевом приближении:
>> >
>> > - заведомо сырой софт: содержащий уже известные апстриму
>> >   критичные ошибки функциональности (например, "не работает
>> >   на i965")
>>
>> Миша, это не критично. Ну, понимаешь - если оно не работает на s3virge
>> (или trident), то можно ли это считать критичным ?
>
> ИМХО регресс - это всегда критично.

+1

>
>>
>> > - жизненно важные подсистемы: kernel, glibc, x11
>>
>> А hal, udev, dbus, psi, kde, firefox ?
>
> Возможно, udev, остльное - не настолько критично.
>
>>
>> Понимаешь, я вот без openvpn,firefox и thunderbird - работать не могу...
>> они для меня _жизненно_ важные. Пускай лучше будет сломан bluetooth в
>> ядре -  я посижу без него.. но вот thunderbird, psi и firefox..
>
> Перечисленное выше "завязано" на "железо" (кроме glibc), остальное - нет. ИМХО
> регрессов с первым лучше не допускать.
>

+1

Rgrds, Алексей

Re: [devel] [JT] subsystem update policy

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

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

On Fri, May 15, 2009 at 10:42:46PM +0400, Anton Farygin wrote:


>> Да не -- я к тому, что Валера это ну глянет и следующий xorg
>> свалится на голову по той же траектории. :)  А я его не против
>> тестить порой, когда получается/есть на чём/предсказуемо.
AF> Так оно и свалится.. а куда деваться то ?
AF> От камня не уйдёшь.. не свалится на нас, так свалится на бедных 
AF> пользователей бубунты..

Вот пусть пользователи бубунты и имеют свой геморрой. К счастью, я являюсь
пользователем ALT Linux а не бубунты, и проблемы бубунты меня интересуют
только в контексте "почитать при сборке пакета о чужих граблях чтобы
заранее обойти", не более того.

А разламывать пакеты надо в pocket'ах. Хочу pocket'ы! Вот были бы
pocket'ы, я бы начал DAHDI-подсистему собирать, а в Сизифе -- боюсь :)

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

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

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

Re: [devel] [JT] subsystem update policy

[Anton Farygin]

Aleksey Novodvorsky пишет:
> 15 мая 2009 г. 22:35 пользователь Anton Farygin <rider@altlinux.com> написал:
> 
>>>>  Но на это нужно значительные ресурсы. Может быть, как вариант, собирать
>>>> xorg такой же как в Ubuntu/SlES/RheL ?
>>> У них ровно те же проблемы с нынешним xorg.
>> Да, безусловно. Но просто меньше будет вопросов "куда спрыгнуть".
> 
> Так зачем собирать "такой же". Полагаю, кстати, что одним из стимулов
> копирования в бранч кривого xorg было как раз "а  у них уже".

Не знаю, что за вещества стимулировали этот процесс, но результат виден.

>>> Ошиблись мы тогда,  когда перенесли нынешний xorg в бранч. В нем были
>>> некоторые улучшения  части новых карт и фич, но регрессия все же
>>> слишком велика. Потому владельцы некоторых карт очень переживают и
>>> считают во всем виноватым shrek@ и  ООО.
>> Решение было действительно принято поспешно, при чём я лично и другие мои
>> коллеги об этом неоднократно предупреждали в списке рассылки community.
>> Может быть, иногда надо начинать прислушиваться к словам окружающих ?
>>
> 
> RM имеет право на ошибку, как и любой из нас.

К сожалению, в данном контексте, RM не имеет права на ошибку.

> 
>>> А виновата-то мировая закулиса!
>> Мировая закулиса тут не при чём.
> 
> 
> Да ну? :-)

Да да... ;)

> 
>>> Если серьезно, то к середине июля апстрим обещает починить. Надо
>>> следить за их патчами постоянно.
>> Это ещё два месяца.
> 
> community release можно раньше.

Какой в нём прок ? Делать его на Sisyphus ?

Re: [devel] [JT] subsystem update policy

[Anton Farygin]

Денис Смирнов пишет:
> On Fri, May 15, 2009 at 10:42:46PM +0400, Anton Farygin wrote:
> 
> 
>>> Да не -- я к тому, что Валера это ну глянет и следующий xorg
>>> свалится на голову по той же траектории. :)  А я его не против
>>> тестить порой, когда получается/есть на чём/предсказуемо.
> AF> Так оно и свалится.. а куда деваться то ?
> AF> От камня не уйдёшь.. не свалится на нас, так свалится на бедных 
> AF> пользователей бубунты..
> 
> Вот пусть пользователи бубунты и имеют свой геморрой. К счастью, я являюсь
> пользователем ALT Linux а не бубунты, и проблемы бубунты меня интересуют
> только в контексте "почитать при сборке пакета о чужих граблях чтобы
> заранее обойти", не более того.
> 
> А разламывать пакеты надо в pocket'ах. Хочу pocket'ы! Вот были бы
> pocket'ы, я бы начал DAHDI-подсистему собирать, а в Сизифе -- боюсь :)

Да, мне для selinux, в данный момент - тоже не помешали бы покеты. 
Придётся городить что-то своё, локальное.

Re: [devel] [JT] subsystem update policy

[Aleksey Novodvorsky]

16 мая 2009 г. 7:59 пользователь Anton Farygin <rider@altlinux.com> написал:

>>
>> community release можно раньше.
>
> Какой в нём прок ? Делать его на Sisyphus ?

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

Rgrds, Алексей

Re: [devel] [JT] subsystem update policy

[Valery V. Inozemtsev]

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

В Сбт, 16/05/2009 в 16:12 +0400, Aleksey Novodvorsky пишет:
> 16 мая 2009 г. 7:59 пользователь Anton Farygin <rider@altlinux.com> написал:
> 
> >>
> >> community release можно раньше.
> >
> > Какой в нём прок ? Делать его на Sisyphus ?
> 
> свободные драфверы фиксятся понемногу и мы сможем представить неплохую
> систему, которую ждут уже давно. И оттестируем.
> Да, на sisyphus, который забранчим за недельку до выхода (как вариант).

я давно хотел это предложить - делать бранч под уже готовый дистрибутив.
потом туда только security фиксы

-- 
Valery V. Inozemtsev

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

Re: [devel] перебранчуем 5.0/branch? (was: копировать нельзя отменить)

[Alexey Tourbin]

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

On Fri, May 15, 2009 at 03:45:10PM +0300, Michael Shigorin wrote:
> Другое дело, что можно попробовать сделать ещё один подход к gtk+,
> если at@ не будет против.  В конце концов, кому он ещё нужен --

Я не против, к тому же эта штука сейчас не собирается.
Прошу готовить изменения на основе
/people/at/packages/gtk.git 1.2.10-alt15 b3874f09

> уж пусть на всякий вытянут и десяток метров шрифтов или придут
> и сами предложат более элегантное дистрибутивное решение.

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

Re: [devel] перебранчуем 5.0/branch?

[AShen]

Michael Shigorin пишет:
> Другое дело, что можно попробовать сделать ещё один подход к gtk+,
> если at@ не будет против.  В конце концов, кому он ещё нужен --
gtk+ нужен lazarus'у ... lazarus на gtk2, qt, fpGUI не достаточно развит 
по сравнению с gtk+ ...

[devel] gtk+ (was: перебранчуем 5.0/branch?)

[Michael Shigorin]

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

On Tue, May 19, 2009 at 09:16:54PM +0400, Alexey Tourbin wrote:
> > Другое дело, что можно попробовать сделать ещё один подход к gtk+,
> > если at@ не будет против.  В конце концов, кому он ещё нужен --
> Я не против, к тому же эта штука сейчас не собирается.
> Прошу готовить изменения на основе
> /people/at/packages/gtk.git 1.2.10-alt15 b3874f09

Собирается (1.2.10-alt16, 62501ac).

> > уж пусть на всякий вытянут и десяток метров шрифтов или придут
> > и сами предложат более элегантное дистрибутивное решение.

А здесь вообще хохма: поставил для проверки в kvm
altlinux-5.0.0_beta-20090528-gnome-desktop-i586-ru-install-dvd5.iso
и добавил на него из 5.0/branch (ну забыл, забыл, неважно)
gtk+-1.2.10-alt15 и xmms-1.2.11-alt7.

Русские буковки в менюшках GTK1 были просто из коробки.

rpm -qa | grep bitmap показало fonts-bitmap-misc и -terminus;
снос terminus ничего не изменил (и на глаз не он), силовой снос
misc (от которого зависит xorg-server-common) менюшки сломал.

Сделал косметические правки в виде 1.2.10-alt17 (7f33a2c),
но вообще можно было и так честно сказать "УМВР".

Да, конкретно для xmms надо ещё доставить и запустить
xmms-cyrsetup, чтоб уже его настроило.  Этого специально
не делал.

putty тоже выглядит абсолютно адекватно, как для gtk1.

Так что наезды объявляю голословными.

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

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