Ubuntu logo

Packaging Guide

1. Вступ у розробку Ubuntu

Ubuntu складається з тисяч різних компонентів, написаних великою кількістю мов проґрамування. Кожен компонент — бібліотека, засіб або графічний застосунок — доступний у вигляді пакунку джерельного коду. Пакунки джерельних кодів у більшості випадків складаються з двох частин: сам джерельний код і метадані. Метадані включають у себе залежності пакунку, інформацію про авторське право і ліцензію, а також інструкції зі збирання пакунку. Після того, як пакунок джерельних кодів скомпільований, у процесі збирання ми отримаємо двійкові пакунки, що є .deb файлами, які користувачі можуть встановити.

Кожного разу, коли виходить нова версія додатку, або коли хтось вносить зміни у джерельний код пакунку, що входить у склад Ubuntu, пакунок з джерельним кодом повинен бути завантажений на збірочні комп’ютери Launchpad для компілювання. Готові бінарні пакунки потім потрапляють у сховище ПЗ та його дзеркала у різних країнах. URL в /etc/apt/sources.list є посиланнями на сховище або його дзеркал. Кожного дня збираються образи для різних версій Ubuntu. Вони можуть бути використані у різних умовах. Є образи, які можна записати на USB-носії або на DVD-диски, образи, які можна використовувати для мережевого завантаження й є образи, призначені для встановлення на телефон або планшет. Ubuntu, серверна версія Ubuntu, Kubuntu й інші гілки мають специфічний перелік необхідних пакунків, які потрапляють в образ. Це образи, які потім використовуються для перевірки встановлення й забезпечують зворотній зв’язок для подальшого планування випуску.

Розробка Ubuntu дуже залежить від поточної фази циклу випуску. Ми випускаємо нову версію Ubuntu щопів-року, що можливо лише завдяки тому, що ми встановлюємо точні дати «заморожування». При досягненні кожної дати заморожування очікується, що розробники будуть вносити рідші та менш значущі зміни. Заморожування нових функцій (feature freeze) — це перша велика дата заморожування, що приходить після проходження першої половини циклу розробки. На цьому етапі нові функції повинні бути переважно зреалізовані. У залишкову частину циклу має бути зосередженя на виправленні вад. Після цього «заморожується» користувацький інтерфейс, потім документація, ядро й тощо, після чого випускається бета-версія (beta release), яка інтенсивно тестується. Після того, як випущена бета-версія, виправляються лише критичні помилки, й випускається release candidate, який, якщо він не містить серйозних помилок, стає у подальшому кінцевим випуском.

./_images/cycle-items.png

Тисячі пакунків джерельного коду, мільярди рядків коду, сотні розробників потребують більше спілкування й планування для підтримування високих стандартів якості. На початку й у середині кожного циклу випуску організовується Ubuntu Developer Summit, де розробники та участники збираються разом, щоб планувати нові функції у наступних випусках. Кожна функція обговорюється зацікавленими сторонами, і складається специфікація, що містить детальну інформацію про початкові припущення, реалізації, внесення необхідних змін у інші пакунки, про тестування тощо. Усе це робиться прозоро й відкрито, тож Ви можете взяти участь віддалено, подивитися видивотрансляцію, поспілкуватися з участниками та підписатися на специфікації, щоб завжди знати про те що відбувається.

Втім на нараді можуть бути обмірковані не усі зміни, оскільки Ubuntu залежить від змін, що вносяться у інші проєкти. Тому участники розробки Ubuntu залишаються постійно на зв’язку. Більшість команд або проєктів використовують окремі переліки розсилки, щоб уникнути більшого потоку не пов’язаних з їх спеціялізацією листів. Для більш безпосереднього координування розробники і добровільні участники використовують Internet Relay Chat (IRC). Усі оговорення є відкритими та публічними.

Ще одним важливим інструментом зв’язку є звіти про вади. Якщо у пакунку або частині інфраструктури виявлена помилка, звіт про неї відправляється на Launchpad. У цьому звіті зібрана уся інформація, й при необхідності відомості про важливість, статус помилки, та особа призначена для її усунення оновлюються. Це робить звіт про ваду ефективним засобом відстежування помилок у пакунках або проєктах й оптимізації робочого навантаження.

Велика частина доступних в Ubuntu проґрам створена не самими розробниками Ubuntu. Багато з проґрам написані розробниками з інших проєктів з відкритим джерельним кодом, а потім інтегровані в Ubuntu. Такі проєкти прийнято називати «апстрімом» (від англ. upstream — угору за течією), оскільки їх джерельний код вливається в Ubuntu, де ми «просто» інтегруємо його у систему. Зв’язок з апстрімом дуже важливий для Ubuntu. Не лише Ubuntu отримує проґрамний код з апстріму, але й апстрім отримує від користувачів Ubuntu(й інших дистрибутивів) звіти про вади та латки.

Найважливішим апстрімом для Ubuntu є Debian. Debian — це дистрибутив, на якому заснована Ubuntu, й саме там створені багато інженерних рішень, що стосуються інфраструктури пакунків. За традицією, в Debian для кожного окремого пакунку завжди є супроводжуючий (мейнтейнер) або окрема група супроводу. В Ubuntu теж є команди, зацікавлені у роботі над підмножиною пакунків й, зрозуміло, кожен розробник має власну область компетенції, але участь (і права завантаження змін) зазвичай доступні будь-кому, хто продемонструє здатність та бажання працювати.

Внести зміну в Ubuntu новому участнику не так складно, як здається, й це може бути вельми корисним досвідом. Це дозволяє не лише навчитися чомусь новому й захоплюючому, але й поділитися своїм вирішенням проблеми з мільйонами інших користувачів.

Розробка відкритого проґрамного забезпечення відбувається у розподіленому світі, у якому у розробників можуть бути різні цілі й різні області інтересів. Наприклад, може бути так, що окремий апстрім зацікавлений у роботі над великим нововведенням, в той час як Ubuntu, внаслідок тісного розкладу релізів, більше зацікавлена у випуску стабільної версії, у якій лише виправлені деякі вади. Тому ми використовуємо «Ubuntu Distributed Development», де робота над кодом ведеться у різних гілках, які потім зливаються один з одним після перевірки коду й достатньої кількості обговорень.

./_images/cycle-branching.png

У приведеному вище прикладі має сенс включити в Ubuntu існуючу версію проєкту, зробити виправлення вад, додати їх у апстрім для наступного випуску проєкту й включити його (якщо він до цього придатний) у наступний випуск Ubuntu. Це буде найкращим компромісом і ситуацією у якій виграють обидві сторони.

Щоб виправити помилку в Ubuntu, потрібно спочатку отримати джерельний код пакунку, попрацювати над його виправленням, забезпечити свою роботу документацією, щоб іншим розробникам та користувачам було легко зрозуміти, що саме Ви зробили, а потім зібрати пакунок й протестувати його. Після того, як Ви протестували змінений пакунок, можна запропонувати включити його у поточний розроблюваний реліз Ubuntu. Розробник з правом завантаження перевірить Ваш пакунок й потім інтегрує його в Ubuntu.

./_images/cycle-process.png

При спробі знайти вирішення корисно перевірити, чи відомо про проблему, над якою Ви працюєте в апстрімі, й чи не знайдено там вже її можливе вирішення. Якщо ні, зробіть усе можливе, щоб вирішити проблему спільними зусиллями.

Додаткові кроки, які Ви можете зробити, — це адаптування Вашої зміни для попередніх підтримуваних випусків Ubuntu й відправлення її в апстрім.

Найважливішими вимогами для успішної розробки в Ubuntu є: вміти «примушувати речі знову працювати», не боятися читати документацію й задавати питання, бути командним гравцем та мати певну схильність до роботи детектива.

Good places to ask your questions are ubuntu-motu@lists.ubuntu.com and #ubuntu-motu on freenode.. You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software.