[gentoo-commits] gentoo commit in xml/htdocs/proj/es/kernel: maintenance.xml

[JosA MarAa Alonso (nimiux)]

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@g.o">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@g.o</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@g.o 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@g.o 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@g.o
-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@g.o 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@××××××.org</li>
-<li>CC kernel@g.o</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@××××××.org</li>
+  <li>CC kernel@g.o</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@g.o,
-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@g.o, 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>