Release Criteria/es

Libreoffice usa un un plan de lanzamiento basado en tiempo. No espera por mejoras, o por arreglos a bugs - pero esta basado (tan puro como posible) en tiempo. Esto estimula la diciplina de introducir mejoras, da predictibilidad y permite un lanzamiento continuo. Este modelo ha demostrado tener la mejor calidad para el software libre.

Los lanzamientos basados en tiempo vuelve feliz a todo tipo de usuarios. Entusiastas comienzan a usar X.Y.0 lanzamientos con hermosas nuevas mejoras bugs identificados. Cuanto mas usuarios conservadores son mas atraidos a las frecuentes y puros lanzamiento de arreglos. Aun con los usuarios mas conservadores se satisface por un lanzamiento de arreglo de bug, e.g. X.Y.3.

Criterio
Los lanzamientos de candidatos pueden ser marcados como final cuando:


 * están públicamente disponibles por los ultimos 10 días si ningún bug bloqueador se reporta

Nominar un bog bloqueador
Fija la severidad: bloqueador, y comenta la dependencia con el bug meta:

(*) Checar tambien todos los bugs bloqueadores.

IMPORTANTE: El bug meta es llamado bugs mas incomodos. Estos listan bugs que molestan a muchas personas y se les da lanzamientos X.Y. Estos ayudan a los desarrolladores a prioritizar el trabajo pero muchos de los bugs no afectan a la fecha del lanzamiento. Solo bugs con la severidad de bloqueador podría retrazar el lanzamiento.

Nota que los comentarios son automaticamente enviados a la lista de correo de [mailto:libreoffice@lists.freedesktop.org libreoffice].

Definición del bug bloqueador
Any software has bugs. All bugs can't be fixed otherwise the product would never get released. Bugs that could block the release must have one of the following symptoms:


 * app can not be installed
 * app does not start
 * data loss
 * crash
 * freeze
 * security bug
 * license problem
 * unusable function

Also some normal bugs might have the above symptoms. The real blockers must fulfill also the following conditions:


 * problem must be reproducible by more users; if it is not reproducible, it  is most likely a problem on the user side; also developers need more  information from the reporter; it is not fair to block the release and  all users if the reporter does not provide the needed information on  time
 * broken functionality must be regression against the last released version; if it was not reported early, it is a rarely  used function and the fix could wait until the next release;
 * data loss in import/export filters must be regression against released  versions; LibO has very good import/export filters from/into many file  formats; they are improved in every release but they are never 100%;  sometimes they even depend on a missing functionality; if the problem is  not a regression, it is considered as a feature and thus it is not a  blocker
 * problem must affect most users or there must not be a reasonable workaround; it is bad to block the  release and all users because of a corner case when a reasonable  workaround exists

Note that the above definition can not be taken too strictly. Every nominated bug will be considered per basis on the [mailto:libreoffice@lists.freedesktop.org libreoffice]  mailing list. This does not mean that other bugs are not fixed during the release candidate phase. If the release is blocked, anyone could still add safe fixes for other critical bugs.