Комментарии 28
Почему не используете гитхаб?
Чтоб не контрибьютили, очевидно. Такая же беда с OpenJDK :( Мейлинг листы в 2016м == ~0 новых контрибьютеров извне.
// Понятно, что это просто исторически и долго переезжать, но имхо, отсутствие свежей крови погубит эти проекты в долгосрочной перспективе.
Ну хз, вот например RethinkDB вполне имеет внешних контрибьюторов, Rust, Kotlin, и тд всё это сложные, большие проекты, но благодаря тому, что процесс контрибьюции всем известен и понятен он происходит.
А то, что это контрибуция в PostgreSQL затратное по времени занятие скорее всего говорит о слабой документации и автоматизации процессов.
Комьюнити должно быть большим и разнообразным и если кто-то захотел что-то законтрибьютить, ему ничто не должно мешать. Чем больше людей вовлечено в процесс и может внести изменения, тем более качественным получится продукт. Осознанно отсекать часть потенциальных контрибуторов предположением, что только "фуллтайм адепты" могут вносить изменения — это не самая хорошая идея.
Тонкий момент, на который налетают все начинающие контрибьюторы в PostgreSQL без исключения — если вы внесли изменение в .h файл, не забудьте прогнать make clean.
Увы, это имеет место не только в разработке для Postgres. Поправить одну строчку в .h, и ждать полчаса на сборку всего пакета.
И еще, хотелось бы услышать ваше мнение о ветке Postgres для 1С, насколько это соответствует стандартам разработки в мире Postgres.
Сборка PostgreSQL заточенная для 1C, насколько я знаю, никаким стандартам разработки в мире PostgreSQL не противоречит.
Я в Neovim добавил автоматическую генерацию деклараций функций, теперь любое изменение в файле вроде eval.c вызывает пересборку практически всего. Абсолютно не вижу как этого можно избежать, имея на руках только информацию о том, изменился ли файл и какой файл зависит от какого. Вот если бы система сборки видела более конкретные связи (к примеру, файл x.c использует функции foo() и bar() из y.h, но их сигнатуры не изменились ⇒ пересобирать x.c не нужно; аналогично с типами, константами, макросами), то таких пересборок избежать было бы можно.
«Если анализатором PVS-Studio заинтересуется кто-то из разработчиков проекта PostgreSQL, мы готовы предоставить им на время регистрационный ключ. Прошу написать их нам в поддержку.»
https://habrahabr.ru/company/pvs-studio/blog/207148/
Могу написать такую же про FreeBSD, если она будет кому-то интересна. У меня есть пара контрибьюшенов в дерево портов + я временами репорчу минорные баги в ядре.
Где увидеть еще не принятые патчи и куда писать свой code review?
Ревьювим. Находим соответствующий тред. Пишем туда что-то в таком стиле. Только здесь конкретно я нафакапил, так как поломал тред (надеюсь что сегодня его починю). Просто написать письмо с правильным subject, чтобы оно попало в тред, недостаточно, нужно в письме проставить правильный заголовок In-Reply-To. Или просто следить за тредом с самого начала.
В первом приближении как-то так.
Есть один пользователь Arch Linux.
У нас 3 пользователя Arch Linux и 2 пользователя Gentoo Linux (включая меня). Ubuntu всё меньше и меньше.
Становимся контрибьютером в PostgreSQL