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

Translation

(itstool) path: listitem/para
English
The <literal>doc/</literal> tree is tagged by the FreeBSD Documentation Engineering Team.
Context English Spanish State
July 30, 2016 20 julio, 2016
RC2 build starts: Empieza la compilación de la RC2:
August 5, 2016 5 agosto, 2016
Final Ports package builds [4]: Última compilación de los ports [4]:
August 6, 2016 6 agosto, 2016
Ports release tag: Etiqueta de liberación de puertos:
August 12, 2016 12 agosto, 2016
RC3 build starts [*]: Empieza la compilación de la RC3 [*]:
RELEASE build starts: Empieza la compilación de la RELEASE:
August 19, 2016 19 agosto, 2016
RELEASE announcement: Anuncio de liberación:
September 2, 2016 2 septiembre, 2016
Items marked with "[*]" are "as needed". Los elementos marcados con "[*]" identifican los pasos realizados solo "cuando sean necesarios".
The <literal>doc/</literal> tree slush is coordinated by the FreeBSD Documentation Engineering Team. La congelación del árbol de <literal>doc/</literal> está coordinada por el equipo de ingeniería de documentación de FreeBSD.
The Ports quarterly branch used is determined by when the final <literal>RC</literal> build is planned. A new quarterly branch is created on the first day of the quarter, so this metric should be used when taking the release cycle milestones into account. The quarterly branch is created by the FreeBSD Ports Management Team. La rama trimestral del árbol de ports se determina en el momento en que se planifica la compilación final de la fase de <literal>RC</literal>. Se crea una nueva rama trimestral el primer día del trimestre, por lo que esta métrica se debe utilizar al tener en cuenta los hitos del ciclo de lanzamiento. El equipo de gestión de ports de FreeBSD crea una rama trimestral.
The <literal>doc/</literal> tree is tagged by the FreeBSD Documentation Engineering Team. El equipo de ingeniería de documentación de FreeBSD crea el tag del árbol de <literal>doc/</literal>.
The final Ports package build is done by the FreeBSD Ports Management Team after the final (or what is expected to be final) <literal>RC</literal> build. El equipo de gestión de ports de FreeBSD realiza la compilación final de los ports después de la compilación final (o la fase que sea la final) de la fase <literal>RC</literal>.
If the release is being created from an existing <literal>stable/</literal> branch, the <acronym>KBI</acronym> freeze date can be excluded, since the <acronym>KBI</acronym> is already considered frozen on established <literal>stable/</literal> branches. Si la versión se está creando desde la rama <literal>stable/</literal>, la fecha de congelación de <acronym>KBI</acronym> puede ser excluida, ya que se considera que <acronym>KBI</acronym> está congelado en la rama <literal>stable/</literal>.
When writing the release cycle schedule, a number of things need to be taken into consideration, in particular milestones where the target date depends on predefined milestones upon which there is a dependency. For example, the Ports Collection release tag originates from the active quarterly branch at the time of the last <literal>RC</literal>. This in part defines which quarterly branch is used, when the release tag can happen, and what revision of the ports tree is used for the final <literal>RELEASE</literal> build. 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 tag de la colección de ports se obtiene de la rama trimestral que esté activa en el momento de la última fase <literal>RC</literal>. Esto, en parte, define qué rama trimestral se usa, cuándo se puede realizar el tag y qué revisión del árbol de ports se usa para la compilación final de <literal>RELEASE</literal>.
After general agreement on the schedule, the FreeBSD Release Engineering Team emails the schedule to the FreeBSD Developers. Después de un acuerdo general del programa, el equipo de ingeniería de lanzamientos de FreeBSD envía el programa por correo electrónico a los desarrolladores de FreeBSD.
It is somewhat typical that many developers will inform the FreeBSD Release Engineering Team about various works-in-progress. In some cases, an extension for the in-progress work will be requested, and in other cases, a request for <quote>blanket approval</quote> to a particular subset of the tree will be made. Es normal que muchos desarrolladores informen al equipo de lanzamientos de FreeBSD sobre varios trabajos en proceso. En algunos casos, se solicitará una extensión del trabajo que haya en proceso, y en otros casos, se solicitará una <quote>blanket approval</quote> para un subconjunto específico del árbol.
When such requests are made, it is important to make sure timelines (even if estimated) are discussed. For blanket approvals, the length of time for the blanket approval should be made clear. For example, a FreeBSD developer may request blanket approvals from the start of the code slush until the start of the <literal>RC</literal> builds. 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 <literal>RC</literal>.
In order to keep track of blanket approvals, the FreeBSD Release Engineering Team uses an internal repository to keep a running log of such requests, which defines the area upon which a blanket approval was granted, the author(s), when the blanket approval expires, and the reason the approval was granted. One example of this is granting blanket approval to <filename class="directory">release/doc/</filename> to all FreeBSD Release Engineering Team members until the final <literal>RC</literal> to update the release notes and other release-related documentation. Para realizar un seguimiento de las aprobaciones generales, el equipo de ingeniería de lanzamientos de FreeBSD utiliza un repositorio interno para mantener un registro de las solicitudes, que define el área sobre la cual se ha otorgado la aprobación general, el autor/es, en qué momento expira la aprobación general y la razón por la que se otorgó la aprobación. Un ejemplo es otorgar una aprobación general a <filename class="directory">release/doc/</filename> a todos los miembros del equipo de ingeniería de lanzamientos de FreeBSD hasta la <literal>RC</literal> final para actualizar las notas de la versión y otra documentación relacionada con la versión.
The FreeBSD Release Engineering Team also uses this repository to track pending approval requests that are received just prior to starting various builds during the release cycle, which the Release Engineer specifies the cutoff period with an email to the FreeBSD developers. El equipo de ingeniería de lanzamientos 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.
Depending on the underlying set of code in question, and the overall impact the set of code has on FreeBSD as a whole, such requests may be approved or denied by the FreeBSD Release Engineering Team. Dependiendo del conjunto de código en cuestión, y el impacto general que el conjunto de código tiene en FreeBSD en su conjunto, el equipo de ingeniería de lanzamientos de FreeBSD puede aprobar o denegar dichas solicitudes.
The same applies to work-in-progress extensions. For example, in-progress work for a new device driver that is otherwise isolated from the rest of the tree may be granted an extension. A new scheduler, however, may not be feasible, especially if such dramatic changes do not exist in another branch. Lo mismo se aplica al trabajo que haya en progreso. Por ejemplo, en el caso del desarrollo de un nuevo driver, 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 scheduler, puede no ser viable, en especial si los cambios no están en otra rama.
The schedule is also added to the Project website, in the <literal>doc/</literal> repository, in <filename>head/en_US.ISO8859-1/htdocs/releases/<replaceable>12.0</replaceable>R/schedule.xml</filename>. This file is continuously updated as the release cycle progresses. El programa también se añade a la web del proyecto, en el repositorio <literal>doc/</literal>, en <filename>head/en_US.ISO8859-1/htdocs/releases/<replaceable>12.0</replaceable>R/schedule.xml</filename>. Este archivo se actualiza continuamente a medida que avanza el ciclo del lanzamiento.
In most cases, the <filename>schedule.xml</filename> can be copied from a prior release and updated accordingly. En la mayoría de los casos, se puede copiar el archivo <filename>schedule.xml</filename> de una versión anterior y actualizarse.
In addition to adding <filename>schedule.xml</filename> to the website, <filename>head/share/xml/navibar.ent</filename> and <filename>head/share/xml/release.ent</filename> are also updated to add the link to the schedule to various subpages, as well as enabling the link to the schedule on the Project website index page. Además de añadir el archivo <filename>schedule.xml</filename> a la web, también se actualizarán los archivos <filename>head/share/xml/navibar.ent</filename> y <filename>head/share/xml/release.ent</filename> para añadir el enlace a la programación en varias subpáginas, así como habilitar el enlace a la programación en la página index de la web del proyecto.
The schedule is also linked from <filename>head/en_US.ISO8859-1/htdocs/releng/index.xml</filename>. También se enlaza a la programación desde el archivo <filename>head/en_US.ISO8859-1/htdocs/releng/index.xml</filename>.
Approximately one month prior to the scheduled <quote>code slush</quote>, the FreeBSD Release Engineering Team sends a reminder email to the FreeBSD Developers. Aproximadamente un mes antes del <quote>code slush</quote>, el equipo de ingeniería de lanzamientos de FreeBSD envía un correo electrónico de recordatorio a los desarrolladores de FreeBSD.
User avatar fernape

Suggestion added

El Equipo de Ingeniería de Documentación de FreeBSD crea el tag del árbol de <literal>doc/</literal>.

Suggested change:

El eEquipo de iIngeniería de dDocumentación de FreeBSD crea el tag del árbol de <literal>doc/</literal>.
3 months ago

Loading…

The <literal>doc/</literal> tree is tagged by the FreeBSD Documentation Engineering Team.
El Equipo de Ingeniería de Documentación de FreeBSD crea el tag del árbol de <literal>doc/</literal>.
3 months ago

Capitalized in the original

3 months ago
New source string a year ago
Browse all component changes
User avatar fernape

Translation comment

Capitalized in the original

3 months ago

Things to check

Suggestions

There is 1 suggestion for this string.

View

Comments

There is 1 comment for this string.

View

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:324
String age
a year ago
Source string age
a year ago
Translation file
articles/es_ES/freebsd-releng.po, string 68