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

Source file repositories/reference/linux-study-clean/Documentation/translations/pt_BR/process/2.Process.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/pt_BR/process/2.Process.rst
Extension
.rst
Size
28018 bytes
Lines
521
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. 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

Annotation

Implementation Notes