Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
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
+1
Documentation/translations/pt_BR/index.rst
+269
Documentation/translations/pt_BR/process/1.Intro.rst
+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.