DebConf11 Day 2: DPL, QA

DebConf11 วันที่สอง เป็นการเริ่มเข้าสู่โหมด conference อย่างแท้จริง เนื้อหาจะเริ่มเจาะกลุ่ม contributor ทั้งหลาย

เริ่มจาก เจ้าภาพมาเล่าถึงที่มาที่ไปของการจัด DebConf ที่บอสเนียในครั้งนี้ แม่งานของทางเจ้าภาพ คือ Adnan Hodzic ประธานกลุ่ม NVO DIVA เริ่มมีแนวคิดจะจัด DebConf ที่บอสเนียมาตั้งแต่ DebConf 7 และการเสนอตัวนั้น ทางเจ้าภาพก็ยังไม่คาดคิดว่าจะได้จัด แต่ก็พยายามผลักดันเต็มที่ โดยเข้าหารัฐบาล จนหน่วยงานของรัฐเห็นชอบ หลังจากนั้นรัฐบาลก็เป็นฝ่ายสนับสนุนออกเงินทุนให้ทุกอย่าง ดังจะเห็นได้จากพิธีเปิดในวันแรก มีคนระดับสูงของรัฐบาลมากล่าวเปิดงานหลายคน ตั้งแต่ระดับรัฐมนตรีลงมา

ทีมเจ้าภาพทำงานร่วมกับทีมจัดงานของเดเบียนอย่างใกล้ชิด เข้าไปคุยกับรัฐบาลด้วยกัน ทรงผมของ Holger ไม่เป็นอุปสรรคต่อการเข้าพบรัฐมนตรี หลังจากที่ Adnan convince รัฐบาลได้แล้ว

ผมเองยอมรับว่าทีมเจ้าภาพทำงานแข็งขันมาก เอาแค่เรื่องวีซ่าของผู้เข้าร่วมงานก็ต้องเตรียมการอย่างดี ตามแก้ปัญหาต่าง ๆ อย่างกรณีของผมเป็นต้น ซึ่งเขาทำงานได้ไม่ขาดตกบกพร่อง

ถัดมาเป็น session แรกของ DPL (Stefano Zacchiroli) พูดถึงจุดแข็งจุดอ่อนของ Debian และแนวทางของโครงการที่จะทำต่อไป

ในช่วงแรก ๆ หลังการก่อตั้ง Debian นั้น มี distro ไม่หลากหลาย Debian จึงมีจุดเด่นชัดเจน แต่ทุกวันนี้มี distro มากมายมหาศาล แล้วอะไรที่ยังเป็นความพิเศษของ Debian อยู่?

• คุณภาพ (quality) Debian มีวัฒนธรรมของความเป็นเลิศทางเทคนิค มีตั้งแต่ policy ที่แน่นหนา มีเครื่องมือควบคุมคุณภาพอย่าง lintian, piuparts, การ rebuild แพกเกจทั้ง archive เพื่อตรวจสอบบั๊กประเภท FTBFS (Fails-To-Build-From-Source) เป็นระยะ โดยทุกแพกเกจได้รับการตรวจสอบเท่าเทียมกันหมด ผู้ดูแลแพกเกจล้วนแต่เป็นผู้เชี่ยวชาญด้านซอฟต์แวร์ และที่สำคัญคือนโยบาย we release when it's ready
• เสรีภาพ (freedom) Debian ได้ส่งเสริมวัฒนธรรมซอฟต์แวร์เสรีอย่างแข็งขันมาตั้งแต่ปี 1993 ทุกอย่างใน Debian เป็นซอฟต์แวร์เสรีทั้งหมด ตั้งแต่ตัวซอฟต์แวร์เอง, โครงสร้างพื้นฐานที่ใช้ดำเนินโครงการ, และความเปิดกว้างในกระบวนการทำงาน สิ่งที่บุคคลภายนอกรับรู้คือ Debian ไม่ทรยศต่ออุดมการณ์ซอฟต์แวร์เสรีเด็ดขาด และยังมีมาตรฐานสูงในเรื่องการส่งเสริมเสรีภาพด้วย
• ความเป็นอิสระ (independence) Debian อยู่ได้ด้วยการทำงานของอาสาสมัครล้วน ๆ ไม่มีโครงสร้างแบบบริษัทหรือลำดับชั้นการบริหารงาน ไม่มีบริษัทใดบริษัทหนึ่งคอยค้ำจุนหรือชี้นำได้ แต่อยู่ได้ด้วยการบริจาค (ทั้งในรูปตัวเงินและฮาร์ดแวร์) และวัฒนธรรมการให้
• กระบวนการตัดสินใจ (decision making) มีสองส่วน คือ do-ocracy และ democracy โดย do-ocracy คือการให้อำนาจตัดสินใจกับคนที่ลงมือทำ ส่วน democracy คือการใช้เสียงส่วนใหญ่ของชุมชนตัดสินปัญหา do-ocracy มักใช้กับงานทางเทคนิค และ democracy มักใช้กับสิ่งที่นอกเหนือจากนั้น ซึ่งผลของ do-ocracy คือ เครดิตจะติดตัวคนทำไปด้วย
• งานปลายน้ำ (derivatives) Debian เป็นต้นน้ำให้กับ distro ปลายน้ำที่ยัง active อยู่ประมาณ 130 distro ซึ่ง distro เหล่านี้ยังคงใช้ประโยชน์จาก Debian และพึ่งพา Debian อยู่ (แม้ผู้ใช้จำนวนมากจะไม่ทราบก็ตาม) ถ้า Debian ทำงานผิดพลาด จะมีคนเดือดร้อนจำนวนมาก

เหล่านี้คือจุดแข็งของ Debian แต่จุดแข็งเหล่านี้ก็สามารถย้อนกลับมาเป็นอุปสรรคได้เช่นกัน

• ขาดคน? ปีที่แล้ว คน Debian บ่นกันมากว่า Debian ขาดคนทำงาน แต่ถ้าดูสถิติปีนี้ก็จะเห็นว่าสามารถดึงดูดคนเข้าร่วมได้มากพอสมควร (DD เพิ่มขึ้น 25 คน, DM เพิ่มขึ้น 30 คน ปัจจุบันมี DD 911 คน และ DM อีก 149 คน)
• คุณภาพ? การทำงานที่มีคุณภาพนั้นใช้เวลานาน แต่จากสถิติ เราก็ทำได้ดีขึ้น (etch ใช้เวลา 22 เดือน, lenny 22 เดือน, squeeze 24 เดือน ในขณะที่ยังต่ำกว่าเวลาเฉลี่ยคือ 25 เดือน) แนวทางที่จะทำคือ ใช้นโยบาย time-based freeze, ใช้กระบวนการ release ที่ทุกคนต้องร่วมกันรับผิดชอบ (ไม่ใช่ดูแค่แพกเกจของตัวเอง), รวมทั้งการเสนอ trade-off อย่าง CUT หรือ rolling
• เสรีภาพ? การตั้งมาตรฐานสูงเรื่องเสรีภาพจะเป็นอุปสรรคไหม? คำตอบสั้น ๆ คือ ไม่ โดยมีวงเล็บต่อท้ายว่า (Well, maybe, but it's not negotiable) (ได้รับเสียงปรบมือเกรียวกราวในห้องประชุม)
• ความเป็นอิสระและ do-ocracy? ข้อเสียคือเรื่องนี้กระตุ้นได้แต่งานทางเทคนิค ไม่สามารถกระตุ้นการทำงานอย่างอื่นที่ไม่ geek ได้ เช่น งานเอกสาร งานตรวจสอบ งานบริหาร งานประชาสัมพันธ์ งานบัญชี งานด้านกฎหมาย ฯลฯ แต่งานเหล่านี้ก็ขาดเสียมิได้ มิฉะนั้นพวก geek ก็ hack กันไม่ถนัดเหมือนกัน แนวทางที่ควรทำคือ ให้การยอมรับงานเหล่านี้มากขึ้น เปิดรับผู้เข้าร่วมด้านต่าง ๆ มากขึ้น รวมทั้งทุกคนเองก็ต้องพร้อมอาสาเข้ามาทำด้วย
• democracy? แน่นอนว่าการใช้ประชาธิปไตยจะทำให้เกิดความล่าช้าโดยธรรมชาติ เพราะจะต้องมีคนบางส่วนที่ไม่เห็นด้วยและอภิปรายคัดค้าน แต่ก็ต้องเข้าใจว่า ประชามติ (concensus) กับ เอกฉันท์ (unanimity) เป็นคนละเรื่องกัน และแม้เราจะใช้ทั้ง democracy และ do-ocracy แต่ถ้าจะต้องการให้อะไรเกิดขึ้นก็ต้องลงมือทำ! แนวทางที่ควรทำคือ สนับสนุนเทคโนโลยีที่ทำให้เกิดการ fork ได้ เช่น PPA, test-driven development ซึ่งได้มีการเสนอใน Debian กันอยู่
• งานปลายน้ำ? distro ปลายน้ำบางครั้งก็เป็นอุปสรรคได้ ถ้าเขาลดทอนอุดมคติของเราลง แต่ในขณะเดียวกัน งานปลายน้ำก็อาจเป็นผลดีได้ เพราะเขาช่วยเจาะกลุ่มผู้ใช้กลุ่มต่าง ๆ ให้ โดยสิ่งที่จะเป็นผลดีกับทุกคน คือการสมทบงานกลับไปสู่ต้นน้ำ แนวทางที่ควรทำคือ ส่งเสริมการทำงานร่วมกันระหว่างงานปลายน้ำและต้นน้ำ, พยายามอธิบายแนวคิดของ Debian ให้กับผู้เข้าร่วมต่าง ๆ ได้รับทราบ, เผยแพร่วัฒนธรรมการตอบแทนกลับคืนสู่ชุมชน (give-back) ของ Debian ตาม Social Contract ข้อ 2

ข้อสรุปคือ:

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

ถัดจากนั้น อ.กิตติ์กับผมได้แยกไปฟังกันคนละห้อง อ.กิตติ์อยู่ในห้องประชุมใหญ่ ผมไปฟังห้องเล็ก

ห้องเล็กวันนี้ เนื้อหาเป็นเรื่องของการควบคุมคุณภาพ (QA) ใน Debian

เรื่องแรกคือ มีการเสนอมาตรการกลั่นกรองคุณภาพซอฟต์แวร์ที่จะเข้าสู่ Debian โดยปัจจุบัน Debian มีซอฟต์แวร์หลากหลายมาก ซอฟต์แวร์บางตัวเขียนโค้ดยุ่งเหยิง แก้บั๊กยาก ควรจะให้เข้า Debian หรือไม่? โดยมีการเสนอมาตรการการให้คะแนนคุณภาพซอฟต์แวร์ไว้ดังนี้:

• ไม่มีขีดกำหนดตายตัว คะแนนรวมจะเป็นตัวเลขบอกระดับคุณภาพเท่านั้น ไม่มีขีดขั้นว่าเท่าไรจึงจะผ่านเกณฑ์ แต่จะอาศัยความกดดันทางสังคมเป็นหลัก
• uniqueness คือถ้าซอฟต์แวร์นั้นไม่มีซอฟต์แวร์ทดแทนอื่นแล้ว ก็จำเป็นต้องให้คะแนนไว้ แม้คุณภาพโค้ดจะไม่ดีก็ตาม เพื่อให้คง feature ไว้
• ตำแหน่งใน dependency tree ถ้าซอฟต์แวร์นั้นมีแพกเกจอื่น depend อยู่มาก ก็จำเป็นต้องให้คะแนนไว้เช่นกัน
• สถิติ popcon ถ้ามีผู้ใช้เยอะ ก็ให้คะแนนสูง
• ข้อมูลใน UDD เกี่ยวกับจำนวนบั๊ก ความสม่ำเสมอในการดูแลแพกเกจ
• จำนวนรูโหว่ที่พบ โดยนับเป็นจำนวน CVE-ID ต่อ LOC
• ปริมาณ comment โดยคิดสัดส่วนต่อ LOC (ใช้ ohcount)

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

เรื่องอื่น ๆ ที่เสนอคือ อาจให้ ITP ต้องมี DD รับรอง 2 คนไหม? DD อาจทำ peer-review กันเองผ่าน mentors ด้วยดีไหม นอกเหนือจากการ mentor sponsoree?

เรื่องที่สองเป็นสถานะของ Ruby ใน Debian โดยได้พูดถึงอุปสรรคต่าง ๆ ที่ผ่านมาและการแก้ไข

อุปสรรคหลักคือ Ruby พัฒนาโดยคนญี่ปุ่น เมลลิงลิสต์ที่นักพัฒนาคุยกันจะใช้ภาษาญี่ปุ่นเป็นหลัก ทำให้เข้าร่วมได้ยาก นอกจากนี้ Ruby ยังมีระบบแพกเกจของตัวเอง คือ RVM และ Rubygems และไม่ยอมรับระบบแพกเกจของ distro ทำให้เกิดความไม่ลงรอยกันกับทีม Debian แต่ทีม Debian ก็ได้กำจัดข้อเสียต่าง ๆ ใน Debian จนกระทั่งได้รับการยอมรับแล้ว และได้สร้างเครื่องมือ gem2deb เพื่อแปลงแพกเกจ Rubygems ให้เป็น source package ของ Debian และได้ทยอยแปลงแพกเกจใน Debian ให้ใช้รูปแบบใหม่นี้ไปเรื่อย ๆ ทีละส่วน

นอกจากนี้ก็ได้พูดถึงเป้าหมายของ Wheezy ว่าอาจจะใช้ Ruby 1.9.3 มี Jruby ใน non-free ส่วน Rubidious นั้นอยู่ระหว่าง ITP ในโหมดที่เรียกว่า cookie-licking (หมายความว่า เจ้าของบั๊กบอกว่ากำลังทำ ๆ มาเป็นเวลานาน แต่ไม่มีความคืบหน้า คนอื่นจะเข้าไปทำก็ไม่กล้า เปรียบเหมือนการเลียคุกกี้แต่ไม่กิน คนอื่นจะกินก็ไม่กล้าหยิบ)

เรื่องถัดจากนั้นก็เป็นการประชุม BoF (Birds of a Feather: การประชุมระดมสมอง) ในกลุ่ม QA, Lintian และ Piuparts (อ่านว่า พิวพาร์ทส์) ซึ่งรายละเอียดขอละไว้ก่อน เนื่องจาก blog ยาวมากแล้ว และคนเขียนกำลังหิวข้าว :-P