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

Translation

(itstool) path: section/para
English
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.
464/4330 · 433
Context English Portuguese (Brazil) State
After the code has been available for review and no further changes are necessary, the code is committed into the development branch, -CURRENT. If the change applies for the -STABLE branch or the other branches as well, a <quote>Merge From Current</quote> ("MFC") countdown is set by the committer. After the number of days the committer chose when setting the MFC have passed, an email will automatically be sent to the committer reminding them to commit it to the -STABLE branch (and possibly security branches as well). Only security critical changes should be merged to security branches. Depois que o código estiver disponível para revisão e nenhuma alteração adicional for necessária, o código será "committed" na branch de desenvolvimento, -CURRENT. Se a alteração se aplicar também à branch -STABLE ou às outras branches, uma contagem regressiva de um <quote>Merge From Current</quote> ("MFC") será definida pelo committer. Após o número de dias que o committer escolheu ao configurar o MFC, um email será enviado automaticamente ao committer, lembrando-o de enviá-lo para a branch -STABLE (e possivelmente também para branches de segurança). Apenas alterações críticas de segurança devem ser aplicadas a branch de segurança.
Delaying the commit to -STABLE and other branches allows for <quote>parallel debugging</quote> where the committed code is tested on a wide range of configurations. This makes changes to -STABLE to contain fewer faults and thus giving the branch its name. Atrasar o commit para -STABLE e outras branches permite <quote>depuração paralela</quote> onde o código "committed" é testado em uma ampla gama de configurações. Isso faz alterações no -STABLE para conter menos falhas e, assim, dar seu nome à branch.
Process summary: A committer commits code Resumo do processo: um committer aplica o código
_ external ref='proc-commit' md5='__failed__' external ref='proc-commit' md5='__failed__'
<imageobject><imagedata fileref="proc-commit"/></imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Refer to paragraph below for a screen-reader friendly version.</phrase> </textobject>
When a committer has written a piece of code and wants to commit it, they first need to determine if it is trivial enough to go in without prior review or if it should first be reviewed by the developer community. If the code is trivial or has been reviewed and the committer is not the maintainer, they should consult the maintainer before proceeding. If the code is contributed by an outside vendor, the maintainer should create a patch that is sent back to the vendor. The code is then committed and then deployed by the users. Should they find problems with the code, this will be reported and the committer can go back to writing a patch. If a vendor is affected, they can choose to implement or ignore the patch. Quando um committer escreveu um pedaço de código e quer fazer o seu commit, ele primeiro precisa determinar se é trivial o suficiente entrar sem uma análise prévia ou se deve ser revisado pela comunidade de desenvolvedores. Se o código é trivial ou foi revisado e o committer não é o mantenedor, ele deve consultar o mantenedor antes de continuar. Se o código for contribuído por um fornecedor externo, o mantenedor deve criar um patch que seja enviado de volta ao fornecedor. O código é então confirmado e implantado pelos usuários. Caso encontrem problemas com o código, isso será relatado e o committer poderá voltar a escrever um patch. Se um fornecedor for afetado, ele pode optar por implementar ou ignorar o patch.
Process summary: A contributor commits code Resumo do processo: um colaborador envia o código
_ external ref='proc-contrib' md5='__failed__' external ref='proc-contrib' md5='__failed__'
<imageobject><imagedata fileref="proc-contrib"/></imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Refer to paragraphs below and above for a screen-reader friendly version.</phrase> </textobject>
The difference when a contributor makes a code contribution is that they submit the code through the Bugzilla interface. This report is picked up by the maintainer who reviews the code and commits it. A diferença quando um colaborador faz uma contribuição de código é que ele envia o código através da interface do Bugzilla. Este relatório é escolhido pelo mantenedor que revisa o código e faz o seu commit.
Hats included in this process are: <_:orderedlist-1/> Hats incluídos neste processo são: <_:orderedlist-1/>
Core election Eleição do Core
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.

Loading…

User avatar None

New source string

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