Translation

(itstool) path: sect1/para
English
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.
571/5250
Context English Portuguese (Brazil) State
Final Ports package builds [4]: Última compilação dos ports [4]:
August 6, 2016 6 de agosto de 2016
Ports release tag: Aplicação da tag na árvore dos ports:
August 12, 2016 12 de agosto de 2016
RC3 build starts [*]: compilação da fase RC3 [*]:
RELEASE build starts: início de compilação da RELEASE:
August 19, 2016 19 de agosto de 2016
RELEASE announcement: Anúncio da RELEASE:
September 2, 2016 2 de setembro de 2016
Items marked with "[*]" are "as needed". Itens marcados com "[*]" identificam passos executados apenas "conforme necessário".
The <literal>doc/</literal> tree slush is coordinated by the FreeBSD Documentation Engineering Team. O pré congelamento da árvore <literal>doc</literal> é coordenado pela Equipe de Engenharia de Documentação do 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. A branch trimestral da árvore da coleção de ports é determinada quando a compilação final da fase <literal>RC</literal> é planejada. Uma nova branch trimestral é criada no primeiro dia do trimestre, portanto, essa métrica deve ser usada ao considerar os marcos do ciclo de release. Uma branch trimestral é criada pela Equipe de Gerenciamento de Ports do FreeBSD.
The <literal>doc/</literal> tree is tagged by the FreeBSD Documentation Engineering Team. A árvore <literal>doc</literal> é recebe a tag da Equipe de Engenharia de Documentação do FreeBSD.
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. A compilação final dos pacotes é feita pela Equipe de Gerenciamento de Ports do FreeBSD após a compilação final (ou o que é esperada ser a final) de uma 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. Se a versão RELEASE estiver sendo criada a partir de uma branch <literal>stable</literal> existente, a data de congelamento do <acronym>KBI</acronym> poderá ser excluída, já que o <acronym>KBI</acronym> já está congelado em branchs <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. Ao escrever o cronograma do ciclo de versões, várias coisas precisam ser levadas em consideração, em particular os milestones nos quais a data alvo depende de milestones pré-definidos sobre os quais existe uma dependência. Por exemplo, a aplicação da tag de release da Coleção de Ports é originada da branch trimestral ativa no momento da última fase do <literal>RC</literal>. Isso em parte define qual branch trimestral é usada, quando a aplicação da tag pode acontecer e qual revisão da árvore de ports é usada para a construção final de uma <literal>RELEASE</literal>.
After general agreement on the schedule, the FreeBSD Release Engineering Team emails the schedule to the FreeBSD Developers. Depois de um acordo geral sobre o cronograma, a Equipe de Engenharia de Release do FreeBSD envia e-mails para os desenvolvedores do 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. É normal que muitos desenvolvedores informem a Equipe de Engenharia de Release do FreeBSD sobre vários trabalhos em andamento. Em alguns casos, uma extensão para o trabalho em andamento será solicitada e, em outros casos, uma solicitação para uma <quote>aprovação geral</quote> para um subconjunto específico da árvore será feita.
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. Quando tais solicitações são feitas, é importante certificar-se de que os cronogramas (mesmo que estimados) sejam discutidos. Para as aprovações gerais, o período de tempo para a aprovação geral deve ser claro. Por exemplo, um desenvolvedor do FreeBSD pode solicitar aprovações gerais desde o início do code slush até o início da construção da primeira <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 manter o controle das aprovações gerais, a Equipe de Engenharia de Release do FreeBSD usa um repositório interno para manter um registro de tais solicitações, que define a área na qual uma aprovação geral foi concedida, o(s) autor(es), quando a aprovação geral expira e a razão pela qual a aprovação foi concedida. Um exemplo disso é a concessão de uma aprovação geral na <filename class="directory">release/doc/</filename> a todos os membros da Equipe de Engenharia de Release do FreeBSD até o <literal>RC</literal> final para atualizar as notas de lançamento e outras documentação relacionada ao lançamento.
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. A Equipe de Engenharia de Release do FreeBSD também usa este repositório para rastrear solicitações de aprovação pendentes que são recebidas antes de iniciar várias compilações durante o ciclo de release, que o Engenheiro de Release especifica o período de corte com um email para os desenvolvedores do 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. Dependendo do conjunto de código subjacente em questão, e do impacto geral que o conjunto de código tem no FreeBSD como um todo, tais solicitações podem ser aprovadas ou negadas pela Equipe de Engenharia de Release do FreeBSD.
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. O mesmo se aplica às extensões de trabalho em andamento. Por exemplo, o trabalho em andamento para um novo driver de dispositivo que de outra forma é isolado do restante da árvore pode receber uma extensão. Um novo scheduler, no entanto, pode não ser viável, especialmente se tais mudanças dramáticas não existirem em outra branch.
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. O cronograma também é adicionado ao site do projeto, no repositório <literal>doc</literal>, em <filename>head/en_US.ISO8859-1/htdocs/releases/<replaceable>12.0</replaceable>R/schedule.xml</filename>. Este arquivo é continuamente atualizado conforme o ciclo progride.
In most cases, the <filename>schedule.xml</filename> can be copied from a prior release and updated accordingly. Na maioria dos casos, o <filename>schedule.xml</filename> pode ser copiado de uma versão anterior e atualizado de acordo.
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. Além de adicionar o <filename>schedule.xml</filename> ao site, o <filename>head/share/xml/navibar.ent</filename> e o <filename>head/share/xml/release.ent</filename> também são atualizados para adicionar o link para o cronograma em várias subpáginas, bem como para habilitar o link para o cronograma na página principal do website do projeto.
The schedule is also linked from <filename>head/en_US.ISO8859-1/htdocs/releng/index.xml</filename>. O cronograma também chamado a partir de <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 um mês antes do <quote>code slush</quote>, a Equipe de Engenharia de Release do FreeBSD envia um email de lembrete para os desenvolvedores do FreeBSD.
Once the first builds of the release cycle are available, update the <literal>beta.local.where</literal> entity in <filename>head/en_US.ISO8859-1/htdocs/releases/<replaceable>12.0</replaceable>R/schedule.xml</filename>. replacing <literal>IGNORE</literal> with <literal>INCLUDE</literal>. Uma vez que as primeiras compilações do ciclo de release estejam disponíveis, atualize a entidade <literal>beta.local.where</literal> em <filename>head/en_US.ISO8859-1/htdocs/releases/<replaceable>12.0</replaceable>R/schedule.xml</filename>. substituindo <literal>IGNORE</literal> por <literal>INCLUDE</literal>.
If two parallel release cycles are happening at once, the <literal>beta2.local.where</literal> entity may be used instead. Se dois ciclos de lançamento paralelo estão acontecendo ao mesmo tempo, a entidade <literal>beta2.local.where</literal> pode ser usada no lugar.
Release Engineering Terminology Terminologia da Engenharia de Release

Loading…

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.
Ao escrever o cronograma do ciclo de versões, várias coisas precisam ser levadas em consideração, em particular os milestones nos quais a data alvo depende de milestones pré-definidos sobre os quais existe uma dependência. Por exemplo, a aplicação da tag de release da Coleção de Ports é originada da branch trimestral ativa no momento da última fase do <literal>RC</literal>. Isso em parte define qual branch trimestral é usada, quando a aplicação da tag pode acontecer e qual revisão da árvore de ports é usada para a construção final de uma <literal>RELEASE</literal>.
a month ago
Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/para
Source string location
article.translate.xml:343
String age
a year ago
Source string age
a year ago
Translation file
articles/pt_BR/freebsd-releng.po, string 71