Рекомендації щодо виправлення помилок¶
Цей документ описує стандартний процес роботи з проблемами в проєктах UBports. (Не плутайте з настановою з написання гарного звіту про помилку.)
Де відстежуються помилки?¶
Основний реєстратор проблем для Ubuntu Touch — це ubports/development/ubuntu-touch GitLab project. Цей проєкт містить записи щодо проблем Ubuntu Touch усіх рівнів та є точкою входу, де користувачі можуть звітувати про знайдені проблеми.
Тим часом інші проєкти у групі також можуть мати власні реєстратори проблем:
Проблеми з певними пристроями реєструються у відповідному проєкті пристрою у підгрупі ubports/porting.
Основні програми записують свої проблеми у ubports/development/apps.
Системні проблеми можна також безпосередньо реєструвати до відповідного компонента (якщо зрозуміло, який компонент призводить до помилки) у ubports/development/core.
GitLab дозволяє бачити проблеми у групі, посилання на проблеми перехресних проєктів та проблеми обміну між проєктами, змушуючи весь проєкт реєструвати проблеми менш важливими. Якщо проблеми, які стосуються портів чи вебсайтів опинилися у проєкті ubports/development/ubuntu-touch, їх можна перемістити до відповідного проєкту.
Мітки¶
Усі проблеми — навіть закриті — повинні бути позначеними мітками для можливості використання фільтрів на GitLab. Напр., проблеми з міткою „Kind: enhancement“ всередині ubports/development group. Для поглиблення знань щодо пошуку та фільтрів зверніться до Довідки GitLab.
Наступні мітки використовуються всередині проєктів UBports. Оскільки запити на злиття (MR, merge requests) у GitLab мають однакові набори ярликів, деякі з ярликів можна також використовувати для запитів на злиття.
Доробити
Розглянемо також написання документа щодо процесів із запитами на злиття.
- Kind: описує природу проблеми
Kind: bug: ця проблема описує дещо, що працює неправильно.
Kind: enhancement: ця проблема — це запит на додаткову функціональність або описує дещо, що можна покращити.
Kind: maintenance: ця проблема описує технічну ваду; нам потрібно дещо очистити.
Kind: FTBFS: ця проблема описує проблеми збірки з джерельного коду («Fails To Build From Source») (акронім з Debian).
Kind: process: ця проблема — це проблема реєстрації деяких процесів. Наприклад, процесу випуску релізу Ubuntu Touch.
Kind: question: Ця проблема є запитом на підтримку або загальним запитанням. Замість цього можна перенаправити до форумів.
- Needs: описує деякі дії які можна чи потрібно зробити
Needs: help from community: мейнтейнери (підтримка) зараз не мають ресурсів на розв’язання цієї проблеми та були б раді мати підтримку від спільноти.
Needs: confirmation/more info: Баг потрібно підтвердити та / або отримати більше інформації від постраждалих користувачів.
Needs: feedback from author: використовується для позначення запитів на злиття, які вимагають відгуків від авторів після перегляду. Відрізняється від Needs: confirmation/more info, який призначений для опису проблем.
Needs: discussion: не зрозуміло як розв’язати цю проблему та необхідне обговорення.
Needs: rebase: цей запит на злиття повинен бути перероблений (rebased), але у підтримки (мейнтейнерів) немає дозволу на розміщення у джерельній гілці (push to the source branch).
- Severity: наскільки вагома проблема.
Severity: critical: ця проблема досить вагома та повинна блокувати випуск релізу (визначено його контрольною точкою).
Area: ця проблема стосується певної області Ubuntu Touch (напр., HAL, middleware, UI). Можуть бути створені відповідні мітки цього префіксу.
Topic: ця проблема стосується відповідних розділів (напр., VoLTE, фонова міграція контактів). Також можуть бути створені відповідні мітки цього префіксу.
- Resolution: використовується, коли проблему закрито з причини, відмінної від вказаної.
Resolution: unable to confirm: ми не змогли відтворити проблему та бракує інформації.
Resolution: not our bug: ця проблема не є проблемою в Ubuntu Touch, але скоріше проблемою сторонньої, встановленої користувачем, програми.
Resolution: won’t fix: Баг, виправлення якого не має сенсу, оскільки він може виправитися самостійно, вимагає забагато праці, невиправний або ж основний компонент буде незабаром змінений.
Resolution: work as intended: поведінка, описана у проблемі — передбачувана поведінка програмного забезпечення.
Backport to: <branch name>: використовується автоматизацією для автоматичних звітів щодо MR до гілок стабільного релізу.
- Різні мітки
Good first issue: ця проблема містить настанови або корисні поради для її виправлення. Це найкраще місце для новачків для ознайомлення з проєктом через виправлення справжніх проблем.
Hotfix: цей запит на злиття чи проблема розглядаються як можлива частина латки для релізу Ubuntu Touch
Примітка
Якщо проблеми в трекері репозиторію позначені локально власними мітками, вони повинні бути задокументовані у README.md.
Статус¶
Поле статусу потрібне для індикації перебігу опрацювання проблеми. Ми визначили наступні статуси:
Нова: Цей статус для щойно створених заявок з описом проблем. Він говорить про те, що проблема ще не оброблена; Розробники та інші, хто сортує звернення можуть їх залюбки розподіляти, призначати тип та інші мітки, вирішувати чи потрібні віхи з контрольними точками тощо. Крім того, якщо проблема є робочим елементом, проблемою відстеження чи чимось таким, поданим розробниками, цей статус можна пропустити.
Готова до опрацювання: Говорить про те, що проблема відсортована і з нею можна працювати.
Примітка
Цей статус замінює стандартний «To do».
Заблокована: Говорить про те, що перед продовженням потрібно розв’язати деякі питання зовні цієї проблеми.
В роботі: Говорить про те, що розробник активно працює над проблемою. Проблема повинна бути передана розробнику.
Має MR: існує запит на злиття (MR), який розв’язує цю проблему.
Завершена: Проблему розв’язано у гілці
main.Дубль: Проблема є дублікатом. GitLab призначає цей статус автоматично, коли проблема позначена як дублікат.
Відкинута: Проблема закрита з іншої причини, окрім вирішення. Повинна мати для пояснення позначку «Розв’язання: *» (див. вище).
Контрольні точки¶
Контрольні точки використовуються для розуміння який реліз має проблему. Одночасно відкрито до трьох контрольних точок:
Контрольна точка для найближчого стабільного релізу, напр., «Ubuntu Touch 24.04-1.1».
Контрольна точка для старшої версії релізу у розробці, напр., «Ubuntu Touch 24.04-2.0».
Як тільки розробка релізу виходить на стабільну фазу, можна створити контрольну точку для наступної старшої версії випуску (напр., «Ubuntu Touch 24.04-3.0»).
Розробникам рекомендовано уникати призначення великої кількості проблем до контрольних точок, оскільки перевантаження контрольних точок призводить до втрачання сенсу використання їх у відстеженні прогресу щодо випуску.
Призначені¶
Для прозорості розуміння, хто працює над проблемою, повинен бути призначений розробник. Це також дозволяє використовувати глобальний фільтр GitLab за списком завдань (TODO list).
Розробникам варто тримати свої списки короткими, а статуси завдань актуальними.
Панель проблем GitLab¶
Ми використовуємо панелі проблем GitLab для візуалізації перебігу розв’язування проблем в кожній контрольній точці. Панелі — т.з. дошки канбан (kanban), де кожний стовпчик відповідає визначеному статусу (нова, готова до опрацювання, заблокована, має MR (запит на злиття)), завершена, відкинута).
Епос GitLab¶
Ми використовуємо епоси Gitlab для позначення тем, які можуть охоплювати окремі або сукупні контрольні точки/випуски. Це допомагає організувати деякі довгострокові цілі, які занадто великі, щоб охопити все одразу.
Як використовуються мітки, контрольні точки та інше?¶
Подумайте про мітки, контрольні точки та інші поля як про інструменти, з якими можна ефективно комунікувати із заявниками, іншими розробниками, іншими зацікавленими. Це можна використовувати у різний спосіб:
Оскільки ці поля з’являються у списку проблем, це допомагає швидко зрозуміти у чому саме питання, допомагаючи розробникам швидко зрозуміти проблему. Наприклад, розробник може побачити проблему у списку, та якщо там буде мітка «потребує обговорення», він зможе вставити свої п’ять копійок.
Поле можна використовувати для відбору цікавих проблем. Наприклад, якщо учасник спільноти хоче долучитися до підтвердження проблем, він може відібрати їх з фільтром за міткою «вимагає підтвердження» (needs confirmation).
Так само через фільтр можна відкидати нецікаві проблеми. Наприклад, якщо розробник хоче знайти цікаву для себе проблему, над якою міг би попрацювати, можна скористатися фільтром з міткою «Вид: процес» (Kind: process) (використовується, напр., для проблем реєстрації процесів).
Оскільки не завжди є хтось конкретний, хто може сортувати проблеми та встановлювати на них мітки, розробникам рекомендується встановлювати всі ці поля під час роботи над проблемою. Це допоможе співпрацювати над тим, що вже було зроблено та допоможе узагальнити проблему для швидшого розуміння.