¿Cómo involucrar a más personas para mejorar X.org para Ubuntu? [cerrado]

En Ubuntu, X es una de las piezas más críticas en la pila. Como tal, recibimos un MONTÓN de preguntas e informes de errores al respecto, probablemente aproximadamente 100 veces más de lo que tenemos mano de obra para manejar.

Canonical está contratando ingenieros adicionales para trabajar en X, lo que ayudará, pero aún hay muchas cosas que están fuera del alcance de lo que Canonical puede hacer, por lo que creo que es realmente importante tener una comunidad fuerte involucrada en mejorar X en Ubuntu, particularmente alrededor de obtener todas estas cantidades masivas de informes de errores respondidos, evaluados y (con suerte) resueltos.

Sin embargo, es difícil encontrar personas para trabajar en X o convencer a las personas de que vale la pena invertir su tiempo en ello. ¿Cómo sugeriría animar a las personas a involucrarse, que de otro modo no estarían pensando en trabajar en X?

Bueno, como todo, hace que sea fácil y accesible para las personas descubrirlo. Entonces, por lo que recuerdo con la selección de errores originalmente, no hubo mucha ayuda proveniente de la comunidad. Luego, cuando algunas páginas wiki explicaban los procesos regulares en la detección de errores y algunos días de errores, involucraban a muchos más miembros de la comunidad. Además, si puede comenzar una actividad regular para que la comunidad la haga y ofrecer ayuda a quienes la prueban, obtendrá algún interés.

Si necesita ayuda con la actividad, puede enviarme un correo electrónico y ayudarlo a organizarla.

Entonces, mi respuesta es hacer una página wiki con preguntas y comandos para obtener una buena información de clasificación de errores para involucrar a las personas en eso.

Para el desarrollo es un gran problema. Las cosas de Xorg y Kernel requieren habilidades de programación de bajo nivel para la mayoría de las funciones de corrección e implementación de errores. Por lo tanto, debe dirigirse a un grupo específico de programadores y hacer que se interesen. No tengo ninguna sugerencia aquí, excepto preguntar un poco y ver quién se junta en # ubuntu-x y preguntarles si pueden ayudar.

La razón por la que X no obtiene tanto trabajo es porque requiere una gran cantidad de conocimiento sobre cómo funcionan las GPU, la memoria, etc., así como la familiaridad con la base de código X.org y, en cierta medida, la programación del kernel. No es algo trivial entrar y, desde la perspectiva de la comunidad, aquellos que estén interesados ​​en trabajar con controladores X o X probablemente ya lo estén haciendo. Actualmente no hay motivación para que un desarrollador para desarrollador trabaje en Xorg aparte del interés personal.

Lo que tiene la comunidad que los desarrolladores de X.org no necesariamente tienen es el acceso a una amplia variedad de hardware. Tener personas que estén dispuestas a pasar el tiempo para escribir 'buenos' informes de errores y probar controladores y partes de la pila de Xorg antes de un lanzamiento probablemente ayudará a los ingenieros más que nada.

Actualmente hay un repositorio de edgers Xorg que utilizo para probar los controladores en mi sistema estable. Es bastante fácil deshacer un solo paquete después de haber terminado las pruebas. Sin embargo, la única otra forma en que podemos probar es compilar X usted mismo o instalar el repositorio de edgers que se construye desde arriba. Esto hace un reemplazo X al por mayor por lo que puedo decir. Esto significa que es un enfoque de todo o nada para probar X.

Tener una forma de tener 2 versiones de X (y elegir con bastante facilidad) cuál desea usar permitiría a los evaluadores no solo probar X, sino que posteriormente volver a un Xorg en funcionamiento para que puedan enviar el informe de error.

Hablando como desarrollador que está casualmente interesado en X, aquí están mis problemas:

1. Solo tengo acceso a un puñado de tarjetas gráficas y sospecho que la mayoría de las personas solo tienen acceso a una. Por lo tanto, no puedo hacer mucho por la gran mayoría de los errores, que siempre estarán en "alguna otra tarjeta".

2. A diferencia de la mayoría de los paquetes, no puedo crear trivialmente un entorno de prueba para una nueva versión del controlador; Las máquinas virtuales tienen sus propios controladores X.

3. No puedo actualizar fácilmente al último controlador, probarlo y luego revertirlo. Esto desalienta la experimentación (porque si algo sale mal, bien podría ser bloqueado); También dificulta las pruebas de regresión.

4. La última vez que lo miré, aplicar un parche con éxito, compilar y ejecutar X fue difícil de hacer, pisé todo el administrador de paquetes, requirió que los módulos del kernel también fueran parcheados, y fue casi un paso irreversible.

5. Hoy en día, los controladores X dividen su código entre kernel, Mesa, udev (para configuraciones y valores predeterminados) y controladores de usuario. Lo que significa que los parches también se dividen ...

Así que supongo que la respuesta es hacer que aplicar y revertir los cambios sea algo manejado por el administrador de paquetes y fácil de recuperar cuando se rompe el sistema.

Además, un sistema como DKMS debe considerarse para los controladores X; si pudiera parchear / compilar / probar / desinstalar fácilmente, por ejemplo, el controlador de entrada para mi pantalla táctil sin tener que reconstruir todo el artilugio monolítico (con la amenaza de hacer que X sea completamente inutilizable), obtendría una contribución más informal y me motivaría a mira errores de prueba y parches de prueba relacionados con ese bit de hardware.

Para complementar lo que dijo jbowtie, agregaría que, como un triager de errores, encuentro que los errores de X son muy difíciles de tratar, simplemente porque X es una bestia muy compleja. Esto se refleja en la complejidad de la página wiki de resolución de problemas . Lo que definitivamente ayudaría es una especie de programa de tutoría para que los miembros de BugSquad aprendan a lidiar mejor con los errores X. ¿Tal vez un día de abrazo de bicho alrededor? ¿O una sesión de capacitación práctica en # ubuntu-aula?

Es difícil mejorar X.org cuando muchos usuarios usan controladores propietarios que reemplazan porciones de la pila de gráficos y luego miran al equipo X.org cuando una actualización del kernel / X.org interrumpe la instalación de su controlador.

Gran parte de la charla sobre "No tengo todas las tarjetas disponibles" también es válida.

La programación de gráficos es bastante difícil si no eres un buen programador. La depuración puede ser un verdadero dolor, especialmente si no puede ver lo que está sucediendo.