1 ปีหลังจาก Guix ย้ายไป Codeberg

• Guix ย้ายรูปแบบการทำงานร่วมกันที่ใช้งาน Savannah และ Debbugs แบบอีเมลมานานกว่า 10 ปีไปยัง Codeberg ในปี 2025 ทำให้ จุดเริ่มต้นการมีส่วนร่วม ของโครงการที่มีผู้เข้าร่วมมากกว่า 400 คนต่อปีเปลี่ยนไปอย่างมาก
• การเปลี่ยนผ่านครั้งนี้เป็นกรณีใช้งานจริงครั้งแรกของกระบวนการ Guix Consensus Document ที่เริ่มใช้ในเดือนธันวาคม 2024 และ GCD 002 มีผลบังคับใช้ในต้นเดือนพฤษภาคม 2025 หลังจากหารือกันนานสองเดือน
• เวิร์กโฟลว์แบบอีเมลเดิมมีประสิทธิภาพสำหรับผู้ชำนาญ เพราะมีเครื่องมืออย่าง Emacs, mumi และ qa.guix.gnu.org รองรับ แต่ในแบบสำรวจที่มีผู้ตอบ 900 คน มักถูกชี้ว่าเป็น อุปสรรค สำหรับผู้ร่วมพัฒนา
• หลังย้ายไป Codeberg จำนวนผู้เขียนและผู้เขียนหน้าใหม่เพิ่มขึ้น แต่หากตัดจุดพีคชั่วคราวในเดือนมิถุนายน 2025 ออกไป ก็ยังยากที่จะยืนยัน ผลของ Codeberg อย่างชัดเจน
• มีการเปิดพูลรีเควสต์มากกว่า 500 รายการต่อเดือน ทำให้แบ็กล็อกใหญ่ขึ้น และการลดช่องว่างของ CI, ข้อกำหนดเรื่องลายเซ็น และภาระการรีวิวยังคงเป็นโจทย์งานถัดไปของ Guix

---

การย้ายจากการทำงานร่วมกันแบบอีเมลไปสู่ Codeberg

• Guix ย้าย การโฮสต์ซอร์สโค้ด, การติดตามอีชู และพูลรีเควสต์ ไปยัง Codeberg ในปี 2025
  • ก่อนหน้านั้นโฮสต์โค้ดบน Savannah มานานกว่า 10 ปี
  • รายงานบั๊กและแพตช์จัดการผ่านอีเมล และติดตามด้วย Debbugs instance
  • เนื่องจากเป็นโครงการที่มีผู้ร่วมเขียนโค้ดมากกว่า 400 คนต่อปี การย้ายจึงเป็นความเปลี่ยนแปลงครั้งใหญ่ในตัวเอง
• ผู้ร่วมพัฒนาหลักเดิมคุ้นเคยกับเวิร์กโฟลว์แบบอีเมล และทำงานได้อย่างมีประสิทธิภาพด้วยแพ็กเกจ Debbugs สำหรับ Emacs หรืออีเมลไคลเอนต์ขั้นสูง
  • Debbugs พึ่งพาโค้ด Perl เพียงไม่กี่ร้อยบรรทัด รวมถึงมาตรฐานอีเมลและโครงสร้างแบบ federated ขณะที่เว็บ forge อย่าง Forgejo เป็นระบบที่ใหญ่กว่าและมี dependency ฝั่ง Go จำนวนมาก
• รอบ ๆ กระบวนการแบบอีเมลเดิม ยังมี เครื่องมือเสริม วางรากฐานไว้อยู่แล้ว
  • mumi ให้เว็บอินเทอร์เฟซสำหรับ Debbugs
  • Quality Assurance service จะนำอีเมลแพตช์ซีรีส์ไปใช้กับ Git branch โดยอัตโนมัติ และบิลด์แพ็กเกจจาก branch นั้น
• แบบสำรวจผู้ใช้และผู้ร่วมพัฒนาครั้งแรกที่เผยแพร่ในเดือนมกราคม 2025 มีผู้ตอบมากกว่า 900 คน และผู้ร่วมพัฒนามักยกเวิร์กโฟลว์แบบอีเมลว่าเป็น อุปสรรค ต่อการมีส่วนร่วม

การตัดสินใจแบบฉันทามติผ่าน GCD 002

• Guix ไม่มี “benevolent dictator” สำหรับตัดสินใจ และได้นำ Guix Consensus Document process มาใช้ในเดือนธันวาคม 2024
• กระบวนการ GCD มีเป้าหมายที่ การสร้างฉันทามติ มากกว่าการลงคะแนนแบบง่าย ๆ
  • ผู้เขียนข้อเสนอต้องปรับข้อเสนอร่วมกับผู้เข้าร่วม
  • ผู้เข้าร่วมควรเสนอความต้องการของตนและการเปลี่ยนแปลงที่เป็นรูปธรรมเพื่อสะท้อนสิ่งนั้น แทนการคัดค้านอย่างเดียว
  • ในร่างสุดท้ายจะแสดงจุดยืนด้วย support, accept, disapprove
• GCD 002 ถูกยื่นในเดือนกุมภาพันธ์ 2025 เป็นข้อเสนอให้ย้ายไป Codeberg
  • การหารือ ดำเนินไปเป็นเวลาสองเดือน ซึ่งเป็นระยะสูงสุดตามขั้นตอน
  • สมาชิกทีม Guix สองในสามเข้าร่วมการพิจารณาอย่างรอบคอบ
  • ในบรรดาผู้เข้าร่วม 72% เลือก support และอีก 28% เลือก accept
  • ไม่มี disapprove และข้อเสนอมีผลบังคับใช้ในต้นเดือนพฤษภาคม 2025
• สมาชิกบางส่วนที่มีประสบการณ์ยาวนานรู้สึกว่าเวิร์กโฟลว์ที่ดูเหมือนยึดเว็บเป็นหลักมีประสิทธิภาพน้อยกว่าอีเมล และยังไม่สบายใจกับการละทิ้งโครงสร้างพื้นฐานบางส่วนที่อิงอีเมล
• อย่างไรก็ตาม โอกาสที่จะเชื่อมต่อกับชุมชนที่กว้างขึ้นและปรับปรุง ประสบการณ์นักพัฒนา เป็นแรงสนับสนุนสำคัญของการเปลี่ยนผ่าน
• การเลือก forge ที่อิงซอฟต์แวร์เสรีและโฮสต์โดยองค์กรไม่แสวงหากำไร Codeberg e.V. ไม่ก่อให้เกิดข้อถกเถียงใหญ่ และยังสอดคล้องกับแนวทางของ Guix

การเปลี่ยนผ่านแบบค่อยเป็นค่อยไป และช่องว่าง CI ที่ใหญ่กว่าคาด

• การย้ายไป Codeberg ดำเนินแบบ ค่อยเป็นค่อยไป ตามฉันทามติใน GCD
  • รีโพซิทอรีหลักถูก ย้าย เมื่อ 25 พฤษภาคม 2025
  • รีโพซิทอรีเดิมยังคงอยู่ในฐานะมิเรอร์จนถึงตอนนี้
  • ตัวติดตามอีชูและแพตช์เดิมจะคงไว้จนถึง 1 มกราคม 2026
  • หลังจากนั้น อีชูและพูลรีเควสต์บน Codeberg จะเป็นกลไกที่รองรับเพียงอย่างเดียว
  • รายงานบั๊กและแพตช์เก่ายังคง เข้าถึงออนไลน์ได้
• ด้วยแผนที่จัดทำขึ้นระหว่างการหารือเพื่อสร้างฉันทามติ ทำให้ระหว่างการเปลี่ยนผ่านแทบไม่มีปัญหาใหญ่หรือเหตุการณ์ไม่คาดคิด
• คุณภาพบริการจากพนักงานและอาสาสมัครของ Codeberg e.V. อยู่ในระดับดี และ downtime ที่เกิดเป็นครั้งคราวก็มักสั้นและมีประกาศชัดเจน
• สำหรับผู้ร่วมพัฒนาที่ชอบเวิร์กโฟลว์นอกเบราว์เซอร์ การปรับปรุงอินเทอร์เฟซ Emacs ช่วยได้มาก
  • fj.el และ Emacs-Forgejo มีความก้าวหน้า
  • ความสามารถในการสร้างพูลรีเควสต์ด้วย AGit workflow ก็ช่วยลดภาระในการปรับตัว
• ปัญหาที่คาดการณ์ไว้ไม่เพียงพอคือ continuous integration สำหรับพูลรีเควสต์
  • ฟังก์ชันที่ qa.guix.gnu.org ใช้บิลด์อีเมลแพตช์ไม่ได้ถูกพอร์ตไปยัง Codeberg
  • หลายเดือนแรก ผู้รีวิวต้องตรวจเองว่าพูลรีเควสต์จะก่อปัญหาหรือไม่ ซึ่งไม่ใช่สภาพที่ยั่งยืน
• ในเดือนกันยายน 2025 มีการตั้งอินสแตนซ์ Cuirass ที่ pulls.ci.guix.gnu.org และเริ่มบิลด์พูลรีเควสต์
  • ช่วงแรกมันยังมีข้อจำกัดมากกว่า qa.guix.gnu.org จึงถูกมองเป็น มาตรการชั่วคราว
  • ปัจจุบันแพ็กเกจถูกบิลด์สำหรับสถาปัตยกรรมเดียว
  • ผู้ร่วมพัฒนาใหม่สามารถเห็นผลสำเร็จหรือความล้มเหลวที่ guix-cuirass-bot ฝากไว้ในพูลรีเควสต์ได้ทันที

กระแสการมีส่วนร่วมเพิ่มขึ้น แต่แบ็กล็อกก็ขยายตัว

• หากดูจากจำนวนคอมมิตบน main branch ระหว่างพฤษภาคม 2024 ถึงพฤษภาคม 2026 ความเร็วในการคอมมิตของ Guix ยังคงอยู่ระหว่าง “สูง” และ “สูงมาก” อย่างต่อเนื่อง
• ความเร็วการคอมมิตเพียงอย่างเดียวสะท้อนความเปลี่ยนแปลงได้ไม่ชัดนัก ดังนั้นจำนวนผู้เขียนคอมมิตรายเดือน, ผู้คอมมิต และผู้เขียนคอมมิตหน้าใหม่รายเดือนจึงเป็นตัวชี้วัดที่มีประโยชน์กว่า
• จำนวนผู้เขียนรายเดือนและผู้เขียนหน้าใหม่ยังคงเพิ่มขึ้นต่อเนื่อง
  • หลังย้ายไป Codeberg ทันทีในเดือนมิถุนายน 2025 มีจุดพีคทั้งจำนวนผู้เขียนและผู้เขียนหน้าใหม่
  • นอกช่วงนั้น การเติบโตในช่วง 2025–2026 คล้ายกับช่วง 2024–2025
  • Guix ยังคงดึงดูดผู้ร่วมพัฒนาใหม่ได้ แต่ยังไม่เห็น ผลของ Codeberg ที่ชัดเจนมากนัก
• จำนวนผู้คอมมิตรายเดือนเพิ่มขึ้นช้ากว่าจำนวนผู้เขียน ซึ่งอาจบ่งชี้ว่าผู้คอมมิตต้องรับมือกับ contribution มากขึ้น
• ข้อมูลพูลรีเควสต์ถูกรวบรวมผ่าน Forgejo API ของ Codeberg
• มีการเปิดพูลรีเควสต์มากกว่า 500 รายการต่อเดือน และแม้อัตราการ merge จะสูง แต่ยังต่ำกว่าปริมาณที่ไหลเข้าเล็กน้อย ทำให้ แบ็กล็อก เพิ่มขึ้นต่อเนื่อง
  • ปัจจุบันพูลรีเควสต์ที่ยังเปิดอยู่มีราว 639 รายการ จากทั้งหมด 6,459 รายการ หรือประมาณ 10%
  • สำหรับการเปรียบเทียบ Nixpkgs มีพูลรีเควสต์ที่เปิดอยู่ 12k จากทั้งหมด 473k หรือราว 2.5%
  • แบ็กล็อกของ Guix อาจเกิดจากแรงเสียดทานที่สูงเกินไปหรือ feedback จาก CI ที่ยังไม่เพียงพอ
• Guix กำหนดให้ทุกคอมมิตต้องมี ลายเซ็นของ committer ที่ได้รับอนุมัติ
  • ไม่ใช่รูปแบบกดปุ่ม Merge อย่างเดียวเหมือนหลายโครงการรวมถึง Nixpkgs
  • ผู้ที่ทำการ merge ต้องรับผิดชอบในการนำการเปลี่ยนแปลงไปใช้และลงลายเซ็น
  • Guix เลือกความปลอดภัยของซัพพลายเชนซอฟต์แวร์ระหว่างความสะดวกของนักพัฒนาและความปลอดภัยของผู้ใช้
  • ยังต้องดูกันต่อว่าจะลดต้นทุนส่วนนี้ได้หรือไม่

ความร่วมมือที่มองเห็นได้ชัดขึ้นบน Codeberg

• หลังย้ายไป Codeberg กิจกรรมของโครงการมี ความมองเห็นได้ มากขึ้น
• ผล CI แสดงโดยตรงภายในพูลรีเควสต์ ทำให้ผู้ร่วมพัฒนาตรวจสอบได้ทันที
• ทีม ของ Guix ถูกนำไปใช้เป็นทีมบน Codeberg
  • ขอบเขตของทีมระบุไว้ในไฟล์ CODEOWNERS file
  • ผู้รับผิดชอบในขอบเขตนั้นจะถูกเรียกโดยอัตโนมัติ
  • บอตจะติดป้ายอย่าง team-python เพื่อให้กรองอีชูและพูลรีเควสต์ตาม label ได้
• อย่างไรก็ตาม ปัญหาที่ทีมไม่ได้รับการแจ้งเตือนจากอีชูที่ติดป้ายเหล่านั้น ยังเป็นจุดไม่สะดวก
• ฟีเจอร์อย่างการอ้างอิงข้ามกันระหว่างอีชูกับพูลรีเควสต์ และ milestone ก็ดูจะช่วยการทำงานร่วมกันได้เช่นกัน

โจทย์โครงสร้างพื้นฐานที่ยังเหลือ และความสัมพันธ์กับ Codeberg

• โครงสร้างพื้นฐานของ Guix ยังต้องการความช่วยเหลือเพิ่มเติม
  • ต้องเพิ่มประสิทธิภาพการบิลด์ของ pulls.ci.guix.gnu.org
  • หากเป็นไปได้ก็ควรบิลด์สถาปัตยกรรมที่ไม่ใช่ x86 ได้ด้วย
  • Cuirass ยังมีข้อจำกัดหลายอย่าง และบางส่วนกำลังได้รับการแก้ไขใน ซีรีส์ 1.4.x ที่วางแผนไว้
  • pulls.ci.guix.gnu.org ยังเน้นแพ็กเกจเป็นหลัก และหากเหมาะสมก็ควรรัน system test ได้ด้วย
• เวิร์กโฟลว์ของแพ็กเกจเมนเทนเนอร์ก็ยังมีพื้นที่ให้ปรับปรุง
  • topic branch และ world rebuild scheduling ยังผูกกับตัวติดตามบั๊กตัวเก่าที่ปลดระวางไปแล้วอยู่มาก
• Guix ต้องระวังไม่ให้สร้างภาระเกินไปแก่เซิร์ฟเวอร์ของ Codeberg และต้องเฝ้าดูการใช้พื้นที่รีโพซิทอรีด้วย
  • เคยมี กรณีที่สร้างภาระหนักเกินไปให้เซิร์ฟเวอร์ Codeberg
  • ฟอร์กเดียวของ Guix อาจเกินโควตา 750MiB สำหรับผู้ใช้ใหม่บน Codeberg
• ทางออกหนึ่งคือการ กำหนดให้ผู้ร่วมพัฒนาใหม่ใช้ AGit workflow เพื่อสร้างพูลรีเควสต์
  • AGit เป็นที่นิยมในหมู่ผู้ร่วมพัฒนา Guix อยู่แล้ว
  • แต่สำหรับบางคนมันคุ้นเคยน้อยกว่าเวิร์กโฟลว์พูลรีเควสต์ทั่วไป จึงมองว่าเป็น “downgrade”
  • เช่นเดียวกับกรณีของ Gentoo การเพิ่มไอคอน “AGit fork” อาจช่วยให้ค้นพบได้ง่ายขึ้น
• Guix Foundation ได้ ลงคะแนน ให้เป็นสมาชิกผู้สนับสนุนของ Codeberg e.V. เพื่อแสดงความขอบคุณและการสนับสนุน
• มีการส่ง พูลรีเควสต์ที่เพิ่ม Forgejo และบริการสำหรับตั้งค่ามันใน Guix
  • นี่เป็นทิศทางที่จะทำให้สามารถมีการตั้งค่าแบบ declarative และการดีพลอย forge ที่ทำซ้ำได้ภายใน Guix เอง

[GN⁺]

ความคิดเห็นจาก Lobste.rs

• การได้เห็นตัวชี้วัดจริงของโครงการที่เกี่ยวกับการ ย้ายไป Codeberg น่าสนใจมาก ส่วนตัวมีเหตุผลมากเกินพอที่จะเลิกใช้ GitHub เลยหวังว่า Codeberg จะกลายเป็น GitHub ใหม่ แต่ฉันย้ายไปใช้เซิร์ฟเวอร์ Forgejo ที่โฮสต์เอง และตอนนี้ใช้ Codeberg เป็นปลายทางสำรองข้อมูลสำหรับทุกรีโพซิทอรี

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

• สิ่งที่น่าหงุดหงิดจริง ๆ หลังจากเริ่มใช้ Codeberg คือ แทบไม่มีเครื่องมือไหนรองรับ การเชื่อมต่อกับ git ได้ดี และส่วนใหญ่ในทางปฏิบัติก็รองรับแค่ GitHub / GitLab

  • ในฐานะคนใช้ magit forge ก็ได้แต่ร้องไห้

• ฉันไม่ค่อยเข้าใจส่วนที่บอกว่าจะคงระบบติดตาม issue/patch แบบเก่าไว้ถึงวันที่ 1 มกราคม 2026 แล้วหลังจากนั้นจะรองรับเฉพาะ Codeberg issues และ pull requests เท่านั้น
  ถ้าผู้มีส่วนร่วมจำนวนมากไม่ชอบแนวทางใหม่นี้ ก็ไม่เข้าใจว่าทำไมต้องบังคับเปลี่ยน และก็สงสัยด้วยว่าการเปิดให้มีหลาย workflow พร้อมกันนั้นมีต้นทุนแฝงอะไรหรือเปล่า ทำไมต้องบังคับให้ทุกคนใช้วิธีเดียวกัน
  เป็นข้อสังเกตเล็กน้อย แต่ดูเหมือน Codeberg จะไม่ได้มีพนักงานประจำหลายคน เท่าที่ฉันรู้มีแค่คนเดียว แก้ไข: ได้เพิ่มพนักงานคนที่สองเมื่อเดือนธันวาคมปีที่แล้ว