DebConf11 Day 3: Rolling, Multiarch, TDD

DebConf11 วันที่ 3 ที่ผมเข้าฟังก็มีเรื่อง พบ Release Team, พบ Debian Sysadmins (DSA), Rolling BoF, Packaging with Git, Multiarch, Test-Driven Development

เรื่องที่เป็นประเด็นน่าสนใจของวันนี้คงอยู่ที่ rolling release, multiarch support และ test-driven development ซึ่งเป็นเรื่องใหม่ที่มีการเสนอเข้า Debian ในรุ่น Wheezy นี้

สำหรับ CUT และ rolling release นี้ release team บอกว่าไม่มีปัญหา แต่อย่าให้ release team ต้องทำงานหนักขึ้นเป็นพอ ใน BoF นั้น Raphael Hertzog ได้เริ่มจากการพูดถึงจุดมุ่งหมายของ rolling release ว่าเป็นการเจาะกลุ่มผู้ใช้เดสก์ท็อปทั่วไป ไม่ใช่สำหรับผู้ใช้เซิร์ฟเวอร์ ซึ่งหมายความว่า สถาปัตยกรรมที่จะมีการใช้งานจริง ๆ อาจจะเหลือแค่ i386, amd64, armel ก็ได้

คำถามถัดมาคือ สามารถใช้ testing เป็น rolling ได้เลยไหม?

• testing นั้นมีการอัปเดตสม่ำเสมอแน่ละ แต่มัน usable อย่างสม่ำเสมอด้วยหรือเปล่า?
• เราพร้อมจะรองรับผู้ใช้ testing เต็มที่จริง ๆ หรือเปล่า? นี่ต้องเป็นภาระของ maintainer ทั้งหลายที่เพิ่มขึ้น
• เราพร้อมจะแก้บั๊กให้แบบทันเหตุการณ์ได้หรือเปล่า? (โดยปกติ การอัปโหลดแพกเกจจะเอาขึ้นที่ unstable รอจนกระทั่ง ๑๐ วันผ่านไปโดยไม่มีบั๊กร้ายแรงจึงจะผ่านเข้า testing ยกเว้น security bug จึงจะมีการอัปโหลดเข้า testing แบบทันทีทันใด และถ้าเป็นกรณี migration เป็นชุดจะใช้เวลานานขึ้นอีก เพราะต้องรอ migrate พร้อมกัน)
• มี installer ที่ดีหรือเปล่า? (โครงการ CUT จะทำ installer ที่ใช้การได้อย่างสม่ำเสมอสำหรับ testing)

จากการสอบถามคำถาม ๓ ข้อ คือ

1. testing usable ไหม?
2. Debian ควรรับรองให้ผู้ใช้ใช้ testing อย่างเป็นทางการไหม?
3. เราพร้อมจะ support ผู้ใช้ testing อย่างเต็มที่ไหม?

คำตอบของ DD ส่วนใหญ่จะตอบ yes ในข้อแรก แล้ว yes น้อยลงเรื่อย ๆ ในข้อหลัง ๆ

ผมคิดว่าความเห็นส่วนใหญ่จะเป็นว่า stable นั้นเก่าเกินไปสำหรับผู้ใช้เดสก์ท็อป ส่วน unstable ก็ต้องอาศัยประสบการณ์พอสมควรในการดูแลระบบ จะมี testing ที่อยู่กลาง ๆ และแนะนำให้ผู้ใช้เดสก์ท็อปมือใหม่ใช้ แต่ถ้าจะถึงกับประกาศให้ใช้เป็นทางการนั้น จะต้องมีการปรับเปลี่ยนระบบการทำงานพอสมควร ซึ่งเมื่อเปรียบเทียบข้อดีข้อเสียแล้ว DD หลายคนจึงเลือกตอบ no มากกว่า แม้การใช้ testing ปัจจุบันก็ไม่ได้ส่งผลเสียอะไรขนาดนั้น (DD บางคนถึงกับบอกว่า unstable + apt-listbugs นั่นแหละดีที่สุดแล้ว)

ในอีกทางหนึ่ง ก็มี DD บางคนได้ทำงานล่วงหน้าไปแล้วเพื่อทดลองกระบวนการต่าง ๆ ที่จะใช้กับ rolling

คำถามถัดมาคือ แล้วจะทำอย่างไรให้ rolling นั้น rolling ต่อไปเรื่อย ๆ โดยเฉพาะในช่วง freeze? ก็มีแนวทางอย่างน้อย ๒ แนวทาง:

• ทำ symlink ให้ rolling == testing ในช่วงปกติ แล้ว fork rolling ในช่วง freeze
  • DD ต้องแยกสมาธิดูแลทั้ง testing และ rolling แยกกันในช่วง freeze อาจทำให้ออก stable ช้าลงไปอีก
• ทำ rolling แยกต่างหากเลย
  • สามารถสร้างกฎใหม่ ๆ ได้
  • อาจเป็นอุปสรรคต่อการออก stable มากขึ้นไปอีก?

ครั้งนี้เป็นการระดมสมอง ยังไม่มีการตัดสินใจอย่างใด

ข้ามมาที่เรื่อง Multiarch ซึ่งหัวเรี่ยวหัวแรงคือ Steve Langasek เล่าว่า เริ่มมีแนวคิดนี้มาตั้งแต่ปี 2009 ที่ Barcelona จนกระทั่งเริ่ม implement ครั้งแรกใน Ubuntu 11.04 เพียงไม่กี่แพกเกจ เพียงเพื่อให้สามารถติดตั้ง flash plugin แบบ i386 บน amd64 ได้เท่านั้น แล้วจึงมาเริ่มทำใน Debian ในรุ่น Wheezy นี้ โดยทยอยแก้ไขไลบรารีต่าง ๆ ให้รองรับ multiarch ทั้งระบบ ซึ่งเป็นการย้ายขนานใหญ่กว่าใน Ubuntu มาก

สิ่งที่ Steve ได้เรียนรู้จากการผลักดันครั้งนี้คือ:

• เอกสารประกอบนั้นสำคัญมาก ไม่ใช่แค่แก้ policy แล้วก็จบ แต่ต้องมีเอกสารสรุปให้ทุกคนทำตามได้โดยสะดวกด้วย
• แบ่งงานเป็นส่วน ๆ ทำไปทีละส่วน เพราะไลบรารีต่าง ๆ มีความสัมพันธ์กันเป็นชุด ๆ
• ไม่มีอะไรที่จะคงอยู่ถาวรไปกว่าวิธีแก้แบบชั่วคราวอีกแล้ว (Nothing is so permanent as temporary solution.) ดังนั้น อย่าคิดแต่ว่าจะแก้แบบชั่วคราวไปก่อน

สิ่งที่เราจะได้จากการรองรับ multiarch คือ:

• สภาพแวดล้อมสำหรับการจำลองเครื่องต่าง ๆ แบบทันทีทันใด ไม่ต้องไปอาศัย chroot อีกแล้ว
• การคอมไพล์ข้ามสถาปัตยกรรม (cross-compilation) ไม่ใช่เรื่องยากอีกต่อไป (Steve สาธิตการคอมไพล์แพกเกจสำหรับ arm โดยไม่ต้องใช้ chroot ไม่ต้องติดตั้งอะไรพิเศษ เสร็จในเวลาอันรวดเร็ว)
• การปรับระบบข้ามสถาปัตยกรรม (cross-grading) ทำได้ทันทีโดยไม่ต้องเริ่มติดตั้งใหม่ เช่น จาก arm เป็น armel, จาก i386 เป็น amd64, จาก armel เป็น armhf
• รองรับซอฟต์แวร์ที่แจกจ่ายแบบไบนารีอย่างเดียว (เช่น Adobe flash player) ได้ดีขึ้น

ส่วนเรื่องสุดท้าย คือ test-driven developement นั้น เริ่มจากสรุประบบการทดสอบคุณภาพที่ Debian มีอยู่แล้ว เช่น archive rebuild (จับบั๊ก FTBFS), lintian, piuparts, auto-REJECT ที่ ftp-master, การทดสอบแพกเกจขณะคอมไพล์ (make check), การทดสอบการเชื่อมรวม (EDOS), การวิเคราะห์ซอร์สโค้ดแบบอัตโนมัติ (CADA)

จากนั้นก็เป็นการสอบถามทุกคน ว่ายังมีการทดสอบแบบใดอีกไหมที่ตนเองทำอยู่ เผื่อจะนำมาใช้ใน Debian โดยรวมต่อไป

รายละเอียดขอจบเพียงเท่านี้ เนื่องจากเวลาในการเขียน blog หมดลงแล้ว..