Fullstack developer
0,0
рейтинг
9 января 2013 в 10:32

Разработка → Как принять участие в open source проекте Chromium tutorial

В q&a разделе Хабра присутствует довольно много вопросов от людей, выбирающих open source проект, в котором они хотели бы поучаствовать: раз, два, три, четыре, пять.

Думаю, многие слышали про браузер Google Chrome и про то, что он основан на open source проекте Chromium. Так получилось, что в течении прошедшего года мне удалось внести небольшой вклад в этот проект в качестве независимого разработчика (то есть я не имею никакого отношения к Google и занимаюсь этим проектом в свободное от работы время). В процессе мне, естественно, пришлось разобраться с некоторыми техническими и организационными моментами, чем и хотелось бы поделиться.

Ниже я расскажу о том, как собрать Хромиум в домашних условиях, как выбрать задачу из системы баг-трекинга и как сделать так, чтобы ваш код оказался в репозитории.

Для начала хочу сказать, что по адресу www.chromium.org/Home находятся подробнейшие инструкции на все случаи жизни — начиная от получения исходного кода и заканчивая инструкциями по отправке ваших патчей на коммит. Кроме того, рекомендую прочитать этот документ и пройтись по ссылкам в нем.

Процесс для независимого разработчика состоит из следующих шагов:

  1. Собрать Хромиум.
  2. Выбрать баг из Issues List.
  3. Исправить баг, протестировать.
  4. Отправить баг на ревью.
  5. Исправить review issues, перейти к шагу 4.
  6. Попросить ревьюера закоммитить ваш код.
  7. Наслаждаться результатом.

Ниже — подробнее о каждом из шагов.

Шаг 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 и в исходном коде. Утилиты удобные, а люди — дружелюбные.

С удовольствием отвечу на вопросы в комментариях.
Alexey Korepanov @alexaol
карма
64,0
рейтинг 0,0
Fullstack developer
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (58)

  • +22
    После скольких успешно закрытых багов берут на работу в Гугл? :)

    Полная сборка заняла около 6 часов
    xkcd.com/303/
    image
    • +3
      i7, SSD, 12 Gb RAM, incredubuild — и полная пересборка зпанимает около 40 мин, при небольших правках и вовсе достаточно шустро.
      • +5
        «Достаточно шустро» в моём понимании — это секунд пять между нажатием хоткея для Build/Run и запуском программы в отладчике :)
        • +2
          У сотрудников Гугла примерно так и есть :)
          https://plus.google.com/108706994620819334985/posts/9yvfSRdrVz9
          • +1
            Скриншот по ссылке, с загрузкой 32 ядер на ~100%
            image


            Как-то не верится, что компилляция Хрома может нагрузить 32 ядра — больше похоже на то, что у него в Хроме под линуксом открыт десяток вкладок с флэшбаннерами :)
            • +9
              Компиляция прекрасно параллелится.
              • +1
                А можно заюзать Ccache и даже все перекомпилировать заново не нужно будет
                • 0
                  Я не уверен что будет сильный выигрыш. Перекомпиляция с маленькими изменениями и так происходит совсем быстро.
            • 0
              а что это за железо?
              • 0
                HP Z620
    • 0
      Не могу сказать, после скольки закрытых багов берут в Гугл. По моим ощущениям, компании-гиганты вроде Амазона, Гугла и Микрософта ищут программистов, умеющих быстро решать алгоритмические задачи и просто сообразительных. Участие в реальных проектах менее важно, чем умение быстро выяснить, например, что двоичное дерево является деревом поиска, впервые встретившись с этой задачей. И это, на мой взгляд, логично — такие программисты будут на порядок производительнее своих коллег.

      Это впечатление основано на личном опыте (в двух из этих трех компаний я доходил до «онсайт» интервью, к сожалению, неудачно). Зато в этих организациях работают по-настоящему умные ребята.
      • 0
        И то, и другое важно. Работа над серьёзными open source проектами — большой плюс при приёме на работу.
  • +1
    Интересно, а какой баг Вы исправили?
  • +5
    Может я ошибаюсь, но, помойму, Хромиум слишком тяжеловесный проект для новичка в мире Opensource. И я говорю не так про объем кода, как количество всех деталей в процесе сотрудничества, работы над кодом, документирования, отчета о проделаной работе и тд.

    Я бы все таки рекоммендовал найти проект среднего размера на Github или, к примеру, у Apache есть проекты любого калибра от монстров до мелких библиотек на многих языках.
    • +3
      Это как раз тот случай, когда не стоит бояться трудностей и начать именно с такого большого проекта, как Chromium. У него большое сообщество разработчиков, куча инструкций, все продумано для новичков — отличный опыт в командной разработке в промышленных масштабах. Помучившись со всем, что вы перечислили здесь, вы сможете применять лучшие практики организации разработки в своих и чужих кампаниях в будущем.
      • 0
        Возможно, вы правы.

        Из личного опыта я много раз пытался вникнуть в процесс разработки крупных проектов (Ubuntu и Debian если быть точнее), которые так само имели множество инструкций для новичков, однако по причине отсутствия опыта я не понимал для чего нужны все эти правила, сложности, ограничения и тд, из-за чего я не смог доконца понять всю систему разработки.

        Сейчас у меня за плечами проект среднего размера на Github, где я понял основы source version control, bug tracking, планирования технических задач, схемы версирования пакетов, peer reviewing. Я понял эти понятия на простых примерах и теперь разобратся в процессе разработки того же Chromium для меня проще простого, чего, я считаю, нильзя сказать про начинающих разработчиков.
  • +1
    Про серьезную машину это вы правду сказали — когда собирал хромиум из исходников на моем mac book pro, поставил где-то в 6 часов вечера, в результате не дождался — уснул. Утром проснулся и удостоверился, что все собралось. Наверное больше доставит если собрать хромиум под генту :)
    • +4
      Ничего доставляющего. Сплошная рутина. Шестиядерный i7, HT, вся сборка (/var/tmp) в tmpfs в оперативе, этот ваш попсовый ccache и…

      genlop -t chromium | tail

      Thu Nov 29 21:35:09 2012 >>> www-client/chromium-23.0.1271.91
      merge time: 19 minutes and 24 seconds.

      Mon Dec 3 18:59:23 2012 >>> www-client/chromium-23.0.1271.95
      merge time: 17 minutes and 50 seconds.

      Sat Dec 15 23:21:33 2012 >>> www-client/chromium-23.0.1271.97
      merge time: 6 minutes and 24 seconds.
  • +3
    По поводу качества кода — приятно читатать комментарии-объяснения, например, взять ту же реализацию синглтона — ( %src%/base/memory ) — что-то новое, интересное да и почерпнул. Или, совсем не сложное, — хранение путей FilePath ( %src%/base/file_path.h ) — объяснение к заголовочному файлу — чего стоит. Или реализацию действительно надёжного сохранения файла. Иногда дух захватывает.

    Что заинтересовало меня «в стиле» так это — огромное количество глобальных переменных ( да, в большинстве случаев, это некие константы, что вполне логично и все они разбросаны по пространствам имён ), но всё же…
    + наверное, присутствие вперемешку определения полноценного класса… а потом — куча глобальных функций для работы с данным класом, которые вполне логично могли бы переместиться в сам клас в некоторых случаях. Или вообще, например, чисто сишный код ( я имею ввиду структуры + ф-и для работы с ними, но структуры с конструкторами и деструкторами )…

    Не знаю как вы, но посмотреть это стоит 100 % — очень интересно!
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Думаю, что нужно вставить ещё пункт после п.2: Проверить наличие бага
    • 0
      Да, было и такое — многие баги уже не воспроизводятся, хотя помечены в баг-трекере как активные. Я не уверен, что делать с такими багами — возможно, их можно как-то заэскалировать кому-то, чтобы их перетестировали и закрыли, но деталей я не знаю.
  • +1
    многоядерный процессор и не менее 8 Гб памяти. Кроме того, потребуется около 60 Гб свободного пространства на жёстком диске, в качестве которого рекомендуют использовать отдельный SSD.
    В общем, это удовольствие не для всех.
    • +19
      Эдакий «элитный» Open Source :)
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Расскажу свою историю. Порой в хроме меня раздражало отсутствие раскладко-независимого поиска по истории. Например, если написать в адресной строке «рфик», то хотелось бы на первом месте видеть ссылки на «habr», (при условии наличия ссылок в history). Гугление ничего похожего не нашло, поэтому решил прикрутить эту фичу самостоятельно. Скачал исходники, настроил среду разработки, запустил компиляцию… и пришел в ужас от медлительности этого процесса. Мой ноутбук грелся и гудел всю ночь. В конце концов, не выдержав такого насилия над собой, он просто вырубился от перегрева. Такие дела.
    • 0
      А как же игры ?? они же больше процессорного времени тратят…
      Сгрустнуло время компиляции.

      Хотя на втором Пентиуеме (единсственный мой комп тогда еще) Я собирал Dragon Fly BSD порядка 2 дней. Так и не собрал (Ctrl +break), в итоге запустил startx и радовался ))

      Господа приводите пожалуйста конфигурации компа, а то не понятно сколько времени Хром у вас собирается…
      • 0
        А как же игры ?? они же больше процессорного времени тратят…

        От игр слабые/дешёвые ноутбуки тоже вырубаются. И от перекодирования видео.
        Я так в UFO под DosBox-ом играл с пылесосом — раз в 15 минут продувал радиаторы у ноутбука, потому что DosBox загружал проц на 100% :)
        • 0
          Всем кто испытывает проблемы с самопроизвольным выключением при загруженной системе, в обязательном порядке необходимо почистить свой ноутбук. Скорее всего при вскрытии пациента вы увидите подобную картину:

          Радиатор превратился в валенок.жпг
          image

          • 0
            На некоторых (дешёвых?) ноутбуках мощности вентиляторов просто не хватает, чтобы остужать процессор при длительной высокой нагрузке. Вот я и помогал пылесосом :)
  • +11
    >билд с нуля обошелся, кажется, в 35 рублей

    Блин, умом вроде бы всё понимаю, но мерять билды в рублях — это как-то против природы. Эдак будешь бояться лишний раз код скомпилировать, чтобы на бабло не попасть.
  • +2
    У меня контрибтютинг в Chromium закончился на его сборке. Развернулся, пошел контрибьютить в Qt/KDE
  • +1
    FireFox заметно быстрее собирается. У меня было 1900 секунд в один поток. В прошлом году, что ли. Я тогда тестировал ssd/ram drive и их действие на время компиляции.
    • +1
      Справедливости ради следует сказать, что один только рецепт сборки Файерфокса под Windows выглядит довольно страшно.

      (Меня, например, отпугнул.)
  • +1
    Сборку можно сделать с включенными shared library (http://www.chromium.org/developers/how-tos/component-build), компиляция будет выполняться быстрее. На этапе линковки это поможет, но не сильно.
    Второй момент — есть official и dev сборка. Первая собирается с кучей оптимизаций, её не стоит использовать при разработке. Правда по дефолту включен режим dev, можно не заморачиваться.
    • 0
      Вообще если интересно — приходите ко мне в команду заниматься разработкой браузера на основе хромиума. У вас будет уйма возможностей собирать хромиум и разрабатывать под него новые интересные фичи.

      Мы — компания Itim. Основное направление работы компании — разработка поиска для Вьетнама.
  • 0
    А какой язык используется в Хромиуме для разработки?
    • 0
      В основном C++ и Python.
  • 0
    На сколько мне известно, для коммита в хром не нужно никого просить: достаточно поставить галочку возле метки «Commit:» у чейнджлиста. У ревьюеров нужно просить только запустить боты — это внешним разработчикам не доступно.
    • 0
      Возможно, это работает только если у вас есть права на коммит в репозиторий. По умолчанию такого права нет и процедура его получения довольно длительна:
      www.chromium.org/getting-involved/become-a-committer
  • +16
    Немного юмора
    image
    (на всякий случай: я в курсе что сборка в 6 часов была на машине 5-летней давности без SSD — я всё внимательно прочёл, это просто шутка, не придирайтесь (-; )
    • 0
      > на всякий случай: я в курсе что сборка в 6 часов была на машине 5-летней давности без SSD — я всё внимательно прочёл, это просто шутка, не придирайтесь (-;

      Написали бы тогда не 6, а 60 часов, было бы еще смешнее :)
      • +1
        Все предложения в левой колонке — точные цитаты из текста статьи. Так смешнее (-:
        • +1
          Не вижу ничего смешного. Вы, наверное, Gentoo не собирали)))
  • 0
    Помню я как-то раз (может пару лет назад) с дуру поставил такой Aur-пакет с Chromium, что стягивает исходники и компилит. Заняло вроде пару часов от силы на одноядерном Pentium-M (Dothan).
  • 0
    > Я пользовался Microsoft Visual C++ 2008 Express Edition (в данный момент они рекомендуют использовать версию 2010).

    VS 2008 более не поддерживаеется. Для сборки требуется VS 2010.
  • +2
    Кто воодушевился статьёй, исправьте, пожалуйста, баг code.google.com/p/chromium/issues/detail?id=68105
    (Невозможность выполнить синхронный XMLHttpRequest, при котором происходите редирект на другой домен или протокол). А?
    • 0
      Да уж, с исправлениями багов, касающихся расширений, у них в багтрекере всегда все как-то очень вяло.
  • +1
    Пишу сюда из этого самого Chromium'a.

    Собрал свежий порт chromium 24.0.1312.52 из коллекции портов FreeBSD: www.freshports.org/www/chromium/
    с помощью системного LLVM/Clang 3.1 (отметил опцию: CLANG=on: Build Chromium with Clang instead of GCC 4.6+ в меню сборки)

    Потребовалось заметно меньше 9 ГБ свободного пространства на жёстком диске. Процессор четырёхъядерный AMD Phenom II X4 810 и RAM около 8 ГБ.
    Время сборки пакета составило 25 минут (сборка началась в 16:23, закончилась в 16:58).
  • 0
    А какую IDE вы использовали и как её настраивали? Я, к сожалению, не могу воспользоваться Xcode или VisualStudio — я Linux-пользователь и в моём распоряжении несколько иной зоопарк.
    • 0
      Под Linux я не пользовался IDE, так что, боюсь, не смогу вам помочь. Можно попробовать Eclipse, но практического опыта использования этой среды у меня нет.
      • 0
        Eclipse индексирова-индексировал, да не выиндексировал: проработав более 10 часов (на машине, на которой собственно сборка заняла 4), завис на 98%. Пробовать еще раз — то еще удовольствие. QtCreator просто молча упал примерно на середине индекса, хотя и добрался до этой середины минут за 40, а не за 5 часов, как Eclipse.
        • 0
          У меня в Eclipse индексация завершается (часа за 2-4) и потом неплохо работает. Возможно Eclipse'у не хватает памяти. Ее можно увеличить опциями -Xms и -Xmx в стартовых скриптах. Вообще индексация такая долгая из-за того, что она до сих пор не распараллелена.
          • 0
            Пороги по памяти увеличены до 1024 и 3072 соответственно сразу. А больше куда? У меня 4 Gb. памяти.
            • 0
              Вобщем, пока выясняю всё то, что мне нужно выяснить связкой gdb-grep-vim. Но энтузиазма мне не на долго хватит.
            • +1
              У меня стоит 384 и 1200.
              • 0
                С ума сойти. Уменьшил пороги — и всё заработало. Даже не знаю, что предполагать — swap — не swap…
                Спасибо, помогли.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.