From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Mailer: Gnus v5.8.8/XEmacs 21.4 - "Portable Code" X-Comment-To: Peter Novodvorsky To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy References: <20030415144045.GA13440@shamrock.office.altlinux.ru> <87he8zljh6.fsf@velvet.po.cs.msu.su> <874r4ylq0m.fsf@velvet.po.cs.msu.su> <20030416221006.GA27370@nomad.office.altlinux.org> In-Reply-To: From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: 17 Apr 2003 14:47:17 +0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r 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: Hello, Peter PN> Кстати я вношу с солгласия Эда и Димы патчик в kernel-policy: PN> kernel policy обновляется участниками kernel maintainer committee. PN> Состав kernel committee: PN> +- Ed Bartosh PN> +- Dmitry Levin PN> - Peter 'nidd' Novodvorsky Согласен, спасибо. А почему у всех e-mailы не @altlinux.ru ? >> В полиси можно зафиксировать общую стратегию, применяемую в >> репозитарии, пусть даже она будет носить рекомендательный характер. >> Ведь полиси - это стратегический документ ? PN> В качестве рекоммендации можно конечно. Тут прозвучало и другое мнение :) DVL> Модули, исходники которых живут и меняются асинхронно с самим ядром, имеет DVL> смысл собирать отдельно от ядра. Впрочем, я об этом уже говорил. >> Да, поддерживаю. PN> ура. Вот еще бы насчет базового ядра (только vanilla+fixes) kernel-image-common что-нибудь в полиси написать ? PN> Остаются два ключевых вопроса: PN> 1. Как прикладываются патчи (обязательность apply скрипта) Ну, мое предложение уже тут звучало :) PN> 2. и [I] Это не принципиально. Пусть kernel-headers-alsa, по-моему понятно. PN> Кажется всё, да? Про стратегию выноса в модули и kernel-image-common, если такое устраивает. PN> Насчёт возможности собирания внешних модулей внутри ядра. В redhat PN> используется система с директорией add-on, в которую всё PN> кладётся. Можно, чтобы каждый source пакет (типа alsa-source) включал PN> в себя apply скрипт, который распаковывает его самого в add-on и PN> прописывает в Config.in себя. А смысл их собирать внутри ядра ? PN> Хотелось бы по-быстрее завершить это обсуждение и принять базовую PN> полиси, чтобы приступить к работе. Да, у меня уже времени в обрез давно. Все планы поломались из-за этой задержки. Да, предлагаю убрать из Сизифа все это безобразие и начать реализовывать новую схему в Daedalus. После принятия полиси, разумеется. -- Best regards, Ed V. Bartosh