[devel] Следующий дистрибутив

Денис Смирнов =?iso-8859-1?q?mithraen_=CE=C1_altlinux=2Eru?=
Сб Июл 22 00:24:10 MSD 2006


On Thu, Jul 20, 2006 at 02:56:08PM +0400, Dmitry V. Levin wrote:

>> мантейнеров, имеющих разные скиллы. Однако в этом есть одна проблема --
>> скажем по параметру "качество сборки" я сейчас склонен доверять только
>> подписям двух людей -- at@ и ldv на . Бутылочное горлышко это, однако.
>> Эффективного решения этой проблемы, лично мне, не известно. Пока я вижу
>> только набор эвристик, которые позволят автоматически генерировать некий
>> репозиторий, который будет существенно лучше нынешнего.
DVL> Я думаю, что вы на самом деле доверяете ещё нескольким мантейнерам.

Конкретно по параметру "качество сборки", увы, я вижу сейчас только двух
"маньяков", для которых это критично. Больше мне неизвестного кого-либо,
который будет вкладывать огромный объем работы в небольшое увеличение
качества (это я про verify_elf всякие, as-needed, который многими попросту
бойкотировался в начале, и т.д.). Это не значит что я не доверяю _пакетам_
других мантейнеров, это значит что я не могу считать по-умолчанию
_качество спека_ очень высоким. Где-то это очень важно, где-то не важно
совсем.

Вот собрал я graphviz. Если ты посмотришь в спек, то у тебя сильно
испортится настроение, и надолго. Но приложение работает. Я абсолютно
уверен что на этот пакет надо вешать blocker, с текстом "мантейнера
пристрелить". Однако времени привести его в порядок у меня нет, и не будет
в ближайшее время. И больше никто на приведение этого кошмарика в чувство
браться не хочет.

По параметру "стабильность сборки", кстати, опыт показал, ни одному пакету
нельзя доверять, если он не прожил в Сизифе хотя бы несколько дней. Вон
даже ты как-то setup разломал так, что несколько дней мат в рассылке
слышен был.

То что я вижу как возможность автоматического формирования
"протестированого" репозитория, это подтверждения группы участников team,
чьи голоса будут взвешены, да ещё и по разным критерям. Да с разными
требованиями веса, в зависимости от "важности" пакета.

Вот есть, например, nginx. Я запросто могу отправить новую версию. Но вот
lakostis@ и mike@, которые его уже активно используют, могут поиметь
проблемы. И поэтому подписи пары человек _кроме_ меня будут существенны
чтобы принимать решение о возможной замене.

Скажем на пакете типа xmms мне подпись кого-либо, кто понимает существенно
выше среднего в безопасности мне нафиг не нужна. А вот пакеты уровня
какого-нибудь sqlite должны быть проверены с особой тщательностью.

А вот xorg вообще в "пользовательский" репозиторий без десятка-другого
подписей попадать не должен.

Есть характеристики:
 - безопасность (важно в основном для сервисов)
 - качество сборки (важно для системообразующих пакетов и библиотек)
 - работоспособность

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

Ну и после введения git'а review изменений можно будет делать куда проще.

Мне вот сейчас совершенно непонятно как строить такие списки с весовыми
коэффициентами. У каждого своё мнение.

>> Сейчас все упирается в отсутствие централизованого сервера, вместо
>> rsync-репозиториев (надеюсь когда Дмитрий вернется из отпуска эта проблема
>> будет решена).
DVL> Я тоже на это надеюсь.  В принципе сервер уже существует и даже делает вид
DVL> что работает.

Будем ждать с нетерпением. Вместе с документацией, или хотя бы
аудио-записью (о расшифровке не мечтаем) твоего доклада на тему
использования git в разработке.

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

http://freesource.info
----------------------------------------------------------------------------
inger, zerg: как вы такое отлаживаете-то?  поделитесь секретами :)
		-- mike in #6964



Подробная информация о списке рассылки Devel