The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

(itstool) path: listitem/para
English
Jane Random BugBuster confirms that the bug report has sufficient information to be reproducible. If not, she goes back and forth with the reporter to obtain the needed information. At this point the bug is set to the <literal>Open</literal> state.
273/2480 · 248
Context English Spanish State
_ translator-credits Sergio Carlavilla carlavilla@FreeBSD.org, 2019
Aaron H Farias Martinez timido@ubuntu.com,2020
Problem Report Handling Guidelines Guía para el manejo de informes de problemas
FreeBSD is a registered trademark of the FreeBSD Foundation. FreeBSD es una marca registrada de FreeBSD Foundation.
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. Muchas de las designaciones utilizadas por los fabricantes y vendedores para distinguir sus productos se reclaman como marcas comerciales. Cuando esas designaciones aparecen en este documento, y el Proyecto FreeBSD estaba al tanto del reclamo de marca registrada, las designaciones han sido seguidas por el <quote>™</quote> o el <quote>®</quote> símbolo.
$FreeBSD: head/en_US.ISO8859-1/articles/pr-guidelines/article.xml 51348 2017-12-30 22:56:56Z eadler $ $FreeBSD: head/en_US.ISO8859-1/articles/pr-guidelines/article.xml 51348 2017-12-30 22:56:56Z eadler $
These guidelines describe recommended handling practices for FreeBSD Problem Reports (PRs). Whilst developed for the FreeBSD PR Database Maintenance Team <email>freebsd-bugbusters@FreeBSD.org</email>, these guidelines should be followed by anyone working with FreeBSD PRs. Esta guía describe las prácticas recomendadas para manejar los informes de problemas (PRs) de FreeBSD. Aunque se desarrolló para el FreeBSD PR database maintenance team <email>freebsd-bugbusters@FreeBSD.org</email>, cualquiera que trabaje con PRs de FreeBSD debe seguir estas pautas.
<personname><firstname>Dag-Erling</firstname><surname>Smørgrav</surname></personname> <personname><firstname>Dag-Erling</firstname><surname>Smørgrav</surname></personname>
<personname><firstname>Hiten</firstname><surname>Pandya</surname></personname> <personname><firstname>Hiten</firstname><surname>Pandya</surname></personname>
Introduction Introducción
Bugzilla is an issue management system used by the FreeBSD Project. As accurate tracking of outstanding software defects is important to FreeBSD's quality, the correct use of the software is essential to the forward progress of the Project. Bugzilla es un sistema de gestión de errores utilizado por el proyecto FreeBSD. Un seguimiento preciso de los defectos de software pendientes es importante para la calidad de FreeBSD, el uso correcto del software es esencial para el progreso del proyecto.
Access to Bugzilla is available to the entire FreeBSD community. In order to maintain consistency within the database and provide a consistent user experience, guidelines have been established covering common aspects of bug management such as presenting followup, handling close requests, and so forth. El acceso a Bugzilla está disponible para toda la comunidad de FreeBSD. Con el fin de mantener la coherencia dentro de la base de datos y proporcionar una experiencia de usuario consistente, se han establecido pautas que cubren aspectos comunes de la gestión de errores, como la presentación del seguimiento, el manejo de las solicitudes de cierre, etc.
Problem Report Life-cycle Ciclo de vida de un informe de problemas
The Reporter submits a bug report on the website. The bug is in the <literal>Needs Triage</literal> state. El usuario envía un informe de error al sitio web. El error está en el estado <literal>Needs Triage</literal>.
Jane Random BugBuster confirms that the bug report has sufficient information to be reproducible. If not, she goes back and forth with the reporter to obtain the needed information. At this point the bug is set to the <literal>Open</literal> state. Jane Random BugBuster confirma que el error reportado tiene la suficiente información para ser reproducido. Si no, se interactuará repetidamente con el usuario para obtener la información necesaria. En este punto, el error se establece en el estado <literal>Open</literal>.
Joe Random Committer takes interest in the PR and assigns it to himself, or Jane Random BugBuster decides that Joe is best suited to handle it and assigns it to him. The bug should be set to the <literal>In Discussion</literal> state. Joe Random Committer se interesa por el PR y se lo asigna a si mismo, o Jane Random BugBuster decide que Joe es la persona más adecuada para resolver el problema y le asigna error. El error se debe poner en el estado <literal>In Discussion</literal>.
Joe has a brief exchange with the originator (making sure it all goes into the audit trail) and determines the cause of the problem. Joe tiene una breve conversación con el usuario que ha enviado el informe del problema (asegurándose de que todo queda registrado) y determina la causa.
Joe pulls an all-nighter and whips up a patch that he thinks fixes the problem, and submits it in a follow-up, asking the originator to test it. He then sets the PRs state to <literal>Patch Ready</literal>. Joe está toda la noche trabajando y elabora un parche que cree que soluciona el problema, y lo envía en un follow-up, pidiéndole al usuario que lo ha enviado que lo pruebe. A continuación, fija el estado del PR en <literal>Patch Ready</literal>.
A couple of iterations later, both Joe and the originator are satisfied with the patch, and Joe commits it to <literal>-CURRENT</literal> (or directly to <literal>-STABLE</literal> if the problem does not exist in <literal>-CURRENT</literal>), making sure to reference the Problem Report in his commit log (and credit the originator if they submitted all or part of the patch) and, if appropriate, start an MFC countdown. The bug is set to the <literal>Needs MFC</literal> state. Un par de iteraciones más tarde, tanto Joe como el usuario que lo ha creado están satisfechos con el parche, y Joe realiza el commit a <literal>-CURRENT</literal> (o directamente a <literal>-STABLE</literal> si el problema no existe en <literal>-CURRENT</literal>), asegurándose de hacer referencia al informe de problemas en su log del commit (y dando el crédito al usuario si envió todo o parte del parche) y, si corresponde, iniciará una cuenta atrás de MFC. El error se fija en el estado <literal>Needs MFC</literal>.
If the patch does not need MFCing, Joe then closes the PR as <literal>Issue Resolved</literal>. Si el parche no necesita pasar por un MFC, Joe entonces cierra el PR con el estado <literal>Issue Resolved</literal>.
Many PRs are submitted with very little information about the problem, and some are either very complex to solve, or just scratch the surface of a larger problem; in these cases, it is very important to obtain all the necessary information needed to solve the problem. If the problem contained within cannot be solved, or has occurred again, it is necessary to re-open the PR. Muchos PRs son enviados con muy poca información sobre el problema, y algunos son muy complejos de resolver, o simplemente arañan la superficie de un problema mayor; en estos casos, es muy importante obtener toda la información necesaria para resolver el problema. Si el problema no se puede resolver, o si ha ocurrido nuevamente, es necesario volver a abrir el PR.
Problem Report State Estados de los informes de problemas
It is important to update the state of a PR when certain actions are taken. The state should accurately reflect the current state of work on the PR. Es importante actualizar el estado de un PR cuando se toman ciertas acciones. El estado debe reflejar con precisión la situación actual del trabajo en el PR.
A small example on when to change PR state Un pequeño ejemplo de cuándo cambiar el estado de un PR
When a PR has been worked on and the developer(s) responsible feel comfortable about the fix, they will submit a followup to the PR and change its state to <quote>feedback</quote>. At this point, the originator should evaluate the fix in their context and respond indicating whether the defect has indeed been remedied. Cuando un PR haya sido tratado y el desarrollador/es se sienta cómodo con la solución, enviará un follow-up al PR y cambiará su estado a <quote>feedback</quote>. En este punto, el usuario que lo ha creado debe evaluar la solución en su contexto y responder indicando si el defecto ha sido solucionado.
A Problem Report may be in one of the following states: Un informe de problemas puede estar en uno de los siguientes estados:
open Abrir
Initial state; the problem has been pointed out and it needs reviewing. Estado inicial; el problema ha sido indicado y necesita ser revisado.
analyzed analizar
The problem has been reviewed and a solution is being sought. El problema ha sido revisado y se está buscando una solución.

Loading…

User avatar None

New source string

FreeBSD Doc (Archived) / articles_pr-guidelines — Spanish

New source string a year ago
Browse all component changes

Glossary

English Spanish
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: listitem/para
Source string location
article.translate.xml:67
String age
a year ago
Source string age
a year ago
Translation file
articles/es_ES/pr-guidelines.po, string 14