[devel] цели проекта ALT (was: suggesting arch/noarch)

[Mykola S. Grechukh]

ппкс

On 12/31/09, Денис Смирнов <mithraen на altlinux.ru> wrote:
> On Tue, Dec 29, 2009 at 03:41:59PM +0200, Michael Shigorin wrote:
>
> MS> Мой диагноз очень прост -- заигрались в технологии
> MS> и залюбовались на себя.
>
> Причем, что важно, для пользователя умного важнее люди в команде, чем их
> технологии.
>
> Потому как технологии надо развивать и т.д., а делать это, увы, роботы не
> умеют.
>
> Именно поэтому слова "ядро от vsu@", и "basesystem от ldv@" ценятся, как
> это ни странно, выше чем "хорошо собранное ядро", "хорошо собранная
> basesystem". Потому что первое -- это прогнозируемый уровень качества и
> поддержки, а второе -- нет.
>
> Миш, я с тобой согласен в плане указанных тобой проблем, но хочу заметить
> что они все-таки заметно комплексней.
>
> Неправильно говорить что технологии не важны, важны только люди. Это тоже
> бред, хотя и в меньшей степени чем "не надо заботиться о тупых людишках".
>
> Как ни крути, а параноидальные проверки, вкручиваемые at@ с ldv@ в
> сборочницу очень важны, и дают заметную выгоду нам как пользователям и
> интеграторам, хотя и создают геморрой нам как мантейнерам.
>
> Это классическая задача, сводящаяся к конфликту:
> - если не делать параноидальных проверок -- люди будут ошибаться, и
>   репозиторий будет таким же дерьмом как Fedora;
> - если делать параноидальные проверки, то свборка Hello World превращается
>   в весьма сложный квест, а также кривая обучения нового мантейнера
>   превращается в непреодолимую для большинства людей;
>
> И то, и другое приводит к потере ключевых преимуществ сизифа как
> платформы, а значит делает его неинтересным.
>
> То что предлагаешь ты -- это луддизм. То что предлагает Алексей -- это,
> откровенно говоря, открытое презрение к команде, типа роботы -- лучше. Обе
> этих моделей в чистом виде привели бы к краху, хотя предложенное тобой
> более жизнеспобно.
>
> Я же предлагаю забить на эту тему вообще, ибо этот конфликт неразрешим сам
> по себе, и сконцентрироваться на более четком разделение где именно
> применяется какая из моделей. Потому что нет неправильных технологий, есть
> применение их не там где надо. И это относится и к твоим предложениям, и к
> предложениям Алексея.
>
> Мое предложение:
> - решить таки вопрос с main+contrib, разделив уровень проверки;
> - для каждой новой параноидальной проверки должна быть ручка в spec'е
>   (кстати такая ручка хороша бы и для repocop'а);
> - любая проверка вводится следующим образом:
>   - на wiki описывается суть проверки, ее смысл, цели, технология,
> 	методики исправления и методики отключения проверки;
>   - сначала репокоп (с патчгенератором);
>   - потом в некоторой утилите, вроде rpmcs, которая позволила бы
> 	мантейнеру внести соответствующие модификации в spec легким движением
> 	руки;
>   - потом в sisyphus_check или другие средства ограничения при сборке в
> 	репозиторий;
> - в каждом средстве тестирования должен указываться url на соответствующее
>   описание в wiki;
>
> Если эта технология будет соблюдаться, то, как я понимаю, все твои
> претензии по поводу сложностей исчезнут полностью, правда ценой несколько
> более сложной процедуры введения новых технологий обеспечения надежности
> репозитория;
>
> Что скажешь?
>
> --
> С уважением, Денис
>
> http://freesource.info
> ----------------------------------------------------------------------------
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Mykola Grechukh
RISC Group IT Solutions