diff options
Diffstat (limited to 'documentation/content/es/articles/pr-guidelines/_index.adoc')
| -rw-r--r-- | documentation/content/es/articles/pr-guidelines/_index.adoc | 252 |
1 files changed, 128 insertions, 124 deletions
diff --git a/documentation/content/es/articles/pr-guidelines/_index.adoc b/documentation/content/es/articles/pr-guidelines/_index.adoc index 8f22947060..39f0c4d396 100644 --- a/documentation/content/es/articles/pr-guidelines/_index.adoc +++ b/documentation/content/es/articles/pr-guidelines/_index.adoc @@ -1,12 +1,16 @@ --- -title: Guía para el manejo de informes de problemas authors: - - author: Dag-Erling Smørgrav - - author: Hiten Pandya + - + author: 'Dag-Erling Smørgrav' + - + author: 'Hiten Pandya' +description: 'Estas directrices describen las prácticas recomendadas para los Informes de Problemas de FreeBSD (Problem Reports o PRs).' +tags: ["PR", "guideline", "bugs", "maintenance", "BugZilla", "FreeBSD"] +title: 'Guía para el Manejo de Informes de Problemas' trademarks: ["freebsd", "general"] --- -= Guía para el manejo de informes de problemas += Guía para el Manejo de Informes de Problemas :doctype: article :toc: macro :toclevels: 1 @@ -40,7 +44,7 @@ endif::[] [.abstract-title] Resumen -Esta guía describe las prácticas recomendadas para manejar los informes de problemas (PRs) de FreeBSD. Aunque se desarrolló para el FreeBSD PR database maintenance team mailto:freebsd-bugbusters@FreeBSD.org[freebsd-bugbusters@FreeBSD.org], cualquiera que trabaje con PRs de FreeBSD debe seguir estas pautas. +Esta guía describe las prácticas recomendadas para manejar los Informes de Problemas (PRs) de FreeBSD. Aunque se desarrolló para el FreeBSD PR Database Maintenance Team mailto:freebsd-bugbusters@FreeBSD.org[freebsd-bugbusters@FreeBSD.org], cualquiera que trabaje con PRs de FreeBSD debe seguir estas pautas. ''' @@ -49,58 +53,56 @@ toc::[] [[intro]] == Introducción -Bugzilla es un sistema de gestión de errores que utiliza el proyecto FreeBSD. El seguimiento preciso de los defectos de software pendientes es importante para la calidad de FreeBSD. Del mismo modo, el uso correcto del software es esencial para el progreso del proyecto. +Bugzilla es un sistema de gestión de errores utilizado por el proyecto FreeBSD. Un seguimiento preciso de los defectos de software pendientes es importante para la calidad de FreeBSD, el uso correcto del software es esencial para el progreso del Proyecto. -El acceso a Bugzilla está abierto a toda la comunidad de FreeBSD. Se han establecido ciertas pautas para cubrir aspectos comunes de la gestión de errores como la presentación del seguimiento, la gestión de solicitudes de cierre, etc con el fin de mantener la coherencia dentro de la base de datos y proporcionar una experiencia de usuario consistente. +El acceso a Bugzilla está disponible para toda la comunidad de FreeBSD. Con el fin de mantener la coherencia dentro de la base de datos y proporcionar una experiencia de usuario consistente, se han establecido pautas que cubren aspectos comunes de la gestión de errores, como la presentación del seguimiento, el manejo de las solicitudes de cierre, etc. [[pr-lifecycle]] -== Ciclo de vida de un informe de problemas +== Ciclo de Vida de un Informe de Problemas -* El usuario envía un informe de error al sitio web. El error está en el estado `Needs Triage`. -* Jane Random BugBuster confirma que el error reportado contiene la suficiente información para ser reproducido. Si no, se interactuará repetidamente con el usuario hasta obtener la información necesaria. En este punto el error se establece en el estado `Open`. -* Joe Random Committer se interesa por el PR y se lo asigna a si mismo, o Jane Random BugBuster decide que Joe es la persona más adecuada para resolver el problema y le asigna el error. El error se debe poner en el estado `In Discussion`. +* El Usuario (Reporter) envía un informe de error a través del sitio web. El bug se encuentra en el estado `Needs Triage`. +* Jane Random BugBuster confirma que el error reportado tiene la suficiente información para ser reproducido. Si no, se interactuará repetidamente con el usuario para obtener la información necesaria. En este punto, el error se establece en el estado `Open`. +* Joe Random Committer se interesa por el PR y se lo asigna a sí mismo, o Jane Random BugBuster decide que Joe es la persona más adecuada para resolver el problema y se lo asigna. El error se debe poner en el estado `In Discussion`. * Joe tiene una breve conversación con el usuario que ha enviado el informe del problema (asegurándose de que todo queda registrado) y determina la causa. -* Joe está toda la noche trabajando y elabora un parche que cree que soluciona el problema y lo envía en un follow-up, pidiéndole al usuario que lo ha reportado que lo pruebe. A continuación fija el estado del PR en `Patch Ready`. -* Un par de interaciones más tarde tanto Joe como el usuario que lo ha creado están satisfechos con el parche y Joe realiza el commit a `-CURRENT` (o directamente a `-STABLE` si el problema no existe en `-CURRENT`), asegurándose de hacer referencia al informe de problemas en su log del commit (y dando el crédito al usuario si envió todo o parte del parche) y, si corresponde, iniciará una cuenta atrás de MFC. El error se fija en el estado `Needs MFC`. -* Si el parche no necesita pasar por un MFC Joe cierra el PR con el estado `Issue Resolved`. +* Joe trabaja toda la noche y confecciona un parche que cree que soluciona el problema, y lo envía de nuevo, pidiendo al usuario que lo pruebe. Luego establece el estado del PR a `Patch Ready`. +* Un par de iteraciones más tarde, tanto Joe como el usuario que lo ha creado están satisfechos con el parche, y Joe realiza el commit a `-CURRENT` (o directamente a `-STABLE` si el problema no existe en `-CURRENT`), asegurándose de hacer referencia al informe de problemas en su mensaje de commit (y dando el crédito al usuario si envió todo o parte del parche) y, si corresponde, iniciará una cuenta atrás de MFC. El error cambia al estado `Needs MFC`. +* Si no se necesita integrar el parche desde current (MFC), Joe cierra el PR y lo marca con `Issue Resolved`. [NOTE] ==== -Muchos PRs se envían con muy poca información sobre el problema y algunos son muy complejos de resolver, o simplemente arañan la superficie de un problema mayor; en estos casos es muy importante conseguir toda la información necesaria para resolver el problema. Si el problema no se puede resolver o si el problema se repite, es necesario volver a abrir el PR. +Muchos PRs son enviados con muy poca información sobre el problema, y algunos son muy complejos de resolver, o simplemente arañan la superficie de un problema mayor; en estos casos, es muy importante obtener toda la información necesaria para resolver el problema. Si el problema no se puede resolver, o si ha ocurrido nuevamente, es necesario volver a abrir el PR. ==== [[pr-states]] -== Estados de los informes de problemas +== Estados de los Informes de Problemas -Es importante actualizar el estado de un PR cuando se llevan a cabo ciertas acciones. +Es importante actualizar el estado de un PR cuando se realizan ciertas acciones. El estado debe reflejar con precisión la situación actual del trabajo en el PR. -.Un ejemplo simple de cuándo cambiar el estado de un PR. +.Un pequeño ejemplo de cuándo cambiar el estado de un PR [example] ==== - -Cuando un PR se haya gestionado y el/los desarrollador/es estén satisfechos con la solución se envia un follow-up al PR y su estado cambiará a "feedback". En este punto el usuario que lo ha creado debe evaluar la solución en su contexto y responder indicando si el defecto ha sido solucionado. +Cuando un PR ha sido tratado y el desarrollador/es se sienta cómodo con la solución, enviará un follow-up al PR y cambiará su estado a "feedback". En este punto, el usuario que lo ha creado debe evaluar la solución en su contexto y responder indicando si el defecto ha sido solucionado. ==== -Un informe de problemas puede estar en uno de los siguientes estados: +Un Informe de Problema puede estar en uno de los siguientes estados: -[.glosslist] -open:: -Estado inicial: el problema ha sido reportado y necesita ser revisado. +Abierto:: +Estado inicial; el problema ha sido indicado y necesita ser revisado. -analyzed:: -El problema consta como revisado y se está buscando una solución. +Analizado:: +El problema ha sido revisado y se está buscando una solución. -feedback:: -Hay que realizar trabajos adicionales que requieren más información del usuario o de la comunidad; es posible que haga falta también más información sobre la solución propuesta. +Comentarios:: +Hay que realizar trabajo adicional que requiere información adicional del usuario o de la comunidad; posiblemente información sobre la solución propuesta. -patched:: -Se ha realizado un commit con el parche, pero aún hay algo pendiente (MFC o tal vez confirmación del usuario que lo creó). +Parcheado:: +Se ha realizado un commit con el parche, pero aún hay algo pendiente (MFC, o tal vez confirmación del usuario que lo creó). -suspended:: -No se está trabajando en el problema debido a la falta de información o recursos. Este es un candidato excelente para alguien que esté buscando un proyecto. Si el problema no se puede resolver se cerrará en lugar de suspenderse. El proyecto de documentación utiliza suspended para los elementos de la wish-list que implican una cantidad significativa de trabajo para el cual nadie dispone de tiempo. +Suspendido:: +No se está trabajando en el problema debido a la falta de información o recursos. Este es un candidato excelente para alguien que está buscando un proyecto. Si el problema no se puede resolver, se cerrará, en lugar de suspenderse. El proyecto de documentación utiliza suspendido para los elementos de la lista de deseos que implican una cantidad significativa de trabajo para el cual nadie tiene tiempo actualmente. -closed:: -Un informe de problemas se cierra cuando se han integrado, documentado y probado los cambios o cuando se abandona la solución del problema. +Cerrado:: +Un informe de problemas se cierra cuando se han integrado, documentado y probado los cambios, o cuando se abandona la solución del problema. [NOTE] ==== @@ -108,9 +110,9 @@ El estado "patched" está directamente relacionado con el feedback, por lo que p ==== [[pr-types]] -== Tipos de informes de problemas +== Tipos de Informes de Problemas -Al tratar con informes de problemas, ya sea como desarrollador que tiene acceso directo a la base de datos de informes de problemas o como colaborador que navega por la base de datos y envía follow-ups con parches, comentarios, sugerencias o solicitudes de cambio, va a encontrarse usted con distintos tipos de PRs. +Al tratar con informes de problemas, ya sea como desarrollador que tiene acceso directo a la Base de Datos de Informes de Problemas o como colaborador que navega por la base de datos y envía follow-ups con parches, comentarios, sugerencias o solicitudes de cambio, encontrará varios tipos diferentes de PRs. * <<pr-unassigned>> * <<pr-assigned>> @@ -123,20 +125,21 @@ Las siguientes secciones describen para qué se usa cada tipo de PRs, cuándo un [[pr-unassigned]] == PRs sin asignar -Cuando los PRs llegan se asignan en primer lugar a un responsable genérico (placeholder). Estos siempre tienen el prefijo `freebsd-`. El valor exacto para este patrón depende de la categoría. En la mayoría de los casos corresponde a una lista de correo específica de FreeBSD. Esta es una lista actualizada con los más comunes en primer lugar: +Cuando los PRs llegan, inicialmente se asignan a un responsable genérico (placeholder). Estos siempre tienen el prefijo `freebsd-`. El valor exacto para este patrón depende de la categoría; en la mayoría de los casos, corresponde a una lista de correo específica de FreeBSD. Aquí está la lista actual, con las más comunes primero: + [[default-assignees-common]] -.Asignaciones predeterminadas -- más comunes +.Asignaciones Predeterminadas — más comunes [cols="1,1,1", options="header"] |=== | Tipo | Categorías -| Asignación predeterminada +| Asignaciones Predeterminadas |sistema base |bin, conf, gnu, kern, misc |freebsd-bugs -|arquitectura específica +|específico de una arquitectura |alpha, amd64, arm, i386, ia64, powerpc, sparc64 |freebsd-_arch_ @@ -144,36 +147,36 @@ Cuando los PRs llegan se asignan en primer lugar a un responsable genérico (pla |ports |freebsd-ports-bugs -|documentación enviada junto con el sistema +|documentación entregada con el sistema |docs |freebsd-doc -|páginas web de FreeBSD (sin incluir docs) -|sitio web +|Páginas web de FreeBSD (sin incluir docs) +|Website |freebsd-www |=== [[default-assignees-other]] -.Asignaciones predeterminadas -- otros +.Asignaciones Predeterminadas — otros [cols="1,1,1", options="header"] |=== | Tipo | Categorías -| Asignación predeterminada +| Asignaciones Predeterminadas -|labores de promoción -|promoción +|esfuerzos de apoyo y promoción +|advocacy |freebsd-advocacy -|problemas con la Java Virtual Machine(TM) +|Problemas de la Máquina Virtual de Java (Java Virtual Machine(TM)) |java |freebsd-java |cumplimiento de estándares -|estándares +|standards |freebsd-standards -|bibliotecas de threading +|librerías de hilos |threads |freebsd-threads @@ -182,28 +185,29 @@ Cuando los PRs llegan se asignan en primer lugar a un responsable genérico (pla |freebsd-usb |=== -Es bastante habitual que el usuario responsable del PR lo asigne a la categoría incorrecta. Si usted corrige la categoría recuerde por favor que hay que corregir también la asignación. Nuestros usuarios parecen tener dificultades en particular con el hecho de que aunque su problema ocurra en un sistema i386 podría afectar a todas las plataformas de FreeBSD y por lo tanto ser más adecuado para `kern`. Lo contrario también sucede, por supuesto. +No te sorprendas al descubrir que el usuario responsable del PR lo ha asignado a la categoría incorrecta. Si corriges la categoría, no te olvides de corregir también la asignación. (En particular, nuestros usuarios parecen tener dificultades para entender que aunque su problema ocurra en un sistema i386, podría ser genérico de todo FreeBSD y, por lo tanto, ser más adecuado para `kern`. Lo contrario también es cierto, por supuesto.) -Cualquiera puede reasignar estos PR de sus responsables genéricos a otra persona en grupo. Hay varios tipos de responsables: listas de correo especializadas, alias de correo (utilizados para asuntos muy específicos) de interés limitado) e individuos. +Algunos PRs pueden ser reasignados lejos de estos responsables genéricos por cualquier persona. Hay varios tipos de responsables: listas de correo especializadas; alias de correo (utilizados para ciertos casos de interés limitado); y los individuos particulares. -Para los responsables que son listas de correo utilice la designación larga al realizar la asignación: por ejemplo, `freebsd-foo` en lugar de `foo`. Así evitará los correos electrónicos duplicados enviados a las listas de distribución. +Para los responsables que son listas de correo, utiliza la designación larga al realizar la asignación (por ejemplo, `freebsd-foo` en lugar de `foo`); esto evitará los mensajes de correo electrónico duplicados enviados a la lista de correo. [NOTE] ==== -Como la lista de personas que se han ofrecido voluntarias para ser los responsables predeterminados para ciertos tipos de PRs cambia con bastante frecuencia es mucho más adecuado recurrir a la https://wiki.freebsd.org/AssigningPRs[wiki de FreeBSD]. +Como la lista de individuos que se han prestado voluntarios a ser los responsables por defecto de varios tipos de PR cambia tan frecuentemente, es mucho más útil para https://wiki.freebsd.org/AssigningPRs[la wiki de FreeBSD]. ==== -A continuación hay un listado con ejemplos de dichas entidades. Es probable que el listado no sea exhaustivo. +Aquí hay un listado de ejemplo de dichas entidades; probablemente no esté completo. + [[common-assignees-base]] -.Responsables comunes -- sistema base +.Responsables Comunes — sistema base [cols="1,1,1,1", options="header"] |=== | Tipo -| Categoría sugerida -| Responsable sugerido -| Tipo de responsable +| Categoría Sugerida +| Responsable Sugerido +| Tipo de Responsable -|problema específico de la arquitectura ARM(R). +|problema específico de la arquitectura ARM(R) |arm |freebsd-arm |lista de correo @@ -218,27 +222,27 @@ A continuación hay un listado con ejemplos de dichas entidades. Es probable que |freebsd-ppc |lista de correo -|problema con la interfaz avanzada de configuración y energía (man:acpi[4]) +|problema con la Configuración Avanzada y Gestión de Energía (man:acpi[4]) |kern |freebsd-acpi |lista de correo -|problema con los controladores del modo de transferencia asíncrono (ATM) +|problemas con los controladores del Modo de Transferencia Asíncrono (ATM) |kern |freebsd-atm |lista de correo -|problemas con sistemas FreeBSD embebidos o de small-footprint (por ejemplo, NanoBSD/PicoBSD/FreeBSD-arm) +|problema con sistemas FreeBSD embebidos o de pocos recursos (por ejemplo, NanoBSD/PicoBSD/FreeBSD-arm) |kern |freebsd-embedded |lista de correo -|problema con los controladores de FireWire(R) +|problema con controladores de FireWire(R) |kern |freebsd-firewire |lista de correo -|problema con el código fuente del sistema de archivos +|problema con el código del sistema de ficheros |kern |freebsd-fs |lista de correo @@ -253,7 +257,7 @@ A continuación hay un listado con ejemplos de dichas entidades. Es probable que |freebsd-ipfw |lista de correo -|problema con los controladores de la red digital de servicios integrados (ISDN) +|problema con los drivers de Redes Digitales de Servicios Integrados (ISDN) |kern |freebsd-isdn |lista de correo @@ -268,7 +272,7 @@ A continuación hay un listado con ejemplos de dichas entidades. Es probable que |freebsd-emulation |lista de correo -|problema con el stack de red +|problema con la pila de red |kern |freebsd-net |lista de correo @@ -288,7 +292,7 @@ A continuación hay un listado con ejemplos de dichas entidades. Es probable que |freebsd-multimedia |lista de correo -|problema con el subsistema y controladores wireless man:wlan[4] +|problema con el subsistema man:wlan[4] y controladores wireless |kern |freebsd-wireless |lista de correo @@ -298,141 +302,141 @@ A continuación hay un listado con ejemplos de dichas entidades. Es probable que |freebsd-sysinstall |lista de correo -|problema con los scripts de inicio del sistema (man:rc[8]) +|problema con los scripts de arranque del sistema (man:rc[8]) |kern |freebsd-rc |lista de correo -|problema con la funcionalidad VIMAGE o VNET y el código relacionado +|problema relacionado con el código y la funcionalidad de VIMAGE o VNET |kern |freebsd-virtualization |lista de correo -|problema con la emulación de Xen +|problema con la emulación Xen |kern |freebsd-xen |lista de correo |=== [[common-assignees-ports]] -.Responsables comunes -- coleción de ports +.Responsables Comunes — Colección de Ports [cols="1,1,1,1", options="header"] |=== | Tipo -| Categoría sugerida -| Responsable sugerido -| Tipo de responsable +| Categoría Sugerida +| Responsable Sugerido +| Tipo de Responsable -|problema con el framework de ports (¡__no__ con un port en concreto!) +|problema con la infraestructura de ports (__no__ con un port individual) |ports |portmgr |alias -|port mantenido por apache@FreeBSD.org +|port que está mantenido por apache@FreeBSD.org |ports |apache |lista de correo -|port mantenido por autotools@FreeBSD.org +|port que es mantenido por autotools@FreeBSD.org |ports |autotools |alias -|port mantenido por doceng@FreeBSD.org +|port que es mantenido por doceng@FreeBSD.org |ports |doceng |alias -|port mantenido por eclipse@FreeBSD.org +|port que es mantenido por eclipse@FreeBSD.org |ports |freebsd-eclipse |lista de correo -|port mantenido por gecko@FreeBSD.org +|port que es mantenido por gecko@FreeBSD.org |ports |gecko |lista de correo -|port mantenido por gnome@FreeBSD.org +|port que es mantenido por gnome@FreeBSD.org |ports |gnome |lista de correo -|port mantenido por hamradio@FreeBSD.org +|port que es mantenido por hamradio@FreeBSD.org |ports |hamradio |alias -|port mantenido por haskell@FreeBSD.org +|port que es mantenido por haskell@FreeBSD.org |ports |haskell |alias -|port mantenido por java@FreeBSD.org +|port que es mantenido por java@FreeBSD.org |ports |freebsd-java |lista de correo -|port mantenido por kde@FreeBSD.org +|port que es mantenido por kde@FreeBSD.org |ports |kde |lista de correo -|port mantenido por mono@FreeBSD.org +|port que es mantenido por mono@FreeBSD.org |ports |mono |lista de correo -|port mantenido por office@FreeBSD.org +|port que es mantenido por office@FreeBSD.org |ports |freebsd-office |lista de correo -|port mantenido por perl@FreeBSD.org +|port que es mantenido por perl@FreeBSD.org |ports |perl |lista de correo -|port mantenido por python@FreeBSD.org +|port que es mantenido por python@FreeBSD.org |ports |freebsd-python |lista de correo -|port mantenido por ruby@FreeBSD.org +|port que es mantenido por ruby@FreeBSD.org |ports |freebsd-ruby |lista de correo -|port mantenido por secteam@FreeBSD.org +|port que es mantenido por secteam@FreeBSD.org |ports |secteam |alias -|port mantenido por vbox@FreeBSD.org +|port que es mantenido por vbox@FreeBSD.org |ports |vbox |alias -|port mantenido por x11@FreeBSD.org +|port que es mantenido por x11@FreeBSD.org |ports |freebsd-x11 |lista de correo |=== -Los PRs relacionados con los ports que tienen un maintainer que es a la vez un committer de ports pueden ser reasignados por cualquiera, pero es importante recordar que no todos los committers de FreeBSD tienen un commit bit de ports, por lo que no puede guiarse únicamente por la dirección de correo electrónico. +Los PRs relacionados con los ports que tienen un mantenedor que es a la vez un committer de ports pueden ser reasignados por cualquiera (pero ten en cuenta que no todo committer de FreeBSD es necesariamente un committer de ports, por lo que no puedes guiarte únicamente por la dirección de correo electrónico.) -En el caso de otros PRs por favor no los reasigne a otros individuos (que no sean usted) a menos que esté seguro de que el responsable realmente quiere estar al tanto del PR. Esto ayudará a evitar situaciones en las que nadie se dedica a solucionar un problema en particular porque todo el mundo implicado asume que el responsable ya está en ello. +Para otros PRs, por favor, no los reasignes a otros individuos (otros que no seas tú mismo), a menos que estés seguro de que el responsable realmente quiere mantenerse al tanto del PR. Esto ayudará a evitar situaciones en las que nadie se dedica a solucionar un problema en particular porque todos asumen que el responsable ya está trabajando en ello. [[common-assignees-other]] -.Responsables comunes -- otros +.Responsables Comunes — Otros [cols="1,1,1,1", options="header"] |=== | Tipo -| Categoría sugerida -| Responsable sugerido -| Tipo de responsable +| Categoría Sugerida +| Responsable Sugerido +| Tipo de Responsable -|problema con la base de datos de PR +|problema con la base de datos de PRs |bin |bugmeister |alias @@ -444,46 +448,46 @@ En el caso de otros PRs por favor no los reasigne a otros individuos (que no sea |=== [[pr-assigned]] -== PRs asignados +== PRs Asignados -Si un PR tiene el campo `responsible` establecido con el nombre de usuario de un desarrollador de FreeBSD significa que el PR se ha entregado a esa persona en particular para que desarrolle sobre él trabajo adicional. +Si un PR tiene el campo `responsible` establecido al nombre de usuario de un desarrollador de FreeBSD, significa que el PR ha sido traspasado a dicho individuo para realizar más trabajo. -Los PRs asignados no deben ser modificados por nadie más que el responsable o el bugmeister. Si tiene algún comentario que hacer al respecto envíe un follow-up. Si por algún motivo cree que el PR debe cambiar de estado o reasignarse envíe un mensaje al responsable. Si el responsable no responde en dos semanas anule la asignación del PR y haga lo que estime conveniente. +Los PRs asignados no deben ser tocados por nadie más que el responsable o el bugmeister. Si tienes comentarios, envía un follow-up. Si, por algún motivo, crees que el PR debe cambiar de estado o ser reasignado, envía un mensaje al responsable. Si el responsable no responde en dos semanas, anula la asignación del PR y haz lo que quieras. [[pr-dups]] -== PRs duplicados +== PRs Duplicados -Si encuentra más de un PR que describe el mismo problema elija el que contiene la mayor cantidad de información útil y cierre los demás indicando claramente el número de PR sustituidos. Si varios PRs contienen información útil que no está repetida envíe toda la información restante en un follow-up, incluidas las referencias a los demás. Cierre después los otros PRs una vez hayan sido completamente reemplazados. +Si encuentras más de un PR que describe el mismo problema, elige el que contiene la mayor cantidad de información útil y cierre los demás, indicando claramente el número de PR sustituidos. Si varios PRs contienen información útil que no está repetida, envía toda la información restante en un follow-up, incluidas las referencias a los demás; luego cierra los otros PRs (que ahora han sido completamente reemplazados). [[pr-stale]] -== PRs obsoletos +== PRs Obsoletos -Un PR se considera obsoleto si no ha sido modificado en más de seis meses. Siga el siguiente procedimiento para gestionar PRs obsoletos: +Un PR se considera obsoleto si no ha sido modificado en más de seis meses. Aplica el siguiente procedimiento para tratar los PRs obsoletos: -* Si el PR contiene suficientes detalles intente reproducir el problema en `-CURRENT` y en `-STABLE`. Si logra reproducir el problema envíe un follow-up detallando sus hallazgos e intente encontrar a alguien a quien asignárselo. Establezca el estado en "analyzed" si ese es el caso. -* Si el PR describe un problema que sabe que es el resultado de un error de uso (configuración incorrecta o de otro tipo) envíe un follow-up que explique qué hizo mal el usuario. Más tarde cierre el PR con el motivo "User error" o "Configuration error". -* Si el PR describe un error que sabe que ha sido corregido tanto en `-CURRENT` como en `-STABLE` ciérrelo con un mensaje que indique cuándo se solucionó en cada rama. -* Si el PR trata de un error que sabe que ha sido corregido en `-CURRENT` pero no en `-STABLE` intente averiguar cuándo espera la persona que lo corrigió ejecutar el MFC, o intente encontrar a alguien más (quizás usted mismo) que pueda hacerlo. Establezca el estado en "patched" y asígnelo a quien quiera que se haya encargado de hacer el MFC. -* En cualquier otro caso solicite al usuario que confirme si el problema persiste en las versiones más recientes. Si el usuario no responde en un mes cierre el PR con la anotación "Feedback timeout". +* Si el PR contiene suficientes detalles, intenta reproducir el problema en `-CURRENT` y `-STABLE`. Si lo consigues, envía un followup detallando tus hallazgos e intenta encontrar a alguien a quien asignárselo. Cambia el estado a "analyzed" si procede. +* Si el PR describe un problema que sabes que es el resultado de un error de uso (configuración incorrecta o de otro tipo), envía un follow-up que explique qué hizo mal el usuario, luego cierra el PR con el motivo "User error" o "Configuration error". +* Si el PR describe un error que sabes que ha sido corregido tanto en `-CURRENT` como en `-STABLE`, ciérralo con un mensaje que indique que ha sido arreglado en cada rama. +* Si el PR describe un error que sabes que ha sido corregido en `-CURRENT`, pero no en `-STABLE`, intenta averiguar cuándo piensa hacer el MFC la persona que lo corrigió, o intenta encontrar a alguien (¿quizás tú mismo?) para hacerlo. Cambia el estado a "patched" y asígnalo a quien vaya a hacer el MFC. +* En otros casos, solicita al usuario que confirme si el problema persiste en las versiones más nuevas. Si el usuario no responde en un mes, cierra el PR con la anotación "Feedback timeout". [[pr-misfiled-notpr]] -== PRs sin errores +== PRs Sin Errores -Los desarrolladores que encuentren PRs que han aparecido ya en http://lists.FreeBSD.org/mailman/listinfo/freebsd-bugs[freebsd-bugs] o alguna otra lista deberían cerrar el PR informando al usuario en un comentario por qué el problema reportado no es realmente un PR y dónde debe publicarse el mensaje. +Los desarrolladores que se encuentran con PRs que parece que deberían haber sido enviados a la {freebsd-bugs} o alguna otra lista deberían cerrar el PR, informando al creador en un comentario que esto no es en realidad un PR y dónde se debería enviar el mensaje. -Las direcciones de correo electrónico que utiliza Bugzilla para recibir los PR se publican en la documentación de FreeBSD y se anuncian y publican en el sitio web. Esto significa que los spammers ya las tienen. +Las direcciones de correo electrónico que utiliza Bugzilla para recibir los PR se han publicado como parte de la documentación de FreeBSD, se han anunciado y se enumeran en el sitio web. Esto significa que los spammers las han encontrado. -Cuando cierre uno de estos PRs, haga lo siguiente: +Cuando cierres uno de estos PRs, haz lo siguiente: -* Establezca el componente en `junk` (en `Supporting Services`). -* Establezca como responsable a `nobody@FreeBSD.org`. -* Establezca el estado en `Issue Resolved`. +* Establece el componente a `junk` (bajo `Supporting Services`). +* Establece Responsible a `nobody@FreeBSD.org`. +* Cambia el estado a `Issue Resolved`. -Establecer la categoría en `junk` indica que no hay contenido útil dentro del PR y ayuda a reducir el desorden en las categorías principales. +Establecer la categoría a `junk` hace evidente que no hay contenido útil en el PR y ayuda a reducir la basura en las categorías principales. [[references]] -== Lecturas adicionales +== Otras Lecturas -Esta es una lista de recursos relevantes para la correcta escritura y procesamiento de informes de problemas. De ninguna manera debe considerarse completa. +Esta es una lista de recursos relacionados con la escritura y procesamiento adecuados de informes de error. No pretende ser una lista completa. -* extref:{problem-reports}[Cómo escribir informes de problemas para FreeBSD] -- directrices para los usuarios que envían un PR. +* extref:{problem-reports}[Cómo Escribir Informes de Error de FreeBSD]-guía para los creadores de PR. |