[devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Michael Shigorin <mike@osdn.org.ua>]

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

On Thu, Jun 16, 2005 at 04:22:40PM +0400, Alexey Tourbin wrote:
> > Это плохо постольку, поскольку полиси в существенной степени
> > нигде не зафиксированы.
> Полиси пусть kirill@ пишет. :)

Я ж не против, постараюсь и помочь.  Только скорее не "пишет", 
а всё-таки "записывает", насколько понимаю.

> Предлагается установить достаточно высокую планку прохождения
> пакетов в сизиф.  И время от времени её поднимать.

Юмор оценил.

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

> > Есть предложение обязать вводящих полиси фиксировать их хотя
> > бы на том же wiki, если не в документации пакета, который
> Есть языковая проблема: если в рассылках словечки типа
> "слинковаться" -- это techspeak, то для документации это уже не
> катит.

В своё время внести Sisyphus в список дистров на faq.a.r мне
отказали, мотивировав это вполне внятно.  Я, собственно, и не
собирался спорить, а пошёл тормошить wiki.sisyphus.ru.

Есть мнение (высказанное этоё весной в docs@), что поднимать
планку для документации по Sisyphus превыше актуальности
бессмысленно.

> Может по-английски полиси писать?  Будет одно серьезное
> преимущество: весь остальной мир узнает, какие у нас здесь
> ценные идеи бродят. :)

Для англоязычного перевода есть более первоочередные цели,
когда кого-нить угораздит переводить.

> > масштабироваться (а как общественный проект -- он обязан быть
> > достаточно разным), следует реализовать различие критичности
> > проверок для различных компонент.
> Проверка ELF'ов достаточно критична.  Некритичные компоненты
> должны быть noarch -- с них и спросу никакого нет.

Ты хотел сказать "contrib"?  С noarch спрос бывает ещё какой.

> По поводу масштабирования, субъективное мнение: никакого
> масштабирования в ближайшем будущем не будет, лучше попытаться
> всеми силами вырваться вперед.

Зачем/как?

> Грубо говоря, чтобы на вопрос "чем это лучше Fedora Core" можно
> было с чистой совестью ответить: "всем"

Да ладно, хватает "works for me".

> Вперёд можно вырваться только за счет технологического
> превосходства.

Да нет, те же RH и SuSE IMVCO впереди исключительно за счёт
организационного превосходства.  Где-то на wiki есть мои
плевательства про их спеки, я уж не говорю про порезку пакетов 
и вагон всего прочего.

> > Есть мнение, что часть этих работ уже выполнена в рамках
> > проектов incominger и prometeus, при этом (похоже) имела
> > место некоторая дубликация.  Хорошо бы помочь их авторам
> > скоординироваться и/или интегрировать код.
> Подробнее: какой именно код дублируется?

Анализ пакета.  Как минимум процесс раздирания пакета на запчасти
-- точно. (речь не только о коде, но и о дубликации процессов)

> > Дим, а может, пора ALT начинать не толстеть, а взрослеть и
> > для начала всё те же правила игры публиковать?  А то забава
> > раскладыванием подводных грабель -- штука такая,
> > посмешит-посмешит да и надоест.
> Для RPM нужен legacy mode -- чтобы при сборке пакетов в частном
> порядке не приходилось вникать в особенности ALT полиси.

Ммм... это с отрывом большинства/всех проверок, не
предусмотренных в голом upstream?

> Более серьезная претензция как раз по части .la файлов -- не
> собираются KDE'шные приложения без хака на configure и т.п.
> Если совместимости на уровне RPM никто не гарантировал, то
> несовместимость на уровне GNU autotools -- это уже некий
> показатель.

Скажем так -- нигде эти несовместимости толком вместе не описаны.

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

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

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

"...а оптимист говорит -- есть куда!" :]

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

> > PS: рекомендую _прочитать_ вчерашнюю ссылку на newsforge и
> > подумать про перфекционизм.  Он уместен разве что в
> > SRPMS.perfect.  :)
> Да прочитал.  Вот несколько ошибок мы вчера нашли -- это хорошо
> или плохо?  Например, нерабочий libnss_wins.  Это какую
> пользовательскую базу нужно иметь, чтобы дождаться от
> тестеров-волонтёров квалифицированного багрепорта по этому
> поводу?  И какая у нас пользовательская база имеется и сколько
> тестеров-волонтёров тестируют в репозитарии специфические фичи.
> Очень важный вопрос.

Так тут вторая сторона ордена -- какую надо иметь квалификацию,
чтобы откопать корень проблемы и порешать его?  Дима -- *Дима* --
вон как-то обошёлся в ответе без слова "тривиально".

> Так вот, просто предлагается ликвидировать целый класс
> потенциальных ошибок.  Перфекционизм это или нет, я не знаю.

Это хорошее дело, если для contrib оно не будет вменяться в
обязанность.  В зависимости от высоты планки для base и
прилежащих компонент -- _там_ вполне может.  По крайней мере 
я был бы за.

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

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