А кем и как вообще принимается решение о том, чьи изменения войдут в ядро? И кто вообще имеет право/возможность их вносить?

Там система всё время меняется. Что-то среднее между диктатурой и анархией :)

Есть некоторое дерево (ну или восходящий граф). На вершине сидит Линус Торвальдс. В принципе, можно послать патчу прямо ему, и при определённых условиях он их примет.

Несколько сбоку от Линуса сидит Эндрю Мортон — это типа его «заместитель» или «правая рука». Можно послать патчи Мортону, он их принимает (если они ему нравятся) и накапливает в своём бранче, некоторое время маринует, а потом засылает Линусу.

Уровнем чуть ниже Линуса сидят мейнтейнеры различных подсистем — например, Dave Miller (и несколько его соратников) имеют свой отдельный бранч, куда они накапливают изменения для нетворкинга (вся сетевая подсистема, и драйвера сетевые тоже), или там Лен Браун. Если твой патч касается нетворкинга, не стоит засылать его прямо Линусу — у нетворкинга есть свой бранч и свой мейнтейнер, ему (не лично, конечно, а в соответствующий список рассылки — netdev@) это и надо засылать. Если что-то такое, у чего мейнтейнера и отдельной ветки нет — засылаем (обычно) Мортону или Линусу (и в lkml — linux kernel mailing list).

Понятное дело, с первого раза патчи обычно не берут. Иногда даже и цели такой не ставится, и патчи засылаются в соответствующую рассылку с комментом RFC (Request for Comments, мол, на обсуждение). Далее люди, которым это интересно, смотрят код, отвечают на него сооответствующими комментариями (типа «вот тут вот можно сделать проще» или «тут вот не хватает локинга, возможна плохая ситуация» или "а так вообще нельзя делать, кг/ам"). Если всё нравятся, просто пишут Signed-off-by: My Name <my@email.com> или Acked-by: Name . Signed-off-by — это типа подписано, человек под этим кодом подписывается. Подписаться как минимум должен сам автор :) Acked-by — это типа acknowledged, что-то вроде «принято» или «разрешаю» или «смотрел, пойдёт» или «не возражаю» — это тоже хороший признак, но не настолько сильный, как Signed-off-by. Но этого на первый раз обычно не происходят — обычно на первый раз тебе люди показывают, где ты налажал, или где можно улучшить, или где надо по-другому делать… Ты собираешь эти комменты (или дискутируешь в том же списке) и через какое-то время выпускаешь новую версию набора патчей. Так может пройти несколько итераций, и когда всем всё будет нравиться, уже можно отправлять с пометкой «возьмите», соответствующими Signed-off-by и прочее. Конечно, это я про сложные патчи говорил — какие-то простые, тривиальные, типа «исправить английский в документации», конечно, не нуждаются в итеративном улучшении — их или берут сразу, или это лажа какая-то.

В итоге это всё скапливается в бранче, который ведёт Линус Торвальдз. И он периодически (раз в два месяца теоречески, практически скорее раз в три месяца) выпускает релизы. Соответственно, трудится он тоже неравномерно — в самом начале (когда произошёл очередной релиз и начинается новая версия) берёт всё, что попало (не буквально, конечно), потом только мелкие фичи и фиксы, потом только фиксы, а в конце только регрессии (то есть фиксы к тому, что поломалось в этой версии) — так созревает следующая версия.

Если очень-очень схематично, то как-то так. Раньше схема была чуть более плоская, но когда народу стало больше, и количество присылаемых патчей стало больше, сделали такую «пирамиду», чтобы Линусу мог справляться.

Патчи прямо таки в виде исходников шлются, и при одобрении делается merge в какой-то бранч?

И получается, что любой желающий может слать исправления?

Чёрт, писал коммент на работе и не успел, похоже, дописать.

Патчи шлются в виде патчей (то есть текста в виде, понятном утилите patch;) -- по другому это называется diff'ом, потому что патч генерится утилитой diff). Так я тебя запутаю... Короче, там бывает несколько форматов, но они все похожи, поэтому на примере unified diff. обычно там идёт несколько строчек, предварённых знаком - (что значит -- эти строчки выкинуть), и несколько строчек, предварённых знаком + (что значит -- эти строчки добавить), и каждый такой блок из строчек с плюсами и минусами окружён контекстом (то есть несколькими строчками из исходников, которые не меняются.

Выглядит это примерно так (конечно, цвета уже добавила утилита, "раскрашивающая" патчи): http://git.openvz.org/?p=vzctl;a=commitdiff;h=d24176df3cfd1c103e90b932f3e16e4aee13e239
То есть вначале идёт описание, а потом сам патч. Вот в таком примерно виде оно и засылается (иногда одиночными патчами, иногда наборами из нескольких (до нескольких десятков). Если наборами -- то каждый патч в одинаковом письме, а в письмах в сабджекте стоит что-то типа [4/9] (то есть четвёртый патч из девяти) -- чтобы было понятно, сколько там всего, и в каком порядке их прикладывать.

Соответственно, если патч "нравится", обычно отвечают, что, мол, приложили, а если нет -- то почему не нравится. Возможен вариант дискуссии, в ходе которой рождается новая версия патча.

И таки да, исправления может слать совершенно любой желающий. Если есть желание начать -- есть специальные как-бы организации типа kernel newbies (http://kernelnewbies.org/) или kernel janitors -- первые учатся и учат друг друга, вторые (могут пересекаться с первыми) шлют простые патчи, которые "подчищают" что-нибудь тут и там. Вот типичный пример патча от kernel janitor:
http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b82d4043b3550df00a036f6aa2c8ab9578a283ef

по поводу diff и patch — вот тут микромануал, как ими пользоваться. Если совсем кратко, то diff умеет сравнивать два файла (или, скажем, два каталога со всем содержимым) и выводить разницу между ними, а patch умеет этот файл с разницей прикладывать к «старой» версии, чтобы получить новую (можно и наоборот, при желании).

http://stephenjungels.com/jungels.net/articles/diff-patch-ten-minutes.html

OK, более менее понятно. Спасибо за развёрнутую консультацию. Довольно интересно. :-)

Объясните пожалуйста в чем различия веток linux-next и linux-2.6? Какую из них для начала выбрать и сколько будет все это будет весить?

Берите linux-next
На диске займет около гига, я думаю. По сети трафик будет, возможно, поменьше.

Сколько оно будет весить на диске не важно, важно сколько скачать потребуется.
Судя из разговоров на linux-general@vger.kernel.org, в linux-next попадают исправления быстрее, чем в ветку Линуса. Так ?

Спасибо, очень познавательно.

Паша Емельянов рассказывал примерно про всё про это на конференции в Киеве осенью. Думаю заставить его рассказать то же самое «на Протве» летом.

Ага... Было очень интересно послушать. У меня кстати фотки остались!

Насколько я понимаю Мортону уже это дело жутко надоело или по крайней мере он уже просто устал заниматься проверкой патчей. Что же будет дальше? Эта пирамида выдержит бурный рост?

AFAIK, Signed-off-by is for the copyright trail. ACK means a code review. Не знаю даже как и сказать по-русски, ну в обсчем несколько иная направленность. Мантайнер может подписать не посмотрев если он знает откуда патч.

Тут можно только поздравить и пожелать дальнейших успехов!

Ого, есть с чем поздравить. Что и делаю ;)