Линус Торвальдс объявил (https://plus.google.com/102150693225130002912/posts/2BXkWyrY4jH) о незначительной задержке релиза Linux-ядра 3.0, который планировалось выпустить в понедельник. Задержка связана с обнаружением в последний момент проблемы, связанной с работой кода проверки файловых путей. Несмотря на то, что в настоящий момент уже доступен патч и известна причина возникновения проблемы, релиз будет немного задержан из-за необходимости провести дополнительное тестирование.
Отдельно отмечается, что выявленная ошибка проявляется крайне редко и требует достаточно специфичного стечения обстоятельств. Например, для чтобы повторить условия проявления проблемы потребовалось несколько недель стресс-тестирования. По словам Линуса на подобную редкую проблему можно было бы не обращать внимание, спокойно выпустить релиз и включить патч в состав одного из корректирующих обновлений, но выпуск релиза, в котором заведомо есть известные ошибки, какими бы редкими они ни были, заведомо порочная практика, до которой не следует опускаться.URL: https://plus.google.com/102150693225130002912/posts/2BXkWyrY4jH
Новость: http://www.opennet.ru/opennews/art.shtml?num=31225
1.98 revision 1,
1.98 revision 2,
...
Правильное решение. Не люблю, когда выходит какой-нибудь 3.0, а через день после него уже 3.0.1
Так через неделю все равно будет 3.0.1 :)
Так количество систем на котором будут мучить новое ядро увеличится в несколько раз. Тестировщики - страшные люди :)
Но им надо сказать спасибо за то что шишки от грабель - на их лбах, а не ваших.
будет, но ведь найдут ошибки, которые сейчас невидны. а закрывать те ошибки, которые уже известны до релиза это правильно.
Где можно поподробнее почитать, как они ядро тестируют?
Дожились, Линус пишет в гуглофлюс, правильно, накой в баню LKML, зачем...
Куда катится этот мир.
+1, похоже на рекламу новой соцсети
может человек решил попробовать. Что в этом такого предосудительного?
просто окошком ошибся
> Дожились, Линус пишет в гуглофлюс, правильно, накой в баню LKML, зачем...
> Куда катится этот мир.Списки рассылки никто не читает. Включая участников. Причем уже лет 30.
Ну-ну. Именно поэтому в lkml от 300 до 1000 сообщений в день?
Не читают.
Но пишут.:)
Ожидал такого комментария... %)
> Не читают.
> Но пишут.
> :)Отсюда вывод lkml пишут чукчи! =)))))))
Для вас важнее _куда_ он пишет или _что_ он пишет?
Относиться надо ко всему спокойнее...
Т е во всех релизах ядра нет никаких известных проблем? Что-то не верится.
Любой пользователь с ходу перечислит пару косяков связанных я ядром, которые его преследуют с н какого-то ядра или вообще хронически.
> Т е во всех релизах ядра нет никаких известных проблем? Что-то не
> верится.
> Любой пользователь с ходу перечислит пару косяков связанных я ядром, которые его
> преследуют с н какого-то ядра или вообще хронически.Одного 12309 хватит за глаза
> Одного 12309 хватит за глазаА это не один баг. Как всегда, лабухи навалили пачку разных багов в кучу, мало мальски похожих на то что там есть. Ждать закрытия такого бага можно долго. Что характерно, те подтипы багов которые могли мешать жить на большинстве конфигураций - удавлены. Поэтому в реальных конфигурациях указанный баг как правило не проявляется. То что проявляется, часто и нагло - давно пришиблено разработчиками. Потому что они тоже люди и им совсем не нравится работать в системе с такими багами, приколитесь?
специфичное стечение обстоятельств - это 1 час мирового тестирования. :)
> специфичное стечение обстоятельств - это 1 час мирового тестирования. :)Где ж ты был, Капитан? Пиво пил? Ну у меня вот стоит последний rc этого ядра а баг я так и не поймал.
Что мешает на каждую функцию ЗАРАНЕЕ писать микротест и добавлять его в систему автоматизированного модульного тестирования, чтобы не возникало ВНЕЗАПНОСТИ? Или лучше выпустить релиз, а тысячи хомячков всё оттестируют за месяц — потом только и останется разгребать тучи одних и тех же багрепортов? Идеология разработки: сначала пишем, потом думаем над тем, что же такое написали, и как оно работает на самом-то деле. :))Пора уходить от "побочных эффектов".
Что мешает учить жизни Оракел и фбзд коре тим?
вестимо, карма жабакодера шибко мешает
1. откуда такая уверенность, что они так не делают?
2. откуда уверенность в том, что эти микротесты покроют 100% всех возможных аварийных ситуаций?
3. если бы они соизволили тестировать на хомячках, то и вывалов ядра было бы до безобразия много, что не наблюдается в большинстве случаев.
4. а про идеологию, откуда такая инфа? по своему опыту, небось?
> 1. откуда такая уверенность, что они так не делают?потому что в этом случае testsuite был бы частью (причем весьма большой) исходиков ядра.
> 2. откуда уверенность в том, что эти микротесты покроют 100% всех возможных аварийных ситуаций?
микротесты могли бы покрыть часть кода, но вряд ли бы сгодились для драйверов устройств (если конечно не писать хитрые стабы).
> потому что в этом случае testsuite был бы частью (причем весьма большой) исходиков ядра.http://ltp.sourceforge.net/ Не часть. Где-то ты сфейлил?
> потому что в этом случае testsuite был бы частью (причем весьма большой)
> исходиков ядра.Видел массу проектов с юнит-тестами, битком набитыми вот таким. Которым все это не помогло. Test driven development - это мягко говоря не панацея. Более жестко говоря, попытки впарить его как единственно верный подход являются надувательством. Потому что есть масса проектов которые используют иные подходы, обладая хорошим качеством кода, равно как хватает проектов написаных по данному подходу, обладающих мерзкими багами.
> Что мешает на каждую функцию ЗАРАНЕЕ писать микротестТот факт, что конкурент напишет _сразу_ код, зарелизит, его протестируют на гораздо бОльшем числе систем, и только к тому времени мы закончим прогон микротестов, и сможем начать интеграционное тестирование.
BTW, хотелось бы посмотреть на микротест, который сможет эмулировать "несколько недель стресс-тестирования"
> BTW, хотелось бы посмотреть на микротест, который сможет эмулировать "несколько недель
> стресс-тестирования"А нету таких. Поэтому юнит-тесты - может и неплохое изобретение, но панацеей уж точно не является. Они могут протестировать пару стандартных ситуаций, гарантирующих лишь то что по крупному ничего не отъехало при стыковке 2 кусков кода. Баги такого уровня и так будут пойманы, с юнит тестами или без. А вот более заковыристые - юнит-тестами не ловятся вообще. Поэтому юниттесты имеют смысл только если удается их сделать без значительных затрат сил.
Мешает то что комбинаций функций + оборудования + программ, помноженных на количество версий перечисленного, превосходит все человеческие возможности по написанию тестов.
> Что мешает на каждую функцию ЗАРАНЕЕ писать микротест и добавлять его в систему автоматизированного модульного тестированияЭмерджентность (от англ. emergence — возникновение, появление нового) в теории систем — наличие у какой-либо системы особых свойств, не присущих её подсистемам и блокам, а также сумме элементов, не связанных особыми системообразующими связями; несводимость свойств системы к сумме свойств её компонентов.
Ну и указанный выше "зоопарк" реальных условий эксплуатации (комбинации железа, комбинации настроек, различные use-cases, и т. п.).
Буду банальным... Но как там с 12309? )
>Буду банальным... Но как там с 12309? )Он остался в ветке 2.6
>>Буду банальным... Но как там с 12309? )
>>Он остался в ветке 2.6O'Rly?!
Настоящая причина задержки релиза 3.0:>[оверквотинг удален]
>with the odd numbers going like:
>
> - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up
> to it (timeframe: a month or two).
> - 2.<odd>.x: aim for big changes that may destabilize the kernel for
> several releases (timeframe: a year or two)
> - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
> the kernel to be a microkernel using a special message-passing version
> of Visual Basic. (timeframe: "we expect that he will be released from
> the mental institution in a decade or two").