git: 694907d96e - main - [doc-es]: Add freebsd-releng article translation

The branch main has been updated by fernape:

URL: https://cgit.FreeBSD.org/doc/commit/?id=694907d96ef1d75339155d6efee0d60d825007ff

commit 694907d96ef1d75339155d6efee0d60d825007ff
Author:     Fernando Apesteguía <fernape@FreeBSD.org>
AuthorDate: 2022-01-12 15:54:19 +0000
Commit:     Fernando Apesteguía <fernape@FreeBSD.org>
CommitDate: 2022-01-13 07:03:31 +0000

    [doc-es]: Add freebsd-releng article translation
---
 .../content/es/articles/freebsd-releng/_index.adoc |  802 +++++++
 .../content/es/articles/freebsd-releng/_index.po   | 2340 ++++++++++++++++++++
 2 files changed, 3142 insertions(+)

diff --git a/documentation/content/es/articles/freebsd-releng/_index.adoc b/documentation/content/es/articles/freebsd-releng/_index.adoc
new file mode 100644
index 0000000000..e1614931a8
--- /dev/null
+++ b/documentation/content/es/articles/freebsd-releng/_index.adoc
@@ -0,0 +1,802 @@
+---
+authors:
+  - 
+    author: 'Glen Barber'
+    email: gjb@FreeBSD.org
+description: 'Describe la aproximación utilizada por el equipo de ingeniería de versiones de FreeBSD para producir versiones de calidad de producción del Sistema Operativo FreeBSD. Describe las herramientas disponibles para aquellos que estén interesados en producir versiones personalizadas de FreeBSD para lanzamientos corporativos o productos comerciales'
+organizations:
+  - 
+    organization: 'The FreeBSD Foundation'
+    webpage: https://www.freebsdfoundation.org/
+  - 
+    organization: 'Rubicon Communications, LLC (Netgate)'
+    webpage: https://www.netgate.com/
+tags: ["releases", "engineering", "process", "FreeBSD"]
+title: 'Ingeniería de versiones de FreeBSD'
+trademarks: ["freebsd", "intel", "general"]
+---
+
+= Ingeniería de versiones de FreeBSD
+:doctype: article
+:toc: macro
+:toclevels: 1
+:icons: font
+:sectnums:
+:sectnumlevels: 6
+:source-highlighter: rouge
+:experimental:
+:teamBugmeister: FreeBSD Bugmeister Team
+:teamDoceng: FreeBSD Documentation Engineering Team
+:teamPortmgr: FreeBSD Ports Management Team
+:teamPostmaster: FreeBSD Postmaster Team
+:teamRe: FreeBSD Release Engineering Team
+:teamSecteam: FreeBSD Security Team
+:branchHead: head/
+:branchStable: stable/
+:branchStablex: stable/12/
+:branchReleng: releng/
+:branchRelengx: releng/12.0/
+:branchReleasex: release/12.0.0/
+:branchRevision: 12.0
+
+:images-path: articles/freebsd-releng/
+
+ifdef::env-beastie[]
+ifdef::backend-html5[]
+include::shared/authors.adoc[]
+include::shared/mirrors.adoc[]
+include::shared/releases.adoc[]
+include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[]
+:imagesdir: ../../../images/{images-path}
+endif::[]
+ifdef::backend-pdf,backend-epub3[]
+include::../../../../shared/asciidoctor.adoc[]
+endif::[]
+endif::[]
+
+ifndef::env-beastie[]
+include::../../../../../shared/asciidoctor.adoc[]
+endif::[]
+
+[.abstract-title]
+Resumen
+
+Este artículo describe el proceso detrás del modelo de ingeniería de versiones adoptado por el Proyecto FreeBSD.
+
+[NOTE]
+====
+Este documento todavía no ha sido actualizado para describir los procedimientos actuales del equipo de Ingeniería de Versiones de FreeBSD que siguieron a la transición de Subversion a Git.
+====
+
+'''
+
+toc::[]
+
+[[introduction]]
+== Introducción al Proceso de Ingeniería de Versiones de FreeBSD
+
+El desarrollo de FreeBSD tiene un flujo de trabajo muy específico. En general, todos los cambios en el sistema base de FreeBSD se hacen en la rama {branchHead}, que representa la cima del árbol de fuentes.
+
+Después de un periodo de pruebas razonable, los cambios se pueden integrar en las ramas {branchStable}. El tiempo mínimo por defecto para integrar cambios en las ramas {branchStable} es de tres (3) días.
+
+A pesar de la regla general de esperar un mínimo de tres días antes de integrar cambios desde {branchHead}, hay algunas circunstancias especiales bajo las cuales una integración inmediata puede ser necesaria, como arreglos críticos de seguridad, o un arreglo de un fallo que directamente imposibilita el proceso de generación de versiones.
+
+Después de varios meses, y de que el número de cambios en la rama {branchStable} haya crecido significativamente, es hora de liberar la siguiente versión de FreeBSD. Estas versiones han sido denominadas históricamente como versiones punto ("point" releases).
+
+Entre las versiones de las ramas {branchStable}, aproximadamente cada dos (2) años, se sacará una versión directamente desde {branchHead}. Estas versiones se han denominado históricamente como versiones "punto cero" ("dot-zero" releases).
+
+Este artículo resaltará el flujo de trabajo y responsabilidades del {teamRe} tanto para las versiones "dot-zero" como las versiones "point".
+
+Las siguientes secciones de este artículo describen:
+
+<<releng-prep>>::
+Información general y preparación antes de comenzar el ciclo de lanzamiento.
+
+<<releng-website>>::
+Cambios en el Sitio Web Durante el Ciclo de Liberación
+
+<<releng-terms>>::
+Terminología e información general, tales como "code slush" y "code freeze", usados en este documento.
+
+<<releng-head>>::
+El proceso de Ingeniería de Versiones para una versión "dot-zero".
+
+<<releng-stable>>::
+El proceso de Ingeniería de Versiones para una versión "point".
+
+<<releng-building>>::
+Información relacionada con los procedimientos específicos para construir el medio de instalación.
+
+<<releng-mirrors>>::
+Procedimientos para publicar un medio de instalación.
+
+<<releng-wrapup>>::
+Terminando el ciclo de lanzamiento.
+
+[[releng-prep]]
+== Información General y Preparación
+
+Aproximadamente dos meses antes del ciclo de lanzamiento, el {teamRe} decide una programación para la versión. La programación incluye varios hitos en el ciclo de lanzamiento como fechas de congelación, fechas para ramificación y fechas para construcción. Por ejemplo:
+
+[.informaltable]
+[cols="1,1", frame="none", options="header"]
+|===
+| Hito
+| Fecha Prevista
+
+|{branchHead} slush:
+|May 27, 2016
+
+|{branchHead} freeze:
+|June 10, 2016
+
+|{branchHead} KBI freeze:
+|June 24, 2016
+
+|`doc/` tree slush [1]:
+|June 24, 2016
+
+|Ports quarterly branch [2]:
+|July 1, 2016
+
+|{branchStablex} branch:
+|July 8, 2016
+
+|`doc/` tree tag [3]:
+|July 8, 2016
+
+|BETA1 build starts:
+|July 8, 2016
+
+|{branchHead} thaw:
+|July 9, 2016
+
+|BETA2 build starts:
+|July 15, 2016
+
+|BETA3 build starts [*]:
+|July 22, 2016
+
+|{branchRelengx} branch:
+|July 29, 2016
+
+|RC1 build starts:
+|July 29, 2016
+
+|{branchStablex} thaw:
+|July 30, 2016
+
+|RC2 build starts:
+|August 5, 2016
+
+|Final Ports package builds [4]:
+|August 6, 2016
+
+|Ports release tag:
+|August 12, 2016
+
+|RC3 build starts [*]:
+|August 12, 2016
+
+|RELEASE build starts:
+|August 19, 2016
+
+|RELEASE announcement:
+|September 2, 2016
+|===
+
+[NOTE]
+====
+Los elementos marcados con "[*]" identifican los pasos realizados solo "cuando sean necesarios".
+====
+
+. El "slush" (semi congelación) del árbol `doc/` está coordinado por el {teamDoceng}.
+. La rama trimestral de Ports que se va a ser utilizada se determina por el momento en el que se planifica la construcción de la `RC`final. Una nueva rama trimestral es creada el primer día del trimestre, por lo que se debería usar esta métrica cuando se consideren los hitos del ciclo de lanzamiento. La rama trimestral es creada por el {teamPortmgr}.
+. El árbol `doc/` es etiquetado por el {teamDoceng}.
+. La construcción final de los paquetes de Ports es realizada por el {teamPortmgr} después de la construcción `RC` definitiva (o lo que se espera que sea la definitiva).
+
+[NOTE]
+====
+Si la versión se está creando a partir de una rama {branchStable} existente, la fecha de congelación del KBI (Kernel Binary Interface) se puede excluir, ya que el KBI ya se considera congelado en ramas {branchStable} establecidas.
+====
+
+Al escribir el programa del ciclo de lanzamientos, se deben tener en cuenta varias cosas, en particular, los hitos en los que la fecha objetivo depende de los hitos predefinidos de los que exista una dependencia. Por ejemplo, la etiqueta de la Colección de Ports se obtiene de la rama trimestral que esté activa en el momento de la última fase `RC`. Esto, en parte, define qué rama trimestral se usa, cuándo se puede realizar la etiqueta y qué revisión del árbol de ports se usa para la compilación final de `RELEASE`.
+
+Después de un acuerdo general sobre la programación, el {teamRe} envía un correo electrónico con la programación a los Desarrolladores de FreeBSD.
+
+Es algo típico que muchos desarrolladores informen al {teamRe} sobre varios trabajos en curso. En algunos casos, se solicitará una extensión del trabajo en curso y en otros casos, se hará una petición de "blanket approval" (aprobación total) para un subconjunto particular del árbol.
+
+Cuando se hacen tales solicitudes, es importante asegurarse de que se discutan los plazos (incluso si se estiman). Para las aprobaciones generales, el período de tiempo para la aprobación general debe quedar claro. Por ejemplo, un desarrollador de FreeBSD puede solicitar una aprobación general desde el principio del slush del código hasta el inicio de la compilación de la `RC`.
+
+[NOTE]
+====
+Para realizar el seguimiento de los "blanket approvals", el {teamRe} usa un repositorio interno para mantener un registro de esas peticiones, el cual define el área sobre la que se aprueba el "blanket approval", los autores, cuando expira la aprobación y la razón por la que fue concedido. Un ejemplo de esto es aprobar "blanket approval" para [.filename]#release/doc/# para todos los miembros de {teamRe} hasta la `RC` definitiva con el fin de actualizar las notas de la versión y otra documentación relacionada con ella.
+====
+
+[NOTE]
+====
+El equipo de ingeniería de versiones de FreeBSD también utiliza este repositorio para rastrear las solicitudes de aprobación pendientes que se reciben justo antes de empezar el ciclo de compilaciones del lanzamiento, que el ingeniero de lanzamientos especifica el período límite con un correo electrónico a los desarrolladores de FreeBSD.
+====
+
+Dependiendo del conjunto de código que haya por debajo y el impacto tal que el conjunto de código tienen en FreeBSD como un todo, esas peticiones pueden ser aprobadas o denegadas por el {teamRe}.
+
+Lo mismo se aplica al trabajo que haya en progreso. Por ejemplo, en el caso del desarrollo de un nuevo controlador, el cual está aislado del resto del árbol del código fuente, podría tener una extensión de tiempo. Sin embargo, en el caso de un nuevo planificador de procesos, puede no ser viable, en especial si los cambios no están en otra rama.
+
+El programa también se añade a la página web del Proyecto, en el repositorio `doc/`, en [.filename]#~/website/content/en/releases/{branchRevision}R/schedule.adoc#. Este fichero se actualiza continuamente según progresa el ciclo de lanzamiento.
+
+[NOTE]
+====
+La mayor parte de las veces, el fichero the [.filename]#schedule.adoc# se puede copiar de una versión anterior y actualizarlo como corresponda.
+====
+
+Además de añadir [.filename]#schedule.adoc# al sitio web, también se actualiza [.filename]#~/shared/releases.adoc# para añadir el enlace al programa a las distintas subpáginas, así como habilitar el enlace al programa en la página índice del sitio web del Proyecto.
+
+El programa también se enlaza desde [.filename]#~/website/content/en/releng/_index.adoc#.
+
+Aproximadamente un mes antes del "code slush" planificado, el {teamRe} envía un correo electrónico recordatorio a los Desarrolladores de FreeBSD.
+
+[[releng-terms]]
+== Terminología de la Ingeniería de Versiones
+
+Esta sección describe parte de la terminología utilizada en el resto de este documento.
+
+[[releng-terms-code-slush]]
+=== El Code Slush
+
+Aunque el code slush no es una congelación completa del árbol, el {teamRe} solicita que los fallos existentes en el código base tengan prioridad sobre las nuevas características.
+
+El code slush no impone aprobaciones en los commits a la rama.
+
+[[releng-terms-code-freeze]]
+=== La Congelación del Código
+
+La congelación del código marca el punto en el tiempo en el que todos los commits a la rama requieren una aprobación explícita por parte del {teamRe}.
+
+El repositorio de Subversion de FreeBSD tiene varios hooks para realizar comprobaciones de integridad antes de que se haga cualquier commit al árbol del código fuente. Uno de esos hooks evaluará si realizar el commit a una rama en particular requiere de aprobación específica.
+
+Para forzar la aprobación de los commits por parte del {teamRe}, el Ingeniero de Lanzamiento actualiza [.filename]#base/svnadmin/conf/approvers# y lo escribe en el repositorio. Una vez hecho esto, cualquier cambio en la rama debe incluir una línea "Approved by:" en el mensaje de commit.
+
+La línea "Approved by:" debe coincidir con la segunda columna del archivo [.filename]#base/svnadmin/conf/approvers#, de lo contrario, el commit será rechazado por los hooks del repositorio.
+
+[NOTE]
+====
+Durante la congelación de código, se insta a los committers de FreeBSD a seguir las link:https://wiki.freebsd.org/Releng/ChangeRequestGuidelines[Change Request Guidelines].
+====
+
+[[releng-terms-kbi-freeze]]
+=== La Congelación del KBI/KPI
+
+La estabilidad de KBI/KPI implica que llamar a una función a través de dos versiones de software diferentes den el mismo resultado. Quien llama, ya sea un proceso, un subproceso o una función, espera que la función se comporte de cierta forma, de lo contrario, la estabilidad de KBI/KPI en la rama se ve afectada.
+
+[[releng-website]]
+== Cambios en el Sitio Web Durante el Ciclo de Liberación
+
+Esta sección describe los cambios que deberían de ocurrir en el sitio web a medida que avanza el ciclo de lanzamiento.
+
+[NOTE]
+====
+Los ficheros especificados en esta sección son relativos a la rama `head/` del repositorio `doc` en Subversion.
+====
+
+[[releng-website-prerelease]]
+=== Cambios en el Sitio Web Antes de que Empiece el Ciclo de Lanzamiento
+
+Cuando el programa del ciclo de lanzamientos está disponible, estos archivos deben actualizarse para habilitar varias funcionalidades diferentes en la web del Proyecto FreeBSD:
+
+[.informaltable]
+[cols="1,1", frame="none", options="header"]
+|===
+| Fichero a Editar
+| Qué Cambiar
+
+|[.filename]#~/shared/releases.adoc#
+|Cambiar `beta-upcoming` de `IGNORE` a `INCLUDE`
+
+|[.filename]#~/shared/releases.adoc#
+|Cambiar `beta-testing` de `IGNORE` a `INCLUDE`
+
+|===
+
+[[releng-website-beta-rc]]
+=== Cambios del Sitio Web Durante `BETA` o `RC`
+
+Cuando se transita de `PRERELEASE` a `BETA`, estos ficheros necesitan ser actualizados para habilitar el bloque "Help Test" en la página de descargas. Todos los ficheros son relativos a [.filename]#head/# en el repositorio `doc`:
+
+[.informaltable]
+[cols="1,1", frame="none", options="header"]
+|===
+| Fichero a Editar
+| Qué Cambiar
+
+|[.filename]#share/releases.adoc#
+|Actualizar `betarel-vers` a `BETA__1__`
+
+|[.filename]#~/website/data/en/news/news.toml#
+|Añadir una entrada anunciando la `BETA`
+
+|[.filename]#~/website/static/security/advisory-template.txt#
+|Añadir la nueva `BETA`, `RC`, o `RELEASE` final a la plantilla
+
+|[.filename]#~/website/static/security/errata-template.txt#
+|Añadir la nueva `BETA`, `RC`, o `RELEASE` final a la plantilla
+|===
+
+Una vez que se crea la rama {branchRelengx}, se necesita generar los distintos documentos relativos a la versión y añadirlos manualmente al repositorio `doc/`.
+
+En [.filename]#release/doc#, invoca para generar las páginas [.filename]#errata.html#, [.filename]#hardware.html#, [.filename]#readme.html#, y [.filename]#relnotes.html#, las cuales son añadidas luego a [.filename]#doc/head/en_US.ISO8859-1/htdocs/releases/X.YR/#, donde _X.Y_ representan los números de versión mayor y menor del lanzamiento.
+
+Se debe establecer la propiedad `fbsd:nokeywords` en los nuevos ficheros añadidos para que los hooks de pre-commit los añadan al repositorio.
+
+[NOTE]
+====
+Los documentos relevantes relacionados con una versión están en el repositorio [.filename]#doc# para FreeBSD 12.x y posteriores.
+====
+
+[[releng-ports-beta-rc]]
+=== Cambios en los Ports durante `BETA`, `RC`, y la `RELEASE` Final
+
+Para cada construcción durante el ciclo de lanzamiento, los ficheros `MANIFEST` que contienen el SHA256` de los distintos conjuntos de distribuciones, como `base.txz`, `kernel.txz` y demás son añadidos al port package:misc/freebsd-release-manifests[]. Esto permite a otras utilidades, como package:ports-mgmt/poudriere[], utilizar estos conjuntos de distribuciones de forma segura al proporcionar un mecanismo mediante el cual verificar los checksums.
+
+[[releng-head]]
+== Versiones desde {branchHead}
+
+Esta sección describe los procedimientos generales del ciclo de lanzamiento de FreeBSD desde la rama {branchHead}.
+
+[[releng-head-builds-alpha]]
+=== Construcciones FreeBSD "`ALPHA`"
+
+El concepto de construcción "`ALPHA`" se introdujo en el ciclo de FreeBSD 10.0-RELASE. A diferencia de las construcciones `BETA` y `RC`, las construcciones `ALPHA` no están incluidas en la programación de lanzamientos de FreeBSD.
+
+La idea detrás de las construcciones `ALPHA` es proporcionar construcciones regulares de FreeBSD antes de la creación de la rama {branchStable}.
+
+Las instantáneas FreeBSD `ALPHA` se deberían construir aproximadamente una vez a la semana.
+
+Para la primera construcción `ALPHA`, el valor `BRANCH` en [.filename]#sys/conf/newvers.sh# tiene que cambiarse de `CURRENT` a `ALPHA1`. Para las siguientes construcciones `ALPHA`, incrementa cada valor `ALPHA__N__` en uno.
+
+Visita <<releng-building>> para obtener información acerca de cómo construir imágenes `ALPHA`.
+
+[[releng-head-branching]]
+=== Creando la Rama {branchStablex}
+
+A la hora de crear la rama {branchStable} , se necesitan varios cambios tanto en la nueva rama {branchStablex} como en la rama {branchHead} . Los ficheros indicados son relativos a la raíz del repositorio. Para crear una nueva rama {branchStablex} en Subversion:
+
+[source, shell, subs="attributes"]
+....
+% svn cp ^/head {branchStablex}
+....
+
+Una vez que la rama {branchStablex} ha sido escrita en el repositorio, haz los siguientes cambios:
+
+[.informaltable]
+[cols="1,1", frame="none", options="header"]
+|===
+| Fichero a Editar
+| Qué Cambiar
+
+|[.filename]#stable/12/UPDATING#
+|Actualizar la versión de FreeBSD y eliminar la nota acerca de `WITNESS`
+
+|[.filename]#stable/12/contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h#
+a|
+
+[source, shell, subs="attributes"]
+.... #ifndef MALLOC_PRODUCTION #define MALLOC_PRODUCTION #endif .... |[.filename]#stable/12/lib/clang/llvm.build.mk# |Descomentar `-DNDEBUG` |[.filename]#stable/12/sys/\*/conf/GENERIC*# |Eliminar soporte de depuración |[.filename]#stable/12/sys/*/conf/MINIMAL# |Eliminar soporte de depuración |[.filename]#stable/12/release/release.conf.sample# |Actualizar `SRCBRANCH` |[.filename]#stable/12/sys/*/conf/GENERIC-NODEBUG# |Eliminar estas configuraciones del núcleo |[.filename]#stable/12/sys/arm/conf/std.arm*# |Eliminar opciones de depuración |[.filename]#stable/12/sys/conf/newvers.sh# |Actualizar el valor de `BRANCH` para reflejar `BETA1` |[.filename]#stable/12/share/mk/src.opts.mk# |Mover `REPRODUCIBLE_BUILD` de `\__DEFAULT_NO_OPTIONS` a `__DEFAULT_YES_OPTIONS` |[.filename]#stable/12/share/mk/src.opts.mk# |Mover `LLVM_ASSERTIONS` de `\__DEFAULT_YES_OPTIONS` a `__DEFAULT_NO_OPTIONS` (sólo FreeBSD 13.x y posteriores) |[.filename]#stable/12/libexec/rc/rc.conf# |Cambiar `dumpdev` de `AU
 TO` a `NO` (es configurable para aquellos que lo quieren activado por defecto) |[.filename]#stable/12/release/Makefile# |Eliminar las entradas `debug.witness.trace`
+|===
+
+Después, en la rama {branchHead} , que se convertirá en una nueva versión mayor:
+
+[.informaltable]
+[cols="1,1", frame="none", options="header"]
+|===
+| Fichero a Editar
+| Qué Cambiar
+
+|[.filename]#head/UPDATING#
+|Actualizar la versión de FreeBSD
+
+|[.filename]#head/sys/conf/newvers.sh#
+|Actualizar el valor de `BRANCH` para reflejar `CURRENT`, e incrementar `REVISION`
+
+|[.filename]#head/Makefile.inc1#
+|Actalizar `TARGET_TRIPLE` y `MACHINE_TRIPLE`
+
+|[.filename]#head/sys/sys/param.h#
+|Actualizar `__FreeBSD_version`
+
+|[.filename]#head/gnu/usr.bin/cc/cc_tools/freebsd-native.h#
+|Actualizar `FBSD_MAJOR` y `FBSD_CC_VER`
+
+|[.filename]#head/contrib/gcc/config.gcc#
+|Añadir la sección `freebsdversion.h`
+
+|[.filename]#head/lib/clang/llvm.build.mk#
+|Actualizar el valor de `OS_VERSION`
+
+|[.filename]#head/lib/clang/freebsd_cc_version.h#
+|Actualizar `FREEBSD_CC_VERSION`
+
+|[.filename]#head/lib/clang/include/lld/Common/Version.inc#
+|Actualizar `LLD_REVISION_STRING`
+
+|[.filename]#head/Makefile.libcompat#
+|Actualizar `LIB32CPUFLAGS`
+|===
+
+[[releng-stable]]
+== Versiones desde {branchStable}
+
+Esta sección describe los procedimientos generales del ciclo de lanzamiento de FreeBSD desde una rama {branchStable} establecida.
+
+[[releng-stable-slush]]
+=== Code Sluch de la Rama FreeBSD `stable`
+
+En preparación para la congelación del código en una rama `estable`, varios archivos deben ser actualizados para reflejar que el ciclo de liberación está oficialmente en curso. Estos archivos son todos relativos al nivel más alto de la rama estable:
+
+[.informaltable]
+[cols="1,1", frame="none", options="header"]
+|===
+| Fichero a Editar
+| Qué Cambiar
+
+|[.filename]#sys/conf/newvers.sh#
+|Actualizar el valor de `BRANCH` para reflejar `PRERELEASE`
+
+|[.filename]#Makefile.inc1#
+|Actualizar `TARGET_TRIPLE`
+
+|[.filename]#lib/clang/llvm.build.mk#
+|Actualizar `OS_VERSION`
+
+|[.filename]#Makefile.libcompat#
+|Actualizar `LIB32CPUFLAGS`
+|===
+
+[[releng-stable-builds-beta]]
+=== Construcciones FreeBSD `BETA`
+
+Después del code slush, la siguiente fase del ciclo de lanzamiento es la congelación del código. Este es el punto en el que todos los commits a la rama estable requieren de una autorización explícita del {teamRe}. Esto se fuerza mediante unos hook de pre-commit en el repositorio de Subversion, editando [.filename]#base/svnadmin/conf/approvers# para incluir una expresión regular que concuerde con la rama {branchStablex} para la versión:
+
+[.programlisting, subs="attributes"]
+....
+^/{branchStablex}	re
+^/{branchRelengx}	re
+....
+
+[NOTE]
+====
+Hay dos excepciones, las cuales no requieren la aprobación del commit. La primera es cualquier cambio que deba realizar el Ingeniero de Lanzamientos para continuar con el flujo de trabajo diario del ciclo de lanzamientos, y el segundo, son las correcciones de errores de seguridad que puedan ocurrir durante el ciclo de lanzamientos.
+====
+
+Una vez que la congelación de código tiene efecto, la siguiente construcción de la rama se etiqueta como `BETA1`. Esto se hace actualizando el valor `BRANCH` en [.filename]#sys/conf/newvers.sh# de `PRERELEASE` a `BETA1`.
+
+Una vez hecho esto, se comienza la construcción del primer conjunto `BETA`. Las construcciones `BETA` subsiguientes no requieren más actualización que la del fichero [.filename]#sys/conf/newvers.sh#, incrementando el número de construcción `BETA`.
+
+[[releng-stable-branching]]
+=== Creando la Rama {branchRelengx}
+
+Cuando la primera construcción `RC` (Release Candidate) está lista para comenzar, se crea la rama {branchRelengx}. Este es un proceso de varios pasos que se tiene que realizar en un orden específico, para evitar anomalías como el solapado de valores de `__FreeBSD_version`, por ejemplo. Las rutas mostradas abajo son relativas a la raíz del repositorio. El orden de los commits y lo que hay que cambiar es el siguiente:
+
+[source, shell, subs="attributes"]
+....
+% svn cp ^/{branchStablex} {branchRelengx}
+....
+
+[.informaltable]
+[cols="1,1", frame="none", options="header"]
+|===
+| Fichero a Editar
+| Qué Cambiar
+
+|[.filename]#releng/12.0/sys/conf/newvers.sh#
+|Cambiar `BETA__X__` a `RC1`
+
+|[.filename]#releng/12.0/sys/sys/param.h#
+|Actualizar `__FreeBSD_version`
+
+|[.filename]#releng/12.0/etc/pkg/FreeBSD.conf#
+|Reemplazar `latest` con `quarterly` como repositorio de paquetes por defecto
+
+|[.filename]#releng/12.0/release/pkg_repos/release-dvd.conf#
+|Reemplazar `latest` with `quarterly` como repositorio de paquetes por defecto
+
+|[.filename]#stable/12/sys/conf/newvers.sh#
+|Actualizar `BETA__X__` con `PRERELEASE`
+
+|[.filename]#stable/12/sys/sys/param.h#
+|Actualizar `__FreeBSD_version`
+
+|[.filename]#svnadmin/conf/approvers#
+|Añadir una nueva línea "approvers" para la rama "releng" como se hizo para la rama "stable"
+|===
+
+[source, shell, subs="attributes"]
+....
+% svn propdel -R svn:mergeinfo {branchRelengx}
+% svn commit {branchRelengx}
+% svn commit {branchStablex}
+....
+
+Ahora que ya existe el nuevo valor de `__FreeBSD_version`, actualiza también [.filename]#~/documentation/content/en/books/porters-handbook/versions/chapter.adoc# en el repositorio del Proyecto de Documentación.
+
+Después de que la primera construcción `RC` se haya completado y haya sido probada, la rama {branchStable} puede ser "descongelada" quitando (o comentando) la entrada ^/{branchStablex} en [.filename]#svnadmin/conf/approvers#.
+
+Cuando la primera `RC` esté disponible, se debería enviar un correo a {teamBugmeister} para añadir la nueva `-RELEASE` de FreeBSD a las `versiones` disponibles en el menú desplegable que se muestra en el gestor de bugs.
+
+[[releng-building]]
+== Construir los Medios de Instalación de FreeBSD
+
+Esta sección describe los procedimientos generales que producen instantáneas y versiones del desarrollo de FreeBSD.
+
+[[releng-build-scripts]]
+=== Scripts de Construcción de Versiones
+
+Esta sección describe los scripts de construcción utilizados por {teamRe} para producir instantáneas de desarrollo y versiones.
+
+[[releng-build-scripts-single]]
+==== El Script [.filename]#release.sh#
+
+Antes de la versión FreeBSD 9.0-RELEASE, se actualizó [.filename]#src/release/Makefile# para soportar, y el script [.filename]#src/release/generate-release.sh# fue introducido como un envoltorio, para automatizar la invocación de los distintos objetivos.
+
+Antes de FreeBSD 9.2-RELEASE, se introdujo [.filename]#src/release/release.sh#, que basado en gran medida en [.filename]#src/release/generate-release.sh# incluía soporte para especificar archivos de configuración para anular varias opciones y variables de entorno. El soporte para los archivos de configuración proporcionaba soporte para construir de forma cruzada cada arquitectura para una versión especificando un archivo de configuración separado para cada invocación.
+
+Un pequeño ejemplo de cómo usar [.filename]#src/release/release.sh# para construir una única versión en [.filename]#/scratch#:
+
+[source, shell, subs="attributes"]
+....
+# /bin/sh /usr/src/release/release.sh
+....
+
+Un breve ejemplo del uso de [.filename]#src/release/release.sh# para construir una única versión cruzada utilizando un directorio de destino diferente, cree un [.filename]#release.conf# personalizado que contenga:
+
+[.programlisting, subs="attributes"]
+....
+# release.sh configuration for powerpc/powerpc64
+CHROOTDIR="/scratch-powerpc64"
+TARGET="powerpc"
+TARGET_ARCH="powerpc64"
+KERNEL="GENERIC64"
+....
+
+Después invoca [.filename]#src/release/release.sh# así:
+
+[source, shell, subs="attributes"]
+....
+# /bin/sh /usr/src/release/release.sh -c $HOME/release.conf
+....
+
+Echa un vistazo a [.filename]#src/release/release.conf.sample# para más detalles y ejemplos de uso.
+
+[[releng-build-scripts-multiple]]
+==== El Script Envoltorio [.filename]#thermite.sh#
+
+Para que la construcción cruzada del conjunto completo de arquitecturas soportadas en una rama determinada sea más rápida y fácil, y para reducir los factores de error humano, se escribió un script de envoltura alrededor de [.filename]#src/release/release.sh# para iterar a través de las diversas combinaciones de arquitecturas e invocar [.filename]#src/release/release.sh# utilizando un archivo de configuración específico para esa arquitectura.
+
+El script de envoltura se llama [.filename]#thermite.sh#, el cual está disponible en el repositorio Subversion de FreeBSD en `svn://svn.freebsd.org/base/user/gjb/thermite/`, junto con ficheros de configuración para construir las instantáneas de desarrollo de {branchHead} y {branchStablex}.
+
+El uso de [.filename]#thermite.sh# se trata en <<releng-build-snapshot>> y <<releng-build-release>>.
+
+Cada arquitectura y núcleo individual tiene su propio archivo de configuración usado por [.filename]#release.sh#. Cada rama tiene su propia configuración [.filename]#defaults-X.conf#, que contiene entradas comunes en cada arquitectura, donde se establecen y/o anulan las anulaciones o variables especiales en los archivos por construcción.
+
+El esquema para nombrar los ficheros de configuración de cada construcción es de la forma [.filename]#${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf#, donde las variables en mayúsculas son equivalentes a lo que se utiliza en el sistema de construcción y las variables en minúsculas se establecen dentro de los ficheros de configuración, mapeando al número de versión mayor de la respectiva rama.
+
+Cada rama también tiene su propia configuración [.filename]#builds-X.conf#, que es usada por [.filename]#thermite.sh#. El script [.filename]#thermite.sh# itera a través de cada valor ${revision}, ${TARGET_ARCH}, ${KERNCONF}, y ${type}, creando una lista maestra de lo que hay que construir. Sin embargo, una determinada combinación de la lista sólo se construirá si existe el respectivo archivo de configuración, que es donde el esquema de denominación anterior es relevante.
+
+Hay dos caminos para la obtención de archivos:
+
+* [.filename]#builds-12.conf# - [.filename]#main.conf#
++
+Este controla el comportamiento de [.filename]#thermite.sh#
+* [.filename]#12-amd64-GENERIC-snap.conf# - [.filename]#defaults-12.conf# - [.filename]#main.conf#
++
+Este controla el comportamiento de [.filename]#release/release.sh# en la construcción
+
+[NOTE]
+====
+Los ficheros de configuración [.filename]#builds-12.conf#, [.filename]#defaults-12.conf#, y [.filename]#main.conf# existen para reducir la repetición entre los archivos de cada construcción.
+====
+
+[[releng-build-snapshot]]
+=== Construyendo Instantáneas de Desarrollo de FreeBSD
+
+Las máquinas de construcción de la versión oficial tienen un diseño de sistema de archivos específico, que usando ZFS, [.filename]#thermite.sh# se aprovecha mucho con los clones y las instantáneas, asegurando un ambiente de construcción prístino.
+
+El script de construcción se encuentra en [.filename]#/releng/scripts-snapshot/scripts# o [.filename]#/releng/scripts-release/scripts# respectivamente, para evitar colisiones entre una construcción `RC` de una rama releng y una instantánea `STABLE`de la rama estable respectiva.
+
+Existe un conjunto separado de datos para las construcciones de las imágenes finales, [.filename]#/snap/ftp#. Este directorio contiene los directorios tanto de las instantáneas como de las versiones. Sólo se usan si la variable `EVERYTHINGISFINE` está definida en [.filename]#main.conf#.
+
+[NOTE]
+====
+El nombre de la variable `EVERYTHINGISFINE` se escogió para evitar colisiones con una variable que pudiera estar establecida en el entorno del usuario, habilitando accidentalmente el comportamiento que depende de ella al estar definida.
+====
+
+Conforme [.filename]#thermite.sh# itera por la lista maestra de combinaciones y localiza el fichero de configuración de cada construcción, se crea un conjunto de datos ZFS bajo [.filename]#/releng#, tales como [.filename]#/releng/12-amd64-GENERIC-snap#. Los árboles `src/`, `ports/`, y `doc/`se descargan en conjuntos de datos ZFS separados, tales como [.filename]#/releng/12-src-snap#, los cuales son clonados después y montados en sus respectivos conjuntos de datos. Esto se hace para evitar descargar un árbol más de una vez.
+
+Asumiendo estas rutas de sistemas de archivos, [.filename]#thermite.sh# sería invocado como:
+
+[source, shell, subs="attributes"]
+....
+# cd /releng/scripts-snapshot/scripts
+# ./setrev.sh -b {branchStablex}
+# ./zfs-cleanup.sh -c ./builds-12.conf
+# ./thermite.sh -c ./builds-12.conf
+....
+
+Una vez que se han completado las compilaciones, se dispone de guiones auxiliares adicionales para generar correos electrónicos de instantáneas de desarrollo que se envían a la lista de correo `freebsd-snapshots@freebsd.org`:
+
+[source, shell, subs="attributes"]
+....
+# cd /releng/scripts-snapshot/scripts
+# ./get-checksums.sh -c ./builds-12.conf | ./generate-email.pl > snapshot-12-mail
+....
+
+[NOTE]
+====
+La salida generada debe ser verificada dos veces para comprobar que es correcta, y el correo electrónico en sí debe ser firmado en línea mediante PGP.
+====
+
+[NOTE]
+====
+Los scripts de apoyo sólo se utilizan en las construcciones de instantáneas de desarrollo. Los anuncios durante un ciclo de liberación (excepto el anuncio de la versión definitiva) se crean a partir de una plantilla de correo. Un ejemplo de la plantilla de correo que se usa actualmente se puede encontrar link:here[aquí].
+====
+
+[[releng-build-release]]
+=== Construyendo Versiones de FreeBSD
+
+De forma similar para la construcción de instantáneas de desarrollo de FreeBSD, [.filename]#thermite.sh# se invocaría del mismo modo. La diferencia entre instantáneas de desarrollo y construcciones de versión, `BETA` y `RC` incluidas, es que los ficheros de configuración deben utilizar el tipo `release` en lugar de `snap` como se mencionaba anteriormente.
+
+Además, `BUILDTYPE` y `types` se deben cambiar de `snap`a `release`en [.filename]#defaults-12.conf# y [.filename]#builds-12.conf#, respectivamente.
+
+Cuando se construya `BETA`, `RC` y la `RELEASE` final, también hay que establecer estáticamente `BUILDSVNREV` a la revisión de la rama que refleja el cambio de nombre, `BUILDDATE` a la fecha en la que las construcciones comienzan en formato `YYYYMMDD`. Si los árboles `doc/` y `ports/` han sido etiquetados, hay que establecer también `PORTBRANCH` y `DOCBRANCH` a las rutas de las etiquetas relevantes en el repositorio de Subversion, reemplazando `HEAD` con la última revisión. También hay que establecer `releasesrc` en [.filename]#builds-12.conf# a la rama relevante, como {branchStablex} o {branchRelengx}.
+
+Durante el ciclo de lanzamiento, se almacena una copia de [.filename]#CHECKSUM.SHA512# y [.filename]#CHECKSUM.SHA256# para cada arquitectura en el repositorio interno de {teamRe} además de ser incluido en varios correos electrónicos de anuncio. Cada [.filename]#MANIFEST# que contiene los hashes de [.filename]#base.txz#, [.filename]#kernel.txz#, etc. es añadido también a package:misc/freebsd-release-manifests[] en la Colección de Ports.
+
+En preparación para la construcción de la liberación, varios archivos necesitan ser actualizados:
+
+[.informaltable]
+[cols="1,1", frame="none", options="header"]
+|===
+| Fichero a Editar
+| Qué Cambiar
+
+|[.filename]#sys/conf/newvers.sh#
+|Actualizar el valor de `BRANCH` a `RELEASE`
+
+|[.filename]#UPDATING#
+|Añadir la fecha prevista del anuncio
+
+|[.filename]#lib/csu/common/crtbrand.c#
+|Reemplazar `__FreeBSD_version` con el valor en [.filename]#sys/sys/param.h#
+|===
+
+Después de construir la `RELEASE` final, la rama {branchRelengx} se etiqueta como {branchRelengx} utilizando la revisión a partir de la cual se construyó la `RELEASE`. De forma similar a la creación de las ramas {branchStablex} y {branchRelengx}, esto se hace con `svn cp`. Desde la raíz del repositorio:
+
+[source, shell, subs="attributes"]
+....
+% svn cp ^/{branchRelengx}@r306420 {branchReleasex}
+% svn commit {branchReleasex}
+....
+
+[[releng-mirrors]]
+== Publicar los Medios de Instalación de FreeBSD para los Mirrors del Proyecto
+
+Esta sección describe el procedimiento para publicar instantáneas del desarrollo de FreeBSD y las versiones en los mirrors del Proyecto.
+
+[[releng-mirrors-staging]]
+=== Puesta en marcha las Imágenes de los Medios de Instalación de FreeBSD
+
+La puesta en marcha de las instantáneas y lanzamientos de FreeBSD es un proceso de dos partes:
+
+* Crear la estructura de directorios que concuerda con la jerarquía en `ftp-master`
++
+Si `EVERYTHINGISFINE` está definida en los ficheros de configuración de la construcción, [.filename]#main.conf# en el caso de los scripts de construcción referenciados arriba, esto sucede automáticamente después de que se haya completado la construcción, creando la estructura de directorios en [.filename]#${DESTDIR}/R/ftp-stage# con una estructura de rutas que concuerda con lo que se espera en `ftp-master`. Esto es equivalente a ejecutar directamente lo siguiente:
++
+[source, shell, subs="attributes"]
+....
+# make -C /usr/src/release -f Makefile.mirrors EVERYTHINGISFINE=1 ftp-stage
+....
++
+Después de que se haya construido cada arquitectura, [.filename]#thermite.sh# sincronizará con rsync el [.filename]#${DESTDIR}/R/ftp-stage# de la construcción a [.filename]#/snap/ftp/snapshots# o [.filename]#/snap/ftp/releases# en la máquina de construcción, respectivamente.
+* Copiar los ficheros a un directorio de preparación en `ftp-master` antes de mover los ficheros a [.filename]#pub/# para comenzar la propagación a los mirrors del Proyecto
++
+Una vez que todas las construcciones han terminado, [.filename]#/snap/ftp/snapshots#, o [.filename]#/snap/ftp/releases# para una release, es consultado por `ftp-master` utilizando rsync para [.filename]#/archive/tmp/snapshots# o [.filename]#/archive/tmp/releases#, respectivamente.
++
+[NOTE]
+====
+En `ftp-master` en la infraestructura del Proyecto FreeBSD, este proceso necesita nivel de acceso `root`, ya que este paso debe ejecutarse como el usuario `archive`.
+====
+
+[[releng-mirrors-publishing]]
+=== Publicación de los Medios de Instalación de FreeBSD
+
+Una vez que las imágenes están preparadas en [.filename]#/archive/tmp/#, están listas para ser publicadas poniéndolas en [.filename]#/archive/pub/FreeBSD#. Para reducir el tiempo de propagación se crean enlaces desde [.filename]#/archive/tmp# a [.filename]#/archive/pub/FreeBSD#.
+
+[NOTE]
+====
+Para que esto sea efectivo, tanto [.filename]#/archive/tmp# como [.filename]#/archive/pub# deben estar en el mismo sistema de ficheros lógico.
+====
+
+Hay un problema, sin embargo, donde se debe usar rsync después para corregir los enlaces simbólicos en [.filename]#pub/FreeBSD/snapshots/ISO-IMAGES# que serán reemplazados con enlaces duros, incrementando el tiempo de propagación.
+
+[NOTE]
+====
+Al igual que con los pasos de preparación, este requiere acceso nivel `root` ya que este paso debe ser ejecutado como el usuario `archive`.
+====
+
+Como usuario `archive`:
+
+[source, shell, subs="attributes"]
+....
+% cd /archive/tmp/snapshots
+% pax -r -w -l . /archive/pub/FreeBSD/snapshots
+% /usr/local/bin/rsync -avH /archive/tmp/snapshots/* /archive/pub/FreeBSD/snapshots/
+....
+
+Reemplaza _snapshots_ con _releases_ donde corresponda.
+
+[[releng-wrapup]]
+== Cerrando el Ciclo de Liberación
+
+En esta sección se describen las tareas generales posteriores a la liberación.
+
+[[releng-wrapup-en]]
+=== Notificaciones de Errores Posteriores a la Liberación
+
+Según se acerca el final del ciclo de liberación, es común tener varios EN candidatos (Errata Notice) para tratar problemas que han sido descubiertos tarde en el ciclo. Después de la release, el {teamRe} y el {teamSecteam} revisan cambios que no fueron aprobados antes de la release final, y dependiendo del alcance del cambio en cuestión, podría crear una EN.
+
+[NOTE]
+====
+El proceso de creación de ENs es manejado por el {teamSecteam}.
+====
+
+Para solicitar una Errata Notice después de que el ciclo de liberación haya finalizado, un desarrollador debería rellenar el https://www.freebsd.org/security/errata-template.txt[Errata Notice template], en concreto las secciones `Background`, `Problem Description`, `Impact`, y `Workaround`si es aplicable.
+
+La plantilla completa de la Errata Notice se debería enviar junto con un parche contra {branchReleng} o una lista de revisiones de la rama {branchStable}.
+
+Para peticiones de Errata Notice que sean inmediatamente posteriores a la release, la petición debería ser enviada por correo electrónico al {teamRe} y al {teamSecteam}. Una vez que la rama {branchReleng} ha sido entregada al {teamSecteam} como se describe en <<releng-wrapup-handoff>>, las peticiones de Errata Notice deberían ser enviadas al {teamSecteam}.
+
+[[releng-wrapup-handoff]]
+=== Entrega al {teamSecteam}
+
+Aproximadamente dos semanas después de la release, el Ingeniero de Liberación actualiza [.filename]#svnadmin/conf/approvers# cambiando la columna `approver` de `re` a `(so|security-officer)` para la rama {branchRelengx}.
+
+[[releng-eol]]
+== Fin del ciclo de Vida de la Versión
+
+Esta sección describe los ficheros que hay que actualizar en el sitio web cuando una versión alcanza su EoL (End-of-Life).
+
+[[releng-eol-website]]
+=== Actualizaciones del Sitio Web para End-Of-Life
+
+Cuando un lanzamiento llega al final de su vida, las referencias a ese lanzamiento deben ser eliminadas y/o actualizadas en el sitio web:
+
+[.informaltable]
+[cols="1,1", frame="none", options="header"]
+|===
+| Fichero
+| Qué Cambiar
+
+
+|[.filename]#~/website/themes/beastie/layouts/index.html#
+|Eliminar las referencias a `u-relXXX-announce` y `u-relXXX-announce`.
+
+|[.filename]#~/website/content/en/releases/_index.adoc#
+|Mover las variables `u-relXXX-*` de la lista de versiones soportadas a la lista de Legacy Releases.
+
+|[.filename]#~/website/content/en/releng/_index.adoc#
+|Actualizar la rama releng apropiada para reflejar que la rama ya no está soportada.
+
+|[.filename]#~/website/content/en/security/_index.adoc#
+|Eliminar la rama de la lista de ramas soportadas.
+
+|[.filename]#~/website/content/en/where.adoc#
+|Eliminar las URLs de la versión.
+
+|[.filename]#~/website/themes/beastie/layouts/partials/sidenav.html#
+|Eliminar las referencias a `u-relXXX-announce` y `u-relXXX-announce`.
+
+|[.filename]#~/website/static/security/advisory-template.txt#
+|Eliminar las referencias a las ramas releng y release.
+
+|[.filename]#~/website/static/security/errata-template.txt#
+|Eliminar las referencias a las ramas releng y release.
+|===
diff --git a/documentation/content/es/articles/freebsd-releng/_index.po b/documentation/content/es/articles/freebsd-releng/_index.po
new file mode 100644
index 0000000000..58f0c047cb
--- /dev/null
+++ b/documentation/content/es/articles/freebsd-releng/_index.po
@@ -0,0 +1,2340 @@
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR The FreeBSD Project
+# This file is distributed under the same license as the FreeBSD Documentation package.
+# Fernando  Apesteguía <fernando.apesteguia@gmail.com>, 2021, 2022.
+msgid ""
+msgstr ""
+"Project-Id-Version: FreeBSD Documentation VERSION\n"
+"POT-Creation-Date: 2021-11-04 20:26-0300\n"
+"PO-Revision-Date: 2022-01-12 15:04+0000\n"
+"Last-Translator: Fernando  Apesteguía <fernando.apesteguia@gmail.com>\n"
+"Language-Team: Spanish <https://translate-dev.freebsd.org/projects/"
+"documentation/articlesfreebsd-releng_index/es/>\n"
+"Language: es\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=2; plural=n != 1;\n"
+"X-Generator: Weblate 4.10.1\n"
+
+#. type: YAML Front Matter: description
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:1
+#, no-wrap
+msgid "Describes the approach used by the FreeBSD release engineering team to make production quality releases of the FreeBSD Operating System. It describes the tools available for those interested in producing customized FreeBSD releases for corporate rollouts or commercial productization"
+msgstr ""
+"Describe la aproximación utilizada por el equipo de ingeniería de versiones "
+"de FreeBSD para producir versiones de calidad de producción del Sistema "
+"Operativo FreeBSD. Describe las herramientas disponibles para aquellos que "
+"estén interesados en producir versiones personalizadas de FreeBSD para "
+"lanzamientos corporativos o productos comerciales"
+
+#. type: Title =
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:1
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:16
+#, no-wrap
+msgid "FreeBSD Release Engineering"
+msgstr "Ingeniería de versiones de FreeBSD"
+
+#. type: Plain text
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:50
+msgid ""
+"include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/"
+"{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] "
+"include::shared/{{% lang %}}/urls.adoc[]"
+msgstr ""
+"include::shared/attributes/attributes-{{% lang %}}.adoc[]\n"
+"include::shared/{{% lang %}}/teams.adoc[]\n"
+"include::shared/{{% lang %}}/mailing-lists.adoc[]\n"
+"include::shared/{{% lang %}}/urls.adoc[]"
+
+#. type: Plain text
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:63
+msgid "Abstract"
+msgstr "Resumen"
+
+#. type: Plain text
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:65
+msgid ""
+"This article describes the release engineering process of the FreeBSD "
+"Project."
+msgstr ""
+"Este artículo describe el proceso detrás del modelo de ingeniería de "
+"versiones adoptado por el Proyecto FreeBSD."
+
+#. type: delimited block = 4
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:69
+msgid ""
+"This document has not yet been updated to describe the current release "
+"procedures of the FreeBSD Release Engineering team following the transition "
+"from Subversion to Git."
+msgstr ""
+"Este documento todavía no ha sido actualizado para describir los "
+"procedimientos actuales del equipo de Ingeniería de Versiones de FreeBSD que "
+"siguieron a la transición de Subversion a Git."
+
+#. type: Plain text
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:72
+msgid "'''"
+msgstr "'''"
+
+#. type: Title ==
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:76
+#, no-wrap
+msgid "Introduction to the FreeBSD Release Engineering Process"
+msgstr "Introducción al Proceso de Ingeniería de Versiones de FreeBSD"
+
+#. type: Plain text
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:80
+msgid ""
+"Development of FreeBSD has a very specific workflow.  In general, all "
+"changes to the FreeBSD base system are committed to the {branchHead} branch, "
+"which reflects the top of the source tree."
+msgstr ""
+"El desarrollo de FreeBSD tiene un flujo de trabajo muy específico. En "
+"general, todos los cambios en el sistema base de FreeBSD se hacen en la rama "
+"{branchHead}, que representa la cima del árbol de fuentes."
+
+#. type: Plain text
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:83
+msgid ""
+"After a reasonable testing period, changes can then be merged to the "
+"{branchStable} branches.  The default minimum timeframe before merging to "
+"{branchStable} branches is three (3) days."
+msgstr ""
+"Después de un periodo de pruebas razonable, los cambios se pueden integrar "
+"en las ramas {branchStable}. El tiempo mínimo por defecto para integrar "
+"cambios en las ramas {branchStable} es de tres (3) días."
+
+#. type: Plain text
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:85
+msgid ""
+"Although a general rule to wait a minimum of three days before merging from "
+"{branchHead}, there are a few special circumstances where an immediate merge "
+"may be necessary, such as a critical security fix, or a bug fix that "
+"directly inhibits the release build process."
+msgstr ""
+"A pesar de la regla general de esperar un mínimo de tres días antes de "
+"integrar cambios desde {branchHead}, hay algunas circunstancias especiales "
+"bajo las cuales una integración inmediata puede ser necesaria, como arreglos "
+"críticos de seguridad, o un arreglo de un fallo que directamente "
+"imposibilita el proceso de generación de versiones."
+
+#. type: Plain text
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:88
+msgid ""
+"After several months, and the number of changes in the {branchStable} branch "
+"have grown significantly, it is time to release the next version of "
+"FreeBSD.  These releases have been historically referred to as \"point\" "
+"releases."
+msgstr ""
+"Después de varios meses, y de que el número de cambios en la rama "
+"{branchStable} haya crecido significativamente, es hora de liberar la "
+"siguiente versión de FreeBSD. Estas versiones han sido denominadas "
+"históricamente como versiones punto (\"point\" releases)."
+
+#. type: Plain text
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:91
+msgid ""
+"In between releases from the {branchStable} branches, approximately every "
+"two (2) years, a release will be cut directly from {branchHead}.  These "
+"releases have been historically referred to as \"dot-zero\" releases."
+msgstr ""
+"Entre las versiones de las ramas {branchStable}, aproximadamente cada dos (2)"
+" años, se sacará una versión directamente desde {branchHead}. Estas "
+"versiones se han denominado históricamente como versiones \"punto cero\" "
+"(\"dot-zero\" releases)."
+
+#. type: Plain text
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:93
+msgid ""
+"This article will highlight the workflow and responsibilities of the "
+"{teamRe} for both \"dot-zero\" and \"point\"' releases."
+msgstr ""
+"Este artículo resaltará el flujo de trabajo y responsabilidades del {teamRe} "
+"tanto para las versiones \"dot-zero\" como las versiones \"point\"."
+
+#. type: Plain text
+#: documentation/content/en/articles/freebsd-releng/_index.adoc:95
*** 2183 LINES SKIPPED ***