Как привлечь больше людей к улучшению X.org для Ubuntu? [закрыто]

В Ubuntu X является одним из наиболее важных элементов в стеке. Таким образом, мы получаем ТОННО вопросов и сообщений об ошибках, вероятно, примерно в 100 раз больше, чем у нас есть рабочая сила.

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

Однако трудно найти людей, которые будут работать над X или убедить людей, что им стоит потратить на это свое время. Как бы вы предложили поощрять участие людей, которые иначе не думают работать над X?

Ну, как и все, многое из этого позволяет людям легко и легко узнать об этом. Так что из того, что я помню, с помощью сортировки ошибок изначально не было большой помощи от сообщества. Затем, когда на некоторых вики-страницах, объясняющих обычные процессы сортировки ошибок и некоторые дни ошибок, вовлекалось гораздо больше членов сообщества. Также, если вы можете начать регулярную деятельность для сообщества и предложить помощь тем, кто ее попробует, вы проявите некоторый интерес.

Если вам нужна помощь с этим мероприятием, вы можете написать мне по электронной почте и оказать помощь в его организации.

Поэтому я отвечаю на создание вики-страницы с вопросами и командами для получения хорошей информации об ошибках, чтобы вовлечь людей в это.

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

Причина, по которой X не получает много работы, заключается в том, что ему требуется огромное количество знаний о том, как работают графические процессоры, память и т. Д., А также знакомство с базой кода X.org и в некоторой степени программированием ядра. Это не тривиальная вещь, чтобы войти в и с точки зрения сообщества те, кто интересуется работой над драйверами X или X, вероятно, уже делают это. В настоящее время у разработчика нет мотивации для работы над Xorg, кроме личного интереса.

Сообщество, которым разработчики X.org не обязательно обладают, - это доступ к широкому кругу оборудования. Наличие людей, которые готовы потратить время на написание «хороших» отчетов об ошибках и тестирование драйверов и частей стека Xorg перед выпуском, вероятно, поможет инженерам больше всего на свете.

В настоящее время существует репозиторий Xorg Edgers, который я использую для тестирования драйверов в моей стабильной системе. Довольно просто откатить один пакет после того, как я закончу тестирование. Однако единственный способ проверить это - либо собрать X самостоятельно, либо установить хранилище edgers, которое собирается из апстрима. Это делает оптовую замену X, насколько я могу судить. Это означает, что это подход «все или ничего» к тестированию X.

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

Говоря как разработчик, который случайно интересуется X, вот мои проблемы:

1. У меня есть доступ только к нескольким видеокартам, и я подозреваю, что большинство людей имеют доступ только к одной. Таким образом, я не могу многое сделать для подавляющего большинства ошибок, которые всегда будут на «какой-то другой карте».

2. В отличие от большинства пакетов, я не могу легко создать тестовую среду для новой версии драйвера; виртуальные машины имеют свои собственные драйверы X.

3. Я не могу легко обновить до последней версии драйвера, проверить его, а затем вернуться. Это препятствует экспериментированию (потому что, если что-то пойдет не так, я с таким же успехом могу быть обманут); это также мешает регрессионному тестированию.

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

5. В настоящее время драйверы X делят свой код между ядром, Mesa, udev (для настроек и настроек по умолчанию) и пользовательскими драйверами. А это значит, что патчи тоже делятся ...

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

Кроме того, систему, подобную DKMS, следует искать для драйверов X; если бы я мог легко пропатчить / скомпилировать / протестировать / удалить, скажем, драйвер ввода для моего сенсорного экрана без необходимости перестраивать всю монолитную штуковину (с угрозой сделать X совершенно непригодным для использования), вы бы получили более случайный вклад и мотивировали бы меня посмотрите на исправление ошибок и тестирование исправлений, относящихся к этой части оборудования.

В дополнение к тому, что сказал jbowtie, я бы добавил, что в качестве триггера ошибок я нахожу, что с ошибками X очень сложно иметь дело просто потому, что X - очень сложный зверь. Это отражается на сложности страницы вики по устранению неполадок . Что определенно помогло бы, это своего рода программа наставничества для участников BugSquad, чтобы узнать, как лучше справляться с ошибками X. Может быть, обнять день вокруг? Или практическая тренировка в # ubuntu-классе?

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

Многие разговоры о том, что «у меня нет всех доступных карт», также верны.

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