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 ------ Linux.Kiev http://www.linux.kiev.ua/