Làm cách nào để có thêm nhiều người tham gia vào việc cải thiện X.org cho Ubuntu? [đóng cửa]

Trong Ubuntu, X là một trong những phần quan trọng hơn trong ngăn xếp. Như vậy, chúng tôi nhận được một TẤN câu hỏi và báo cáo lỗi về nó, có thể gấp 100 lần số lượng chúng tôi có nhân lực để xử lý.

Canonical đang thuê các kỹ sư bổ sung để làm việc trên X, điều này sẽ giúp ích, nhưng vẫn còn nhiều điều nằm ngoài phạm vi của những gì Canonical có thể làm, vì vậy tôi cảm thấy rất quan trọng khi có một cộng đồng mạnh mẽ tham gia vào việc cải thiện X trong Ubuntu, đặc biệt xung quanh việc nhận được tất cả số lượng lớn các báo cáo lỗi này đã được trả lời, xử lý và (hy vọng) đã được giải quyết.

Tuy nhiên, thật khó để tìm người làm việc trên X hoặc thuyết phục mọi người rằng việc họ đầu tư thời gian vào đó là đáng giá. Làm thế nào bạn có thể đề nghị đi về việc khuyến khích mọi người tham gia, những người có thể không nghĩ đến việc làm việc trên X?

Cũng giống như mọi thứ rất nhiều, nó làm cho mọi người dễ dàng và dễ tiếp cận để tìm hiểu về nó. Vì vậy, từ những gì tôi nhớ với cách xử lý lỗi ban đầu, không có nhiều sự giúp đỡ đến từ cộng đồng. Sau đó, khi một số trang wiki giải thích các quy trình thường xuyên trong việc xử lý lỗi và một số ngày lỗi có nhiều thành viên cộng đồng tham gia hơn. Ngoài ra nếu bạn có thể bắt đầu một hoạt động thường xuyên để cộng đồng thực hiện và cung cấp trợ giúp cho những người dùng thử, bạn sẽ nhận được một số sự quan tâm.

Nếu bạn cần giúp đỡ với hoạt động bạn có thể gửi email cho tôi và giúp đỡ với việc tổ chức nó.

Vì vậy, câu trả lời của tôi là tạo một trang wiki với các câu hỏi và lệnh để có được thông tin xử lý lỗi tốt để thu hút mọi người tham gia vào đó.

Để phát triển nó là một vấn đề lớn. Công cụ Xorg và Kernel yêu cầu kỹ năng lập trình cấp thấp cho hầu hết các tính năng sửa lỗi và triển khai. Vì vậy, bạn phải nhắm mục tiêu một nhóm lập trình viên cụ thể và khiến họ quan tâm. Tôi không có bất kỳ đề xuất nào ở đây ngoại trừ hỏi một chút và xem ai đi chơi trong # ubfox-x và hỏi họ xem họ có thể giúp gì không.

Lý do X không nhận được nhiều công việc là vì nó đòi hỏi một lượng kiến ​​thức khổng lồ về cách thức GPU, bộ nhớ, v.v. hoạt động cũng như làm quen với cơ sở mã X.org và ở một mức độ nào đó là lập trình kernel. Đây không phải là một việc nhỏ để tham gia và từ góc độ cộng đồng, những người quan tâm đến việc làm việc trên trình điều khiển X hoặc X có lẽ đã làm như vậy. Hiện tại không có động lực cho một nhà phát triển để nhà phát triển làm việc trên Xorg ngoài lợi ích cá nhân.

Điều mà cộng đồng có mà các nhà phát triển X.org không nhất thiết phải có, là quyền truy cập vào nhiều loại phần cứng. Có những người sẵn sàng dành thời gian để viết các báo cáo lỗi 'tốt' và trình điều khiển thử nghiệm và các bộ phận của ngăn xếp Xorg trước khi phát hành có thể sẽ giúp các kỹ sư nhiều hơn bất cứ điều gì.

Hiện tại có một repo Xorg edgers mà tôi sử dụng để kiểm tra trình điều khiển trên hệ thống ổn định của mình. Thật dễ dàng để quay lại một gói duy nhất sau khi tôi đã thử nghiệm xong. Tuy nhiên, cách khác duy nhất chúng ta có thể kiểm tra là tự xây dựng X hoặc cài đặt kho edgers xây dựng từ thượng nguồn. Điều này không thay thế X bán buôn như tôi có thể nói. Điều này có nghĩa là đó là một cách tiếp cận tất cả hoặc không có gì để thử nghiệm X.

Có một cách để có 2 phiên bản X (và khá dễ dàng lựa chọn) mà phiên bản bạn muốn sử dụng sẽ cho phép người kiểm tra không chỉ kiểm tra X, mà sau đó quay lại Xorg đang hoạt động để họ có thể gửi báo cáo lỗi.

Nói như một nhà phát triển tình cờ quan tâm đến X, đây là vấn đề của tôi:

1. Tôi chỉ có quyền truy cập vào một số ít card đồ họa và tôi nghi ngờ hầu hết mọi người chỉ có quyền truy cập vào một. Do đó, tôi không thể làm gì nhiều cho phần lớn các lỗi, sẽ luôn nằm trong "một số thẻ khác".

2. Không giống như hầu hết các gói, tôi không thể tạo ra một môi trường thử nghiệm cho phiên bản trình điều khiển mới; máy ảo có trình điều khiển X riêng.

3. Tôi không thể dễ dàng cập nhật trình điều khiển mới nhất, kiểm tra thử, sau đó hoàn nguyên. Điều này không khuyến khích thử nghiệm (vì nếu có sự cố xảy ra, tôi cũng có thể bị gạch đá); nó cũng cản trở thử nghiệm hồi quy.

4. Lần trước tôi đã xem xét, áp dụng thành công một bản vá, biên dịch và chạy X rất khó thực hiện, bước qua trình quản lý gói, yêu cầu các mô-đun hạt nhân cũng được vá và là một bước không thể đảo ngược.

5. Ngày nay, trình điều khiển X phân chia mã của họ giữa kernel, Mesa, udev (cho cài đặt và mặc định) và trình điều khiển userland. Điều đó có nghĩa là các bản vá cũng bị chia tách ...

Vì vậy, tôi đoán câu trả lời là thực hiện việc áp dụng và hoàn nguyên các thay đổi được xử lý bởi trình quản lý gói và dễ dàng khôi phục khi hệ thống của bạn bị hỏng.

Ngoài ra, một hệ thống như DKMS nên được xem xét cho trình điều khiển X; nếu tôi có thể dễ dàng vá / biên dịch / kiểm tra / gỡ cài đặt, trình điều khiển đầu vào cho màn hình cảm ứng của tôi mà không phải xây dựng lại toàn bộ chi tiết nguyên khối (với mối đe dọa làm cho X hoàn toàn không thể sử dụng được), bạn sẽ nhận được nhiều đóng góp ngẫu nhiên hơn và thúc đẩy tôi nhìn vào các lỗi xử lý và các bản vá thử nghiệm liên quan đến bit phần cứng đó.

Để bổ sung cho những gì jbowtie đã nói, tôi sẽ nói thêm rằng, với tư cách là một người sửa lỗi, tôi thấy các lỗi X rất khó đối phó, đơn giản vì X là một con thú rất phức tạp. Điều này được phản ánh trong sự phức tạp của trang wiki khắc phục sự cố . Điều chắc chắn sẽ giúp là một loại chương trình cố vấn cho các thành viên BugSquad để tìm hiểu cách xử lý các lỗi X tốt hơn. Có thể làm một ngày ôm lỗi xung quanh nó? Hoặc một buổi đào tạo thực hành trong lớp học # ubfox?

Thật khó để cải thiện X.org khi nhiều người dùng sử dụng trình điều khiển độc quyền thay thế các phần của ngăn xếp đồ họa và sau đó tìm đến nhóm X.org khi nâng cấp kernel / nâng cấp X.org phá vỡ cài đặt trình điều khiển của họ.

Rất nhiều cuộc nói chuyện về "Tôi không có sẵn tất cả các thẻ" cũng hợp lệ.

Lập trình đồ họa khá khó nếu bạn không phải là một lập trình viên giỏi. Gỡ lỗi có thể là một nỗi đau thực sự, đặc biệt là nếu bạn không thể thấy những gì đang xảy ra.