☰

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

tag-icon • tag-icon linux kernel git history
Linux 커널 프로젝트 초기에는 버그를 어떻게 추적했습니까?

우리 모두는 Linus Torvalds가 Bitkeeper의 문제 때문에 Git을 만들었다는 것을 알고 있습니다. (적어도 나에게는) 내가 모르는 것은 그 전에 문제/티켓/버그를 추적하는 방법입니다. 나는 시도했지만 흥미로운 것을 얻지 못했습니다. 이 주제에 대해 내가 할 수 있는 유일한 토론은 이것입니다.Linus는 Bugzilla 사용에 대한 우려를 공유합니다..

추측:- 사람들이 초기 단계에서 버그를 추적하는 가장 쉬운 방법은 티켓을 자체 분기에 넣는 것입니다. 그러나 노이즈가 좋은 버그보다 더 커지면 곧바로 확장되지는 않을 것이라고 확신합니다.

나는 Bugzilla를 보고 사용해 보았는데 올바른 "키워드"를 모르면 때때로 막힐 수 있습니다.노트:나는 특히 초기(1991-1995)에 관심이 있습니다.에 익숙해문제를 추적하세요.

두 개의 단서를 살펴봤습니다."커널 SCM 범례", 그리고"상식: Git은 언제 자체 호스팅이 되었나요?” 그러나 이 중 어느 것도 초기 커널 버그 추적을 언급하지 않습니다.

나는 주변을 검색했지만 1991-1992년에 등장한 FOSS 버그 추적 소프트웨어를 찾을 수 없었습니다. Bugzilla, Request-tracker 및 기타 도구는 훨씬 나중에 출시되었으므로 단계적으로 폐지된 것 같습니다.

핵심 문제

  1. 그렇다면 당시 Linus와 하위 시스템 관리자, 사용자는 어떻게 버그를 보고하고 추적했습니까?
  2. 버그 추적 소프트웨어를 사용하거나, 버그 분기를 만들고, 그 안에 있는 버그에 대한 문제와 토론을 수동으로 제출하거나(비용이 많이 들고 고통스럽습니다), 아니면 그냥 이메일을 사용합니까?
  3. 훨씬 후에 Bugzilla가 등장했고(1998년에 처음 출시됨)오류 사실을 사후에 보고하는 주요 방법.

과거에 어떻게 일이 이루어졌는지에 대한 보다 명확한 이해를 기대합니다.

답변1

처음에는 무언가(패치나 버그 보고서)를 제공해야 하는 경우 Linus에 메일로 보낼 수 있습니다. 이는 목록으로 메일을 보내는 방식으로 발전했습니다(목록이 생성되기 전 [email protected]).kernel.org

버전 관리가 없습니다. Linus는 때때로 FTP 서버에 tarball을 배치합니다. 이는 "라벨"과 동일합니다. 처음에 사용 가능한 도구는 RCS와 CVS였으며 Linus는 이를 싫어했기 때문에 모두가 패치를 메일로 보냈습니다. (이있다리누스의 설명그가 CVS를 사용하고 싶지 않은 이유에 대해. )

Bitkeeper 이전에는 다른 독점 버전 제어 시스템이 있었지만 Linux의 분산형 자원 봉사 기반 개발로 인해 사용할 수 없게 되었습니다. 패치가 독점 버전 제어 시스템(라이센스는 수천 달러부터 시작)을 거쳐야 한다면 방금 버그를 발견한 임의의 사람들은 결코 패치를 보내지 않을 것입니다.

Bitkeeper는 두 가지 문제를 모두 해결합니다. CVS만큼 중앙 집중화되어 있지 않으며, 무료 소프트웨어는 아니지만 커널 기여자가 무료로 사용할 수 있습니다. 그로 인해 한동안은 충분히 좋아졌습니다.

오늘날 git 기반 개발에도 불구하고 메일링 리스트는 여전히 가장 중요한 곳입니다. 무언가를 기여하고 싶다면 물론 git을 사용하여 준비할 수 있지만 병합하기 전에 관련 메일링 리스트에서 논의해야 합니다. Bugzilla는 "전문적"으로 보이고 전문적이지 않은 사람들의 설익은 버그 보고서를 흡수하기 위해 존재합니다.진짜그것의 일부가 되기를 원합니다.

오래된 버그 보고 지침을 보려면Linux 기록 저장소. (이것은 git이 존재하기 전의 모든 버전을 포함하는 git 저장소입니다. 대부분의 경우 tarball에서 다시 빌드되므로 버전당 하나의 커밋을 포함합니다.) 관심 있는 파일에는 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 ([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.

답변2

이러한 프로세스는 뉴스그룹(USENET)과 (주로) 이메일을 사용합니다. 버그는 스레드로 "존재"하며 제목에 " " 또는 " "를 추가하는 것이 [BUG REPORT]일반적인 관례입니다 . LINUX BUG REPORT오류ID가 없습니다. 일반적인 사용자 기반을 고려할 때 버그 보고서에는 패치가 동반되는 경우가 많습니다. 오랫동안 잊혀진 소프트웨어 도구를 사용했습니다: ( ibug아래 참조) 무엇보다도 diff+ patch.

~에서Linux 설치 및 시작하기(1994년 1월, 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년

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

아주 초기에는 이메일 목록이 있었습니다.ml-리눅스-버그(1992/1993), 여기에서초기 FAQ내부에여유 소프트웨어릴리스 1.01:

VI.01) $#@!을 Linux로 포팅한 후 제대로 실행되지 않는 것 같습니다. 오류를 보고하려면 어떻게 해야 하나요?

[...] 내 "[이메일 보호됨]"버그 보고서 목록이 제거되었습니다. Linux에는 버그가 너무 적어서 대부분 뉴스 그룹이나 Linus를 통해 해결된 후 모아서 게시할 수 있는 것으로 나타났습니다. :) 간단히 말해서: Linux에 있는 경우 버그나 Linux로 포팅된 소프트웨어의 경우 일반적으로 다음 패치 레벨이나 버전에서 수정됩니다.

"linux-kernel" 이메일 목록(원래 버전에서 실행됨 vger), 뉴스 그룹 alt.os.linux, 그리고 comp.os.linux(곧1993년 계층구조로 분할).

이것초기 Linux FAQ(v1.11 1992년 11월)comp.os.linux에서는 Linus에게 직접 이메일을 보낼 것을 권장합니다.

1992년매트 웰시(리눅스 실행,리눅스 성경,TLDP)발표하다ibug이메일로 전송되는 오류 보고서를 생성하는 데 도움이 됩니다(아이러니하게도 당시 Linux에서는 이메일을 보낼 만큼 충분한 네트워크가 부족했기 때문에 이 기능을 실행할 수 없었습니다).

이메일오류 보고서 템플릿linux.temp또한 comp.os.linux에도 정기적으로 게시되며 버그 보고서는 다음으로 업데이트됩니다.템플릿 업데이트linux.fix.temp.

아직 하나 있어요패치 저장소(FTP), 내가 아는 한 이것은 주로 (배타적이지는 않지만) Linux로 포팅된 프로그램에 대한 패치입니다.

1993-1994

커널 소스 코드의 CVS 복사본은 일반적이며 내가 찾을 수 있는 가장 빠른 것은 커널 0.99.14 시대의 Dirk Steinberg의 것입니다. 이것첫 번째 발표linux-activists에서 1993년 1월의 내용을 찾을 수 있습니다. 넌 아직 찾을 수 있어보관된 사본(1994). Dirk는 또한 CVS에서 cvs 바이너리와 libc 소스 코드를 유지 관리합니다.

CVS는 현대적인 의미에서 버그를 추적하는 데 사용되지 않으며 일부 개발자는 CVS 사용을 선호하며 패치는 cvs에서 생성된 diff로 제출되는 경우가 많습니다.

1995-1996

이 무렵(1995년 10월) David S. Miller는 Linux 커널의 SPARC 포트에 CVS를 사용하기 시작했습니다(Linux/SPARC 포트). 1996년 2월까지 몇몇 다른 커널 개발자들은 독립적으로 CVS를 사용하여 linux-kernel의 패치를 추적했습니다.이 스레드그리고이 스레드: 앨런 콕스, 스티븐 트위디, 케이 헤닝슨. (두 번째 스레드에서는 Russ Nelson이 Linus의 CVS에 대한 혐오감을 직접적으로 표현했다고 보고합니다.)

1997-1998

1998년 4월, 리누스의 둘째 아이가 태어난 직후, linux-kernel에서 볼 수 있듯이 CVS에 문제가 재발했습니다.이 하위 스레드(Linus는 CVS에 대한 우려를 직접적으로 반복했습니다.)

1997년 12월, 앤드루 테리갈게시된 지터버그, 웹 기반 버그 추적기입니다. 1998년 6월까지 "linux-patches" JitterBug가 개발되었습니다.linux-kernel에서 Alan Cox가 제공함. 내가 아는 바로는 이것이 Linus와 다른 주요 개발자들이 사용한 최초의 실제 버그 추적 시스템이었습니다. 안타깝게도 "linux-patches" 인스턴스는 더 이상 온라인 상태가 아닙니다.

1998년 9월bitkeeper가 Linux 커널에서 처음으로 승격되었습니다.저자: 래리 맥에보이

1999년 이후

통과1999/2000 lml FAQ(원본) vger의 CVS 트리를 참조하여 시작하십시오(질문 1-16). 이것은 당시 Andrew Tridgell에 의해 유지되었습니다.

2001년 12월까지 Jitterbug는 인기를 잃었습니다. 이 Linux 커널을 참조하세요.철사, Linus, Alan Cox 및 기타 많은 사람들이 그 이유에 대해 논의합니다.

2002년 1월까지,Linus는 비트키퍼에 관심을 갖게 되었습니다.(PowerPC Linux 커널 팀에서는 이미 사용하고 있습니다).

2002년 2월Linus는 Bitkeeper를 사용하기 시작합니다.2.5 개발 트리의 경우.

2002년 11월, OSDL은 2.5 트리용 Linux Bugzilla를 호스팅했습니다.발표되다. (아직 읽지 않으셨다면버그질라 링크질문에는 지금 읽어보세요. 오래된 Linus의 폭언이 포함되어 있습니다.)

2005년 4월Linus는 BitKeeper에서 탈퇴한다고 발표했습니다., 약.git그 사람이 먼저 이름을 언급했지. 곧바로git은 이미 자체 호스팅이 가능합니다.그 후 Linus는 BitKeeper 사용을 중단하고 git을 커널로 사용하기 시작했습니다.

2008년 12월덧붙여 대는 세공패치 추적기리눅스 커널이 출시되었습니다, 메일링 리스트와 통합되어 패치 및 후속 패치를 추적하는 SCCS에 구애받지 않는 웹 기반 패치 추적기입니다. 이 방법은 오늘날까지 계속 사용되고 있으며 약 40개의 목록이 이러한 방식으로 추적되고 있습니다.https://patchwork.kernel.org/, 그러나 모두가 활성화된 것은 아닙니다.

인용하다

유용한 참고자료:

답변3

버그 보고가 자체 개발을 어떻게 처리하는지 알 수 있습니다 git.

그들은 버그 추적 소프트웨어를 사용하지 않습니다. 버그가 보고되었으며 다음에서 논의되었습니다.메일링 리스트 개발. 이는 놀라운 일이지만 잘 작동합니다.

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

이것은 "충분히 좋은 버그 추적기를 찾지 못했습니다"가 아니라 "아직 충분히 좋은 버그 추적기를 찾지 못했습니다"에 관한 것입니다.
그러나 “우리에게는 더 나은 방법이 있습니다”도 아닙니다.

이 접근 방식을 사용하면 프로젝트 또는 하위 프로젝트의 관리자(예: 수석 개발자)가 개발 목록의 비공식 조정자로서 중요한 역할을 할 수 있습니다.
버그를 처리하는 것은 그 일부이며 이러한 방식으로 버그를 관리하는 것은 간단한 작업처럼 보이지 않을 수 있습니다. 이는 확실히 해당 역할을 수행하는 사람의 기술에 달려 있습니다.

이 접근 방식의 가장 공식적인 부분은 주간 상태 요약 메시지입니다.
각 브랜치에서 현재 일어나고 있는 일을 간략한 항목으로 나열합니다. git 개발의 예를 보려면 gmane.comp.version-control.git미러 메일링 리스트 뉴스그룹을 참조하세요.git.git이 하는 일

저는 이것을 확실히 말할 수 있습니다. 이 일을 잘하는 관리자가 있다면 아주 잘 작동할 것입니다.
예를 들어, 나는매우버그 추적기의 도입이 변경 오버헤드를 상각한 후에도 장기적으로 구현의 기능과 품질에 긍정적인 생산성 영향을 미친다면 놀랄 것입니다.


Linux 커널의 경우 지금까지 git이 수행한 작업과 유사합니다.
Linux 커널 개발을 위한 개발 메일링 리스트는 확실히 중요합니다. 하지만 git처럼 중앙 위치로 목록이 없습니다. 파일 시스템이나 네트워킹과 같은 별도의 하위 주제 목록이 있습니다.
별도의 주제가 존재하고 주로 별도의 개발자가 처리하므로 일부 그룹은 실제로 해당 그룹에 국한된 도구를 사용할 수 있습니다.

관련 정보