เกร็ดการรายงานบั๊ก

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

แต่คงจะได้พบรายงานบั๊กที่ไม่ค่อยมีประโยชน์บ่อย ๆ Josselin Mouette นักพัฒนา debian คนหนึ่งจึงได้ blog เกี่ยวกับ เกร็ดการรายงานบั๊กเดเบียน ผมเห็นว่าเป็นเกร็ดที่มีประโยชน์ จึงขอถอดความมาถ่ายทอดต่อ ณ ที่นี้

ถ้า testing มีปัญหา ก็ลอง unstable

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

ขอให้นึกถึงเหตุผลที่ reportbug ต้องตรวจหาแพกเกจรุ่นที่ใหม่กว่าที่อาจจะมีใน unstable แล้ว และโดยทั่วไปแล้ว บั๊กที่คุณพบมักจะถูกแก้ไปแล้วใน unstable เพราะฉะนั้น ถ้าทำได้ก็ขอให้ลองกับรุ่นใน unstable ก่อนที่จะรายงานบั๊ก

รายงานบั๊กกับแพกเกจที่มีปัญหาโดยตรง

"ปัญหานี้เกี่ยวกับการสั่งพิมพ์ในโปรแกรม GNOME เพราะฉะนั้น ผมจึงรายงานปัญหานี้กับ libgnomeprint"

อย่าทำอย่างนั้น ขอให้ รายงานบั๊กกับโปรแกรมที่มีปัญหาโดยตรง ถ้ามีไลบรารีเข้ามาเกี่ยวข้อง reportbug จะส่งข้อมูลที่จำเป็นมาให้ด้วยอยู่แล้ว และผู้ดูแลแพกเกจจะสามารถมอบหมายบั๊กนั้นให้กับไลบรารีที่เกี่ยวข้องได้โดยง่าย ถ้าคุณไม่แน่ใจว่าเป็นปัญหาของแพกเกจไหน ก็อาจจะรายงานกับ metapackage ไปเลย (เช่น สำหรับ GNOME ก็รายงานบั๊กกับแพกเกจ gnome)

อย่าพยายามเดาหลายชั้นว่าสาเหตุจะมาจากไหน

"หลังจากอัปเกรด libfoo แล้ว bar ก็เริ่มพัง เพราะฉะนั้น ผมจึงรายงานบั๊กกับ libfoo"

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

อย่าลืมอธิบายด้วยว่าสิ่งที่เป็นปัญหาคืออะไร

"frobniz ใน libfrob พัง คุณควรจะเปลี่ยน /usr/share/libfrob/blah บรรทัดที่ 13 ให้เป็นอีกแบบหนึ่ง ผมไม่รู้ว่า libfrob มันคืออะไร แต่ผมมีปัญหาที่คิดว่าเกี่ยวกับ frobniz"

อย่าพยายามเดาหลายชั้น ขอให้เริ่มจากอธิบายปัญหาที่คุณพบเสียก่อน สิ่งที่คุณพยายามตรวจสอบอาจจะน่าสนใจ แต่อย่าลืมอธิบายว่าปัญหาอะไรที่ทำให้คุณเริ่มตรวจสอบ

การใช้งานกรณีไหนที่เราควรรองรับ?

"ผมพยายามทำสิ่งนั้นกับแพกเกจของคุณ แต่ท่าทางมันจะซับซ้อนเอามาก ๆ / มันไม่ทำงานอย่างที่คิด / มันทำงานผิดอย่างน่าอนาถ แพกเกจของคุณมันห่วยแตก!"

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

ในสถานการณ์แบบนี้ ขอให้ระบุในรายงานด้วย ว่าคุณต้องการจะทำ อะไร และ ทำไม ถึงต้องการทำเช่นนั้น

strace ไม่ใช่เครื่องมือดีบั๊กครอบจักรวาล

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

สำหรับกรณีเฉพาะบางกรณีที่ต้องใช้ strace ช่วยในการดีบั๊ก เรายินดีรับเบาะแสที่ว่านี้ แต่ถ้าคุณไม่แน่ใจ ก็ขออย่าได้แนบมา นักพัฒนาจะขอจากคุณเอง หรือมิฉะนั้น เครื่องมือดีบั๊กสำหรับกรณีทั่วไปก็คือ gdb

ใช้ reportbug

มีเหตุผลที่ดีมากมายที่ทำไมบางแพกเกจจึงมีแฟ้มควบคุมการรายงานบั๊กมาด้วย คุณควรใช้เครื่องมือรายงานบั๊กที่ทำตามข้อมูลเหล่านี้ คือ reportbug ยกเว้นในกรณีที่คุณแค่จะขอฟีเจอร์เพิ่มเติม กรุณาหลีกเลี่ยง reportbug-ng เพราะมันจะให้ข้อมูลที่ต้องการมาไม่ครบ

ที่มา: blog ของ Josselin Mouette

Topic: 
Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้