โครงการ Linux Kernel ติดตามข้อบกพร่องในช่วงแรกได้อย่างไร

เราทุกคนรู้ว่า Linus Torvalds สร้าง Git เนื่องจากปัญหาเกี่ยวกับ Bitkeeper ไม่มีอะไรที่เป็นที่รู้จัก (อย่างน้อยสำหรับฉัน) คือปัญหา / ตั๋ว / ข้อบกพร่องถูกติดตามอย่างไรจนถึงตอนนี้ ฉันพยายาม แต่ไม่ได้สนใจอะไรเลย การอภิปรายเดียวที่ฉันก็สามารถที่จะได้รับในเรื่องนี้เป็นหนึ่งในที่ไลนัสที่ใช้ร่วมกันกับความกังวลเกี่ยวกับการใช้ Bugzilla

การเก็งกำไร: - วิธีที่ง่ายที่สุดสำหรับคนที่จะติดตามบั๊กในระยะแรกนั้นคือการใส่ตั๋วในสาขาของตัวเอง แต่มั่นใจว่าค่อนข้างเร็วที่จะไม่ลดขนาดด้วยเสียงรบกวนมากกว่าการรับบั๊กที่ดี

ฉันเคยเห็นและใช้ Bugzilla และถ้าคุณไม่รู้จัก 'คำหลัก' ที่ถูกต้องในบางครั้งคุณก็จะถูกนิ่งงัน หมายเหตุ:ฉันสนใจเป็นพิเศษในช่วงต้นปี (2534-2538) ว่าพวกเขาเคยติดตามปัญหาอย่างไร

ฉันดูสองกระทู้ " Kernel SCM saga " และ " Trivia: git self-host เมื่อไหร่? " แต่ไม่มีสิ่งใดที่กล่าวถึงเกี่ยวกับการติดตามบั๊กของเคอร์เนลในวันแรก ๆ

ฉันค้นหาไปรอบ ๆ และไม่สามารถรับซอฟต์แวร์ติดตามบั๊กของ FOSS ใด ๆ ที่อยู่ในนั้นในปี 1991-1992 Bugzilla, Request-tracker และอื่น ๆ มามากในภายหลังดังนั้นพวกเขาจึงดูเหมือนจะออก

คำถามสำคัญ

1. ในตอนนั้นไลนัสผู้ดูแลระบบย่อยและผู้ใช้รายงานและติดตามข้อบกพร่องในสมัยนั้นอย่างไร
2. พวกเขาใช้ซอฟต์แวร์ติดตามบั๊กทำสาขาของบั๊กและตั้งคำถามและอภิปรายด้วยตนเองในบั๊ก (อาจมีราคาแพงและเจ็บปวดในการทำเช่นนั้น) หรือแค่ใช้อีเมล
3. ภายหลัง Bugzilla มาพร้อม (รุ่นแรก 1998) และที่ดูเหมือนว่าจะเป็นวิธีการหลักในการรายงานข้อบกพร่องนั้น

หวังว่าจะมีภาพที่ชัดเจนขึ้นของวิธีการทำสิ่งต่างๆในวันที่เก่ากว่า

ในการเริ่มต้นถ้าคุณมีสิ่งที่จะมีส่วนร่วม (แพทช์หรือรายงานข้อผิดพลาด) คุณส่งมันไปยังไลนัส สิ่งนี้ได้วิวัฒนาการไปสู่การส่งจดหมายไปยังรายการ (ซึ่งlinux-kernel@vger.rutgers.eduก่อนหน้าkernel.orgนี้ถูกสร้างขึ้น)

ไม่มีการควบคุมเวอร์ชัน บางครั้งไลนัสก็ใส่ tarball ลงในเซิร์ฟเวอร์ FTP นี่คือเทียบเท่ากับ "แท็ก" เครื่องมือที่มีในตอนแรกคือ RCS และ CVS และ Linus เกลียดพวกนั้นดังนั้นทุกคนก็แค่ส่งแพตช์ (มีคำอธิบายจาก Linusเกี่ยวกับสาเหตุที่เขาไม่ต้องการใช้ CVS)

มีระบบการควบคุมเวอร์ชัน pre-Bitkeeper ที่เป็นกรรมสิทธิ์อื่น ๆ แต่การพัฒนาแบบกระจายโดยใช้อาสาสมัครของ Linux ทำให้ไม่สามารถใช้งานได้ บุคคลที่สุ่มที่เพิ่งพบข้อผิดพลาดจะไม่ส่งแพตช์หากต้องผ่านระบบควบคุมเวอร์ชันที่เป็นกรรมสิทธิ์พร้อมใบอนุญาตเริ่มต้นที่พันดอลลาร์

Bitkeeper แก้ปัญหาทั้งสองอย่าง: มันไม่ได้รวมอยู่ที่ส่วนกลางเหมือน CVS และในขณะที่มันไม่ใช่ซอฟต์แวร์เสรีผู้สนับสนุนเคอร์เนลก็สามารถใช้งานได้โดยไม่ต้องจ่ายเงิน นั่นทำให้ดีพออยู่พักหนึ่ง

แม้จะมีการพัฒนาบนพื้นฐานของระบบคอมไพล์ แต่รายชื่อผู้รับจดหมายยังคงเป็นที่สำหรับการดำเนินการ เมื่อคุณต้องการมีส่วนร่วมคุณจะต้องเตรียมมันด้วย git แน่นอน แต่คุณจะต้องพูดคุยเรื่องนี้ในรายชื่อผู้รับจดหมายที่เกี่ยวข้องก่อนที่จะถูกรวมเข้าด้วยกัน Bugzilla จะมีการดู "มืออาชีพ" และดื่มด่ำรายงานข้อผิดพลาดอ่อนหัดจากคนที่ไม่ได้จริงๆต้องการที่จะได้มีส่วนร่วม

เห็นบางส่วนของคำแนะนำข้อผิดพลาดการรายงานเก่าได้รับประวัติศาสตร์ที่เก็บลินุกซ์ (นี่คือที่เก็บ git ที่มีทุกรุ่นจากก่อนที่ git มีอยู่ส่วนใหญ่จะมีหนึ่งคอมมิทต่อการเปิดตัวเนื่องจากมันถูกสร้างใหม่จาก tarballs) ไฟล์ที่น่าสนใจ ได้แก่README, และMAINTAINERSREPORTING-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" ในหัวเรื่องเป็นแบบแผนทั่วไป ไม่มีรหัสบั๊ก เมื่อพิจารณาจากฐานผู้ใช้ทั่วไปรายงานข้อผิดพลาดมักจะมาพร้อมกับแพตช์ มีเป็นหนึ่งในเครื่องมือซอฟต์แวร์ยาวลืมใช้ibug(ดูด้านล่าง) กว่าที่อื่น ๆ+diffpatch

จากการติดตั้งและเริ่มต้นใช้งาน Linux (ม.ค. 1994, สำเนาที่เก็บถาวร 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 (0.98.6) ใน comp.os.linux: https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

เร็วมากมีรายชื่ออีเมลml-linux-bugs (1992/1993) จากคำถามที่พบบ่อยก่อนหน้านี้ในการแจกจ่ายSlackware 1.01:

VI.01) ดูเหมือนว่า $ # @! พอร์ตบน Linux ไม่ทำงานอย่างถูกต้องฉันจะทำอย่างไรเกี่ยวกับการรายงานข้อบกพร่อง?

[... ] โปรดทราบว่ารายการการรายงานข้อผิดพลาด "ml-linux-bugs@dg-rtp.dg.com" ของฉันได้ถูกยกเลิก ปรากฎว่าลินุกซ์มีข้อบกพร่องน้อยมากซึ่งส่วนใหญ่จะได้รับการแก้ไขในกลุ่มข่าวหรือผ่าน Linus ก่อนที่ฉันจะสามารถสะสมและโพสต์ได้ :) โดยย่อ: หากมีข้อผิดพลาดใน Linux หรือซอฟต์แวร์ที่มีพอร์ต Linux มักจะได้รับการแก้ไขใน patchlevel หรือเวอร์ชันถัดไป

มีรายการอีเมล "linux-kernel" (ซึ่งรันบนต้นฉบับvger), กลุ่มข่าวสาร alt.os.linux จากนั้น comp.os.linux (ซึ่งแบ่งอย่างรวดเร็วเป็นลำดับชั้นในปี 1993 )

คำถามที่พบบ่อย Linux ต้นนี้(v1.11 พ.ย. 1992)จาก comp.os.linux ยังแนะนำให้ส่งอีเมลถึง Linus โดยตรง

ในปี 1992 แมตต์เวลส์ ( เรียกใช้ Linux , Linux Bible , TLDP ) ประกาศibugให้ความช่วยเหลือในการสร้างรายงานข้อผิดพลาดทางอีเมล (แดกดันคุณไม่สามารถเรียกใช้งานได้บน Linux ในเวลานั้นเนื่องจากไม่มีเครือข่ายเพียงพอที่จะส่งอีเมล)

ส่งอีเมลเทมเพลตรายงานข้อผิดพลาดที่linux.tempถูกโพสต์ในระยะ comp.os.linux เกินไปและการปรับปรุงการรายงานข้อผิดพลาดมีแม่แบบการปรับปรุงlinux.fix.temp

นอกจากนี้ยังมีที่เก็บแพตช์ (FTP)เท่าที่ฉันสามารถบอกได้ว่าส่วนใหญ่ (ไม่เฉพาะ) สำหรับแพทช์ไปยังโปรแกรมสำหรับการย้ายไปยัง Linux

1993-1994

สำเนา CVS ของเคอร์เนลเป็นเรื่องธรรมดาสิ่งแรกที่ฉันสามารถหาได้คือ Dirk Steinberg's จากยุค kernal-0.99.14 การประกาศครั้งแรกที่ฉันพบได้คือตั้งแต่เดือนมกราคม 1993 กับนักเคลื่อนไหวลินุกซ์ คุณยังสามารถหาสำเนาเก็บถาวร (1994) เดิร์คยังบำรุงรักษาพันธุ์ CVS และแหล่ง libc ใน CVS

CVS ไม่ได้ใช้ในการติดตามข้อบกพร่องในความรู้สึกร่วมสมัยนักพัฒนาบางคนชอบที่จะใช้มันและแพทช์ถูกส่งบ่อยครั้งในรูปแบบของ CVs ที่สร้างความแตกต่าง

1995-1996

ประมาณช่วงเวลานี้ (ต.ค. 2538) David S. Miller เริ่มใช้ CVS สำหรับพอร์ต SPARC ของเคอร์เนล Linux ( พอร์ต Linux / SPARC ) ในเดือนกุมภาพันธ์ 1996 ผู้พัฒนาเคอร์เนลรายอื่นหลายรายใช้ CVS ในการติดตามแพตช์จาก linux-kernel เธรดนี้และนี้เธรดนี้ : Alan Cox, Stephen Tweedie, Kai Henningsen (เธรดที่สองรายงานรัสเนลสันระบุถึงความเกลียดชังมือแรกของ Linus ต่อ CVS)

1997-1998

ในเดือนเมษายนปี 1998 หลังจากเกิดลูกคนที่สองของ Linus ปัญหา CVS ขึ้นมาอีกครั้งจาก linux-kernel ดูหัวข้อย่อยนี้ (Linus ย้ำข้อกังวลของเขาเกี่ยวกับ CVS ที่นั่นโดยตรง)

ในเดือนธันวาคมปี 1997 Andrew Tridgell เปิดตัว jitterbugซึ่งเป็นตัวติดตามบั๊กบนเว็บ เมื่อเดือนมิถุนายน 2541 JitterBug "linux-patches" ได้รับการสนับสนุนบน linux-kernel โดย Alan Coxสนับสนุนบนลินุกซ์เคอร์เนลโดยอลันค็อกซ์นี่คือเท่าที่ฉันสามารถบอกได้ระบบการติดตามบั๊กที่แท้จริงครั้งแรกที่ใช้โดย Linus และผู้พัฒนาที่สำคัญอื่น ๆ น่าเศร้าที่อินสแตนซ์ "linux-patches" ไม่ได้ออนไลน์อีกต่อไป

ในเดือนกันยายนปี 1998 bitkeeper ได้รับการส่งเสริมบน linux-kernelโดย Larry McEvoy

พ.ศ. 2542 และต่อมา

ภายในปี1999/2000 คำถามที่พบบ่อย lkmlเริ่มอ้างอิง (Q 1-16) กับแผนผัง CVS บน (ต้นฉบับ) vger นี่คือการบำรุงรักษาในเวลาโดยแอนดรูว์ Tridgell

ในเดือนธันวาคมปี 2001 โลดโผนได้ลดลงออกจากความโปรดปรานดูลินุกซ์เคอร์เนลนี้ด้าย Linus อลันคอคส์และคนอื่น ๆ อีกหลายคนมีส่วนร่วมในการอภิปรายว่าทำไม

ในเดือนมกราคมปี 2002 Linus เริ่มได้รับความสนใจใน bitkeeper (ทีมเคอร์เนล PowerPC Linux ใช้ไปแล้ว)

ในเดือนกุมภาพันธ์ 2545 Linus เริ่มใช้ Bitkeeperสำหรับต้นไม้แห่งการพัฒนา 2.5

ในเดือน พ.ย. 2002 OSDL เจ้าภาพลินุกซ์ Bugzilla สำหรับต้นไม้ 2.5 ได้มีการประกาศ (ถ้าคุณยังไม่ได้อ่านลิงก์บั๊กซิลล่าในคำถามให้ไปและอ่านมันตอนนี้มันมีพรั่งพรู Linus โบราณ)

ในเมษายน 2005 Linus ประกาศย้ายออกไปจาก BitKeeperรอบเวลาแรกที่เขากล่าวถึงgitโดยใช้ชื่อ ไม่นานหลังจากที่คอมไพล์มีความสามารถในการจัดการโฮสต์ด้วยตนเองแล้วไลนัสก็หยุดใช้ BitKeeper และเริ่มใช้งานคอมไพล์สำหรับเคอร์เนล

ในเดือนธันวาคม 2551 มีการประกาศตัวติดตามการเย็บปะติดปะต่อกันสำหรับเคอร์เนลลินุกซ์ซึ่งเป็นตัวติดตามแพทช์เว็บที่ไม่เชื่อเรื่องพระเจ้า SCCS ซึ่งรวมกับรายการส่งเมลเพื่อติดตามแพตช์และติดตามผล มันยังคงใช้มาจนถึงทุกวันนี้มีรายการประมาณ 40 รายการที่ติดตามด้วยวิธีนี้ในhttps://patchwork.kernel.org/แม้ว่าจะไม่ได้เปิดใช้งานทั้งหมด

อ้างอิง

การอ้างอิงที่มีประโยชน์:

• สาระสำคัญของการทำงานแบบกระจาย: กรณีของเคอร์เนล Linux (Jae Yun Moon, Lee Sproull) http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (พ.ย. 2000)
• แนวทางสำหรับการรายงานข้อบกพร่องของ Linux (กรกฎาคม 1992) http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• คลังข้อมูล Kenneth R. Saborio ของการโพสต์ / อีเมล Linux สำคัญ: http://www.informatica.co.cr/linux/index.htm (1991-2005)
• ไฟล์เก็บถาวรเคอร์เนล linux ตั้งแต่วันนี้ (พ.ย. 2014) ย้อนกลับไปที่ปี 1995 http://lkml.iu.edu/hypermail/linux/kernel/ (น่าเสียดายที่อีเมลฉบับแรกคือจากเดือนมิถุนายน 1995 ที่ผู้ดูแลระบบ Chris Dent ประกาศว่าเขาทำหายไปก่อนหน้านี้ ไฟล์เก็บถาวร ... ) ไฟล์เก็บถาวรLKMLจะย้อนกลับไปในปี 1996
• ชิ้นส่วนจาก linux-devel 1993-1994 จาก tsx11 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux- devel / (ไม่สนใจวันที่ใน URL และไฟล์)
• เครื่องมือการจัดการเวอร์ชัน: CVS ถึง BK ในเคอร์เนล Linux , Sjaikh & Cornford (แคลิฟอร์เนีย 2003)
• ดูเพิ่มเติมที่กระทู้ข่าวแฮ็กเกอร์ (มีนาคม 2558) เป็นวันครบรอบ 10 ปีของการใช้คอมไพล์ git: https://news.ycombinator.com/item?id=9263336

ฉันสามารถบอกได้ว่าการรายงานข้อผิดพลาดได้รับการจัดการเพื่อการพัฒนาgitตัวเองอย่างไร

พวกเขาไม่ได้ใช้ซอฟต์แวร์ติดตามบั๊ก จะมีการรายงานข้อบกพร่องและหารือเกี่ยวกับเมลพัฒนา อาจเป็นเรื่องที่น่าแปลกใจ แต่ก็ใช้ได้ดีมาก

คำถามหรือข้อเสนอที่จะใช้ซอฟต์แวร์ติดตามบั๊กเกิดขึ้นบ่อยครั้งดังนั้นคุณสามารถเรียนรู้มากมายเกี่ยวกับสิ่งนี้ได้จากการค้นหารายการเก็บถาวรจดหมายข่าว git

มันไม่เกี่ยวกับ "เรายังไม่พบตัวติดตามบั๊กที่ดีพอ";
แต่มันก็ไม่เกี่ยวกับ "เรามีวิธีการที่เหนือกว่า" เช่นกัน

ด้วยวิธีการนี้ผู้ดูแลโครงการหรือโครงการย่อย - บางอย่างเช่นนักพัฒนานำ - มีบทบาทสำคัญในฐานะผู้ดูแลอย่างไม่เป็นทางการของรายการพัฒนา
การจัดการข้อบกพร่องเป็นส่วนหนึ่งของมันและดูเหมือนว่าจะไม่ใช่งานที่สำคัญในการจัดการข้อบกพร่องด้วยวิธีนี้ แน่นอนมันขึ้นอยู่กับทักษะของบุคคลในบทบาทนั้น

ส่วนที่เป็นทางการที่สุดของวิธีนี้คือข้อความสรุปสถานะรายสัปดาห์
มันแสดงรายการสิ่งที่เกิดขึ้นในสาขาต่าง ๆ เป็นรายการสั้น ๆ สำหรับตัวอย่างจากการพัฒนาคอมไพล์ดูที่นี่ที่กลุ่มข่าวgmane.comp.version-control.gitทำมิเรอร์รายชื่อผู้รับจดหมาย: มีอะไรทำใน git.git

สิ่งที่ฉันสามารถพูดได้อย่างแน่นอน: ถ้าคุณมีผู้ดูแลที่เก่งในเรื่องนี้มันทำงานได้ดีมาก
ตัวอย่างเช่นฉันจะประหลาดใจมากหากการแนะนำตัวติดตามบั๊กมีผลในเชิงบวกต่อคุณสมบัติและคุณภาพของการใช้งานแม้ในระยะยาวหลังจากการตัดจำหน่ายค่าโสหุ้ยการเปลี่ยนแปลง

สำหรับเคอร์เนลลินุกซ์มันคล้ายกับวิธีการทำ git จนถึงทุกวันนี้
รายการส่งเมล์สำหรับการพัฒนาสำหรับการพัฒนาเคอร์เนลของ Linux นั้นมีความสำคัญอย่างแน่นอน แต่ไม่ใช่รายการเดียวที่เป็นศูนย์กลางเช่นเดียวกับคอมไพล์ มีรายการแยกต่างหากสำหรับหัวข้อย่อยเช่นระบบไฟล์หรือระบบเครือข่าย
เนื่องจากมีหัวข้อแยกต่างหากที่จัดการโดยนักพัฒนาส่วนใหญ่แยกจึงเป็นไปได้ที่บางกลุ่มจะใช้เครื่องมือในกลุ่มของพวกเขา