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

18

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?

Bryce
fuente
3
Sugeriría hacer esto una entrada de Wiki de la comunidad.
Marco Ceppi
¿Dónde pueden las personas que desean comenzar tener una entrada fácil para ayudar?
txwikinger
Al menos no estás preguntando cómo involucrar a más personas con XFree86;)
Stefan Lasiewski
1
Tenemos un montón de documentos en wiki.ubuntu.com/X para ayudar a las personas que desean ayudar en X. Cubre problemas básicos de X, describe algunos de los procesos de manejo de errores de X, etc. Es un wiki, así que siéntase libre de agregarlo también.
Bryce

Respuestas:

7

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.

Shane Fagan
fuente
¿No está dirigido a implementar Wayland en el futuro? ¿No sería mejor hacer que la gente trabaje en eso?
Ingo
12

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.

usuario543
fuente
3
En realidad, lo que necesitamos no es realmente más informes de errores (tenemos TONELADAS), sino más bien personas que revisen todos los informes que han enviado a Ubuntu, separen lo bueno de lo malo y ayuden a los usuarios cuando sea posible. De hecho, tenemos bastante pocos problemas para que mucha gente pruebe; muchos de ellos no saben cómo escribir informes de errores 'buenos', pero con un poco de trabajo de selección pueden mejorarse (y reenviarse para su posterior trabajo). Es
Bryce
1
¿Tal vez deberíamos hacer un día de corrección de errores para x-server?
txwikinger
12

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.

jbowtie
fuente
Creo que tienes razón en que estos son todos los problemas que un voluntario potencial podría pensar como razones por las que no podrían trabajar en X. Sin embargo, hay muchas cosas que no requieren "abrir el capó" que una persona podría hacer. para ayudar mucho: solucionar errores, responder preguntas de los usuarios, rastrear buenos parches que valga la pena incluir en Ubuntu. Cosas que realmente no enfrentan estos problemas particulares.
Bryce
1
Le tengo más miedo a X que al núcleo. Puedo arrancar un núcleo antiguo fácilmente.
maco
1
Nunca tengo miedo: o Puede configurar fácilmente un entorno de arranque dual donde puede probar parches de kernel, así como servidores Xorg inestables. Ni siquiera tiene que ser tan grande ya que no necesita la mayoría de las herramientas de la GUI para hacerlo simple, y mientras compila puede estar en su entorno normal y entrar en el sistema inestable.
LassePoulsen
4

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?

Bruno Girin
fuente
Un programa de tutoría es en realidad una muy buena idea. Hemos hablado sobre algunas ideas al respecto, pero el desafío hasta ahora ha sido encontrar personas dispuestas a intentarlo.
Bryce
He hecho dos días de abrazo de insectos para X hasta ahora. Casi nadie apareció para hacer triaje, y no obtuvimos ningún miembro nuevo.
Bryce
1

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.

Broam
fuente
Estoy de acuerdo con usted sobre el dolor de los controladores propietarios desde la perspectiva del desarrollador. Pero en el nivel de distribución de ubuntu estamos interesados ​​principalmente en el empaque de los controladores, que es de código abierto y podría beneficiarse de la participación de la comunidad en mejorarlo.
Bryce
Tener una variedad de tarjetas gráficas parece que debería ser importante, pero en mi experiencia hasta ahora, es útil pero no crítico. Lo que me parece más útil es tener 2 computadoras, una para su uso diario regular que se mantiene estable, y una segunda en la que puede dividir X, depurar, ssh, etc.
Bryce