From owner-svn-doc-all@freebsd.org Thu Sep 5 19:36:06 2019 Return-Path: Delivered-To: svn-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C9153D1649; Thu, 5 Sep 2019 19:36:06 +0000 (UTC) (envelope-from carlavilla@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46PWBt4vdMz4HVx; Thu, 5 Sep 2019 19:36:06 +0000 (UTC) (envelope-from carlavilla@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8C78B91FD; Thu, 5 Sep 2019 19:36:06 +0000 (UTC) (envelope-from carlavilla@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x85Ja6Y7000800; Thu, 5 Sep 2019 19:36:06 GMT (envelope-from carlavilla@FreeBSD.org) Received: (from carlavilla@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id x85Ja6Xv000798; Thu, 5 Sep 2019 19:36:06 GMT (envelope-from carlavilla@FreeBSD.org) Message-Id: <201909051936.x85Ja6Xv000798@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: carlavilla set sender to carlavilla@FreeBSD.org using -f From: Sergio Carlavilla Delgado Date: Thu, 5 Sep 2019 19:36:06 +0000 (UTC) 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 X-SVN-Group: doc-head X-SVN-Commit-Author: carlavilla X-SVN-Commit-Paths: head/es_ES.ISO8859-1/articles/problem-reports X-SVN-Commit-Revision: 53375 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 19:36:06 -0000 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 @@ - - -
- Cómo enviar informes de problemas de &os; - + + +
- $FreeBSD$ + + Escribiendo informes de problemas de FreeBSD - - &tm-attrib.freebsd; - &tm-attrib.cvsup; - &tm-attrib.ibm; - &tm-attrib.intel; - &tm-attrib.sparc; - &tm-attrib.sun; - &tm-attrib.general; + FreeBSD is a registered trademark of the FreeBSD Foundation. + 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. + 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. + 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. + 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 â„¢ or the ® symbol. + $FreeBSD$ + + $FreeBSD$ + - Este artículo describe cómo realizar y enviar - informes de errores para el proyecto &os; de la mejor forma - posible. - &trans.es.jrh; + Este artículo describe cómo realizar y enviar informes de problemas para el proyecto FreeBSD de la mejor forma posible. - Dag-ErlingSmørgravEscrito por - + Dag-Erling Smørgrav Contributed by - $FreeBSD$ + Mark Linimon + problem reports
- Introducción + Introducción - 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 no es un error o PR erroneo. - 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. + 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 no es un error o PR erróneo. 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. - 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. + 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. - 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. + 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. - 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.
+ 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. +
- Cuándo enviar informes de problemas + Cuándo enviar informes de problemas - 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 bug 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 - no ser 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 bugs: una mejora o una solucitud - nuevas características, por citar un par de ejemplos. + 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 no ser 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. - Así que ?cómo podemos determinar qué - constituye un bug y qué no? Como regla para - principiantes podemos decir que su problema - no es un bug si - se puede expresar como una pregunta (normalmente del estilo de - ?cómo hago X? o - ?donde puedo encontrar Y?). 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;. + Entonces, ¿cómo se determina qué es un error y qué no? Como regla general, el problema no es un error si puede expresarse como una pregunta (normalmente del estilo de ¿Cómo hago X? o ¿Dónde puedo encontrar Y?). 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 lista de correo de preguntas generales de FreeBSD. - A continuación se muestran algunos casos en los que resulta - apropiado enviar un informe de problemas sobre algo que no se - considera un bug: + Tenga en cuenta estos factores al enviar PRs sobre ports u otro software que no sea parte de FreeBSD: - 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. + 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 portscout 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. - 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 los ports que no están mantenidos (el MAINTAINER es ports@FreeBSD.org), 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). + + + En cualquier caso, seguir el proceso descrito en el Manual del Porter dará los mejores resultados. (Es posible que también desee leer Cómo contribuir a la colección de ports de FreeBSD). + - Otro tema es que si el sistema donde se experimentó el - bug 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. + 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. - Por último, un bug que no se puede - reproducir difícilmente puede arreglarse. Si el - bug 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 bug 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. -
+ 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: + + + 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 kern); las utilidades binarias (bin); las páginas del manual y documentación (docs); y las páginas web (www). Todos los errores en estas áreas deben informarse a los desarrolladores de FreeBSD. + + + + El código en el sistema base escrito y mantenido por otros, e importado y adaptado a FreeBSD. Los ejemplos incluyen clang1 y sendmail8. 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. + + + + 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 ports). 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. + + + + 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. + + Si el problema está en el sistema base, primero lea la sección de preguntas frecuentes sobre las versiones de FreeBSD, 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 la lista de versiones soportadas. + + 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. + +
Preparativos - 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: + 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: - Las - Preguntas Más - - Frecuentes (FAQ) de &os;. - Las FAQ intentan proporcionar respuestas para un - amplio rango de dudas, tales como aquellas relacionadas - con las - - compatibilidades - hardware, las - aplicaciones - de usuario y la - configuración - del kernel. + La lista de preguntas más frecuentes (FAQ) de FreeBSD. Las preguntas frecuentes intentan proporcionar respuestas a una amplia gama de preguntas, como las relacionadas con la compatibilidad del hardware, las aplicaciones de usuario y la configuración del kernel. - Las - - listas - - de correo. Si no está subscrito utilice - la - búsqueda en los archivos 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. + Las listas de correo, si no está suscrito, utilice la búsqueda en los archivos 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. - Opcionalmente, la web entera—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. + 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. + - A continuación, la búsqueda a través de - - la base de datos &os; PR (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. + A continuación, la búsqueda a través de la base de datos de PR de FreeBSD (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. - 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. + 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. - En el caso de las fuentes del sistema &os; debe estudiarse - cuidadosamente el contenido del fichero - /usr/src/UPDATING del sistema o su - última versión, que se encuentra en http://www.FreeBSD.org/cgi/cvsweb.cgi/src/UPDATING. - (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 el código base de FreeBSD, debe estudiar cuidadosamente el contenido del fichero /usr/src/UPDATING del sistema o la versión más reciente en https://svnweb.freebsd.org/base/head/UPDATING?view=log. (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). - 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 - /usr/ports/UPDATING (para ports - individuales) o el archivo - /usr/ports/CHANGES (para cambios que - afectan a la colección de ports completa). http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/UPDATING - y http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES - también se encuentran disponibles a través de CVSweb. - - - + 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 /usr/ports/UPDATING (para ports individuales) o el archivo /usr/ports/CHANGES (para cambios que afectan a la colección de ports completa). https://svnweb.freebsd.org/port/head/UPDATING?view=log y https://svnweb.freebsd.org/ports/head/CHANGES?view=log también están disponibles a través de svnweb. + + +
- A continuación debemos asegurarnos de que el informe de - errores llega a las personas adecuadas. - - 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. - - 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. - -
- Escribir el informe de problemas + Escribiendo el informe de problemas - 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. + 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. -
- Consejos y trucos para escribir un buen informe de - problemas +
+ Consejos y trucos para escribir un buen informe de problemas - No deje la línea de Synopsis - vacía. Los PRs se dirigen tanto a una lista de - correo mundial (donde se utiliza el campo - Synopsis para rellenar la línea - Subject: del correo) como a una base - de datos (GNATS). Cualquier persona que consulte la base - de datos por el campo sinopsis y encuentre un - PR con una línea de Asunto 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. + No deje el campo Summary vacío. Los PRs se envían a una lista de correo global (donde se utiliza el campo Summary para la línea Subject:), 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. - Evite utilizar una línea de - Synopsis débil.. 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 Synopsis: portupgrade is - broken, se pueden ver las ventajas que - proporciona una línea como la siguiente: - Synopsis: port sysutils/portupgrade produce un - coredump en -current. (En el caso concreto de - los ports, resulta especialmente útil poseer tanto la - categoría como el nombre del port en la línea - Synopsis.) + Rellene el campo Summary correctamente, no use descripciones vagas. 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, Summary: portupgrade is broken, podría utilizar este otro, el cual, tiene mucha más información: Summary: port ports-mgmt/portupgrade coredumps on -current. (En el caso de los ports, es especialmente útil tener el nombre de la categoría y el nombre del port en el campo Summary). - Si se dispone de un parche, dígalo. - 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 - [patch] al comienzo de la línea - Synopsis. (Aunque no es obligatorio - utilizar dicha cadena, se trata de un estándar de facto - que se utiliza de forma mayoritaria.) - + Si tiene un parche, dígalo. Es más probable que se analice un PR con un parche incluido que uno sin él. Incluya la palabra clave patch en Bugzilla. - Si es mantenedor del port, dígalo. - 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 - [maintainer update] al comienzo de la - línea de sinopsis, y además se debería - asignar el campo Class del PR a la cadena - maintainer-update. De esta forma - cualquier committer que maneje el PR no tendrá que - realizar comprobaciones. + Si es un maintainer, dígalo. Si mantiene una parte del código fuente (por ejemplo, un port que ya exista), debe establecer el campo Class de su PR a maintainer-update. De esta forma, cualquier committer que se ocupe de su PR no tendrá que verificarlo. + - Sea concreto. - Cuanta más información se proporcione sobre el - problema que se tiene, más posiblidades de obtener una - respuesta. + Sea concreto. Cuanta más información se proporcione sobre el problema que tiene, más posibilidades de obtener una respuesta. - 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. + 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 CD-ROM 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. + - Incluya qué opciones globales se han especificado - en el archivo make.conf. Aviso: - Es bien conocido por todos que especificar - -O2 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. - + Incluya qué opciones globales ha especificado en sus ficheros make.conf, src.conf y src-env.conf. Dado el número infinito de opciones, no todas las combinaciones pueden ser totalmente compatibles. + - 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): + 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. + + + 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): + - La configuración del kernel (incluyendo los - dispositivos hardware que se tienen - instalados) + la configuración del kernel (incluidos los dispositivos de hardware que ha instalado) - Si se tienen opciones de depuración activadas - (tales como WITNESS), y en tal - caso, si el problema persiste cuando se cambia el - valor de dichas opciones + si tiene o no opciones de depuración activadas (como WITNESS), y si es así, si el problema persiste cuando se cambia el valor de dichas opciones - Una traza de depuración, si se pudo - generar. + el texto completo de cualquier backtrace, panic u otra salida por consola, o entradas en /var/log/messages, si se generó alguna + - El hecho de que se ha leido detenidamente el - archivo src/UPDATING para - constatar que el problema no se ha identificado - allí (se garantiza que alguién le - preguntará sobre este punto) + la salida de pciconf -l y partes relevantes de su salida dmesg si su problema se relaciona con una pieza específica de hardware - 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) + el hecho de que haya leído src/UPDATING y que su problema no esté listado (seguro que alguien le preguntará sobre este punto) + + + 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) + - 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): + 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): - Los ports que se tiene instalados + Qué ports ha instalado + - Cualesquiera variables de entorno que - sobreescriban los valores por defecto del archivo - bsd.port.mk, tales como - PORTSDIR + Cualquier variable de entorno que sobrescriba los valores por defecto del archivo bsd.port.mk, como PORTSDIR + - El hecho de que se ha leido - ports/UPDATING y que nuestro - problema no se encuentra identificado en dicho - archivo (se garantiza que alguien puede preguntar - este hecho). + El hecho de que ha leído el archivo ports/UPDATING y que su problema no se encuentra en la lista (puede preguntar a alguien) - + + + Evitar peticiones de características vagas. Los PRs del estilo alguien debería implementar algo que haga esto, aquello y lo de más allá 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 freebsd-questions, que una entrada en la base de datos de PR, como ya se ha comentado anteriormente. - Evitar peticiones de características - vagas. Los PRs del estilo de - alguien debería implementar algo que haga - esto y aquello y lo de más allá 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 - freebsd-questions, como ya se ha - comentado anteriormente. + Asegúrese que nadie más ha enviado un PR similar. 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 https://bugs.freebsd.org/bugzilla/query.cgi. (Por supuesto, todo el mundo es culpable de olvidarse de hacerlo de vez en cuando). - Asegúrese que nadie más ha enviado un - PR similar. 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 http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query. - (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) + Informe un solo problema por informe. 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. + - Evite peticiones controvertidas. - 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 Forma Correcta de - Hacerlo. Como se avisó anteriormente, una - búsqueda meticulosa en las listas de correo en los - archivos históricos sitos en http://www.FreeBSD.org/search/search.html#mailinglists - resulta siempre una buena idea y sirve para preparar - nuestro razonamiento y aprender de la experiencia y de las - decisiones tomadas en el pasado. + Evite peticiones controvertidas. 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 forma correcta de hacerlo. Como se avisó anteriormente, una búsqueda meticulosa en las listas de correo utilizando los archivos históricos en https://www.FreeBSD.org/search/search.html#mailinglists es siempre una buena opción. + - Sea educado. - 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. + Sea educado. 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. + +
-
- Antes de comenzar. +
+ Antes de comenzar - Antes de ejecutar el programa &man.send-pr.1;, asegúrese - de que la variable de entorno VISUAL (o - EDITOR si la variable VISUAL no - se encuentra definida) se encuentra apuntando a algo con - sentido. + Se aplican consideraciones similares al uso del formulario de envío de PR por la aplicación web. Tenga cuidado con las operaciones de cortar y pegar que puedan cambiar los espacios en blanco u otro formato de texto. - 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 - Correo Electrónico del manual de &os; en http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mail.html. + 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.
-
+
Adjuntar parches o archivos - 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 - de línea de comandos para especificar los - nombres de todos los archivos que se desean adjuntar: + Al adjuntar un parche, asegúrese de usar svn diff o diff1 con el argumento 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. -&prompt.user; send-pr -a /var/run/dmesg -a /tmp/errors + 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. - No se preocupe por los archivos binarios, dichos archivos - se codifican automáticamente para no interferir con el agente - de correo. + No envíe parches como archivos adjuntos usando Content-Transfer-Encoding: quoted-printable. Esto escapará el carácter (character escaping) y todo el parche será inútil. - Si se adjunta un parche, asegúrese que se utiliza la - opción o la opción - 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. + 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. - 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. + 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ó. +
- También tenga en cuenta que mientras que la - inclusión de parches en un PR se considera como algo - positivo—particularmente cuando se soluciona el problema - que describe el informe—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. +
+ Rellenar el formulario - 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.
+ + 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. + -
- Rellenar la plantilla + Cuando presente un error, encontrará los siguientes campos: - 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. - - Al comienzo de la plantilla, justo debajo de las líneas de - SEND-PR:, 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 - From: y Reply-To: 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 Cc:. - - A continuación aparecen una serie de campos de una sola - línea: - - Submitter-Id: No cambie este - campo. El valor por defecto - current-users es correcto, incluso si - se está ejecutando &os.stable;. + Synopsis: 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. + - Originator: Se rellena - automáticamente con el campo gecos 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 < >. + Severity: Escoga una de las opciones, Affects only me (Solo me afecta a mi), Affects some people (Afecta a algunas personas) o Affects many people (Afecta a muchas personas). No sea exagerado; absténgase de etiquetar su problema Affects many people (Afecta a muchas personas) 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. + - Organization: Escriba lo que - usted quiera. Este campo no se utiliza para nada - significativo. + Category: Elija una categoría apropiada. - - Confidential: Esto se rellena - automáticamente con el literal no. - Cambiar este valor carece de sentido ya que no existe - ningún informe de problemas de &os; confidencial—la - base de datos de PR se distribuye a todo el mundo de forma - pública mediante CVSup. - + 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 sistema base). 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. - - Synopsis: 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. + Aquí una descripción de las principales categorías: - Como se avisó anteriormente, si su informe de - problemas incluye un parche, por favor incluya en la - sinopsis la etiqueta [patch] al - comienzo; si usted es un mantenedor de software, también - puede añadir la cadena [maintainer - update] y asignar el campo Class - del informe al valor - maintainer-update. - - - Severity: Los valores aceptados - son non-critical, - serious o critical. - No sea exagerado; evite etiquetar el problema como - critital a menos que sea realmente algo - crítico (e.g. escalada de permisos hacia - root, kernel panic fácilmente - reproducible). Incluso debe pensarse detenidamente - etiquetar algo como serious 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. - - - Priority: Los valores aceptados - son low, medium o - high. high debe - reservarse para problemas que afecten a la mayoría de los - usuarios de &os; y medium para aquellos - problemas que afecten a varios usuarios. + + + Si hay un problema con el kernel, las bibliotecas (como la biblioteca estándar de C libc) o en un controlador de un periférico en el sistema base, en general, utilizará la categoría kern. (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. - - Category: Seleccione uno de los - siguientes valores (extraídos de - /usr/gnats/gnats-adm/categories): - - advocacy: para problemas - relacionados con la imagen pública de &os;. Raras veces - utilizado. - - alpha: para problemas - específicos de la plataforma Alpha. + Si el problema es con un binario como sh1 o mount8, 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 whereis programname. La convención de FreeBSD para la colección de ports es instalar todo por debajo de /usr/local, aunque un administrador del sistema puede sobreescribirlo. Para estos, utilizará la categoría de ports (sí, incluso si la categoría del port es www; vea más abajo). Si la ubicación es /bin, /usr/bin, /sbin, o / usr/sbin, es parte del sistema base, y debe usar la categoría bin. Estas son todas las cosas que se describen en las secciones 1 u 8 de las páginas del manual. + - amd64: para problemas - específicos de la plataforma AMD64. + Si cree que el error está en los scripts de inicio (rc), o en algún otro tipo de archivo de configuración no ejecutable, entonces la categoría correcta es conf (configuración). Estas son las cosas que se describen en la sección 5 de las páginas del manual. + - bin: para problemas con - aplicaciones de la zona de usuario del sistema - base. + 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 docs. - - conf: para problemas de - archivos de configuración, valores por defecto, - etc. + + Si tiene un problema con un port llamado www/algunnombredeport, esto entra en la categoría de ports. + + + - - docs: para problemas con las - páginas de manual o la documentación online. - + Hay algunas categorías más especializadas. + - gnu: para problemas - realacionados con aplicaciones gnu de &os; tales como - &man.gcc.1; o &man.grep.1;. + Si el problema se catalogará en kern pero estuviera relacionado con el subsistema USB, la elección correcta es usb. + - i386: para problemas - específicos de la plataforma &i386;. + Si el problema se catalogará en kern pero estuviera relacionado con las bibliotecas de threading, la elección correcta es threads. + - ia64: para problemas - específicos de la plataforma ia64. + Si el problema se catalogará en el sistema base, pero estuviera relacionado con nuestra interpretación de estándares, como POSIX, la elección correcta es standards. + - java: para problemas - relacionados con &java;. + 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, i386 para ordenadores compatibles con Intel en modo 32 bits; amd64 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, arm o powerpc. - - kern: para problemas - relacionados con el kernel o con (no especifícos de - ninguna plataforma) controladores de - dispositivos. + + Estas categorías se utilizan con frecuencia para los problemas No lo sé. En lugar de suponer, utilice misc. + - - misc: 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). - + + Uso correcto de la categoría de arquitectura específica - - ports: para problemas - relacionados con el árbol de ports. + 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: i386 es la categoría correcta. + - - powerpc: para problemas - específicos de la plataforma &powerpc;. - + + Uso incorrecto de la categoría de arquitectura específica - - sparc64: para problemas - específicos de la plataforma &sparc64;. - - - - standards: para problemas - relativos a la adecuación con estándares. - - - - threads: para problemas - relacionados con la implementación de threads de &os; - (especialmente en &os.current;). - - - www: para cambios o mejoras - del sitio web de &os;. - - - - Class: Se puede seleccionar uno - entre los siguientes: - - - - sw-bug: bugs de software. + 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 kern es la categoría correcta. + *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***