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

Translation

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.
(itstool) path: section/para
English
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.
557/4920 · 492
Context English Portuguese (Brazil) State
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
.X releases are releases of the -STABLE branch. They are scheduled to come out every 4 months. As versões .X são releases da branch -STABLE. Elas estão programadas para sair a cada 4 meses.
.X.Y releases are security releases that follow the .X branch. These come out only when sufficient security fixes have been merged since the last release on that branch. New features are rarely included, and the security team is far more involved in these than in regular releases. As versões .X.Y são versões de segurança que seguem a branch .X. Eles saem somente quando correções de segurança suficientes foram feito aplicadas desde o último release nessa branch. Novos recursos raramente são incluídos e a equipe de segurança está muito mais envolvida nesses recursos do que em releases regulares.
There are three different kinds of releases: <_:orderedlist-1/> Existem três tipos diferentes de releases: <_:orderedlist-1/>
Many commercial vendors use these images to create CD-ROMs that are sold in retail outlets. Muitos fornecedores comerciais usam essas imagens para criar CD-ROMs que são vendidos em lojas de varejo.
For releases of the -STABLE-branch, the release process starts 45 days before the anticipated release date. During the first phase, the first 15 days, the developers merge what changes they have had in -CURRENT that they want to have in the release to the release branch. When this period is over, the code enters a 15 day code freeze in which only bug fixes, documentation updates, security-related fixes and minor device driver changes are allowed. These changes must be approved by the release engineer in advance. At the beginning of the last 15 day period a release candidate is created for widespread testing. Updates are less likely to be allowed during this period, except for important bug fixes and security updates. In this final period, all releases are considered release candidates. At the end of the release process, a release is created with the new version number, including binary distributions on web sites and the creation of CD-ROM images. However, the release is not considered "really released" until a <xref linkend="tool-pgp"/>-signed message stating exactly that, is sent to the mailing list freebsd-announce; anything labelled as a "release" before that may well be in-process and subject to change before the PGP-signed message is sent. <_:footnote-1/>. Para releases da branch -STABLE, o processo de release inicia 45 dias antes da data de lançamento prevista. Durante a primeira fase, os primeiros 15 dias, os desenvolvedores aplicam as alterações que tiveram no -CURRENT e que desejam ter na versão para a branch do release. Quando esse período terminar, o código entra em um congelamento de código de 15 dias, no qual apenas correções de bugs, atualizações de documentação, correções relacionadas à segurança e pequenas alterações de driver de dispositivo são permitidas. Essas alterações devem ser aprovadas pelo engenheiro de release com antecedência. No início do último período de 15 dias, um candidato a reçease é criado para testes generalizados. É menos provável que as atualizações sejam permitidas durante esse período, exceto por importantes correções de bugs e atualizações de segurança. Neste período final, todos os releases são considerados candidatos a release. No final do processo de release, uma release é criada com o novo número da versão, incluindo distribuições binárias em sites e a criação de imagens em CD-ROM. No entanto, a release não é considerado "realmente liberado" até que uma mensagem <xref linkend="tool-pgp"/>-assinada afirmando exatamente isso, seja enviada para a lista de discussão freebsd-announce; Qualquer coisa rotulada como "release" antes disso pode estar em processo e sujeita a alterações antes do envio da mensagem assinada pelo PGP. <_:footnote-1/>.
The releases of the -CURRENT-branch (that is, all releases that end with <quote>.0</quote>) are very similar, but with twice as long timeframe. It starts 8 weeks prior to the release with announcement of the release time line. Two weeks into the release process, the feature freeze is initiated and performance tweaks should be kept to a minimum. Four weeks prior to the release, an official beta version is made available. Two weeks prior to release, the code is officially branched into a new version. This version is given release candidate status, and as with the release engineering of -STABLE, the code freeze of the release candidate is hardened. However, development on the main development branch can continue. Other than these differences, the release engineering processes are alike. Os lançamentos da branch -CURRENT (ou seja, todas as releases que terminam com <quote>.0</quote>) são muito semelhantes, mas com o dobro do prazo. Começa 8 semanas antes do lançamento com o anúncio da linha do tempo da release. Duas semanas após o processo de release, o congelamento de recursos é iniciado e os ajustes de desempenho devem ser mantidos ao mínimo. Quatro semanas antes do lançamento, uma versão beta oficial é disponibilizada. Duas semanas antes do lançamento, o código é oficialmente transformado em uma nova versão. Esta versão recebe status de release candidate e, como na engenharia de release do -STABLE, o congelamento de código do release candidate é endurecido. No entanto, o desenvolvimento na branch principal de desenvolvimento pode continuar. Além dessas diferenças, os processos de engenharia de release são semelhantes.
.0 releases go into their own branch and are aimed mainly at early adopters. The branch then goes through a period of stabilisation, and it is not until the <xref linkend="role-releng"/> decides the demands to stability have been satisfied that the branch becomes -STABLE and -CURRENT targets the next major version. While this for the majority has been with .1 versions, this is not a demand. Releases .0 vão para o seu própria branch e são destinadas principalmente a adoções primárias. A branch passa por um período de estabilização, e não é até que o <xref linkend="role-releng"/> decida que as demandas de estabilidade foram satisfeitas e de que o branch se torna -STABLE e -CURRENT segmenta a próxima versão principal. Enquanto isso para a maioria tem sido com versões .1, isso não é uma demanda.
Most releases are made when a given date that has been deemed a long enough time since the previous release comes. A target is set for having major releases every 18 months and minor releases every 4 months. The user community has made it very clear that security and stability cannot be sacrificed by self-imposed deadlines and target release dates. For slips of time not to become too long with regards to security and stability issues, extra discipline is required when committing changes to -STABLE. A maioria das versões são feitas quando uma determinada data é considerada longa o suficiente desde o lançamento anterior. Uma data destino é definida para ter grandes releases a cada 18 meses e versões menores a cada 4 meses. A comunidade de usuários deixou bem claro que a segurança e a estabilidade não podem ser sacrificadas por prazos auto impostos e datas de lançamento desejadas. Por um lapso de tempo para não se tornar muito longo no que diz respeito a questões de segurança e estabilidade, é necessária uma disciplina extra ao aplicar alterações na -STABLE.
Make release schedule

Loading…

User avatar None

Source string changed

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

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.
8 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
Source string location
book.translate.xml:2153
String age
8 months ago
Source string age
8 months ago
Translation file
books/pt_BR/dev-model.po, string 305