Як взяти участь в open source проекті Chromium, SavePearlHarbor
Ще одна копія хабора
Головне меню
Навігація за записами
Як взяти участь у open source проекті Chromium
Думаю, багато хто чув про браузер Google Chrome і про те, що він ґрунтується на open source проекті Chromium. Так вийшло, що протягом минулого року мені вдалося зробити невеликий внесок у цей проект як незалежний розробник (тобто я не маю жодного відношення до Google і займаюся цим проектом у вільний від роботи час). У процесі мені, звичайно, довелося розібратися з деякими технічними та організаційними моментами, чим хотілося б поділитися.
Нижче я розповім про те, як зібрати Хроміум в домашніх умовах, як вибрати завдання із системи баг-трекінгу і як зробити так, щоб ваш код опинився в репозиторії.
Процес для незалежного розробника складається з наступних кроків:
- Зібрати Хроміум.
- Вибрати баг із 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
Розробникам-початківцям рекомендується вибирати баги з міткою 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 та у вихідному коді. Утиліти зручні, а люди — дружелюбні.