Como o projeto Linux Kernel rastreou bugs nos primeiros dias?

Todos sabemos que Linus Torvalds criou o Git por causa de problemas com o Bitkeeper. O que não se sabe (pelo menos para mim) é: como os problemas / tickets / bugs foram rastreados até então? Eu tentei, mas não consegui nada de interessante. A única discussão que pude abordar o assunto foi essa em que Linus compartilhou preocupações sobre o uso do Bugzilla .

Especulação: - A maneira mais fácil para as pessoas rastrearem bugs na fase inicial seria colocar tickets em um ramo próprio, mas tenho certeza de que, rapidamente, isso não teria aumentado com o barulho que superava os bons bugs.

Eu já vi e usei o Bugzilla e, a menos que você saiba as 'palavras-chave' certas, às vezes você ficaria perplexo. NOTA: Estou especificamente interessado nos primeiros anos (1991-1995) em como eles costumavam rastrear problemas.

Eu observei dois tópicos, " Kernel SCM saga ", e " Trivia: Quando o git se auto-hospedou? ", Mas nenhum deles mencionou o rastreamento de erros do kernel nos primeiros dias.

Eu procurei e não consegui encontrar nenhum software de rastreamento de erros da FOSS que existisse entre 1991-1992. Bugzilla, Request-tracker e outros vieram muito mais tarde, então eles parecem estar fora.

Questões-chave

1. Como então Linus, os mantenedores de subsistemas e os usuários relataram e rastrearam erros naqueles dias?
2. Eles usaram algum software de rastreamento de bugs, criaram um ramo de bugs e fizeram manualmente perguntas e discussões sobre o bug (seria caro e doloroso fazer isso) ou apenas usaram email.
3. Muito mais tarde, surgiu o Bugzilla (primeiro lançamento, 1998) e essa parece ser a principal maneira de relatar erros posteriormente .

Ansioso para ter uma imagem mais clara de como as coisas eram feitas nos dias anteriores.

No começo, se você tinha algo a contribuir (um patch ou um relatório de bug), você o enviava para Linus. Isso evoluiu para enviá-lo para a lista (que foi criada [email protected]antes kernel.org).

Não havia controle de versão. De tempos em tempos, Linus colocava um tarball no servidor FTP. Isso foi o equivalente a uma "tag". As ferramentas disponíveis no início eram RCS e CVS, e Linus odeia essas ferramentas, então todo mundo enviou correções. (Há uma explicação de Linus sobre o motivo de ele não querer usar o CVS.)

Havia outros sistemas de controle de versão proprietários anteriores ao Bitkeeper, mas o desenvolvimento descentralizado e voluntário do Linux tornou impossível usá-los. Uma pessoa aleatória que acabou de encontrar um bug nunca enviará um patch se precisar passar por um sistema de controle de versão proprietário com licenças a partir de milhares de dólares.

O Bitkeeper contornou esses dois problemas: não era centralizado como o CVS e, embora não fosse um Software Livre, os colaboradores do kernel podiam usá-lo sem pagar. Isso fez o suficiente por um tempo.

Mesmo com o desenvolvimento baseado em git de hoje, as listas de discussão ainda estão onde está a ação. Quando você quiser contribuir com algo, é claro que você o preparará com o git, mas precisará discuti-lo na lista de discussão relevante antes que ela seja mesclada. O Bugzilla existe para parecer "profissional" e absorver relatórios de erros incompletos de pessoas que realmente não querem se envolver.

Para ver algumas das instruções antigas de relatório de erros, obtenha o repositório histórico do Linux . (Este é um repositório git que contém todas as versões anteriores à existência do git; geralmente contém um commit por release desde que foi reconstruído a partir dos tarballs). Arquivos de interesse incluem README, MAINTAINERSe REPORTING-BUGS.

Uma das coisas interessantes que você pode encontrar é o arquivo README do Linux-0.99.12:

 - if you have problems that seem to be due to kernel bugs, please mail
   them to me ([email protected]), and possibly to any other
   relevant mailing-list or to the newsgroup.  The mailing-lists are
   useful especially for SCSI and NETworking problems, as I can't test
   either of those personally anyway.

Os processos usaram grupos de notícias (USENET) e (predominantemente) email. Um bug "existia" como um encadeamento, colocar " [BUG REPORT]" ou " LINUX BUG REPORT" no assunto era uma convenção comum. Não houve IDs de bug. Dada a base de usuários típica, um relatório de bug geralmente vinha com um patch. Havia uma ferramenta de software esquecida usada: ibug(veja abaixo), além da diff+ patch.

De instalação e introdução ao Linux (janeiro de 1994, cópia arquivada v2.0) >

2.6  The Design and Philosophy of Linux

 When new users encounter Linux, they often have a few misconceptions and
 false expectations of the system. Linux is a  unique  operating  system,
 and  it is important to understand its philosophy and design in order to
 use it effectively.  Time enough for a soapbox. Even if you are an  aged
 UNIX guru, what follows is probably of interest to you.

     In  commercial UNIX development houses, the entire system is devel-
 oped with a rigorous policy of quality assurance,  source  and  revision
 control systems, documentation, and bug reporting and resolution. [...]

     With  Linux,  you  can  throw  out  the entire concept of organized
 development, source control systems, structured bug reporting,  or  sta-
 tistical  analysis.   Linux  is,  and more than likely always will be, a
 hacker's operating system.(4)

                   [...]  For the most part, the Linux community communi-
 cates via various mailing lists and USENET newsgroups. A number of  con-
 ventions have sprung up around the development effort: for example, any-
 one wishing to have their  code  included  in  the  ``official''  kernel
 should  mail it to Linus Torvalds, which he will test and include in the
 kernel [...]

1992

Aqui está um relatório de bug e correção de dezembro de 1992 (0.98.6) no comp.os.linux: https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

Muito cedo, havia uma lista de e-mails ml-linux-bugs (1992/1993), desta FAQ inicial na distribuição do Slackware 1.01:

VI.01) Parece que $ # @! portados no linux não funcionam corretamente, o que faço para relatar bugs?

[...] Observe que minha lista de relatórios de erros "[email protected]" foi desativada. Acontece que o Linux tem tão poucos bugs, a maioria dos quais é resolvida no grupo de notícias ou através do Linus antes que eu possa acumulá-los e publicar. :) Em resumo: se houver um erro no Linux ou no software portado pelo Linux, ele será corrigido normalmente no próximo nível de patch ou versão.

Havia a lista de e-mail "linux-kernel" (que era executada no original vger), grupos de notícias alt.os.linux e comp.os.linux (que rapidamente se dividiram em uma hierarquia em 1993 ).

Este FAQ do Linux (v1.11 Nov 1992) do comp.os.linux também sugere enviar um email diretamente para o Linus.

Em 1992, Matt Welsh ( executando Linux , Linux Bible , TLDP ) anunciouibug a assistência na geração de relatórios de erros por e-mail (ironicamente, você não podia executá-lo no Linux naquele momento, pois faltava rede suficiente para enviar um e-mail).

Um modelo de relatório de erro delinux.temp email também era publicado periodicamente no comp.os.linux, e as atualizações em um relatório de erro tinham um modelo de atualizaçãolinux.fix.temp .

Havia também um repositório de patches (FTP) , até onde eu sei, isso era principalmente (não exclusivamente) para patches de programas para portar no Linux.

1993-1994

As cópias CVS da fonte do kernel eram comuns, a mais antiga que posso encontrar é a de Dirk Steinberg, da era kernal-0.99.14. O primeiro anúncio que encontro é de janeiro de 1993, sobre ativistas do Linux. Você ainda pode encontrar cópias arquivadas (1994) . Dirk também manteve os binários cvs e a fonte libc no CVS.

O CVS não foi usado para rastrear bugs no sentido contemporâneo, alguns desenvolvedores preferiram usá-lo, e os patches eram frequentemente enviados na forma de diferenças geradas por cvs.

1995-1996

Por volta dessa época (outubro de 1995), David S. Miller começou a usar o CVS para a porta SPARC do kernel Linux (a porta Linux / SPARC ). Em fevereiro de 1996, vários outros desenvolvedores do kernel estavam usando o CVS de forma independente para acompanhar os patches, a partir do linux-kernel deste e de outro segmento : Alan Cox, Stephen Tweedie, Kai Henningsen. (O segundo tópico relata Russ Nelson declarando a aversão de Linus em primeira mão ao CVS.)

1997-1998

Em abril de 1998, logo após o nascimento do segundo filho de Linus, a questão do CVS surgiu novamente. No linux-kernel, veja este subtítulo (Linus reitera suas preocupações sobre o CVS diretamente).

Em dezembro de 1997, Andrew Tridgell lançou o jitterbug , um rastreador de erros baseado na Web. Em junho de 1998, o "linux-patches" JitterBug estava sendo defendido no linux-kernel por Alan Cox . Até onde eu sei, foi o primeiro sistema de rastreamento de bugs usado pelo Linus e por outros desenvolvedores importantes, infelizmente a instância "linux-patches" não está mais online.

Em setembro de 1998, o bitkeeper é promovido pela primeira vez no linux-kernel por Larry McEvoy.

1999 e mais tarde

Em 1999/2000, as perguntas frequentes do lkml começaram a se referir (Q 1-16) à árvore do CVS no vger (original). Isso foi mantido na época por Andrew Tridgell.

Em dezembro de 2001, o Jitterbug havia caído em desuso, veja esse tópico do linux-kernel , Linus, Alan Cox e muitos outros envolvidos na discussão do porquê.

Em janeiro de 2002, Linus começou a se interessar pelo bitkeeper (já usado pela equipe do kernel do PowerPC Linux).

Em fevereiro de 2002, Linus começou a usar o Bitkeeper para a árvore de desenvolvimento 2.5.

Em novembro de 2002, o OSDL hospedou o Linux Bugzilla para a árvore 2.5 foi anunciado . (Se você ainda não leu o link do bugzilla na pergunta, leia-o agora, ele contém os antigos discursos do Linus).

Em abril de 2005, Linus anunciou uma mudança para o BitKeeper , na época em que ele mencionou gitpela primeira vez pelo nome . Logo após o git se tornar capaz de se hospedar , Linus parou de usar o BitKeeper e começou a usar o git para o kernel.

Em dezembro de 2008, foi anunciado o rastreador de patches Patchwork para linux-kernel ; este é um rastreador de patches baseado na Web, independente do SCCS, que se integra a listas de discussão para rastrear patches e acompanhamentos. Seu uso continua até hoje, existem aproximadamente 40 listas rastreadas dessa maneira em https://patchwork.kernel.org/ , embora nem todas estejam ativas.

Referências

Referências úteis:

• Essência do trabalho distribuído: O caso do kernel do Linux (Jae Yun Moon, Lee Sproull) http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (Nov 2000)
• Diretrizes para relatar erros do Linux (julho de 1992) http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• Arquivo de Kenneth R. Saborio de importantes publicações / emails do Linux: http://www.informatica.co.cr/linux/index.htm (1991-2005)
• arquivos linux-kernel de hoje (novembro de 2014) de volta a 1995 http://lkml.iu.edu/hypermail/linux/kernel/ (infelizmente, o primeiro email é de junho de 1995, onde o administrador Chris Dent anuncia que perdeu o anterior arquivos ...) O arquivo LKML remonta apenas a 1996
• Fragmentos do linux-devel 1993-1994 de tsx11 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux- devel / (desconsidere as datas na URL e nos arquivos)
• Ferramentas de gerenciamento de versão: CVS para BK no Linux Kernel , Sjaikh & Cornford (ca. 2003)
• Veja também este tópico do Hacker News (março de 2015) quando se aproxima o 10º aniversário do git: https://news.ycombinator.com/item?id=9263336

Eu posso dizer como o relatório de erros é tratado para o desenvolvimento de gitsi mesmo.

Eles não usam nenhum software de rastreamento de bugs. Os erros são relatados e discutidos na lista de discussão de desenvolvimento . É possivelmente surpreendente, mas funciona muito bem.

A pergunta ou proposta de usar algum software de rastreamento de bugs aparece com frequência, para que você possa aprender muito sobre isso pesquisando nos arquivos das listas de discussão do git.

Não se trata de "ainda não encontramos um rastreador de erros que seja bom o suficiente";
Mas também não se trata de "temos um método superior".

Com esse método, o mantenedor do projeto ou subprojeto - algo como um desenvolvedor líder - tem um papel importante como moderador informal da lista de desenvolvimento.
Lidar com bugs faz parte disso e não parece ser uma tarefa trivial gerenciar os bugs dessa maneira; Certamente depende das habilidades das pessoas nesse papel.

A parte mais formal do método é uma mensagem de resumo do status semanal.
Ele lista as coisas atualmente acontecendo nos vários ramos como itens curtos. Para um exemplo do desenvolvimento do git, veja isso no grupo de notícias que gmane.comp.version-control.gitespelha a lista de discussão: O que está cozinhando no git.git

O que posso dizer com certeza: se você tem um mantenedor que é bom nisso, ele funciona muito bem.
Por exemplo, ficaria muito surpreso se a introdução de um rastreador de erros tivesse um efeito positivo na produtividade dos recursos e na qualidade implementados, mesmo a longo prazo após a amortização da sobrecarga da mudança.

Para o kernel Linux, é semelhante a como é feito para o git, até hoje.
As listas de discussão de desenvolvimento para o desenvolvimento do kernel Linux são certamente importantes. Mas não é uma lista como um local central como no git. Existem listas separadas para subtópicos, como sistemas de arquivos ou redes.
Como existem tópicos separados, tratados principalmente por desenvolvedores separados, é possível que alguns grupos usem ferramentas localmente para o grupo.