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

PostgreSQL LogoУ цій статті я хотів би розповісти про те, як виглядає процес розробки 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 for everyone 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] і короткий опис. У тілі листа розкажіть, яку проблему вирішує патч, і яким чином він це робить. Почитайте архів розсилки, щоб подивитися, як це зазвичай виглядає. Якщо патч невеликий, наприклад, виправляє пару помилок, його можуть прийняти відразу і без особливих питань. У більш складних випадках патч потрібно надіслати на найближчий коммитфест:

PostgreSQL Commitfest

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

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

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

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

Висновок
Додаткові матеріали для самостійного вивчення:

Це все, про що я хочу сьогодні розповісти. Якщо у вас є питання, я буду радий відповісти на них у коментарях.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.