Làm thế nào mà dự án Linux Kernel theo dõi các lỗi trong những ngày đầu?

Chúng ta đều biết rằng Linus Torvalds đã tạo ra Git vì các vấn đề với Bitkeeper. Điều không được biết (ít nhất là với tôi) là, các vấn đề / vé / lỗi được theo dõi cho đến lúc đó như thế nào? Tôi đã thử nhưng không có gì thú vị. Cuộc thảo luận duy nhất tôi có thể có được về chủ đề này là cuộc thảo luận mà Linus đã chia sẻ mối quan tâm với việc sử dụng Bugzilla .

Suy đoán: - Cách dễ nhất để mọi người theo dõi lỗi trong giai đoạn ban đầu là đặt vé vào một nhánh của chính nó nhưng chắc chắn rằng sẽ nhanh chóng không bị ảnh hưởng bởi tiếng ồn khi vượt qua các lỗi tốt.

Tôi đã thấy và sử dụng Bugzilla và trừ khi bạn biết đúng 'từ khóa' vào những lúc bạn sẽ bị bối rối. LƯU Ý: Tôi đặc biệt quan tâm đến những năm đầu (1991-1995) về cách họ sử dụng để theo dõi các vấn đề.

Tôi đã xem xét hai chủ đề, " Kernel SCM saga " và " Trivia: Khi nào git tự lưu trữ? " Nhưng không ai trong số này đề cập đến việc theo dõi lỗi của kernel trong những ngày đầu.

Tôi đã tìm kiếm xung quanh và không thể tìm thấy bất kỳ phần mềm theo dõi lỗi FOSS nào có trong năm 1991-1992. Bugzilla, Người theo dõi yêu cầu và những người khác đến muộn hơn nhiều, vì vậy họ dường như bị loại.

Câu hỏi chính

1. Linus, những người duy trì hệ thống con và người dùng đã báo cáo và theo dõi các lỗi trong những ngày đó như thế nào?
2. Có phải họ đã sử dụng một số phần mềm theo dõi lỗi, tạo ra một nhánh lỗi và tự đặt câu hỏi và thảo luận về lỗi đó (sẽ rất tốn kém và đau đớn khi làm điều đó) hoặc chỉ sử dụng e-mail.
3. Rất lâu sau, Bugzilla xuất hiện (bản phát hành đầu tiên năm 1998) và đó dường như là cách chính để báo cáo lỗi sau đó .

Nhìn về phía trước để có một bức tranh rõ ràng hơn về cách mọi thứ đã được thực hiện trong những ngày cũ.

Ban đầu, nếu bạn có một cái gì đó để đóng góp (bản vá hoặc báo cáo lỗi), bạn đã gửi nó cho Linus. Điều này phát triển thành gửi thư đến danh sách ( linux-kernel@vger.rutgers.edutrước đây kernel.orgđã được tạo ra).

Không có kiểm soát phiên bản. Thỉnh thoảng, Linus đặt một tarball trên máy chủ FTP. Điều này tương đương với một "thẻ". Các công cụ có sẵn lúc đầu là RCS và CVS, và Linus ghét chúng, vì vậy mọi người chỉ cần gửi các bản vá. (Có một lời giải thích từ Linus về lý do tại sao anh ta không muốn sử dụng CVS.)

Có các hệ thống kiểm soát phiên bản độc quyền tiền Bitkeeper khác, nhưng sự phát triển dựa trên tình nguyện phi tập trung của Linux đã khiến nó không thể sử dụng chúng. Một người ngẫu nhiên vừa tìm thấy một lỗi sẽ không bao giờ gửi một bản vá nếu nó phải thông qua một hệ thống kiểm soát phiên bản độc quyền với giấy phép bắt đầu bằng hàng ngàn đô la.

Bitkeeper đã khắc phục cả hai vấn đề đó: nó không tập trung như CVS và trong khi đó không phải là Phần mềm miễn phí, những người đóng góp kernel được phép sử dụng nó mà không phải trả tiền. Điều đó làm cho nó đủ tốt trong một thời gian.

Ngay cả với sự phát triển dựa trên git ngày nay, các danh sách gửi thư vẫn là nơi hành động. Khi bạn muốn đóng góp một cái gì đó, tất nhiên bạn sẽ chuẩn bị nó với git, nhưng bạn sẽ phải thảo luận về nó trong danh sách gửi thư có liên quan trước khi nó được hợp nhất. Bugzilla ở đó để trông "chuyên nghiệp" và tiếp thu các báo cáo lỗi nửa nướng từ những người không thực sự muốn tham gia.

Để xem một số hướng dẫn báo cáo lỗi cũ, hãy lấy kho lưu trữ Linux lịch sử . (Đây là kho lưu trữ git chứa tất cả các phiên bản từ trước khi git tồn tại; chủ yếu là nó chứa một cam kết cho mỗi lần phát hành kể từ khi nó được xây dựng lại từ tarball). File quan tâm bao gồm README, MAINTAINERSvà REPORTING-BUGS.

Một trong những điều thú vị mà bạn có thể tìm thấy đó là từ 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.

Các quy trình được sử dụng các nhóm tin tức (USENET) và email (chủ yếu). Một lỗi "tồn tại" như một chủ đề, đặt " [BUG REPORT]" hoặc " LINUX BUG REPORT" trong chủ đề là một quy ước chung. Không có ID lỗi. Với cơ sở người dùng thông thường, một báo cáo lỗi thường đi kèm với một bản vá. Có một công cụ phần mềm bị lãng quên từ lâu được sử dụng: ibug(xem bên dưới), ngoài công cụ diff+ patch.

Từ cài đặt Linux và bắt đầu (tháng 1 năm 1994, bản sao lưu trữ 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

Đây là báo cáo lỗi và sửa từ tháng 12 năm 1992 (0.98.6) trên comp.os.linux: https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

Rất sớm đã có một danh sách email ml-linux-bug (1992/1993), từ Câu hỏi thường gặp ban đầu này trong bản phân phối Slackware 1.01:

VI.01) Có vẻ như $ # @! được chuyển trên linux không chạy chính xác, tôi phải làm gì khi báo cáo lỗi?

[...] Lưu ý rằng danh sách báo cáo lỗi "ml-linux-bugs@dg-rtp.dg.com" của tôi đã bị loại bỏ. Hóa ra Linux có quá ít lỗi, hầu hết được giải quyết trên nhóm tin tức hoặc thông qua Linus trước khi tôi có thể tích lũy chúng và đăng bài. :) Tóm lại: nếu có lỗi trong Linux hoặc trong phần mềm có cổng Linux, thì nó thường sẽ được sửa trong bản vá hoặc phiên bản tiếp theo.

Có danh sách email "linux-kernel" (chạy trên bản gốc vger), nhóm tin alt.os.linux, sau đó comp.os.linux (nhanh chóng phân chia thành một hệ thống phân cấp vào năm 1993 ).

Câu hỏi thường gặp về Linux sớm này (v1.11 tháng 11 năm 1992) từ comp.os.linux cũng đề nghị gửi email trực tiếp cho Linus.

Năm 1992, Matt Welsh ( Chạy Linux , Kinh thánh Linux , TLDP ) đã tuyên bốibug hỗ trợ tạo báo cáo lỗi qua email (trớ trêu thay, bạn không thể chạy nó trên Linux tại thời điểm đó vì nó không đủ mạng để có thể gửi email).

Mẫu báo cáo lỗilinux.temp email cũng được đăng định kỳ trên comp.os.linux và các bản cập nhật cho báo cáo lỗi có mẫu cập nhậtlinux.fix.temp .

Ngoài ra còn có một kho lưu trữ bản vá (FTP) , theo như tôi có thể nói rằng phần lớn (không phải độc quyền) cho các bản vá cho các chương trình để chuyển sang Linux.

1993-1994

Các bản sao CVS của nguồn nhân là phổ biến, sớm nhất tôi có thể tìm thấy là của Dirk Steinberg, từ thời đại kernal-0,99,14. Các thông báo đầu tiên tôi có thể tìm thấy là từ tháng 1 năm 1993 trên linux-nhà hoạt động. Bạn vẫn có thể tìm thấy các bản sao lưu trữ (1994) . Dirk cũng duy trì nhị phân cvs và nguồn libc trong CVS.

CVS không được sử dụng để theo dõi các lỗi theo nghĩa hiện đại, một số nhà phát triển thích sử dụng nó và các bản vá thường được gửi dưới dạng cvs tạo khác biệt.

1995-1996

Trong khoảng thời gian này (tháng 10 năm 1995) David S. Miller bắt đầu sử dụng CVS cho cổng SPARC của nhân Linux ( Cổng Linux / SPARC ). Đến tháng 2 năm 1996, một số nhà phát triển kernel khác đã sử dụng CVS một cách độc lập để theo dõi các bản vá, từ linux-kernel luồng này và luồng này : Alan Cox, Stephen Tweedie, Kai Henningsen. (Chủ đề thứ hai báo cáo rằng Russ Nelson nói rõ sự ác cảm của Linus với CVS.)

1997-1998

Vào tháng 4 năm 1998, ngay sau khi sinh đứa con thứ hai của Linus, vấn đề về CVS đã xuất hiện trở lại, từ kernel-kernel nhìn thấy sự thay thế này (Linus nhắc lại mối quan tâm của anh ấy về CVS ở đó).

Vào tháng 12 năm 1997, Andrew Tridgell đã phát hành jitterorms , một công cụ theo dõi lỗi dựa trên web. Đến tháng 6 năm 1998, JitterBug "linux-patch" đã được Alan Cox ủng hộ trên linux-kernel . Điều này theo như tôi có thể nói, hệ thống theo dõi lỗi thực tế đầu tiên được Linus và các nhà phát triển khóa khác sử dụng, thật đáng buồn là phiên bản "linux-patch" không còn trực tuyến nữa.

Vào tháng 9 năm 1998, bitkeeper được quảng bá lần đầu tiên trên kernel-linux bởi Larry McEvoy.

1999 và sau đó

Đến năm 1999/2000, Câu hỏi thường gặp về lkml bắt đầu đề cập đến (Q 1-16) cho cây CVS trên (bản gốc) vger. Điều này được duy trì tại thời điểm bởi Andrew Tridgell.

Đến tháng 12 năm 2001, Jitterorms đã không được ủng hộ, hãy xem chủ đề hạt nhân linux này , Linus, Alan Cox và nhiều người khác tham gia thảo luận về lý do tại sao.

Đến tháng 1 năm 2002, Linus bắt đầu quan tâm đến bitkeeper (đã được nhóm nhân PowerPC Linux sử dụng).

Vào tháng 2 năm 2002, Linus bắt đầu sử dụng Bitkeeper cho cây phát triển 2.5.

Vào tháng 11 năm 2002, OSDL đã lưu trữ Linux Bugzilla cho cây 2.5 đã được công bố . (Nếu bạn chưa đọc liên kết bugzilla trong câu hỏi, hãy đi và đọc nó ngay bây giờ, nó có chứa các câu thần chú Linus cổ điển).

Vào tháng 4 năm 2005, Linus tuyên bố rời khỏi BitKeeper , khoảng thời gian anh được nhắc đến lần đầu tiên gitbằng tên . Ngay sau khi git trở nên có khả năng tự lưu trữ , Linus đã ngừng sử dụng BitKeeper và bắt đầu sử dụng git cho kernel.

Vào tháng 12 năm 2008, trình theo dõi bản vá chắp vá cho kernel-linux đã được công bố , đây là trình theo dõi bản vá dựa trên web không liên quan đến SCCS tích hợp với danh sách gửi thư để theo dõi các bản vá và theo dõi. Việc sử dụng của nó tiếp tục cho đến ngày nay, có khoảng 40 danh sách được theo dõi theo cách này trên https://patchwork.kernel.org/ , mặc dù không phải tất cả đều hoạt động.

Tài liệu tham khảo

Tài liệu tham khảo hữu ích:

• Bản chất của công việc phân tán: Trường hợp hạt nhân Linux (Jae Yun Moon, Lee Sproull) http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (tháng 11 năm 2000)
• Hướng dẫn báo cáo lỗi Linux (tháng 7 năm 1992) http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• Kho lưu trữ các bài đăng / email quan trọng của Kenneth R. Saborio: http://www.informatica.co.cr/linux/index.htm (1991-2005)
• lưu trữ linux-kernel từ hôm nay (tháng 11 năm 2014) trở lại năm 1995 http://lkml.iu.edu/hypermail/linux/kernel/ (đáng buồn thay, email đầu tiên là từ tháng 6 năm 1995, nơi quản trị viên Chris Dent thông báo rằng anh ta đã mất trước đó lưu trữ ...) Lưu trữ LKML chỉ quay trở lại năm 1996
• Các đoạn từ linux-devel 1993-1994 từ tsx11 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux- devel / (bỏ qua các ngày trong URL và trên các tệp)
• Công cụ quản lý phiên bản: CVS sang BK trong Linux Kernel , Sjaikh & Cornford (khoảng năm 2003)
• Xem thêm chủ đề Tin tức Hacker này (tháng 3 năm 2015) là kỷ niệm 10 năm tiếp cận git: https://news.ycombinator.com/item?id=9263336

Tôi có thể cho biết cách báo cáo lỗi được xử lý cho sự phát triển của gitchính nó.

Họ không sử dụng bất kỳ phần mềm theo dõi lỗi. Lỗi được báo cáo và thảo luận về danh sách gửi thư phát triển . Nó có thể gây ngạc nhiên, nhưng hoạt động rất tốt.

Câu hỏi hoặc đề xuất sử dụng một số phần mềm theo dõi lỗi xuất hiện thường xuyên, vì vậy bạn có thể tìm hiểu rất nhiều về vấn đề này từ việc tìm kiếm lưu trữ danh sách gửi thư git.

Đó không phải là "chúng tôi chưa tìm thấy trình theo dõi lỗi đủ tốt";
Nhưng nó cũng không phải là "chúng ta có một phương pháp ưu việt".

Với phương pháp này, người duy trì dự án hoặc tiểu dự án - một cái gì đó giống như một nhà phát triển chính - có vai trò quan trọng là người điều hành không chính thức của danh sách phát triển.
Xử lý lỗi là một phần của nó và dường như không phải là một nhiệm vụ tầm thường để quản lý lỗi theo cách này; Nó chắc chắn phụ thuộc vào kỹ năng của những người trong vai trò đó.

Phần chính thức nhất của phương pháp là một thông báo tóm tắt trạng thái hàng tuần.
Nó liệt kê những thứ hiện đang diễn ra trên các nhánh khác nhau như các mục ngắn. Để biết ví dụ từ sự phát triển của git, hãy xem điều này tại nhóm tin gmane.comp.version-control.gitphản ánh danh sách gửi thư: Nấu ăn gì trong git.git

Những gì tôi có thể nói chắc chắn: Nếu bạn có một người bảo trì giỏi về việc này, nó hoạt động cực kỳ tốt.
Ví dụ, tôi sẽ rất ngạc nhiên nếu việc giới thiệu trình theo dõi lỗi có năng suất hiệu quả tích cực đối với các tính năng và chất lượng được triển khai, ngay cả trong dài hạn sau khi khấu hao chi phí thay đổi.

Đối với nhân Linux, nó tương tự như cách nó được thực hiện cho git, cho đến ngày nay.
Danh sách gửi thư phát triển để phát triển nhân Linux chắc chắn rất quan trọng. Nhưng nó không phải là một danh sách như một vị trí trung tâm như với git. Có các danh sách riêng cho các chủ đề phụ, như hệ thống tập tin hoặc mạng.
Do có các chủ đề riêng biệt, được xử lý bởi hầu hết các nhà phát triển riêng biệt, nên có thể một số nhóm sử dụng các công cụ cục bộ cho nhóm của họ.