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

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

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
----------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20091231/91cb1dd0/attachment.bin>