doc/es/gnome/docs/bugging.sgml
Hiroki Sato de3f531874 www cleanup mega commit:
- Move includes.nav*.sgml to share/sgml/navibar.ent and
   <lang>/share/sgml/navibar.l10n.ent.

 - Move includes.sgml and includes.xsl to
   share/sgml/common.ent, share/sgml/header.ent, <lang>/share/sgml/l10n.ent,
   and <lang>?share/sgml/header.l10n.ent.

 - Move most of XSLT libraries to share/sgml/*.xsl and
   <lang>/share/sgml/*.xsl.

 - Move news.xml and other *.xml files for the similar purpose
   to share/sgml/*.xml and <lang>/share/sgml/*.xml.

 - Switch to use a custom DTD for HTML document.  Now we use
   "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension", which is
   HTML 4.01 + some entities previously pulled via
   "<!ENTITY % includes SYSTEM "includes.sgml"> %includes;" line.
   The location of entity file will be resolved by using catalog file.

 - Add DOCTYPE declearation to XML documents.  This makes the followings
   possible:

   * Use of &foo; entities for SGML in an XML file instead of defining
     {$foo} as the same content.

   * &symbolic; entities for Latin characters.

 - Duplicated information between SGML and XML, or English and
   translated doc, has been removed as much as possible.
2006-08-19 21:22:38 +00:00

114 lines
5.5 KiB
Text
Executable file

<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY date "$FreeBSD: www/es/gnome/docs/bugging.sgml,v 1.6 2005/10/04 07:56:17 murray Exp $">
<!ENTITY title "Proyecto FreeBSD GNOME: Reportando un Error">
<!ENTITY % navinclude.developers "INCLUDE">
]>
<html>
&header;
<h2>1. &iquest;Qu&eacute; hay que inclu&iacute;r en un informe de
error?</h2>
<p>La regla del pulgar es: incluya toda la informaci&oacute;n
posible. Incluso si cuenta con informaci&oacute;n que no sea muy
relevante, los desarrolladores puden descartarla sin problema.
Por el contrario, la situaci&oacute;n es muy complicada cuando hay
muy poca informaci&oacute;n para rastrear o repetir el problema
- en estos casos los desarrolladores deben pasar mucho tiempo
adivinando y/o preguntando a quien envi&oacute; el informe para
obtener m&aacute;s informaci&oacute;n.</p>
<p>Existe una infinidad de ejemplos de informes de errores
completamente in&uacute;tiles, algo como <i>"Hey, existe un
problema con gnomefoo. Estoy usando FreeBSD-X.Y. Por favor
arr&eacute;glenlo"</i>. De sobra esta decir que este informe es
una p&eacute;rdida de tiempo tanto para quien lo env&iacute;a
como para el desarrollador y por supuesto de ancho de banda.
Como m&iacute;nimo el informe debe contener la siguiente
informaci&oacute;n:</p>
<ul>
<li><p>La versi&oacute;n exacta del sistema operativo
(normalmente es la salida de <tt>uname -a</tt>).</p></li>
<li><p>Una lista de todos los paquetes instalados en su sistema.
</p></li>
<li><p>Sus variables de entorno (la salida de <tt>/usr/bin/env
</tt>).
<li><p>Si esta compilado desde los ports; la fecha y hora
estimada de la &uacute;ltima vez que actualiz&oacute; su
&aacute;rbol de ports.</p></li>
<li><p>Informaci&oacute;n espec&iacute;fica de cada tipo de
error: el archivo de registro (log) de una compilaci&oacute;n
fallida en el caso de que el fallo se presente al compilar un
port, un stack trace en caso de que se trate de un core dump,
una clara y detallada descripci&oacute;n del problema cuando la
aplicaci&oacute;n realiza algo inesperado, etc. Intente ponerse
en los zapatos del desarrollador y en cada caso en particular,
y evaluar que informaci&oacute;n ser&aacute; necesaria para
lograr llegar a la ra&iacute;z del problema. No asuma que
ellos ya saben del problema pero son flojos para arreglarlo.
</p></li>
</ul>
<p>Si cuenta con una soluci&oacute;n o una forma de arreglarlo,
entonces incl&uacute;yalo tambi&eacute;n en el informe,
a&uacute;n cuando no est&eacute; seguro de que sea la mejor forma
de arreglarlo. Si no lo es, le puede dar una buena idea a los
desarrolladores para enfocarlo, lo cual se traduce en ahorro
de tiempo.
</p>
<h2>2. &iquest;D&oacute;nde informar?</h2>
<p>Antes de avisar de un fallo, o incluso enviar un correo a la
lista, haga una
<a href="http://www.freebsd.org/search/search.html">b&uacute;squeda</a>
por los archivos de la lista de correo de FreeBSD GNOME, para
ver si no se ha informado ya del problema. La mayor parte de los
problemas se repiten y al realizar dicha
b&uacute;squeda puede encontrar una soluci&oacute;n m&aacute;s
r&aacute;pidamente.
</p>
<p>Una vez que est&eacute; seguro de que se trata de un nuevo
informe existen varias formas de enviar un informe de fallo en
GNOME para FreeBSD: puede enviar un informe a la
<a href="mailto:&email;@FreeBSD.org">lista de correo freebsd-gnome</a>
, rellenar un informe de fallos en el
<a href="http://www.freebsd.org/support.html#gnats">sistema de
gesti&oacute;n de informes de fallos de FreeBSD</a>,
enviar su informe a los mismos desarrolladores de GNOME, a su
<a href="http://bugzilla.gnome.org/">sistema de seguimiento de
fallos</a>, o bien una combinaci&oacute;n de estos.<p>
<p>Es pr&aacute;cticamente imposible definir una g&iacute;ua que
claramente le indique d&oacute;nde informar en cada caso
particular, por lo que debe hacer uso de su sentido
com&uacute;n; de cualquier forma estas reglas pueden serle
&uacute;tiles:</p>
<ul>
<li><p>Si es un problema espec&iacute;fico de FreeBSD (p.e.
error en checksum, fallo de un parche, error de escritura en el
Makefile del port, etc.), entonces env&iacute;elo a la lista de
correo <a href="mailto:&email;@FreeBSD.org">freebsd-gnome</a>.
</p></li>
<li><p>Si es claro que el problema no es espec&iacute;fico de
FreeBSD y no conoce la soluci&oacute;n env&iacute;elo a los
desarrolladores del software directamente:
para la mayor&iacute;a de los componentes de GNOME hay que
usar su sistema de fallos, Bugzilla).</p></li>
<li><p>Si el problema no es particular de FreeBSD pero es algo
grave y usted cuenta con una soluci&oacute;n entonces informe
a ambos; a FreeBSD y al sistema de fallos del autor, de tal
forma que el port en cuesti&oacute;n ser&aacute; arreglado y
otros usuarios de FreeBSD se beneficiar&aacute;n de su
soluci&oacute;n sin la necesidad de esperar la pr&oacute;xima
versi&oacute;n del proveedor.</p></li>
</ul>
&footer;
</body>
</html>