Начало разработки ядра версии 2.6.26 отмечено (http://www.linuxworld.com/news/2008/051208-slow.html) большим количеством изменений, что привело к появлению ошибок, вызывающих множественные отказы, в том числе и при загрузке. Хотя эти проблемы были известны даже раньше, чем вышла версия 2.6.26-rc1, образовался ряд проблем между разработчиками, относительно несоответствия в версиях исправлений. Данное обстоятельство привело к множеству обращений разработчиков, с просьбой замедлить процесс разработки.Предлагается ограничить количество нововведений на каждом цикле разработки, определить подсистемы с большим количеством ошибок, регрессом и исключить новшества в них, пока не исправят старые проблемы. Кроме того, планируется вовлечь людей в изучение, тестирование, и работу с кодом, который будет добавлен.
Эндрю Мортон отметил: "существенная часть разработчиков, даже полагает, что нет никаких реальных проблем в этом отношении". А вот, по словам Arjan van de Ven "... мы добил...URL: http://www.linuxworld.com/news/2008/051208-slow.html
Новость: http://www.opennet.me/opennews/art.shtml?num=15947
неужели...
наконец-то.СКорости - уже выше крыши.
Дааавно пора подумать о качестве.
"Общее отношение числа ошибок к их количеству снизилось!"
Интересная фраза, я думал количество_ошибок == число_ошибок
Одну и туже(с точки зрения разработчика) ошибку могут зарепортить несколько десятков раз.
"Общее отношение числа ошибок к их количеству снизилось!" , судя по всему, является переводом"Subsystems are seeing flat or lower bugcounts/bugrates."
что имхо более точно:
"В подсистемах ядра неувеличивается отношение количества ошибок к их частоте."
Однако, что имеет ввиду Арйен ван де Вен всё равно не очень понятно :).
Давно пора!
Наконец-то. Здравый смысл торжествует!!!!
поддерживаю...\\ краткость - сестра таланта...
Ну.. еще один шаг.. ну пожалуста.
Глядиш и вернут назад стабильное API... раз уж доходит что надо бы кому-то править их ошибки. А то сейчас правят то что по быстрее и чаще у людей вылазит - а на старые которые проявляются редко - ложат болт..
>Ну.. еще один шаг.. ну пожалуста.
>Глядиш и вернут назад стабильное API...при любой скорости разработки - не вернут.
Ибо это строго ручной тормоз в развитии.
Серьезно? Сколько тебе лет?
>Серьезно? Сколько тебе лет?Школьник, читай Documentation/stable_api_nonsense.txt
а когда они sky2 драйвер починят для marvel сетевух интересно?
уже. начиная с 2.6.26-rc1 все прекрасно работает
>уже. начиная с 2.6.26-rc1 все прекрасно работаетпожалуйста скажите какая модель в чейнжлоге этого релиза ничего нет о драйвере sky2
На самом деле у всего этого плача о стабильном API есть одна причина.
Во времена чет/нечет простым людям было понятно что стабильное, а что не очень. теперь же картина вообще не ясна, - API ломают без какой-либо логики в нумерации. Даже использование вроде уже стейбла, на одну/две версии ниже текущей не спасает от новых сюрпризов. За примерами далеко ходить не надо, - еще свежо в памяти 2.6.16.x, которое чинилось после бакпорта новых фич из 2.6.17.x.
Читка рассылок конечно помогает, но не всегда получается увидить в них регрессию-подляну и уж тем более что-либо ожидать от нового ядра.Я согласен, что должен быть строгий механизм нумерации версий, например: в нечетных ветках мы ломает и добавляем, а в четных ветках чиним и вычищаем. На мой взгляд это вполне вписывается в существующую схему нумерации и никому мозг ломать заново не надо и новых мажорных версий строить.
Официальные нестабильные релизы (пусть и нечетные) - вот где отсутсвие логики.
Релиз - должен быть стабильным.Щас ему далеко до этого, потому как скорость добавления фич высока.
А так: добавляем и ломает - rcX, а все ок - в релизах.
Ето понятно, но. Ломать-то проще чем строить. Соответсвенно на обезбаживание должно уделяться больше времени, чем на ломку.
ГЫгы
Наконец-то подумали об этом.
На самом деле надоела уже эта ситуация, не прикольно когда драйвер не ставить на версии ядра выше 2.6.22 ...