| /linux/Documentation/translations/pt_BR/process/ |
| H A D | security-bugs.rst | 24 será processado. Uma parte significativa dos relatórios é de bugs que já
39 imagem de sistema de arquivos, etc). Executáveis apenas binários não são
72 pois podem ser úteis para manter os usuários finais protegidos durante o
95 iminente para muitos usuários. Antes de relatar, considere se o problema
111 triagem de que outros relatórios precisam.
133 lista certa de destinatários para enviar um relatório. No kernel Linux, todos
187 Uma fração significativa dos relatórios de bugs enviados à equipe de segurança
191 forçados a ignorar tais relatórios devido à sua má qualidade ou precisão. Sendo
192 assim, os relatores devem ter um cuidado especial com vários pontos que tendem
193 a tornar esses relatórios desnecessariamente difíceis de lidar:
[all …]
|
| H A D | 6.Followthrough.rst | 27 Um patch de qualquer relevância resultará em uma série de comentários de outros
64 O que tudo isso significa é que, quando os revisores lhe enviam comentários,
67 que isso aconteça. Quando você receber comentários de revisão em um patch,
89 Um erro fatal é ignorar os comentários de revisão na esperança de que eles
91 respondido aos comentários que recebeu da vez anterior, é provável que descubra
136 você receber mais comentários de um novo conjunto de revisores; esses
137 comentários precisam ser respondidos da mesma forma que na rodada anterior.
158 uma nova rodada de comentários de desenvolvedores que não estavam cientes do
168 próprios kernels. E, logicamente, onde há testadores, haverá relatórios de
185 responda aos relatórios de erros e corrija os problemas, se for viável. É para
[all …]
|
| H A D | maintainer-tip.rst | 9 A árvore tip é uma coleção de vários subsistemas e áreas de
91 - **Vários componentes de código do núcleo**:
140 Também é útil estruturar o changelog em vários parágrafos e não
213 Para cenários complexos, especialmente condições de corrida (race conditions) e problemas
481 Frases em comentários começam com uma letra maiúscula.
483 Comentários de linha única::
487 Comentários de várias linhas::
496 Sem comentários no fim da linha (veja abaixo):
498 …Por favor, abstenha-se de usar comentários no fim da linha. Comentários no fim da linha atrapalham…
506 Use comentários independentes em vez disso::
[all …]
|
| H A D | stable-api-nonsense.rst | 23 2.6. Essa é a interface cuja estabilidade os usuários e desenvolvedores de
47 código-fonte fechado, código-fonte oculto, blobs binários, wrappers de
84 processadores. Não há como drivers binários compilados para uma arquitetura
87 Vários desses problemas podem ser contornados simplesmente compilando o módulo
95 Linux contém vários kernels, cada um ajustado para diferentes tipos de
126 assíncrono. Isso reduziu a complexidade de vários drivers e aumentou a
134 Isso contrasta fortemente com vários sistemas operacionais de código fechado,
207 Robert Love e Nishanth Aravamudan pela revisão e pelos comentários sobre
|
| H A D | coding-style.rst | 43 A maneira preferida de aliviar vários níveis de indentação em uma instrução
94 Fora de comentários, documentação e, exceto em Kconfig, espaços nunca são
198 linhas vazias para colocar comentários.
278 Use um espaço em volta (de cada lado) da maioria dos operadores binários e
279 ternários, como qualquer um destes::
283 mas sem espaço após operadores unários::
287 sem espaço antes dos operadores unários pós-fixados de incremento e
292 sem espaço após os operadores unários prefixados de incremento e
328 que conta o número de usuários ativos, você deve chamá-la de
432 permitidos -- embora não sejam obrigatórios em código novo seu.
[all …]
|
| H A D | maintainer-kvm-x86.rst | 19 Testes são obrigatórios. Seja consistente com os estilos e padrões estabelecidos.
133 Exceto por alguns casos excepcionais, não use comentários kernel-doc para
138 Comentários
140 Escreva comentários usando o modo imperativo e evite pronomes. Use comentários
143 o código falar por si mesmo. Se o código em si for inescrutável, comentários
155 em comentários. Em vez disso, se necessário (veja abaixo), copie e cole o trecho
160 em comentários. Com poucas exceções, o KVM *deve* respeitar o comportamento
228 x86 por vários motivos. Primeiro e mais importante, qual código está sendo
281 execução, por exemplo, patches que apenas modificam comentários. Sempre que
307 Testes específicos do KVM não são estritamente obrigatórios, por exemplo, se a
[all …]
|
| H A D | submitting-patches.rst | 59 que você acredita que ele pode ter sobre os usuários. Tenha em mente que a
181 Por outro lado, se você fizer uma única alteração em vários arquivos,
226 O verificador emite relatórios em três níveis:
234 Selecione os destinatários do seu patch
248 patches, mas o volume dessa lista fez com que vários desenvolvedores a
266 disponibilizem o patch aos usuários; em tais casos, obviamente, o
320 Responda aos comentários de revisão
323 Seu patch quase certamente receberá comentários dos revisores sobre maneiras
325 e-mail. Você deve responder a esses comentários; ignorar revisores é uma
327 e-mails deles para responder aos seus comentários. Comentários de revisão
[all …]
|
| H A D | 4.Coding.rst | 82 projeto que envolva vários milhões de linhas de código poderia fazer o
176 Esse código mostrava vários sinais de ter sido desenvolvido a portas fechadas em
205 usuários existentes. Esse tipo de alteração é chamado de "regressão", e as
269 - DEBUG_OBJECTS adicionará código para rastrear o tempo de vida de vários
292 diante. Em outras palavras, o lockdep pode encontrar uma série de cenários nos
294 problema pode ser doloroso (tanto para desenvolvedores quanto para usuários) em
352 outros desenvolvedores e será útil para os seus usuários. Em muitos casos, a
379 comentários com formatação especial; esses comentários podem ser extraídos e
381 trabalhando em um subsistema que possui comentários kerneldoc, você deve
384 mal nenhum em adicionar comentários kerneldoc para o futuro; de fato, esta pode
[all …]
|
| H A D | howto.rst | 104 Este arquivo fornece uma lista das versões mínimas de vários pacotes de
105 software que são necessários para compilar e executar o kernel com
301 Este é o ramo recomendado para usuários que desejam o kernel estável
319 Os mantenedores dos vários subsistemas do kernel — e também muitos
321 desenvolvimento em repositórios de código-fonte. Dessa forma, outros
328 A maioria desses repositórios são árvores git, mas também existem outros
330 endereços desses repositórios de subsistemas estão listados no arquivo
335 discussão (veja a seção respectiva abaixo). Para vários subsistemas do
338 quaisquer comentários sobre um patch ou revisões feitas a ele, e os
425 Se várias pessoas responderem ao seu e-mail, a lista de destinatários em
[all …]
|
| H A D | maintainer-handbooks.rst | 19 a critérios específicos de submissão. Veja
|
| H A D | kernel-driver-statement.rst | 13 nocivos aos usuários do Linux, às empresas e ao ecossistema Linux como
16 seus usuários do conhecimento da comunidade Linux. Fornecedores que
|
| H A D | code-of-conduct.rst | 35 * Provocações (*trolling*), comentários insultuosos/depreciativos e ataques
51 comentários, commits, código, edições em wiki, issues e outras contribuições que
|
| H A D | 2.Process.rst | 8 usuários e desenvolvedores. Com uma base de usuários atualmente na casa
172 comentários que tiverem. Se tudo correr bem, esse processo deve apontar
196 gerenciado por Linus Torvalds. Mais comentários e/ou problemas podem surgir
200 - Lançamento estável. O número de usuários potencialmente
247 alto nível pedirão a Linus para realizar o pull de seus repositórios os patches
259 de repositórios pode ser arbitrariamente longa, embora raramente exceda dois
330 muitos subdiretórios para drivers ou sistemas de arquivos que estão a caminho
366 comunidade do kernel é o Git. O Git é um entre vários sistemas de controle
369 excelente desempenho ao lidar com grandes repositórios e grandes volumes de
447 destinatários. Sempre certifique-se de que a pessoa a quem você está
|
| H A D | embargoed-hardware-issues.rst | 92 hardware no passado e possui os mecanismos necessários para permitir o
121 a fusos horários e outros fatores, devendo ser usadas apenas quando estritamente
157 a vários propósitos:
188 do Linux e tem sido usado com sucesso para desenvolver mitigações para vários
279 CVEs, nem os CVEs são necessários para o processo de desenvolvimento. Se os CVEs
288 acerca do processo de relatórios e tratamento posterior. Os embaixadores não
|
| H A D | maintainer-netdev.rst | 26 de diretórios do Linux.
37 rede do Linux (ex: RFCs, revisões, comentários, etc.) ocorre na **netdev**.
72 Existem duas árvores de rede (repositórios git) em jogo. Ambas são coordenadas
215 comentários e respostas cheguem após uma semana de silêncio. Se um
242 Mesmo os usuários que não bebem leite apreciam ouvir as vacas dizendo
543 upstream são obrigatórios.
570 fornecedores, hospedagem de CI no GitHub (GH CI), outros repositórios sob o
586 seus comentários impedirem ou desviarem o fluxo de patches. Uma tag Reviewed-by
598 funcionários. Sinta-se à vontade para solicitar feedback dos mantenedores da
|
| H A D | kernel-enforcement-statement.rst | 17 desenvolvimento assumir o seguinte compromisso com os usuários do kernel Linux,
43 este software. Queremos trabalhar com os usuários de forma aberta e transparente
|
| H A D | submit-checklist.rst | 33 atendam aos critérios de exceção documentados em
105 para capturar vários problemas de portabilidade decorrentes de falsas
|
| H A D | code-of-conduct-interpretation.rst | 96 de e-mail públicas distribuídas por vários servidores diferentes controlados
112 e-mail e comentários associados em mensagens de listas de discussão,
113 mensagens de log de alterações (changelog) do kernel ou comentários no
137 O Comitê do Código de Conduta consiste em membros voluntários da comunidade
|
| H A D | 3.Early-stage.rst | 47 comunicar os requisitos dos usuários a essas pessoas é uma perda de tempo.
64 - Quem são os usuários afetados por esse problema? Quais casos de uso a
193 Se uma postagem de pedido de comentários (RFC) render poucos
194 comentários, não presuma que isso significa que não há interesse no
|
| H A D | botching-up-ioctls.rst | 133 morrem, e seus usuários não vão gostar mais de você se você travar a máquina
139 * Tenha casos de teste para os cenários mais complexos (corner cases) no seu
179 não é um bug, já que os timeouts sempre podem ser estendidos -- mas os usuários
188 * Tenha casos de teste para cenários complexos (corner-cases), especialmente se
|
| H A D | maintainer-devicetree.rst | 29 os mantenedores de DT podem fazer comentários, mas, em geral, não se espera
|
| /linux/Documentation/translations/pt_BR/admin-guide/ |
| H A D | index.rst | 66 Aqui está um conjunto de documentos voltados a usuários que estão tentando
110 Suporte a formatos binários não nativos. Observe que alguns destes
|
| H A D | devices.rst | 74 Links obrigatórios
145 Sockets e pipes nomeados não transitórios podem existir em /dev. As entradas
180 seção explica a nomenclatura e o uso dos vários tipos de TTY. Observe que as
226 tanto diferentes dos dispositivos primários. Seu principal propósito é
261 capacidade de SLIP ou PPP) a processos arbitrários geradores de dados. Cada
|
| H A D | README.rst | 53 gerais do UNIX. Eu recomendaria procurar nos subdiretórios de documentação
58 - Existem vários arquivos README no subdiretório Documentation/: eles
126 Compilar e executar os kernels 6.x exige versões atualizadas de vários
255 - Ter drivers desnecessários deixará o kernel maior e, em algumas
378 Dicas sobre como entender os relatórios de bugs do kernel estão em
|
| /linux/Documentation/translations/pt_BR/ |
| H A D | index.rst | 46 Uma tradução não é um *fork* da documentação oficial; portanto, os usuários não
74 Os guias para usuários e administradores do kernel Linux.
|