> Коструктивный с точки зрения обычного девелопера - любое исправление _обязано_ так проходить, Как человек занимающися не первый год вопросами софтостроения могу сказать что столь ответственное и культурное поведение разработчиков как у Теодора - это скорее исключение чем правило. На бумаге много кто и чего обязан. А вот на практике далеко не все могут похвастать таким.
> обязаны найти комит который вносит ошибку - проализировать что там забыли
> и решить - это маленькая заплатка, или дыра в более высокоуровневом дизайне.
Теодор нашел root cause. Что еще от него надо? Он сказал все что в принципе мог сказать о проблеме.
> Но притензия
^^^^^ BUG. Это в высокоуровневом дизайне или маленькая заплатка? :)
> не к этому исправлению - а к тому что было внесено в 3.6.2.
Ну так насколько я понял, у Теодора хватило пороха раскрутить всю цепочку последовательности которая спровоцировала такое изменение. Зачетный детектив. Редко когда увидишь такой приличный разбор полетов.
>> убиения файловых систем участились. Как видим, стабильность апи не помогла
>> предотвратить жутковатый баг.
> Стабильность API позволяет развивать проекты до состояния готовом к включению в ядро.
У каждой команды свой стиль работы. С своим уставом в чужой монастырь не лезут как вы понимаете. Там есть устоявшийся состав участников. И они работают так как им удобно. Некоторые части ядра вполне себе пилят отдельно в своих репах и мержат лишь изредка, но взаимодействие у них достаточно плотное. Это и баг и фича. Но вполне себе валидный вариант на выбор. Да, там не получится сидеть в своем загончике и не интересоваться внешними миром - придется следить за жизнью проекта. Но это по моим наблюдениям достаточно распостраненная практика для многих индивидуалов и команд. Сложно играть в оркестре шпаря на своей волне и игнорируя всех остальных.
> Или даже просто развивать не тратя силы на постоянные переписывания. Кроме
> того постоянные переписывания вносят местами очень жудкие баги -
Да, писать "жутко" через д - ужасный баг. //У меня хрен проскочишь :)
> позволю опять себе пример OFED 1.5 и его backport на SuSe 10 (если
> не путаю - можно найти свою переписку с маинтейнерами OFED).
> Из-за ошибки в патчах для бэкпорта - создавалась ситуация когда счетчик dirty
> pages в системе забывал уменшаться - и система становилась раком на
> ровном месте через от 3 до 20 минут нагрузки.
Если честно, я в глубине души считаю бэкпорты злом по их природе, ибо прорва работы и грабель совершенно на ровном месте. По сути это попытка ссать против ветра. Другое дело что не всех устраивает бег на острие прогресса. Но опять же - выбор достатчно добровольный, наручниками никто никого вроде бы в XXI веке не приковывает уже. В чем проблема то? Вы хотите построить всю команду, заставив их работать иначе? А хрен, не получится. У них и так лыжи на мази, вкалывают как черти, релизят вполне приличные по качеству ядра, при том качество очень даже, если посмотреть на сроки выпуска и масштаб проекта. Такое сочетание параметров вообще мало кто осиливает. У них получилась весьма недурственная команда и стиль разработки. Ломать это ради вас одного? Многовато хотите, will not work.
> Пример полного переписывания - это изменение page fault api - который последовательно
> имел 3 или 4 редакции в разных ядрах - типа фигня вопрос.
Да, тем кто хочет жить в этом ядре придется играть по этим правилам. Так получилось. Это и баг и фича. Фича - в том что когда надо что-то разломать, они идут и переделывают, а не тянут ...цать лет. Поэтому они могут идти вперед. Баг - потому что ынтырпрайзы к такому обороту дел непривычны. Ну вот и приходится кому-то выступать "буфферами". Да, это нравится не всем. Ну так линуксы не единственная ос на свете. Прсото у других своих недостатков тьмы. Вон в винде стабильное апи. Настолько что уже третий десяток лет пичкают одними и теми же файловыми системами из древних девяностых. И работает оно соответствующе.
