Project locked to follow the migration to Hugo/AsciiDoctor, sorry for the inconvenience and please wait a few days to continue with the translations.
| Language | Translated | Untranslated | Untranslated words | Checks | Suggestions | Comments | |
|---|---|---|---|---|---|---|---|
English
BSD-2-Clause-FreeBSD
|
11 | ||||||
|
|
|||||||
|
Portuguese (Brazil)
BSD-2-Clause-FreeBSD
|
1 | ||||||
|
|
|||||||
|
Spanish
BSD-2-Clause-FreeBSD
|
98% | 6 | 27 | 18 | 20 | 4 | |
|
|
|||||||
Please sign in to see the alerts.
| Project website | wiki.freebsd.org/DocTranslationOnWeblate |
|---|---|
| Instructions for translators | https://wiki.freebsd.org/DocTranslationOnWeblate Mailing list for translators: <<freebsd-translators@freebsd.org> |
| Translation process |
|
| Translation license | BSD-2-Clause-FreeBSD |
| Filemask | articles/*/freebsd-releng.po |
| Languages | 3 |
| Source strings | 321 |
| Source words | 4,369 |
| Source characters | 44,221 |
| Hosted strings | 963 |
| Hosted words | 13,107 |
| Hosted characters | 132,663 |
dbaio
As with the staging steps, this requires <literal>root</literal> level access, as this step must be executed as the <literal>archive</literal> user.
Assim como nas etapas de preparação, isto requer acesso em nível de <literal>root</literal>, já que essa etapa deve ser executada como o usuário <literal>archive</literal>.
In order for this to be effective, both <filename class="directory">/archive/tmp</filename> and <filename class="directory">/archive/pub</filename> must reside on the same logical filesystem.
Para que isto seja efetivo, tanto o <filename class="directory">/archive/tmp</filename> quanto o <filename class="directory">/archive/pub</filename> devem residir no mesmo sistema de arquivos lógico.
Following the code slush, the next phase of the release cycle is the code freeze. This is the point at which all commits to the stable branch require explicit approval from the FreeBSD Release Engineering Team. This is enforced by pre-commit hooks in the Subversion repository by editing <filename>base/svnadmin/conf/approvers</filename> to include a regular expression matching the <literal>stable/<replaceable>12</replaceable>/</literal> branch for the release:
Após o code slush, a próxima fase do ciclo de release é o code freeze. Este é o ponto no qual todos os commits para a branch stable requerem aprovação explícita da Equipe de Engenharia de Release do FreeBSD. Isto é reforçado por hooks de pré-commit no repositório Subversion editando <filename>base/svnadmin/conf/approvers</filename> para incluir uma expressão regular que coincida com a branch <literal>stable/<replaceable>12</replaceable>/</literal> para a release:
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>.
Although a general rule to wait a minimum of three days before merging from <literal>head/</literal>, 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.
Embora seja uma regra geral esperar pelo menos três (3) dias antes de fundir o código produzido na branch <literal>head/</literal>, existem algumas circunstâncias especiais em que uma fusão imediata pode ser necessária, tal como uma correção de segurança crítica ou uma correção de bug que inibe diretamente o processo de compilação de uma release.