Theppitak's blog

My personal blog.

26 กรกฎาคม 2554

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

ป้ายกำกับ: ,

2 ความเห็น:

  • 26 กรกฎาคม 2554 13:32 , Blogger Revolution Log Life Another Dimension แถลง…

    พุดถึงเรื่อง ruby กับ distro ต่างๆจะเห็นได้ชัดเลยว่ามันมีความหลากหลายทาง version แค่นักพัฒนาเองยังมีบางคนใช้ 1.8 บางคนใช้ 1.9 บางคนใช้ jruby อีก

    ส่วน gem2deb ผมคิดว่าคงได้เฉพาะ version MRI ที่เขียนด้วย C เท่านั้นมั้งครับ

    แต่ยอมรับว่า debian กับงาน desktop นี่ต้องออกแรงเยอะกว่า ubuntu แต่สำหรับงาน server นี่เข้าขั้นรักหัวปักหัวปรำ

     
  • 27 กรกฎาคม 2554 13:41 , Blogger Thep แถลง…

    เรื่อง ruby นี่ผมไม่มีความรู้เลยครับ แต่ที่ฟังมา เขาไม่ได้พูดถึงข้อจำกัดของ gem2deb ครับ จากวิธีการ convert ก็จะเป็นการแปลงจาก rubygem เป็น debian source package ก่อน แล้วจึง build deb ตามปกติ ไม่ใช่เป็น binary โดยตรง

    เรื่องงาน desktop ต้องบอกว่าจุดประสงค์เริ่มแรกของ Debian ก็ต้องการให้เป็น universal ไว้ก่อนอยู่แล้วครับ แล้วไปส่งเสริม derivative distro ให้ customize กันเอง เพียงแต่พอเกิด derivative อย่าง Ubuntu ที่ค่อนข้างจะแข่งขันกับต้นน้ำในมุมมองของผู้ใช้ ทำให้ contribution ต่าง ๆ กลับมาไม่ถึง Debian ทั้งหมด ทำให้ Debian ต้องออกมาส่งเสริมการทำงานร่วมกันให้มากขึ้น

     

แสดงความเห็น (มีการกลั่นกรองสำหรับ blog ที่เก่ากว่า 14 วัน)

<< กลับหน้าแรก

hacker emblem