Translation

(itstool) path: section/para
In addition to many people working on the project, there are many related projects to the FreeBSD Project. These are either projects developing brand new features, sub-projects or projects whose outcome is incorporated into FreeBSD <_:footnote-1/>. These projects fit into the FreeBSD Project just like regular development efforts: they produce code that is integrated with the FreeBSD Project. However, some of them (like Ports and Documentation) have the privilege of being applicable to both branches or commit directly to both -CURRENT and -STABLE.
562/5520
Context English Portuguese (Brazil) State
Within the <quote>code</quote> bracket in Jørgensen's model, each programmer has their own working style and follows their own development models. The bracket could very well have been called <quote>development</quote> as it includes requirements gathering and analysis, system and detailed design, implementation and verification. However, the only output from these stages is the source code or system documentation.
Dentro do processo <quote>code</quote> na figura de Jørgensen, cada programador tem seu próprio estilo de trabalho e segue seus próprios modelos de desenvolvimento. O suporte poderia muito bem ter sido chamado de <quote>desenvolvimento</quote>, pois inclui coleta e análise de requisitos, sistema e projeto detalhados, implementação e verificação. No entanto, a única saída desses estágios é o código-fonte ou a documentação do sistema.
From a stepwise model's perspective (such as the waterfall model), the other brackets can be seen as further verification and system integration. This system integration is also important to see if a change is accepted by the community. Up until the code is committed, the developer is free to choose how much to communicate about it to the rest of the project. In order for -CURRENT to work as a buffer (so that bright ideas that had some undiscovered drawbacks can be backed out) the minimum time a commit should be in -CURRENT before merging it to -STABLE is 3 days. Such a merge is referred to as an MFC (Merge From Current).
Da perspectiva de um modelo em etapas (como o modelo em cascata), os outros suportes podem ser vistos como verificação adicional e integração do sistema. Essa integração do sistema também é importante para ver se uma alteração é aceita pela comunidade. Até que o código seja "committed", o desenvolvedor é livre para escolher quanto se deve comunicar sobre o restante do projeto. Para que o -CURRENT funcione como um buffer (para que as ideias brilhantes que tinham algumas desvantagens não descobertas possam ser recuperadas), o tempo mínimo que um "commit" deve estar no -CURRENT antes de fazer o merge (aplicar o código) para -STABLE é de 3 dias. Esse merge (aplicação) é referido como um MFC (Merge From Current).
It is important to notice the word <quote>change</quote>. Most commits do not contain radical new features, but are maintenance updates.
É importante notar a palavra <quote>change (mudança)</quote>. A maioria dos commits não contém novos recursos radicais, mas são atualizações de manutenção.
The only exceptions from this model are security fixes and changes to features that are deprecated in the -CURRENT branch. In these cases, changes can be committed directly to the -STABLE branch.
As únicas exceções desse modelo são correções de segurança e alterações nos recursos que estão obsoletos na branch (ramificação) -CURRENT. Nesses casos, as alterações podem ser "committed" diretamente na branch -STABLE.
For instance, the development of the Bluetooth stack started as a sub-project until it was deemed stable enough to be merged into the -CURRENT branch. Now it is a part of the core FreeBSD system.
Por exemplo, o desenvolvimento da pilha Bluetooth começou como um subprojeto até ser considerada estável o suficiente para ser feito o merge (aplicado) na branch -CURRENT. Agora é parte do sistema principal do FreeBSD.
In addition to many people working on the project, there are many related projects to the FreeBSD Project. These are either projects developing brand new features, sub-projects or projects whose outcome is incorporated into FreeBSD <_:footnote-1/>. These projects fit into the FreeBSD Project just like regular development efforts: they produce code that is integrated with the FreeBSD Project. However, some of them (like Ports and Documentation) have the privilege of being applicable to both branches or commit directly to both -CURRENT and -STABLE.
Além de muitas pessoas trabalhando no projeto, há muitos projetos relacionados ao Projeto FreeBSD. Estes são projetos desenvolvendo novos recursos, subprojetos ou projetos cujo resultado é incorporado ao FreeBSD <_:footnote-1/>. Esses projetos se encaixam no Projeto FreeBSD, assim como os esforços regulares de desenvolvimento: eles produzem código que são integrados ao Projeto FreeBSD. No entanto, alguns deles (como Ports e Documentação) têm o privilégio de serem aplicáveis ​​às duas branchs (ramificações) ou de commit diretamente na -CURRENT e na -STABLE.
According to Kirk McKusick, after 20 years of developing UNIX operating systems, the interfaces are for the most part figured out. There is therefore no need for much design. However, new applications of the system and new hardware leads to some implementations being more beneficial than those that used to be preferred. One example is the introduction of web browsing that made the normal TCP/IP connection a short burst of data rather than a steady stream over a longer period of time.
De acordo com Kirk McKusick, depois de 20 anos desenvolvendo sistemas operacionais UNIX, as interfaces são, na maioria das vezes, resolvidas. Portanto, não há necessidade de muito design. No entanto, novas aplicações do sistema e novo hardware levam a algumas implementações sendo mais benéficas do que aquelas que costumavam ser ter preferencia. Um exemplo é a introdução da navegação Web que tornou a conexão TCP/IP normal uma sequência curta de dados, em vez de um fluxo contínuo durante um período de tempo mais longo.
There is no standards to how design should be done, nor is design collected in a centralised repository. The main design is that of 4.4BSD. <_:footnote-1/> As design is a part of the <quote>Code</quote> bracket in Jørgenssen's model, it is up to every developer or sub-project how this should be done. Even if the design should be stored in a central repository, the output from the design stages would be of limited use as the differences of methodologies would make them poorly if at all interoperable. For the overall design of the project, the project relies on the sub-projects to negotiate fit interfaces between each other rather than to dictate interfacing.
Não há padrões para como o design deve ser feito, nem o design é coletado em um repositório centralizado. O design principal é o do 4.4BSD. <_:footnote-1/> Como o design é parte do processo <quote>Code (Código)</quote> no modelo de Jørgenssen, cabe a cada desenvolvedor ou sub-projeto como isso deve ser feito. Mesmo que o projeto deva ser armazenado em um repositório central, a saída dos estágios do projeto seria de uso limitado, pois as diferenças de metodologias as desvalorizariam se de alguma forma interoperáveis. Para o design geral do projeto, o projeto conta com os subprojetos para negociar interfaces adequadas entre si, em vez de ditar interfaces.
Release branches
Lançamento de versões (Release branches)
The releases of FreeBSD are best illustrated by a tree with many branches where each major branch represents a major version. Minor versions are represented by branches of the major branches.
Os lançamentos do FreeBSD são melhor ilustrados por uma árvore com muitas branches (ramificações), onde cada branch principal representa uma versão principal. Versões secundárias são representadas por branches das branches maiores.
In the following release tree, arrows that follow one-another in a particular direction represent a branch. Boxes with full lines and diamonds represent official releases. Boxes with dotted lines represent the development branch at that time. Security branches are represented by ovals. Diamonds differ from boxes in that they represent a fork, meaning a place where a branch splits into two branches where one of the branches becomes a sub-branch. For example, at 4.0-RELEASE the 4.0-CURRENT branch split into 4-STABLE and 5.0-CURRENT. At 4.5-RELEASE, the branch forked off a security branch called RELENG_4_5.
Na árvore de versões a seguir, as setas que seguem uma a outra em uma determinada direção representam uma branch. Caixas com linhas completas e encorporadas representam lançamentos oficiais. Caixas com linhas pontilhadas representam a branch de desenvolvimento nesse momento. Branchs de segurança são representadas por ovais. As encorporadas diferem das caixas em que representam um fork, definindo um lugar onde uma branch se divide em duas branchs, onde uma das branches se tornam uma sub-branch (sub ramificação). Por exemplo, em 4.0-RELEASE, a branch 4.0-CURRENT é dividida em 4-STABLE e 5.0-CURRENT. No 4.5-RELEASE, a branch retirou uma branch de segurança chamada RELENG_4_5.

Loading…

None

New source string

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

New source string 9 months ago
Browse all component changes

Things to check

Zero-width space

Translation contains extra zero-width space character

Fix string

Reset

Glossary

English Portuguese (Brazil)
Open Source Project Projeto Open Source FreeBSD Doc

Source information

Source string comment
(itstool) path: section/para
Labels
No labels currently set.
Source string location
book.translate.xml:654
Source string age
9 months ago
Translation file
books/pt_BR/dev-model.po, string 108