Translation

A problem is reported by the report originator. It is then classified by a bugbuster and handed to the correct maintainer. HeThey verifiesy the problem and discusses the problem with the originator until they hasve enough information to create a working patch. This patch is then committed and the problem report is closed.
(itstool) path: section/para
A problem is reported by the report originator. It is then classified by a bugbuster and handed to the correct maintainer. They verify the problem and discuss the problem with the originator until they have enough information to create a working patch. This patch is then committed and the problem report is closed.
326/3150
Context English Portuguese (Brazil) State
More and more tests are however performed when building the system (<quote>make world</quote>). These tests are however a very new addition and no systematic framework for these tests have yet been created.
No entanto, mais e mais testes são executados ao construir o sistema (<quote>make world</quote>). Esses testes são, no entanto, uma adição muito nova e ainda não foi criada nenhuma estrutura sistemática para esses testes.
The verification phase of the project is two-fold. Before committing code to the current-branch, developers request their code to be reviewed by their peers. This review is for the most part done by functional testing, but also code review is important. When the code is committed to the branch, a broader functional testing will happen, that may trigger further code review and debugging should the code not behave as expected. This second verification form may be regarded as structural verification. Although the sub-projects themselves may write formal tests such as unit tests, these are usually not collected by the main project and are usually removed before the code is committed to the current branch. <_:footnote-1/>
A fase de verificação do projeto é dupla. Antes de fazer o commit do código para a branch atual, os desenvolvedores solicitam que seu código seja revisado por seus pares. Esta revisão é, na maior parte, feita por testes funcionais, mas a revisão de código também é importante. Quando o código é "committed" para a branch, um teste funcional mais amplo ocorrerá, o que pode acionar mais revisões de código e depuração, caso o código não se comporte conforme o esperado. Esta segunda forma de verificação pode ser considerada como verificação estrutural. Embora os próprios subprojetos possam escrever testes formais, como testes de unidade, eles geralmente não são coletados pelo projeto principal e geralmente são removidos antes que o código seja "committed" na branch atual. <_:footnote-1/>
Maintenance
Manutenção
sendmail and named are examples of code that has been merged from other platforms.
sendmail e named são exemplos de código que foi feito merge (aplicado o código) de outras plataformas.
It is an advantage to the project to for each area of the source have at least one person that knows this area well. Some parts of the code have designated maintainers. Others have de-facto maintainers, and some parts of the system do not have maintainers. The maintainer is usually a person from the sub-project that wrote and integrated the code, or someone who has ported it from the platform it was written for. <_:footnote-1/> The maintainer's job is to make sure the code is in sync with the project the code comes from if it is contributed code, and apply patches submitted by the community or write fixes to issues that are discovered.
É uma vantagem para o projeto que para cada área do código fonte tenha pelo menos uma pessoa que conheça bem essa área. Algumas partes do código designaram mantenedores. Outros têm mantenedores de fato, e algumas partes do sistema não possuem mantenedores. O mantenedor é geralmente uma pessoa do subprojeto que escreveu e integrou o código, ou alguém que o portou da plataforma para a qual foi escrito. <_:footnote-1/> O trabalho do mantenedor é garantir que o código esteja em sincronia com o projeto de onde vem o código, se for um código contribuído, e aplicar correções enviadas pela comunidade ou escrever correções em problemas descobertos.
The main bulk of work that is put into the FreeBSD project is maintenance. <citation><xref linkend="jorgensen2001"/></citation> has made a figure showing the life cycle of changes.
A maior parte do trabalho que é colocado no projeto FreeBSD é a manutenção. <citation><xref linkend="jorgensen2001"/></citation> fez uma figura mostrando o ciclo de vida das mudanças.
Here <quote>development release</quote> refers to the -CURRENT branch while <quote>production release</quote> refers to the -STABLE branch. The <quote>pre-commit test</quote> 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. <quote>Parallel debugging</quote> 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.
As of this writing, there were 269 committers in the project. When they commit a change to a branch, that constitutes a new release. It is very common for users in the community to track a particular branch. The immediate existence of a new release makes the changes widely available right away and allows for rapid feedback from the community. This also gives the community the response time they expect on issues that are of importance to them. This makes the community more engaged, and thus allows for more and better feedback that again spurs more maintenance and ultimately should create a better product.
A partir desta escrita, havia 269 committers no projeto. Quando eles fazem o commit de uma mudança em uma branch, isso constitui uma nova release (versão). É muito comum os usuários da comunidade rastrearem uma determinada branch. A existência imediata de uma nova release torna as mudanças amplamente disponíveis imediatamente e permite um feedback rápido da comunidade. Isso também dá à comunidade o tempo de resposta que eles esperam em questões que são importantes para eles. Isso torna a comunidade mais engajada e, assim, permite mais e melhores feedbacks que estimulam mais a manutenção e, por fim, deverá criar um produto melhor.
Before making changes to code in parts of the tree that has a history unknown to the committer, the committer is required to read the commit logs to see why certain features are implemented the way they are in order not to make mistakes that have previously either been thought through or resolved.
Antes de fazer alterações no código em partes da árvore que tem um histórico desconhecido para o committer, o committer é obrigado a ler os logs de commit para ver porque certos recursos são implementados da maneira que eles estão, para não cometer erros que foram anteriormente pensado ou resolvido.
Problem reporting
Relatório de Problemas
Before FreeBSD 10, FreeBSD included a problem reporting tool called <command>send-pr</command>. Problems include bug reports, feature requests, feature enhancements and notices of new versions of external software that are included in the project. Although <command>send-pr</command> is available, users and developers are encouraged to submit issues using our <link xlink:href="https://bugs.freebsd.org/submit/"> problem report form</link>.
Antes do FreeBSD 10, o FreeBSD incluía uma ferramenta de relatório de problemas chamada <command>send-pr</command>. Os problemas incluem relatórios de bugs, solicitações de recursos, aprimoramentos de recursos e avisos de novas versões de software externo incluídas no projeto. Embora o <command>send-pr</command> esteja disponível, os usuários e desenvolvedores são incentivados a enviar problemas usando nosso <link xlink:href="https://bugs.freebsd.org/submit/">formulário de relatório de problemas</link>.
Problem reports are sent to an email address where it is inserted into the Problem Reports maintenance database. A <xref linkend="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 <xref linkend="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.
Process summary: problem reporting
Resumo do processo: Relatório de Pproblemas
_
external ref='proc-pr' md5='__failed__'
external ref='proc-pr' md5='__failed__'
<imageobject><imagedata fileref="proc-pr"/></imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Refer to paragraph below for a screen-reader friendly version.</phrase> </textobject>
 
A problem is reported by the report originator. It is then classified by a bugbuster and handed to the correct maintainer. They verify the problem and discuss the problem with the originator until they have enough information to create a working patch. This patch is then committed and the problem report is closed.
Um problema é relatado pelo criador do relatório. É então classificado por um bugbuster e entregue ao mantenedor correto. Ele verifica o problema e discute o problema com o criador até que ele tenha informações suficientes para criar um patch de trabalhado. Este patch é então "committed" e o relatório de problemas é fechado.
The roles included in this process are: <_:orderedlist-1/>
As funções incluídas neste processo são: <_:orderedlist-1/>
<citation><xref linkend="freebsd-handle-pr"/></citation>. <citation><xref linkend="freebsd-send-pr"/></citation>
<citation><xref linkend="freebsd-handle-pr"/></citation>. <citation><xref linkend="freebsd-send-pr"/></citation>
Reacting to misbehavior
Reagindo ao mau comportamento
Committing during code freezes without the approval of the Release Engineering team - 2 days
Fazer um commit durante o code freeze (tempo de congelamento de código) sem a aprovação da equipe dos Engenheiros de Release - 2 dias
Committing to a security branch without approval - 2 days
Fazer um commit em uma branch de segurança sem aprovação - 2 dias
Commit wars - 5 days to all participating parties
Guerras por causa de commit - 5 dias para todas as partes participantes
Impolite or inappropriate behavior - 5 days
Comportamento deselegante ou inapropriado - 5 dias
<citation><xref linkend="freebsd-committer"/></citation> has a number of rules that committers should follow. However, it happens that these rules are broken. The following rules exist in order to be able to react to misbehavior. They specify what actions will result in how long a suspension of the committer's commit privileges. <_:itemizedlist-1/> <citation><xref linkend="ref-freebsd-trenches"/></citation>
<citation><xref linkend="freebsd-committer"/></citation> tem um número de regras que os committers devem seguir. No entanto, acontece que essas regras são quebradas. As seguintes regras existem para poder reagir ao mau comportamento. Eles especificam quais ações resultarão e em quanto tempo será uma suspensão dos privilégios de commit do committer. <_:itemizedlist-1/><citation><xref linkend="ref-freebsd-trenches"/></citation>
For the suspensions to be efficient, any single core member can implement a suspension before discussing it on the <quote>core</quote> mailing list. Repeat offenders can, with a 2/3 vote by core, receive harsher penalties, including permanent removal of commit privileges. (However, the latter is always viewed as a last resort, due to its inherent tendency to create controversy.) All suspensions are posted to the <quote>developers</quote> mailing list, a list available to committers only.
Para que as suspensões sejam eficientes, qualquer membro do core pode implementar uma suspensão antes de discuti-la na lista de discussão <quote>core</quote>. Os infratores reincidentes podem, com um voto de 2/3 do core, receber penalidades mais duras, incluindo a remoção permanente dos privilégios de commit. (No entanto, este último é sempre visto como um último recurso, devido à sua tendência inerente de criar controvérsia). Todas as suspensões são postadas na lista de discussão <quote>developers</quote>, uma lista disponível apenas para committers.
It is important that you cannot be suspended for making technical errors. All penalties come from breaking social etiquette.
É importante que você não possa ser suspenso por cometer erros técnicos. Todas as penalidades vêm de quebrar a etiqueta social.
Hats involved in this process: <_:itemizedlist-1/>
Hats envolvidos neste processo: <_:itemizedlist-1/>
Release engineering
Engenharia de Release (Versão)
The FreeBSD project has a Release Engineering team with a principal release engineer that is responsible for creating releases of FreeBSD that can be brought out to the user community via the net or sold in retail outlets. Since FreeBSD is available on multiple platforms and releases for the different architectures are made available at the same time, the team has one person in charge of each architecture. Also, there are roles in the team responsible for coordinating quality assurance efforts, building a package set and for having an updated set of documents. When referring to the release engineer, a representative for the release engineering team is meant.
O projeto FreeBSD possui uma equipe de Engenharia de Release com um engenheiro de release principal responsável por criar versões do FreeBSD que podem ser trazidas para a comunidade de usuários através da rede ou vendidas em lojas de varejo. Como o FreeBSD está disponível em várias plataformas e as releases para as diferentes arquiteturas são disponibilizadas ao mesmo tempo, a equipe tem uma pessoa responsável por cada arquitetura. Além disso, há cargos na equipe responsável por coordenar os esforços de garantia de qualidade, construir um conjunto de pacotes e ter um conjunto atualizado de documentos. Ao se referir ao engenheiro de release, um representante da equipe de engenharia de release é indicado.
When a release is coming, the FreeBSD project changes shape somewhat. A release schedule is made containing feature- and code-freezes, release of interim releases and the final release. A feature-freeze means no new features are allowed to be committed to the branch without the release engineers' explicit consent. Code-freeze means no changes to the code (like bugs-fixes) are allowed to be committed without the release engineers' explicit consent. This feature- and code-freeze is known as stabilising. During the release process, the release engineer has the full authority to revert to older versions of code and thus "back out" changes should they find that the changes are not suitable to be included in the release.
Quando uma versão está chegando, o projeto do FreeBSD muda de forma um pouco. Um cronograma de lançamento é feito contendo congelamentos de recursos e códigos, liberação de versões intermediárias e a versão final. Um congelamento de recursos significa que nenhum novo recurso pode ser aplicado na branch sem o consentimento explícito dos engenheiros de release. O congelamento de código significa que nenhuma alteração no código (como bugs-fixes) pode ser aplicada sem o consentimento explícito dos engenheiros de release. Esse congelamento de recurso e código é conhecido como estabilização. Durante o processo de lançamento, o engenheiro de release tem a autoridade total para reverter para versões mais antigas de código e, assim, "desfazer" as alterações, caso ache que as alterações não são adequadas para serem incluídas na versão.
.0 releases are the first release of a major version. These are branched of the -CURRENT branch and have a significantly longer release engineering cycle due to the unstable nature of the -CURRENT branch
Releases .0 são o primeiro lançamento de uma versão principal. Eles são branches da branch -CURRENT e têm um ciclo de engenharia de release significativamente maior devido à natureza instável da branch -CURRENT

Loading…

User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

A problem is reported by the report originator. It is then classified by a bugbuster and handed to the correct maintainer. HeThey verifiesy the problem and discusses the problem with the originator until they hasve enough information to create a working patch. This patch is then committed and the problem report is closed.
3 months 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
Labels
No labels currently set.
Source string location
book.translate.xml:2091
Source string age
3 months ago
Translation file
books/pt_BR/dev-model.po, string 296