From Fedora Project Wiki
No edit summary
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Mantenimiento Bugzilla de  Fedora(SOP)==
{{autolang}}
 
= Mantenimiento Bugzilla de  Fedora(SOP) =
* Esta página y las páginas asociadas explican los procesos que se utilizan para administrar ''Fedora'' http://bugzilla.redhat.com lo que se refiere al producto Fedora. Estos procesos se han creado sobre la base de las experiencias pasadas de Fedora y las necesidades futuras previstas.
* Esta página y las páginas asociadas explican los procesos que se utilizan para administrar ''Fedora'' http://bugzilla.redhat.com lo que se refiere al producto Fedora. Estos procesos se han creado sobre la base de las experiencias pasadas de Fedora y las necesidades futuras previstas.


Line 22: Line 24:
*El nuevo número de versión para la próxima versión de Fedora se añade a Bugzilla el día de disponibilidad general (GA).
*El nuevo número de versión para la próxima versión de Fedora se añade a Bugzilla el día de disponibilidad general (GA).
*Los cambios en esta política requiere la revisión y aprobación por el FESCo.
*Los cambios en esta política requiere la revisión y aprobación por el FESCo.


== Versión Rawhide ==
== Versión Rawhide ==
Line 47: Line 48:
*seguimiento de errores.
*seguimiento de errores.


=== Rastreador de errores (bloqueaddor)===
== Rastreador de errores (bloqueador) ==
Errores de seguimiento, a veces se denomina ''bloqueador'' de errores, son errores único que se utiliza para realizar un seguimiento de varios errores relacionados. Fedora utiliza generalmente los errores de seguimiento para llevar un registro de errores que deben ser corregidos en los momentos clave en el proceso de desarrollo ([[QA:SOP_blocker_bug_process|bloqueador de errores]])y los errores que corrige se aceptarán a través de períodos de congelamiento ([[QA:SOP_nth_bug_process|nice-to-have bugs]]).El BugZappers son responsables de crear los errores de seguimiento para cada versión. ver [[BugZappers/HouseKeeping/Trackers| Tracking Bugs]] para obtener una lista de los errores de seguimiento actual y el proceso en torno a la creación de ellos.
Errores de seguimiento, a veces se denomina ''bloqueador'' de errores, son errores únicos que se utilizan para realizar un seguimiento de varios errores relacionados. Fedora utiliza generalmente los errores de seguimiento para llevar un registro de errores que deben ser corregidos en los momentos clave en el proceso de desarrollo ([[QA:SOP_blocker_bug_process|bloqueador de errores]]) y los errores que corrige se aceptarán a través de períodos de congelamiento ([[QA:SOP_freeze_exception_bug_process|nice-to-have bugs]]). Los BugZappers son responsables de crear los errores de seguimiento para cada versión. Ver [[BugZappers/HouseKeeping/Trackers| Tracking Bugs]] para obtener una lista de los errores de seguimiento actual y el proceso en torno a la creación de ellos.


=== Final de la Vida (EOL) ===
== Final de la Vida (EOL) ==
*Las versiones de las actualizaciones que ya no están previstos se consideran sin mantenimiento y por lo tanto final de la vida o  comúnmente conocida como EOL.
*Las versiones de las actualizaciones que ya no están previstos se consideran sin mantenimiento y por lo tanto final de la vida o  comúnmente conocida como EOL.
*Fedora no hace un seguimiento o revisión de versiones de errores, donde no habrá más actualizaciones.
*Fedora no hace un seguimiento o revisión de versiones de errores, donde no habrá más actualizaciones.
Line 73: Line 74:
[[Category:BugTriage]]
[[Category:BugTriage]]
[[Category:BugZappers_SOPs]]
[[Category:BugZappers_SOPs]]
[[Category:Spanish translations]]

Latest revision as of 16:31, 6 February 2013

Mantenimiento Bugzilla de Fedora(SOP)

  • Esta página y las páginas asociadas explican los procesos que se utilizan para administrar Fedora http://bugzilla.redhat.com lo que se refiere al producto Fedora. Estos procesos se han creado sobre la base de las experiencias pasadas de Fedora y las necesidades futuras previstas.
  • Vea seguimiento de la pagina, que contiene enlaces a páginas para cada versión para estos procedimientos cuando corren y sea grabado.

Distribución de Tareas

Tareas para asegurarse de que las políticas de manejo de errores se enumeren a continuación sin problemas, se agrupan por cuando tengan lugar. Estas tareas también se incluyen en el calendario de lanzamientos de Fedora integral.

Versiones

  • Las pistas bugs de Fedora basado únicamente en el número de versión de la liberación o de rawhide.
    • rawhide siempre se refiere el comunicado de la actualidad en fase de desarrollo que no ha sido puesto en libertad o han llegado GA (disponibilidad general).
  • Fedora no crea versiones de Fedora separadas en Bugzilla para las versiones de prueba individual, incluyendo, pero no limitado a: alfa y beta.
    • Fedora ha probado esta estructura en el pasado, pero siempre se benefician muy poco y era difícil de mantenerlo y utilizarlo constantemente.
  • El nuevo número de versión para la próxima versión de Fedora se añade a Bugzilla el día de disponibilidad general (GA).
  • Los cambios en esta política requiere la revisión y aprobación por el FESCo.

Versión Rawhide

  • Rawhide es un número de versión único en el que se refiere a la corriente de liberación siempre en fase de desarrollo.
  • En el o alrededor del hito de la función congelar, una nueva versión está ramificada de rawhide
  • El árbol ramificado representa la nueva versión de Fedora y un número de versión correspondiente se agrega a Bugzilla.
    • Los Errores de la liberación ramificada estan realizado bajo un seguimiento en el próximo número de versión.
    • En la ramificacion, los errores asignados a la version rawhide son porcentualizada (cambiada) a la nueva version liberada ya que están más estrechamente relacionados con esa versión
    • Por ejemplo, cuando la rama de rawhide de Fedora 22, todos los errores abiertos para rawhide (con algunas ecepciones) son cambios de Fedora 22.
  • Rebasando cada ciclo de errore de rawhide, ayuda a mantener los errores relacionados con el lanzamiento (ciclo de desarrollo) que se encuentra.
    • Históricamente este fue un problema porque los errores de rawhide no están incluidas en los proceso de EOL y se mantuvo abierta indefinidamente.
    • Rebasando cada ciclo de errore de rawhide también proporciona una idea de, cómo muchos errores se presentan durante un ciclo de desarrollo dado.

Errores de Rawide excluidos del cambio de base

  • Las caracteristicas de Peticiones o las peticiones de mejoras (RFEs).
    • Las caracteristicas de las peticiones o RFEs se designan con la futura palabra clave de la característica.
  • la solicitud abierta de paquete de revisión en contra de la versión de cuero no se rebasan.
    • el Paquete de revisión de errores se presentan y se identifican mediante el componente de revisión del paquete.
  • seguimiento de errores.

Rastreador de errores (bloqueador)

Errores de seguimiento, a veces se denomina bloqueador de errores, son errores únicos que se utilizan para realizar un seguimiento de varios errores relacionados. Fedora utiliza generalmente los errores de seguimiento para llevar un registro de errores que deben ser corregidos en los momentos clave en el proceso de desarrollo (bloqueador de errores) y los errores que corrige se aceptarán a través de períodos de congelamiento (nice-to-have bugs). Los BugZappers son responsables de crear los errores de seguimiento para cada versión. Ver Tracking Bugs para obtener una lista de los errores de seguimiento actual y el proceso en torno a la creación de ellos.

Final de la Vida (EOL)

  • Las versiones de las actualizaciones que ya no están previstos se consideran sin mantenimiento y por lo tanto final de la vida o comúnmente conocida como EOL.
  • Fedora no hace un seguimiento o revisión de versiones de errores, donde no habrá más actualizaciones.
  • Todas las versiones de errores EOL se cierran automáticamente en la fecha EOL después de dar un aviso en los comentarios de errores, 30 días antes de la EOL.
  • Ver Versiones de ciclo de la vida para obtener más información acerca de cómo lanzamientos largos se mantienen y la lista de lanzamientos con su estado actual.
Note.png
Un comunicado sin mantenimiento no recibe mantenimiento o actualización de paquetes. Por lo tanto, los errores no se registran en contra de estas versiones. En el futuro vamos a buscar una mejora en bugzilla para desactivar la posibilidad de presentar errores en las versiones sin mantenimiento ya que no hay valor en hacerlo.

Revisión SOP y Proceso de Aprobación

Note.png
Esta propuesta se distribuyó para su revisión por un período de tres semanas en las listas de Fedora y revisado y aprobado por el FESCO en 2008-03-20