Міжнародна конференція розробників
і користувачів вільного програмного забезпечення

OpenBSD изнутри

Vadim Zhukov, Svetlana Savina, Moscow, Russia

LVEE Winter 2016

The article would bring some light to the dark side of OpenBSD development process. You will know better: 1) about OpenBSD developers hierarchy; 2) what formal and informal rules are used in development process; 3) how OpenBSD development is sponsored nowadays; 4) what OpenBSD team building events AKA hackathons do look like; 5) how Ted Unangst became a verb; 6) and, finally, why do OpenBSD developers hate Australia.

Проект OpenBSD отличается от многих других проектов, занимающихся разработкой операционных систем. Здесь нет демократии, ни “по западному”, ни по какому-либо ещё типу. Не существует ни одной организации, которая могла бы с полным правом заявить, что контролирует проект, полностью или частично. Даже OpenBSD Foundation, будучи основанным несколькими членами сообщества, формально дистанцирован от проекта. Во многом такое положение дел является результатом основателя и главного дирижёра проекта – Тео де Раадта, человека крайне принципиального.

Разработку в OpenBSD можно условно разделить на две части: базовая система (включая xenocara, адаптированная для OpenBSD сборка X Window System) и порты. Разделение это во многом связано с разницей в объёмах и темпах обновления “обслуживаемого” исходного текста: в то время как базовая система насчитывает порядка 25 миллионов строк кода, в портах счёт идёт на сотни миллионов. При этом скорость выхода релизов у многих портов заметно больше, чем у OpenBSD; особенно это заметно на портах, находящихся на острие web-технологий: Web-движки и построенные на их базе браузеры. Как результат, имеются две основные чат-комнаты: “для всех” и, отдельная, для работающих над портами. Как правило, вторые редко пишут в первой, и наоборот.

В чатах общаются практически исключительно разработчики, посторонних там нет. Это не от стремления скрыть что-то важное и страшное от мира, а, скорее, наоборот: в чатах общение часто весьма неформальное, часто идёт обмен довольно личной информацией, выносить которую в списки рассылки не хочется.

О списках рассылки. Их на данный момент можно пересчитать по пальцам одной руки:

tech@ – для технических обсуждений: как правило, именно здесь предлагаются патчи и происходит их ревью. misc@ – для обсуждения всего подряд, включая жалобы на баги. announce@ – важные анонсы происходят через этот адрес. а также список рассылка под кодовым названием “h”, предназначенный для внутреннего пользования; причины закрытости те же, что и выше. Впрочем, иногда на нём также происходит ревью патчей, когда оным требуется особое внимание: письма с этого списка рассылки считаются наиболее приоритетными.

Существует также несколько узкоспециализированных, зачастую временных, ящиков для общения отдельных небольших команд “по интересам”. Часть из них – публичные, часть – нет.

Сам процесс разработки подразумевает ревью практически всего вносимого кода. Если попытаться формализовать список исключений, он окажется составлен примерно таким образом:

- Обновление портов, производимое его мейнтейнером, или по его просьбе. - Внесение изменений в userland-код их (со-)автором. - Внесение изменений в ещё не стабилизированный, недавно внесённый код, производимое его (со-)автором до подключения данного кода в сборку.

Довольно часто как в базовой системе, так и в портах производится массовый неглубокий рефакторинг. В таком случае изменения обязательно тестируются кем-либо ещё, после чего и даётся “okay”. Согласия по каждому порту или каждой составляющей базовой системы при этом никто не спрашивает. Для внесения изменений в ядро и критичные системы обычно требуется минимум два “okay”; исключение составляют малофункциональные коммиты вроде добавления идентификаторов оборудования в таблицы PCI- и USB-устройств.

Стоит отметить, что web-сайт OpenBSD практически полностью находится в CVS-репозитории, а изменения обычно не требуют “okay”.

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

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

Попасть в число разработчиков OpenBSD можно только по приглашению. Сначала приглашают пообщаться, и, если не поступает заметных возражений, приглашающий радует приглашённого предложением пообщаться с Тео. После этого обычно следует также приглашение посетить один из ближайших хакатонов.

Хакатоны – важная составляющая процесса разработки. В год проходит несколько хакатонов, в разных уголках света: это не только возможность встретиться и вживую решить многие накопившиеся вопросы, но ещё и познакомиться с другой страной и другими людьми. В частности, ежегодно проходит большой хакатон, где стараются собраться все разработчики (несколько десятков). В последние годы место большого хакатона стараются по разные стороны Атлантики: чётные в Европе, нечётные – в Америке.

Традиционно хакатон проходит около недели. Организаторы берут на себя помещение и напитки. Размещение и отдельные работы, если требуется, в последние годы оплачивает OpenBSD Foundation. Билеты же участники покупают сами. Так как даты хакатонов планируются сильно заранее (порой чуть ли не за год), то достать сравнительно недорогие билеты при желании труда не составляет.

Помимо хакатонов, OpenBSD Foundation оплачивает счета, связанные с поддержкой инфраструктуры проекта, помогает приобретать оборудование отдельным разработчикам, а также в течение последних нескольких лет курирует проекты в рамках программы Google Summer of Code.

Abstract licensed under Creative Commons Attribution-ShareAlike 3.0 license

Назад