[devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

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 в отдельный пакет - то несколько больше.