The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

19.05.2008 11:50

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

Предлагается ограничить количество нововведений на каждом цикле разработки, определить подсистемы с большим количеством ошибок, регрессом и исключить новшества в них, пока не исправят старые проблемы. Кроме того, планируется вовлечь людей в изучение, тестирование, и работу с кодом, который будет добавлен.

Эндрю Мортон отметил: "существенная часть разработчиков, даже полагает, что нет никаких реальных проблем в этом отношении". А вот, по словам Arjan van de Ven "... мы добились большего успеха, чем в прошлый год, Мы больше сосредоточены на качестве. Мы исправляем ошибки, которые люди больше всего замечают. Общее отношение числа ошибок к интенсивности их появления снизилось (bugcounts/bugrates)!" Тэд Цо (Ted Ts'o) утверждает, что много проблем возникают вследствие неизвестного и низкокачественного железа.

При разработке драйверов, дополнений, исправлений необходимо учитывать специфику экспериментальных версий ядра, а не только текущих стабильных версий и пакетов с ядром из состава дистрибутивов. В версии 2.6.27 должны быть решены проблемы интеграции, уменьшено количество проблем, влияющих на последующие изменения. Иными словами, сделать менее болезненный переход от версии к версии.

  1. Главная ссылка к новости (http://www.linuxworld.com/news...)
Автор новости: pavlinux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/15947-Linux
Ключевые слова: Linux, Kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (18) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Nick (??), 12:05, 19/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    неужели...
    наконец-то.

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

     
  • 1.2, хзкто (?), 12:22, 19/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Общее отношение числа ошибок к их количеству снизилось!"
    Интересная фраза, я думал количество_ошибок == число_ошибок
     
     
  • 2.3, cobold (?), 12:29, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Одну и туже(с точки зрения разработчика) ошибку могут зарепортить несколько десятков раз.
     
     
  • 3.4, overmailed (?), 12:47, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    "Общее отношение числа ошибок к их количеству снизилось!" , судя по всему, является переводом

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

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

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

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

     

  • 1.5, avatar (??), 13:31, 19/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Давно пора!
     
  • 1.6, Аноним (-), 14:06, 19/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Наконец-то. Здравый смысл торжествует!!!!
     
  • 1.7, Аноним (7), 16:42, 19/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    поддерживаю...

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

     
  • 1.10, _umka_ (ok), 18:00, 19/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну.. еще один шаг.. ну пожалуста.
    Глядиш и вернут назад стабильное API... раз уж доходит что надо бы кому-то править их ошибки. А то сейчас правят то что по быстрее и чаще у людей вылазит - а на старые которые проявляются редко - ложат болт..
     
     
  • 2.11, Nick (??), 18:04, 19/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну.. еще один шаг.. ну пожалуста.
    >Глядиш и вернут назад стабильное API...

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

     
     
  • 3.16, Аноним (7), 07:25, 20/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Серьезно? Сколько тебе лет?
     
     
  • 4.19, Nick (??), 17:10, 20/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Серьезно? Сколько тебе лет?

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

     

  • 1.14, sneer (??), 23:15, 19/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а когда они sky2 драйвер починят для marvel сетевух интересно?
     
     
  • 2.15, Аноним (-), 01:35, 20/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    уже. начиная с 2.6.26-rc1 все прекрасно работает
     
     
  • 3.18, sneer (??), 10:53, 20/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >уже. начиная с 2.6.26-rc1 все прекрасно работает

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

     

  • 1.17, Ne01eX (??), 09:24, 20/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На самом деле у всего этого плача о стабильном API есть одна причина.
    Во времена чет/нечет простым людям было понятно что стабильное, а что не очень. теперь же картина вообще не ясна, - API ломают без какой-либо логики в нумерации. Даже использование вроде уже стейбла, на одну/две версии ниже текущей не спасает от новых сюрпризов. За примерами далеко ходить не надо, - еще свежо в памяти 2.6.16.x, которое чинилось после бакпорта новых фич из 2.6.17.x.
    Читка рассылок конечно помогает, но не всегда получается увидить в них регрессию-подляну и уж тем более что-либо ожидать от нового ядра.

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

     
     
  • 2.20, Nick (??), 17:17, 20/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Официальные нестабильные релизы (пусть и нечетные) - вот где отсутсвие логики.
    Релиз - должен быть стабильным.

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

     
     
  • 3.23, Ne01eX (??), 08:36, 21/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Ето понятно, но. Ломать-то проще чем строить. Соответсвенно на обезбаживание должно уделяться больше времени, чем на ломку.
     

  • 1.21, Аноним (21), 19:10, 20/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ГЫгы
    Наконец-то подумали об этом.
    На самом деле надоела уже эта ситуация, не прикольно когда драйвер не ставить на версии ядра выше 2.6.22 ...
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру