¿Cómo involucrar a más gente 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 unas 100 veces más de las que tenemos que 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 siento que es realmente importante tener una comunidad fuerte involucrada en mejorar X en Ubuntu, particularmente en torno a obtener todas estas cantidades masivas de informes de errores respondidos, triaged y (con suerte) resueltos.

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

    
pregunta Bryce 09.08.2010 - 23:42

5 respuestas

7

Bueno, como todo, muchas cosas lo hacen más fácil y accesible para que las personas lo descubran. Entonces, por lo que recuerdo, con el triage de errores originalmente no había mucha ayuda proveniente de la comunidad. Luego, cuando algunas páginas wiki explican los procesos habituales en la búsqueda de errores y algunos días de errores, participan más miembros de la comunidad. Además, si puede comenzar una actividad regular para la comunidad y ofrecer ayuda a quienes la prueban, obtendrá cierto interés.

Si necesita ayuda con la actividad, puede enviarme un correo electrónico y ayudar con la organización.

Así que mi respuesta es hacer una página wiki con preguntas y comandos para obtener una buena información de triage 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 queda en # ubuntu-x y preguntarles si pueden ayudar.

    
respondido por el Shane Fagan 22.08.2010 - 22:22
12

El motivo por el que X no obtiene mucho trabajo es que requiere una gran cantidad de conocimiento sobre cómo funciona la GPU, la memoria, etc., así como la familiaridad con la base de código de X.org y, hasta cierto punto, con la programación del kernel. No es algo trivial y, desde una perspectiva comunitaria, aquellos que estén interesados ​​en trabajar con controladores X o X probablemente ya lo estén haciendo. Actualmente no hay ninguna motivación para que un desarrollador para el desarrollador trabaje en Xorg aparte del interés personal.

Lo que la comunidad tiene 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 dedicar tiempo a escribir 'buenos' informes de errores y probar controladores y partes de la pila Xorg antes de un lanzamiento probablemente ayudará a los ingenieros más que a nada.

Actualmente hay un repositorio de Xorg Edgers que uso para probar los controladores en mi sistema estable. Es bastante fácil deshacer un solo paquete después de que termine la prueba. Sin embargo, la única otra manera en que podemos probar es construir X usted mismo o instalar el repositorio de bordes que se construye desde la parte superior. 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 manera de tener 2 versiones de X (y bastante fácil de elegir) cuál quieres usar permitiría que los probadores no solo prueben X, sino que luego vuelvan a un Xorg en funcionamiento para que puedan enviar el informe de errores.

    
respondido por el user543 10.08.2010 - 02:24
12

Hablando como un 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 la gente solo tiene 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 de controlador; las máquinas virtuales tienen sus propios controladores X.

  3. No puedo actualizar fácilmente el controlador más reciente, probarlo y luego revertirlo. Esto desalienta la experimentación (porque si algo sale mal, también podría ser bricked); también dificulta la prueba de regresión.

  4. La última vez que miré, aplicar con éxito un parche, compilar y ejecutar X era difícil de hacer, recorría todo el administrador de paquetes, requería que los módulos del kernel también fueran parcheados, y era prácticamente 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 userland. Lo que significa que los parches se dividen también ...

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

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

    
respondido por el jbowtie 10.08.2010 - 04:05
4

Para complementar lo que dijo jbowtie, agregaría que, como un bug triager, encuentro que X bugs es un gran desafío, simplemente porque X es una bestia muy compleja. Esto se refleja en la complejidad de la página de resolución de problemas de la wiki . Lo que definitivamente ayudaría es una especie de programa de mentoría para que los miembros de BugSquad aprendan cómo lidiar mejor con los errores X. ¿Quizás un día de abrazo de error? ¿O una sesión de entrenamiento práctico en # ubuntu-classroom?

    
respondido por el Bruno Girin 21.08.2010 - 12:31
1

Es difícil mejorar X.org cuando muchos usuarios usan controladores propietarios que reemplazan partes de la pila de gráficos y luego observan al equipo de X.org cuando una actualización del núcleo / actualización de X.org interrumpe la instalación de controladores.

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.

    
respondido por el Broam 23.08.2010 - 18:13

Lea otras preguntas en las etiquetas