[d-kernel] kernel policy
aen
=?iso-8859-1?q?aen_=CE=C1_altlinux=2Eru?=
Чт Апр 17 18:18:31 MSD 2003
Dmitry V. Levin пишет:
>On Thu, Apr 17, 2003 at 02:14:34PM +0400, Anton Farygin wrote:
>
>
>>Ed V. Bartosh пишет:
>>
>>
>>>Hello, Anton
>>>AF> Удобство эксплуатации - безусловно, важный момент. А о
>>>AF> каком удобстве _эксплуатации_ может идти речь, если
>>>AF> вместо одного пакета появляется десяток-другой ?
>>>Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и
>>>позволяет гибко комплектовать окончательные kernel-image с набором
>>>нужных фич. А для юзера собственно ничего не меняется - он берет
>>>понравившийся kernel-image и ставит себе. Не хочет задумываться -
>>>берет std. Зато потом начинаются бонусы - обновляется какая-нибудь
>>>alsa и это не повод для вытягивания нового ядра, апгрэйдится только
>>>один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда
>>>это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь
>>>такого же плана ?
>>>
>>>
>>Насколько удобно будет сборщикам собирать новые пакеты с драйверами и ядра.
>>
>>Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс
>>сборки ядра будет выглядеть примерно так:
>>
>>1) Nidd собирает kernel-source и выкладывает
>>2) Мантейнеры соответствующих патчей начинают портировать свои патчи на
>>новое ядро. До тех пор, пока все не запортируются - нет возможности
>>собрать std-sub ядро
>>3) После портирования патчей мантейнеры ядер начинают медленно и упорно
>>собирать собственно сами ядра (не забыть, что еще нужно всем владельцам
>>пакетов kernel-feat, входящим в kernel-image запортироваться на новое
>>ядро (если есть необходимость))
>>
>>
>
>Нет, не совсем так.
>
>Поскольку у каждого kernel-image- свой maintainer, то именно он и
>занимается сборкой этого пакета, с обновлением соответствующих
>kernel-{fix,feat}. Если у последних есть собственные maintainer'ы
>(если и будут, то редко), то во взаимодействии с ними.
>
>Сборкой внешних модулей для каждого kernel-image- (тех, которые вообще
>применимы к соответствующим ядрам) занимаются maintainer'ы как этих
>модулей, так и maintainer'ы kernel-image- (кто именно, зависит от взаимной
>договорённости, по умолчанию - maintainer'ы внешних модулей).
>
>Все согласны?
>
>
>
Я согласен.
2nidd: ждем новой версии policy.
Rgrds, Алексей
Подробная информация о списке рассылки devel-kernel