Gentoo Logo

FAQ para Arch Testers de Gentoo x86

Contenido:

1.  Introducción

Este FAQ procura contestar a las preguntas más comunes acerca de cómo convertirse en un "Arch Tester" del equipo x86. También se pueden hacer preguntas en el irc en #gentoo-x86 o enviarlas por correo al autor.

2.  Preguntas

Los Fundamentos

Preguntas generales sobre el "Arch Testing".

Preparativos

Como tener su sistema configurado y listo para probar paquetes.

¡Trabajo, Trabajo, Trabajo!

Trabajo que se realiza diariamente.

3.  Los Fundamentos

Esta sección pretende ser absolutamente genérica y las preguntas contestadas aquí son válidas para la mayoría de las arquitecturas en Gentoo.

¿Qué es un "Arch Tester"?

Un "Arch Tester" (referido comúnmente como "AT") es un usuario digno de confianza capaz de probar una aplicación para determinar su estabilidad. Para ser un AT debe ser capaz de probar una amplia gama de paquetes, y poder entender y modificar ebuilds.

¿Por qué Gentoo necesita "Arch Testers"?

Necesitamos los ATs para ayudar a mejorar la Garantía de Calidad (QA), y para ayudar a los Desarrolladores Arch a asegurar que los paquetes son realmente estables habiendo sido probados por otros que informen sobre sus resultados. Conforme el árbol se hace más y más grande necesitamos a más gente que observe activamente las cosas que se rompen, y ayuden a arreglarlas.

¿Cuáles son las habilidades básicas que necesito para ser un AT?

Debe ser capaz de modificar ebuilds y reconocer errores que deben ser corregidos antes de que marquemos el paquete como estable. También se espera que pueda probar los paquetes e informe del bug correctamente si hay problemas con cualquier cosa. Esto significa que debe sentirse cómodo programando con bash así como en áreas específicas de Gentoo tales como overlays de Portage.

¿Cuáles son los requisitos básicos del sistema si los hay?

Necesitará un sistema, o un chroot, que utilice solamente paquetes marcados como "x86". Esto es así debido a que realmente usamos librerías estables para probar los paquetes, y podemos encontrar bugs en paquetes marcamos como estables. Alternativamente puede ejecutar Gentoo en una máquina dedicada únicamente para pruebas, o en una máquina virtual. Algunos programas adecuados para esto último son VirtualBox, VMWare o QEmu/KVM, aunque se desalienta su uso para trabajo en distintas plataformas por no ser el verdadero hardware.

Además necesita definir FEATURES="test collision-protect" para atrapar los fallos de los test y las colisiones de ficheros entre paquetes. Algunos paquetes no respetan el valor de LDFLAGS y CFLAGS/CXXFLAGS cuando se construyen, lo que puede dar lugar a fallos. Debe definir al menos LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu", lo que hace que Portage muestre una advertencia sobre esto.

¿Qué significa ser parte del equipo AT x86?

Ser parte del Equipo AT x86 significa que está preparado para dedicar una cierta cantidad de tiempo a ayudar a Gentoo/x86. También significa que está interesado en ayudar a probar cualquier aplicación que nos pidan marcar estable.

¿Qué tengo que hacer como AT?. ¿Cuáles son mis roles/responsabilidades?

Necesita ayudar a desarrolladores arch a probar los paquetes. La prueba de un paquete requiere más que simplemente asegurarse de que compila. Esperamos que se compruebe que al menos la mayor parte de la funcionalidad de la aplicación es correcta. Al probar un paquete, asegúrese de tener definida FEATURES="test collision-protect". Si cualquier paquete falla al intentar hacer emerge con esta característica configurada, es una cuestión importante de la QA y no podemos proceder hasta que sea resuelto.

¿Cómo consigo implicarme con el equipo y comienzo a ayudar?

Primero debe leer este FAQ entero así estará al corriente de lo que significa realmente ser un AT. Después de terminar esto, debe ir a irc.freenode.net y entrar en #gentoo-x86. Los desarrolladores a menudo piden ayuda con la prueba de un paquete, y puede intentar ayudar en lo que pueda.

La principal forma de empezar a ayudar es mirar nuestros bugs. Aquí están algunos enlaces para que los añada a sus marcadores o los guarde como búsquedas en bugzilla:

Finalmente, después de que haya demostrado un cierto nivel de compromiso y de que pensemos que será una buena incorporación al equipo, le entregaremos el cuestionario ebuild y entonces pasará un periodo de 30 días con un mentor.

4.  Preparativos

Esta sección trata las preguntas del estilo "cómo configurar" para guiarle a la hora de preparar su sistema para hacer algún trabajo de AT :)

No uso x86 estable, mi equipo es ~x86. ¿Cómo puedo configurar un chroot x86?

Por favor, eche una ojeada a la Guía Chroot para más información respecto a la configuración de un entorno chroot.

Uso un núcleo inestable. ¿Es un inconveniente cuando estoy probando paquetes?

Es preferible que use un núcleo estable fuera del chroot pero no es un requisito estricto.

5.  ¡Trabajo, Trabajo, Trabajo!

Preguntas sobre cómo realizar exactamente su trabajo diario son contestadas aquí.

¿Cuáles son los pasos que necesito seguir cuando estoy probando un paquete?

  1. Asegúrese de que todos los paquetes en el sistema/chroot sean estables.
  2. Ajuste FEATURES="test collision-protect" en /etc/make.conf y use un conjunto de CFLAGS "sano", tal y como se describe en la Guía de Compilación y Optimización de Gentoo.
  3. Elija una petición de las listas de bugs mencionadas arriba, en las que las bugs de seguridad y de palabra clave (keywording) tienen la más absoluta prioridad.
  4. Normalmente, todos los paquetes que se necesitan se listan en la petición, pero a veces, se olvidan las dependencias. Esto no es normalmente un problema en la mayoría de los casos, pero debe incluirlo en su informe de todos modos. Para añadir automáticamente todos los paquetes necesarios al fichero package.keywords, debe usar app-portage/tatt.
  5. Después de hacer emerge del paquete con varias combinaciones de parámetros USE, ejecútelo y asegúrese que la funcionalidad básica es correcta. Si el paquete es una librería, instale un par de paquetes que usen esta librería para asegurar que funcionen con la nueva versión (mejor aún: de todos los paquetes que dependan de él y tengan versiones estables). Las llamadas dependencias inversas se encuentran en el dindex.
  6. Informe al equipo sobre las pruebas realizadas correctamente o los fallos encontrados en el informe de bug correspondiente, incluyendo lo que hizo y en qué plataforma. Si hubo problemas, añada también la salida de emerge --info.
  7. Los problemas que ocurran en la versión estable actual, no serán un obstáculo para las estabilizaciones, pero necesitan ser notificadas de todos modos.

Consejos adicionales que puede encontrar de utilidad:

  • Los testers de arquitectura no solo comprueban paquetes sino que también buscan activamente soluciones para los problemas encontrados. Fuentes importantes de información son los sistemas de control de versiones y los seguidores de bugs (bug trackers) de otras distribuciones y también el desarrollo principal del paquete. ¡Informar de bugs a los autores es tan importante como comprobar los paquetes!.
  • Active un vigilante en Bugzilla en sus preferencias para el alias x86@gentoo.org. Así recibirá todos los correos de Bugzilla dirigidos al equipo x86.

¿Qué poderes divinos tengo como AT?

¡Ja!. ¿Bromea cuando pregunta eso verdad?. Los ATs son los subalternos que hacen todo el trabajo y no tienen ningunos poderes ni juegan ..... De acuerdo, bromeaba :)

Cosas a las que tiene acceso o puede hacer como AT:

  • Privilegios elevados en Gentoo Bugzilla de modo que pueda modificar todos los aspectos de un bug. Esto se da principalmente de forma que pueda reasignar bugs correctamente en caso de que sea necesario y para que se coordine con los mantenedores/otros equipos arch etc. del paquete.
  • Acceso cvs de solo lectura al repositorio gentoo-x86, lo cual no es un privilegio, pero es útil para los ATs. Mire ViewCVS como una URL para acceder de forma anónima.

Cosas a las que no tiene acceso o no puede hacer como AT:

  • Confirmar correcciones en los ebuilds. Tendrá que encontrar al mantenedor a otro desarrollador con acceso para hacerlo.

¿Con quién contactar en caso de errores?

Si descubre algún error importante en el árbol, primero intente contactar con la persona que causó el error. Ésto se puede encontrar normalmente en el ChangeLog, pero si no, use ViewCVS para ver quién realizó el cambio. Si no puede contactar con esta persona, inténtelo con el mantenedor o el equipo del paquete (si el mantenedor no es la misma persona que causó el error). Si todo falla, avise a un desarrollador x86 de la situación, así podremos dirigirlo como mejor podamos hasta que alguien esté disponible para gestionarlo correctamente.

¿Cuál es la mejor forma de entrar en contacto con mantenedores/desarrolladores?

Normalmente la manera más fácil de entrar en contacto con un desarrollador es hacerles "ping" en el IRC. Si no están por el IRC, enviarles un correo. Si no puede contactar con ellos, intente entrar en contacto con algún otro en el equipo (si fuese aplicable). Si no hay un equipo con el que contactar, entonces comente a alguien en el equipo x86 la situación y decidiremos cómo proceder. También, a no ser que el problema sea severo, deles suficiente tiempo para responder por correo electrónico. Compruebe el devaway para asegurarse de que la persona con la que trata de contactar no se ha ido.



Imprimir

Página actualizada 17 de enero, 2012

Sumario: Este documento es la biblia de los "Arch Testers" x86.

Mark Loeser
Autor

Shyam Mani
Editor

Christian Faulhammer
Editor

aj2r
Traductor

José María Alonso
Traductor

John Christian Stoddart
Traductor

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.