2. FreeBSD Doc
  3. articles_committers-guide
  4. Portuguese (Brazil)
  5. Translate

Translation

(itstool) path: listitem/para
This may sound obvious, but if it really were so obvious then we probably would not see so many cases of people clearly not doing this. If your changes are to the kernel, make sure you can still compile both GENERIC and LINT. If your changes are anywhere else, make sure you can still make world. If your changes are to a branch, make sure your testing occurs with a machine which is running that code. If you have a change which also may break another architecture, be sure and test on all supported architectures. Please refer to the <link xlink:href="https://www.FreeBSD.org/internal/">FreeBSD Internal Page</link> for a list of available resources. As other architectures are added to the FreeBSD supported platforms list, the appropriate shared testing resources will be made available.
931/7910
Context English Portuguese (Brazil) State
All of this is never an option which the project's leadership enjoys in the slightest, but unity comes first. No amount of code or good advice is worth trading that away. Tudo isso nunca é uma opção que a liderança do projeto goste nem um pouco, mas a união vem em primeiro lugar. Nenhuma quantidade de código ou de bons conselhos vale a pena se trocar desta forma.
You were not always a committer. At one time you were a contributor. Remember that at all times. Remember what it was like trying to get help and attention. Do not forget that your work as a contributor was very important to you. Remember what it was like. Do not discourage, belittle, or demean contributors. Treat them with respect. They are our committers in waiting. They are every bit as important to the project as committers. Their contributions are as valid and as important as your own. After all, you made many contributions before you became a committer. Always remember that. Você nem sempre foi um committer. Houve uma época em que você era um colaborador. Lembre-se disso em todos os momentos. Lembre-se de como foi tentar obter ajuda e atenção. Não se esqueça de que seu trabalho como colaborador foi muito importante para você. Lembre-se de como foi. Não desencoraje, deprecie ou diminua os colaboradores. Trate-os com respeito. Eles são nossos committers em espera. Eles são tão importantes para o projeto quanto os committers. Suas contribuições são tão válidas e tão importantes quanto as suas. Afinal, você fez muitas contribuições antes de se tornar um committer. Sempre se lembre disso.
Consider the points raised under <xref linkend="respect"/> and apply them also to contributors. Considere os pontos levantados sob <xref linkend="respect"/> e aplique-os também aos contribuidores.
The repository is not where changes are initially submitted for correctness or argued over, that happens first in the mailing lists or by use of the Phabricator service. The commit will only happen once something resembling consensus has been reached. This does not mean that permission is required before correcting every obvious syntax error or manual page misspelling, just that it is good to develop a feel for when a proposed change is not quite such a no-brainer and requires some feedback first. People really do not mind sweeping changes if the result is something clearly better than what they had before, they just do not like being <emphasis>surprised</emphasis> by those changes. The very best way of making sure that things are on the right track is to have code reviewed by one or more other committers. O repositório não é onde as alterações são inicialmente submetidas para correção ou discussão, isso acontece primeiro nas listas de discussão ou pelo uso do serviço do Phabricator. O commit só acontecerá quando algo semelhante a um consenso for alcançado. Isso não significa que a permissão seja necessária antes de corrigir todos os erros óbvios de sintaxe ou erros ortográficos na página manual, significa apenas que é bom desenvolver uma ideia de quando a mudança proposta não é tão óbvia e requer algum feedback primeiro. As pessoas realmente não se importam com mudanças radicais se o resultado for algo claramente melhor do que antes, elas simplesmente não gostam de ser <emphasis>surpreendidas</emphasis> por essas mudanças. A melhor maneira de certificar-se de que as coisas estão no caminho certo é ter o código revisado por um ou mais committers.
When in doubt, ask for review! Em caso de dúvida, peça por uma revisão!
Respect existing maintainers if listed. Respeite os mantenedores existentes, se listados.
Many parts of FreeBSD are not <quote>owned</quote> in the sense that any specific individual will jump up and yell if you commit a change to <quote>their</quote> area, but it still pays to check first. One convention we use is to put a maintainer line in the <filename>Makefile</filename> for any package or subtree which is being actively maintained by one or more people; see <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/developers-handbook/policies.html">https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/developers-handbook/policies.html</link> for documentation on this. Where sections of code have several maintainers, commits to affected areas by one maintainer need to be reviewed by at least one other maintainer. In cases where the <quote>maintainer-ship</quote> of something is not clear, look at the repository logs for the files in question and see if someone has been working recently or predominantly in that area. Muitas partes do FreeBSD não são <quote>possuídas</quote> no sentido de que qualquer indivíduo específico irá pular e gritar se você enviar uma alteração para a <quote>sua</quote> área, mas ainda vale a pena verificar primeiro. Uma convenção que usamos é colocar uma linha de mantenedor no <filename>Makefile</filename> para qualquer pacote ou subárvore que esteja sendo mantido ativamente por uma ou mais pessoas; veja <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/developers-handbook/policies.html">https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/developers-handbook/policies.html</link> para documentação sobre isso. Nas seções de código para quais existirem vários mantenedores, os commits nas áreas afetadas por um mantenedor precisarão ser revisados por pelo menos um outro mantenedor. Nos casos em que o <quote>maintainer-ship</quote> de algo não está claro, consulte os logs do repositório para os arquivos em questão e veja se alguém está trabalhando recentemente ou predominantemente naquela área.
This may be hard to swallow in times of conflict (when each side is convinced that they are in the right, of course) but a version control system makes it unnecessary to have an ongoing dispute raging when it is far easier to simply reverse the disputed change, get everyone calmed down again and then try to figure out what is the best way to proceed. If the change turns out to be the best thing after all, it can be easily brought back. If it turns out not to be, then the users did not have to live with the bogus change in the tree while everyone was busily debating its merits. People <emphasis>very</emphasis> rarely call for back-outs in the repository since discussion generally exposes bad or controversial changes before the commit even happens, but on such rare occasions the back-out should be done without argument so that we can get immediately on to the topic of figuring out whether it was bogus or not. Isso pode ser difícil de engolir em momentos de conflito (quando cada lado está convencido de que eles estão certos, é claro), mas um sistema de controle de versão torna desnecessário ter uma disputa em andamento quando é muito mais fácil simplesmente reverter a mudança que gerou a disputa, faça com que todos se acalmem novamente e tente descobrir qual é a melhor maneira de proceder. Se a mudança acaba por ser a melhor coisa depois de tudo, ela pode ser facilmente trazida de volta. Se ela não for, os usuários não terão que viver com a mudança falsa na árvore enquanto todos estavam ocupados debatendo seus méritos. Pessoas <emphasis>muito</emphasis> raramente pedem rollbacks no repositório, uma vez que a discussão geralmente expõe mudanças ruins ou controversas antes que o commit aconteça, mas em raras ocasiões o rollback deve ser feito sem discussão para que possamos entrar imediatamente da discussão do tópico para descobrirmos se ele era adequado ou não.
Changes go to FreeBSD-CURRENT before FreeBSD-STABLE unless specifically permitted by the release engineer or unless they are not applicable to FreeBSD-CURRENT. Any non-trivial or non-urgent change which is applicable should also be allowed to sit in FreeBSD-CURRENT for at least 3 days before merging so that it can be given sufficient testing. The release engineer has the same authority over the FreeBSD-STABLE branch as outlined in rule #5. As alterações vão para o FreeBSD-CURRENT antes do FreeBSD-STABLE, a menos que especificamente permitido pelo engenheiro de release ou a menos que elas não sejam aplicáveis ao FreeBSD-CURRENT. Qualquer alteração não trivial ou não urgente que seja aplicável também deve ser permitida no FreeBSD-CURRENT por pelo menos 3 dias antes da fusão, para que possa ter tempo suficiente de teste. O engenheiro de lançamento tem a mesma autoridade sobre o branch FreeBSD-STABLE, conforme descrito na regra #5.
This is another <quote>do not argue about it</quote> issue since it is the release engineer who is ultimately responsible (and gets beaten up) if a change turns out to be bad. Please respect this and give the release engineer your full cooperation when it comes to the FreeBSD-STABLE branch. The management of FreeBSD-STABLE may frequently seem to be overly conservative to the casual observer, but also bear in mind the fact that conservatism is supposed to be the hallmark of FreeBSD-STABLE and different rules apply there than in FreeBSD-CURRENT. There is also really no point in having FreeBSD-CURRENT be a testing ground if changes are merged over to FreeBSD-STABLE immediately. Changes need a chance to be tested by the FreeBSD-CURRENT developers, so allow some time to elapse before merging unless the FreeBSD-STABLE fix is critical, time sensitive or so obvious as to make further testing unnecessary (spelling fixes to manual pages, obvious bug/typo fixes, etc.) In other words, apply common sense. Este é outro problema do tipo <quote>não discuta sobre isso</quote>, já que é o engenheiro de release quem é o responsável final (e é espancado) se uma mudança for ruim. Por favor, respeite isso e dê ao engenheiro de release a sua total cooperação quando se trata do branch FreeBSD-STABLE. O gerenciamento do FreeBSD-STABLE pode frequentemente parecer excessivamente conservador para o observador casual, mas também deve ter em mente o fato de que o conservadorismo deve ser a marca do FreeBSD-STABLE e regras diferentes aplicam-se lá do que no FreeBSD-CURRENT. Também não há sentido em fazer com que o FreeBSD-CURRENT seja um campo de testes se as alterações forem mescladas no FreeBSD-STABLE imediatamente. Mudanças precisam de uma chance de serem testadas pelos desenvolvedores do FreeBSD-CURRENT, então espere algum tempo antes da fusão, a menos que a correção do FreeBSD-STABLE seja crítica, sensível ao tempo ou óbvia a ponto de tornar desnecessário testes adicionais (correções ortográficas nas páginas de manual) correções de erros / erros de digitação, etc.) Em outras palavras, aplique o bom senso.
Changes to the security branches (for example, <literal>releng/9.3</literal>) must be approved by a member of the Security Officer Team <email>security-officer@FreeBSD.org</email>, or in some cases, by a member of the Release Engineering Team <email>re@FreeBSD.org</email>. Mudanças nas branches de segurança (por exemplo, <literal>releng/9.3</literal>) devem ser aprovadas por um membro da Equipe de Segurança <email>security-officer@FreeBSD.org</email>, ou em alguns casos , por um membro da Equipe de Engenharia de Release<email>re@FreeBSD.org</email>.
This project has a public image to uphold and that image is very important to all of us, especially if we are to continue to attract new members. There will be occasions when, despite everyone's very best attempts at self-control, tempers are lost and angry words are exchanged. The best thing that can be done in such cases is to minimize the effects of this until everyone has cooled back down. Do not air angry words in public and do not forward private correspondence or other private communications to public mailing lists, mail aliases, instant messaging channels or social media sites. What people say one-to-one is often much less sugar-coated than what they would say in public, and such communications therefore have no place there - they only serve to inflame an already bad situation. If the person sending a flame-o-gram at least had the grace to send it privately, then have the grace to keep it private yourself. If you feel you are being unfairly treated by another developer, and it is causing you anguish, bring the matter up with core rather than taking it public. Core will do its best to play peace makers and get things back to sanity. In cases where the dispute involves a change to the codebase and the participants do not appear to be reaching an amicable agreement, core may appoint a mutually-agreeable third party to resolve the dispute. All parties involved must then agree to be bound by the decision reached by this third party. Este projeto tem uma imagem pública a defender e essa imagem é muito importante para todos nós, especialmente se quisermos continuar a atrair novos membros. Haverá ocasiões em que, apesar das melhores tentativas de autocontrole de todos, os ânimos se perdem e palavras de raiva são trocadas. A melhor coisa que pode ser feita nesses casos é minimizar os efeitos disso até que todos tenham esfriado. Não divulgue palavras iradas em público e não encaminhe correspondências privadas ou outras comunicações privadas para listas publicas de discussão, aliases de mensagens, canais de mensagens instantâneas ou sites de mídia social. O que as pessoas dizem um-para-um é frequentemente muito menos revestido de açúcar do que o que eles diriam em público, e tais comunicações, portanto, não têm lugar lá - elas servem apenas para inflamar uma situação já ruim. Se a pessoa que enviou um flame-o-grama tiver pelo menos a elegância de enviá-lo em particular, então tenha a elegância de mantê-lo em sigilo. Se você acha que está sendo tratado injustamente por outro desenvolvedor e está lhe causando angústia, traga o assunto para o core em vez de torná-lo público. O Core fará o seu melhor para atuar como pacificadores e trazer as coisas de volta para a sanidade. Nos casos em que a disputa envolve uma alteração na base de código e os participantes não parecem estar chegando a um acordo amigável, o core pode nomear um terceiro mutuamente aceitável para resolver a disputa. Todas as partes envolvidas devem então concordar em se comprometer com a decisão tomada por este terceiro.
Respect all code freezes and read the <literal>committers</literal> and <literal>developers</literal> mailing list on a timely basis so you know when a code freeze is in effect. Respeite todos os congelamentos de código e leia atempadamente a lista de discussão <literal>committers</literal> e <literal>developers</literal> para saber quando um congelamento de código está em vigor.
Committing unapproved changes during a code freeze is a really big mistake and committers are expected to keep up-to-date on what is going on before jumping in after a long absence and committing 10 megabytes worth of accumulated stuff. People who abuse this on a regular basis will have their commit privileges suspended until they get back from the FreeBSD Happy Reeducation Camp we run in Greenland. Efetuar o commit de alterações não aprovadas durante um congelamento de código é um erro realmente grande e espera-se que os committers se mantenham atualizados sobre o que está acontecendo antes de entrar depois de uma longa ausência e fazer o commit de 10 megabytes de material acumulado. As pessoas que abusarem disso regularmente terão seus privilégios de commit suspensos até que eles voltem do FreeBSD Happy Reeducation Camp que mantemos na Groenlândia.
Many mistakes are made because someone is in a hurry and just assumes they know the right way of doing something. If you have not done it before, chances are good that you do not actually know the way we do things and really need to ask first or you are going to completely embarrass yourself in public. There is no shame in asking <quote>how in the heck do I do this?</quote> We already know you are an intelligent person; otherwise, you would not be a committer. Muitos erros são cometidos porque alguém está com pressa e apenas assume que sabe a forma certa para fazer alguma coisa. Se você não fez isso antes, é bem provável que você não conheça realmente a maneira como fazemos as coisas e realmente precise perguntar primeiro ou você vai se envergonhar completamente em público. Não há vergonha em perguntar <quote>como diabos eu faço isso?</quote> Já sabemos que você é uma pessoa inteligente; caso contrário, você não seria um committer.
This may sound obvious, but if it really were so obvious then we probably would not see so many cases of people clearly not doing this. If your changes are to the kernel, make sure you can still compile both GENERIC and LINT. If your changes are anywhere else, make sure you can still make world. If your changes are to a branch, make sure your testing occurs with a machine which is running that code. If you have a change which also may break another architecture, be sure and test on all supported architectures. Please refer to the <link xlink:href="https://www.FreeBSD.org/internal/">FreeBSD Internal Page</link> for a list of available resources. As other architectures are added to the FreeBSD supported platforms list, the appropriate shared testing resources will be made available. Isso pode parecer óbvio, mas se realmente fosse tão óbvio, provavelmente não veríamos tantos casos de pessoas claramente não fazendo isso. Se suas mudanças são para o kernel, certifique-se de que você ainda pode compilar o GENERIC e o LINT. Se as suas alterações estiverem em outro lugar, certifique-se de que você ainda pode fazer um "make world". Se as alterações forem feitas em uma branch, certifique-se de que seu teste ocorra com uma máquina que esteja executando esse código. Se você tiver uma alteração que também possa quebrar outra arquitetura, verifique e teste em todas as arquiteturas suportadas. Por favor, consulte a <link xlink:href="https://www.FreeBSD.org/internal/">Página Interna do FreeBSD</link> para obter uma lista dos recursos disponíveis. À medida que outras arquiteturas são adicionadas à lista de plataformas suportadas do FreeBSD, os recursos de teste compartilhados apropriados serão disponibilizados.
Contributed software is anything under the <filename>src/contrib</filename>, <filename>src/crypto</filename>, or <filename>src/sys/contrib</filename> trees. Software contribuído é qualquer código que esteja sob as árvores <filename>src/contrib</filename>, <filename>src/crypto</filename>, ou <filename>src/sys/contrib</filename>.
The trees mentioned above are for contributed software usually imported onto a vendor branch. Committing something there may cause unnecessary headaches when importing newer versions of the software. As a general consider sending patches upstream to the vendor. Patches may be committed to FreeBSD first with permission of the maintainer. As árvores mencionadas acima são para software contribuído geralmente importado para um branch de fornecedor. Fazer o commit de algo lá pode causar dores de cabeça desnecessárias quando for importado novas versões do software. Uma regra geral é considerar enviar os patches upstream diretamente para o fornecedor. Patches podem ser committados primeiramente no FreeBSD, desde que tenha a permissão do mantenedor.
Reasons for modifying upstream software range from wanting strict control over a tightly coupled dependency to lack of portability in the canonical repository's distribution of their code. Regardless of the reason, effort to minimize the maintenance burden of fork is helpful to fellow maintainers. Avoid committing trivial or cosmetic changes to files since it makes every merge thereafter more difficult: such patches need to be manually re-verified every import. As razões para modificar o software upstream variam entre querer controle estrito sobre uma dependência fortemente acoplada à falta de portabilidade na distribuição do repositório canônico do seu código. Independentemente do motivo, o esforço para minimizar a carga de manutenção do fork é útil para outros mantenedores. Evite realizar commits de alterações triviais ou cosméticas nos arquivos, pois isso dificulta cada merge: esses patches precisam ser verificados manualmente a cada importação.
If a particular piece of software lacks a maintainer, you are encouraged to take up ownership. If you are unsure of the current maintainership email <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-arch">FreeBSD architecture and design mailing list</link> and ask. Se uma parte específica do software não tiver um mantenedor, você é incentivado a assumir a propriedade. Se você não tiver certeza sobre o mantenedor atual, envie um email para a <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-arch">lista de email de arquitetura e design do FreeBSD</link> e pergunte.
Policy on Multiple Architectures Política sobre Várias Arquiteturas
FreeBSD has added several new architecture ports during recent release cycles and is truly no longer an <trademark>i386</trademark> centric operating system. In an effort to make it easier to keep FreeBSD portable across the platforms we support, core has developed this mandate: O FreeBSD adicionou ports para várias novas arquiteturas durante os ciclos de release recentes e realmente não é mais um sistema operacional centrado em <trademark>i386</trademark>. Em um esforço para tornar mais fácil manter o FreeBSD portátil entre as plataformas que suportamos, o core desenvolveu este mandato:
Our 32-bit reference platform is i386, and our 64-bit reference platform is amd64. Major design work (including major API and ABI changes) must prove itself on at least one 32-bit and at least one 64-bit platform, preferably the primary reference platforms, before it may be committed to the source tree. Nossa plataforma de referência de 32 bits é a i386 e a nossa plataforma de referência de 64 bits é amd64. O principal trabalho de design (incluindo as principais alterações da API e da ABI) deve ser comprovado em pelo menos uma plataforma de 32 bits e pelo menos uma de 64 bits, preferencialmente nas plataformas de referência primária, antes que o seu commit possa ser feito na árvore de fontes.
The i386 and amd64 platforms were chosen due to being more readily available to developers and as representatives of more diverse processor and system designs - big versus little endian, register file versus register stack, different DMA and cache implementations, hardware page tables versus software TLB management etc. As plataformas i386 e amd64 foram escolhidas por estarem mais prontamente disponíveis para os desenvolvedores e como representantes dos mais diversos designs de processador e de sistema - "big versus little endian", registrador de arquivos versus pilha de registro, diferentes implementações de DMA e cache, tabelas de página de hardware versus gerenciamento de TLB de software, etc.
We will continue to re-evaluate this policy as cost and availability of the 64-bit platforms change. Continuaremos a reavaliar essa política, já que o custo e a disponibilidade das plataformas de 64 bits mudam.
Developers should also be aware of our Tier Policy for the long term support of hardware architectures. The rules here are intended to provide guidance during the development process, and are distinct from the requirements for features and architectures listed in that section. The Tier rules for feature support on architectures at release-time are more strict than the rules for changes during the development process. Os desenvolvedores também devem estar cientes da nossa Política de Tier para o suporte de longo prazo das arquiteturas de hardware. As regras aqui pretendem fornecer orientação durante o processo de desenvolvimento e são diferentes dos requisitos de recursos e arquiteturas listados nessa seção. As regras de Tier para suporte de recursos em arquiteturas no momento da release são mais rigorosas do que as regras para alterações durante o processo de desenvolvimento.
Other Suggestions Outras Sugestões
When committing documentation changes, use a spell checker before committing. For all XML docs, verify that the formatting directives are correct by running <command>make lint</command> and <package>textproc/igor</package>. Ao enviar alterações na documentação, use um verificador ortográfico antes de efetuar o commit. Para todos os documentos XML, verifique se as diretivas de formatação estão corretas executando o <command>make lint</command> e o <package>textproc/igor</package>.
For manual pages, run <package>sysutils/manck</package> and <package>textproc/igor</package> over the manual page to verify all of the cross references and file references are correct and that the man page has all of the appropriate <varname>MLINK</varname>s installed. Para as páginas de manual, execute o <package>sysutils/manck</package> e o <package>textproc/igor</package> na página de manual para verificar se todas as referências cruzadas e referências de arquivo estão corretas e se a página man possui todos os <varname>MLINK</varname>s apropriados instalados.
Do not mix style fixes with new functionality. A style fix is any change which does not modify the functionality of the code. Mixing the changes obfuscates the functionality change when asking for differences between revisions, which can hide any new bugs. Do not include whitespace changes with content changes in commits to <filename>doc/</filename> . The extra clutter in the diffs makes the translators' job much more difficult. Instead, make any style or whitespace changes in separate commits that are clearly labeled as such in the commit message. Não misture correções de estilo com novas funcionalidades. Uma correção de estilo é qualquer alteração que não modifique a funcionalidade do código. Misturar as alterações ofusca a mudança de funcionalidade ao solicitar a comparação das diferenças entre as revisões, o que pode ocultar quaisquer novos bugs. Não inclua alterações de espaço em branco com alterações de conteúdo nos commits para <filename>doc/</filename>. A desordem extra nos diffs torna o trabalho dos tradutores muito mais difícil. Em vez disso, faça qualquer alteração de estilo ou espaço em branco em commits separados e que sejam claramente rotuladas como tal na mensagem de commit.
Deprecating Features Recursos Obsoletos (Deprecated)

Loading…

No matching activity found.

Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: listitem/para
Source string location
article.translate.xml:3679
String age
a year ago
Source string age
a year ago
Translation file
articles/pt_BR/committers-guide.po, string 686