การพัฒนา kernel ของ Linux อีกครั้งหนึ่งได้เน้นย้ำถึงมาตรฐานที่เข้มงวดซึ่งควบคุมหนึ่งในโปรเจกต์โอเพนซอร์สที่สำคัญที่สุดของโลก ความขัดแย้งล่าสุดมีจุดศูนย์กลางอยู่ที่การส่งโค้ดที่ถูกปฏิเสธสำหรับการสนับสนุนสถาปัตยกรรม RISC-V ซึ่งแสดงให้เห็นว่าเวลา คุณภาพของโค้ด และการตัดสินใจเชิงสถาปัตยกรรมมาบรรจบกันในการพัฒนา kernel อย่างไร
การส่งล่าช้าก่อให้เกิดการตอบสนองอย่างรุนแรง
เหตุการณ์เริ่มต้นเมื่อ Palmer Dabbelt วิศวกรซอฟต์แวร์ที่ Meta (เดิมชื่อ Facebook) ส่งชุด patches ของ RISC-V สำหรับช่วง merge window ของ Linux 6.17 เวลาที่ส่งกลับกลายเป็นปัญหาเป็นพิเศษ เนื่องจาก Linus Torvalds เคยเตือนนักพัฒนาล่วงหน้าเกี่ยวกับตารางการเดินทางที่กำลังจะมาถึงเนื่องจากกิจกรรมครอบครัวทั่ว สหรัฐอเมริกา และ ฟินแลนด์ Torvalds ได้ขอให้ส่งเร็วอย่างชัดเจนและเตือนว่า pull requests ที่ส่งล่าช้าจะต้องเผชิญกับการตรวจสอบที่เข้มงวดมากขึ้นในช่วงเวลานี้
บริบทไทม์ไลน์:
- ความขัดแย้งด้านเวลาของ merge window ของ Linux 6.17 กับกิจกรรมครอบครัวของ Torvalds
- Torvalds เดินทางไปงานแต่งงานและงานฉลองวันเกิดใน US และ Finland
- การปรับปรุง RISC-V ถูกเลื่อนไปยังรอบการพัฒนา Linux 6.18
ปัญหาทางเทคนิคนอกเหนือจากการส่งล่าช้า
แม้ว่าการส่งล่าช้าจะดึงดูดการวิพากษ์วิจารณ์ในตอนแรก แต่ปัญหาทางเทคนิคที่ลึกซึ้งกว่านั้นได้เผยออกมาเมื่อมีการทบทวน patch นี้รวมถึงการแก้ไขไฟล์ header ทั่วไปของ Linux แทนที่จะจำกัดการเปลี่ยนแปลงไว้ที่โค้ดเฉพาะ RISC-V การตัดสินใจเชิงสถาปัตยกรรมนี้ทำให้เกิดความกังวลเกี่ยวกับผลกระทบที่อาจเกิดขึ้นต่อส่วนประกอบ kernel ที่ไม่เกี่ยวข้องและความเสถียรของระบบโดยรวม
ฟังก์ชัน Helper ที่ก่อให้เกิดความขัดแย้งดึงดูดการวิจารณ์อย่างรุนแรง
องค์ประกอบที่ก่อให้เกิดความขัดแย้งมากที่สุดเกี่ยวข้องกับฟังก์ชัน helper ที่เรียกว่า make_u32_from_two_u16() ซึ่งออกแบบมาเพื่อรวม unsigned 16-bit integers สองตัวเข้าเป็น 32-bit integer หนึ่งตัว Torvalds อธิบายฟังก์ชันนี้ว่าบ้าและไร้จุดหมาย โดยให้เหตุผลว่ามันทำให้การเรียงลำดับข้อมูลคลุมเครือและเพิ่มความซับซ้อนที่ไม่จำเป็น เขายืนยันว่าฟังก์ชันนี้ทำให้โค้ดเข้าใจได้น้อยลงและทำลายคุณภาพของ codebase อย่างแข็งขัน
ปัญหาทางเทคนิคหลักที่ระบุ:
- ฟังก์ชันช่วย
make_u32_from_two_u16()ถือว่าไม่จำเป็นและสร้างความสับสน - การแก้ไขไฟล์ header แบบทั่วไปแทนที่จะเป็นการเปลี่ยนแปลงเฉพาะ RISC-V
- การส่งงานล่าช้าในช่วง merge window แม้จะมีการเตือนล่วงหน้า
- ผลกระทบเชิงลบที่อาจเกิดขึ้นต่อส่วนประกอบอื่นๆ ของ kernel ที่ไม่เกี่ยวข้อง
 |
|---|
| Linus Torvalds แสดงความกังวลเกี่ยวกับการออกแบบที่ซับซ้อนของฟังก์ชันช่วยเหลือใน RISC-V patches ที่ถูกปฏิเสธ |
ความกังวลเรื่องการปนเปื้อนไฟล์ Header ทั่วไป
การตัดสินใจที่จะวางฟังก์ชันการทำงานเฉพาะ RISC-V ในไฟล์ header ทั่วไปทำให้ Torvalds หงุดหงิดเป็นพิเศษ เขาเน้นว่าแนวปฏิบัติดังกล่าวอาจส่งผลกระทบเชิงลบต่อระบบนิเวศ Linux ที่กว้างขึ้นโดยการบังคับให้โค้ดที่ไม่เกี่ยวข้องต้องรองรับความต้องการเฉพาะสถาปัตยกรรม แนวทางนี้ละเมิดหลักการพัฒนา kernel ที่ยอมรับแล้วซึ่งให้ความสำคัญกับการแยกที่สะอาดระหว่างส่วนประกอบทั่วไปและเฉพาะสถาปัตยกรรม
กำหนดความคาดหวังที่ชัดเจนสำหรับการส่งในอนาคต
หลังจากการปฏิเสธ Torvalds ได้ออกแนวทางเฉพาะสำหรับการมีส่วนร่วมในอนาคต เขาบังคับให้การส่งมุ่งเน้นเฉพาะการเปลี่ยนแปลงเฉพาะสถาปัตยกรรมเว้นแต่จะมีเหตุผลที่น่าเชื่อถือสำหรับการแก้ไขทั่วไป การเปลี่ยนแปลงทั่วไปใดๆ ต้องแสดงให้เห็นถึงประโยชน์ที่ชัดเจนและมาถึงก่อนกำหนดเวลาเป็นอย่างดี คำสั่งนี้ทำหน้าที่เป็นทั้งคำเตือนสำหรับผู้มีส่วนร่วมโดยตรงและแนวทางสำหรับชุมชนนักพัฒนาที่กว้างขึ้น
การตอบสนองของนักพัฒนาและปฏิกิริยาของชุมชน
Dabbelt รับทราบข้อเสนอแนะและมุ่งมั่นที่จะปรับปรุงทั้งเวลาการส่งและคุณภาพของโค้ดสำหรับการมีส่วนร่วมในอนาคต การแลกเปลี่ยนนี้จุดประกายปฏิกิริยาที่หลากหลายภายในชุมชนนักพัฒนา โดยบางคนปกป้องแนวทางตรงไปตรงมาของ Torvalds ว่าจำเป็นสำหรับการรักษามาตรฐานโปรเจกต์ ในขณะที่คนอื่นๆ ตั้งคำถามว่าน้ำเสียงดังกล่าวมีประโยชน์เชิงสร้างสรรค์หรือไม่
วิวัฒนาการของสไตล์ความเป็นผู้นำ
เหตุการณ์นี้สะท้อนแนวทางความเป็นผู้นำที่พัฒนาแล้วแต่ยังคงเรียกร้องของ Torvalds แม้ว่าสไตล์การสื่อสารของเขาจะปรับตัวลงตั้งแต่คำมั่นสัญญาในปี 2018 ที่จะปรับปรุงการปฏิสัมพันธ์กับนักพัฒนา แต่เขายังคงรักษามาตรฐานที่ไม่ยอมประนีประนอมสำหรับคุณภาพโค้ดและโปรโตคอลการส่ง สมดุลระหว่างการดำเนินการอย่างมืออาชีพและความเข้มงวดทางเทคนิคนี้ยังคงหล่อหลอมวัฒนธรรมการพัฒนา kernel ของ Linux
 |
|---|
| Linus Torvalds ยังคงกำหนดมาตรฐานสูงสำหรับคุณภาพโค้ดและการปฏิสัมพันธ์ภายในชุมชนนักพัฒนา Linux kernel |
มองไปข้างหน้าสู่ Linux 6.18
การปรับปรุง RISC-V ที่ถูกปฏิเสธจะต้องรอวงจรการพัฒนา Linux 6.18 หากพวกเขาแก้ไขความกังวลที่ระบุและมาถึงภายในกรอบเวลาที่เหมาะสม ความล่าช้านี้เน้นย้ำว่าการพัฒนา kernel ให้ความสำคัญกับความเสถียรระยะยาวและคุณภาพโค้ดมากกว่าการเพิ่มฟีเจอร์ทันที แม้ว่าการมีส่วนร่วมจะมาจากบริษัทเทคโนโลยีใหญ่ก็ตาม