Отдадим проект в хорошие руки

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

Кто тут неадекватен-то? Вот это — ненависть, отсутствие желания вести технический диалог, ответ вопросом на вопрос — за это вас и минусуют.

P.S. Если потом ещё где-то непонятно будет, за что вас минусуют — обращайтесь, разъясню.

Fedora я не упоминал. Мы для нее и пакетов не собираем, к тому же это leading edge дистрибутив и если регулярно обновлятся, там всё относительно хорошо из коробки.

openSUSE — имеет давнюю традицию по части подмешивания в nginx всякого говна, порой вопиюще отвратительного. Сейчас там nginx собран с Passenger, который славен тем, что делает разную магию в nginx, что порой вызывает совершенно странные баги в непредсказуемых местах. Из относительно свежего: mailman.nginx.org/pipermail/nginx/2013-February/037563.html (обратите внимание, баг проявляется даже если модуль не используется, а просто собран). Из вопиющего, какое-то время назад пользователи openSUSE получали из коробки nginx с печально известным flood_block модулем. Модуль представлял из себя откровенный говнокод, который при первом запросе форкал один из рабочих процессов, а затем каждый запрос подключался к потомку, отправлял в него данные, а тот искал по базе данных и возвращал ответ. Всё это происходило блокированно, причем блокировался не один рабочий процесс, а все, и вне зависимости от настроек, достаточно того, что он просто был собран. Если при этом происходила какая-нибудь ошибка, то всё ещё и падало. Nuff Said.

Что касается CentOS, то наверное нужно поблагодарить пользователей этого дистрибутива за то, что заставляют регулярно тренировать память. Самый большой поток жалоб на баги, исправленные несколько лет назад, приходится на них. Я даже не пойду смотреть, что там за пакет у них сейчас, и с чем они его собирают, и побекпортили ли они все security исправления, или нет (и по опыту, не исключено что не все). Этот дистрибутив базируется на ложных идеях о том, что устаревший (тут даже уместнее — антикварный), не поддерживаемый, протухший софт, с кучей известных багов — является стабильным. Это в корне не так, особенно в случае nginx.

Я не сильно ошибусь, если скажу, что в 95% случаев самый стабильный nginx — это последний коммит в репозитории. У нас драконовский процесс ревью с крайне строгими требованиями к его качеству. Код, который попадает в репозиторий, просматривает построчно от 6-ти до 8-ми глаз разработчиков-перфекционистов. Порой ревью при этом достигает двух десятков итераций. А сам nginx имеет такую структуру, что если и добавляются новые баги, то в большинстве случаев они локализованы строго той новой функциональностью, которая добавляется. В то же время баги в старой функциональности непрерывно исправляются и каждая последующая версия, как правило, является стабильнее всех предыдущих. Нет никакого резона держать версию старее, чем последняя. А если вы параноик и для вас боязнь наступить на новый баг смертельна, то обновляетесь на последнюю с небольшой задержкой (либо просто строго придерживайтесь последней версии stable-ветки по нашей классификации на странице download).

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

с хорошим качеством кода, что снижает трудности сопровождения

Это ложное представление о малых трудностях сопровождения. В действительности код nginx практически не документирован, является весьма сложной системой, не имеющей как такового стабильного обособленного API, и, вообще говоря, всех разработчиков, которые хорошо разбираются в нём, можно сосчитать по пальцам. А если исключить из счета сотрудников Nginx, Inc. то может и хватит одной руки.

Мейнтейнер дистрибутива чаще всего просто не в состоянии оценить качество того или иного стороннего кода, который он добавляет просто по просьбам пользователей или потому, что ему кажется он полезным. А бэкпортятся чаще всего только совсем критические уязвимости, на которые мы сами выкладываем патчи, и которых, к счастью, очень мало (хотя это не мешало, например, debian-у, при наличии опубликованных CVE и патча, жить примерно пол года с уязвимым nginx-ом). Но речь идет только о security-уязвимостях, а такие вещи как падения или очень досадные баги остаются до тех пор, пока народ не обновит дистрибутив (что может произойти только через несколько лет) или не подключит наш репозиторий.

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

Забавным остается то, что последствия чаще всего остаются незаметны от конечного пользователя. Тот же nginx чаще всего работает с таким запасом по производительности, что если его вдруг замедлить раз в 10, то это останется для многих незамеченным. Ну обрабатывает он запрос за 2мс с пакетом из нашего репозитория и за 20мс с пакетом из репозитория дистрибутива, если сервер не является высоконагруженным, не работает на пределе своих ресурсов, и если не делать специально тестов, это легко может оставаться незамеченным. Также и какие-нибудь баги, внесенные сторонним кодом, которые проявляются только при стечение некоторых обстоятельств и настроек.