[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