В q&a разделе Хабра присутствует довольно много вопросов от людей, выбирающих open source проект, в котором они хотели бы поучаствовать: раз, два, три, четыре, пять.
Думаю, многие слышали про браузер Google Chrome и про то, что он основан на open source проекте Chromium. Так получилось, что в течении прошедшего года мне удалось внести небольшой вклад в этот проект в качестве независимого разработчика (то есть я не имею никакого отношения к Google и занимаюсь этим проектом в свободное от работы время). В процессе мне, естественно, пришлось разобраться с некоторыми техническими и организационными моментами, чем и хотелось бы поделиться.
Ниже я расскажу о том, как собрать Хромиум в домашних условиях, как выбрать задачу из системы баг-трекинга и как сделать так, чтобы ваш код оказался в репозитории.
Для начала хочу сказать, что по адресу www.chromium.org/Home находятся подробнейшие инструкции на все случаи жизни — начиная от получения исходного кода и заканчивая инструкциями по отправке ваших патчей на коммит. Кроме того, рекомендую прочитать этот документ и пройтись по ссылкам в нем.
Процесс для независимого разработчика состоит из следующих шагов:
- Собрать Хромиум.
- Выбрать баг из Issues List.
- Исправить баг, протестировать.
- Отправить баг на ревью.
- Исправить review issues, перейти к шагу 4.
- Попросить ревьюера закоммитить ваш код.
- Наслаждаться результатом.
Ниже — подробнее о каждом из шагов.
Шаг 1. Собрать Хромиум
Для сборки требуется достаточно современный компьютер, различные документы на вышеуказанном сайте рекомендуют многоядерный процессор и не менее 8 Гб памяти. Кроме того, потребуется около 60 Гб свободного пространства на жестком диске, в качестве которого рекомендуют использовать отдельный SSD.
Исходный код можно забрать из репозитория с помощью SVN, но, поскольку объем кода значителен, рекомендуют выкачивать архив, разворачивать из него копию на локальной машине и только затем апдейтить ее из репозитория. Размер архива — чуть меньше двух гигабайт.
Подробнее здесь: dev.chromium.org/developers/how-tos/get-the-code
Перед сборкой необходимо, чтобы на машине были установлены все необходимые пакеты/SDK. Для каждой платформы есть своя подробная инструкция, например, для Windows — здесь ( www.chromium.org/developers/how-tos/build-instructions-windows ), для Linux — здесь ( code.google.com/p/chromium/wiki/LinuxBuildInstructions ).
Теперь немного о моем личном опыте. Все цифры будут приведены ориентировочно и исключительно по памяти, записей, к сожалению, не делал.
Мне удалось собрать Хром под Windows и Linux. Под Mac OS не удалось провести линковку, хотя компиляция прошла успешно.
Для сборки под Windows использовался компьютер пятилетней давности с двухядерным процессором и 3 Гб памяти. Полная сборка заняла около 6 часов (не могу сказать точнее, я ставил билд на ночь), плюс линковка — более получаса (на 32 битах оказалось невозможным включить инкрементальную линковку).
Для сборки версии под Линукс был арендован виртуальный сервер в облаке у одного из российских хостеров. Ресурсы там выделяются по запросу и при билде использовалось около 8 Гб памяти и 8 ядер процессора. Оплата там снимается за использованные ресурсы и билд с нуля обошелся, кажется, в 35 рублей. Время полного билда — около часа.
Для сборки под Mac OS использовался хакинтош в виртуальной машине, компиляция заняла больше десяти часов. Я не стал тестировать сборку под этой ОС, лишь убедился, что мои изменения не сломали билд.
Как сказал мне один из работников Google, разработчики, работающие над Хромом, используют два билд бокса с разными операционными системами на их собственный выбор. Он также добавил, что Chrome отличается от Chromium лишь наличием нескольких проприетарных модулей и логотипом. Процесс работы сотрудника Google над Chrome полностью совпадает с процессом работы независимого контрибьютора за исключением того, что сотрудник Google имеет доступ к некоторым закрытым записям в баг-трекере, связанным, например, с безопасностью.
Шаг 2. Выбрать баг из Issues List
Если сборка прошла успешно, вы можете найти открытый баг и попытаться его исправить. Все дефекты, относящиеся к браузеру, находятся в баг-трекере по адресу code.google.com/p/chromium/issues/list.
Начинающим разработчикам рекомендуется выбирать баги с меткой GoodFirstBug. Предполагается, что задачи с этой меткой проще и человек, имеющий слабое представление о коде, сможет достаточно быстро с ними разобраться.
Шаг 3. Исправить баг, протестировать
На этом шаге у вас уже есть работающая сборка и выбранный баг. Все, что вам остается, это попытаться воспроизвести баг и выяснить его причину, пользуясь отладчиком и здавым смыслом. Я пользовался Microsoft Visual C++ 2008 Express Edition (в данный момент они рекомендуют использовать версию 2010).
Перед исправлением бага настоятельно рекомендуют ознакомиться со style guide документом: www.chromium.org/developers/coding-style
К счастью, некоторые несоответствия кода гайдлайнам находятся автоматически утилитой gcl, которая используется для создания чейнджлиста перед отправкой на ревью (так, у меня она нашла пробелы в конце строки, которые я не заметил).
Также рекомендуется иметь опыт разработки промышленного кода, поскольку требования к качеству достаточно высокие.
Если это ваш первый фикс бага в проекте, то помимо изменений в коде вам необходимо внести ваше имя в файл AUTHORS и включить это изменение в ваш коммит.
Шаг 4. Отправить баг на ревью
Ревью кода перед коммитом в проекте обязательно. Если у автора кода нет прав на запись в репозиторий (а это как раз наш случай), то именно ревьюер, как правило, коммитит код.
Перед отправкой кода необходимо сформировать ченджлист, это делается командой gcl, подробнее смотрите здесь:
dev.chromium.org/developers/contributing-code#TOC-Create-a-change-list-CL-
После того, как чейнджлист сформирован, он отправляется в систему, которая называется Rietveld. Далее необходимо выбрать ревьюеров и послать им приглашение. Я искал их, просто просматривая историю изменения кода и выбирая людей, которые сделали наибольшее количество коммитов. Подробнее процесс описан здесь:
dev.chromium.org/developers/contributing-code#TOC-Request-review
Шаг 5. Исправить review issues, перейти к шагу 4
Ревьюеры обычно отвечают на письма в течении 24-48 часов. В моих случаях было несколько раундов ревью, и, насколько я понимаю, это распространенная практика. После того, как все ревьюеры ответят LGTM (looks good to me), вы можете попросить одного из них закоммитить ваш код.
Шаг 6. Попросить ревьюера закоммитить ваш код
Я обычно просто писал что-то вроде “Could you please commit it for me?” и получал через некоторое время письма от tryserver, а потом от commit-bot о том, что код попал в репозиторий.
Шаг 7. Наслаждаться результатом
В целом весь процесс оставил у меня самые положительные впечатления. Код качественный, все организационные и технические моменты подробно задокументированы на сайте chromium.org и в исходном коде. Утилиты удобные, а люди — дружелюбные.
С удовольствием отвечу на вопросы в комментариях.
Автор: alexaol
