초기 Linux Kernel 프로젝트는 버그를 어떻게 추적 했습니까?

우리는 Linus Torvalds가 Bitkeeper 관련 문제로 인해 Git을 생성했음을 알고 있습니다. (최소한 나에게) 알려지지 않은 것은 그때까지 이슈 / 티켓 / 버그가 어떻게 추적 되었는가? 나는 시도했지만 재미있는 것을 얻지 못했습니다. 내가이 주제에 관해 논의 할 수 있었던 유일한 논의는 Linus가 Bugzilla 사용에 대해 우려하는 부분이었습니다 .

추측 : -사람들이 초기 단계에서 버그를 추적하는 가장 쉬운 방법은 티켓을 자체 지점에 배치하는 것이었지만 좋은 버그를 과도하게 잡는 소음으로 확장되지 않았을 것이라고 확신합니다.

나는 Bugzilla를 보았고 사용했습니다. 때로는 올바른 '키워드'를 알지 못한다면 때때로 엉망이 될 것입니다. 참고 : 특히 문제 를 추적 하는 데 사용 된 초기 방법 (1991-1995)에 관심이 있습니다.

나는 " Kernel SCM saga "와 " Trivia : 언제 git self-host를 했습니까? "라는 두 개의 스레드를 보았지만 초기에는 커널의 버그 추적에 대해 언급하지 않았습니다.

나는 주변을 검색했으며 1991-1992 년에 있었던 FOSS 버그 추적 소프트웨어를 얻을 수 없었습니다. Bugzilla, Request-tracker 및 기타는 훨씬 늦게 나타났습니다.

주요 질문

1. 그러면 하위 시스템 유지 관리 업체 인 Linus와 그 당시의 버그는 어떻게보고하고 추적 했습니까?
2. 그들은 버그 추적 소프트웨어를 사용하고, 버그를 만들었고, 버그에 대해 수동으로 커밋 된 질문과 토론 (비싸고 고통 스러울 것임)이나 전자 메일을 사용 했습니까?
3. 훨씬 나중에 Bugzilla가 등장했으며 (1998 년 첫 번째 릴리스) 나중에 버그를보고 하는 주요 방법 인 것 같습니다 .

과거의 일들이 어떻게 이루어 졌는지 더 명확하게 파악하기를 기대합니다.

처음에, 공헌 할 것이 있다면 (패치 또는 버그 보고서), Linus에 우송했습니다. 이것은 linux-kernel@vger.rutgers.edu이전 kernel.org에 작성된 목록으로 메일을 보내도록 발전했습니다 .

버전 관리가 없었습니다. Linus는 때때로 FTP 서버에 tarball을 넣습니다. 이것은 "태그"와 동일합니다. 처음에 사용 가능한 도구는 RCS와 CVS였으며 Linus는이 도구를 싫어하므로 모두가 패치를 메일로 보냈습니다. Linus의 CVS 사용을 원하지 않는 이유에 대한 설명 이 있습니다 .

비트 키퍼 전의 독점적 인 버전 관리 시스템이 있었지만, 분산 된 자원 봉사자 기반의 Linux 개발로 인해이를 사용할 수 없었습니다. 버그를 발견 한 임의의 사람은 수천 달러로 시작되는 라이센스를 가진 독점 버전 관리 시스템을 거쳐야하는 경우 패치를 보내지 않습니다.

Bitkeeper는 두 가지 문제를 모두 해결했습니다. CVS처럼 중앙 집중화되지 않았으며 자유 소프트웨어는 아니지만 커널 기고자들은 지불하지 않고 사용할 수있었습니다. 그것은 한동안 충분히 좋았습니다.

오늘날의 git 기반 개발에서도 메일 링리스트는 여전히 작업 위치에 있습니다. 당신이 무언가를 기고하고 싶을 때, 물론 git으로 준비 할 것이지만, 병합되기 전에 관련 메일 링리스트에서 논의해야합니다. Bugzilla는 "전문적인"모습을 보여 주고 실제로 참여하고 싶지 않은 사람들로부터 반쯤 구운 버그 보고서를 작성합니다 .

이전 버그보고 지침 중 일부를 보려면 히스토리 Linux 저장소를 가져 오십시오 . (이것은 git가 존재하기 전의 모든 버전을 포함하는 git 저장소입니다. 타르볼에서 재구성 된 이후 릴리스 당 하나의 커밋이 포함되어 있습니다). 관심의 파일을 포함 README, MAINTAINERS하고 REPORTING-BUGS.

흥미로운 사실 ​​중 하나는 Linux-0.99.12 README에 있습니다.

 - if you have problems that seem to be due to kernel bugs, please mail
   them to me (Linus.Torvalds@Helsinki.FI), 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.

프로세스는 뉴스 그룹 (USENET) 및 (주로) 이메일을 사용했습니다. 주제 에 " [BUG REPORT]"또는 " LINUX BUG REPORT"를 넣는 버그는 스레드로 "존재"했습니다 . 버그 ID가 없습니다. 일반적인 사용자 기반을 고려할 때 종종 버그 보고서에 패치가 제공됩니다. : 사용되는 하나의 긴 잊혀진 소프트웨어 도구가 있었다 ibug(아래 참조), 그 이외의 diff+는 patch.

에서 리눅스 설치 및 시작하기 (1994년 1월, 2.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

다음은 comp.os.linux의 1992 년 12 월 (0.98.6)의 버그 보고서 및 수정 사항입니다. https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

Slackware 1.01 배포판 의 초기 FAQ 에서 ml-linux-bugs (1992/1993) 라는 이메일 목록이있었습니다 .

VI.01) $ # @ 인 것 같습니다! 리눅스로 포팅이 제대로 실행되지 않습니다. 버그보고는 어떻게합니까?

[...] 내 "ml-linux-bugs@dg-rtp.dg.com"버그보고 목록이 단계적으로 제거되었습니다. 리눅스에는 버그가 거의 없다는 것이 밝혀졌습니다. 그 중 대부분은 뉴스 그룹이나 Linus를 통해 해결되어 쌓여서 게시 할 수 있습니다. :) 간단히 말해서 : Linux 또는 Linux 포트 소프트웨어에 버그가있는 경우 일반적으로 다음 패치 레벨 또는 버전에서 수정됩니다.

"linux-kernel"이메일 목록 (원본에서 실행 됨 vger), 뉴스 그룹 alt.os.linux, comp.os.linux ( 1993 년 계층 구조로 빠르게 분할 )가있었습니다.

이 초기 리눅스 자주 묻는 질문 (V1.11 년 11 월 1992) comp.os.linux 등으로부터도 직접 리누스 이메일을 보내 제안합니다.

1992 년 Matt Welsh ( Linux , Linux Bible , TLDP 실행 ) 는ibug 전자 메일로 전송 된 버그 보고서 생성을 지원 한다고 발표 했습니다.

이메일 버그 리포트 템플릿linux.temp 은 정기적으로 comp.os.linux에 게시되었으며, 버그 리포트에 대한 업데이트linux.fix.temp 는 업데이트 템플릿 입니다.

패치 저장소 (FTP) 도 있었는데 , 이것이 리눅스로 포팅하기위한 프로그램 패치에 주로 사용되는 것은 아닙니다.

1993-1994

커널 소스의 CVS 사본은 일반적이며, 내가 찾을 수있는 가장 빠른 것은 kernal-0.99.14 시대의 Dirk Steinberg입니다. 처음 발표 내가 찾을 수는 리눅스 활동가에 1993년 1월에서입니다. 보관 된 사본 (1994)을 계속 찾을 수 있습니다 . Dirk는 CVS에서 cvs 바이너리와 libc 소스를 유지 관리했습니다.

CVS는 현대적인 의미에서 버그를 추적하는 데 사용되지 않았으며 일부 개발자는 버그를 선호했으며 패치는 cvs 생성 diff 형식으로 자주 제출되었습니다.

1995-1996

이시기 (1995 년 10 월) David S. Miller는 Linux 커널의 SPARC 포트 ( Linux / SPARC 포트 )에 CVS를 사용하기 시작했습니다 . 2월 1996 여러 가지 다른 커널 개발자들은 독립적으로 리눅스 커널 패치를 추적 할 수 CVS를 사용하고 이 스레드 와 스레드 앨런 콕스, 스티븐 트위 디, 카이 헤 닝센을 :. (두 번째 스레드는 Russ Nelson이 직접 Linus의 CVS에 대한 혐오를 언급한다고보고합니다.)

1997-1998

1998 년 4 월, Linus의 두 번째 아이가 태어난 직후 CVS 문제가 다시 나타났습니다. 리눅스 커널 에서이 하위 스레드를 보았습니다 (Linus는 CVS에 대한 그의 관심을 직접 반복합니다).

1997 년 12 월 Andrew Tridgell 은 웹 기반 버그 추적기 인 jitterbug를 발표했습니다 . 1998 년 6 월, "linux-patches"JitterBug는 Alan Cox에 의해 linux-kernel 에서 옹호되었습니다 . Linus와 다른 주요 개발자들이 사용한 최초의 실제 버그 추적 시스템 인 슬프게도 "linux-patches"인스턴스는 더 이상 온라인 상태가 아닙니다.

1998 년 9 월, 비트 키퍼는 Larry McEvoy에 의해 리눅스 커널에서 처음으로 홍보되었습니다 .

1999 년 이후

1999/2000 년까지 lkml FAQ 는 (원본) vger의 CVS 트리를 (Q 1-16) 참조하기 시작했습니다. 이것은 Andrew Tridgell에 의해 당시 유지되었습니다.

2001 년 12 월, Jitterbug는 호의를 얻지 못했습니다.이 리눅스 커널 스레드 인 Linus, Alan Cox 및 다른 많은 사람들이 이유를 논의하는 데 참여합니다.

2002 년 1 월 Linus는 비트 키퍼 (PowerPC Linux 커널 팀에서 이미 사용)에 관심을 갖기 시작했습니다 .

2002 년 2 월 Linus 는 2.5 개발 트리에 Bitkeeper 를 사용하기 시작했습니다 .

2002 년 11 월 OSDL은 2.5 트리 용 Linux Bugzilla를 호스팅 했다고 발표했다 . ( 질문 의 bugzilla 링크 를 아직 읽지 않았다면 지금 읽어보십시오. 빈티지 Linus rants가 포함되어 있습니다.)

2005 년 4 월 Linus는 처음 git으로 이름으로 언급 한 시간에 BitKeeper 에서 멀어짐을 발표했습니다 . git가 자체 호스팅을 할 수있게 된 직후 Linus는 BitKeeper 사용을 중단하고 커널에 git을 사용하기 시작했습니다.

2008 년 12 월 linux-kernel에 대한 패치 워크 패치 추적기 가 발표되었습니다 . SCCS에 독립적 인 웹 기반 패치 추적기는 메일 링리스트와 통합되어 패치와 후속 조치를 추적합니다. https://patchwork.kernel.org/ 에이 방법으로 추적 된 약 40 개의 목록이 현재까지 계속 사용되고 있지만 모든 기능이 활성화 된 것은 아닙니다.

참고 문헌

유용한 참고 자료 :

• 분산 작업의 본질 : Linux 커널의 사례 (Jae Yun Moon, Lee Sproull) http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (2000 년 11 월)
• Linux 버그보고 지침 (1992 년 7 월) http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• Kenneth R. Saborio의 중요한 Linux 게시물 / 이메일 아카이브 : http://www.informatica.co.cr/linux/index.htm(1991-2005 )
• 오늘 (2014 년 11 월)부터 linux-kernel 아카이브 (1995 년) http://lkml.iu.edu/hypermail/linux/kernel/ (슬프게도, 첫 번째 이메일은 1995 년 6 월부터 Chris Dent가 자신이 이전에 잃었다 고 발표 한 이메일입니다 아카이브 ...) LKML 아카이브는 1996 년 으로 돌아갑니다.
• tsx11에서 linux-devel 1993-1994의 단편 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux- devel / (URL 및 파일의 날짜 무시)
• 버전 관리 도구 : Linux 커널 , Sjaikh & Cornford (C. 2003) 에서 CVS에서 BK로
• git 10 주년을 맞이하는 이 해커 뉴스 스레드 (2015 년 3 월)를 참조하십시오 : https://news.ycombinator.com/item?id=9263336

git자체 개발을 위해 버그보고가 처리되는 방식을 알 수 있습니다 .

그들은 버그 추적 소프트웨어를 사용하지 않습니다. 버그는 개발 메일 링리스트 에서보고되고 논의됩니다 . 아마도 놀랍지 만 잘 작동합니다.

버그 추적 소프트웨어를 사용하라는 질문이나 제안이 자주 나오므로 git 메일 링리스트 아카이브를 검색하여 이에 대해 많은 것을 배울 수 있습니다.

"충분한 버그 추적기를 아직 찾지 못했다"는 것이 아닙니다.
그러나 "우수한 방법이있다"는 것도 아닙니다.

이 방법을 사용하면 프로젝트 또는 하위 프로젝트 (주 개발자와 같은)의 관리자가 개발 목록의 비공식 중재자로서 중요한 역할을합니다.
버그 처리는 그 일부이며, 이런 방식으로 버그를 관리하는 것은 쉬운 일이 아닙니다. 그것은 분명히 그 역할을 수행하는 사람들의 기술에 달려 있습니다.

이 방법의 가장 공식적인 부분은 주간 상태 요약 메시지입니다.
다양한 지점에서 현재 진행중인 작업을 짧은 항목으로 나열합니다. git 개발의 예 gmane.comp.version-control.git는 메일 그룹을 미러링하는 뉴스 그룹 에서 git.git의 요리 내용을 참조하십시오.

내가 확실히 말할 수있는 것 : 당신이 이것에 능숙한 관리자가 있다면, 그것은 매우 잘 작동합니다.
예를 들어, 버그 트래커의 도입이 변경 오버 헤드를 상각 한 후에도 장기적으로 구현 된 기능과 품질에 대한 생산성에 긍정적 인 영향을 미친다면 매우 놀랐습니다.

Linux 커널의 경우 현재까지 git에서 수행되는 방식과 유사합니다.
리눅스 커널 개발을위한 개발 메일 링리스트는 확실히 중요하다. 그러나 git과 같은 중심 장소로는 하나의 목록이 아닙니다. 파일 시스템 또는 네트워킹과 같은 하위 주제에 대한 별도의 목록이 있습니다.
대부분 별도의 개발자가 처리하는 별도의 주제가 있기 때문에 일부 그룹은 해당 그룹에 로컬로 도구를 사용할 수 있습니다.