URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 41812
[ Назад ]

Исходное сообщение
"OpenNews: Темп разработки Linux ядра может быть замедлен с целью повышения качества"

Отправлено opennews , 19-Май-08 12:05 
Начало разработки ядра версии 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


Содержание

Сообщения в этом обсуждении
"Темп разработки Linux ядра может быть замедлен с целью повышения качества"
Отправлено Nick , 19-Май-08 12:05 
неужели...
наконец-то.

СКорости - уже выше крыши.
Дааавно пора подумать о качестве.


"Темп разработки Linux ядра может быть замедлен с целью повышения качества"
Отправлено хзкто , 19-Май-08 12:22 
"Общее отношение числа ошибок к их количеству снизилось!"
Интересная фраза, я думал количество_ошибок == число_ошибок

"Темп разработки Linux ядра может быть замедлен с целью повыш..."
Отправлено cobold , 19-Май-08 12:29 
Одну и туже(с точки зрения разработчика) ошибку могут зарепортить несколько десятков раз.

"Темп разработки Linux ядра может быть замедлен с целью повыш..."
Отправлено overmailed , 19-Май-08 12:47 
"Общее отношение числа ошибок к их количеству снизилось!" , судя по всему, является переводом

"Subsystems are seeing flat or lower bugcounts/bugrates."

что имхо более точно:

"В подсистемах ядра неувеличивается отношение количества ошибок к их частоте."

Однако, что имеет ввиду Арйен ван де Вен всё равно не очень понятно :).


"Темп разработки Linux ядра может быть замедлен с целью повышения качества"
Отправлено avatar , 19-Май-08 13:31 
Давно пора!

"Темп разработки Linux ядра может быть замедлен с целью повышения качества"
Отправлено Аноним , 19-Май-08 14:06 
Наконец-то. Здравый смысл торжествует!!!!

"Темп разработки Linux ядра может быть замедлен с целью повышения качества"
Отправлено Аноним , 19-Май-08 16:42 
поддерживаю...

\\ краткость - сестра таланта...


"OpenNews: Темп разработки Linux ядра может быть замедлен с ц..."
Отправлено _umka_ , 19-Май-08 18:00 
Ну.. еще один шаг.. ну пожалуста.
Глядиш и вернут назад стабильное API... раз уж доходит что надо бы кому-то править их ошибки. А то сейчас правят то что по быстрее и чаще у людей вылазит - а на старые которые проявляются редко - ложат болт..

"OpenNews: Темп разработки Linux ядра может быть замедлен с ц..."
Отправлено Nick , 19-Май-08 18:04 
>Ну.. еще один шаг.. ну пожалуста.
>Глядиш и вернут назад стабильное API...

при любой скорости разработки - не вернут.
Ибо это строго ручной тормоз в развитии.


"OpenNews: Темп разработки Linux ядра может быть замедлен с ц..."
Отправлено Аноним , 20-Май-08 07:25 
Серьезно? Сколько тебе лет?

"OpenNews: Темп разработки Linux ядра может быть замедлен с ц..."
Отправлено Nick , 20-Май-08 17:10 
>Серьезно? Сколько тебе лет?

Школьник, читай Documentation/stable_api_nonsense.txt


"Темп разработки Linux ядра может быть замедлен с целью повышения качества"
Отправлено sneer , 19-Май-08 23:15 
а когда они sky2 драйвер починят для marvel сетевух интересно?

"Темп разработки Linux ядра может быть замедлен с целью повыш..."
Отправлено Аноним , 20-Май-08 01:35 
уже. начиная с 2.6.26-rc1 все прекрасно работает

"Темп разработки Linux ядра может быть замедлен с целью повыш..."
Отправлено sneer , 20-Май-08 10:53 
>уже. начиная с 2.6.26-rc1 все прекрасно работает

пожалуйста скажите какая модель в чейнжлоге этого релиза ничего нет о драйвере sky2


"Темп разработки Linux ядра может быть замедлен с целью повышения качества"
Отправлено Ne01eX , 20-Май-08 09:24 
На самом деле у всего этого плача о стабильном API есть одна причина.
Во времена чет/нечет простым людям было понятно что стабильное, а что не очень. теперь же картина вообще не ясна, - API ломают без какой-либо логики в нумерации. Даже использование вроде уже стейбла, на одну/две версии ниже текущей не спасает от новых сюрпризов. За примерами далеко ходить не надо, - еще свежо в памяти 2.6.16.x, которое чинилось после бакпорта новых фич из 2.6.17.x.
Читка рассылок конечно помогает, но не всегда получается увидить в них регрессию-подляну и уж тем более что-либо ожидать от нового ядра.

Я согласен, что должен быть строгий механизм нумерации версий, например: в нечетных ветках мы ломает и добавляем, а в четных ветках чиним и вычищаем. На мой взгляд это вполне вписывается в существующую схему нумерации и никому мозг ломать заново не надо и новых мажорных версий строить.


"Темп разработки Linux ядра может быть замедлен с целью повыш..."
Отправлено Nick , 20-Май-08 17:17 
Официальные нестабильные релизы (пусть и нечетные) - вот где отсутсвие логики.
Релиз - должен быть стабильным.

Щас ему далеко до этого, потому как скорость добавления фич высока.
А так: добавляем и ломает - rcX, а все ок - в релизах.


"Темп разработки Linux ядра может быть замедлен с целью повыш..."
Отправлено Ne01eX , 21-Май-08 08:36 
Ето понятно, но. Ломать-то проще чем строить. Соответсвенно на обезбаживание должно уделяться больше времени, чем на ломку.

"Темп разработки Linux ядра может быть замедлен с целью повышения качества"
Отправлено Аноним , 20-Май-08 19:10 
ГЫгы
Наконец-то подумали об этом.
На самом деле надоела уже эта ситуация, не прикольно когда драйвер не ставить на версии ядра выше 2.6.22 ...