diff options
| -rw-r--r-- | Documentation/translations/pt_BR/process/3.Early-stage.rst | 233 | ||||
| -rw-r--r-- | Documentation/translations/pt_BR/process/development-process.rst | 1 |
2 files changed, 234 insertions, 0 deletions
diff --git a/Documentation/translations/pt_BR/process/3.Early-stage.rst b/Documentation/translations/pt_BR/process/3.Early-stage.rst new file mode 100644 index 000000000000..74e741766b46 --- /dev/null +++ b/Documentation/translations/pt_BR/process/3.Early-stage.rst @@ -0,0 +1,233 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Planejamento em estágio inicial +=============================== + +Ao contemplar um projeto de desenvolvimento do kernel Linux, pode ser tentador +dar um salto direto e começar a codificar. No entanto, como ocorre com qualquer +projeto significativo, grande parte da base para o sucesso é melhor estabelecida +antes que a primeira linha de código seja escrita. Um tempo gasto no planejamento +e na comunicação iniciais pode economizar muito mais tempo mais adiante. + + +Especificando o problema +------------------------ + +Como qualquer projeto de engenharia, um aprimoramento bem-sucedido do kernel +começa com uma descrição clara do problema a ser resolvido. Em alguns casos, +esta etapa é fácil: quando um driver é necessário para um componente de +hardware específico, por exemplo. Em outros, no entanto, é tentador confundir o +problema real com a solução proposta, e isso pode levar a dificuldades. + +Considere um exemplo: alguns anos atrás, desenvolvedores que trabalhavam com o +áudio do Linux buscavam uma maneira de executar aplicativos sem interrupções +(*dropouts*) ou outros artefatos causados por latência excessiva no sistema. A +solução a que chegaram foi um módulo do kernel destinado a se conectar à +estrutura do Linux Security Module (LSM); esse módulo poderia ser configurado +para dar a aplicativos específicos acesso ao escalonador de tempo real. Esse +módulo foi implementado e enviado para a lista de discussão linux-kernel, onde +imediatamente encontrou problemas. + +Para os desenvolvedores de áudio, esse módulo de segurança era suficiente para +resolver o problema imediato deles. Para a comunidade mais ampla do kernel, no +entanto, ele foi visto como um uso indevido da estrutura LSM (que não tem a +intenção de conceder privilégios a processos que eles de outra forma não +teriam) e um risco para a estabilidade do sistema. As soluções preferidas da +comunidade envolviam o acesso ao escalonamento de tempo real via mecanismo +rlimit a curto prazo, e o trabalho contínuo de redução de latência a longo prazo. + +A comunidade de áudio, no entanto, não conseguia enxergar além da solução +específica que havia implementado; eles não estavam dispostos a aceitar +alternativas. O desacordo resultante deixou esses desenvolvedores sentindo-se +desiludidos com todo o processo de desenvolvimento do kernel; um deles voltou +para uma lista de áudio e postou isto: + + "Existe um bom número de desenvolvedores muito bons no kernel Linux, mas eles + tendem a ser abafados por uma grande multidão de tolos arrogantes. Tentar + comunicar os requisitos dos usuários a essas pessoas é uma perda de tempo. + Eles são 'inteligentes' demais para ouvir os meros mortais." + +(https://lwn.net/Articles/131776/). + +A realidade da situação era diferente; os desenvolvedores do kernel estavam muito +mais preocupados com a estabilidade do sistema, com a manutenção a longo prazo e +em encontrar a solução correta para o problema do que com um módulo específico. +A moral da história é focar no problema — e não em uma solução específica — e +discuti-lo com a comunidade de desenvolvimento antes de investir na criação de +um conjunto de códigos. + +Portanto, ao contemplar um projeto de desenvolvimento do kernel, deve-se +obter respostas para um pequeno conjunto de perguntas: + + - Qual é, exatamente, o problema que precisa ser resolvido? + + - Quem são os usuários afetados por esse problema? Quais casos de uso a + solução deve abranger? + + - De que forma o kernel deixa a desejar em resolver esse problema atualmente? + +Só então faz sentido começar a considerar possíveis soluções. + + +Discussão inicial +----------------- + +Ao planejar um projeto de desenvolvimento do kernel, faz todo o sentido realizar +discussões com a comunidade antes de iniciar a implementação. A comunicação +inicial pode economizar tempo e problemas de várias maneiras:number of ways: + + - Pode muito bem ser que o problema já seja tratado pelo kernel de maneiras + que você não compreendeu. O kernel Linux é grande e possui uma série de + recursos e capacidades que não são imediatamente óbvios. Nem todas as + capacidades do kernel são documentadas tão bem quanto se gostaria, e é fácil + deixar passar algumas coisas. Este autor já viu a postagem de um driver + completo que duplicava um driver existente do qual o novo autor não tinha + conhecimento. Códigos que reinventam as rodas existentes não são apenas um + desperdício; eles também não serão aceitos no kernel principal (*mainline*). + + - Pode haver elementos na solução proposta que não serão aceitáveis para a + integração no kernel principal . É melhor descobrir problemas + como este antes de escrever o código. + + - É inteiramente possível que outros desenvolvedores já tenham pensado sobre + o problema; eles podem ter ideias para uma solução melhor e podem estar + dispostos a ajudar na criação dessa solução. + +Anos de experiência com a comunidade de desenvolvimento do kernel ensinaram uma +lição clara: códigos do kernel que são projetados e desenvolvidos a portas +fechadas invariavelmente apresentam problemas que só são revelados quando o +código é lançado na comunidade. Às vezes, esses problemas são graves, exigindo +meses ou anos de esforço antes que o código possa ser adequado aos padrões da +comunidade do kernel. Alguns exemplos incluem: + + - A pilha de rede Devicescape foi projetada e implementada para sistemas + monoprocessados. Ela não pôde ser integrada ao kernel principal (*mainline*) + até que fosse adaptada para sistemas multiprocessados. Ajustar retroativamente + mecanismos de travamento (*locking*) e afins em um código é uma tarefa difícil; + como resultado, a integração desse código (hoje chamado mac80211) foi atrasada + por mais de um ano. + + - O sistema de arquivos Reiser4 incluía uma série de capacidades que, na + opinião dos desenvolvedores principais do kernel, deveriam ter sido + implementadas na camada de sistema de arquivos virtual (*Virtual Filesystem* + ou VFS). Ele também incluía recursos que não podiam ser facilmente + implementados sem expor o sistema a travamentos mútuos (*deadlocks*) causados + pelo usuário. A revelação tardia desses problemas — e a recusa em corrigir + alguns deles — fez com que o Reiser4 permanecesse fora do kernel principal + (*mainline*). + + - O módulo de segurança AppArmor fazia uso de estruturas de dados internas + do sistema de arquivos virtual de maneiras que eram + consideradas inseguras e não confiáveis. Essa preocupação (entre outras) + manteve o AppArmor fora do kernel principal (*mainline*) por anos. + +In each of these cases, a great deal of pain and extra work could have been +avoided with some early discussion with the kernel developers. + + +Como encontrar os mantenedores? +------------------------------- + +Quando os desenvolvedores decidem tornar seus planos públicos, a próxima +pergunta será: por onde começamos? A resposta é encontrar a(s) lista(s) de +discussão correta(s) e o mantenedor adequado. Para listas de discussão, a +melhor abordagem é procurar no arquivo MAINTAINERS por um local relevante para +postar. Se houver uma lista de subsistema adequada, postar nela costuma ser +preferível a postar na linux-kernel; é mais provável que você alcance +desenvolvedores com experiência no subsistema relevante e o ambiente pode ser +mais acolhedor. + +Encontrar os mantenedores pode ser um pouco mais difícil. Novamente, o arquivo +MAINTAINERS é o lugar para começar. No entanto, esse arquivo tende a não estar +sempre atualizado, e nem todos os subsistemas estão representados ali. A +pessoa listada no arquivo MAINTAINERS pode, na verdade, não ser quem está +atuando nessa função atualmente. Portanto, quando houver dúvidas sobre quem +contactar, um truque útil é usar o git (e o "git log" em particular) para ver +quem está ativo no momento dentro do subsistema de interesse. Observe quem +está escrevendo os patches e quem, se houver alguém, está anexando linhas +"Signed-off-by" a esses patches. Essas são as pessoas que estarão em melhor +posição para ajudar com um novo projeto de desenvolvimento. + +A tarefa de encontrar o mantenedor correto às vezes é desafiadora o suficiente +para que os desenvolvedores do kernel tenham adicionado um script para facilitar +o processo: + +:: + + .../scripts/get_maintainer.pl + +Este script retornará o(s) mantenedor(es) atual(is) para um determinado arquivo +ou diretório quando fornecida a opção "-f". Se receber um patch na linha de +comando, ele listará os mantenedores que provavelmente devem receber cópias do +patch. Esta é a maneira preferencial (ao contrário da opção "-f") de obter a +lista de pessoas para incluir em cópia (Cc) nos seus patches. Há uma série de +opções que regulam o quão profundamente o get_maintainer.pl buscará por +mantenedores; por favor, tenha cuidado ao usar as opções mais agressivas, pois +você pode acabar incluindo desenvolvedores que não têm interesse real no código +que você está modificando. + +Se tudo mais falhar, falar com Andrew Morton pode ser uma maneira eficaz de +rastrear um mantenedor para um trecho específico de código. + + +Quando postar? +-------------- + +Se possível, postar seus planos durante os estágios iniciais só pode +ser útil. Descreva o problema que está sendo resolvido e quaisquer +planos que tenham sido feitos sobre como a implementação será feita. +Qualquer informação que você possa fornecer pode ajudar a comunidade de +desenvolvimento a dar contribuições úteis sobre o projeto. + +Uma coisa desanimadora que pode acontecer neste estágio não é uma +reação hostil, mas, em vez disso, pouca ou nenhuma reação. A triste +verdade sobre o assunto é que (1) os desenvolvedores do kernel tendem a +estar ocupados, (2) não há escassez de pessoas com planos grandiosos e +pouco código (ou mesmo perspectiva de código) para apoiá-los, e (3) +ninguém é obrigado a revisar ou comentar sobre ideias postadas por +outros. Além disso, designs de alto nível frequentemente escondem +problemas que só são revelados quando alguém realmente tenta +implementar esses designs; por essa razão, os desenvolvedores do kernel +preferem ver o código. + +Se uma postagem de pedido de comentários (RFC) render poucos +comentários, não presuma que isso significa que não há interesse no +projeto. Infelizmente, você também não pode presumir que não há +problemas com sua ideia. A melhor coisa a fazer nesta situação é +prosseguir, mantendo a comunidade informada à medida que avança. + + +Obter a aprovação oficial +------------------------- + +Se o seu trabalho estiver sendo realizado em um ambiente corporativo como é o +caso da maior parte do trabalho no kernel do Linux —, você deve, obviamente, ter +a permissão de gerentes devidamente autorizados antes de poder publicar os +planos ou o código da sua empresa em uma lista de discussão pública. +A publicação de código que não tenha sido liberado para lançamento sob uma +licença compatível com a GPL pode ser especialmente problemática; quanto mais +cedo a gerência e a equipe jurídica de uma empresa puderem entrar em acordo +sobre a publicação de um projeto de desenvolvimento do kernel, melhor será para +todos os envolvidos. + +Alguns leitores podem estar pensando, neste ponto, que o seu trabalho no kernel +se destina a dar suporte a um produto que ainda não tem uma existência oficialmente +reconhecida. Revelar os planos de seu empregador em uma lista de discussão pública +pode não ser uma opção viável. Em casos como esse, vale a pena considerar se o +segredo é realmente necessário; muitas vezes não há uma real necessidade de manter +os planos de desenvolvimento a portas fechadas. + +Dito isso, também existem casos em que uma empresa legitimamente não pode +revelar seus planos logo no início do processo de desenvolvimento. Empresas com +desenvolvedores de kernel experientes podem optar por prosseguir de maneira isolada +(em "malha aberta"), partindo do pressuposto de que serão capazes de evitar problemas +graves de integração mais tarde. Para empresas que não possuem esse tipo de expertise +interna, a melhor opção costuma ser a contratação de um desenvolvedor externo para +revisar os planos sob um acordo de confidencialidade (NDA). A Linux Foundation opera +um programa de NDA projetado para ajudar nesse tipo de situação; mais informações +podem ser encontradas em: + + https://www.linuxfoundation.org/nda/ + +Esse tipo de revisão costuma ser suficiente para evitar problemas graves mais +tarde, sem a necessidade de uma divulgação pública do projeto. diff --git a/Documentation/translations/pt_BR/process/development-process.rst b/Documentation/translations/pt_BR/process/development-process.rst index 737fdcdffd4a..599c34c859be 100644 --- a/Documentation/translations/pt_BR/process/development-process.rst +++ b/Documentation/translations/pt_BR/process/development-process.rst @@ -19,3 +19,4 @@ conhecimento profundo de programação de kernel para ser compreendida. 1.Intro 2.Process + 3.Early-stage |