From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3E9EB7B7.60608@altlinux.ru> Date: Thu, 17 Apr 2003 18:18:31 +0400 From: aen User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.3) Gecko/20030309 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy References: <87he8zljh6.fsf@velvet.po.cs.msu.su> <3E9C5571.2040009@altlinux.ru> <3E9D746E.5040006@altlinux.ru> <3E9E4517.3070500@altlinux.com> <3E9E6A76.6050402@altlinux.com> <3E9E7E8A.1060907@altlinux.com> <20030417131653.GB32494@nomad.office.altlinux.org> In-Reply-To: <20030417131653.GB32494@nomad.office.altlinux.org> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Sender: devel-kernel-admin@altlinux.ru Errors-To: devel-kernel-admin@altlinux.ru X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: devel-kernel@altlinux.ru List-Unsubscribe: , List-Id: ALT Linux kernel packages development List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: 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, Алексей