linux/Documentation/translations/pt_BR/process/2.Process.rst

.. SPDX-License-Identifier: GPL-2.0

Como funciona o processo de desenvolvimento
===========================================

O desenvolvimento do kernel Linux no início dos anos 1990 era uma
atividade bastante informal, envolvendo um número relativamente pequeno de
usuários e desenvolvedores. Com uma base de usuários atualmente na casa
dos milhões e com cerca de 2.000 desenvolvedores envolvidos ao longo de
um ano, o kernel desde então teve que evoluir uma série de processos
para manter o desenvolvimento acontecendo de forma fluida. Uma
compreensão sólida de como o processo funciona é necessária para ser uma
parte eficaz dele.

A Visão Geral
-------------

O kernel Linux usa um modelo de desenvolvimento de lançamento contínuo
(*rolling release*), vagamente baseado em tempo. Um novo lançamento de
versão principal do kernel (que chamaremos, como exemplo, de 9.x) [1]_
ocorre a cada dois ou três meses, trazendo novos recursos, alterações em
APIs internas e muito mais. Um lançamento típico pode conter cerca de
13.000 conjuntos de alterações (*changesets*) com modificações em várias
centenas de milhares de linhas de código. Lançamentos recentes,
juntamente com suas datas, podem ser encontrados na `Wikipedia
<https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_.

.. [1] Rigorosamente falando, o kernel Linux não utiliza o esquema de
       numeração de versionamento semântico, mas, em vez disso, o par
       9.x identifica a versão de lançamento principal como um número
       inteiro. Para cada lançamento, x é incrementado, mas o 9 é
       incrementado apenas se x for considerado grande o suficiente
       (por exemplo, o Linux 5.0 foi lançado após o Linux 4.20).

O processo de integração (*merging*) de patches segue um fluxo simples a
cada lançamento. No início de cada ciclo de desenvolvimento, abre-se a
**"janela de integração" (*merge window*)**. Durante esse período, todo
código considerado estável e aprovado pela comunidade é unificado ao
kernel principal (*mainline*). A maior parte das novidades  e todas as
grandes mudanças estruturais — entra obrigatoriamente nessa fase, em um
ritmo frenético que chega a **1.000 patches (ou conjuntos de alterações)
por dia**.

(Como observação secundária, vale destacar que as mudanças integradas durante
a janela de integração não surgem do nada; elas foram coletadas, testadas e
organizadas com antecedência. Como esse processo funciona será descrito em
detalhes mais adiante).

A janela de integração dura aproximadamente duas semanas. Ao final desse
período, Linus Torvalds declarará que a janela está fechada e lançará o
primeiro dos kernels "rc". Para o kernel que está destinado a ser o 9.x,
por exemplo, o lançamento que ocorre ao final da janela de integração será
chamado de 9.x-rc1. O lançamento -rc1 é o sinal de que o prazo para integrar
novos recursos terminou e que o período para estabilizar o próximo kernel
começou.

Ao longo das próximas seis a dez semanas, apenas patches que corrijam
problemas devem ser submetidos ao kernel principal. Ocasionalmente, uma
mudança mais significativa será permitida, mas esses casos são raros;
desenvolvedores que tentam integrar novos recursos fora da janela de
integração costumam receber uma recepção pouco amigável. Como regra geral,
se você perder a janela de integração para um determinado recurso, o melhor
a fazer é esperar pelo próximo ciclo de desenvolvimento. (Abre-se uma
exceção ocasional para drivers de hardware que antes não eram suportados;
se eles não modificarem nenhum código já existente na árvore, não podem
causar regressões e deve ser seguro adicioná-los a qualquer momento).

À medida que as correções são integradas ao kernel principal, o ritmo de
envio de patches diminui com o tempo. Linus lança novos kernels -rc cerca
de uma vez por semana; uma série normal chega a algo entre -rc6 e -rc9 antes
que o kernel seja considerado suficientemente estável e o lançamento final
seja realizado. Nesse ponto, todo o processo recomeça.

Como exemplo, veja como ocorreu o ciclo de desenvolvimento da versão 5.4
(todas as datas são de 2019):

	==============  ===============================
	Setembro 15	5.3 Lançamento estável do 5.3
	Setembro 30	5.4-rc1, fechamento da janela de integração
	Outubro 6	5.4-rc2
	Outubro 13	5.4-rc3
	Outubro 20	5.4-rc4
	October 27	5.4-rc5
	Novembro 3	5.4-rc6
	Novembro 10	5.4-rc7
	Novembro 17	5.4-rc8
	Novembro 24	5.4 Lançamento estável do 5.4
	==============  ===============================

Como os desenvolvedores decidem quando encerrar o ciclo de desenvolvimento
e criar o lançamento estável? A métrica mais significativa utilizada é a
lista de regressões de lançamentos anteriores. Nenhum bug é bem-vindo, mas
aqueles que quebram sistemas que funcionavam no passado são considerados
especialmente graves. Por esta razão, patches que causam regressões são
vistos de forma desfavorável e têm grande probabilidade de serem revertidos
durante o período de estabilização.

O objetivo dos desenvolvedores é corrigir todas as regressões conhecidas
antes que o lançamento estável seja feito. No mundo real, esse tipo de
perfeição é difícil de alcançar; há simplesmente variáveis demais em um
projeto deste tamanho. Chega um ponto em que adiar o lançamento final apenas
torna o problema pior; o volume de mudanças esperando pela próxima janela de
integração crescerá ainda mais, criando ainda mais regressões no ciclo
seguinte. Portanto, a maioria dos kernels é lançada com um pequeno número de
regressões conhecidas, embora, felizmente, nenhuma delas seja grave.

Assim que um lançamento estável é feito, sua manutenção contínua é passada
para a "equipe estável" (*stable team*), atualmente composta por Greg
Kroah-Hartman e Sasha Levin. A equipe estável lançará atualizações ocasionais
para a versão estável utilizando o esquema de numeração 9.x.y.

Para ser considerado para um lançamento de atualização, um patch deve (1)
corrigir um bug significativo e (2) já estar integrado ao kernel principal
(*mainline*) para o próximo kernel de desenvolvimento. Os kernels normalmente
receberão atualizações estáveis por um pouco mais de um ciclo de
desenvolvimento após o seu lançamento inicial. Assim, por exemplo, o histórico
do kernel 5.2 ocorreu da seguinte forma (todas as datas são de 2019):

  ==============  ===============================
  7 de Julho      Lançamento estável do 5.2
  14 de Julho     5.2.1
  21 de Julho     5.2.2
  26 de Julho     5.2.3
  28 de Julho     5.2.4
  31 de Julho     5.2.5
  ...             ...
  11 de Outubro   5.2.21
  ==============  ===============================

A versão 5.2.21 foi a última atualização estável do lançamento 5.2.

Alguns kernels são designados como kernels de "longo prazo" (*long term*);
eles receberão suporte por um período mais longo. Por favor, consulte o
seguinte link para obter a lista de versões ativas do kernel de longo prazo
e seus respectivos mantenedores:

	https://www.kernel.org/category/releases.html

A seleção de um kernel para suporte de longo prazo é puramente uma questão
de um mantenedor ter a necessidade e o tempo para manter esse lançamento.
Não há planos conhecidos para suporte de longo prazo para nenhum lançamento
futuro específico.


O Ciclo de Vida de um Patch
---------------------------

Os patches não vão diretamente do teclado do desenvolvedor para o kernel
principal. Em vez disso, existe um processo um tanto complexo (embora um
tanto informal) projetado para garantir que cada patch seja revisado quanto
à sua qualidade e que cada patch implemente uma mudança que seja desejável
ter no mainline. Esse processo pode acontecer rapidamente para correções
menores ou, no caso de mudanças grandes e controversas, arrastar-se por
anos. Grande parte da frustração dos desenvolvedores vem da falta de
compreensão desse processo ou de tentativas de burlá-lo.

Com a esperança de reduzir essa frustração, este documento descreverá como
um patch entra no kernel. O que se segue abaixo é uma introdução que
descreve o processo de uma forma um tanto idealizada. Um tratamento muito
mais detalhado virá nas seções posteriores.

As etapas pelas quais um patch passa são, geralmente:

 - Design. É aqui que os requisitos reais para o patch e a forma
   como esses requisitos serão atendidos são definidos. O trabalho de
   design geralmente é feito sem envolver a comunidade, mas é melhor realizar
   esse trabalho abertamente, se possível; isso pode economizar muito tempo
   evitando ter que refazer o projeto mais tarde.

 - Revisão inicial. Os patches são postados na lista de
   discussão relevante, e os desenvolvedores dessa lista respondem com os
   comentários que tiverem. Se tudo correr bem, esse processo deve apontar
   qualquer problema grave no patch.

 - Revisão ampla. Quando o patch estiver próximo de estar
   pronto para inclusão no mainline, ele deve ser aceito por um mantenedor de
   subsistema relevante — embora essa aceitação não seja uma garantia de que
   o patch chegará até o kernel principal. O patch aparecerá na árvore de
   subsistema do mantenedor e nas árvores -next. Quando o processo funciona,
   esta etapa leva a uma revisão mais ampla do patch e à descoberta de
   quaisquer problemas resultantes da integração deste patch com o trabalho
   que está sendo feito por outros.

 - Por favor, note que a maioria dos mantenedores também tem seus empregos
   regulares, portanto, integrar o seu patch pode não ser a maior prioridade
   deles. Se o seu patch estiver recebendo feedback sobre alterações que são
   necessárias, você deve fazer essas alterações ou justificar por que elas
   não devem ser feitas. Se o seu patch não tiver nenhuma objeção de revisão,
   mas não estiver sendo integrado pelo mantenedor do subsistema ou driver
   adequado, você deve ser persistente em atualizar o patch para o kernel
   atual (garantindo que ele seja aplicado de forma limpa) e continuar
   enviando-o para revisão e integração.

 - Integração no mainline. Eventualmente, um
   patch bem-sucedido será integrado ao repositório principal (*mainline*)
   gerenciado por Linus Torvalds. Mais comentários e/ou problemas podem surgir
   neste momento; é importante que o desenvolvedor seja responsivo a eles e
   corrija quaisquer problemas que venham a aparecer.

 - Lançamento estável. O número de usuários potencialmente
   afetados pelo patch agora é grande, portanto, mais uma vez, novos
   problemas podem surgir.

 - Manutenção de longo prazo. Embora seja perfeitamente
   possível para um desenvolvedor esquecer o código após integrá-lo, esse
   tipo de comportamento tende a deixar uma má impressão na comunidade de
   desenvolvimento. Integrar o código elimina parte do fardo de manutenção,
   já que outros corrigirão problemas causados por mudanças de API. No entanto,
   o desenvolvedor original deve continuar assumindo a responsabilidade pelo
   código se ele quiser que este permaneça útil no longo prazo.

Um dos maiores erros cometidos por desenvolvedores do kernel (ou por seus
empregadores) é tentar reduzir todo o processo a uma única etapa de
"integração no mainline". Essa abordagem invariavelmente leva à frustração
de todos os envolvidos.

Como os patches entram no Kernel
--------------------------------

Existe exatamente uma pessoa que pode integrar patches no repositório do
kernel principal: Linus Torvalds. Mas, por exemplo, dos mais de 9.500 patches
que entraram no kernel 2.6.38, apenas 112 (cerca de 1,3%) foram escolhidos
diretamente pelo próprio Linus. O projeto do kernel há muito tempo cresceu
para um tamanho onde nenhum desenvolvedor sozinho conseguiria inspecionar e
selecionar cada patch sem ajuda. A maneira como os desenvolvedores do kernel
lidaram com esse crescimento foi através do uso de um sistema de "tenentes"
(*lieutenant system*) construído em torno de uma cadeia de confiança.

A base de código do kernel é logicamente dividida em um conjunto de
subsistemas: rede, suporte a arquiteturas específicas,
gerenciamento de memória, dispositivos de vídeo, etc. A maioria dos
subsistemas possui um mantenedor designado, um desenvolvedor que tem a
responsabilidade geral pelo código dentro daquele subsistema. Esses
mantenedores de subsistemas são os guardiões (de forma flexível)
da parte do kernel que gerenciam; são eles que (geralmente) aceitarão um
patch para inclusão no kernel principal.

Cada um dos mantenedores de subsistemas gerencia sua própria versão da árvore
de fontes do kernel, geralmente (mas certamente nem sempre) usando a
ferramenta de gerenciamento de código-fonte Git. Ferramentas como o Git
(e ferramentas relacionadas como o quilt ou mercurial) permitem que os
mantenedores acompanhem uma lista de patches, incluindo informações de
autoria e outros metadados. A qualquer momento, o mantenedor pode identificar
quais patches em seu repositório não são encontrados no mainline.

Quando a janela de integração se abre, os mantenedores de
alto nível pedirão a Linus para realizar o pull de seus repositórios os patches
que selecionaram para integração. Se Linus concordar, o fluxo de patches
subirá para o seu repositório, tornando-se parte do kernel principal. A
quantidade de atenção que Linus dedica a patches específicos
recebidos em uma operação de pull varia. Está claro que, às vezes, ele os
examina bem de perto. Mas, como regra geral, Linus confia que os mantenedores
de subsistemas não enviarão patches ruins para o upstream.

Os mantenedores de subsistemas, por sua vez, podem realizar o pull dos patches
de outros mantenedores. Por exemplo, a árvore de rede é
construída a partir de patches que se acumularam primeiro em árvores dedicadas
a drivers de dispositivos de rede, rede sem fio, etc. Essa cadeia
de repositórios pode ser arbitrariamente longa, embora raramente exceda dois
ou três elos. Como cada mantenedor na cadeia confia naqueles que gerenciam as
árvores de nível inferior, esse processo é conhecido como a "cadeia de
confiança".

Claramente, em um sistema como este, colocar patches no kernel depende de
encontrar o mantenedor correto. Enviar patches diretamente para Linus
normalmente não é o caminho certo a seguir.


Árvore -next
-------------

A cadeia de árvores de subsistemas orienta o fluxo de patches para o kernel,
mas também levanta uma questão interessante: e se alguém quiser dar uma
olhada em todos os patches que estão sendo preparados para a próxima janela
de integração? Os desenvolvedores estarão interessados em saber quais outras
mudanças estão pendentes para ver se há conflitos com os quais se preocupar; um
patch que altera o protótipo de uma função central do kernel, por exemplo,
entrará em conflito com quaisquer outros patches que usem a forma mais antiga
dessa função. Revisores e testadores querem ter acesso às mudanças em sua forma
integrada antes que todas essas alterações cheguem ao kernel principal. Seria
possível realizar o pull das mudanças de todas as árvores de subsistemas
interessantes, mas isso seria um trabalho enorme e propenso a erros.

A resposta vem na forma das árvores -next, onde as árvores de subsistemas
são coletadas para testes e revisão. A mais antiga dessas árvores, mantida
por Andrew Morton, é chamada de "-mm" (de *memory management*, gerenciamento
de memória, que foi como ela começou). A árvore -mm integra patches de uma
longa lista de árvores de subsistemas; ela também possui alguns patches
destinados a ajudar na depuração (*debugging*).

Além disso, a árvore -mm contém uma coleção significativa de patches que
foram selecionados diretamente por Andrew. Esses patches podem ter sido
postados em uma lista de discussão ou podem se aplicar a uma parte do kernel
para a qual não existe uma árvore de subsistema designada. Como resultado, a
-mm opera como uma espécie de árvore de subsistema de "último recurso"; se
não houver outro caminho óbvio para um patch entrar no mainline, é provável
que ele acabe na -mm. Patches diversos que se acumulam na
-mm eventualmente serão encaminhados para uma árvore de subsistema adequada
ou enviados diretamente para Linus. Em um ciclo de desenvolvimento típico,
aproximadamente 5% a 10% do total de patches que entram no mainline chegam
lá por meio da -mm.

O patch -mm atual está disponível no diretório "mmotm" (*-mm of the moment*)
em:

	https://www.ozlabs.org/~akpm/mmotm/

O uso da árvore MMOTM, no entanto, provavelmente será uma experiência
frustrante; existe uma chance real de que ela sequer compile.

A árvore primária para a integração de patches do próximo ciclo é a
linux-next, mantida por Mark Brown. A árvore linux-next é, por design, um
snapshot do que se espera que o mainline se pareça após o
fechamento da próxima janela de integração. As árvores
linux-next são anunciadas nas listas de discussão linux-kernel e linux-next
quando são montadas; elas podem ser baixadas em:

	https://www.kernel.org/pub/linux/kernel/next/

A linux-next tornou-se uma parte integrante do processo de desenvolvimento
do kernel; todos os patches integrados durante uma determinada janela de
integração devem, idealmente, ter encontrado seu caminho para a linux-next algum
tempo antes da abertura da janela de integração.


Árvores de laboratório
----------------------

A árvore de fontes do kernel contém o diretório drivers/staging/, onde residem
muitos subdiretórios para drivers ou sistemas de arquivos que estão a caminho
de serem adicionados à árvore do kernel. Eles permanecem em drivers/staging/
enquanto ainda precisam de mais trabalho; uma vez concluídos, podem ser movidos
para o kernel proper Esta é uma maneira de acompanhar drivers que não estão à
altura dos padrões de codificação ou de qualidade do kernel Linux, mas que as
pessoas podem querer usar e acompanhar o desenvolvimento.

Greg Kroah-Hartman atualmente mantém a árvore de staging. Os drivers que
ainda precisam de trabalho são enviados a ele, com cada driver tendo seu
próprio subdiretório em drivers/staging/. Junto com os arquivos de código-fonte
do driver, um arquivo TODO também deve estar presente no diretório. O arquivo
TODO lista o trabalho pendente que o driver precisa para ser aceito no kernel
propriamente dito, bem como uma lista de pessoas que devem receber cópia
(*Cc'd*) em quaisquer patches para o driver. As regras atuais exigem que os
drivers contribuídos para o staging devem, no mínimo, compilar corretamente.

O staging pode ser uma maneira relativamente fácil de colocar novos drivers
no mainline onde, com sorte, eles chamarão a atenção de outros desenvolvedores
e melhorarão rapidamente. No entanto, a entrada no staging não é o fim da
história; o código no staging que não apresentar progresso regular será,
eventualmente, removido. Os distribuidores também tendem a ser relativamente
relutantes em habilitar drivers do staging. Portanto, o staging é, na melhor
das hipóteses, uma parada no caminho para se tornar um driver mainline adequado.


Ferramentas
-----------

Como pode ser visto no texto acima, o processo de desenvolvimento do kernel
depende fortemente da capacidade de guiar coleções de patches em várias
direções. Todo esse sistema não funcionaria nem de longe tão bem quanto
funciona sem ferramentas adequadamente poderosas. Tutoriais sobre como usar
essas ferramentas estão muito além do escopo deste documento, mas há espaço
para algumas indicações.

De longe, o sistema de gerenciamento de código-fonte dominante usado pela
comunidade do kernel é o Git. O Git é um entre vários sistemas de controle
de versão distribuídos desenvolvidos na comunidade de software livre. Ele é
bem sintonizado para o desenvolvimento do kernel, uma vez que apresenta um
excelente desempenho ao lidar com grandes repositórios e grandes volumes de
patches. Ele também tem a reputação de ser difícil de aprender e usar, embora
tenha melhorado ao longo do tempo. Algum tipo de familiaridade com o Git é
quase um requisito para os desenvolvedores do kernel; mesmo que não o usem
em seu próprio trabalho, eles precisarão do Git para acompanhar o que outros
desenvolvedores (e o mainline) estão fazendo.

O Git agora é empacotado por quase todas as distribuições Linux. Existe uma
página inicial em:

	https://git-scm.com/

Essa página possui indicações para documentações e tutoriais.

Entre os desenvolvedores do kernel que não usam o Git, a escolha mais popular
é, quase certamente, o Mercurial:

	https://www.selenic.com/mercurial/

O Mercurial compartilha muitos recursos com o Git, mas oferece uma interface
que muitos consideram mais fácil de usar.

A outra ferramenta que vale a pena conhecer é o Quilt:

	https://savannah.nongnu.org/projects/quilt/

O Quilt é um sistema de gerenciamento de patches, em vez de um sistema de
gerenciamento de código-fonte. Ele não rastreia o histórico ao longo do
tempo; em vez disso, ele é orientado a rastrear um conjunto específico de
alterações em relação a uma base de código em evolução. Alguns mantenedores
de grandes subsistemas usam o Quilt para gerenciar patches destinados a ir
para o upstream. Para o gerenciamento de certos tipos de árvores (-mm, por
exemplo), o Quilt é a melhor ferramenta para o trabalho.


Listas de discussão
-------------------

Uma grande parte do trabalho de desenvolvimento do kernel Linux é realizada por
meio de listas de discussão. É difícil ser um membro plenamente ativo da
comunidade sem se inscrever em pelo menos uma lista em algum lugar. No entanto,
as listas de discussão do Linux também representam um risco potencial para os
desenvolvedores, que correm o risco de serem soterrados por uma avalanche de
e-mails, de violar as convenções utilizadas nas listas do Linux, ou ambos.

A maioria das listas de discussão do kernel é hospedada no kernel.org; a
lista mestre pode ser encontrada em:

	https://subspace.kernel.org

Existem listas hospedadas em outros locais; por favor, verifique o arquivo
MAINTAINERS para encontrar a lista relevante para qualquer subsistema específico.

A lista de discussão central para o desenvolvimento do kernel é, naturalmente,
a linux-kernel. Esta lista é um lugar intimidador para se estar; o volume pode
atingir 500 mensagens por dia, a quantidade de ruído é alta, a conversa pode
ser severamente técnica e os participantes nem sempre estão preocupados em
demonstrar um alto grau de polidez. No entanto, não há outro lugar onde a
comunidade de desenvolvimento do kernel se reúna como um todo; desenvolvedores
que evitam esta lista perderão informações importantes.

Existem algumas dicas que podem ajudar na sobrevivência na lista linux-kernel:

- Faça com que a lista seja entregue em uma pasta separada, em vez de na sua
  caixa de entrada principal. É preciso ser capaz de ignorar o fluxo de e-mails
  por períodos prolongados de tempo.

- Não tente acompanhar cada conversa ninguém mais faz isso. É importante
  filtrar tanto pelo tópico de interesse (embora note que conversas longas
  podem se desviar do assunto original sem que a linha de assunto do e-mail
  seja alterada) quanto pelas pessoas que estão participando.

- Não alimente os trolls. Se alguém estiver tentando provocar uma resposta
  irada, ignore-o.

- Ao responder a um e-mail da lista linux-kernel (o mesmo valendo para outras
  listas), preserve o cabeçalho Cc: para todos os envolvidos. Na ausência de um
  motivo forte (como uma solicitação explícita), você nunca deve remover
  destinatários. Sempre certifique-se de que a pessoa a quem você está
  respondendo esteja na lista de Cc:. Essa convenção também torna desnecessário
  solicitar explicitamente ser copiado em respostas às suas postagens.

- Pesquise nos arquivos da lista (e na internet como um todo) antes de fazer
  perguntas. Alguns desenvolvedores podem ficar impacientes com pessoas que
  claramente não fizeram sua lição de casa.

- Use respostas intercaladas, o que torna sua resposta mais fácil
  de ler. (ou seja, evite o "top-posting" — a prática de colocar sua resposta
  acima do texto citado ao qual você está respondendo). Para mais detalhes, veja
  :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>`.

- Pergunte na lista de discussão correta. A lista linux-kernel pode até ser o
  ponto de encontro geral, mas não é o melhor lugar para encontrar desenvolvedores
  de todos os subsistemas.

O último ponto, encontrar a lista de discussão correta  é um lugar comum
onde os desenvolvedores iniciantes costumam errar. Alguém que faça uma pergunta
relacionada a redes na lista linux-kernel quase certamente receberá uma
sugestão educada para perguntar na lista netdev em seu lugar, já que essa é a
lista frequentada pela maioria dos desenvolvedores de redes. Existem outras
listas para os subsistemas SCSI, video4linux, IDE, filesystem (sistemas de
arquivos), etc. O melhor lugar para procurar por listas de discussão é no
arquivo MAINTAINERS empacotado junto com o código-fonte do kernel.


Começando com o desenvolvimento do kernel
-----------------------------------------

Perguntas sobre como começar com o processo de desenvolvimento do kernel são
comuns — tanto por parte de indivíduos quanto de empresas. Igualmente comuns
são os passos em falso que tornam o início do relacionamento mais difícil do
que precisa ser.

As empresas frequentemente buscam contratar desenvolvedores bem conhecidos para
dar o pontapé inicial em um grupo de desenvolvimento. Esta pode, de fato, ser
uma técnica eficaz. No entanto, ela também tende a ser cara e não faz muito para
expandir o grupo de desenvolvedores de kernel experientes. É possível capacitar
desenvolvedores internos no desenvolvimento do kernel Linux, desde que haja o
investimento de um pouco de tempo. Dedicar esse tempo pode dotar um empregador
de um grupo de desenvolvedores que entendem tanto o kernel quanto a própria
empresa, e que também podem ajudar a treinar outros. A médio prazo, esta é
frequentemente a abordagem mais lucrativa.

Desenvolvedores individuais frequentemente, e de forma compreensível, ficam sem
saber por onde começar. Iniciar com um grande projeto pode ser intimidante;
muitas vezes deseja-se testar o terreno com algo menor primeiro. Este é o ponto
onde alguns desenvolvedores saltam para a criação de patches que corrigem erros
de ortografia ou pequenos problemas de estilo de código. Infelizmente, tais
patches criam um nível de ruído que distrai a comunidade de desenvolvimento
como um todo, por isso, cada vez mais, eles são vistos com desdém. Novos
desenvolvedores que desejam se apresentar à comunidade não receberão o tipo de
recepção que desejam por esses meios.

Andrew Morton dá este conselho para aspirantes a desenvolvedores do kernel:

::

  "O projeto número um para todos os iniciantes no kernel certamente deveria
  ser 'certificar-se de que o kernel funcione perfeitamente o tempo todo em
  todas as máquinas em que você conseguir colocar as mãos'. Normalmente, a
  maneira de fazer isso é trabalhar com outros para resolver as coisas (isso
  pode exigir persistência!), mas tudo bem — isso é parte do desenvolvimento
  do kernel."

(https://lwn.net/Articles/283982/).

Na ausência de problemas óbvios para corrigir, os desenvolvedores são
aconselhados a olhar para as listas atuais de regressões e bugs abertos em
geral. Nunca há escassez de problemas que precisam de correção; ao abordar
esses problemas, os desenvolvedores ganharão experiência com o processo
enquanto, ao mesmo tempo, constroem respeito com o restante da comunidade de
desenvolvimento.