From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4968E759.1090204@altlinux.com> Date: Sat, 10 Jan 2009 21:22:17 +0300 From: Anton Farygin User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: ALT Linux Team development discussions References: <47c0071b0901081150h662d70d0q8df86fa25ed02f07@mail.gmail.com> <20090110111717.GA30422@mw.office.seiros.ru> <4968E1F6.9050204@altlinux.com> <200901102009.13706.ledest@gmail.com> In-Reply-To: <200901102009.13706.ledest@gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?koi8-r?b?4sHHwSAoIMbP0s3BzNjOzyApIM3P1sXUIMkgzsXUICwg?= =?koi8-r?b?wSDXz9Qg0NLPwszFzcEgxdPU2CE=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.10b3 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 18:23:58 -0000 Archived-At: List-Archive: List-Post: Led пишет: > On Saturday, 10 January 2009 19:59:18 Anton Farygin wrote: >> Денис Смирнов пишет: >>> On Sat, Jan 10, 2009 at 10:03:24AM +0300, Anton Farygin wrote: >>> >>> AF> Потому что ядер должно быть мало. У нас и так силы людей, собирающих >>> AF> ядра - ограничены. Их нужно концентрировать, а не распылять. >>> >>> До недавнего времени их было куда больше. И то, почему остался только >>> один -- это хороший вопрос. >> Поддержка ядра - это процедура, требующая доволно приличного времени и >> сил, не говоря уже про голову и руки. >> >> То, что не все выдерживают - это нормальное явление. >> >>> AF> Т.е. - на мой взгляд тезис - каждой кухарке по ядру - не верен в >>> корне. AF> Лучше толпой исправлять одно ядро, чем одному человеку >>> собирать пять AF> разных ядер. >>> >>> Увы, не работает это. >>> >>> Иногда нужно провести какие-то эксперименты, собрать "левое" ядро. >>> Или нужно ядро со специфическими патчами. >>> Или для специфических задач (как led-tc). >>> >>> Так вот -- если люди не могут решать свои проблемы в рамках Сизифа, они >>> это будут делать в своих локальных репозиториях. >> Думаю, что led-tc возможно перетащить на 2.6.27, с 2.6.22.. > > Зачем? Чтоб было чем занаться ближайшие полгода тестируе его? а ты не думал над тем, что проще тестировать и поддерживать одну кодовую базу, а не разные ? > >> просто у >> Led'а на это в данный момент нет времени. > > ...И желания (см. выше) > >> Отсюда и грабли. >> >> Я честно - не смотрел какой там функционал, но не понимаю, почему его >> нельзя реализовать в std-def. > > Наверное, потому что и тот, кто мейнтейнит std-def тоже не имеет никакого > желания смотреть "какой там функционал". У него, подозреваю, слишком много других проблем. А вот внести изменения в std-def и попросить смержиться - это же тривиально просто... > >> Согласен, что бывают совсем странные случаи, когда лучше собрать ядро >> рядом (сам так делал). Но в идеале надо всё равно всё это хозяйство >> интегрировать в std-xxx (что и было сделано с v4l в своё время). > Это работа (интеграция v4l) на пару часов. Там было больше чем пару часов, ибо пришлось решать проблемы со сборкой всего остального. Если просто накрыть в std-def патчем новый v4l - то да, пара часов. а если выносить v4l в отдельный пакет - то несколько больше.