Release Criteria/es

From The Document Foundation Wiki
Jump to: navigation, search

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:

LibO-3.3.0 bug meta tdf#31865
LibO-3.3.1 bug meta tdf#32894
LibO-3.3.2 meta bug tdf#34404
LibO-3.3.3 meta bug tdf#35509
LibO-3.4 bug meta tdf#35673 blocker bugs (*) annoying bugs
LibO-3.5 meta bug tdf#37361 blocker bugs (*) annoying bugs

(*) 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 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 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.