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

Translation

(itstool) path: section/para
English
Within the project there are sub-projects that are working on new features. These projects are generally done by one person <citation><xref linkend="jorgensen2001"/></citation>. Every project is free to organise development as it sees fit. However, when the project is merged to the -CURRENT branch it must follow the project guidelines. When the code has been well tested in the -CURRENT branch and deemed stable enough and relevant to the -STABLE branch, it is merged to the -STABLE branch.
529/4920 · 492
Context English Portuguese (Brazil) State
The first Core election was held September 2000 A primeira eleição do core foi realizada em setembro de 2000
Core elections are held at least every two years. <_:footnote-1/> Nine core members are elected. New elections are held if the number of core members drops below seven. New elections can also be held should at least 1/3 of the active committers demand this. As eleições do core são realizadas pelo menos a cada dois anos. <_:footnote-1/> Nove membros do core são eleitos. Novas eleições serão realizadas se o número de membros do core ficar abaixo de sete. Novas eleições também podem ser realizadas se pelo menos 1/3 dos committers ativos exigirem isso.
When an election is to take place, core announces this at least 6 weeks in advance, and appoints an election manager to run the elections. Quando uma eleição é realizada, o core anuncia isso com pelo menos 6 semanas de antecedência e nomeia um gerente eleitoral para dirigir as eleições.
Only committers can be elected into core. The candidates need to submit their candidacy at least one week before the election starts, but can refine their statements until the voting starts. They are presented in the <link xlink:href="http://election.uk.freebsd.org/candidates.html">candidates list</link>. When writing their election statements, the candidates must answer a few standard questions submitted by the election manager. Somente committers podem ser eleitos para o core. Os candidatos precisam apresentar sua candidatura pelo menos uma semana antes do início das eleições, mas podem refinar suas declarações até o início da votação. Eles são apresentados na <link xlink:href="http://election.uk.freebsd.org/candidates.html">lista de candidatos</link>. Ao escrever suas declarações eleitorais, os candidatos devem responder a algumas perguntas padrões submetidas pelo gerente eleitoral.
During elections, the rule that a committer must have committed during the 12 past months is followed strictly. Only these committers are eligible to vote. Durante as eleições, a regra que um committer deve ter feito um commit durante os 12 meses passados ​​é seguida estritamente. Apenas esses committers estão qualificados para votar.
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 <quote>developers</quote> 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.
The election results are released one week after the election ends, and the new core team takes office one week after the results have been posted. Os resultados das eleições são divulgados uma semana após o término da eleição, e a nova equipe do core toma posse uma semana após o lançamento dos resultados.
Should there be a voting tie, this will be resolved by the new, unambiguously elected core members. Se houver um empate de votação, isso será resolvido pelos novos membros do core, eleitos sem ambiguidade.
Votes and candidate statements are archived, but the archives are not publicly available. Votos e declarações de candidatos são arquivados, mas os arquivos não estão publicamente disponíveis.
Process summary: Core elections Resumo do processo: Eleições do Core
_ external ref='proc-elections' md5='__failed__' external ref='proc-elections' md5='__failed__'
<imageobject><imagedata fileref="proc-elections"/></imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Refer to paragraph below for a screen-reader friendly version.</phrase> </textobject>
Core announces the election and selects an election manager who prepares the elections, and when ready, candidates can announce their candidacies through submitting their statements. The committers then vote. After the vote is over, the election results are announced and the new core team takes office. O Core anuncia a eleição e seleciona um gerente eleitoral. Ele prepara as eleições e, quando estiver pronto, os candidatos podem anunciar suas candidaturas através da apresentação de suas declarações. Os committers então votam. Após o término da votação, os resultados das eleições são anunciados e a nova equipe do core toma posse.
Hats in core elections are: <_:itemizedlist-1/> Hats nas eleições do Core são: <_:itemizedlist-1/>
Development of new features Desenvolvimento de novos recursos
Within the project there are sub-projects that are working on new features. These projects are generally done by one person <citation><xref linkend="jorgensen2001"/></citation>. Every project is free to organise development as it sees fit. However, when the project is merged to the -CURRENT branch it must follow the project guidelines. When the code has been well tested in the -CURRENT branch and deemed stable enough and relevant to the -STABLE branch, it is merged to the -STABLE branch. Dentro do projeto existem subprojetos que estão trabalhando em novos recursos. Esses projetos geralmente são feitos por uma pessoa <citation><xref linkend="jorgensen2001"/></citation>. Todo projeto é livre para organizar o desenvolvimento como achar melhor. No entanto, quando é feito o merge do projeto (aplicado) à branch -CURRENT, ele deve seguir as diretrizes do projeto. Quando o código foi bem testado na branch -CURRENT e considerado estável o suficiente e relevante para a branch -STABLE, ele é mergeado à branch -STABLE.
The requirements of the project are given by developer wishes, requests from the community in terms of direct requests by mail, Problem Reports, commercial funding for the development of features, or contributions by the scientific community. The wishes that come within the responsibility of a developer are given to that developer who prioritises their time between the request and their wishes. A common way to do this is maintain a TODO-list maintained by the project. Items that do not come within someone's responsibility are collected on TODO-lists unless someone volunteers to take the responsibility. All requests, their distribution and follow-up are handled by the <xref linkend="tool-bugzilla"/> tool. Os requisitos do projeto são fornecidos como o desenvolvedor desejar, solicitações da comunidade em termos de solicitações diretas por correio, relatórios de problemas, financiamento comercial para o desenvolvimento de recursos ou contribuições da comunidade científica. Os desejos que estão sob a responsabilidade de um desenvolvedor são dados àquele desenvolvedor que prioriza seu tempo entre o pedido e seus desejos. Uma maneira comum de fazer isso é manter uma lista de tarefas mantidas pelo projeto. Itens que não são de responsabilidade de alguém são coletados em TODO-lists, a menos que alguém seja voluntário para assumir a responsabilidade. Todos os pedidos, sua distribuição e acompanhamento são tratados pela ferramenta <xref linkend="tool-bugzilla"/>.
Requirements analysis happens in two ways. The requests that come in are discussed on mailing lists, both within the main project and in the sub-project that the request belongs to or is spawned by the request. Furthermore, individual developers on the sub-project will evaluate the feasibility of the requests and determine the prioritisation between them. Other than archives of the discussions that have taken place, no outcome is created by this phase that is merged into the main project. A análise de requisitos acontece de duas maneiras. As solicitações que entram são discutidas em listas de discussão, tanto dentro do projeto principal quanto no subprojeto ao qual a solicitação pertence ou é gerada pela solicitação. Além disso, os desenvolvedores individuais no subprojeto avaliarão a viabilidade das solicitações e determinarão a priorização entre elas. Além dos arquivos das discussões que ocorreram, nenhum resultado é criado por essa fase que é incorporada ao projeto principal.
As the requests are prioritised by the individual developers on the basis of doing what they find interesting, necessary, or are funded to do, there is no overall strategy or prioritisation of what requests to regard as requirements and following up their correct implementation. However, most developers have some shared vision of what issues are more important, and they can ask for guidelines from the release engineering team. Como os pedidos são priorizados pelos desenvolvedores individuais com base em fazer o que eles acham interessante, necessário ou são financiados para fazer, não há estratégia geral ou priorização de solicitações que considerem como requisitos e acompanhamento de sua implementação correta. No entanto, a maioria dos desenvolvedores tem uma visão compartilhada de quais problemas são mais importantes e podem solicitar diretrizes da equipe de engenharia de release.
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.

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:1833
String age
a year ago
Source string age
a year ago
Translation file
books/pt_BR/dev-model.po, string 277