Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Sep 2019 19:36:06 +0000 (UTC)
From:      Sergio Carlavilla Delgado <carlavilla@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r53375 - head/es_ES.ISO8859-1/articles/problem-reports
Message-ID:  <201909051936.x85Ja6Xv000798@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: carlavilla
Date: Thu Sep  5 19:36:06 2019
New Revision: 53375
URL: https://svnweb.freebsd.org/changeset/doc/53375

Log:
  PR: Update the traduction to the article problem-reports
  Approved by: gabor
  Obtained from: The FreeBSD Spanish Documentation Project

Added:
  head/es_ES.ISO8859-1/articles/problem-reports/es_ES.po   (contents, props changed)
Modified:
  head/es_ES.ISO8859-1/articles/problem-reports/Makefile
  head/es_ES.ISO8859-1/articles/problem-reports/article.xml

Modified: head/es_ES.ISO8859-1/articles/problem-reports/Makefile
==============================================================================
--- head/es_ES.ISO8859-1/articles/problem-reports/Makefile	Thu Sep  5 18:56:07 2019	(r53374)
+++ head/es_ES.ISO8859-1/articles/problem-reports/Makefile	Thu Sep  5 19:36:06 2019	(r53375)
@@ -1,15 +1,19 @@
 #
+# The FreeBSD Documentation Project
+# The FreeBSD Spanish Documentation Project
+#
 # $FreeBSD$
-# $FreeBSDes: doc/es_ES.ISO8859-1/articles/problem-reports/Makefile,v 1.1 2004/10/08 23:06:08 carvay Exp $
 #
 # Article: Writing FreeBSD Problem Reports
 
+MAINTAINER=carlavilla@FreeBSD.org
+
 DOC?= article
 
-FORMATS?= html
+FORMATS?= html html-split
 WITH_ARTICLE_TOC?= YES
 
-INSTALL_COMPRESSED?= gz
+INSTALL_COMPRESSED?=gz
 INSTALL_ONLY_COMPRESSED?=
 
 SRCS=	article.xml

Modified: head/es_ES.ISO8859-1/articles/problem-reports/article.xml
==============================================================================
--- head/es_ES.ISO8859-1/articles/problem-reports/article.xml	Thu Sep  5 18:56:07 2019	(r53374)
+++ head/es_ES.ISO8859-1/articles/problem-reports/article.xml	Thu Sep  5 19:36:06 2019	(r53375)
@@ -1,992 +1,413 @@
-<?xml version="1.0" encoding="iso-8859-1"?>
-<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
-	"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">;
-<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="es">
-  <info><title>Cómo enviar informes de problemas de &os;</title>
-     
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">;
+<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:its="http://www.w3.org/2005/11/its" version="5.0" xml:lang="es_ES">
 
-    <pubdate>$FreeBSD$</pubdate>
+  <info>
+    <title>Escribiendo informes de problemas de FreeBSD</title>
 
-
     <legalnotice xml:id="trademarks" role="trademarks">
-      &tm-attrib.freebsd;
-      &tm-attrib.cvsup;
-      &tm-attrib.ibm;
-      &tm-attrib.intel;
-      &tm-attrib.sparc;
-      &tm-attrib.sun;
-      &tm-attrib.general;
+      <para>FreeBSD is a registered trademark of the FreeBSD Foundation.</para>
+      <para>IBM, AIX, OS/2, PowerPC, PS/2, S/390, and ThinkPad are trademarks of International Business Machines Corporation in the United States, other countries, or both.</para>
+      <para>Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.</para>
+      <para>Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.</para>
+      <para>Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the <quote>™</quote> or the <quote>®</quote> symbol.</para>
     </legalnotice>
 
+    <pubdate>$FreeBSD$</pubdate>
+
+    <releaseinfo>$FreeBSD$</releaseinfo>
+
     <abstract>
-     <para>Este artículo describe cómo realizar y enviar
-       informes de errores para el proyecto &os; de la mejor forma
-       posible.</para>
-       &trans.es.jrh;
+      <para>Este artículo describe cómo realizar y enviar informes de problemas para el proyecto FreeBSD de la mejor forma posible.</para>
     </abstract>
 
     <authorgroup>
-      <author><personname><firstname>Dag-Erling</firstname><surname>Sm&oslash;rgrav</surname></personname><contrib>Escrito por </contrib></author>
-    </authorgroup>
+      <author><personname> <firstname>Dag-Erling</firstname> <surname>Smørgrav</surname> </personname> <contrib>Contributed by </contrib></author>
 
-    <releaseinfo>$FreeBSD$</releaseinfo>
+      <author><personname> <firstname>Mark</firstname> <surname>Linimon</surname> </personname></author>
+    </authorgroup>
   </info>
 
   <indexterm><primary>problem reports</primary></indexterm>
 
   <section xml:id="pr-intro">
-    <title>Introducción</title>
+    <title>Introducción</title>
 
-    <para>Una de las experiencias más fustrantes que se pueden
-      experimentar como usuario de software es aquella en la cual el
-      usuario se toma la molestia de rellenar un informe de problemas
-      detallado para observar tras un determinado espacio de tiempo
-      que dicho informe se cierra con una explicación corta y abrupta
-      como <quote>no es un error</quote> o <quote>PR erroneo</quote>.
-      De forma semejante, una de las experiencias más fustrantes que
-      puede experimentar un desarrollador de aplicaciones consiste en
-      verse inundado por una cantidad ingente de informes de errores
-      que en realidad vienen a ser solicitudes de
-      soporte o ayuda, o que contienen poca o ninguna información
-      sobre cúal es el problema y como se puede reproducir.</para>
+    <para>Una de las experiencias más frustrantes que uno puede tener como usuario de software es enviar un informe de problemas solo para que se cierre sumariamente con una explicación breve e inútil como <quote>no es un error</quote> o <quote>PR erróneo</quote>. De manera similar, una de las experiencias más frustrantes que puede experimentar un desarrollador de aplicaciones consiste en verse inundado por una cantidad ingente de informes de problemas que en realidad vienen a ser solicitudes de soporte o ayuda, o que contienen poca o ninguna información sobre cúal es el problema y cómo reproducirlo.</para>
 
-    <para>Este documento intenta describir cómo escribir informes de
-      problemas de calidad. Usted se preguntará cómo se pueden
-      escribir informes de problemas de calidad.  Bien, para ir
-      directos al grano, un informe de problemas de calidad es aquél
-      que se puede analizar y tratar rápidamente, para mútua
-      satisfacción del usuario y del desarrollador.</para>
+    <para>Este documento intenta describir cómo escribir buenos informes de problemas. ¿Qué, se preguntará, es un buen informe de problemas? Bien, para ir directos al grano, un buen informe de problemas es aquél que se puede analizar y tratar rápidamente, para mutua satisfacción del usuario y del desarrollador.</para>
 
-    <para>Aunque el objetivo principal de este artículo se centra en
-      los informes de problemas de &os; la mayoría de los conceptos se
-      pueden aplicar bastante bien en otros proyectos de software.</para>
+    <para>Aunque el objetivo principal de este artículo se centra en los informes de problemas de FreeBSD, la mayoría de los conceptos se pueden aplicar bastante bien en otros proyectos de software.</para>
 
-    <para>Dése cuenta de que este artículo se organiza de forma
-      temática, no cronológicamente, de tal forma que se debe
-      leer el documento íntegro antes de enviar informes
-      de problemas.  No debe tratarse como un tutorial del estilo paso
-      a paso.</para> </section>
+    <para>Tenga en cuenta que este artículo está organizado temáticamente, no cronológicamente. Lea todo el documento antes de enviar un informe de problemas, en lugar de tratarlo como un tutorial paso a paso.</para>
+  </section>
 
   <section xml:id="pr-when">
-    <title>Cuándo enviar informes de problemas</title>
+    <title>Cuándo enviar informes de problemas</title>
 
-    <para>Existen varios tipos de problemas y no todos ellos se
-      merecen la creación de un informe de problemas.  Por supuesto,
-      nadie es perfecto, y existirán ocasiones en las que estaremos
-      convencidos de haber encontrado un <quote>bug</quote> en un programa
-      cuando realmente hemos malinterpretado la sintaxis o el funcionamiento de
-      dicho programa, o simplemente hemos cometido un error
-      tipográfico en un fichero de configuración (aunque en este
-      último caso podría tratarse de un indicador de
-      documentación escasa o que la aplicación peca de una
-      gestión de errores defectuosa.  Incluso
-      teniendo estos aspectos en cuenta existen varios casos en los cuales
-      el envío de un informe de problemas resulta claramente
-      <emphasis>no ser</emphasis> la mejor forma de proceder, ya que dicho
-      envío puede servir para frustrar tanto a quien envía el
-      informe como a quien desarrolló la aplicación.
-      Por el contrario, también existen casos
-      en los que puede resultar apropiado enviar un informe de problemas sobre
-      algo más aparte de <quote>bugs</quote>: una mejora o una solucitud
-      nuevas características, por citar un par de ejemplos.</para>
+    <para>Hay muchos tipos de problemas y no todos ellos merecen la creación de un informe de problemas. Por supuesto, nadie es perfecto, y habrá ocasiones en que lo que parece ser un error en un programa es, de hecho, un malentendido de la sintaxis de un comando o un error tipográfico en un archivo de configuración (aunque en este último caso podría tratarse de un indicador de documentación escasa o que la aplicación peca de una gestión de errores defectuosa). Incluso teniendo estos aspectos en cuenta existen varios casos en los cuales el envío de un informe de problemas resulta claramente <emphasis>no ser</emphasis> la mejor forma de proceder, y solo servirá para frustrar tanto al remitente como a los desarrolladores. Por el contrario, hay casos en los que podría ser apropiado enviar un informe de problemas sobre algo más que un error: una mejora o una nueva característica, por ejemplo.</para>
 
-    <para>Así que ?cómo podemos determinar qué
-      constituye un <quote>bug</quote> y qué no?  Como regla para
-      principiantes podemos decir que su problema
-      <emphasis>no</emphasis> es un <quote>bug</quote> si
-      se puede expresar como una pregunta (normalmente del estilo de
-      <quote>?cómo hago X?</quote> o
-      <quote>?donde puedo encontrar Y?</quote>).  No siempre las
-      cosas son blancas o negras, pero la regla de las preguntas suele
-      cubrir una gran mayoría de casos.  Si lo que se quiere es una
-      respuesta a una consulta, se pueden enviar dichas preguntas a la
-      &a.questions;.</para>
+    <para>Entonces, ¿cómo se determina qué es un error y qué no? Como regla general, el problema <emphasis>no</emphasis> es un error si puede expresarse como una pregunta (normalmente del estilo de <quote>¿Cómo hago X?</quote> o <quote>¿Dónde puedo encontrar Y?</quote>). Las cosas no son siempre blancas o negras, pero la regla de la pregunta cubre la gran mayoría de los casos. Al buscar una respuesta, considere plantear la pregunta a la <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions">lista de correo de preguntas generales de FreeBSD</link>.</para>
 
-    <para>A continuación se muestran algunos casos en los que resulta
-      apropiado enviar un informe de problemas sobre algo que no se
-      considera un <quote>bug</quote>:</para>
+    <para>Tenga en cuenta estos factores al enviar PRs sobre ports u otro software que no sea parte de FreeBSD:</para>
 
     <itemizedlist>
       <listitem>
-	<para>Solucitudes para mejora de características. Normalmente
-	  es una buena idea airear estas propuestas en las listas de
-	  distribución antes de enviar un informe de problemas.</para>
+	<para>Por favor, no envíe informes de problemas que simplemente indiquen la disponibilidad de una nueva versión de una aplicación. Los maintainers de ports son notificados automáticamente por <application>portscout</application> cuando una nueva versión de una aplicación esta disponible. Los parches para actualizar un port a la última versión son bien recibidos.</para>
       </listitem>
 
       <listitem>
-	<para>Notificación de actualizaciones de software que se
-	  mantiene externamente (principalmente ports, pero también
-	  componentes del sistema base al cargo de proyectos independientes
-	  de &os;, como BIND o diversas utilidades GNU)</para>
+	<para>Para los ports que no están mantenidos (el <varname>MAINTAINER</varname> es <literal>ports@FreeBSD.org</literal>), es poco probable que un PR sin un parche adjunto sea cogido por un committer. Para convertirse en el maintainer de un port que no este mantenido, envíe un PR con la petición (sería ideal si viene con un parche adjunto, pero no es necesario).</para>
       </listitem>
+
+      <listitem>
+	<para>En cualquier caso, seguir el proceso descrito en el <link xlink:href="@@URL_RELPREFIX@@/doc/es_ES.ISO8859-1/books/porters-handbook/port-upgrading.html">Manual del Porter</link> dará los mejores resultados. (Es posible que también desee leer <link xlink:href="@@URL_RELPREFIX@@/doc/es_ES.ISO8859-1/articles/contributing/ports-contributing.html">Cómo contribuir a la colección de ports de FreeBSD</link>).</para>
+      </listitem>
     </itemizedlist>
 
-    <para>Otro tema es que si el sistema donde se experimentó el
-      <quote>bug</quote> no está medianamente actualizado se debe
-      considerar muy seriamente su actualización e intentar reproducir
-      el problema en un sistema actualizado antes de emitir el informe.
-      Existen pocas cosas que molesten más a un desarrollador que
-      recibir un informe de problemas sobre un problema que ya ha
-      resuelto.</para>
+    <para>Un error que no se puede reproducir rara vez se podrá arreglar. Si el error solo ocurrió una vez y no puede reproducirlo, y no parece que le ocurra a nadie más, es probable que ninguno de los desarrolladores pueda reproducirlo o descubrir qué es lo que está mal. Eso no significa que no haya ocurrido, significa que las posibilidades de que su informe de problemas lleve a la corrección del error son muy escasas. Para empeorar las cosas, a menudo, este tipo de errores son en realidad causados por fallos en los discos duros o procesadores con sobrecalentamiento, siempre debe intentar descartar estas causas, siempre que sea posible, antes de enviar un PR.</para>
 
-    <para>Por último, un <quote>bug</quote> que no se puede
-      reproducir difícilmente puede arreglarse.  Si el
-      <quote>bug</quote> sólo ocurrió una vez y no somos capaces
-      de reproducirlo, y parece que no le ocurre a nadie más,
-      es muy probable que ni siquiera los desarrolladores puedan
-      reproducirlo y por lo tanto ni siquiera puedan imaginarse qué es
-      lo que falla.  Esto no significa que el <quote>bug</quote> no haya
-      ocurrido, sino que las probabilidades de que nuestro informe de errores
-      sirva para corregir un defecto son muy pequeñas.  Para complicar
-      más las cosas, a menudo estas clases de errores se producen
-      debido a fallos en los discos duros o al sobrecalentamiento del
-      procesador: debe intentar siempre descubrir estos
-      fallos, siempre que sea posible, antes de enviar un PR.</para>
-      </section>
+    <para>A continuación, para decidir a quién debe presentar su informe de problemas, debe comprender que el software que compone FreeBSD está compuesto de varios elementos diferentes:</para>
 
+    <itemizedlist>
+      <listitem>
+	<para>El código en el sistema base que escriben y mantienen los colaboradores de FreeBSD, como el kernel, la biblioteca de C y los controladores de dispositivos (categorizados como <literal>kern</literal>); las utilidades binarias (<literal>bin</literal>); las páginas del manual y documentación (<literal>docs</literal>); y las páginas web (<literal>www</literal>). Todos los errores en estas áreas deben informarse a los desarrolladores de FreeBSD.</para>
+      </listitem>
+
+      <listitem>
+	<para>El código en el sistema base escrito y mantenido por otros, e importado y adaptado a FreeBSD. Los ejemplos incluyen <citerefentry><refentrytitle>clang</refentrytitle><manvolnum>1</manvolnum></citerefentry> y <citerefentry><refentrytitle>sendmail</refentrytitle><manvolnum>8</manvolnum></citerefentry>. La mayoría de los errores en estas áreas deben informarse a los desarrolladores de FreeBSD; pero en algunos casos es posible que deban informarse a los autores originales si los problemas no son específicos de FreeBSD.</para>
+      </listitem>
+
+      <listitem>
+	<para>Las aplicaciones individuales que no están en el sistema base, sino que forman parte de la colección de ports de FreeBSD (categoría <literal>ports</literal>). La mayoría de estas aplicaciones no están escritas por los desarrolladores de FreeBSD; lo que proporciona FreeBSD es simplemente un framework para instalar la aplicación. Por lo tanto, solo informe de un problema a los desarrolladores de FreeBSD cuando crea que el problema es específico de FreeBSD; de lo contrario, repórtelo a los autores del software.</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>Después, averigüe si es un problema puntual. Existen pocas cosas que molesten más a un desarrollador que recibir un informe de problemas sobre un error que ya ha solucionado.</para>
+
+    <para>Si el problema está en el sistema base, primero lea la sección de preguntas frecuentes sobre las <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/faq/introduction.html#LATEST-VERSION">versiones de FreeBSD</link>, si aún no está familiarizado con el tema. FreeBSD no puede solucionar problemas en otras ramas que no sean las más recientes del sistema base, por lo que presentar un informe de error sobre una versión anterior probablemente hará que un desarrollador le aconseje que se actualice a una versión soportada para comprobar si el problema todavía sucede. El equipo Security Officer mantiene <link xlink:href="@@URL_RELPREFIX@@/security/">la lista de versiones soportadas</link>.</para>
+
+    <para>Si el problema está en un port, considere enviar el error al upstream. El proyecto FreeBSD no puede corregir todos los errores en todo el software.</para>
+  </section>
+
   <section xml:id="pr-prep">
     <title>Preparativos</title>
 
-    <para>Una buena regla que se puede seguir consiste en realizar
-      siempre una búsqueda antes de enviar un informe
-      de problemas.  Quizá nuestro problema ya ha sido reportado;
-      quizá se está discutiendo en las listas de
-      distribución o fue discutido hace poco; incluso es posible que
-      se haya arreglado en versiones más recientes del software.
-      Por lo tanto, se deben consultar los sitios y fuentes más obvias
-      antes de proceder con el envío del informe de errores.
-      En &os; esto significa:</para>
+    <para>Una buena regla que se puede seguir consiste en realizar siempre una búsqueda antes de enviar un informe de problemas. Quizá nuestro problema ya ha sido reportado; quizá se está discutiendo en las listas de correo o fue discutido hace poco; incluso puede que ya esté arreglado en una versión más nueva que la que está ejecutando. Por lo tanto, se deben consultar los sitios y fuentes más obvias antes de proceder con el envío del informe de errores. En FreeBSD, esto significa:</para>
 
     <itemizedlist>
       <listitem>
-	<para>Las
-	  <link xlink:href="http://www.freebsd.org/doc/en/books/faq/index.html">Preguntas Más
-<!--
-XXX
-	  <ulink url="&url.books.faq;/index.html">Preguntas Más
--->
-	  Frecuentes</link> (FAQ) de &os;.
-	  Las FAQ intentan proporcionar respuestas para un
-	  amplio rango de dudas, tales como aquellas relacionadas
-	  con las
-<!--
-	  <ulink url="&url.books.faq;/hardware.html">compatibilidades
-	    hardware</ulink>, las
-	  <ulink url="&url.books.faq;/applications.html">aplicaciones
-	  de usuario</ulink> y la
-	  <ulink url="&url.books.faq;/kernelconfig.html">configuración
-	  del kernel</ulink>.
--->
-	  <link xlink:href="http://www.freebsd.org/doc/en/books/faq/hardware.html">compatibilidades
-	      hardware</link>, las
-	  <link xlink:href="http://www.freebsd.org/doc/en/books/faq/applications.html">aplicaciones
-	    de usuario</link> y la
-	  <link xlink:href="http://www.freebsd.org/doc/en/books/faq/kernelconfig.html">configuración
-	    del kernel</link>.</para>
+	<para>La lista de <link xlink:href="@@URL_RELPREFIX@@/doc/es_ES.ISO8859-1/books/faq/index.html">preguntas más frecuentes</link> (FAQ) de FreeBSD. Las preguntas frecuentes intentan proporcionar respuestas a una amplia gama de preguntas, como las relacionadas con la <link xlink:href="@@URL_RELPREFIX@@/doc/es_ES.ISO8859-1/books/faq/hardware.html">compatibilidad del hardware</link>, las <link xlink:href="@@URL_RELPREFIX@@/doc/es_ES.ISO8859-1/books/faq/applications.html">aplicaciones de usuario</link> y la <link xlink:href="@@URL_RELPREFIX@@/doc/es_ES.ISO8859-1/books/faq/kernelconfig.html">configuración del kernel</link>.</para>
       </listitem>
 
       <listitem>
-	<para>Las
-<!--
-	  <ulink
-	    url="&url.books.handbook;/eresources.html#ERESOURCES-MAIL">listas
--->
-	  <link xlink:href="http://www.freebsd.org/doc/en/books/handbook/eresources.html#ERESOURCES-MAIL">listas
-
-	    de correo</link>.  Si no está subscrito utilice
-	  <link xlink:href="http://www.FreeBSD.org/search/search.html#mailinglists">la
-	  búsqueda en los archivos</link> del sitio web de &os;.  Si
-	  el problema no se ha discutido con anterioridad en las
-	  listas, se puede intentar enviar un mensaje y esperar unos
-	  pocos días para ver si alguien puede aconsejarle
-	  adecuadamente sobre algún punto que quizá haya pasado
-	  por alto en relación con el problema.</para>
+	<para>Las <link xlink:href="@@URL_RELPREFIX@@/doc/es_ES.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL">listas de correo</link>, si no está suscrito, utilice la <link xlink:href="https://www.FreeBSD.org/search/search.html#mailinglists">búsqueda en los archivos</link> del sitio web de FreeBSD. Si el problema no se ha discutido con anterioridad en las listas, se puede intentar enviar un mensaje y esperar unos pocos días para ver si alguien puede aconsejarle adecuadamente sobre algún punto que quizá haya pasado por alto en relación con el problema.</para>
       </listitem>
 
       <listitem>
-	<para>Opcionalmente, la web entera&mdash;utilice su motor de
-	  búsqueda favorito para localizar cualquier referencia a su
-	  problema.  Incluso pueden aparecer listas de correo o grupos
-	  de noticias de los cuales ni siquiera tuviera conocimiento
-	  de su existencia o quizá no consideró apropiado
-	  consultarlas al principio.</para> </listitem>
+	<para>Opcionalmente, toda la web: utilice su motor de búsqueda favorito para localizar cualquier referencia al problema. Incluso puede obtener listas de correo archivadas o grupos de noticias que no conocía o en los que no había pensado buscar.</para>
+      </listitem>
 
       <listitem>
-	<para>A continuación, la búsqueda a través de
-	  <link xlink:href="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">;
-	  la base de datos &os; PR</link> (GNATS).  A menos que
-	  nuestro problema sea muy reciente o rebuscado, existe un
-	  gran número de posibilidades de que ya haya sido informado o
-	  reportado.</para>
+	<para>A continuación, la búsqueda a través de la <link xlink:href="https://bugs.freebsd.org/bugzilla/query.cgi">base de datos de PR de FreeBSD</link> (Bugzilla). A menos que el problema sea muy reciente o rebuscado, existe un gran número de posibilidades de que ya haya sido informado o reportado.</para>
       </listitem>
 
       <listitem>
-	<para>Lo más importante, se debería intentar comprobar
-	  si la documentación existente en el código fuente del
-	  programa puede resolver el problema.</para>
+	<para>Lo más importante, se debería intentar comprobar si la documentación existente en el código fuente del programa puede resolver el problema.</para>
 
-	<para>En el caso de las fuentes del sistema &os; debe estudiarse
-	  cuidadosamente el contenido del fichero
-	  <filename>/usr/src/UPDATING</filename> del sistema o su
-	  última versión,  que se encuentra en <uri xlink:href="http://www.FreeBSD.org/cgi/cvsweb.cgi/src/UPDATING">http://www.FreeBSD.org/cgi/cvsweb.cgi/src/UPDATING</uri>.
-	  (Esta información se considera de vital importancia si se
-	  está actualizando de una versión a otra, especialmente
-	  si la actualización se realiza de la versión estable a
-	  la versión &os.current;).</para>
+	<para>Para el código base de FreeBSD, debe estudiar cuidadosamente el contenido del fichero <filename>/usr/src/UPDATING</filename> del sistema o la versión más reciente en <uri xlink:href="https://svnweb.freebsd.org/base/head/UPDATING?view=log">https://svnweb.freebsd.org/base/head/UPDATING?view=log</uri>. (Esta información se considera de vital importancia si se está actualizando de una versión a otra, especialmente si está actualizando a la rama de FreeBSD-CURRENT).</para>
 
-	<para>No obstante, si el problema se encuentra en algo que se
-	  instaló como parte de la collección de ports de &os;,
-	  se debe consultar el archivo
-	  <filename>/usr/ports/UPDATING</filename> (para ports
-	  individuales) o el archivo
-	  <filename>/usr/ports/CHANGES</filename> (para cambios que
-	  afectan a la colección de ports completa).  <uri xlink:href="http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/UPDATING">http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/UPDATING</uri>;
-	  y <uri xlink:href="http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES">http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES</uri>;
-	  también se encuentran disponibles a través de CVSweb.
-	  </para>
-	</listitem>
-      </itemizedlist>
+	<para>No obstante, si el problema se encuentra en algo que se instaló como parte de la colección de ports de FreeBSD, se debe consultar el archivo <filename>/usr/ports/UPDATING</filename> (para ports individuales) o el archivo <filename>/usr/ports/CHANGES</filename> (para cambios que afectan a la colección de ports completa). <uri xlink:href="https://svnweb.freebsd.org/ports/head/UPDATING?view=log">https://svnweb.freebsd.org/port/head/UPDATING?view=log</uri>; y <uri xlink:href="https://svnweb.freebsd.org/ports/head/CHANGES?view=log">https://svnweb.freebsd.org/ports/head/CHANGES?view=log</uri>; también están disponibles a través de svnweb.</para>
+      </listitem>
+    </itemizedlist>
+  </section>
 
-    <para>A continuación debemos asegurarnos de que el informe de
-      errores llega a las personas adecuadas.</para>
-
-    <para>La primera consideración llegados a este punto consiste en:
-      Si el problema resulta ser un bug en un software
-      de terceras partes (un port o un paquete que se ha instalado)
-      se debe informar sobre el bug al autor original del software, no
-      al proyecto &os;.  Existen dos excepciones a esta regla: la
-      primera ocurre cuando el bug no se produce en otras plataformas,
-      en cuyo caso el problema puede residir en cómo fue migrado el
-      software a &os;; la segunda excepción ocurre cuando el autor
-      original ya ha corregido el problema y distribuido un parche o
-      una nueva versión de su software, pero el port de &os;
-      todavía no se ha actualizado.</para>
-
-    <para>La segunda consideración es que el sistema de seguimiento de
-      bugs de &os; ordena los informes de problemas de acuerdo con la
-      categoría que ha seleccionado el informador. De este modo, si se
-      selecciona una categoría incorrecta cuando se envía el
-      informe de problemas, existe una gran probabilidad de que nadie se de
-      cuenta de su existencia durante un período de tiempo indefinido,
-      hasta que alguien se encarge de re-categorizarlo.</para>
-      </section>
-
   <section xml:id="pr-writing">
-    <title>Escribir el informe de problemas</title>
+    <title>Escribiendo el informe de problemas</title>
 
-    <para>Ahora que hemos determinado que el problema que estamos
-      experimentando se merece la redacción de un informe de problemas
-      y que se trata de un problema de &os;, es la hora de comenzar a
-      escribir dicho informe.  Antes de pasar a describir los
-      mecanismos utilizados por el programa encargado de generar los
-      informes PR, vamos a describir una serie de trucos y consejos
-      que nos asegurarán la mayor efectividad posible de nuestro
-      informe.</para>
+    <para>Ahora que ha decidido que su problema merece un informe de problemas y que es un problema de FreeBSD, es el momento de escribir el informe de problemas propiamente dicho. Antes de pasar a describir los mecanismos utilizados por el programa encargado de generar y enviar los PRs, aquí hay algunos consejos y trucos para ayudarle a asegurarse de que su PR sea más efectivo.</para>
 
-    <section>
-      <title>Consejos y trucos para escribir un buen informe de
-      problemas</title>
+    <section xml:id="pr-writing-tips">
+      <title>Consejos y trucos para escribir un buen informe de problemas</title>
 
       <itemizedlist>
 	<listitem>
-	  <para><emphasis>No deje la línea de <quote>Synopsis</quote>
-	    vacía</emphasis>.  Los PRs se dirigen tanto a una lista de
-	    correo mundial (donde se utiliza el campo
-	    <quote>Synopsis</quote> para rellenar la línea
-	    <literal>Subject:</literal> del correo) como a una base
-	    de datos (GNATS).  Cualquier persona que consulte la base
-	    de datos por el campo <literal>sinopsis</literal> y encuentre un
-	    PR con una línea de <literal>Asunto</literal> vacía
-	    tiende simplemente a pasar por alto el informe.  Recuerde que un
-	    PR permanece en la base de datos hasta que alguien se encarga de
-	    cerrar el informe; un informe anónimo normalmente se
-	    perderá para siempre entre el ruido y tardará mucho
-	    en cerrarse.</para>
+	  <para><emphasis>No deje el campo <quote>Summary</quote> vacío.</emphasis> Los PRs se envían a una lista de correo global (donde se utiliza el campo <quote>Summary</quote> para la línea <literal>Subject:</literal>), y se almacenan en una base de datos. Cualquiera que haga una búsqueda por el campo synopsis (sinopsis) en la base de datos y encuentre un PR con la línea del subject (asunto) en blanco tiende a omitirlo. Recuerde que los PR permanecen en esta base de datos hasta que alguien los cierra; un PR que no esté debidamente cumplimentado pasará desapercibido.</para>
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Evite utilizar una línea de
-	    <quote>Synopsis</quote> débil.</emphasis>.  No debe
-	    suponerse que quien lea el PR conoce el contexto adecuado en el
-	    que su mensaje tiene sentido, así que cuanta más
-	    información se proporcione, mejor que mejor.
-	    Por ejemplo, ?qué parte del sistema se ve afectado
-	    por el informe?, ?el problema aparece cuando se está
-	    instalando o cuando se está ejecutando?.  Para
-	    ejemplificar, en lugar de <literal>Synopsis: portupgrade is
-	    broken</literal>, se pueden ver las ventajas que
-	    proporciona una línea como la siguiente:
-	    <literal>Synopsis: port sysutils/portupgrade produce un
-	    coredump en -current</literal>. (En el caso concreto de
-	    los ports, resulta especialmente útil poseer tanto la
-	    categoría como el nombre del port en la línea
-	    <quote>Synopsis</quote>.)</para>
+	  <para><emphasis>Rellene el campo <quote>Summary</quote> correctamente, no use descripciones vagas.</emphasis> No asuma que aquella persona que lea su PR entienda el contexto que motivó su envío, por lo tanto, cuanta más información proporcione, mejor. Por ejemplo, ¿en qué parte del sistema se produce el problema? ¿El problema sucede solo durante la instalación o durante la ejecución del sistema? Por ejemplo, en lugar de, <literal>Summary: portupgrade is broken</literal>, podría utilizar este otro, el cual, tiene mucha más información: <literal>Summary: port ports-mgmt/portupgrade coredumps on -current</literal>. (En el caso de los ports, es especialmente útil tener el nombre de la categoría y el nombre del port en el campo <quote>Summary</quote>).</para>
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Si se dispone de un parche, dígalo.
-	    </emphasis> Un PR con un parche incluido tiene muchas más
-	    posibilidades de ser tratado que uno que no lo tiene. Si
-	    se include dicho parche, escriba la cadena
-	    <literal>[patch]</literal> al comienzo de la línea
-	    <quote>Synopsis</quote>. (Aunque no es obligatorio
-	    utilizar dicha cadena, se trata de un estándar de facto
-	    que se utiliza de forma mayoritaria.)</para>
-
+	  <para><emphasis>Si tiene un parche, dígalo.</emphasis> Es más probable que se analice un PR con un parche incluido que uno sin él. Incluya la palabra clave <literal>patch</literal> en Bugzilla.</para>
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Si es mantenedor del port, dígalo.</emphasis>
-	    Si se está manteniendo el código fuente de una
-	    aplicación (por ejemplo, de un port), se puede
-	    considerar la adición de la cadena
-	    <literal>[maintainer update]</literal> al comienzo de la
-	    línea de sinopsis, y además se debería
-	    asignar el campo <quote>Class</quote> del PR a la cadena
-	    <literal>maintainer-update</literal>. De esta forma
-	    cualquier committer que maneje el PR no tendrá que
-	    realizar comprobaciones.</para> </listitem>
+	  <para><emphasis>Si es un maintainer, dígalo</emphasis>. Si mantiene una parte del código fuente (por ejemplo, un port que ya exista), debe establecer el campo <quote>Class</quote> de su PR a <literal>maintainer-update</literal>. De esta forma, cualquier committer que se ocupe de su PR no tendrá que verificarlo.</para>
+	</listitem>
 
 	<listitem>
-	  <para><emphasis>Sea concreto.</emphasis>
-	    Cuanta más información se proporcione sobre el
-	    problema que se tiene, más posiblidades de obtener una
-	    respuesta.</para>
+	  <para><emphasis>Sea concreto.</emphasis> Cuanta más información se proporcione sobre el problema que tiene, más posibilidades de obtener una respuesta.</para>
 
 	  <itemizedlist>
 	    <listitem>
-	      <para>Incluya la versión del &os; que se está
-		ejecutando (existe un lugar donde escribir esta
-		esta información, vea más abajo) y en
-		qué arquitectura.  Se debe incluir si
-		se está ejecutando desde una release (e.g. desde un
-		CDROM o descarga), o si es desde un sistema mantenido
-		mediante &man.cvsup.1; (y, si esto último se cumple,
-		con qué frecuencia se realiza la actualización).  		Si se está siguiendo la rama &os.current;, se
-		trata de la primera pregunta que nos harán,
-		debido a que los parches (sobre todo para problemas de alto
-		nivel) tienden a aplicarse muy rápidamente, y se espera
-		de los usuarios de &os.current; un seguimiento cercano de
-		las actualizaciones aplicadas.</para> </listitem>
+	      <para>Incluya la versión de FreeBSD que está ejecutando (existe un lugar donde escribir esta información, vea a continuación) y en qué arquitectura. Debe incluir si se está ejecutando desde una release (por ejemplo, desde un <acronym>CD-ROM</acronym> o descarga), o si es desde un sistema mantenido por Subversion (y, si es así, en qué número de revisión se encuentra). Si está usando la rama FreeBSD-CURRENT, esa es la primera pregunta que le harán, porque las correcciones (especialmente para problemas de alto nivel) tienden a aplicarse muy rápidamente, y se espera que los usuarios de FreeBSD-CURRENT se mantengan al día.</para>
+	    </listitem>
 
 	    <listitem>
-	      <para>Incluya qué opciones globales se han especificado
-		en el archivo <filename>make.conf</filename>. Aviso:
-		Es bien conocido por todos que especificar
-		<literal>-O2</literal> y valores superiores para
-		&man.gcc.1; produce fallos y resulta ser proclive a
-		errores en muchas situaciones.  Aunque los
-		desarrolladores de &os; normalmente dan por buenos y
-		aceptan los parches proporcionados por el creador del
-		informe de problemas, normalmente no desean investigar
-		dichas condiciones extrañas debido simplemente a la
-		falta de tiempo y de voluntarios, y puede que
-		respondan diciendo simplemente que dicha opción de
-		compilación no se encuentra soportada.</para>
-		</listitem>
+	      <para>Incluya qué opciones globales ha especificado en sus ficheros <filename>make.conf</filename>, <filename>src.conf</filename> y <filename>src-env.conf</filename>. Dado el número infinito de opciones, no todas las combinaciones pueden ser totalmente compatibles.</para>
+	    </listitem>
 
 	    <listitem>
-	      <para>Si se trata de un problema del kernel, prepárese
-		para proporcionar la siguiente información.  (No es
-		necesario incluir esta información por defecto, puesto
-		que lo único que produce es un crecimiento desmesurado
-		de la base de datos GNATS, pero sí puede merecer la
-		pena incluir resúmenes que usted considere
-		importantes):</para>
+	      <para>Si el problema se puede reproducir fácilmente, incluya información que ayude al desarrollador a reproducirlo por sí mismo. Si se puede hacer una demostración con una entrada específica, incluya un ejemplo con esa entrada, si es posible, e incluya la salida real y la esperada. Si la información es grande o no se puede hacer pública, intente crear un archivo con lo mínimo que muestre el mismo problema y que pueda incluirse en el PR.</para>
+	    </listitem>
 
+	    <listitem>
+	      <para>Si se trata de un problema del kernel, prepárese para proporcionar la siguiente información. (No es necesario incluir esta información por defecto, puesto que lo único que produce es un crecimiento desmesurado de la base de datos, pero sí puede merecer la pena incluir extractos que usted considere importantes):</para>
+
 	      <itemizedlist>
 		<listitem>
-		  <para>La configuración del kernel (incluyendo los
-		    dispositivos hardware que se tienen
-		    instalados)</para>
+		  <para>la configuración del kernel (incluidos los dispositivos de hardware que ha instalado)</para>
 		</listitem>
 
 		<listitem>
-		  <para>Si se tienen opciones de depuración activadas
-		    (tales como <literal>WITNESS</literal>), y en tal
-		    caso, si el problema persiste cuando se cambia el
-		    valor de dichas opciones</para>
+		  <para>si tiene o no opciones de depuración activadas (como <literal>WITNESS</literal>), y si es así, si el problema persiste cuando se cambia el valor de dichas opciones</para>
 		</listitem>
 
 		<listitem>
-		  <para>Una traza de depuración, si se pudo
-		    generar.</para> </listitem>
+		  <para>el texto completo de cualquier backtrace, panic u otra salida por consola, o entradas en <filename>/var/log/messages</filename>, si se generó alguna</para>
+		</listitem>
 
 		<listitem>
-		  <para>El hecho de que se ha leido detenidamente el
-		    archivo <filename>src/UPDATING</filename> para
-		    constatar que el problema no se ha identificado
-		    allí (se garantiza que alguién le
-		    preguntará sobre este punto)</para>
+		  <para>la salida de <command>pciconf -l</command> y partes relevantes de su salida <command>dmesg</command> si su problema se relaciona con una pieza específica de hardware</para>
 		</listitem>
 
 		<listitem>
-		  <para>Si se puede o no se puede ejecutar otro kernel
-		    sin problemas (se trata de identificar problemas
-		    relacionados con el hardware como discos con
-		    errores o CPUs sobrecalentadas, que pueden
-		    confundirse fácilmente con problemas del
-		    kernel)</para>
+		  <para>el hecho de que haya leído <filename>src/UPDATING</filename> y que su problema no esté listado (seguro que alguien le preguntará sobre este punto)</para>
 		</listitem>
+
+		<listitem>
+		  <para>si puede o no ejecutar otro kernel de respaldo sin problemas (se trata de descartar problemas relacionados con el hardware, como discos con errores o CPUs con sobrecalentamiento, que pueden confundirse fácilmente con problemas del kernel)</para>
+		</listitem>
 	      </itemizedlist>
 	    </listitem>
 
 	    <listitem>
-	      <para>Si se trata de un problema relacionado con los
-		ports, prepárese para poder proporcionar la
-		información que se muestra a continuación. (No
-		es necesario incluir esta información por defecto, ya
-		que sólo produce un crecimiento indeseado de la base de
-		datos, pero sí se pueden incluir resúmenes de
-		aquellos datos que usted considere relevantes):</para>
+	      <para>Si se trata de un problema relacionado con los ports, prepárese para poder proporcionar la información que se muestra a continuación. (No es necesario incluir esta información por defecto, ya que esto solo produce un crecimiento indeseado de la base de datos, pero debe incluir extractos que considere que pueden ser relevantes):</para>
 
 	      <itemizedlist>
 		<listitem>
-		  <para>Los ports que se tiene instalados</para>
+		  <para>Qué ports ha instalado</para>
 		</listitem>
+
 		<listitem>
-		  <para>Cualesquiera variables de entorno que
-		    sobreescriban los valores por defecto del archivo
-		    <filename>bsd.port.mk</filename>, tales como
-		    <varname>PORTSDIR</varname></para>
+		  <para>Cualquier variable de entorno que sobrescriba los valores por defecto del archivo <filename>bsd.port.mk</filename>, como <varname>PORTSDIR</varname></para>
 		</listitem>
+
 		<listitem>
-		  <para>El hecho de que se ha leido
-		    <filename>ports/UPDATING</filename> y que nuestro
-		    problema no se encuentra identificado en dicho
-		    archivo (se garantiza que alguien puede preguntar
-		    este hecho).</para>
+		  <para>El hecho de que ha leído el archivo <filename>ports/UPDATING</filename> y que su problema no se encuentra en la lista (puede preguntar a alguien)</para>
 		</listitem>
 	      </itemizedlist>
 	    </listitem>
-
 	  </itemizedlist>
+	</listitem>
 
+	<listitem>
+	  <para><emphasis>Evitar peticiones de características vagas.</emphasis> Los PRs del estilo <quote>alguien debería implementar algo que haga esto, aquello y lo de más allá</quote> son informes con pocas probabilidades de obtener resultados positivos. Recuerde, el código fuente se encuentra disponible para todo el mundo, por lo tanto, si desea una característica, ¡la mejor manera de asegurarse de que se incluya es ponerse a trabajar en ella! También tenga en cuenta que para discutir este tipo de problemas resulta más adecuado utilizar la lista <literal>freebsd-questions</literal>, que una entrada en la base de datos de PR, como ya se ha comentado anteriormente.</para>
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Evitar peticiones de características
-	    vagas.</emphasis> Los PRs del estilo de
-	    <quote>alguien debería implementar  algo que haga
-	    esto y aquello y lo de más allá</quote> son
-	    informes con pocas probabilidades de obtener resultados
-	    positivos.  Las características deben ser muy concretas y
-	    específicas. Recuerde que el código fuente se
-	    encuentra disponible para todo el mundo, de tal forma que si usted
-	    necesita una característica, la mejor forma de verla
-	    incluida en futuras versiones de la herramienta consiste
-	    en ponerse usted mismo a trabajar sobre ella, manos a la
-	    obra. También tenga en cuenta que para discutir este tipo
-	    de problemas resulta más adecuado utilizar la lista
-	    <literal>freebsd-questions</literal>, como ya se ha
-	    comentado anteriormente.</para>
+	  <para><emphasis>Asegúrese que nadie más ha enviado un PR similar.</emphasis> Aunque esto ya se ha mencionado anteriormente, vale la pena repetirlo aquí. Solamente lleva uno o dos minutos utilizar el motor de búsqueda web  en <uri xlink:href="https://bugs.freebsd.org/bugzilla/query.cgi">https://bugs.freebsd.org/bugzilla/query.cgi</uri>.  (Por supuesto, todo el mundo es culpable de olvidarse de hacerlo de vez en cuando).</para>
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Asegúrese que nadie más ha enviado un
-	    PR similar.</emphasis> Aunque esto ya se ha mencionado
-	    anteriormente, merece la pena que se repita en este punto.
-	    Sólamente lleva uno o dos minutos realizar una
-	    búsqueda basada en un motor web en <uri xlink:href="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query</uri>.
-	    (Por supuesto, a todo el mundo se le puede olvidar
-	    realizar esto de vez en cuando, pero por esa misma razón
-	    merece la pena hacer incapié en ello)</para></listitem>
+	  <para><emphasis>Informe un solo problema por informe.</emphasis> Evite incluir dos o más problemas dentro del mismo informe, a menos que estén relacionados. Al enviar parches, evite agregar múltiples funciones o corregir varios errores en el mismo PR, a menos que estén estrechamente relacionados — ya que los PR suelen tardar más en resolverse.</para>
+	</listitem>
 
 	<listitem>
-	  <para><emphasis>Evite peticiones controvertidas.</emphasis>
-	    Si nuestro PR se dirige hacia un área o tema controvertido
-	    en el pasado, debemos prepararnos no sólo a ofrecer
-	    parches, si no también a justificar por qué motivo
-	    los parches proporcionados son la <quote>Forma Correcta de
-	    Hacerlo</quote>.  Como se avisó anteriormente, una
-	    búsqueda meticulosa en las listas de correo en los
-	    archivos históricos sitos en <uri xlink:href="http://www.FreeBSD.org/search/search.html#mailinglists">http://www.FreeBSD.org/search/search.html#mailinglists</uri>;
-	    resulta siempre una buena idea y sirve para preparar
-	    nuestro razonamiento y aprender de la experiencia y de las
-	    decisiones tomadas en el pasado.</para> </listitem>
+	  <para><emphasis>Evite peticiones controvertidas.</emphasis> Si su PR se dirige a un área que ha sido controvertida en el pasado, probablemente debería estar preparado para no solo ofrecer parches, sino también una justificación de por qué los parches son la <quote>forma correcta de hacerlo</quote>. Como se avisó anteriormente, una búsqueda meticulosa en las listas de correo utilizando los archivos históricos en <uri xlink:href="https://www.FreeBSD.org/search/search.html#mailinglists">https://www.FreeBSD.org/search/search.html#mailinglists</uri>; es siempre una buena opción.</para>
+	</listitem>
 
 	<listitem>
-	  <para><emphasis>Sea educado.</emphasis>
-	    Casi cualquier persona que se encarge de tratar nuestro
-	    informe de problemas trabajará en el como un voluntario.
-	    A nadie le gusta que le digan cómo hacer las cosas cuando
-	    ya se están haciendo de una forma determinada,
-	    especialmente cuando la motivación para realizarlas no es
-	    monetaria.  Este hecho es bueno tenerlo en mente y
-	    aplicarlo para cualquier proyecto de Software
-	    Libre.</para> </listitem> </itemizedlist>
+	  <para><emphasis>Sea educado.</emphasis> Practicamente cualquier persona que se encargue de tratar su PR es un voluntario. A nadie le gusta que le digan que tiene que hacer algo cuando ya lo están haciendo por alguna otra motivación que no sea la económica. Es bueno tenerlo en cuenta en todo momento en los proyectos de código abierto.</para>
+	</listitem>
+      </itemizedlist>
     </section>
 
-    <section>
-      <title>Antes de comenzar.</title>
+    <section xml:id="pr-writing-before-beginning">
+      <title>Antes de comenzar</title>
 
-      <para>Antes de ejecutar el programa &man.send-pr.1;, asegúrese
-	de que la variable de entorno <envar>VISUAL</envar> (o
-	<envar>EDITOR</envar> si la variable <envar>VISUAL</envar> no
-	se encuentra definida) se encuentra apuntando a algo con
-	sentido.</para>
+      <para>Se aplican consideraciones similares al uso del formulario de envío de PR <link xlink:href="https://bugs.freebsd.org/bugzilla/enter_bug.cgi">por la aplicación web</link>. Tenga cuidado con las operaciones de cortar y pegar que puedan cambiar los espacios en blanco u otro formato de texto.</para>
 
-      <para>Es importante comprobar que la entrega de correo funciona
-	correctamente. &man.send-pr.1; utiliza mensajes de correo para
-	enviar y realizar un seguimiento de los informes de problemas.
-	Si no se puede generar correo electrónico desde la
-	máquina en la que se ejecuta &man.send-pr.1;, el informe
-	jamás llegará a la base de datos GNATS.
-	Si quiere saber más sobre la
-	configuración del correo en &os; consulte el capítulo de
-	<quote>Correo Electrónico</quote> del manual de &os; en <uri xlink:href="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mail.html">http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mail.html</uri>.</para>;
+      <para>Finalmente, si el envío es largo, prepare el trabajo sin conexión, de forma que no se pierda nada si hay un problema al enviarlo.</para>
     </section>
 
-    <section>
+    <section xml:id="pr-writing-attaching-patches">
       <title>Adjuntar parches o archivos</title>
 
-      <para>El programa &man.send-pr.1; posee la capacidad de adjuntar
-	archivos al informe de problemas. Se pueden adjuntar tantos
-	archivos como se quiera siempre y cuando se utilice un nombre
-	distinto para cada archivo (e.g. el nombre del archivo después
-	de eliminar el path). Simplemente basta con utilizar la opción
-	<option>-a</option> de línea de comandos para especificar los
-	nombres de todos los archivos que se desean adjuntar:</para>
+      <para>Al adjuntar un parche, asegúrese de usar  <command>svn diff</command> o <citerefentry><refentrytitle>diff</refentrytitle><manvolnum>1</manvolnum></citerefentry> con el argumento <option>-u</option> para crear un diff unificado, y asegúrese de especificar el número de revisión SVN del repositorio contra el que modificó los archivos, para que los desarrolladores que lean su informe puedan aplicarlos fácilmente. Para problemas relacionados con el kernel o utilidades del sistema base, se prefiere un parche contra FreeBSD-CURRENT (la rama HEAD de Subversion), ya que todo el código nuevo debe aplicarse y probarse allí primero. Después de que se hayan realizado las pruebas adecuadas o importantes, se hará el merge/migración a la rama FreeBSD-STABLE.</para>
 
-<screen>&prompt.user; <userinput>send-pr -a /var/run/dmesg -a /tmp/errors</userinput></screen>
+      <para>Si adjunta un parche como parte del mensaje, en lugar de como adjunto, tenga en cuenta que uno de los problemas más comunes es la tendencia de algunos programas de correo electrónico de mostrar las tabulaciones como espacios, lo cual estropeará por completo todo lo que pretenda que forme parte de un Makefile.</para>
 
-      <para>No se preocupe por los archivos binarios, dichos archivos
-	se codifican automáticamente para no interferir con el agente
-	de correo.</para>
+      <para>No envíe parches como archivos adjuntos usando <command>Content-Transfer-Encoding: quoted-printable</command>. Esto escapará el carácter (character escaping) y todo el parche será inútil.</para>
 
-      <para>Si se adjunta un parche, asegúrese que se utiliza la
-	opción <option>-c</option> o la opción
-	<option>-u</option> de &man.diff.1; para crear un contexto
-	unificado (el contexto suele ser el preferido por quienes lo han de
-	recibir) y además asegúrese de especificar
-	los números de revisión de CVS de los archivos que se
-	modifican para que los desarrolladores que lean el informe
-	puedan aplicar dichos parches fácilmente.  Para problemas
-	relacionados con el kernel o con las utilidades del sistema
-	base, se prefiere un parche contra &os.current; (la rama HEAD
-	del árbol CVS) ya que cualquier código nuevo debe
-	probar se primeramente en dicha rama.  Después de comprobar su
-	correcto funcionamiento de una forma sustancial y extensa,
-	eventualmente dicho código pasará a formar parte de
-	&os.stable;, mediante unión o migración.</para>
+      <para>También tenga en cuenta que, incluir pequeños parches en un PR, en general, está bien, especialmente cuando soluciona el problema descrito en el PR, los parches grandes y especialmente el nuevo código que pueda requerir una revisión sustancial antes de realizar el commit deben colocarse en un servidor web o ftp, y la URL debe incluirse en el PR en lugar del parche. Los parches en el correo electrónico tienden a ser destrozados, y cuanto más grande sea el parche, más difícil será para las partes interesadas desenmarañarlo. Además, la publicación de un parche en la web le permite modificarlo sin tener que volver a enviar el parche completo en un follow-up al PR original. Finalmente, los parches grandes simplemente aumentan el tamaño de la base de datos, ya que los PR cerrados no se eliminan, sino que se guardan y simplemente se marcan como completos.</para>
 
-      <para>Si se envía un parte en línea, en vez de como
-        adjunto, tenga en cuenta que el principal problema de esta forma de
-	enviar los parches es que, dependiendo del lector de correo
-	utilizado, algunos lectores muestran los tabuladores como
-	espacios, lo cual arruina completamente el formato y la
-	indentación del parche, e invalida totalmente un parche que
-	forme parte de un Makefile.</para>
+      <para>También debe tener en cuenta que, a menos que se especifique explícitamente lo contrario en su PR o en el propio parche, se asumirá que los parches que envíe se licenciarán en los mismos términos que el archivo original que modificó.</para>
+    </section>
 
-      <para>También tenga en cuenta que mientras que la
-        inclusión de parches en un PR se considera como algo
-	positivo&mdash;particularmente cuando se soluciona el problema
-	que describe el informe&mdash;partes grandes y especialmente
-	código nuevo que puede requerir una sustancial revisión
-	antes de ser aplicado debería hacerse accesible a través
-	de otros medios, como páginas web o servidores de ftp, y
-	en vez de incluir el parche en el informe se puede incluir la URL.
-	Los parches de gran tamaño en los correos electrónicos
-	tienden a mezclarse o partirse, especialmente cuando GNATS los trata,
-	y cuanto más grande es el parche más difícil
-	 resulta recuperar el original.  También existe una ventaja
-	añadida a la inclusión del parche a través de una
-	URL, ya que de este modo se puede modificar el parche sin tener que
-	reenviar el informe como una respuesta al informe inicial.</para>
+    <section xml:id="pr-writing-filling-template">
+      <title>Rellenar el formulario</title>
 
-      <para>Se debe prestar atención también al hecho de que, a
-	menos que se especifique explícitamente lo contrario en el PR o
-	en el propio parche, cualquier parche enviado se supone
-	licenciado bajo los mismos términos y condiciones que el
-	archivo original que modifica.</para> </section>
+      <note>
+	<para>La dirección de correo electrónico que utilice pasará a ser pública y podrá estar disponible para los spammers. Debe tener implementados procedimientos de manejo de spam o usar una cuenta de correo electrónico temporal. Sin embargo, tenga en cuenta que si no utiliza una cuenta de correo electrónico válida, no podremos hacerle preguntas sobre su PR.</para>
+      </note>
 
-    <section>
-      <title>Rellenar la plantilla</title>
+      <para>Cuando presente un error, encontrará los siguientes campos:</para>
 
-      <para>Cuando se ejecuta &man.send-pr.1; se nos presenta en
-	pantalla una plantilla. Esta plantilla consiste en una lista
-	de campos, algunos de los cuales se encuentran ya rellenados,
-	mientras que otros poseen comentarios donde se explica su
-	propósito o se comentan los valores aceptables. No se preocupe
-	por los comentarios, puesto que se borran automáticamente
-	antes de generar el informe.</para>
-
-      <para>Al comienzo de la plantilla, justo debajo de las líneas de
-	<literal>SEND-PR:</literal>, se encuentran las cabeceras de
-	correo electrónico. Dichas cabeceras normalmente no se tienen
-	que modificar, a menos que se esté rellenando el informe desde
-	una máquina que puede enviar correo pero no puede recibirlo
-	directamente, en cuyo caso usted tendrá que editar los campos
-	<literal>From:</literal> y <literal>Reply-To:</literal> para
-	escribir la dirección de correo válida. También
-	puede enviarse una copia a usted mismo o a cualquier otra persona
-	rellenando el campo <literal>Cc:</literal>.</para>
-
-      <para>A continuación aparecen una serie de campos de una sola
-	línea:</para>
-
       <itemizedlist>
 	<listitem>
-	  <para><emphasis>Submitter-Id:</emphasis> No cambie este
-	    campo. El valor por defecto
-	    <literal>current-users</literal> es correcto, incluso si
-	    se está ejecutando &os.stable;.</para> </listitem>
+	  <para><emphasis>Synopsis:</emphasis> Rellene este campo con una descripción corta y precisa del problema. El campo debe ser rellenado en inglés, pues es el idioma de comunicación en el proyecto FreeBSD. La sinopsis se utiliza como subject del correo electrónico del informe de problemas, y también se utiliza en los listados y resúmenes de informes de la base de datos; informes de problemas con vagas sinopsis tienden a ser completamente ignorados.</para>
+	</listitem>
 
 	<listitem>
-	  <para><emphasis>Originator:</emphasis> Se rellena
-	    automáticamente con el campo <literal>gecos</literal> del
-	    usuario que está actualmente dentro del sistema. Por
-	    favor, especifique su nombre real, opcionalmente
-	    acompañado por su dirección de correo
-	    electrónico entre &lt; &gt;.</para> </listitem>
+	  <para><emphasis>Severity:</emphasis> Escoga una de las opciones, <literal>Affects only me (Solo me afecta a mi)</literal>, <literal>Affects some people (Afecta a algunas personas)</literal> o <literal>Affects many people (Afecta a muchas personas)</literal>. No sea exagerado; absténgase de etiquetar su problema <literal>Affects many people (Afecta a muchas personas)</literal> a menos que realmente lo haga. Los desarrolladores de FreeBSD no trabajarán en su problema más rápido si infla su importancia, ya que muchas otras personas han hecho exactamente lo mismo.</para>
+	</listitem>
 
 	<listitem>
-	  <para><emphasis>Organization:</emphasis> Escriba lo que
-	    usted quiera.  Este campo no se utiliza para nada
-	    significativo.</para> </listitem>
+	  <para><emphasis>Category:</emphasis> Elija una categoría apropiada.</para>
 
-	<listitem>
-	  <para><emphasis>Confidential:</emphasis> Esto se rellena
-	    automáticamente con el literal <literal>no</literal>.
-	    Cambiar este valor carece de sentido ya que no existe
-	    ningún informe de problemas de &os; confidencial&mdash;la
-	    base de datos de PR se distribuye a todo el mundo de forma
-	    pública mediante <application>CVSup</application>.</para>
-	    </listitem>
+	  <para>Lo primero que debe hacer es decidir en qué parte del sistema se encuentra su problema. Recuerde, FreeBSD es un sistema operativo completo, instala un kernel, la biblioteca estándar, muchos controladores de periféricos y un gran número de utilidades (el <quote>sistema base</quote>). Sin embargo, hay miles de aplicaciones adicionales en la colección de ports. Primero deberá decidir si el problema está en el sistema base o en algo instalado a través de la colección de ports.</para>
 
-	<listitem>
-	  <para><emphasis>Synopsis:</emphasis> Rellene este campo con
-	    una descripción corta y precisa del problema. La sinopsis
-	    se utiliza como subject del correo electrónico del informe
-	    de problemas, y también se utiliza en los listados y
-	    resúmenes de informes de la base de datos; informes de
-	    problemas con obscuras sinopsis tienden a ser
-	    completamente ignorados.</para>
+	  <para>Aquí una descripción de las principales categorías:</para>
 
-	  <para>Como se avisó anteriormente, si su informe de
-	    problemas incluye un parche, por favor incluya en la
-	    sinopsis la etiqueta <literal>[patch]</literal> al
-	    comienzo; si usted es un mantenedor de software, también
-	    puede añadir la cadena <literal>[maintainer
-	    update]</literal> y asignar el campo <quote>Class</quote>
-	    del informe al valor
-	    <literal>maintainer-update</literal>.</para> </listitem>
-
-	<listitem>
-	  <para><emphasis>Severity:</emphasis> Los valores aceptados
-	    son <literal>non-critical</literal>,
-	    <literal>serious</literal> o <literal>critical</literal>.
-	    No sea exagerado; evite etiquetar el problema como
-	    <literal>critital</literal> a menos que sea realmente algo
-	    crítico (e.g.  escalada de permisos hacia
-	    <systemitem class="username">root</systemitem>, kernel panic fácilmente
-	    reproducible). Incluso debe pensarse detenidamente
-	    etiquetar algo como <literal>serious</literal> a menos que
-	    se trate de algo que afecte a muchos usuarios (problemas
-	    con drivers de dispositivos particulares o con utilidades
-	    del sistema).  Los desarrolladores de &os; no van a
-	    resolver el problema más rápido por el hecho de
-	    variar esta etiqueta, debido a que existe mucha gente que infla
-	    este campo inadecuadamente. De hecho, los desarrolladores
-	    prestan muy poca atención al valor de este campo y del
-	    siguiente precisamente por esto último.</para> </listitem>
-
-	<listitem>
-	  <para><emphasis>Priority:</emphasis> Los valores aceptados
-	    son <literal>low</literal>, <literal>medium</literal> o
-	    <literal>high</literal>.  <literal>high</literal> debe
-	    reservarse para problemas que afecten a la mayoría de los
-	    usuarios de &os; y <literal>medium</literal> para aquellos
-	    problemas que afecten a varios usuarios.</para>
+	  <itemizedlist>
+	    <listitem>
+	      <para>Si hay un problema con el kernel, las bibliotecas (como la biblioteca estándar de C <literal>libc</literal>) o en un controlador de un periférico en el sistema base, en general, utilizará la categoría <literal>kern</literal>. (Hay algunas excepciones; vea más abajo). En general, estas son las cosas que se describen en la sección 2, 3 ó 4 de las páginas del manual.</para>
 	    </listitem>
 
-	<listitem>
-	  <para><emphasis>Category:</emphasis> Seleccione uno de los
-	    siguientes valores (extraídos de
-	    <filename>/usr/gnats/gnats-adm/categories</filename>):</para>
-	    <itemizedlist> <listitem>
-	    <para><literal>advocacy:</literal> para problemas
-	    relacionados con la imagen pública de &os;.  Raras veces
-	    utilizado.</para> </listitem>
-
 	    <listitem>
-	      <para><literal>alpha:</literal> para problemas
-		específicos de la plataforma Alpha.</para> </listitem>
+	      <para>Si el problema es con un binario como <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> o <citerefentry><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>, primero deberá determinar si estos programas se encuentran en el sistema base o se añadieron a través de la colección de ports. Si no está seguro, puede hacer <command>whereis <replaceable>programname</replaceable></command>. La convención de FreeBSD para la colección de ports es instalar todo por debajo de <filename class="directory">/usr/local</filename>, aunque un administrador del sistema puede sobreescribirlo. Para estos, utilizará la categoría de <literal>ports</literal> (sí, incluso si la categoría del port es <literal>www</literal>; vea más abajo). Si la ubicación es <filename class="directory">/bin</filename>, <filename class="directory">/usr/bin</filename>, <filename class="directory">/sbin</filename>, o <filename class="directory">/
 usr/sbin</filename>, es parte del sistema base, y debe usar la categoría <literal>bin</literal>. Estas son todas las cosas que se describen en las secciones 1 u 8 de las páginas del manual.</para>
+	    </listitem>
 
 	    <listitem>
-	      <para><literal>amd64:</literal> para problemas
-		específicos de la plataforma AMD64.</para> </listitem>
+	      <para>Si cree que el error está en los scripts de inicio <literal>(rc)</literal>, o en algún otro tipo de archivo de configuración no ejecutable, entonces la categoría correcta es <literal>conf</literal> (configuración). Estas son las cosas que se describen en la sección 5 de las páginas del manual.</para>
+	    </listitem>
 
 	    <listitem>
-	      <para><literal>bin:</literal> para problemas con
-		aplicaciones de la zona de usuario del sistema
-		base.</para> </listitem>
+	      <para>Si ha encontrado un problema en el conjunto de la documentación (artículos, libros, man pages) o en el sitio web, la elección correcta es <literal>docs</literal>.</para>
 
-	    <listitem>
-	      <para><literal>conf:</literal> para problemas de
-		archivos de configuración, valores por defecto,
-		etc.</para> </listitem>
+	      <note>
+		<para>Si tiene un problema con un port llamado <literal>www/<replaceable>algunnombredeport</replaceable></literal>, esto entra en la categoría de <literal>ports</literal>.</para>
+	      </note>
+	    </listitem>
+	  </itemizedlist>
 
-	    <listitem>
-	      <para><literal>docs:</literal> para problemas con las
-		páginas de manual o la documentación online.
-		</para> </listitem>
+	  <para>Hay algunas categorías más especializadas.</para>
 
+	  <itemizedlist>
 	    <listitem>
-	      <para><literal>gnu:</literal> para problemas
-		realacionados con aplicaciones gnu de &os; tales como
-		&man.gcc.1; o &man.grep.1;.</para> </listitem>
+	      <para>Si el problema se catalogará en <literal>kern</literal> pero estuviera relacionado con el subsistema USB, la elección correcta es <literal>usb</literal>.</para>
+	    </listitem>
 
 	    <listitem>
-	      <para><literal>i386:</literal> para problemas
-		específicos de la plataforma &i386;.</para> </listitem>
+	      <para>Si el problema se catalogará en <literal>kern</literal> pero estuviera relacionado con las bibliotecas de threading, la elección correcta es <literal>threads</literal>.</para>
+	    </listitem>
 
 	    <listitem>
-	      <para><literal>ia64:</literal> para problemas
-		específicos de la plataforma ia64.</para> </listitem>
+	      <para>Si el problema se catalogará en el sistema base, pero estuviera relacionado con nuestra interpretación de estándares, como <trademark class="registered">POSIX</trademark>, la elección correcta es <literal>standards</literal>.</para>
+	    </listitem>
 
 	    <listitem>
-	      <para><literal>java:</literal> para problemas
-		relacionados con &java;.</para> </listitem>
+	      <para>Si está convencido de que el problema solo ocurrirá con la arquitectura del procesador que está utilizando, seleccione una de las categories específicas de la arquitectura: normalmente, <literal>i386</literal> para ordenadores compatibles con Intel en modo 32 bits; <literal>amd64</literal> para máquinas AMD que se ejecutan en modo 64 bits (esto también incluye ordenadores compatibles con Intel que se ejecutan en modo EMT64); y las menos comunes, <literal>arm</literal> o <literal>powerpc</literal>.</para>
 
-	    <listitem>
-	      <para><literal>kern:</literal> para problemas
-		relacionados con el kernel o con (no especifícos de
-		ninguna plataforma) controladores de
-		dispositivos.</para> </listitem>
+	      <note>
+		<para>Estas categorías se utilizan con frecuencia para los problemas <quote>No lo sé</quote>. En lugar de suponer, utilice <literal>misc</literal>.</para>
+	      </note>
 
-	    <listitem>
-	      <para><literal>misc:</literal> para cualquier cosa que
-		no encaja en ninguna de las anteriores categorías.
-		(Tenga en cuenta que es muy fácil que los problemas
-		bajo esta categoría se pierdan en el olvido).</para>
-		</listitem>
+	      <example>
+		<title>Uso correcto de la categoría de arquitectura específica</title>
 
-	    <listitem>
-	      <para><literal>ports:</literal> para problemas
-		relacionados con el árbol de ports.</para> </listitem>
+		<para>Tiene un ordenador común (PC-based machine), y cree que ha encontrado un problema específico para un conjunto de chips o una placa base en particular: <literal>i386</literal> es la categoría correcta.</para>
+	      </example>
 
-	    <listitem>
-	      <para><literal>powerpc:</literal> para problemas
-		específicos de la plataforma &powerpc;.</para>
-		</listitem>
+	      <example>
+		<title>Uso incorrecto de la categoría de arquitectura específica</title>
 
-	    <listitem>
-	      <para><literal>sparc64:</literal> para problemas
-		específicos de la plataforma &sparc64;.</para>
-		</listitem>
-
-	    <listitem>
-	      <para><literal>standards:</literal> para problemas
-		relativos a la adecuación con estándares.</para>
-		</listitem>
-
-	    <listitem>
-	      <para><literal>threads:</literal> para problemas
-		relacionados con la implementación de threads de &os;
-		(especialmente en &os.current;).</para> </listitem>
-
-	     <listitem>
-	       <para><literal>www:</literal> para cambios o mejoras
-		 del sitio web de &os;.</para> </listitem>
-		 </itemizedlist> </listitem>
-
-	<listitem>
-	  <para><emphasis>Class:</emphasis> Se puede seleccionar uno
-	    entre los siguientes:</para>
-
-	  <itemizedlist>
-	    <listitem>
-	      <para><literal>sw-bug:</literal> bugs de software.</para>
+		<para>Está teniendo un problema con una tarjeta periférica adicional en un bus común, o un problema con un tipo particular de unidad de disco duro: en este caso, probablemente afecte a más de una arquitectura, y <literal>kern</literal> es la categoría correcta.</para>
+	      </example>

*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201909051936.x85Ja6Xv000798>