Ubuntu의 X.org를 개선하는 데 더 많은 사람들을 참여시키는 방법은 무엇입니까? [닫은]

우분투에서 X는 스택에서 가장 중요한 부분 중 하나입니다. 따라서 우리는 처리 할 수있는 인력의 약 100 배에 달하는 많은 질문과 버그 보고서를받습니다.

Canonical은 도움이 될 X 작업을 위해 추가 엔지니어를 고용하고 있지만 Canonical이 할 수있는 범위를 벗어난 많은 것들이 여전히 있습니다. 따라서 우분투에서 X를 개선하는 데 강한 커뮤니티가 특히 중요하다고 생각합니다. 이 모든 방대한 양의 버그 보고서를 응답, 심사 및 (희망적으로) 해결하는 것.

그러나 X에서 일할 사람들을 찾거나 시간을 투자하는 것이 가치가 있다고 사람들을 설득하기는 어렵습니다. X에 대한 작업을 생각하지 않는 사람들이 참여하도록 격려하는 방법에 대해 어떻게 제안 하시겠습니까?

모든 것을 좋아하는 것처럼 사람들이 쉽게 알아볼 수 있습니다. 따라서 버그 심사를 통해 처음 기억 한 내용은 커뮤니티에서 많은 도움을받지 못했습니다. 그런 다음 일부 위키 페이지에서 버그를 분류하는 일반적인 프로세스와 일부 버그 일을 설명하면 더 많은 커뮤니티 구성원이 참여하게됩니다. 또한 커뮤니티가 정기적으로 활동을 시작하고 시도하는 사람들에게 도움을 줄 수 있다면 관심을 가질 것입니다.

당신이 활동에 대한 도움이 필요하면 나에게 이메일을 보내거나 조직하는 데 도움이 될 수 있습니다.

그래서 제 대답은 사람들이 참여할 수 있도록 좋은 버그 심사 정보를 얻는 데 필요한 질문과 명령으로 위키 페이지를 만드는 것입니다.

개발의 큰 문제입니다. Xorg와 Kernel은 대부분의 버그 수정 및 구현 기능을 위해 낮은 수준의 프로그래밍 기술이 필요합니다. 따라서 특정 프로그래머 그룹을 대상으로하고 관심을 가져야합니다. 나는 여기에 약간의 질문을하고 누가 # ubuntu-x에 어울리는 지보고 그들이 도울 수 있는지 물어 보는 것을 제외하고는 어떤 제안도 없습니다.

X가 많은 작업을 수행하지 못하는 이유는 GPU, 메모리 등이 작동하는 방식과 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를 개선하기가 어렵습니다.

"사용 가능한 카드가 모두 없습니다"에 대한 많은 이야기도 유효합니다.

좋은 프로그래머가 아니라면 그래픽 프로그래밍은 상당히 어렵다. 디버깅은 특히 어려운 일이 될 수 있습니다.