Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

docs: pt_BR: translate process/1.Intro.rst

Add Brazilian Portuguese translation of the development process
introduction (Documentation/process/1.Intro.rst), covering the
executive summary, importance of mainline code, and licensing.

Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Daniel Castro <arantescastro@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260317140136.29256-1-arantescastro@gmail.com>

authored by

Daniel Castro and committed by
Jonathan Corbet
a0529bbe 98b764fd

+270
+1
Documentation/translations/pt_BR/index.rst
··· 66 66 .. toctree:: 67 67 :maxdepth: 1 68 68 69 + Introdução <process/1.Intro> 69 70 Como começar <process/howto> 70 71 Requisitos mínimos <process/changes> 71 72 Manuais dos mantenedores <process/maintainer-handbooks>
+269
Documentation/translations/pt_BR/process/1.Intro.rst
··· 1 + .. SPDX-License-Identifier: GPL-2.0 2 + 3 + Introdução 4 + ========== 5 + 6 + Sumário 7 + ------- 8 + 9 + O restante desta seção cobre o processo de desenvolvimento do kernel e os 10 + tipos de frustração que os desenvolvedores e empresas podem encontrar pelo 11 + caminho. Existem diversas razões que justificam a recomendação para que seja 12 + feito o merge do código do kernel ao kernel principal ("mainline"), como 13 + disponibilidade automática aos usuários, suporte da comunidade em diversas 14 + formas, e a oportunidade de influenciar a direção do desenvolvimento do 15 + kernel. Contribuições ao kernel Linux obrigatoriamente devem estar disponíveis 16 + sob uma licença compatível com a GPL. 17 + 18 + :ref:`development_process` apresenta o processo de desenvolvimento, o ciclo de 19 + lançamento, e a mecânica da janela de merge. As várias fases no desenvolvimento 20 + de patch, revisão, e ciclo de merge são explicadas. Algumas ferramentas e 21 + listas de e-mail são discutidas. Desenvolvedores que queiram começar a 22 + desenvolver o kernel são encorajados a buscar e corrigir bugs como exercício 23 + inicial. 24 + 25 + :ref:`development_early_stage` cobre os primeiros passos do processo de 26 + desenvolvimento, com ênfase no envolvimento da comunidade de desenvolvedores o 27 + mais cedo possível. 28 + 29 + :ref:`development_coding` é sobre o processo de codificação; muitas armadilhas 30 + já encontradas por outros desenvolvedores são discutidas. Alguns requisitos 31 + para patches são explicados, e é feita uma introdução para algumas ferramentas 32 + que podem ajudar a garantir que os patches de kernel estão corretos. 33 + 34 + :ref:`development_posting` fala sobre o processo de envio de patches para 35 + revisão. Para serem levados em consideração pela comunidade desenvolvedora, os 36 + patches devem estar devidamente formatados e descritos, assim como devem estar 37 + no lugar correto. Seguir os conselhos dessa seção pode ajudar na recepção 38 + positiva do seu trabalho. 39 + 40 + :ref:`development_followthrough` cobre o que acontece após o envio dos patches; 41 + o trabalho ainda está longe de estar concluído. Trabalhar com os revisores é 42 + parte crucial do processo de desenvolvimento; essa seção oferece dicas de como 43 + evitar problemas nesse estágio importante. Desenvolvedores são alertados a não 44 + presumir que o trabalho acabou após o merge do patch no "mainline". 45 + 46 + :ref:`development_advancedtopics` introduz dois tópicos mais "avançados": 47 + gerenciamento de patches com git e revisão de patches por outros. 48 + 49 + :ref:`development_conclusion` conclui o documento com indicações de fontes com 50 + mais informações sobre o desenvolvimento do kernel. 51 + 52 + Sobre este documento 53 + -------------------- 54 + 55 + O kernel Linux, com mais de 8 milhões de linhas de código e bem mais de 1000 56 + contribuintes a cada lançamento ("release"), é um dos maiores e mais ativos 57 + projetos de software livre em existência. Desde seu modesto início em 1991, 58 + este kernel evoluiu para se tornar um dos melhores componentes de sistemas 59 + operacionais, rodando em pequenos players de música digital, PCs de mesa, os 60 + maiores supercomputadores em existência, e todos os outros tipos de sistema 61 + entre eles. É robusto, eficiente, e uma solução escalável para quase toda 62 + situação. 63 + 64 + O crescimento do Linux trouxe o aumento no número de desenvolvedores (e 65 + empresas) desejando participar no seu desenvolvimento. Fabricantes de hardware 66 + querem garantir que o Linux suporte bem os seus produtos, tornando-os atrativos 67 + para usuários Linux. Fabricantes de sistemas embarcados, que usam o Linux como 68 + componente em um produto integrado, querem que o Linux seja tão capaz e 69 + adequado quanto possível para a tarefa em questão. Distribuidores de software 70 + que baseiam seus produtos em Linux têm claro interesse nas capacidades, 71 + performance, e confiabilidade do kernel Linux. É também comum que usuários 72 + finais queiram alterar o Linux para atender melhor suas necessidades. 73 + 74 + Uma das características mais atrativas do Linux é sua facilidade de acesso a 75 + esses desenvolvedores; qualquer um com as habilidades necessárias pode melhorar 76 + o Linux e influenciar a direção do seu desenvolvimento. Produtos proprietários 77 + não conseguem oferecer esse tipo de abertura, que é característico do processo 78 + de software livre. O kernel é ainda mais acessível que a maioria dos outros 79 + projetos de software livre. Um ciclo típico de três meses de desenvolvimento 80 + do kernel pode envolver mais de 1000 desenvolvedores trabalhando para mais de 81 + 100 empresas (ou absolutamente nenhuma empresa). 82 + 83 + Trabalhar com a comunidade de desenvolvimento do kernel não é uma tarefa árdua. 84 + Contudo, muitos colaboradores potenciais passaram por dificuldades ao tentar 85 + trabalhar no kernel. A comunidade evoluiu suas próprias formas de funcionamento 86 + que permitem operar de forma fluida (e produzir um produto de alta qualidade) 87 + em um ambiente em que milhares de linhas de código são alteradas todos os dias. 88 + Não é surpresa que o processo de desenvolvimento do kernel Linux seja muito 89 + diferente dos modelos de desenvolvimento proprietários. 90 + 91 + O processo de desenvolvimento do kernel pode parecer estranho e intimidador 92 + para novos desenvolvedores, mas existem bons motivos e uma sólida experiência 93 + por trás disso. Um desenvolvedor que não entenda os caminhos próprios da 94 + comunidade kernel (ou pior, que tente menosprezá-los ou contorná-los) terá uma 95 + experiência frustrante pela frente. A comunidade de desenvolvimento ajuda 96 + aqueles que tentam aprender, mas gasta pouco tempo com aqueles que não escutam 97 + ou não ligam para o processo de desenvolvimento. 98 + 99 + Espera-se que aqueles que leiam este documento sejam capazes de evitar essa 100 + experiência frustrante. Há muito material aqui, mas o esforço envolvido na sua 101 + leitura valerá a pena. A comunidade de desenvolvimento sempre necessita de 102 + desenvolvedores que ajudem a melhorar o kernel; o texto a seguir deve ajudar 103 + você - ou aqueles trabalhando para você - a se juntar à nossa comunidade. 104 + 105 + Créditos 106 + -------- 107 + 108 + Esse documento foi escrito por Jonathan Corbet, corbet@lwn.net. Aprimorado 109 + pelos comentários de Johannes Berg, James Berry, Alex Chiang, Roland Dreier, 110 + Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda 111 + McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, e Jochen Voß. 112 + 113 + Esse trabalho contou com o apoio da Linux Foundation; agradecimentos especiais 114 + para Amanda McPherson, que viu o valor desse esforço e fez tudo acontecer. 115 + 116 + A importância de levar o código até o "mainline" 117 + ------------------------------------------------- 118 + 119 + Algumas empresas e desenvolvedores ocasionalmente se perguntam por que devem 120 + se importar em aprender como trabalhar com a comunidade do kernel e ter seu 121 + código no "mainline" (o kernel mantido por Linus Torvalds e usado como base 122 + para os distribuidores Linux). No curto prazo, contribuir com o código pode 123 + parecer um gasto evitável; parece mais fácil apenas manter o seu código à 124 + parte e oferecer suporte direto aos usuários. A verdade é que manter código 125 + fora da árvore principal ("out-of-tree") é uma falsa economia. 126 + 127 + Para ilustrar os custos do código "out-of-tree", aqui estão alguns aspectos 128 + relevantes do processo de desenvolvimento do kernel; a maioria será discutida 129 + com mais detalhes adiante neste documento. Considere: 130 + 131 + - Código integrado via merge ao "mainline" fica disponível para todos os 132 + usuários Linux. Estará automaticamente presente em todas as distribuições 133 + que o habilitarem. Não há necessidade de discos de armazenamento, downloads, 134 + ou as complicações de dar suporte a múltiplas versões de variadas 135 + distribuições; tudo simplesmente funciona, para o desenvolvedor e para o 136 + usuário. Incorporação ao "mainline" resolve um grande número de problemas 137 + de distribuição e suporte. 138 + 139 + - Enquanto desenvolvedores do kernel se esforçam para manter uma interface 140 + estável para o espaço do usuário, a API interna está em constante mudança. 141 + A ausência de uma interface interna estável é uma escolha deliberada de 142 + design; permite que sejam feitas melhorias fundamentais a qualquer tempo e 143 + resulta em código de qualidade superior. Uma consequência dessa política é 144 + que código "out-of-tree" precisa ser constantemente atualizado para que 145 + continue funcionando com novos kernels. Manter código "out-of-tree" requer 146 + significativo trabalho apenas para mantê-lo funcionando. 147 + 148 + Por sua vez, código que está no "mainline" não precisa dessa manutenção, 149 + resultado de uma regra simples que exige que qualquer desenvolvedor que 150 + altere uma API, também conserte qualquer código que deixe de funcionar como 151 + resultado da alteração. Código que teve o merge realizado no "mainline" tem 152 + custo significativamente menor de manutenção. 153 + 154 + - Além disso, código que está no kernel será muitas vezes melhorado por outros 155 + desenvolvedores. Resultados surpreendentes podem surgir ao permitir que sua 156 + comunidade de usuários e clientes melhore seu produto. 157 + 158 + - Código do kernel está sujeito a revisão, tanto antes como depois do merge ao 159 + "mainline". Independentemente das habilidades do desenvolvedor original, o 160 + processo de revisão invariavelmente encontra maneiras de evoluí-lo. Bugs 161 + severos e problemas de segurança são constantemente encontrados durante o 162 + processo de revisão. Isso é especialmente válido para código desenvolvido em 163 + ambiente isolado; tais códigos se beneficiam fortemente ao serem revistos por 164 + outros desenvolvedores. Código "out-of-tree" é código de baixa qualidade. 165 + 166 + - Participação no processo de desenvolvimento é a forma pela qual você pode 167 + influenciar a direção do desenvolvimento do kernel. Usuários que se queixam 168 + externamente são ouvidos, porém desenvolvedores ativos têm maior poder de 169 + articulação - e a habilidade de implementar mudanças que façam o kernel 170 + funcionar melhor para suas necessidades. 171 + 172 + - Quando o código é mantido à parte, sempre existe a possibilidade de que 173 + terceiros contribuam para uma implementação diferente de uma funcionalidade 174 + parecida. Se isso acontecer, ter seu código integrado via merge se tornará 175 + muito mais difícil - ao ponto de ser impossível. Você enfrentará duas 176 + alternativas desagradáveis, (1) manter uma funcionalidade "out-of-tree" 177 + indefinidamente ou (2) abandonar seu código e migrar seus usuários para a 178 + versão na árvore principal ("in-tree"). 179 + 180 + - Contribuição de código é a ação fundamental que faz todo o processo 181 + funcionar. Ao contribuir com seu código você pode adicionar nova 182 + funcionalidade ao kernel e proporcionar capacidades e exemplos que podem ser 183 + usados por outros desenvolvedores de kernel. Se você desenvolveu código para 184 + o Linux (ou está pensando em desenvolver), você claramente tem interesse na 185 + continuidade do sucesso dessa plataforma; contribuição de código é uma das 186 + melhores maneiras de garantir esse sucesso. 187 + 188 + Todos os argumentos acima se aplicam a qualquer código "out-of-tree", incluindo 189 + código distribuído de maneira proprietária, em formato exclusivamente binário. 190 + Existem fatores adicionais que devem ser levados em consideração antes de 191 + qualquer distribuição de código de kernel apenas em binário, incluindo: 192 + 193 + - As questões legais da distribuição de kernel proprietário são, no melhor dos 194 + casos, confusas; muitos detentores de direitos autorais do kernel acreditam 195 + que a maioria dos módulos binários são produtos derivados do kernel e que, 196 + como resultado, sua distribuição é uma violação da Licença Pública Geral GNU 197 + ("GNU General Public License"), que será tratada com mais profundidade abaixo. 198 + Este autor não é um advogado, e nada neste documento pode ser considerado 199 + aconselhamento jurídico. O verdadeiro status de módulos privados ("closed 200 + source") só pode ser determinado judicialmente. Independentemente disso, a 201 + incerteza que cerca esses módulos existe. 202 + 203 + - Os módulos binários aumentam consideravelmente a dificuldade de depuração de 204 + problemas do kernel ("debugging"), a ponto de a maioria dos desenvolvedores 205 + de kernel sequer tentar. Portanto, a distribuição de módulos exclusivamente 206 + binários tornará mais difícil que os seus usuários recebam suporte. 207 + 208 + - O suporte também é mais difícil para distribuidores de módulos exclusivamente 209 + binários, que precisam fornecer uma versão do módulo para cada distribuição e 210 + cada versão do kernel que desejam suportar. Dezenas de versões de um único 211 + módulo podem ser necessárias para fornecer uma cobertura razoavelmente 212 + abrangente, e seus usuários terão que atualizar seu módulo separadamente 213 + sempre que atualizarem seu kernel. 214 + 215 + - Tudo o que foi dito acima sobre revisão de código se aplica em dobro ao 216 + código fechado. Como esse código não está disponível, ele não pode ter sido 217 + revisado pela comunidade e, sem dúvida, terá sérios problemas. 218 + 219 + Os fabricantes de sistemas embarcados, em particular, podem ser tentados a 220 + ignorar grande parte do que foi dito nesta seção, acreditando que estão 221 + lançando um produto autossuficiente que usa uma versão congelada do kernel e 222 + não requer mais desenvolvimento após o lançamento. Esse argumento ignora o 223 + valor de uma revisão de código abrangente e o valor de permitir que seus 224 + usuários adicionem recursos ao seu produto. Mas esses produtos também têm uma 225 + vida comercial limitada, após a qual uma nova versão deve ser lançada. Nesse 226 + ponto, os fornecedores cujo código está no "mainline" e bem mantido estarão em 227 + uma posição muito melhor para preparar o novo produto para o mercado 228 + rapidamente. 229 + 230 + Licenciamento 231 + ------------- 232 + 233 + Código é submetido ao kernel do Linux sob diversas licenças, mas todo ele deve 234 + ser compatível com a versão 2 da Licença Pública Geral GNU (GPLv2), que é a 235 + licença que cobre a distribuição do kernel como um todo. Na prática, isso 236 + significa que todas as contribuições de código são cobertas pela GPLv2 (com, 237 + opcionalmente, uma linguagem que permita a distribuição sob versões posteriores 238 + da GPL) ou pela licença BSD de três cláusulas. Quaisquer contribuições que não 239 + sejam cobertas por uma licença compatível não serão aceitas no kernel. 240 + 241 + A cessão de direitos autorais não é exigida (nem solicitada) para o código 242 + contribuído para o kernel. Todo o código incorporado ao kernel principal mantém 243 + sua titularidade original; como resultado, o kernel agora tem milhares de 244 + proprietários. 245 + 246 + Uma implicação dessa estrutura de propriedade é que qualquer tentativa de 247 + alterar o licenciamento do kernel está fadada ao fracasso quase certo. Existem 248 + poucos cenários práticos em que o acordo de todos os detentores de direitos 249 + autorais poderia ser obtido (ou seu código removido do kernel). Portanto, em 250 + particular, não há perspectiva de migração para a versão 3 da GPL em um futuro 251 + próximo. 252 + 253 + É imprescindível que todo o código contribuído para o kernel seja legitimamente 254 + software livre. Por esse motivo, código de contribuidores sem identidade 255 + conhecida ou contribuidores anônimos não será aceito. Todos os contribuidores 256 + são obrigados a "assinar" seu código, declarando que ele pode ser distribuído 257 + com o kernel sob a GPL. Código que não tenha sido licenciado como software 258 + livre por seu proprietário, ou que apresente risco de criar problemas 259 + relacionados a direitos autorais para o kernel (como código derivado de 260 + esforços de engenharia reversa sem as devidas salvaguardas) não pode ser 261 + contribuído. 262 + 263 + Questões sobre direitos autorais são comuns em listas de discussão de 264 + desenvolvimento Linux. Normalmente, essas perguntas recebem muitas respostas, 265 + mas é importante lembrar que as pessoas que respondem a essas perguntas não são 266 + advogados e não podem fornecer aconselhamento jurídico. Se você tiver dúvidas 267 + jurídicas relacionadas ao código-fonte do Linux, não há substituto para 268 + conversar com um advogado especializado nessa área. Confiar em respostas 269 + obtidas em listas de discussão técnicas é arriscado.