1.. SPDX-License-Identifier: GPL-2.0 2 3Como funciona o processo de desenvolvimento 4=========================================== 5 6O desenvolvimento do kernel Linux no início dos anos 1990 era uma 7atividade bastante informal, envolvendo um número relativamente pequeno de 8usuários e desenvolvedores. Com uma base de usuários atualmente na casa 9dos milhões e com cerca de 2.000 desenvolvedores envolvidos ao longo de 10um ano, o kernel desde então teve que evoluir uma série de processos 11para manter o desenvolvimento acontecendo de forma fluida. Uma 12compreensão sólida de como o processo funciona é necessária para ser uma 13parte eficaz dele. 14 15A Visão Geral 16------------- 17 18O kernel Linux usa um modelo de desenvolvimento de lançamento contínuo 19(*rolling release*), vagamente baseado em tempo. Um novo lançamento de 20versão principal do kernel (que chamaremos, como exemplo, de 9.x) [1]_ 21ocorre a cada dois ou três meses, trazendo novos recursos, alterações em 22APIs internas e muito mais. Um lançamento típico pode conter cerca de 2313.000 conjuntos de alterações (*changesets*) com modificações em várias 24centenas de milhares de linhas de código. Lançamentos recentes, 25juntamente com suas datas, podem ser encontrados na `Wikipedia 26<https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_. 27 28.. [1] Rigorosamente falando, o kernel Linux não utiliza o esquema de 29 numeração de versionamento semântico, mas, em vez disso, o par 30 9.x identifica a versão de lançamento principal como um número 31 inteiro. Para cada lançamento, x é incrementado, mas o 9 é 32 incrementado apenas se x for considerado grande o suficiente 33 (por exemplo, o Linux 5.0 foi lançado após o Linux 4.20). 34 35O processo de integração (*merging*) de patches segue um fluxo simples a 36cada lançamento. No início de cada ciclo de desenvolvimento, abre-se a 37**"janela de integração" (*merge window*)**. Durante esse período, todo 38código considerado estável e aprovado pela comunidade é unificado ao 39kernel principal (*mainline*). A maior parte das novidades e todas as 40grandes mudanças estruturais — entra obrigatoriamente nessa fase, em um 41ritmo frenético que chega a **1.000 patches (ou conjuntos de alterações) 42por dia**. 43 44(Como observação secundária, vale destacar que as mudanças integradas durante 45a janela de integração não surgem do nada; elas foram coletadas, testadas e 46organizadas com antecedência. Como esse processo funciona será descrito em 47detalhes mais adiante). 48 49A janela de integração dura aproximadamente duas semanas. Ao final desse 50período, Linus Torvalds declarará que a janela está fechada e lançará o 51primeiro dos kernels "rc". Para o kernel que está destinado a ser o 9.x, 52por exemplo, o lançamento que ocorre ao final da janela de integração será 53chamado de 9.x-rc1. O lançamento -rc1 é o sinal de que o prazo para integrar 54novos recursos terminou e que o período para estabilizar o próximo kernel 55começou. 56 57Ao longo das próximas seis a dez semanas, apenas patches que corrijam 58problemas devem ser submetidos ao kernel principal. Ocasionalmente, uma 59mudança mais significativa será permitida, mas esses casos são raros; 60desenvolvedores que tentam integrar novos recursos fora da janela de 61integração costumam receber uma recepção pouco amigável. Como regra geral, 62se você perder a janela de integração para um determinado recurso, o melhor 63a fazer é esperar pelo próximo ciclo de desenvolvimento. (Abre-se uma 64exceção ocasional para drivers de hardware que antes não eram suportados; 65se eles não modificarem nenhum código já existente na árvore, não podem 66causar regressões e deve ser seguro adicioná-los a qualquer momento). 67 68À medida que as correções são integradas ao kernel principal, o ritmo de 69envio de patches diminui com o tempo. Linus lança novos kernels -rc cerca 70de uma vez por semana; uma série normal chega a algo entre -rc6 e -rc9 antes 71que o kernel seja considerado suficientemente estável e o lançamento final 72seja realizado. Nesse ponto, todo o processo recomeça. 73 74Como exemplo, veja como ocorreu o ciclo de desenvolvimento da versão 5.4 75(todas as datas são de 2019): 76 77 ============== =============================== 78 Setembro 15 5.3 Lançamento estável do 5.3 79 Setembro 30 5.4-rc1, fechamento da janela de integração 80 Outubro 6 5.4-rc2 81 Outubro 13 5.4-rc3 82 Outubro 20 5.4-rc4 83 October 27 5.4-rc5 84 Novembro 3 5.4-rc6 85 Novembro 10 5.4-rc7 86 Novembro 17 5.4-rc8 87 Novembro 24 5.4 Lançamento estável do 5.4 88 ============== =============================== 89 90Como os desenvolvedores decidem quando encerrar o ciclo de desenvolvimento 91e criar o lançamento estável? A métrica mais significativa utilizada é a 92lista de regressões de lançamentos anteriores. Nenhum bug é bem-vindo, mas 93aqueles que quebram sistemas que funcionavam no passado são considerados 94especialmente graves. Por esta razão, patches que causam regressões são 95vistos de forma desfavorável e têm grande probabilidade de serem revertidos 96durante o período de estabilização. 97 98O objetivo dos desenvolvedores é corrigir todas as regressões conhecidas 99antes que o lançamento estável seja feito. No mundo real, esse tipo de 100perfeição é difícil de alcançar; há simplesmente variáveis demais em um 101projeto deste tamanho. Chega um ponto em que adiar o lançamento final apenas 102torna o problema pior; o volume de mudanças esperando pela próxima janela de 103integração crescerá ainda mais, criando ainda mais regressões no ciclo 104seguinte. Portanto, a maioria dos kernels é lançada com um pequeno número de 105regressões conhecidas, embora, felizmente, nenhuma delas seja grave. 106 107Assim que um lançamento estável é feito, sua manutenção contínua é passada 108para a "equipe estável" (*stable team*), atualmente composta por Greg 109Kroah-Hartman e Sasha Levin. A equipe estável lançará atualizações ocasionais 110para a versão estável utilizando o esquema de numeração 9.x.y. 111 112Para ser considerado para um lançamento de atualização, um patch deve (1) 113corrigir um bug significativo e (2) já estar integrado ao kernel principal 114(*mainline*) para o próximo kernel de desenvolvimento. Os kernels normalmente 115receberão atualizações estáveis por um pouco mais de um ciclo de 116desenvolvimento após o seu lançamento inicial. Assim, por exemplo, o histórico 117do kernel 5.2 ocorreu da seguinte forma (todas as datas são de 2019): 118 119 ============== =============================== 120 7 de Julho Lançamento estável do 5.2 121 14 de Julho 5.2.1 122 21 de Julho 5.2.2 123 26 de Julho 5.2.3 124 28 de Julho 5.2.4 125 31 de Julho 5.2.5 126 ... ... 127 11 de Outubro 5.2.21 128 ============== =============================== 129 130A versão 5.2.21 foi a última atualização estável do lançamento 5.2. 131 132Alguns kernels são designados como kernels de "longo prazo" (*long term*); 133eles receberão suporte por um período mais longo. Por favor, consulte o 134seguinte link para obter a lista de versões ativas do kernel de longo prazo 135e seus respectivos mantenedores: 136 137 https://www.kernel.org/category/releases.html 138 139A seleção de um kernel para suporte de longo prazo é puramente uma questão 140de um mantenedor ter a necessidade e o tempo para manter esse lançamento. 141Não há planos conhecidos para suporte de longo prazo para nenhum lançamento 142futuro específico. 143 144 145O Ciclo de Vida de um Patch 146--------------------------- 147 148Os patches não vão diretamente do teclado do desenvolvedor para o kernel 149principal. Em vez disso, existe um processo um tanto complexo (embora um 150tanto informal) projetado para garantir que cada patch seja revisado quanto 151à sua qualidade e que cada patch implemente uma mudança que seja desejável 152ter no mainline. Esse processo pode acontecer rapidamente para correções 153menores ou, no caso de mudanças grandes e controversas, arrastar-se por 154anos. Grande parte da frustração dos desenvolvedores vem da falta de 155compreensão desse processo ou de tentativas de burlá-lo. 156 157Com a esperança de reduzir essa frustração, este documento descreverá como 158um patch entra no kernel. O que se segue abaixo é uma introdução que 159descreve o processo de uma forma um tanto idealizada. Um tratamento muito 160mais detalhado virá nas seções posteriores. 161 162As etapas pelas quais um patch passa são, geralmente: 163 164 - Design. É aqui que os requisitos reais para o patch e a forma 165 como esses requisitos serão atendidos são definidos. O trabalho de 166 design geralmente é feito sem envolver a comunidade, mas é melhor realizar 167 esse trabalho abertamente, se possível; isso pode economizar muito tempo 168 evitando ter que refazer o projeto mais tarde. 169 170 - Revisão inicial. Os patches são postados na lista de 171 discussão relevante, e os desenvolvedores dessa lista respondem com os 172 comentários que tiverem. Se tudo correr bem, esse processo deve apontar 173 qualquer problema grave no patch. 174 175 - Revisão ampla. Quando o patch estiver próximo de estar 176 pronto para inclusão no mainline, ele deve ser aceito por um mantenedor de 177 subsistema relevante — embora essa aceitação não seja uma garantia de que 178 o patch chegará até o kernel principal. O patch aparecerá na árvore de 179 subsistema do mantenedor e nas árvores -next. Quando o processo funciona, 180 esta etapa leva a uma revisão mais ampla do patch e à descoberta de 181 quaisquer problemas resultantes da integração deste patch com o trabalho 182 que está sendo feito por outros. 183 184 - Por favor, note que a maioria dos mantenedores também tem seus empregos 185 regulares, portanto, integrar o seu patch pode não ser a maior prioridade 186 deles. Se o seu patch estiver recebendo feedback sobre alterações que são 187 necessárias, você deve fazer essas alterações ou justificar por que elas 188 não devem ser feitas. Se o seu patch não tiver nenhuma objeção de revisão, 189 mas não estiver sendo integrado pelo mantenedor do subsistema ou driver 190 adequado, você deve ser persistente em atualizar o patch para o kernel 191 atual (garantindo que ele seja aplicado de forma limpa) e continuar 192 enviando-o para revisão e integração. 193 194 - Integração no mainline. Eventualmente, um 195 patch bem-sucedido será integrado ao repositório principal (*mainline*) 196 gerenciado por Linus Torvalds. Mais comentários e/ou problemas podem surgir 197 neste momento; é importante que o desenvolvedor seja responsivo a eles e 198 corrija quaisquer problemas que venham a aparecer. 199 200 - Lançamento estável. O número de usuários potencialmente 201 afetados pelo patch agora é grande, portanto, mais uma vez, novos 202 problemas podem surgir. 203 204 - Manutenção de longo prazo. Embora seja perfeitamente 205 possível para um desenvolvedor esquecer o código após integrá-lo, esse 206 tipo de comportamento tende a deixar uma má impressão na comunidade de 207 desenvolvimento. Integrar o código elimina parte do fardo de manutenção, 208 já que outros corrigirão problemas causados por mudanças de API. No entanto, 209 o desenvolvedor original deve continuar assumindo a responsabilidade pelo 210 código se ele quiser que este permaneça útil no longo prazo. 211 212Um dos maiores erros cometidos por desenvolvedores do kernel (ou por seus 213empregadores) é tentar reduzir todo o processo a uma única etapa de 214"integração no mainline". Essa abordagem invariavelmente leva à frustração 215de todos os envolvidos. 216 217Como os patches entram no Kernel 218-------------------------------- 219 220Existe exatamente uma pessoa que pode integrar patches no repositório do 221kernel principal: Linus Torvalds. Mas, por exemplo, dos mais de 9.500 patches 222que entraram no kernel 2.6.38, apenas 112 (cerca de 1,3%) foram escolhidos 223diretamente pelo próprio Linus. O projeto do kernel há muito tempo cresceu 224para um tamanho onde nenhum desenvolvedor sozinho conseguiria inspecionar e 225selecionar cada patch sem ajuda. A maneira como os desenvolvedores do kernel 226lidaram com esse crescimento foi através do uso de um sistema de "tenentes" 227(*lieutenant system*) construído em torno de uma cadeia de confiança. 228 229A base de código do kernel é logicamente dividida em um conjunto de 230subsistemas: rede, suporte a arquiteturas específicas, 231gerenciamento de memória, dispositivos de vídeo, etc. A maioria dos 232subsistemas possui um mantenedor designado, um desenvolvedor que tem a 233responsabilidade geral pelo código dentro daquele subsistema. Esses 234mantenedores de subsistemas são os guardiões (de forma flexível) 235da parte do kernel que gerenciam; são eles que (geralmente) aceitarão um 236patch para inclusão no kernel principal. 237 238Cada um dos mantenedores de subsistemas gerencia sua própria versão da árvore 239de fontes do kernel, geralmente (mas certamente nem sempre) usando a 240ferramenta de gerenciamento de código-fonte Git. Ferramentas como o Git 241(e ferramentas relacionadas como o quilt ou mercurial) permitem que os 242mantenedores acompanhem uma lista de patches, incluindo informações de 243autoria e outros metadados. A qualquer momento, o mantenedor pode identificar 244quais patches em seu repositório não são encontrados no mainline. 245 246Quando a janela de integração se abre, os mantenedores de 247alto nível pedirão a Linus para realizar o pull de seus repositórios os patches 248que selecionaram para integração. Se Linus concordar, o fluxo de patches 249subirá para o seu repositório, tornando-se parte do kernel principal. A 250quantidade de atenção que Linus dedica a patches específicos 251recebidos em uma operação de pull varia. Está claro que, às vezes, ele os 252examina bem de perto. Mas, como regra geral, Linus confia que os mantenedores 253de subsistemas não enviarão patches ruins para o upstream. 254 255Os mantenedores de subsistemas, por sua vez, podem realizar o pull dos patches 256de outros mantenedores. Por exemplo, a árvore de rede é 257construída a partir de patches que se acumularam primeiro em árvores dedicadas 258a drivers de dispositivos de rede, rede sem fio, etc. Essa cadeia 259de repositórios pode ser arbitrariamente longa, embora raramente exceda dois 260ou três elos. Como cada mantenedor na cadeia confia naqueles que gerenciam as 261árvores de nível inferior, esse processo é conhecido como a "cadeia de 262confiança". 263 264Claramente, em um sistema como este, colocar patches no kernel depende de 265encontrar o mantenedor correto. Enviar patches diretamente para Linus 266normalmente não é o caminho certo a seguir. 267 268 269Árvore -next 270------------- 271 272A cadeia de árvores de subsistemas orienta o fluxo de patches para o kernel, 273mas também levanta uma questão interessante: e se alguém quiser dar uma 274olhada em todos os patches que estão sendo preparados para a próxima janela 275de integração? Os desenvolvedores estarão interessados em saber quais outras 276mudanças estão pendentes para ver se há conflitos com os quais se preocupar; um 277patch que altera o protótipo de uma função central do kernel, por exemplo, 278entrará em conflito com quaisquer outros patches que usem a forma mais antiga 279dessa função. Revisores e testadores querem ter acesso às mudanças em sua forma 280integrada antes que todas essas alterações cheguem ao kernel principal. Seria 281possível realizar o pull das mudanças de todas as árvores de subsistemas 282interessantes, mas isso seria um trabalho enorme e propenso a erros. 283 284A resposta vem na forma das árvores -next, onde as árvores de subsistemas 285são coletadas para testes e revisão. A mais antiga dessas árvores, mantida 286por Andrew Morton, é chamada de "-mm" (de *memory management*, gerenciamento 287de memória, que foi como ela começou). A árvore -mm integra patches de uma 288longa lista de árvores de subsistemas; ela também possui alguns patches 289destinados a ajudar na depuração (*debugging*). 290 291Além disso, a árvore -mm contém uma coleção significativa de patches que 292foram selecionados diretamente por Andrew. Esses patches podem ter sido 293postados em uma lista de discussão ou podem se aplicar a uma parte do kernel 294para a qual não existe uma árvore de subsistema designada. Como resultado, a 295-mm opera como uma espécie de árvore de subsistema de "último recurso"; se 296não houver outro caminho óbvio para um patch entrar no mainline, é provável 297que ele acabe na -mm. Patches diversos que se acumulam na 298-mm eventualmente serão encaminhados para uma árvore de subsistema adequada 299ou enviados diretamente para Linus. Em um ciclo de desenvolvimento típico, 300aproximadamente 5% a 10% do total de patches que entram no mainline chegam 301lá por meio da -mm. 302 303O patch -mm atual está disponível no diretório "mmotm" (*-mm of the moment*) 304em: 305 306 https://www.ozlabs.org/~akpm/mmotm/ 307 308O uso da árvore MMOTM, no entanto, provavelmente será uma experiência 309frustrante; existe uma chance real de que ela sequer compile. 310 311A árvore primária para a integração de patches do próximo ciclo é a 312linux-next, mantida por Mark Brown. A árvore linux-next é, por design, um 313snapshot do que se espera que o mainline se pareça após o 314fechamento da próxima janela de integração. As árvores 315linux-next são anunciadas nas listas de discussão linux-kernel e linux-next 316quando são montadas; elas podem ser baixadas em: 317 318 https://www.kernel.org/pub/linux/kernel/next/ 319 320A linux-next tornou-se uma parte integrante do processo de desenvolvimento 321do kernel; todos os patches integrados durante uma determinada janela de 322integração devem, idealmente, ter encontrado seu caminho para a linux-next algum 323tempo antes da abertura da janela de integração. 324 325 326Árvores de laboratório 327---------------------- 328 329A árvore de fontes do kernel contém o diretório drivers/staging/, onde residem 330muitos subdiretórios para drivers ou sistemas de arquivos que estão a caminho 331de serem adicionados à árvore do kernel. Eles permanecem em drivers/staging/ 332enquanto ainda precisam de mais trabalho; uma vez concluídos, podem ser movidos 333para o kernel proper Esta é uma maneira de acompanhar drivers que não estão à 334altura dos padrões de codificação ou de qualidade do kernel Linux, mas que as 335pessoas podem querer usar e acompanhar o desenvolvimento. 336 337Greg Kroah-Hartman atualmente mantém a árvore de staging. Os drivers que 338ainda precisam de trabalho são enviados a ele, com cada driver tendo seu 339próprio subdiretório em drivers/staging/. Junto com os arquivos de código-fonte 340do driver, um arquivo TODO também deve estar presente no diretório. O arquivo 341TODO lista o trabalho pendente que o driver precisa para ser aceito no kernel 342propriamente dito, bem como uma lista de pessoas que devem receber cópia 343(*Cc'd*) em quaisquer patches para o driver. As regras atuais exigem que os 344drivers contribuídos para o staging devem, no mínimo, compilar corretamente. 345 346O staging pode ser uma maneira relativamente fácil de colocar novos drivers 347no mainline onde, com sorte, eles chamarão a atenção de outros desenvolvedores 348e melhorarão rapidamente. No entanto, a entrada no staging não é o fim da 349história; o código no staging que não apresentar progresso regular será, 350eventualmente, removido. Os distribuidores também tendem a ser relativamente 351relutantes em habilitar drivers do staging. Portanto, o staging é, na melhor 352das hipóteses, uma parada no caminho para se tornar um driver mainline adequado. 353 354 355Ferramentas 356----------- 357 358Como pode ser visto no texto acima, o processo de desenvolvimento do kernel 359depende fortemente da capacidade de guiar coleções de patches em várias 360direções. Todo esse sistema não funcionaria nem de longe tão bem quanto 361funciona sem ferramentas adequadamente poderosas. Tutoriais sobre como usar 362essas ferramentas estão muito além do escopo deste documento, mas há espaço 363para algumas indicações. 364 365De longe, o sistema de gerenciamento de código-fonte dominante usado pela 366comunidade do kernel é o Git. O Git é um entre vários sistemas de controle 367de versão distribuídos desenvolvidos na comunidade de software livre. Ele é 368bem sintonizado para o desenvolvimento do kernel, uma vez que apresenta um 369excelente desempenho ao lidar com grandes repositórios e grandes volumes de 370patches. Ele também tem a reputação de ser difícil de aprender e usar, embora 371tenha melhorado ao longo do tempo. Algum tipo de familiaridade com o Git é 372quase um requisito para os desenvolvedores do kernel; mesmo que não o usem 373em seu próprio trabalho, eles precisarão do Git para acompanhar o que outros 374desenvolvedores (e o mainline) estão fazendo. 375 376O Git agora é empacotado por quase todas as distribuições Linux. Existe uma 377página inicial em: 378 379 https://git-scm.com/ 380 381Essa página possui indicações para documentações e tutoriais. 382 383Entre os desenvolvedores do kernel que não usam o Git, a escolha mais popular 384é, quase certamente, o Mercurial: 385 386 https://www.selenic.com/mercurial/ 387 388O Mercurial compartilha muitos recursos com o Git, mas oferece uma interface 389que muitos consideram mais fácil de usar. 390 391A outra ferramenta que vale a pena conhecer é o Quilt: 392 393 https://savannah.nongnu.org/projects/quilt/ 394 395O Quilt é um sistema de gerenciamento de patches, em vez de um sistema de 396gerenciamento de código-fonte. Ele não rastreia o histórico ao longo do 397tempo; em vez disso, ele é orientado a rastrear um conjunto específico de 398alterações em relação a uma base de código em evolução. Alguns mantenedores 399de grandes subsistemas usam o Quilt para gerenciar patches destinados a ir 400para o upstream. Para o gerenciamento de certos tipos de árvores (-mm, por 401exemplo), o Quilt é a melhor ferramenta para o trabalho. 402 403 404Listas de discussão 405------------------- 406 407Uma grande parte do trabalho de desenvolvimento do kernel Linux é realizada por 408meio de listas de discussão. É difícil ser um membro plenamente ativo da 409comunidade sem se inscrever em pelo menos uma lista em algum lugar. No entanto, 410as listas de discussão do Linux também representam um risco potencial para os 411desenvolvedores, que correm o risco de serem soterrados por uma avalanche de 412e-mails, de violar as convenções utilizadas nas listas do Linux, ou ambos. 413 414A maioria das listas de discussão do kernel é hospedada no kernel.org; a 415lista mestre pode ser encontrada em: 416 417 https://subspace.kernel.org 418 419Existem listas hospedadas em outros locais; por favor, verifique o arquivo 420MAINTAINERS para encontrar a lista relevante para qualquer subsistema específico. 421 422A lista de discussão central para o desenvolvimento do kernel é, naturalmente, 423a linux-kernel. Esta lista é um lugar intimidador para se estar; o volume pode 424atingir 500 mensagens por dia, a quantidade de ruído é alta, a conversa pode 425ser severamente técnica e os participantes nem sempre estão preocupados em 426demonstrar um alto grau de polidez. No entanto, não há outro lugar onde a 427comunidade de desenvolvimento do kernel se reúna como um todo; desenvolvedores 428que evitam esta lista perderão informações importantes. 429 430Existem algumas dicas que podem ajudar na sobrevivência na lista linux-kernel: 431 432- Faça com que a lista seja entregue em uma pasta separada, em vez de na sua 433 caixa de entrada principal. É preciso ser capaz de ignorar o fluxo de e-mails 434 por períodos prolongados de tempo. 435 436- Não tente acompanhar cada conversa ninguém mais faz isso. É importante 437 filtrar tanto pelo tópico de interesse (embora note que conversas longas 438 podem se desviar do assunto original sem que a linha de assunto do e-mail 439 seja alterada) quanto pelas pessoas que estão participando. 440 441- Não alimente os trolls. Se alguém estiver tentando provocar uma resposta 442 irada, ignore-o. 443 444- Ao responder a um e-mail da lista linux-kernel (o mesmo valendo para outras 445 listas), preserve o cabeçalho Cc: para todos os envolvidos. Na ausência de um 446 motivo forte (como uma solicitação explícita), você nunca deve remover 447 destinatários. Sempre certifique-se de que a pessoa a quem você está 448 respondendo esteja na lista de Cc:. Essa convenção também torna desnecessário 449 solicitar explicitamente ser copiado em respostas às suas postagens. 450 451- Pesquise nos arquivos da lista (e na internet como um todo) antes de fazer 452 perguntas. Alguns desenvolvedores podem ficar impacientes com pessoas que 453 claramente não fizeram sua lição de casa. 454 455- Use respostas intercaladas, o que torna sua resposta mais fácil 456 de ler. (ou seja, evite o "top-posting" — a prática de colocar sua resposta 457 acima do texto citado ao qual você está respondendo). Para mais detalhes, veja 458 :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>`. 459 460- Pergunte na lista de discussão correta. A lista linux-kernel pode até ser o 461 ponto de encontro geral, mas não é o melhor lugar para encontrar desenvolvedores 462 de todos os subsistemas. 463 464O último ponto, encontrar a lista de discussão correta é um lugar comum 465onde os desenvolvedores iniciantes costumam errar. Alguém que faça uma pergunta 466relacionada a redes na lista linux-kernel quase certamente receberá uma 467sugestão educada para perguntar na lista netdev em seu lugar, já que essa é a 468lista frequentada pela maioria dos desenvolvedores de redes. Existem outras 469listas para os subsistemas SCSI, video4linux, IDE, filesystem (sistemas de 470arquivos), etc. O melhor lugar para procurar por listas de discussão é no 471arquivo MAINTAINERS empacotado junto com o código-fonte do kernel. 472 473 474Começando com o desenvolvimento do kernel 475----------------------------------------- 476 477Perguntas sobre como começar com o processo de desenvolvimento do kernel são 478comuns — tanto por parte de indivíduos quanto de empresas. Igualmente comuns 479são os passos em falso que tornam o início do relacionamento mais difícil do 480que precisa ser. 481 482As empresas frequentemente buscam contratar desenvolvedores bem conhecidos para 483dar o pontapé inicial em um grupo de desenvolvimento. Esta pode, de fato, ser 484uma técnica eficaz. No entanto, ela também tende a ser cara e não faz muito para 485expandir o grupo de desenvolvedores de kernel experientes. É possível capacitar 486desenvolvedores internos no desenvolvimento do kernel Linux, desde que haja o 487investimento de um pouco de tempo. Dedicar esse tempo pode dotar um empregador 488de um grupo de desenvolvedores que entendem tanto o kernel quanto a própria 489empresa, e que também podem ajudar a treinar outros. A médio prazo, esta é 490frequentemente a abordagem mais lucrativa. 491 492Desenvolvedores individuais frequentemente, e de forma compreensível, ficam sem 493saber por onde começar. Iniciar com um grande projeto pode ser intimidante; 494muitas vezes deseja-se testar o terreno com algo menor primeiro. Este é o ponto 495onde alguns desenvolvedores saltam para a criação de patches que corrigem erros 496de ortografia ou pequenos problemas de estilo de código. Infelizmente, tais 497patches criam um nível de ruído que distrai a comunidade de desenvolvimento 498como um todo, por isso, cada vez mais, eles são vistos com desdém. Novos 499desenvolvedores que desejam se apresentar à comunidade não receberão o tipo de 500recepção que desejam por esses meios. 501 502Andrew Morton dá este conselho para aspirantes a desenvolvedores do kernel: 503 504:: 505 506 "O projeto número um para todos os iniciantes no kernel certamente deveria 507 ser 'certificar-se de que o kernel funcione perfeitamente o tempo todo em 508 todas as máquinas em que você conseguir colocar as mãos'. Normalmente, a 509 maneira de fazer isso é trabalhar com outros para resolver as coisas (isso 510 pode exigir persistência!), mas tudo bem — isso é parte do desenvolvimento 511 do kernel." 512 513(https://lwn.net/Articles/283982/). 514 515Na ausência de problemas óbvios para corrigir, os desenvolvedores são 516aconselhados a olhar para as listas atuais de regressões e bugs abertos em 517geral. Nunca há escassez de problemas que precisam de correção; ao abordar 518esses problemas, os desenvolvedores ganharão experiência com o processo 519enquanto, ao mesmo tempo, constroem respeito com o restante da comunidade de 520desenvolvimento. 521