* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/kernel: maintenance.xml
@ 2008-11-25 14:58 John Christian Stoddart (chiguire)
0 siblings, 0 replies; 7+ messages in thread
From: John Christian Stoddart (chiguire) @ 2008-11-25 14:58 UTC (permalink / raw
To: gentoo-commits
chiguire 08/11/25 14:58:32
Added: maintenance.xml
Log:
first spanish translation (chema alonso)
Revision Changes Path
1.1 xml/htdocs/proj/es/kernel/maintenance.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.1&content-type=text/plain
Index: maintenance.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/kernel-upgrade.xml,v
1.16 2006/07/23 12:27:14 neysx Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/proj/es/kernel/maintenance.xml" lang="es">
<title>Guía de los Mantenedores del Núcleo Linux Gentoo</title>
<author title="Autor">
<mail link="dsd@gentoo.org">Daniel Drake</mail>
</author>
<author title="Traductor">
<mail link="chema@nibbler.org.es">José María Alonso</mail>
</author>
<abstract>
Introducción a los procesos de mantenimiento del núcleo Gentoo
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license
See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>0.2</version>
<date>2008-11-19</date>
<chapter>
<title>Introducción</title>
<section>
<body>
<p>
Esta guía pretende documentar los procesos usados en el mantenimiento del
paquete central del núcleo de Gentoo, gentoo-sources. Está escrito con la
esperanza de que ayudará a futuros colaboradores a participar en las tareas
de mantenimiento.
</p>
<p>
En el centro de gentoo-sources está genpatches: un conjunto de parches
genérico diseñado para ser minimalista, independiente de Gentoo y accesible
a otras distribuciones y proyectos. Por favor, asegúrese de que conoce
adecuadamente genpatches antes de continuar: lea la <uri
link="http://dev.gentoo.org/~dsd/genpatches/">página principal de
genpatches</uri>.
</p>
<p>
Este documento fue escrito por Daniel Drake, el líder del proyecto del
núcleo. Las referencias a "mí" en este documento, se refieren a Daniel,
pero, por favor no crea que éste es un proyecto de una sola persona. Otros
miembros del equipo estarán gustosos de ayudarle igualmente.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Comenzando</title>
<section>
<title>Listas de correo</title>
<body>
<p>
Por favor, suscríbase a la lista de correo
<b>gentoo-kernel</b>. Instrucciones para la suscripción pueden encontrarse
<uri link="http://www.gentoo.org/main/es/lists.xml">aquí</uri>, y los
archivos pueden encontrarse <uri
link="http://archives.gentoo.org/gentoo-kernel/">aquí</uri>. Esta lista
tiene poca actividad. Anunciaré la modificaciones a este documento en esta
misma lista.
</p>
<p>
Deberá igualmente suscribirse a la lista de correo linux-kernel (LKML). Esta
lista tiene una <e>extremadamente</e> alta actividad. No debe intentar
leerla completamente, sin embargo eche un vistazo a las cabeceras de los
mensajes cada uno o dos días, no olvidando los aspectos que le interesen. Es
también interesante leer los anuncios de release de Linus y la gente de
-stable, y también los anuncios de release de Andrew Morton -mm para
mantenerse al día de lo que sucede en la comunidad del núcleo.
</p>
<p>
Mantenga la LKML archivada en su propia carpeta en un buen cliente de
correo. Se volverá muy útil más adelante o cuando esté investigando
incidencias reportadas por usuarios en el bugzilla de Gentoo. Yo intento
mantener al menos los 30,000 mensajes más recientes.
</p>
<p>
Para suscribirse a la LKML, envíe un correo a
<mail>majordomo@vger.kernel.org</mail> con lo siguiente en el cuerpo del
mensaje:
</p>
<pre caption="Cuerpo del mensaje">
subscribe linux-kernel SU-DIRECCION-DE-CORREO
</pre>
<p>
También le puede interesar leer la <uri link="http://www.tux.org/lkml/">FAQ
de LKML</uri>. Contiene un montón de información sobre el uso de la lista de
correo en particular, y de la comunidad del núcleo en general. No espero que
al comienzo, tenga necesidad de escribir a la LKML, pero esté seguro de leer
esta FAQ antes de enviarles su primer mensaje.
</p>
</body>
</section>
<section>
<title>IRC</title>
<body>
<p>
Por favor, sea activo en el canal IRC #gentoo-kernel en freenode. El sitio
web gentoo tiene más información en <uri
link="http://www.gentoo.org/main/es/irc.xml">los canales IRC</uri>.
</p>
<p>
Mientras está aprendiendo, por favor, ¡háganos preguntas!. Esta es la mejor
forma de aprender. Si no contestamos, pregunte en otro momento. Queremos
ayudarle, ¡ya que probablemente esto hará que usted nos ayude en el futuro!
</p>
<p>
Los principales mantenedores del núcleo son Daniel Drake (usuario de IRC
<c>dsd_</c>) y Mike Pagano (usuario de IRC <c>mpagano</c>).
</p>
</body>
</section>
<section>
<title>Bugzilla en Gentoo</title>
<body>
<p>
La mayor parte del mantenimiento del núcleo en Gentoo se realiza en <uri
link="https://bugs.gentoo.org">bugzilla</uri> - informes de incidencias,
peticiones de palabras clave, peticiones de características, etc. Asegúrese
de tener su propia cuenta personal.
</p>
<p>
Ahora deberá configurar bugzilla para que le envíe copias de todos los
mensajes de incidencias relacionadas con el mantenimiento del núcleo. Para
hacer esto, vaya a <uri
link="http://bugs.gentoo.org/userprefs.cgi?tab=email">Email Preferences
</uri> de bugzilla y añada <c>kernel@gentoo.org</c> a su lista de
seguimiento de usuarios (User Watching). Le suguiero que ponga en marcha un
filtro de correo que mueva estos mensajes a su propia carpeta.
</p>
<p>
Otra característica útil son las búsquedas almacenadas de bugzilla. Puede
hacer una consulta a bugzilla y salvarla con un nombre definido por el
usuario para acceder rápidamente más tarde. Los enlaces a estas búsquedas
almacenadas se muestran en la parte baja de todas las pantallas de
bugzilla. Para cada una de las siguientes consultas, por favor desplácese
hasta el final de la lista de incidencias resultante y use la funcionalidad
"Remember search" para salvar cada una de ellas:
</p>
<p>
<uri
link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=kernel%40gentoo.org&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&query_based_on=kernel&field0-0-0=keywords&type0-0-0=notsubstring&value0-0-0=ebuild&field0-0-1=noop&type0-0-1=noop&value0-0-1=&field0-1-0=status_whiteboard&type0-1-0=notsubstring&value0-1-0=linux-2.4&field0-2-0=keywords&type0-2-0=notsubstring&value0-2-0=tracker">
Incidencias del núcleo Gentoo</uri>: Esta consulta lista todas las
incidencias abiertas asignadas a kernel@gentoo.org excepto las entregas de
ebuild, incidencias de seguimiento e incidencias de la versión 2.4. Esta es
la lista principal de incidencias en la que estará trabajando.
</p>
<p>
<uri
link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=anywordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&resolution=UPSTREAM&resolution=---&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&query_based_on=Kernel+regressions&field0-0-0=status_whiteboard&type0-0-0=regexp&value0-0-0=linux-2%5C.6%5C..*-regression">
Regresiones del núcleo</uri>: Esta consulta lista todas las incidencias de
regresión abiertas. Una incidencia de regresión es una incidencia que fue
introducida en una cierta release del núcleo mientras que esa misma
funcionalidad no daba problemas en versiones anteriores. Por muchas razones,
las regresiones son la forma más crítica de incidencia.
</p>
<p>
<uri
link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=watch-linux-bugzilla&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&query_based_on=Linux+bugzilla&field0-0-0=noop&type0-0-0=noop&value0-0-0=">
bugzilla Linux</uri>: Esta consulta lista todas las incidencias reportadas
en el bugzilla de Gentoo que han sido escaladas al <uri
link="http://bugzilla.kernel.org">bugzilla del núcleo</uri>.
</p>
</body>
</section>
<section>
<title>El núcleo en bugzilla</title>
<body>
<p>
Nosotros escalamos la mayoría de las incidencias al bugzilla del núcleo,
<uri
link="http://bugzilla.kernel.org">http://bugzilla.kernel.org</uri>. Deberá
crearse una cuenta aquí, y de nuevo, poner <c>kernel@gentoo.org</c> en su
lista de seguimiento de usuarios.
</p>
</body>
</section>
<section>
<title>Subversion</title>
<body>
<p>
Probablemente, encontrará útil mantener una copia subversion de genpatches
en local.
</p>
<pre caption="Haciendo checkout de genpatches desde un SVN anónimo">
# svn co svn://anonsvn.gentoo.org/linux-patches/genpatches-2.6/trunk genpatches
</pre>
</body>
</section>
<section>
<title>Sitios Web</title>
<body>
<p>
Aquí se muestra una lista de sitios web de utilidad a los que me verá
referirme en algún momento.
</p>
<ul>
<li><uri link="https://bugs.gentoo.org">bugzilla de Gentoo</uri></li>
<li><uri link="http://bugzilla.kernel.org">bugzilla del Núcleo</uri></li>
<li><uri link="http://dev.gentoo.org/~dsd/genpatches">Página principal de
genpatches </uri></li>
<li><uri link="http://www.kernel.org">kernel.org</uri></li>
<li><uri link="http://lxr.linux.no/">LXR Cross Referencer</uri> - útil si va a
husmear en el código fuente</li>
<li><uri
link="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary">
gitweb: El árbol de Linus</uri> - las releases del núcleo se generan desde
este repositorio</li>
<li><uri link="http://git.kernel.org">gitweb: índice de los repositorios del
núcleo</uri></li>
</ul>
</body>
</section>
</chapter>
<chapter>
<title>Estilo en el mantenimiento</title>
<section>
<title>Objetivos generales</title>
<body>
<p>
El núcleo es un enorme montón de código base y es uno de los paquetes que
está presente en el sistema de prácticamente cualquier usuario y además está
siendo usado en todo momento. Nuestro estilo de mantenimiento puede parecer
extraño al principio, pero por favor, recuerde que el mantenimiento del
núcleo es en sí una enorme tarea, y por ello, uno de nuestros principales
objetivos es minimizar la cantidad de trabajo que tenemos que hacer (y de
forma global, hacer las cosas más manejables).
</p>
<p>
Una forma en la que reducimos nuestra carga de trabajo es intentar
desviarnos lo menos posible de las releases del kernel: tratamos de hacer
genpatches tan pequeño como nos sea posible. Cuantos menos parches tengamos
que gestionar/compatibilizar hacia atrás/adelante, menor trabajo tendremos
en nuestras manos.
</p>
<p>
Otro enfoque que tomamos es la rápida adopción de nuevas releases del
núcleo. Cada nueva release del núcleo corrige muchas incidencias y añade
soporte para más hardware, lo que invariantemente afecta la proporción de
nuestros usarios. En lugar de pasar por las penurias de compatibilizar hacia
atrás estos cambios en el código, reducimos nuestra carga de trabajo
recomendando la rápida adopción de estas nuevas releases de las que origina
este nuevo código. En favor de estos objetivos, tendemos a discontinuar el
soporte de núcleos viejos en cuanto una nueva release ha sido terminada.
</p>
<p>
Lleva bastante más tiempo la corrección de incidencias que el manejo de
parches. Habiendo tanto código, obtenemos un flujo constante de informes de
incidencia del núcleo en nuestro bugzilla. Algunas de ellas requieren gran
cantidad de tiempo/esfuerzo para ser resueltas. Para ello trabajamos de
forma racional en la resolución de nuestras incidendias.
</p>
<p>
Incluso depués de 3 años gestionando incidencias, personalmente sólo estoy
familiarizado con una pequeña proporción del código base del núcleo. Es
importante que escalemos estas cuanto antes, puesto que los desarrolladores
del núcleo saben lo que hacen. Como aprenderá más adelante, no hacemos
muchas correcciones en Gentoo (downstream).
</p>
<p>
Respecto al reenvío de las incidencias citadas arriba a los desarrolladores
de núcleo (upstream), es importante que mantengamos unas buenas relaciones
con estos desarrolladores. En general, los desarrolladores upstream están al
tanto de incidencias reportadas por distros - después de todo, la mayor
parte de las distribuciones parchean sus releases de núcleo de forma tan
acusada que nos son fácilmente soportadas por personas fuera de esas
distribuciones. Yo, recientemente tuve que sacar un parche de un conjunto de
parches de Mandriva, y sólo por curiosidad, corrí diffstat a sus
parches. ¡El conjunto de datos fue tan grande que reveló una oscura
incidencia en el propio diffstat!
</p>
<p>
Una forma en la que intentamos ganarnos el respeto de los desarrolladores
upstream es usando nuestra política de parches: aparte de circunstancias
excepcionales, no añadimos ningún parche hasta que ellos lo han incluido en
el árbol de desarrollo oficial. Además, esto nos ayuda a respetar las
decisiones en el desarrollo upstream y asegura la calidad (y el soporte
upstream) de nuestro conjunto de parches.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Gestión de incidencias</title>
<section>
<title>Estrategia básica</title>
<body>
<p>
El proceso de corrección de incidencias varía ciertamente de una incidencia
a otra, sin embargo hay muchas cosas en común. Normalmente y durante el
proceso suelo hacer lo siguiente:
</p>
<ul>
<li>Verificar que no se trata de un error de usuario o de configuración</li>
<li>Verificar que no es una incidencia específica de la distro Gentoo</li>
<li>Reunir información detallada para clasificar el problema</li>
<li>Enviar la incidencia al upstream </li>
</ul>
<p>
Con esto en mente, las incidencias a veces siguen un proceso como el
siguiente:
</p>
<ol>
<li>Evaluación inicial</li>
<li>Recopilación de información (incluyendo las peticiones de test del núcleo)</li>
<li>Investigación</li>
<li>Reportando al upstream</li>
</ol>
</body>
</section>
<section>
<title>Proceso inicial</title>
<body>
<p>
Un usuario informa de una incidencia en el bugzilla de Gentoo. Un agente de
incidencias reasigna la misma a <c>kernel@gentoo.org</c>.
</p>
<p>
Usted recibe un mensaje por correo electrónico notificando de esta nueva
incidencia. En primer lugar realiza unas mínimas comprobaciones iniciales
sobre la incidencia: ¿es un error obvio del usuario? ¿Es un duplicado de
otra incidencia que ya ha sido reportada?
</p>
</body>
</section>
<section>
<title>Recopilación de información</title>
<body>
<p>
El informe de incidencia inicial normalmente adolece de poca información, no
por culpa de la persona que la ha reportado. Ejemplos de preguntas comunes
que puede realizar en respuesta al informe inicial, incluyen:
</p>
<ul>
<li><b>¿Qué núcleo está usando?</b> Esta es información importante que se omite
frecuentemente en el informe inicial.</li>
<li><b>¿Ha probado con otras versiones del núcleo?</b> En algunas ocasiones, el
usuario sabe que es una incidencia con larga existencia, esta información
puede ser de utilidad.</li>
<li><b>¿Existe algún núcleo previo en el que haya funcionado?</b> Aquí, usted
básicamente está preguntando "¿se trata de una regresión?"</li>
<li><b>¿Puede usted reproducirlo?</b> Algunas veces lo usuarios anexan volcados
de una caída sin indicación de si fue una única caída después de años de
estabilidad, o si realmente ocurre poco después del arranque o si saben una
forma de provocar la caída.</li>
</ul>
<p>
Naturalmente existen muchas otras preguntas que podrían ser realizadas en la
mayoría de los informes de incidencia, pero muchos de ellos pueden ser
contestados pidiendo información de ciertos comandos o ciertos
ficheros. Normalmente pido información de los siguientes:
</p>
<ul>
<li><b>dmesg</b> - éste vuelca el log del núcleo del arranque actual a la
consola. Contiene todo tipo de información interesante sobre el hardware y
los drivers, así como información sobre cualquier error al nivel del núcleo
que pueden haber ocurrido.</li>
<li><b>.config</b> - algunas veces es útil comprobar exáctamente cómo el usuario
ha configurado su núcleo.</li>
<li>Salida de <b>lsmod</b> - cuando el usuario ha construído ciertos componentes
como módulos ésta es la forma de verificar lo que se ha cargado.</li>
<li>Salida de <b>lspci</b> - ésta ofrece una útil visión general del hardware
del sistema y puede ser usado para tener una idea de que drivers debería
estar cargando el usuario.</li>
</ul>
<p>
Después de pedir un poco de información, podría ocurrir que se diera cuenta
de que necesita pedir algo más. Eso esta bien, simplemente coloque un nuevo
comentario con la nueva petición.
</p>
</body>
</section>
<section>
<title>Consideraciones sobre las versiones</title>
<body>
<p>
Normalmente aceptamos informes de incidencia de 2 versiones del núcleo al
mismo tiempo:
</p>
<ol>
<li>El núcleo más reciente con palabras clave stable</li>
<li>El núcleo más reciente con palabras clave testing</li>
</ol>
<p>
Por ejemplo, en el momento de escribir este documento, el núcleo estable más
reciente es 2.6.20. La versión 2.6.21 acaba de ser publicada, y ya está
disponible en el árbol testing, sin embargo necesita sustancialmente más
tiempo de pruebas antes de que estemos lo bastante seguros para marcarlo
como estable. A lo largo de este tiempo aceptaremos incidencias para la
última release gentoo-sources-2.6.20, y la última release
gentoo-sources-2.6.21.
</p>
<p>
Incluso si un usuario crea una incidencia en un núcleo actualmente
soportado, a menudo le pedimos que lo pruebe con la última versión de
desarrollo del núcleo (la 2.6.22-rc1 en el ejemplo de arriba). ¿Porqué?,
estamos tratando de mover esta incidencia al upstream tan pronto como sea
posible, y como desarrollador del núcleo, simplemente no tiene mucho sentido
diagnosticar nada en un código base que no es el actual.
</p>
<p>
Con esto en mente, y el ejemplo de arriba de las versiones actuales, hay
algunas situaciones que nos podemos encontrar:
</p>
<ul>
<li>Un usuario puede informar de una incidencia con la 2.6.19 o posterior. Estos
núcleos no están soportados. En primer lugar se les deber pedir que lo
reproduzcan en cualquier núcleo que tenga soporte (déles la opción de la
2.6.20 o la 2.6.21), y si la incidencia todavía existe en estas versiones,
pídales que prueben con la última versión de desarrollo (2.6.22-rc1).</li>
<li>El usuario puede reportar una incidencia con la 2.6.20 (la versión estable
del núcleo actualmente soportada). Pídales que prueben la actual versión
testing (2.6.21), y si la incidencia persiste en esta versión, pídales que
que prueben con la última versión de desarrollo (2.6.22-rc1).</li>
<li>El usuario puede reportar una incidencia con la 2.6.21 (la versión testing
del núcleo actualmente soportada). Pídales que prueben a reproducirla con la
última versión de desarrollo del núcleo (por ejemplo la 2.6.22-rc1).</li>
</ul>
<p>
2 semanas después de la publicación por parte del upstream de un núcleo de
'producción' hay un perido en el que no hay versión de desarrollo del núcleo
disponible. Por ejemplo la 2.6.21 acaba de salir y la 2.6.22-rc1 no será
publicada hasta por lo menos una semana. En este caso, puede saltarse el
paso en el que le pida al usuario que pruebe con la última versión de
desarrollo del núcleo -- reproduciendo la incidencia en la 2.6.21 es
suficiente para pedir a los desarrolladores upstream que trabajen en ello.
</p>
</body>
</section>
<section>
<title>Investigando la incidencia</title>
<body>
<p>
Cuando crea que dispone de toda la información acerca del problema, puede
intentar encontrar otros informes acerca de la misma cuestión. En algunos
casos puede hacer esto sin pedir al usuario que pruebe con los nuevos
núcleos.
</p>
<p>
Normalmente sucede que la incidencia ya ha sido informada al upstream y que
todavía haya discusión acerca de cómo corregirla o quizas un parche ya esté
disponible.
</p>
<p>
Esta parte es símplemente de sentido común: ponga algunas palabras en
google. Si dispone de un mensaje de error distinguible, búsquelo. Por otro
lado busque "linux 2.6.20 sky2" si está investigando el funcionamiento de
una regresión en la 2.6.20 con el driver sky2.
</p>
<p>
Puede además consultar el bugzilla de linux con similares términos de
búsqueda y usar su cliente de correo para buscar en sus archivos locales
LKML.
</p>
<p>
Si encuentra algo, magnífico, haga referencia de ello en la
incidencia. Puede incluso haber encontrado la solución al
problema. Ciertamente no es común encontrar referencias para búsquedas
estándar.
</p>
</body>
</section>
<section>
<title>vanilla-sources</title>
<body>
<p>
Ocasionalmente, tenemos informes de incidencia de personas usando
<c>vanilla-sources</c>. El hecho de aceptar o no estas incidencias es
cuestión de juicio. Se ofrece vanilla-sources para ayudar a las pruebas,
pero no está soportado: Si está roto, nosotros no lo arreglamos.
</p>
<p>
Una vez dicho esto, si alguien informa de una incidencia en
vanilla-sources-2.6.21.1 (la última versión upstream) seguramente esté
presente también en la última release gentoo-sources-2.6.21, por lo tanto
tiene sentido aceptar la incidencia y proceder con la diagnosis usual. Sin
embargo, si cree que gentoo-sources puede tener un parche para solucionarlo,
entonces no dude en recordarles que vanilla-sources no tiene soporte y que
necesitan reproducirlo en gentoo-sources antes de que podamos echarle un
vistazo.
</p>
<p>
En algunas ocasiones, el usuario informa de regresiones -rc del núcleo, por
ejemplo, informan de incidencias presentes en vanilla-sources-2.6.22-rc1
pero no en la 2.6.21. En estos casos puede cerrar la incidencia en ese
momento: Debe agradecer al usuario por informar de esta cuestión pero haga
notar que deben informar de la misma al upstream en el bugzilla del núcleo
directamente. gentoo-sources no publica releases -rc.
</p>
</body>
</section>
<section>
<title>Módulos binarios y fuera-de-núcleo</title>
<body>
<p>
Nos podemos encontrar, mientras recopilamos información, que el usuario esta
usando módulos/drivers del núcleo que no son parte de los fuentes oficiales
del núcleo. Un ejemplo de este tipo de paquetes podría ser
<c>x11-drivers/nvidia-drivers</c>.
</p>
<p>
De nuevo, estas situaciones requieren de algún criterio. No hay ninguna
forma de que podamos dar soporte a núcleos que han sido modificados en
tiempo de ejecución de esta forma, por lo tanto es perfectamente razonable
pedir al usuario que reproduzca la incidencia sin cargar los módulos
externos (y pedirle igualmente que <e>no</e> se hayan cargado en ningún
momento desde el arranque, al contrario que arrancar y cargar y descargar
los módulos, y reproduciendo entonces las incidencias.
</p>
<p>
Una vez dicho esto, puede concluir en ocasiones que la incidencia existirá
de todas formas, en cuyo caso no hay necesidad de pedirles que la
reproduzcan sin los módulos externos. Por ejemplo puede haber encontrado un
informe idéntico en un núcleo non-tainted (no-modificado) en LKML.
</p>
</body>
</section>
<section>
<title>Gestión de las regresiones</title>
<body>
<p>
Si llega a la conclusión de que una incidencia es una regresión, hay algunas
cosas extra a considerar. En primer lugar, debe etiquetarla como tal (lea
sobre el campo "Status Whiteboard" más adelante en este documento). En
segundo lugar, deber darse cuenta de que la utilidad de gestión del código
fuente Linux (git) tiene una útil característica bisectiva que puede
identificar el commit exacto que causó la regresión. Esto hace más fácil la
resolución de la incidencia.
</p>
<p>
Sin embargo, realizar una bisección es un proceso que consume bastante
tiempo: Para identificar una regresión entre las versiones 2.6.x y 2.6.x+1
normalmente requiere que construya y pruebe aproximadamente 13 núcleos
distintos. Por lo que, a menos que observe que el usuario está
particularmente interesado, debe agotar otras opciones en primer
lugar. Puede reenviar la incidencia al upstream y después de algunos días,
si no ha habido ningún progreso, pregúnteles si están considerando hacer una
bisección.
</p>
<p>
Tengo algunas instrucciones ya escritas acerca de cómo hacer una bisección,
que son fáciles de seguir. Si va a sugerir una bisección, le recomendaría
que diera un enlace a <uri
link="http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/">
este artículo</uri>.
</p>
</body>
</section>
<section>
<title>Si el usuario no responde</title>
<body>
<p>
Es desafortunado, pero común, los usuario se vuelven mudos y no dan la
información extra que ha solicitado. Como no nos pagan por arreglar estas
cosas y tenemos mucho trabajo, lo mejor es descartar estas incidencias.
</p>
<p>
Después de 14 días, si el usuario no ha respondido a mi petición más
reciente, cierro la incidencia como NEEDINFO con un comentario pidiendo que
reabran la incidencia cuando tengan la información. A menudo esto hace que
el usuario entregue lo solicitado.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Informando de incidencias al upstream</title>
<section>
<title>Visión general</title>
<body>
<p>
Ha llegado a la conclusión de que parece una incidencia del núcleo, ha
recopilado la información que lo refleja, y es reproducible en el último
núcleo de desarrollo. El siguiente paso es reportar la incidencia al
upstream.
</p>
<p>
Hay 2 formas de hacer esto: pidiendo al usuario que informe de la incidencia
en el bugzilla de núcleo y realizándolo usted mismo, enviando un correo a
las listas y mantenedores correspondientes.
</p>
<p>
Es muy importante que se lo pongamos fácil a los desarrolladores
upstream. Cuando informe de incidencias, deje bien claro qué versiones están
afectadas, mencionando la que no se han modificado (normalmente podemos
decir "it's present in 2.6.19-gentoo but is also reproducible on unmodified
2.6.20-rc5").
</p>
<p>
Ya que el procedimiento incluye un enlace a la incidencia en el downstream,
asegúrese de que toda la información es presentada al upstream - no espere
que ellos hagan clic y lean toda la incidencia del downstream que contiene
alguún grado de ruido de cualquier forma.
</p>
<p>
El procedimiento esbozado abajo incluye la modificación del campo "status
whiteboard", que es explicado más adelante en este documento.
</p>
</body>
</section>
<section>
<title>Informando de incidencias en el bugzilla del núcleo</title>
<body>
<p>
El bugzilla del núcleo es el primer mecanismo que usamos para informar de
incidencias al upstream. Realmente, el modo en el que lo hacemos es intentar
que el usuario cree el informe de la incidencia y nosotros hacemos el
seguimiento. Este es el proceso que sigo:
</p>
<ol>
<li>Marque la incidenca Gentoo como UPSTREAM y añada "linux-bugzilla-pending" al
campo "status whiteboard". Cuando haga esto, añada un comentario preguntando
al usuario que informe de la incidencia al upstream. Deles la URL del
bugzilla del núcleo, pídales que pongan la URL de la incidencia en la
incidencia de Gentoo cuando lo hayan hecho, deles algunas indicaciones de lo
que deben incluir en su informe de incidencia (<uri
link="https://bugs.gentoo.org/show_bug.cgi?id=164802#c19">por
ejemplo</uri>).</li>
<li>Cuando el usuario responda con la URL de la incidencia en el upstream,
coloque esta URL en el campo URL de la incidencia de Gentoo. Elimine
"linux-bugzilla-pending" del campo "status whiteboard", y añada
"watch-linux-bugzilla". Añada un pequeño comentario indicando que estaremos
pendientes de la incidencia en el upstream.</li>
<li>Vaya al informe de incidencia en el upstream. Lealo completamente. ¿Olvidó
el usuario alguna información importante para su descripción? En este caso
añada un comentario con esa información. Si hay adjuntos que sean de
utilidad en la incidencia en Gentoo que el usuario no haya anexado a la
incidencia, añádala usted mismo con una pequeña descripción.</li>
<li>Añada kernel@gentoo.org a la lista CC. Si el usuario no indica la URL a la
incidencia en Gentoo en el informe de incidencia de upstream, añada un
comentario con la URL.</li>
</ol>
<p>
Si el usuario no contesta a la petción de abrir la incidencia en el
upstream, desestime la incidencia como lo haría para otros casos sin
respuesta. Debido a que cerró la incidencia como UPSTREAM, se caerá de la
lista de todas formas -- por lo que se continuará el proceso cuando
respondan con la URL de la incidencia en el upstream. La palabra clave
linux-bugzilla-pending nos permite medir cuántas incidencias se pierden
cuando alcanzan este punto, y nos permite hacer un seguimiento.
</p>
<p>
Cuando la incidencia sea actualizada en el upstream, kernel@gentoo.org
obtendrá el correo con este cambio, y como usted tiene esa dirección el el
seguimiento de usuarios, podrá verlo también. Cuando la incidencia sea
corregida, reabra la incidencia en Gentoo con un corto resumen de la
solución, eliminando la etiqueta "watch-linux-bugzilla".
</p>
<p>
Si alguien cierra la incidencia en el upstream sin una solución (por ejemplo
el usuario no respondió a la petición de información, o la incidencia se
marcó como inválida), refleje estos cambios en la incidencia en Gentoo:
marque esta incidencia como CLOSED y elimine la etiqueta
"watch-linux-bugzilla".
</p>
</body>
</section>
<section>
<title>Enviando informes de incidencia por correo al upstream</title>
<body>
<p>
Será escrito en el futuro. Esto es usado como caso extremo en el que la
incidencia en el upstream no está teniendo la atención que necesita.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Otras cuestiones de bugzilla</title>
<section>
<title>Privilegios de acceso</title>
<body>
<p>
Este documento incluye referencias a la manipulación de incidencias en el
bugzilla de Gentoo (abrir/cerrar/reabrir/reasignar/etc). A menos que sea un
desarrollador de Gentoo o sea un usuario que ha informado de una incidencia,
realmente no tendrá acceso a esto.
</p>
<p>
Si cierta acción ha de ser tomada sobre una incidencia en la que usted no
tiene permisos, debe preguntar en el canal #gentoo-kernel de IRC para que
alguien realice la operación. Si no hay respuesta, deje un simple comentario
sobre la incidencia pidiendo el cambio, por ejemplo. "please close this bug
as NEEDINFO"
</p>
<p>
Sé que esto es una lata, pero es sólo temporal. Una vez que haya realizado
algunas contribuciones a las incidencias de esta forma, incrementaré sus
permisos de acceso a bugzilla para que pueda realizar estas tareas ustes
solo.
</p>
<p>
El otro aspecto de este problema es la manipulación de incidencias en el
bugzilla del núcleo upstream. Se necesita hacer esto más que en las bugs de
Gentoo. Yo personalmente tengo acceso de desarrollador la bugzilla upstream,
por lo que si se necesita hacer algo (clausura de
incidencias/reasignación/etc), persígame en IRC. En el futuro podríamos ver
la posibilidad de tener a más gente con accesoo de desarrollador a esta
plataforma.
</p>
</body>
</section>
<section>
<title>Status Whiteboard</title>
<body>
<p>
Bugzilla tiene un campo de texto de una sola línea llamado "status
whiteboard" para cada incidencia, en el que es usted libre de poner
cualquier cosa. Yo lo uso como cierta forma de etiquetado.
</p>
<p>
Si una incidencia está presente en la 2.6.20, pero corregida en la 2.6.21 y
la corrección no se conoce aún, yo pongo "linux-2.6.21" en el campo "status
whiteboard". Esto está efectivamente etiquetando la incidencia diciendo
"este problema desaparece cuando la versión 2.6.21 se publique".
</p>
<p>
Si la incidencia es una regresión de la 2.6.21, yo escribo
"linux-2.6.21-regression" en el campo "status whiteboard". De hecho esto se
usa en una de las búsquedas almacenadas mencionadas anteriormente. Si la
incidencia es una regresión pero la versión que introdujo la incidencia es
desconocida (por ejemplo, funciona en la 2.6.16, pero en la 2.6.20 no), yo
coloco "linux-2.6.??-regression" en el "whiteboard". Para regresiones,
también prefijo el campo "summary" con (por ejemplo) <c>[2.6.21
regression]</c>, de este modo las cosas se ven rápidamente en los resultados
de la búsqueda.
</p>
<p>
Si la incidencia ha sido reportada upstream, coloco la URL de la incidencia
en el campo URL, y "watch-linux-bugzilla" en el campo "status
whiteboard". Esto se usa en una de las búsquedas almacenadas.
</p>
</body>
</section>
<section>
<title>Asignación de incidencias</title>
<body>
<p>
Todas las incidencias del núcleo son asignadas a <c>kernel@gentoo.org</c>
por defecto. Cuando una incidencia ha sido resuelta pero no está corregida
en portage (esto es, está pendiente de un parche que debe ser añadido a
genpatches, o pendiente de la siguiente release de genpatches/gentoo-sources
release), añadimos la palabra clave InSVN.
</p>
</body>
</section>
<section>
<title>Resolución de incidencias</title>
<body>
<p>
Cuando se marca una incidencia como resuelta pero no está arreglada en
portage (es decir, está pendiente de que se añada un parche a genpatches o
pendiente de la siguiente release de genpatches/gentoo-sources release),
añadimos la palabra clave bugzilla <c>InSVN</c>.
</p>
<p>
Se cierra entonces la incidencia con un mensaje apropiado cuando una nueva
release del núcleo (incorporando la corrección) se añade la árbol de
portage.
</p>
</body>
</section>
</chapter>
<chapter>
<title>genpatches y linux-stable</title>
<section>
<title>Criterio de envíos</title>
<body>
<ul>
<li>Esta sección esta pensada para describir el proceso únicamente a
desarrolladores del núcleo (en lugar de para los futuros), pero si está
realmente interesado, no dude en preguntar en IRC si quisiera enviar un
parche.</li>
<li>El parche debe ajustarse a las reglas del núcleo estable, mire en
Documentation/stable_kernel_rules.txt</li>
<li>El parche debe ser enviado a por lo menos una release gentoo-sources. La
razón para esto es que en algún momento, los parches grabados en genpatches
no están probados -- la comprobación completa se lleva a cabo antes de su
publicación.</li>
<li>El parche no debe estar ya presente en la cola stable. Compruebe la <uri
link="http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=tree">interfaz
web de stable-queue.git</uri>.</li>
</ul>
</body>
</section>
<section>
<title>Proceso de envío</title>
<body>
<p>
Redacte un correo de la siguiente forma:
</p>
<ul>
<li>Dirigido a stable@kernel.org"</li>
<li>CC kernel@gentoo.org</li>
<li>CC al autor del parche, cuyos datos de contacto se pueden encontrar en el
propio parche</li>
<li>Use el mismo asunto que el presente en el parche, prefíjelo con [PATCH] si
no lo está ya.</li>
<li>En el cuerpo del mensaje, incluya una breve descripción con una referencia
al informe de incidencia de Gentoo, por ejemplo: "This patch fixes a bootup
crash in the snd-intel-hda driver as detailed at
http://bugs.gentoo.org/12345"</li>
<li><e>Adjunte</e> el parche al mensaje, directamente desde genpatches. El
parche debe venir de gitweb o similar y tener los detalles de autoría,
commit ID, etc.</li>
</ul>
</body>
</section>
</chapter>
<chapter>
<title>¿Qué hacer ahora?</title>
<section>
<body>
<p>
Eche un vistazo a algunos informes de incidencia de las búsquedas
almacenadas configuradas anteriormente. Si puede contribuir de forma
directa, adelante. Sin embargo, lo normal es que no esté seguro de qué hacer
a continuación. Por lo tanto, tome una incidencia, y pregúntenos acerca de
ella, preferiblemente en el canal #gentoo-kernel de IRC. Alternativamente,
puede escribir a la lista de correo gentoo-kernel.
</p>
<p>
Puede parecer que muchas de las incidencias abiertas estén en buenas manos
esperando por el usuario o algo así. Sin embargo, por favor esté cerca, ¡ya
que siempre tenemos un flujo contínuo de nuevas incidencias!
</p>
<p>
Aunque este documento le ha presentado lo procesos, puede que no se sienta
capaz de meterse en los problemas y resolver incidencias. ¡Eso está bien!
Porque usted está en nuestra lista de seguimiento de kernel@gentoo.org,
usted verá las incidencias según entran. Antes o después será capaz de hacer
las mismas actividades que nosotros en otras incidencias, ¡y usted estará en
el camino!
</p>
<p>
¡Gracias por tu interés en ayudarnos!
</p>
</body>
</section>
</chapter>
</guide>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/kernel: maintenance.xml
@ 2008-11-28 12:48 John Christian Stoddart (chiguire)
0 siblings, 0 replies; 7+ messages in thread
From: John Christian Stoddart (chiguire) @ 2008-11-28 12:48 UTC (permalink / raw
To: gentoo-commits
chiguire 08/11/28 12:48:26
Modified: maintenance.xml
Log:
updated spanish translation (chema alonso)
Revision Changes Path
1.2 xml/htdocs/proj/es/kernel/maintenance.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.2&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.2&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?r1=1.1&r2=1.2
Index: maintenance.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- maintenance.xml 25 Nov 2008 14:58:32 -0000 1.1
+++ maintenance.xml 28 Nov 2008 12:48:26 -0000 1.2
@@ -878,21 +878,6 @@
</section>
<section>
-<title>Asignación de incidencias</title>
-<body>
-
-<p>
-Todas las incidencias del núcleo son asignadas a <c>kernel@gentoo.org</c>
-por defecto. Cuando una incidencia ha sido resuelta pero no está corregida
-en portage (esto es, está pendiente de un parche que debe ser añadido a
-genpatches, o pendiente de la siguiente release de genpatches/gentoo-sources
-release), añadimos la palabra clave InSVN.
-</p>
-
-</body>
-</section>
-
-<section>
<title>Resolución de incidencias</title>
<body>
@@ -950,7 +935,7 @@
</p>
<ul>
-<li>Dirigido a stable@kernel.org"</li>
+<li>Dirigido a stable@kernel.org</li>
<li>CC kernel@gentoo.org</li>
<li>CC al autor del parche, cuyos datos de contacto se pueden encontrar en el
propio parche</li>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/kernel: maintenance.xml
@ 2009-01-30 14:04 John Christian Stoddart (chiguire)
0 siblings, 0 replies; 7+ messages in thread
From: John Christian Stoddart (chiguire) @ 2009-01-30 14:04 UTC (permalink / raw
To: gentoo-commits
chiguire 09/01/30 14:04:54
Modified: maintenance.xml
Log:
updated spanish translation (jose maria alonso)
Revision Changes Path
1.3 xml/htdocs/proj/es/kernel/maintenance.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.3&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.3&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?r1=1.2&r2=1.3
Index: maintenance.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- maintenance.xml 28 Nov 2008 12:48:26 -0000 1.2
+++ maintenance.xml 30 Jan 2009 14:04:53 -0000 1.3
@@ -11,7 +11,7 @@
<mail link="dsd@gentoo.org">Daniel Drake</mail>
</author>
<author title="Traductor">
- <mail link="chema@nibbler.org.es">José María Alonso</mail>
+ <mail link="gentoo@nimiux.org">José María Alonso</mail>
</author>
<abstract>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/kernel: maintenance.xml
@ 2010-05-24 19:50 JosA MarAa Alonso (nimiux)
0 siblings, 0 replies; 7+ messages in thread
From: JosA MarAa Alonso (nimiux) @ 2010-05-24 19:50 UTC (permalink / raw
To: gentoo-commits
nimiux 10/05/24 19:50:22
Modified: maintenance.xml
Log:
Changed translator's mail. Used gentoo username instead.
Revision Changes Path
1.4 xml/htdocs/proj/es/kernel/maintenance.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.4&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.4&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?r1=1.3&r2=1.4
Index: maintenance.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- maintenance.xml 30 Jan 2009 14:04:53 -0000 1.3
+++ maintenance.xml 24 May 2010 19:50:22 -0000 1.4
@@ -11,7 +11,7 @@
<mail link="dsd@gentoo.org">Daniel Drake</mail>
</author>
<author title="Traductor">
- <mail link="gentoo@nimiux.org">José María Alonso</mail>
+ <mail link="nimiux" />
</author>
<abstract>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/kernel: maintenance.xml
@ 2012-10-28 15:21 Sven Vermeulen (swift)
0 siblings, 0 replies; 7+ messages in thread
From: Sven Vermeulen (swift) @ 2012-10-28 15:21 UTC (permalink / raw
To: gentoo-commits
swift 12/10/28 15:21:19
Modified: maintenance.xml
Log:
Removing link attribute from guides
Revision Changes Path
1.5 xml/htdocs/proj/es/kernel/maintenance.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.5&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.5&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?r1=1.4&r2=1.5
Index: maintenance.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- maintenance.xml 24 May 2010 19:50:22 -0000 1.4
+++ maintenance.xml 28 Oct 2012 15:21:19 -0000 1.5
@@ -5,7 +5,7 @@
1.16 2006/07/23 12:27:14 neysx Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<guide link="/proj/es/kernel/maintenance.xml" lang="es">
+<guide lang="es">
<title>Guía de los Mantenedores del Núcleo Linux Gentoo</title>
<author title="Autor">
<mail link="dsd@gentoo.org">Daniel Drake</mail>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/kernel: maintenance.xml
@ 2013-05-26 18:47 JosA MarAa Alonso (nimiux)
0 siblings, 0 replies; 7+ messages in thread
From: JosA MarAa Alonso (nimiux) @ 2013-05-26 18:47 UTC (permalink / raw
To: gentoo-commits
nimiux 13/05/26 18:47:06
Modified: maintenance.xml
Log:
Fix xml format. Fix typos. No version bump
Revision Changes Path
1.6 xml/htdocs/proj/es/kernel/maintenance.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.6&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.6&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?r1=1.5&r2=1.6
Index: maintenance.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- maintenance.xml 28 Oct 2012 15:21:19 -0000 1.5
+++ maintenance.xml 26 May 2013 18:47:06 -0000 1.6
@@ -6,6 +6,7 @@
1.16 2006/07/23 12:27:14 neysx Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide lang="es">
+
<title>Guía de los Mantenedores del Núcleo Linux Gentoo</title>
<author title="Autor">
<mail link="dsd@gentoo.org">Daniel Drake</mail>
@@ -60,7 +61,7 @@
</chapter>
<chapter>
-<title>Comenzando</title>
+<title>Comenzamos</title>
<section>
<title>Listas de correo</title>
@@ -68,9 +69,10 @@
<p>
Por favor, suscríbase a la lista de correo
-<b>gentoo-kernel</b>. Instrucciones para la suscripción pueden encontrarse
-<uri link="http://www.gentoo.org/main/es/lists.xml">aquí</uri>, y los
-archivos pueden encontrarse <uri
+<b>gentoo-kernel</b>.
+<uri link="http://www.gentoo.org/main/es/lists.xml">Aquí</uri>
+se pueden encontar instrucciones para la suscripción, y los
+archivos se pueden encontrar <uri
link="http://archives.gentoo.org/gentoo-kernel/">aquí</uri>. Esta lista
tiene poca actividad. Anunciaré la modificaciones a este documento en esta
misma lista.
@@ -127,7 +129,7 @@
<p>
Mientras está aprendiendo, por favor, ¡háganos preguntas!. Esta es la mejor
forma de aprender. Si no contestamos, pregunte en otro momento. Queremos
-ayudarle, ¡ya que probablemente esto hará que usted nos ayude en el futuro!
+ayudarle, ¡ya que probablemente esto hará que nos ayude en el futuro!
</p>
<p>
@@ -155,7 +157,7 @@
hacer esto, vaya a <uri
link="http://bugs.gentoo.org/userprefs.cgi?tab=email">Email Preferences
</uri> de bugzilla y añada <c>kernel@gentoo.org</c> a su lista de
-seguimiento de usuarios (User Watching). Le suguiero que ponga en marcha un
+seguimiento de usuarios (User Watching). Le sugiero que ponga en marcha un
filtro de correo que mueva estos mensajes a su propia carpeta.
</p>
@@ -240,19 +242,27 @@
</p>
<ul>
-<li><uri link="https://bugs.gentoo.org">bugzilla de Gentoo</uri></li>
-<li><uri link="http://bugzilla.kernel.org">bugzilla del Núcleo</uri></li>
-<li><uri link="http://dev.gentoo.org/~dsd/genpatches">Página principal de
-genpatches </uri></li>
-<li><uri link="http://www.kernel.org">kernel.org</uri></li>
-<li><uri link="http://lxr.linux.no/">LXR Cross Referencer</uri> - útil si va a
-husmear en el código fuente</li>
-<li><uri
-link="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary">
-gitweb: El árbol de Linus</uri> - las releases del núcleo se generan desde
-este repositorio</li>
-<li><uri link="http://git.kernel.org">gitweb: índice de los repositorios del
-núcleo</uri></li>
+ <li><uri link="https://bugs.gentoo.org">bugzilla de Gentoo</uri></li>
+ <li><uri link="http://bugzilla.kernel.org">bugzilla del Núcleo</uri></li>
+ <li>
+ <uri link="http://dev.gentoo.org/~dsd/genpatches">Página principal de
+ genpatches </uri>
+ </li>
+ <li><uri link="http://www.kernel.org">kernel.org</uri></li>
+ <li>
+ <uri link="http://lxr.linux.no/">LXR Cross Referencer</uri> - útil si va a
+ husmear en el código fuente
+ </li>
+ <li>
+ <uri
+ link="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary">
+ gitweb: El árbol de Linus</uri> - las releases del núcleo se generan desde
+ este repositorio
+ </li>
+ <li>
+ <uri link="http://git.kernel.org">gitweb: índice de los repositorios del
+ núcleo</uri>
+ </li>
</ul>
</body>
@@ -301,26 +311,26 @@
parches. Habiendo tanto código, obtenemos un flujo constante de informes de
incidencia del núcleo en nuestro bugzilla. Algunas de ellas requieren gran
cantidad de tiempo/esfuerzo para ser resueltas. Para ello trabajamos de
-forma racional en la resolución de nuestras incidendias.
+forma racional en la resolución de nuestras incidencias.
</p>
<p>
-Incluso depués de 3 años gestionando incidencias, personalmente sólo estoy
-familiarizado con una pequeña proporción del código base del núcleo. Es
-importante que escalemos estas cuanto antes, puesto que los desarrolladores
-del núcleo saben lo que hacen. Como aprenderá más adelante, no hacemos
-muchas correcciones en Gentoo (downstream).
+Incluso después de tres años gestionando incidencias, personalmente
+solo estoy familiarizado con una pequeña proporción del código base del
+núcleo. Es importante que escalemos estas cuanto antes, puesto que los
+desarrolladores del núcleo saben lo que hacen. Como aprenderá más
+adelante, no hacemos muchas correcciones en Gentoo (downstream).
</p>
<p>
Respecto al reenvío de las incidencias citadas arriba a los desarrolladores
de núcleo (upstream), es importante que mantengamos unas buenas relaciones
-con estos desarrolladores. En general, los desarrolladores upstream están al
+con estos desarrolladores. En general, estos desarrolladores están al
tanto de incidencias reportadas por distros - después de todo, la mayor
parte de las distribuciones parchean sus releases de núcleo de forma tan
acusada que nos son fácilmente soportadas por personas fuera de esas
distribuciones. Yo, recientemente tuve que sacar un parche de un conjunto de
-parches de Mandriva, y sólo por curiosidad, corrí diffstat a sus
+parches de Mandriva, y solo por curiosidad, corrí diffstat a sus
parches. ¡El conjunto de datos fue tan grande que reveló una oscura
incidencia en el propio diffstat!
</p>
@@ -330,8 +340,8 @@
upstream es usando nuestra política de parches: aparte de circunstancias
excepcionales, no añadimos ningún parche hasta que ellos lo han incluido en
el árbol de desarrollo oficial. Además, esto nos ayuda a respetar las
-decisiones en el desarrollo upstream y asegura la calidad (y el soporte
-upstream) de nuestro conjunto de parches.
+decisiones en el desarrollo principal y asegura la calidad (y el soporte
+del equipo de desarrollo) de nuestro conjunto de parches.
</p>
</body>
@@ -353,10 +363,10 @@
</p>
<ul>
-<li>Verificar que no se trata de un error de usuario o de configuración</li>
-<li>Verificar que no es una incidencia específica de la distro Gentoo</li>
-<li>Reunir información detallada para clasificar el problema</li>
-<li>Enviar la incidencia al upstream </li>
+ <li>Verificar que no se trata de un error de usuario o de configuración</li>
+ <li>Verificar que no es una incidencia específica de la distro Gentoo</li>
+ <li>Reunir información detallada para clasificar el problema</li>
+ <li>Enviar la incidencia al equipo de desarrollo (upstream)</li>
</ul>
<p>
@@ -365,10 +375,12 @@
</p>
<ol>
-<li>Evaluación inicial</li>
-<li>Recopilación de información (incluyendo las peticiones de test del núcleo)</li>
-<li>Investigación</li>
-<li>Reportando al upstream</li>
+ <li>Evaluación inicial</li>
+ <li>
+ Recopilación de información (incluyendo las peticiones de test del núcleo)
+ </li>
+ <li>Investigación</li>
+ <li>Informar al equipo de desarrollo (upstream)</li>
</ol>
</body>
@@ -384,7 +396,7 @@
</p>
<p>
-Usted recibe un mensaje por correo electrónico notificando de esta nueva
+Se recibe un mensaje por correo electrónico notificando de esta nueva
incidencia. En primer lugar realiza unas mínimas comprobaciones iniciales
sobre la incidencia: ¿es un error obvio del usuario? ¿Es un duplicado de
otra incidencia que ya ha sido reportada?
@@ -404,38 +416,55 @@
</p>
<ul>
-<li><b>¿Qué núcleo está usando?</b> Esta es información importante que se omite
-frecuentemente en el informe inicial.</li>
-<li><b>¿Ha probado con otras versiones del núcleo?</b> En algunas ocasiones, el
-usuario sabe que es una incidencia con larga existencia, esta información
-puede ser de utilidad.</li>
-<li><b>¿Existe algún núcleo previo en el que haya funcionado?</b> Aquí, usted
-básicamente está preguntando "¿se trata de una regresión?"</li>
-<li><b>¿Puede usted reproducirlo?</b> Algunas veces lo usuarios anexan volcados
-de una caída sin indicación de si fue una única caída después de años de
-estabilidad, o si realmente ocurre poco después del arranque o si saben una
-forma de provocar la caída.</li>
+ <li>
+ <b>¿Qué núcleo está usando?</b> Esta es información importante que se omite
+ frecuentemente en el informe inicial.
+ </li>
+ <li>
+ <b>¿Ha probado con otras versiones del núcleo?</b> En algunas ocasiones, el
+ usuario sabe que es una incidencia con larga existencia, esta información
+ puede ser de utilidad.
+ </li>
+ <li>
+ <b>¿Existe algún núcleo previo en el que haya funcionado?</b> Aquí,
+ básicamente se está preguntando "¿se trata de una regresión?"
+ </li>
+ <li>
+ <b>¿Puede reproducirlo?</b> Algunas veces lo usuarios anexan volcados
+ de una caída sin indicación de si fue una única caída después de años de
+ estabilidad, o si realmente ocurre poco después del arranque o si saben una
+ forma de provocar la caída.
+ </li>
</ul>
<p>
Naturalmente existen muchas otras preguntas que podrían ser realizadas en la
mayoría de los informes de incidencia, pero muchos de ellos pueden ser
-contestados pidiendo información de ciertos comandos o ciertos
+contestados pidiendo información sobre ciertas órdenes o ciertos
ficheros. Normalmente pido información de los siguientes:
</p>
<ul>
-<li><b>dmesg</b> - éste vuelca el log del núcleo del arranque actual a la
-consola. Contiene todo tipo de información interesante sobre el hardware y
-los drivers, así como información sobre cualquier error al nivel del núcleo
-que pueden haber ocurrido.</li>
-<li><b>.config</b> - algunas veces es útil comprobar exáctamente cómo el usuario
-ha configurado su núcleo.</li>
-<li>Salida de <b>lsmod</b> - cuando el usuario ha construído ciertos componentes
-como módulos ésta es la forma de verificar lo que se ha cargado.</li>
-<li>Salida de <b>lspci</b> - ésta ofrece una útil visión general del hardware
-del sistema y puede ser usado para tener una idea de que drivers debería
-estar cargando el usuario.</li>
+ <li>
+ <b>dmesg</b> - éste vuelca el log del núcleo del arranque actual
+ a la consola. Contiene todo tipo de información interesante sobre
+ el hardware y los controladores, así como información sobre
+ cualquier error al nivel del núcleo que pueden haber ocurrido.
+ </li>
+ <li>
+ <b>.config</b> - algunas veces es útil comprobar exactamente cómo
+ el usuario ha configurado su núcleo.
+ </li>
+ <li>
+ Salida de <b>lsmod</b> - cuando el usuario ha construido ciertos
+ componentes como módulos ésta es la forma de verificar lo que se ha
+ cargado.
+ </li>
+ <li>
+ Salida de <b>lspci</b> - ésta ofrece una útil visión general del
+ hardware del sistema y puede ser usado para tener una idea de qué
+ controladores debería estar cargando el usuario.
+ </li>
</ul>
<p>
@@ -457,8 +486,8 @@
</p>
<ol>
-<li>El núcleo más reciente con palabras clave stable</li>
-<li>El núcleo más reciente con palabras clave testing</li>
+ <li>El núcleo más reciente con palabras clave stable</li>
+ <li>El núcleo más reciente con palabras clave testing</li>
</ol>
<p>
@@ -475,9 +504,9 @@
Incluso si un usuario crea una incidencia en un núcleo actualmente
soportado, a menudo le pedimos que lo pruebe con la última versión de
desarrollo del núcleo (la 2.6.22-rc1 en el ejemplo de arriba). ¿Porqué?,
-estamos tratando de mover esta incidencia al upstream tan pronto como sea
-posible, y como desarrollador del núcleo, simplemente no tiene mucho sentido
-diagnosticar nada en un código base que no es el actual.
+estamos tratando de mover esta incidencia al equipo de desarrollo tan pronto
+como sea posible, y como desarrollador del núcleo, simplemente no tiene
+mucho sentido diagnosticar nada en un código base que no es el actual.
</p>
<p>
@@ -486,35 +515,43 @@
</p>
<ul>
-<li>Un usuario puede informar de una incidencia con la 2.6.19 o posterior. Estos
-núcleos no están soportados. En primer lugar se les deber pedir que lo
-reproduzcan en cualquier núcleo que tenga soporte (déles la opción de la
-2.6.20 o la 2.6.21), y si la incidencia todavía existe en estas versiones,
-pídales que prueben con la última versión de desarrollo (2.6.22-rc1).</li>
-<li>El usuario puede reportar una incidencia con la 2.6.20 (la versión estable
-del núcleo actualmente soportada). Pídales que prueben la actual versión
-testing (2.6.21), y si la incidencia persiste en esta versión, pídales que
-que prueben con la última versión de desarrollo (2.6.22-rc1).</li>
-<li>El usuario puede reportar una incidencia con la 2.6.21 (la versión testing
-del núcleo actualmente soportada). Pídales que prueben a reproducirla con la
-última versión de desarrollo del núcleo (por ejemplo la 2.6.22-rc1).</li>
+ <li>
+ Un usuario puede informar de una incidencia con la 2.6.19 o posterior.
+ Estos núcleos no tienen soporte. En primer lugar se les deber pedir
+ que lo reproduzcan en cualquier núcleo que tenga soporte (déles la
+ opción de las versiones 2.6.20 o 2.6.21), y si la incidencia todavía
+ existe en estas versiones, pídales que prueben con la última versión
+ de desarrollo (2.6.22-rc1).
+ </li>
+ <li>
+ El usuario puede reportar una incidencia con la 2.6.20 (la versión estable
+ del núcleo actualmente soportada). Pídales que prueben la actual versión
+ testing (2.6.21), y si la incidencia persiste en esta versión, pídales que
+ que prueben con la última versión de desarrollo (2.6.22-rc1).
+ </li>
+ <li>
+ El usuario puede reportar una incidencia con la 2.6.21 (la versión testing
+ del núcleo actualmente soportada). Pídales que prueben a reproducirla con la
+ última versión de desarrollo del núcleo (por ejemplo la 2.6.22-rc1).
+ </li>
</ul>
<p>
-2 semanas después de la publicación por parte del upstream de un núcleo de
-'producción' hay un perido en el que no hay versión de desarrollo del núcleo
-disponible. Por ejemplo la 2.6.21 acaba de salir y la 2.6.22-rc1 no será
-publicada hasta por lo menos una semana. En este caso, puede saltarse el
-paso en el que le pida al usuario que pruebe con la última versión de
-desarrollo del núcleo -- reproduciendo la incidencia en la 2.6.21 es
-suficiente para pedir a los desarrolladores upstream que trabajen en ello.
+Dos semanas después de la publicación por parte del equipo de desarrollo
+de un núcleo de 'producción' hay un periodo en el que no hay versión de
+desarrollo del núcleo disponible. Por ejemplo la 2.6.21 acaba de salir
+y la 2.6.22-rc1 no será publicada hasta por lo menos una semana. En este
+caso, puede saltarse el paso en el que se le pide al usuario que pruebe
+con la última versión de desarrollo del núcleo, reproducir la
+incidencia en la 2.6.21 es suficiente para pedir a los desarrolladores
+del equipo de desarrollo que trabajen en ello.
</p>
</body>
</section>
<section>
-<title>Investigando la incidencia</title>
+<title>Investigar la incidencia</title>
<body>
<p>
@@ -525,9 +562,9 @@
</p>
<p>
-Normalmente sucede que la incidencia ya ha sido informada al upstream y que
-todavía haya discusión acerca de cómo corregirla o quizas un parche ya esté
-disponible.
+Normalmente sucede que la incidencia ya ha sido informada al equipo
+de desarrollo y que todavía haya discusión acerca de cómo corregirla
+o quizás ya esté disponible un parche.
</p>
<p>
@@ -566,13 +603,14 @@
<p>
Una vez dicho esto, si alguien informa de una incidencia en
-vanilla-sources-2.6.21.1 (la última versión upstream) seguramente esté
-presente también en la última release gentoo-sources-2.6.21, por lo tanto
-tiene sentido aceptar la incidencia y proceder con la diagnosis usual. Sin
-embargo, si cree que gentoo-sources puede tener un parche para solucionarlo,
-entonces no dude en recordarles que vanilla-sources no tiene soporte y que
-necesitan reproducirlo en gentoo-sources antes de que podamos echarle un
-vistazo.
+vanilla-sources-2.6.21.1 (la última versión del equipo de desarrollo)
+seguramente esté presente también en la última release
+gentoo-sources-2.6.21, por lo tanto tiene sentido aceptar la incidencia
+y proceder con la diagnosis usual. Sin embargo, si cree que
+gentoo-sources puede tener un parche para solucionarlo, entonces no
+dude en recordarles que vanilla-sources no tiene soporte y que
+necesitan reproducirlo en gentoo-sources antes de que podamos echarle
+un vistazo.
</p>
<p>
@@ -580,8 +618,8 @@
ejemplo, informan de incidencias presentes en vanilla-sources-2.6.22-rc1
pero no en la 2.6.21. En estos casos puede cerrar la incidencia en ese
momento: Debe agradecer al usuario por informar de esta cuestión pero haga
-notar que deben informar de la misma al upstream en el bugzilla del núcleo
-directamente. gentoo-sources no publica releases -rc.
+notar que deben informar de la misma al equipo de desarrollo en el bugzilla
+del núcleo directamente. gentoo-sources no publica releases -rc.
</p>
</body>
@@ -592,10 +630,10 @@
<body>
<p>
-Nos podemos encontrar, mientras recopilamos información, que el usuario esta
-usando módulos/drivers del núcleo que no son parte de los fuentes oficiales
-del núcleo. Un ejemplo de este tipo de paquetes podría ser
-<c>x11-drivers/nvidia-drivers</c>.
+Nos podemos encontrar, mientras recopilamos información, que el
+usuario esta usando módulos/controladores del núcleo que no son
+parte de los fuentes oficiales del núcleo. Un ejemplo de este tipo
+de paquetes podría ser <c>x11-drivers/nvidia-drivers</c>.
</p>
<p>
@@ -638,9 +676,9 @@
normalmente requiere que construya y pruebe aproximadamente 13 núcleos
distintos. Por lo que, a menos que observe que el usuario está
particularmente interesado, debe agotar otras opciones en primer
-lugar. Puede reenviar la incidencia al upstream y después de algunos días,
-si no ha habido ningún progreso, pregúnteles si están considerando hacer una
-bisección.
+lugar. Puede reenviar la incidencia al equipo de desarrollo y después
+de algunos días, si no ha habido ningún progreso, pregúnteles si están
+considerando hacer una bisección.
</p>
<p>
@@ -677,7 +715,7 @@
</chapter>
<chapter>
-<title>Informando de incidencias al upstream</title>
+<title>Informar de incidencias al equipo de desarrollo</title>
<section>
<title>Visión general</title>
@@ -687,28 +725,28 @@
Ha llegado a la conclusión de que parece una incidencia del núcleo, ha
recopilado la información que lo refleja, y es reproducible en el último
núcleo de desarrollo. El siguiente paso es reportar la incidencia al
-upstream.
+equipo de desarrollo.
</p>
<p>
-Hay 2 formas de hacer esto: pidiendo al usuario que informe de la incidencia
-en el bugzilla de núcleo y realizándolo usted mismo, enviando un correo a
-las listas y mantenedores correspondientes.
+Hay dos formas de hacer esto: pidiendo al usuario que informe de
+la incidencia en el bugzilla de núcleo o realizándolo uno mismo,
+enviando un correo a las listas y mantenedores correspondientes.
</p>
<p>
Es muy importante que se lo pongamos fácil a los desarrolladores
-upstream. Cuando informe de incidencias, deje bien claro qué versiones están
-afectadas, mencionando la que no se han modificado (normalmente podemos
-decir "it's present in 2.6.19-gentoo but is also reproducible on unmodified
-2.6.20-rc5").
+del equipo de desarrollo. Cuando informe de incidencias, deje bien claro
+qué versiones son las afectadas, mencionando la que no se han modificado
+(normalmente podemos decir "it's present in 2.6.19-gentoo but is also
+reproducible on unmodified 2.6.20-rc5").
</p>
<p>
Ya que el procedimiento incluye un enlace a la incidencia en el downstream,
-asegúrese de que toda la información es presentada al upstream - no espere
-que ellos hagan clic y lean toda la incidencia del downstream que contiene
-alguún grado de ruido de cualquier forma.
+asegúrese de que toda la información es presentada al equipo de desarrollo,
+no espere que ellos hagan clic y lean toda la incidencia que, de cualquier
+forma contiene algo de ruido.
</p>
<p>
@@ -720,76 +758,89 @@
</section>
<section>
-<title>Informando de incidencias en el bugzilla del núcleo</title>
+<title>Informar de incidencias en el bugzilla del núcleo</title>
<body>
<p>
El bugzilla del núcleo es el primer mecanismo que usamos para informar de
-incidencias al upstream. Realmente, el modo en el que lo hacemos es intentar
-que el usuario cree el informe de la incidencia y nosotros hacemos el
-seguimiento. Este es el proceso que sigo:
+incidencias al equipo de desarrollo. Realmente, el modo en el que lo
+hacemos es intentar que el usuario cree el informe de la incidencia y
+nosotros hacemos el seguimiento. Este es el proceso que sigo:
</p>
<ol>
-<li>Marque la incidenca Gentoo como UPSTREAM y añada "linux-bugzilla-pending" al
-campo "status whiteboard". Cuando haga esto, añada un comentario preguntando
-al usuario que informe de la incidencia al upstream. Deles la URL del
-bugzilla del núcleo, pídales que pongan la URL de la incidencia en la
-incidencia de Gentoo cuando lo hayan hecho, deles algunas indicaciones de lo
-que deben incluir en su informe de incidencia (<uri
-link="https://bugs.gentoo.org/show_bug.cgi?id=164802#c19">por
-ejemplo</uri>).</li>
-<li>Cuando el usuario responda con la URL de la incidencia en el upstream,
-coloque esta URL en el campo URL de la incidencia de Gentoo. Elimine
-"linux-bugzilla-pending" del campo "status whiteboard", y añada
-"watch-linux-bugzilla". Añada un pequeño comentario indicando que estaremos
-pendientes de la incidencia en el upstream.</li>
-<li>Vaya al informe de incidencia en el upstream. Lealo completamente. ¿Olvidó
-el usuario alguna información importante para su descripción? En este caso
-añada un comentario con esa información. Si hay adjuntos que sean de
-utilidad en la incidencia en Gentoo que el usuario no haya anexado a la
-incidencia, añádala usted mismo con una pequeña descripción.</li>
-<li>Añada kernel@gentoo.org a la lista CC. Si el usuario no indica la URL a la
-incidencia en Gentoo en el informe de incidencia de upstream, añada un
-comentario con la URL.</li>
+ <li>
+ Marque la incidencia Gentoo como UPSTREAM y añada
+ "linux-bugzilla-pending" al campo "status whiteboard". Cuando haga
+ esto, añada un comentario preguntando al usuario que informe de la
+ incidencia al equipo de desarrollo. Deles la URL del bugzilla del
+ núcleo, pídales que pongan la URL de la incidencia en la incidencia
+ de Gentoo cuando lo hayan hecho, deles algunas indicaciones de lo
+ que deben incluir en su informe de incidencia (<uri
+ link="https://bugs.gentoo.org/show_bug.cgi?id=164802#c19">por
+ ejemplo</uri>).
+ </li>
+ <li>
+ Cuando el usuario responda con la URL de la incidencia en el equipo de
+ desarrollo, coloque esta URL en el campo URL de la incidencia de Gentoo.
+ Elimine "linux-bugzilla-pending" del campo "status whiteboard", y añada
+ "watch-linux-bugzilla". Añada un pequeño comentario indicando que
+ estaremos pendientes de la incidencia del equipo de desarrollo.
+ </li>
+ <li>
+ Vaya al informe de incidencia en el equipo de desarrollo. Lealo
+ completamente. ¿Olvidó el usuario alguna información importante para su
+ descripción? En este caso, añada un comentario con esa información.
+ Si hay adjuntos que sean de utilidad en la incidencia en Gentoo que
+ el usuario no haya anexado a la incidencia, añádala junto con una
+ pequeña descripción.
+ </li>
+ <li>
+ Añada kernel@gentoo.org a la lista CC. Si el usuario no indica la URL
+ a la incidencia en Gentoo en el informe de incidencia del equipo de
+ desarrollo, añada un comentario con la URL.
+ </li>
</ol>
<p>
Si el usuario no contesta a la petción de abrir la incidencia en el
-upstream, desestime la incidencia como lo haría para otros casos sin
-respuesta. Debido a que cerró la incidencia como UPSTREAM, se caerá de la
-lista de todas formas -- por lo que se continuará el proceso cuando
-respondan con la URL de la incidencia en el upstream. La palabra clave
-linux-bugzilla-pending nos permite medir cuántas incidencias se pierden
-cuando alcanzan este punto, y nos permite hacer un seguimiento.
+equipo de desarrollo, desestime la incidencia como lo haría para otros
+casos sin respuesta. Debido a que cerró la incidencia como UPSTREAM,
+se caerá de la lista de todas formas -- por lo que se continuará el
+proceso cuando respondan con la URL de la incidencia en el equipo de
+desarrollo. La palabra clave linux-bugzilla-pending nos permite medir
+cuántas incidencias se pierden cuando alcanzan este punto, y nos
+permite hacer un seguimiento.
</p>
<p>
-Cuando la incidencia sea actualizada en el upstream, kernel@gentoo.org
-obtendrá el correo con este cambio, y como usted tiene esa dirección el el
-seguimiento de usuarios, podrá verlo también. Cuando la incidencia sea
-corregida, reabra la incidencia en Gentoo con un corto resumen de la
-solución, eliminando la etiqueta "watch-linux-bugzilla".
+Cuando el equipo de desarrollo actualice la incidencia,
+kernel@gentoo.org obtendrá el correo con este cambio, y como tiene
+esa dirección en el seguimiento de usuarios, podrá verlo también.
+Cuando la incidencia sea corregida, reabra la incidencia en Gentoo
+con un corto resumen de la solución, eliminando la etiqueta
+"watch-linux-bugzilla".
</p>
<p>
-Si alguien cierra la incidencia en el upstream sin una solución (por ejemplo
-el usuario no respondió a la petición de información, o la incidencia se
-marcó como inválida), refleje estos cambios en la incidencia en Gentoo:
-marque esta incidencia como CLOSED y elimine la etiqueta
-"watch-linux-bugzilla".
+Si alguien cierra la incidencia en el equipo de desarrollo sin
+una solución (por ejemplo el usuario no respondió a la petición de
+información, o la incidencia se marcó como inválida), refleje
+estos cambios en la incidencia en Gentoo: marque esta incidencia
+como CLOSED y elimine la etiqueta "watch-linux-bugzilla".
</p>
</body>
</section>
<section>
-<title>Enviando informes de incidencia por correo al upstream</title>
+<title>Enviar informes de incidencia por correo al equipo de desarrollo</title>
<body>
<p>
-Será escrito en el futuro. Esto es usado como caso extremo en el que la
-incidencia en el upstream no está teniendo la atención que necesita.
+Será escrito en el futuro. Esto es usado como caso extremo en el
+que la incidencia en el equipo de desarrollo no está teniendo la
+atención que necesita.
</p>
</body>
@@ -805,22 +856,22 @@
<body>
<p>
-Este documento incluye referencias a la manipulación de incidencias en el
-bugzilla de Gentoo (abrir/cerrar/reabrir/reasignar/etc). A menos que sea un
-desarrollador de Gentoo o sea un usuario que ha informado de una incidencia,
-realmente no tendrá acceso a esto.
+Este documento incluye referencias a la manipulación de incidencias
+en el bugzilla de Gentoo (abrir/cerrar/reabrir/reasignar/etc).
+A menos que sea un desarrollador de Gentoo o sea un usuario que ha
+informado de una incidencia, realmente no tendrá acceso a esto.
</p>
<p>
-Si cierta acción ha de ser tomada sobre una incidencia en la que usted no
-tiene permisos, debe preguntar en el canal #gentoo-kernel de IRC para que
-alguien realice la operación. Si no hay respuesta, deje un simple comentario
-sobre la incidencia pidiendo el cambio, por ejemplo. "please close this bug
-as NEEDINFO"
+Si se debe tomar alguna acción sobre una incidencia en la que no se
+tienen permisos, debe preguntar en el canal #gentoo-kernel de IRC
+para que alguien realice la operación. Si no hay respuesta, deje un
+simple comentario sobre la incidencia pidiendo el cambio, por ejemplo.
+"please close this bug as NEEDINFO"
</p>
<p>
-Sé que esto es una lata, pero es sólo temporal. Una vez que haya realizado
+Sé que esto es una lata, pero es solo temporal. Una vez que haya realizado
algunas contribuciones a las incidencias de esta forma, incrementaré sus
permisos de acceso a bugzilla para que pueda realizar estas tareas ustes
solo.
@@ -828,12 +879,12 @@
<p>
El otro aspecto de este problema es la manipulación de incidencias en el
-bugzilla del núcleo upstream. Se necesita hacer esto más que en las bugs de
-Gentoo. Yo personalmente tengo acceso de desarrollador la bugzilla upstream,
-por lo que si se necesita hacer algo (clausura de
-incidencias/reasignación/etc), persígame en IRC. En el futuro podríamos ver
-la posibilidad de tener a más gente con accesoo de desarrollador a esta
-plataforma.
+bugzilla del núcleo del equipo de desarrollo. Se necesita hacer esto más
+que en las incidencias de Gentoo. Yo personalmente tengo acceso de
+desarrollador al bugzilla del equipo de desarrollo, por lo que si se
+necesita hacer algo (clausura de incidencias/reasignación/etc),
+persígame en IRC. En el futuro podríamos ver la posibilidad de tener
+a más gente con acceso de desarrollador a esta plataforma.
</p>
</body>
@@ -844,34 +895,37 @@
<body>
<p>
-Bugzilla tiene un campo de texto de una sola línea llamado "status
-whiteboard" para cada incidencia, en el que es usted libre de poner
-cualquier cosa. Yo lo uso como cierta forma de etiquetado.
+Bugzilla tiene un campo de texto de una sola línea llamado
+"status whiteboard" para cada incidencia, en el que se es
+libre de poner cualquier cosa. Yo lo uso como cierta forma
+de etiquetado.
</p>
<p>
-Si una incidencia está presente en la 2.6.20, pero corregida en la 2.6.21 y
-la corrección no se conoce aún, yo pongo "linux-2.6.21" en el campo "status
-whiteboard". Esto está efectivamente etiquetando la incidencia diciendo
-"este problema desaparece cuando la versión 2.6.21 se publique".
+Si una incidencia está presente en la 2.6.20, pero corregida en la
+2.6.21 y la corrección no se conoce aún, yo pongo "linux-2.6.21"
+en el campo "status whiteboard". Esto está efectivamente etiquetando
+la incidencia diciendo "este problema desaparece cuando la versión
+2.6.21 se publique".
</p>
<p>
Si la incidencia es una regresión de la 2.6.21, yo escribo
-"linux-2.6.21-regression" en el campo "status whiteboard". De hecho esto se
-usa en una de las búsquedas almacenadas mencionadas anteriormente. Si la
-incidencia es una regresión pero la versión que introdujo la incidencia es
-desconocida (por ejemplo, funciona en la 2.6.16, pero en la 2.6.20 no), yo
-coloco "linux-2.6.??-regression" en el "whiteboard". Para regresiones,
-también prefijo el campo "summary" con (por ejemplo) <c>[2.6.21
-regression]</c>, de este modo las cosas se ven rápidamente en los resultados
-de la búsqueda.
+"linux-2.6.21-regression" en el campo "status whiteboard". De hecho
+esto se usa en una de las búsquedas almacenadas mencionadas
+anteriormente. Si la incidencia es una regresión pero la versión que
+introdujo la incidencia es desconocida (por ejemplo, funciona en la
+2.6.16, pero en la 2.6.20 no), yo escribo "linux-2.6.??-regression"
+en el "whiteboard". Para regresiones, también prefijo el campo
+"summary" con (por ejemplo) <c>[2.6.21 regression]</c>, de este
+modo las cosas se ven rápidamente en los resultados de la búsqueda.
</p>
<p>
-Si la incidencia ha sido reportada upstream, coloco la URL de la incidencia
-en el campo URL, y "watch-linux-bugzilla" en el campo "status
-whiteboard". Esto se usa en una de las búsquedas almacenadas.
+Si la incidencia ha sido reportada al equipo de desarrollo, escribo
+la URL de la incidencia en el campo URL, y "watch-linux-bugzilla"
+en el campo "status whiteboard". Esto se usa en una de las búsquedas
+almacenadas.
</p>
</body>
@@ -889,9 +943,9 @@
</p>
<p>
-Se cierra entonces la incidencia con un mensaje apropiado cuando una nueva
-release del núcleo (incorporando la corrección) se añade la árbol de
-portage.
+Se cierra entonces la incidencia con un mensaje apropiado cuando una
+nueva release del núcleo (incorporando la corrección) se añade al árbol
+de portage.
</p>
</body>
@@ -908,19 +962,27 @@
<body>
<ul>
-<li>Esta sección esta pensada para describir el proceso únicamente a
-desarrolladores del núcleo (en lugar de para los futuros), pero si está
-realmente interesado, no dude en preguntar en IRC si quisiera enviar un
-parche.</li>
-<li>El parche debe ajustarse a las reglas del núcleo estable, mire en
-Documentation/stable_kernel_rules.txt</li>
-<li>El parche debe ser enviado a por lo menos una release gentoo-sources. La
-razón para esto es que en algún momento, los parches grabados en genpatches
-no están probados -- la comprobación completa se lleva a cabo antes de su
-publicación.</li>
-<li>El parche no debe estar ya presente en la cola stable. Compruebe la <uri
-link="http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=tree">interfaz
-web de stable-queue.git</uri>.</li>
+ <li>
+ Esta sección esta pensada para describir el proceso únicamente a
+ desarrolladores del núcleo (en lugar de para los futuros), pero si está
+ realmente interesado, no dude en preguntar en IRC si quisiera enviar un
+ parche.
+ </li>
+ <li>
+ El parche debe ajustarse a las reglas del núcleo estable, mire en
+ Documentation/stable_kernel_rules.txt
+ </li>
+ <li>
+ El parche debe ser enviado a por lo menos una release gentoo-sources.
+ La razón para esto es que en algún momento, los parches grabados en
+ genpatches no están probados -- la comprobación completa se lleva a
+ cabo antes de su publicación.
+ </li>
+ <li>
+ El parche no debe estar ya presente en la cola stable. Compruebe la <uri
+ link="http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=tree">
+ interfaz web de stable-queue.git</uri>.
+ </li>
</ul>
</body>
@@ -935,19 +997,27 @@
</p>
<ul>
-<li>Dirigido a stable@kernel.org</li>
-<li>CC kernel@gentoo.org</li>
-<li>CC al autor del parche, cuyos datos de contacto se pueden encontrar en el
-propio parche</li>
-<li>Use el mismo asunto que el presente en el parche, prefíjelo con [PATCH] si
-no lo está ya.</li>
-<li>En el cuerpo del mensaje, incluya una breve descripción con una referencia
-al informe de incidencia de Gentoo, por ejemplo: "This patch fixes a bootup
-crash in the snd-intel-hda driver as detailed at
-http://bugs.gentoo.org/12345"</li>
-<li><e>Adjunte</e> el parche al mensaje, directamente desde genpatches. El
-parche debe venir de gitweb o similar y tener los detalles de autoría,
-commit ID, etc.</li>
+ <li>Dirigido a stable@kernel.org</li>
+ <li>CC kernel@gentoo.org</li>
+ <li>
+ CC al autor del parche, cuyos datos de contacto se pueden encontrar en el
+ propio parche
+ </li>
+ <li>
+ Use el mismo asunto que el presente en el parche, prefíjelo con [PATCH] si
+ no lo está ya.
+ </li>
+ <li>
+ En el cuerpo del mensaje, incluya una breve descripción con una
+ referencia al informe de incidencia de Gentoo, por ejemplo:
+ "This patch fixes a bootup crash in the snd-intel-hda driver as
+ detailed at http://bugs.gentoo.org/12345"
+ </li>
+ <li>
+ <e>Adjunte</e> el parche al mensaje, directamente desde genpatches. El
+ parche debe venir de gitweb o similar y tener los detalles de autoría,
+ commit ID, etc.
+ </li>
</ul>
</body>
@@ -962,25 +1032,25 @@
<p>
Eche un vistazo a algunos informes de incidencia de las búsquedas
almacenadas configuradas anteriormente. Si puede contribuir de forma
-directa, adelante. Sin embargo, lo normal es que no esté seguro de qué hacer
-a continuación. Por lo tanto, tome una incidencia, y pregúntenos acerca de
-ella, preferiblemente en el canal #gentoo-kernel de IRC. Alternativamente,
-puede escribir a la lista de correo gentoo-kernel.
+directa, adelante. Sin embargo, lo normal es que no esté seguro de qué
+hacer a continuación. Por lo tanto, tome una incidencia, y pregúntenos
+acerca de ella, preferiblemente en el canal #gentoo-kernel de IRC.
+Alternativamente, puede escribir a la lista de correo gentoo-kernel.
</p>
<p>
Puede parecer que muchas de las incidencias abiertas estén en buenas manos
esperando por el usuario o algo así. Sin embargo, por favor esté cerca, ¡ya
-que siempre tenemos un flujo contínuo de nuevas incidencias!
+que siempre tenemos un flujo continuo de nuevas incidencias!
</p>
<p>
-Aunque este documento le ha presentado lo procesos, puede que no se sienta
-capaz de meterse en los problemas y resolver incidencias. ¡Eso está bien!
-Porque usted está en nuestra lista de seguimiento de kernel@gentoo.org,
-usted verá las incidencias según entran. Antes o después será capaz de hacer
-las mismas actividades que nosotros en otras incidencias, ¡y usted estará en
-el camino!
+Aunque este documento le ha presentado lo procesos, puede que no se
+sienta capaz de meterse en los problemas y resolver incidencias.
+¡Eso está bien! Porque está en nuestra lista de seguimiento de
+kernel@gentoo.org, y verá las incidencias según entran.
+Antes o después podrá hacer las mismas actividades que nosotros
+en otras incidencias, y ¡estará en el camino!
</p>
<p>
@@ -990,6 +1060,5 @@
</body>
</section>
</chapter>
-
</guide>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/kernel: maintenance.xml
@ 2013-08-30 15:43 JosA MarAa Alonso (nimiux)
0 siblings, 0 replies; 7+ messages in thread
From: JosA MarAa Alonso (nimiux) @ 2013-08-30 15:43 UTC (permalink / raw
To: gentoo-commits
nimiux 13/08/30 15:43:14
Modified: maintenance.xml
Log:
Kernel project pages have been moved to the Gentoo Wiki.
Revision Changes Path
1.7 xml/htdocs/proj/es/kernel/maintenance.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.7&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?rev=1.7&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml?r1=1.6&r2=1.7
Index: maintenance.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/es/kernel/maintenance.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- maintenance.xml 26 May 2013 18:47:06 -0000 1.6
+++ maintenance.xml 30 Aug 2013 15:43:14 -0000 1.7
@@ -5,7 +5,7 @@
1.16 2006/07/23 12:27:14 neysx Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<guide lang="es">
+<guide redirect="https://wiki.gentoo.org/wiki/Project:Kernel/Maintenance" lang="es">
<title>Guía de los Mantenedores del Núcleo Linux Gentoo</title>
<author title="Autor">
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-08-30 15:43 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-30 14:04 [gentoo-commits] gentoo commit in xml/htdocs/proj/es/kernel: maintenance.xml John Christian Stoddart (chiguire)
-- strict thread matches above, loose matches on Subject: below --
2013-08-30 15:43 JosA MarAa Alonso (nimiux)
2013-05-26 18:47 JosA MarAa Alonso (nimiux)
2012-10-28 15:21 Sven Vermeulen (swift)
2010-05-24 19:50 JosA MarAa Alonso (nimiux)
2008-11-28 12:48 John Christian Stoddart (chiguire)
2008-11-25 14:58 John Christian Stoddart (chiguire)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox