Становимся контрибьютером в PostgreSQL

В этой статье я хотел бы рассказать о том, как выглядит процесс разработки PostgreSQL глазами одного из контрибьютеров в этот самый PostgreSQL. Заниматься разработкой этой СУБД я начал в декабре 2015 года, когда устроился работать в компанию Postgres Professional. То есть, не так уж давно. А значит, еще свежи воспоминания о моментах, которые поначалу казались мне не вполне очевидными. Хотелось бы их законспектировать, чтобы новым людям, приходящим в нашу команду, а также всем тем, кто желает попробовать себя в роли разработчика открытой реляционной СУБД, было легче. Я расскажу о том, как выглядит процесс разработки PostgreSQL, какие инструменты я использую в своей повседневной работе, как следует оформлять патчи, и так далее. Заинтересовавшихся прошу проследовать под кат.

Набор инструментов

Вопрос, который будоражит умы миллионов — какую IDE или текстовый редактор использовать? :) Практика показывает, что разрабатывать PostgreSQL можно в чем угодно. Кто-то из моих коллег использует Sublime Text, кто-то предпочитает Vim, кто-то Emacs, также есть пользователи KDevelop и Visual Studio Code. Я лично первое время вполне успешно использовал CLion, сейчас же перешел на Vim + ctags. В общем и целом, главное, чтобы в редакторе была подсветка синтаксиса, переход к определению, возможно какие-то простые вещи вроде переименования переменных и проверки орфографии. Какие-то навороченные автоматические рафакторинги вам вряд ли понадобятся. Дело в том, что патч с результатом таких рефакторингов вряд ли так просто примут.

Второй не менее волнительный вопрос — какую ОС или дистрибутив Linux выбрать? У нас в компании многие разработчики используют Ubuntu. Также есть пользователи MacOS. Под Windows, вроде, никто не сидит — для разработки под эту платформу обычно запускают виртуалку. Есть один пользователь Arch Linux. Я лично долгое время пользовался Ubuntu, но недавно ударился головой и перешел на FreeBSD. В общем и целом, любая *nix система должна подойти.

PostgreSQL успешно компилируется GCC, CLang и Visual Studio, возможно и какими-то другими компиляторами (Intel C++ Compiler?). Более того, сообщество стремится поддерживать совместимость кода со всеми этими компиляторами. Так что компилятор вы можете использовать любой. Также вы можете использовать свой любимый отладчик, будь то GDB, LLDB, что-то встроенное в вашу IDE или какой-нибудь WinDbg.

Код PostgreSQL живет в Git. Помимо официального репозитория еще есть зеркало на GitHub, но это чисто зеркало. Открывать там issues и слать туда пуллреквесты бессмысленно. Во время разработки патча никому нет дела, какую систему контроля версий вы используете. Но патч обычно посылают в виде вывода команды git diff.

В первом приближении, вроде, ничего не забыл. Время от времени я также использую perf, tcpdump, strace/truss, dtrace, rr, lcov, различные статические анализаторы и другие инструменты. Но потребность в них возникает скорее в порядке исключения. Основные инструменты разработки — это текстовый редактор, git, компилятор, отладчик и, конечно же, мозг. Да, и еще почтовый клиент. Но об этом я расскажу ниже.

Сборка, прогон тестов и так далее

В настоящее время PostgreSQL использует Autotools. Autotools сам по себе не очень приятная штука. К тому же, не рассчитанная на Windows. Поэтому для сборки PostgreSQL под эту платформу предусмотрен специальный набор Perl-скриптов, что несколько костыльно. Мой коллега Юрий Журавлев пытается протолкнуть патч, переводящий PostgreSQL на CMake. Но там все непросто, так как текущая система расширений PostgreSQL сильно завязана на Autotools.

Все проекты, использующие Autotools, собираются примерно одинаково:

./configure --prefix=...
make -j4 -s
make check
make install

Для быстрого локального развертывания PostgreSQL я использую такой набор скриптов, многими из которых со мной поделился Стас Кельвич.

Тонкий момент, на который налетают все начинающие контрибьюторы в PostgreSQL без исключения — если вы внесли изменение в .h файл, не забудьте прогнать make clean. По умолчанию при изменении .h файла зависящие от него .c файлы не пересобираются. Если этого не знать, можно пронаблюдать широчайший спектр занимательнейших магических эффектов :)

Идея для первого патча, и как еще можно помочь проекту

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

Проще всего поискать в коде и документации опечатки. Их там действительно много. Так происходит по той причине, что перед мержем предложенных патчей коммитеры часто их слегка переписывают, совсем чуть-чуть. В результате получается совершенно новый патч, который никто не вычитывал, отсюда и опечатки. Можно просто следить за новыми коммитами и каждую неделю присылать 1-2 патча. Исправлением комментариев к коду сложно что-то сломать, поэтому ваш патч охотно примут.

Бывает так, что какие-то куски кода можно немного отрефакторить. Это тоже довольно простое изменение. Делаем код красивее и правильнее, прогоняем тесты, если ничего не сломалось — предлагаем патч.

Исправление багов. В рассылку pgsql-bugs@ регулярно репортят баги (как правило, минорные). Обычно исправление бага — это халява. Пишем тест, воспроизводящий баг. Переписываем код так, чтобы тест больше не падал. Шлем патч.

Оптимизация. Тоже халява — код должен делать то же самое, только быстрее. Пишем бенчмарк, воспроизводящий проблему с производительностью, переписываем код так, чтобы он работал быстрее, шлем патч.

Улучшение документации и комментариев. Например, вы пытаетесь понять, как работает код, но не понимаете. Похоже, вы нашли место, где комментарии к коду можно улучшить!

Часто можно найти, что запатчить, собрав проект каким-то необычным компилятором (например, очень старой или очень новой версией GCC), на необычной платформе (ARM, PowerPC, ...) под необычной операционной системой (NetBSD, OpenIndiana). Тесты обычно не сыпятся, но пара варнингов при компиляции может проскочить. Еще часто помогает прогнать по коду какой-нибудь статический анализатор.

Если у вас нет идеи для своего патча, вы можете существенно помочь проекту, сделав code review и/или протестировав чужой патч. Программисты, как правило, очень любят писать код, но не особо любят ревьювить и тестировать его. Поэтому ревьюверов в сообществе PostgreSQL прямо реально не хватает. Ревьювером, кстати, быть довольно просто. Нужно убедиться, что патч применяется, код после этого компилируется и проходит тесты, а также что задача, которую перед собой ставил автор, при этом решена. Если вам не ясно, как это проверить, возможно, автор недостаточно хорошо это описал. Это повод задать вопрос автору в соответствующем треде и перевести патч в состояние waiting on author. А если при этом вы еще и в состоянии читать код и давать адекватные советы по переименованию переменных и разбиению процедур на несколько, то вам просто цены нет! О code review, выставлении патчей на коммитфест и различных состояниях патчей речь пойдет далее.

Про мейлинг листы и блоги

Все общение разработчиков PostgreSQL происходит в рассылке pgsql-hackers@. Еще имеет смысл подписаться на pgsql-committers@. Туда прилетают уведомления о последних мержах в мастер, иногда завязывается обсуждение конкретного коммита. Трафик в этих двух мейлинг листах не такой уж большой, это вам не LKML. Их вполне реально читать со своего основного ящика без каких-либо фильтров (правда, я читаю далеко не все треды подряд). Я лично получаю их все на рабочий e-mail.

Еще может иметь смысл подписаться на pgsql-general@ (общие вопросы) и уже упомянутый pgsql-bugs@ (багрепорты). Но, строго говоря, для разработки это не требуется.

По поводу выбора почтового клиента. В принципе, подойдет любой. Многие используют Thunderbird. Я долгое время сидел на Claws Mail, а сейчас переполз на Mutt. Видел, как кто-то из коллег использует GMail.

Хорошим тоном является не слать в рассылку HTML-письма. Текст письма по ширине стоит ограничить 72-я символами. Понятное дело, использовать можно только английский язык. Использовать аттачи, в отличие от того же LKML, не запрещается. Тяжелые аттачи лучше куда-нибудь заливать, а не слать напрямую в мейлинг лист.

В сообществе PostgreSQL, насколько мне известно, нет какого-либо code of conduct. Но это не отменяет необходимости быть вежливым, не использовать сарказм, никогда не переходить на личности, и так далее. Электронные письма, особенно на английском языке, часто получаются несколько сухими. Поэтому неплохой идеей будет использовать в тексте побольше слов вроде please, thank you, и так далее. Я лично стараюсь начинать любое письмо словами вроде «Thank you everyone for great comments!» и заканчивать чем-то вроде «As always, please don't hesitate to share any thoughts on this topic!». Попробуйте, и вы удивитесь, насколько дружелюбнее к вам станет сообщество.

Возможно, стоило бы сказать пару слов про основных действующих лиц в рассылке, таких, как Tom Lane, Simon Riggs, Robert Haas, Andres Freund, Alvaro Herrera, Bruce Momjian, и других. Но проблема в том, что действующих лиц довольно много, и кто конкретно заинтересуется вашим патчем заранее сказать трудно. Поэтому скажу лишь, что неплохой идеей будет первое время читать подписи людей, которые вам отвечают, смотреть, на каких доменах находятся их e-mail, поискать их имена в git log ну или в Google в конце-то концов.

Кстати, некоторые люди из сообщества PostgreSQL ведут блоги (которые как раз можно найти благодаря Google), на которые не лишено смысла подписаться. Я лично в настоящее время подписан на следующие связанные с PostgreSQL RSS-фиды:

# PostgreSQL
http://postgresmen.ru/news.xml
http://planet.postgresql.org/rss20.xml
http://habrahabr.ru/rss/company/postgrespro/blog/
http://www.postgrespro.ru/rss
http://www.postgresql.org/news.rss
http://postgresweekly.com/rss/1ijl6aaa
http://postgres-edu.blogspot.com/feeds/posts/default
http://feeds.feedburner.com/depesz
http://rhaas.blogspot.com/feeds/posts/default
http://amitkapila16.blogspot.com/feeds/posts/default
http://obartunov.livejournal.com/data/rss

Заметьте, что в список входит Планета PostgreSQL, которая агрегирует многие блоги, которых нет в списке.

Как послать патч

В общем случае, прежде, чем начинать работу над каким-то большим патчем, не лишено смысла написать в pgsql-hackers@ письмо-proposal с описанием того, что вы хотите сделать, как, и зачем. Может оказаться, что это никому особо и не нужно. Или наоборот, что это так нужно, что за последние лет 5 предлагалось несколько решений, о которых вы не знаете, и с которыми стоит предварительно ознакомиться. Ну или вам могут просто дать пару советов по реализации, куда стоит посмотреть, какие граничные случаи учесть, и так далее. Разработчики PostgreSQL — занятые люди, у которых своих дел хватает, так что не стоит бояться, что вашу гениальную идею кто-то тут же украдет. Скорее вам скажут, что это вряд ли будет работать, и предоставят возможность доказать обратное.

По поводу оформления кода. В PostgreSQL используется ANSI C, так что про всякие там С11, C++ или Rust сразу забудьте. Для форматирования кода используется утилита pgindent. Инструкцию по ее сборке вы найдете в исходниках PostgreSQL, в файле src/tools/pgindent/README. Перед созданием патча всегда прогоняйте код через pgindent, иначе его никто даже смотреть не станет. (Но следите за тем, чтобы pgindent не вносил изменения там, где вы ничего не меняли! В этом случае, возможно, код будет проще отформатировать вручную.) В остальном каких-то особо строгих правил нет. Просто смотрите, как оформлен код в районе того места, куда вы вонзаетесь, и старайтесь писать так же.

Когда патч готов, оправьте его в pgsql-hackers@, указав в subject метку [PATCH] и краткое описание. В теле письма расскажите, какую проблему решает патч, и каким образом он это делает. Почитайте архив рассылки, чтобы посмотреть, как это обычно выглядит. Если патч небольшой, например, исправляет пару опечаток, его могут принять сразу и без особых вопросов. В более сложных случаях патч нужно отправить на ближайший коммитфест:



Коммитфест — это местное название спринта. Один коммитфест длится один месяц. Например, сейчас открыт сентябрьский коммитфест. Все новые патчи добавляются в него. В начале сентября начнется рассмотрение патчей из сентябрьского коммитфеста, а все новые патчи будут добавляться в ноябрьский (в октябре коммитфеста нет, месяц правятся баги и так далее). Так продолжается до марта, всего 4 коммитфеста — в сентябре, ноябре, январе и марте. Затем наступает кодфриз, правятся баги, формируются альфа- и бета-релизы.

Патчи на коммитфесте бывают в разных состояниях. Все они имеют говорящие названия. Needs review означает, что патчу требуется ревьювер. Waiting on author означает, что какие-то действия требуются со стороны автора патча. Ready for committer означает, что патч прошел кодревью и по нему больше нет вопросов. Один из коммитеров может ознакомиться с ним и либо вмержить, либо вернуть автору на доработку. Ну и так далее.

Запаситесь терпением. Если на ваш патч никто не реагирует, это не значит, что он никому не нужен. Просто сейчас все заняты другими патчами. Если ваш патч есть в коммитфесте и не висит в Waiting on author, про него никто не забудет, не переживайте. Если вам ответил ревьювер или коммитер, внимательно прочитайте ответ, внесите соответствующие изменения в патч и отправьте его новую версию. Спорить с ревьюверами или коммитерами, по моему личному опыту, занятие очень неблагодарное. Быстрее исправить код и послать исправленный патч. Более того, нередко потом понимаешь, что ревьювер или коммитер в общем-то был прав, а ты — нет. Впрочем, у некоторых моих коллег иной опыт, и они наоборот считают, что всегда нужно спорить.

Пока вы ждете реакции на ваш патч, неплохой идеей будет самим заревьювить чей-нибудь патч. В сообществе PostgreSQL есть такое негласное правило — если вы шлете патч за патчем, и сами при этом никого не ревьювите, то очень быстро перестанут ревьювить и вас. Более того, чем быстрее будут приняты или отклонены другие патчи на коммитфесте, тем быстрее очередь дойдет до вашего, тем больше у вас будет времени внести правки до закрытия коммитфеста.

Заключение

Дополнительные материалы для самостоятельного изучения:

• Видеокурс «Hacking PostgreSQL» Анастасии Лубенниковой. Замечательный курс о внутреннем устройстве PostgreSQL. Доступны видео и слайды.
• Книга Database System Implementation. Как в ней написано, именно так PostgreSQL и работает.
• Основы отладки при помощи GDB. Там же вы найдете ссылки на статьи про отладку при помощи LLDB, использование замечательного инструмента RR, и не только.
• О том, как профилировать код с использованием perf, bcc/eBPF и других инструментов. В статьях вы также найдете ссылки на материалы по DTrace и SystemTap.
• Туториалы по Valgrind'у и статическим анализаторам для C/C++. Эти инструменты помогают находить различного рода ошибки в коде, крайне полезно уметь ими пользоваться.
• Наша компания перманентно нанимает. Работа интересная, хотя и несколько специфичная. Привыкнув к недельным спринтам с еженедельной выкаткой нового кода, мне долгое время было непросто перестроиться.

Это все, о чем я хотел сегодня рассказать. Если у вас есть вопросы, я буду рад ответить на них в комментариях.

Продолжение: Контрибьютим в PostgreSQL: примеры реальных патчей, часть 1 из N