Re: [devel] [sisyphus -> devel] Стабильный Сизиф

["Денис Смирнов" <mithraen@altlinux.ru>]

On Mon, Jun 19, 2006 at 11:44:10AM +0300, Michael Shigorin wrote:

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

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

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

Поэтому надо эти репозитории разделить.

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

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

>>>> Для разработчиков удобно иногда совершать действия, которые
>>>> приводят к появлению множества unmet'ов. Значит в сизифе
>>>> наличие unmet'ов не рекомендовано, но выносить в orphaned
>>>> неустанавливаемый пакет можно не ранее чем через 2 месяца
>>>> (то бишь 8 недель),
> AT>> Ты рассматриваешь простейший вариант, когда имеется непосредственный
> AT>> unmet, в котором виноват сам этот пакет, содержащий unmet.  Существуют
> AT>> другие варианты, когда пакет нельзя установить из-за unmet'ов в других
> AT>> пакетах "вниз по дереву" (или "вверх"?).
>> Обрати внимание на слова "не ранее". Ранее нельзя выносить даже виновных.
MS> Бишь мы получаем, что разгребение бардака методом несоздания на
MS> данном этапе скорее просто заступорит разработку вообще.  Без
NS> рабочего варианта решения "как плюхнуть новую библиотеку, которая
MS> цепляет пол-сизифа".

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

MS> В принципе, когда-то Sisyphus характеризовался как замкнутый
MS> репозиторий.  Не знаю, насколько это соответствовало реальности, 
MS> но сейчас давно не соответствует (и стоило бы убрать из
MS> официальных страничек).

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

> AT>> В общем случае ситуация может быть ещё сложнее: пакет разрешает один
> AT>> старый unmet и добавляет один новый.  Хороший это пакет или плохой?
>> Мое мнение -- это не важно. Для репозитория который используют
>> разработчики это не имеет значения. Я выложил новую версию
>> библиотеки, которую я поддерживаю, значит все должны с этим
>> смириться. Или положить эту же библиотеку под другим именем
>> другой версии. Это -- безусловный факт, и наличие unmet'ов этот
>> процесс тормозить не должно.
MS> Факт, но не согласующийся с заботой о коллегах.  Иногда бывают
MS> дохлые, хотя полезные апстримы, и недостаток знаний для починки.
MS> Выход -- параллельные версии библиотек, как это ни неприятно.
MS> Но это тоже труд, особенно с учётом того, что предыдущая версия
MS> скорее сломается в бегущем вперёд окружении (e.g. gcc).

Я это понимаю :) Но обычно с этой библиотекой действительно _надо_
пересобрать пол сизифа. Только на пользователях другой половины Сизифа это
отражаться не должно.

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

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