Як залучити більше людей до вдосконалення X.org для Ubuntu? [зачинено]

У Ubuntu X є однією з найважливіших фігур у стеці. Таким чином, ми отримуємо ТОН запитань та повідомлень про помилки, можливо, приблизно в 100 разів більше, ніж у нас є робоча сила.

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

Однак важко знайти людей, які працюють над X, або переконати людей, що їм варто вкладати свій час у це. Як би ви запропонували заохочувати людей до залучення, які інакше не могли б думати про роботу над X?

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

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

Тож моя відповідь - це створення вікі-сторінки із запитаннями та командами для отримання гарної інформації про помилку про помилки, щоб залучити людей до цього.

Для розвитку це велика проблема. Речі Xorg і Kernel вимагають навичок програмування низького рівня для більшості функцій виправлення та впровадження помилок. Тож вам потрібно орієнтуватися на певну групу програмістів та зацікавити їх. Тут я не маю жодних пропозицій, за винятком того, щоб трохи попросити і подивитися, хто висить у # ubuntu-x, і запитати, чи можуть вони допомогти.

Причина X не отримує багато роботи в тому, що вона потребує величезної кількості знань про те, як працюють GPU, пам'ять тощо., А також ознайомлення з кодовою базою X.org і певною мірою програмуванням ядра. Це не тривіальна річ, щоб потрапити в та з точки зору громади ті, хто зацікавлений у роботі над X або X драйверами, ймовірно, вже роблять це. Наразі у розробника немає мотивації для розробника працювати над Xorg, окрім особистого інтересу.

Діяльність спільноти, яку розробники X.org не обов'язково мають, - це доступ до найрізноманітніших апаратних засобів. Маючи людей, які готові витратити час на написання «хороших» звітів про помилки та тестових драйверів та частин стека Xorg перед випуском, ймовірно, допоможуть інженерам більше ніж усе.

В даний час існує репортер Xorg Edgers, який я використовую для тестування драйверів на моїй стабільній системі. Досить легко повернути один пакет після того, як я закінчив тестування. Однак єдиний інший спосіб, який ми можемо перевірити, - це створити X самостійно або встановити сховище Edgers, яке будується з висхідної лінії. Наскільки я можу сказати, це оптова заміна X. Це означає, що підхід до тестування X є повністю або нічого.

Маючи спосіб мати 2 версії X (і досить легко вибрати), яку ви хочете використовувати, дозволить тестерам не тільки перевірити X, але згодом повернутися до робочого Xorg, щоб вони могли подати звіт про помилку.

Виступаючи як розробник, який випадково цікавиться X, ось мої проблеми:

1. Я маю доступ лише до кількох відеокарт, і я підозрюю, що більшість людей мають доступ лише до однієї. Таким чином, я не можу багато зробити для переважної більшості помилок, яка завжди буде на "якійсь іншій карті".

2. На відміну від більшості пакетів, я не можу тривіально створити тестове середовище для нової версії драйвера; віртуальні машини мають власні X драйвери.

3. Я не можу легко оновити до останнього драйвера, перевірити його та відновити. Це відлякує експериментування (адже якщо щось піде не так, я також можу бути занесене цеглою); це також перешкоджає регресійному тестуванню.

4. Минулого разу я подивився, успішно застосувавши патч, скласти та запустити X було важко, переступив весь менеджер пакунків, вимагав також виправлення модулів ядра, і це був майже незворотний крок.

5. На сьогоднішній день драйвери X розділяють свій код між ядром, Mesa, udev (для налаштувань і стандартних налаштувань) та драйверами користувачів. Це означає, що патчі також розщеплюються ...

Тому я гадаю, що відповідь полягає в тому, щоб застосувати та скасувати зміни щось, що обробляється менеджером пакунків і легко відновитись, коли воно порушує вашу систему.

Також для X-драйверів слід шукати таку систему, як DKMS; якби я міг легко виправити / компілювати / перевірити / видалити, скажімо, драйвер вводу для мого сенсорного екрану без необхідності перебудувати всю монолітну контрацепцію (з її загрозою зробити X абсолютно непридатним), ви отримаєте більш випадковий внесок і мотивуєте мене подивіться на триагуючі помилки та тестування виправлень, пов’язаних із цим бітом обладнання.

Щоб доповнити те, що сказав jbowtie, я додам, що, як триггер помилок, мені здається, що X-помилок дуже складно боротися, просто тому, що X - дуже складний звір. Це відображається на складності сторінки вікі з усунення несправностей . Що, безумовно, допоможе - це така собі програма наставництва для членів BugSquad, щоб навчитися краще боротися з X-помилками. Можливо, обіймати клопа день навколо нього? Або практичне заняття в # ubuntu-класі?

Важко вдосконалити X.org, коли багато користувачів використовують власні драйвери, які замінюють частини графічного стеку, а потім звертаються до команди X.org, коли оновлення ядра / оновлення X.org порушує встановлення драйвера.

Багато розмов про те, що "у мене не всі карти доступні" також справедливі.

Графічне програмування досить складно, якщо ти не хороший програміст. Налагодження може бути справжнім болем, особливо якщо ви не бачите, що відбувається.