Cómo enviar un informe

Informes sobre problemas en «versiones finales» (release).

Antes de enviar informes sobre errores o problemas en las versiones finales de OpenSSH, mire esta lista de comprobaciones:

1. Mire en la página de parches y anotaciones sobre OpenSSH.
2. Averigüe si hay una versión nueva ya disponible para OpenBSD, o para la versión portable, dependiendo de su plataforma.
3. Revise las Preguntas Frecuentes en busca de problemas reportados con frecuencia como errores, pero que no lo son.
4. Revise la lista de errores corregidos desde la última versión liberada y errores conocidos reportados desde la última versión liberada.

Si nada de esto tiene que ver con su problema, entonces haga uso de Bugzilla para enviar un informe de error (pero antes lea la información que sigue sobre los informes en privado de errores de seguridad).

Se puede contactar directamente con los desarrolladores de OpenSSH enviando un mensaje a una de las siguientes direcciones:

• openssh@openssh.com. Es una lista privada de sólo lectura para los desarrolladores de OpenSSH.
  Es apropiada para: informes sobre problemas con OpenSSH en OpenBSD, e informes sobre problemas de seguridad en cualquier plataforma.
  No es apropiada para: preguntas tipo cómo se hace, informes de problemas en sistemas que no sean OpenBSD o con parches procedentes de terceras partes, ni para discusiones de carácter general.
• openssh-unix-dev@mindrot.org Es una lista pública abierta para usuarios, sin necesidad de suscripción.
  Es apropiada para: informes sobre errores, preguntas tipo cómo se hace y discusiones sobre OpenSSH en cualquier plataforma (incluido OpenBSD).
  No es apropiada para: informes sobre problemas de seguridad, informes sobre errores de binarios que no hayan sido suministrados por el equipo de OpenBSD (a menos que el error pueda ser reproducido con una distribución normal de OpenSSH).

Informes sobre problemas en «versiones de desarrollo» (current).

1. Verifique el problema un par de veces como mínimo, con el código fuente actualizado con un par de días de diferencia.
2. No envíe informes sobre problemas de compilación con el árbol de fuentes, a menos que persistan. La mayoría de las veces, estos problemas son un fallo del usuario o ya se encuentra alguien trabajando sobre ellos en ese momento.
3. Recuerde que los servidores de anoncvs se actualizan con una diferencia de tiempo significativa con respecto al árbol de fuentes.
4. Compruebe los cambios en OpenSSH para ver si ya se ha solucionado el problema.

Envío de los informes.

Intente ser directo y conciso. No dé instrucciones vagas o poco detalladas como «se cuelga». Hable con otros usuarios en IRC o use algún otro recurso como los archivos de la lista de correo para confirmar que es un problema nuevo, repetible, etc... y asegúrese de que no es un problema en su sistema.

Vea Cómo reportar errores con efectividad de Simon Tatham, una excelente descripción del arte de reportar errores. Recuerde, entre mejor sea la información en su reporte, mayores son las oportunidades de que su problema sea resuelto.

Se aceptan las sugerencias sobre nuevas funcionalidades, especialmente si éstas van acompañadas por código que implemente la característica sugerida. Si alguien escribe el código para la nueva funcionalidad en su lugar, lo más probable es que no se entienda bien y que lo haga para que no pueda reconocerlo.

Tipos de informes sobre errores en orden de preferencia:

1. Los problemas reiterativos con parches para el código fuente son los mejores.
2. Los problemas reiterativos que no sean específicos de la composición de su hardware/software.
3. Los problemas reiterativos que sean específicos de la composición de su software.
4. Los problemas reiterativos que sean específicos de la composición de su hardware.