Translation Information

Project website docs.freebsd.org/en
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Only chosen users can contribute.
  • The translation uses bilingual files.
Translation license BSD 2-Clause "Simplified" License
Filemask documentation/content/*/books/dev-model/_index.po
Translation file Download documentation/content/pt_BR/books/dev-model/_index.po
User avatar None

Automatic translation

Documentation / books/dev-model/_indexPortuguese (Brazil)

The main tasks in the Documentation project are to work on current projects in the "FreeBSD Documentation Set", and translate the documentation to other languages.
As principais tarefas no projeto de Documentação são trabalhar em projetos atuais no <quote>Conjunto de Documentação do FreeBSD</quote>, e traduzir a documentação para outros idiomas.
8 days ago
New contributor 8 days ago
User avatar None

Automatic translation

Documentation / books/dev-model/_indexPortuguese (Brazil)

The releases of the -CURRENT-branch (that is, all releases that end with ".0") are very similar, but with twice as long timeframe. It starts 8 weeks prior to the release with announcement of the release time line. Two weeks into the release process, the feature freeze is initiated and performance tweaks should be kept to a minimum. Four weeks prior to the release, an official beta version is made available. Two weeks prior to release, the code is officially branched into a new version. This version is given release candidate status, and as with the release engineering of -STABLE, the code freeze of the release candidate is hardened. However, development on the main development branch can continue. Other than these differences, the release engineering processes are alike.
Os lançamentos da branch -CURRENT (ou seja, todas as releases que terminam com <quote>.0</quote>) são muito semelhantes, mas com o dobro do prazo. Começa 8 semanas antes do lançamento com o anúncio da linha do tempo da release. Duas semanas após o processo de release, o congelamento de recursos é iniciado e os ajustes de desempenho devem ser mantidos ao mínimo. Quatro semanas antes do lançamento, uma versão beta oficial é disponibilizada. Duas semanas antes do lançamento, o código é oficialmente transformado em uma nova versão. Esta versão recebe status de release candidate e, como na engenharia de release do -STABLE, o congelamento de código do release candidate é endurecido. No entanto, o desenvolvimento na branch principal de desenvolvimento pode continuar. Além dessas diferenças, os processos de engenharia de release são semelhantes.
8 days ago
New contributor 8 days ago
User avatar None

Automatic translation

Documentation / books/dev-model/_indexPortuguese (Brazil)

Problem reports are sent to an email address where it is inserted into the Problem Reports maintenance database. A <<role-bugbuster>> classifies the problem and sends it to the correct group or maintainer within the project. After someone has taken responsibility for the report, the report is being analysed. This analysis includes verifying the problem and thinking out a solution for the problem. Often feedback is required from the report originator or even from the FreeBSD community. Once a patch for the problem is made, the originator may be asked to try it out. Finally, the working patch is integrated into the project, and documented if applicable. It there goes through the regular maintenance cycle as described in section <<model-maintenance>>. These are the states a problem report can be in: open, analyzed, feedback, patched, suspended and closed. The suspended state is for when further progress is not possible due to the lack of information or for when the task would require so much work that nobody is working on it at the moment.
Os relatórios de problemas são enviados para um endereço de e-mail, onde são inseridos no banco de dados de manutenção de Relatórios de Problemas. Um <xref linkend="role-bugbuster"/> classifica o problema e o envia ao grupo ou mantenedor correto dentro do projeto. Depois que alguém assume a responsabilidade pelo relatório, o relatório estará sendo analisado. Esta análise inclui verificar o problema e pensar em uma solução para o problema. Muitas vezes é necessário feedback do criador do relatório ou até mesmo da comunidade do FreeBSD. Uma vez que um patch para o problema é feito, o criador pode ser solicitado a testá-lo. Finalmente, o patch de trabalhado é integrado ao projeto e documentado, se aplicável. Ele passa pelo ciclo de manutenção regular, conforme descrito na seção <xref linkend="model-maintenance"/>. Estes são os estados em que um relatório de problemas pode estar: aberto, analisado, feedback, corrigido, suspenso e fechado. O estado suspenso é para quando um progresso adicional não é possível devido à falta de informação ou quando a tarefa exigiria tanto trabalho que ninguém está trabalhando nela no momento.
8 days ago
New contributor 8 days ago
User avatar None

Automatic translation

Documentation / books/dev-model/_indexPortuguese (Brazil)

Here "development release" refers to the -CURRENT branch while "production release" refers to the -STABLE branch. The "pre-commit test" is the functional testing by peer developers when asked to do so or trying out the code to determine the status of the sub-project. "Parallel debugging" is the functional testing that can trigger more review, and debugging when the code is included in the -CURRENT branch.
Aqui, <quote>desenvolvimento de release (versão)</quote> refere-se a branch -CURRENT, enquanto o <quote>release em produção</quote> refere-se a branch -STABLE. O <quote>teste de pré-commit</quote> é o teste funcional feito por desenvolvedores de peers quando solicitado a fazê-lo ou a testar o código para determinar o status do subprojeto. <quote>Debug paralelo</quote> é o teste funcional que pode acionar mais revisões e debugs quando o código é incluído na branch -CURRENT.
8 days ago
New contributor 8 days ago
User avatar None

Automatic translation

Documentation / books/dev-model/_indexPortuguese (Brazil)

When voting, the committer may vote once in support of up to nine nominees. The voting is done over a period of four weeks with reminders being posted on "developers" mailing list that is available to all committers.
Ao votar, o committer pode votar uma vez em apoio de até nove candidatos. A votação é feita durante um período de quatro semanas com lembretes sendo postados na lista de discussão <quote>developers</quote> que está disponível para todos os committers.
8 days ago
New contributor 8 days ago
Browse all translation changes

Statistics

Percent Strings Words Chars
Total 333 9,698 62,806
Translated 43% 144 2,974 18,440
Needs editing 4% 14 961 6,015
Failing checks 4% 14 24 178

Last activity

Last change April 7, 2021, 3:22 a.m.
Last author Anonymous

Daily activity

Daily activity

Weekly activity

Weekly activity