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

Translation

(itstool) path: section/para
English
Clouds of development efforts hang over the project where developers use the development models they see fit. The product of their work is then integrated into -CURRENT where it undergoes parallel debugging and is finally merged from -CURRENT into -STABLE. Security fixes are merged from -STABLE to the security branches.
421/3210 · 321
Context English Portuguese (Brazil) State
5.3 Release 5.3 Release
The latest -CURRENT version is always referred to as -CURRENT, while the latest -STABLE release is always referred to as -STABLE. In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. <citation><xref linkend="freebsd-releng"/></citation> A última versão -CURRENT é sempre referida como -CURRENT, enquanto a versão mais recente -STABLE é sempre referida como -STABLE. Nessa figura, -STABLE se refere a 4-STABLE, enquanto -CURRENT refere-se a 5.0-CURRENT seguindo para 5.0-RELEASE. <citation><xref linkend="freebsd-releng"/></citation>
A <quote>major release</quote> is always made from the -CURRENT branch. However, the -CURRENT branch does not need to fork at that point in time, but can focus on stabilising. An example of this is that following 3.0-RELEASE, 3.1-RELEASE was also a continuation of the -CURRENT-branch, and -CURRENT did not become a true development branch until this version was released and the 3-STABLE branch was forked. When -CURRENT returns to becoming a development branch, it can only be followed by a major release. 5-STABLE is predicted to be forked off 5.0-CURRENT at around 5.3-RELEASE. It is not until 5-STABLE is forked that the development branch will be branded 6.0-CURRENT. Um <quote>lançamento principal</quote> é sempre feito a partir da branch -CURRENT. No entanto, a branch -CURRENT não precisa ser feito fork nesse momento, mas pode concentrar-se na estabilização. Um exemplo disso é que, após 3.0-RELEASE, 3.1-RELEASE também era uma continuação da branch -CURRENT, e -CURRENT não se tornou uma branch de desenvolvimento verdadeira até que esta versão fosse lançada e fosse feito o fork da branch 3-STABLE. Quando -CURRENT retorna para se tornar uma branch de desenvolvimento, ele só pode ser seguido por um lançamento principal. Prevê-se que seja feito o fork do 5-STABLE a partir da branch 5.0-CURRENT em torno da 5.3-RELEASE. Não é feito até que seja feito o fork da 5-STABLE, então a branch de desenvolvimento será marcada como 6.0-CURRENT.
A <quote>minor release</quote> is made from the -CURRENT branch following a major release, or from the -STABLE branch. Uma <quote>versão secundária</quote> é feita a partir da branch -CURRENT após uma versão principal ou da branch -STABLE.
The first release this actually happened for was 4.5-RELEASE, but security branches were at the same time created for 4.3-RELEASE and 4.4-RELEASE. A primeira versão onde isso aconteceu foi na 4.5-RELEASE, mas as branches de segurança foram criadas ao mesmo tempo para 4.3-RELEASE e 4.4-RELEASE.
There is a terminology overlap with respect to the word "stable", which leads to some confusion. The -STABLE branch is still a development branch, whose goal is to be useful for most people. If it is never acceptable for a system to get changes that are not announced at the time it is deployed, that system should run a security branch. Existe uma terminologia que se sobrepõe à palavra "stable (estável)", o que leva a alguma confusão. A branch -STABLE ainda é uma branch de desenvolvimento, cujo objetivo é ser útil para a maioria das pessoas. Se nunca for aceitável que um sistema obtenha alterações que não são anunciadas no momento em que é implantado, esse sistema deve executar uma branch de segurança.
Following and including, 4.3-RELEASE<_:footnote-1/>, when a minor release has been made, it becomes a <quote>security branch</quote>. This is meant for organisations that do not want to follow the -STABLE branch and the potential new/changed features it offers, but instead require an absolutely stable environment, only updating to implement security updates. <_:footnote-2/> Seguindo e incluindo, 4.3-RELEASE <_:footnote-1/>, quando uma liberação secundária foi feita, ela se torna uma <quote>branch de segurança</quote>. Isso se destina a organizações que não desejam seguir a branch -STABLE e os possíveis recursos novos/alterados que oferece, mas que exigem um ambiente absolutamente estável, atualizando apenas para implementar atualizações de segurança. <_:footnote-2/>
Each update to a security branch is called a <quote>patchlevel</quote>. For every security enhancement that is done, the patchlevel number is increased, making it easy for people tracking the branch to see what security enhancements they have implemented. In cases where there have been especially serious security flaws, an entire new release can be made from a security branch. An example of this is 4.6.2-RELEASE. Cada atualização para uma branch de segurança é chamada de <quote>patchlevel (à nível de correção)</quote>. Para cada aprimoramento de segurança que é feito, o número de patchlevel é aumentado, tornando mais fácil para as pessoas rastrearem a branch para ver quais melhorias de segurança implementaram. Nos casos em que houve falhas graves de segurança, uma nova versão inteira pode ser feita a partir de uma branch de segurança. Um exemplo disso é a 4.6.2-RELEASE.
Model summary Resumo do modelo
To summarise, the development model of FreeBSD can be seen as the following tree: Para resumir, o modelo de desenvolvimento do FreeBSD pode ser visto como a seguinte árvore:
The overall development model O modelo geral de desenvolvimento
_ external ref='freebsd-code-model' md5='__failed__' external ref='freebsd-code-model' md5='__failed__'
<imageobject><imagedata fileref="freebsd-code-model"/></imageobject> <textobject><_:literallayout-1/></textobject> <textobject> <phrase>Refer to paragraphs below for a screen-reader friendly version.</phrase> </textobject>
The tree of the FreeBSD development with ongoing development efforts and continuous integration. A árvore do desenvolvimento do FreeBSD com esforços contínuos de desenvolvimento e integração contínua.
The tree symbolises the release versions with major versions spawning new main branches and minor versions being versions of the main branch. The top branch is the -CURRENT branch where all new development is integrated, and the -STABLE branch is the branch directly below it. Below the -STABLE branch are old, unsupported versions. A árvore simboliza as versões de lançamento com versões principais gerando novas branchs principais e versões secundárias sendo versões da branch principal. A branch superior é a branch -CURRENT, onde todo o desenvolvimento novo é integrado, e a branch -STABLE é a branch diretamente abaixo dela.
Clouds of development efforts hang over the project where developers use the development models they see fit. The product of their work is then integrated into -CURRENT where it undergoes parallel debugging and is finally merged from -CURRENT into -STABLE. Security fixes are merged from -STABLE to the security branches. Nuvens de esforços de desenvolvimento pairam sobre o projeto, onde os desenvolvedores usam os modelos de desenvolvimento que eles acham adequados. O produto de seu trabalho é então integrado em -CURRENT, onde ele é depurado paralelamente e finalmente é feito o merge (aplicado o código) do -CURRENT na -STABLE. As correções de segurança são feitos os merges (aplicado os códigos) da -STABLE para as branches de segurança.
Hats Hats (Funções)
Many committers have a special area of responsibility. These roles are called hats. These hats can be either project roles, such as public relations officer, or maintainer for a certain area of the code. Because this is a project where people give voluntarily of their spare time, people with assigned hats are not always available. They must therefore appoint a deputy that can perform the hat's role in their absence. The other option is to have the role held by a group. Muitos committers têm uma área especial de responsabilidade. Esses papéis são chamados de hats. Esses títulos podem ser funções do projeto, como diretor de relações públicas ou mantenedor de uma determinada área do código. Como esse é um projeto em que as pessoas doam voluntariamente seu tempo livre, as pessoas com hats atribuídos nem sempre estão disponíveis. Eles devem, portanto, nomear um substituto que possa desempenhar o cargo de hat em sua ausência. A outra opção é ter o cargo ocupado por um grupo.
Many of these hats are not formalised. Formalised hats have a charter stating the exact purpose of the hat along with its privileges and responsibilities. The writing of such charters is a new part of the project, and has thus yet to be completed for all hats. These hat descriptions are not such a formalisation, rather a summary of the role with links to the charter where available and contact addresses. Muitos desses hats não são formalizados. Hats formalizados têm uma carta indicando o propósito exato do hat, juntamente com seus privilégios e responsabilidades. A redação de tais cartas é uma nova parte do projeto e, portanto, ainda não foi concluída para todos os hats. Essas descrições de hats não são uma formalização, e sim um resumo da função com links para a carta quando disponíveis e endereços de contato.
General Hats Hats Universais
Contributor Colaborador
A Contributor contributes to the FreeBSD project either as a developer, as an author, by sending problem reports, or in other ways contributing to the progress of the project. A contributor has no special privileges in the FreeBSD project. <citation><xref linkend="freebsd-contributors"/></citation> Um Colaborador contribui para o projeto do FreeBSD como desenvolvedor, como autor, enviando relatórios de problemas ou contribuindo de outras formas para o progresso do projeto. Um colaborador não tem privilégios especiais no projeto do FreeBSD. <citation><xref linkend="freebsd-contributors"/></citation>
Committer Committer
A person who has the required privileges to add their code or documentation to the repository. A committer has made a commit within the past 12 months. <citation><xref linkend="freebsd-bylaws"/></citation> An active committer is a committer who has made an average of one commit per month during that time. Uma pessoa que possui os privilégios necessários para adicionar seu código ou documentação ao repositório. Um committer fez um commit nos últimos 12 meses. <citation><xref linkend="freebsd-bylaws"/></citation> Um committer ativo é um committer que fez uma média de um commit por mês durante esse tempo.
It is worth noting that there are no technical barriers to prevent someone, once having gained commit privileges to the main- or a sub-project, to make commits in parts of that project's source the committer did not specifically get permission to modify. However, when wanting to make modifications to parts a committer has not been involved in before, they should read the logs to see what has happened in this area before, and also read the MAINTAINERS file to see if the maintainer of this part has any special requests on how changes in the code should be made. Vale a pena notar que não existem barreiras técnicas para impedir que alguém, uma vez tendo ganho privilégios de commit para o main- ou um sub-projeto, de fazer commits em partes do código desse projeto que o committer não obteve permissão especificamente para modificar. No entanto, quando quiser fazer modificações em partes que um committer não tenha participado antes, ele deve ler os logs para ver o que aconteceu nesta área antes, e também ler o arquivo MAINTAINER para ver se o mantenedor desta parte tem quaisquer pedidos especiais sobre como as alterações no código devem ser feitas
Core Team Equipe principal (Core Team)
The core team is elected by the committers from the pool of committers and serves as the board of directors of the FreeBSD project. It promotes active contributors to committers, assigns people to well-defined hats, and is the final arbiter of decisions involving which way the project should be heading. As of July 1st, 2004, core consisted of 9 members. Elections are held every two years. A equipe principal é eleita pelos committers da lista de committers e serve como a diretoria do projeto FreeBSD. Promove colaboradores ativos para committers, atribui pessoas a hats bem definidos e é o mediador final de decisões envolvendo o caminho que o projeto deve seguir. Em 1º de julho de 2004, o core consistia de 9 membros. As eleições são realizadas a cada dois anos.
Maintainership Maintainership
Maintainership means that that person is responsible for what is allowed to go into that area of the code and has the final say should disagreements over the code occur. This involves proactive work aimed at stimulating contributions and reactive work in reviewing commits. Maintainership significa que essa pessoa é responsável pelo que é permitido entrar nessa área do código e tem a palavra final caso ocorram discordâncias sobre o código. Isso envolve trabalho proativo destinado a estimular contribuições e trabalho reativo na revisão de commits.
With the FreeBSD source comes the MAINTAINERS file that contains a one-line summary of how each maintainer would like contributions to be made. Having this notice and contact information enables developers to focus on the development effort rather than being stuck in a slow correspondence should the maintainer be unavailable for some time. Com o código fonte do FreeBSD vem o arquivo MAINTAINERS que contém um resumo de uma linha de como cada mantenedor gostaria que as contribuições fossem feitas. Ter este aviso e informações de contato permite que os desenvolvedores se concentrem no esforço de desenvolvimento, em vez de ficarem presos em uma correspondência lenta, caso o mantenedor não esteja disponível por algum tempo.
If the maintainer is unavailable for an unreasonably long period of time, and other people do a significant amount of work, maintainership may be switched without the maintainer's approval. This is based on the stance that maintainership should be demonstrated, not declared. Se o mantenedor não estiver disponível por um período de tempo excessivamente longo, e outras pessoas fizerem uma quantidade significativa de trabalho, a manutenção pode ser trocada sem a aprovação do mantenedor. Isto é baseado na postura de que a manutenção deve ser demonstrada, não declarada.

Loading…

User avatar None

New source string

FreeBSD Doc (Archived) / books_dev-model — Portuguese (Brazil)

New source string a year ago
Browse all component changes

Glossary

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

Source information

Source string comment
(itstool) path: section/para
Source string location
book.translate.xml:916
String age
a year ago
Source string age
a year ago
Translation file
books/pt_BR/dev-model.po, string 145