ที่เก็บโค้ดของ Mozilla Firefox ย้ายจาก Mercurial ไปยัง GitHub

 (github.com/mozilla-firefox)
4 คะแนน โดย GN⁺ 2025-05-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ช่วงนี้ Firefox ได้ย้ายที่เก็บหลักจาก Mercurial ไปยัง GitHubแล้ว
  • ยังคงใช้ Bugzilla สำหรับติดตามบั๊ก, Phabricator สำหรับรีวิวโค้ด, และ Taskcluster สำหรับ CI ต่อไป
  • ปัจจุบัน GitHub เป็นที่เก็บศูนย์กลาง แต่เซิร์ฟเวอร์ Mercurial ยังคงถูกดูแลต่อโดยซิงก์จาก GitHub และระบบอัตโนมัติเดิมก็มีแผนจะทยอยเปลี่ยนไปใช้ Git
  • ที่เก็บ try สำหรับทดสอบ CI ยังอิงกับ Mercurial แต่กำลังค่อย ๆ ถูกซ่อนไว้หลัง abstraction layer และมีแผนจะย้ายไป Git ในอนาคต
  • เมื่อสามารถใช้ Git เป็นค่าเริ่มต้นได้แล้ว ผู้ร่วมพัฒนาใหม่ก็ไม่จำเป็นต้องเรียน Mercurial เพิ่ม แค่รู้ Git ก็เพียงพอ
    • ก่อนหน้านี้ต้องติดตั้งส่วนขยาย git cinnabar แต่ตอนนี้ใช้ Git พื้นฐานอย่างเดียวก็เพียงพอ
  • mozilla-central เดิมของ Mercurial ถูกเปลี่ยนเป็น สาขา main ใน Git และสาขา autoland ก็ยังคงเป็น autoland เช่นเดิม
  • เวิร์กโฟลว์แบบ PR บน GitHub ยังไม่ได้ถูกนำมาใช้ และไม่ได้รวมอยู่ในการเปลี่ยนแปลงครั้งนี้ แม้อนาคตจะยังเป็นไปได้ แต่ยังไม่มีแผนอย่างเป็นทางการ
  • Mozilla สามารถลดภาระในการดูแลโครงสร้างพื้นฐาน VCS ของตนเองได้ด้วยการย้ายไป GitHub
  • เป้าหมายหลักคือการลดต้นทุนและความซับซ้อนในการให้บริการ ประสิทธิภาพ, ความเสถียร, และความพร้อมใช้งาน ที่โปรเจ็กต์ขนาดใหญ่ต้องการด้วยตัวเอง

ประวัติและคำอธิบายแบบละเอียดโดย Glandium ผู้สร้าง git-cinnabar: How I (kind of) killed Mercurial at Mozilla

> Mozilla เปลี่ยนที่เก็บโค้ดของ Firefox ไปยัง GitHub พร้อมปิดฉากยุค Mercurial

  • Mozilla ตัดสินใจ เปลี่ยน VCS หลักของการพัฒนา Firefox จาก Mercurial ไปเป็น Git และใช้ GitHub เป็นที่เก็บอย่างเป็นทางการ
  • เบื้องหลังการตัดสินใจนี้คือการพัฒนาและการใช้งานเครื่องมือส่วนขยาย git-cinnabar อย่างต่อเนื่องในระยะยาว ซึ่งทำให้ผู้ใช้ Git เข้าถึงที่เก็บ Mercurial ได้อย่างราบรื่น
  • ปัญหาเรื่องโครงสร้างสาขาของ Mercurial, การขยายขนาดของที่เก็บ, และภาระในการดูแลเซิร์ฟเวอร์เอง ล้วนส่งผลร่วมกันจน ความยากในการคงโครงสร้างพื้นฐานของตนเองสะสมมากขึ้นเรื่อย ๆ
  • แม้การเลือก GitHub จะมีข้อถกเถียงอยู่บ้าง แต่เมื่อภายใน Mozilla มีรีโพซิทอรีหลายพันรายการอยู่บน GitHub แล้ว ก็ถือเป็นทางเลือกที่เลี่ยงได้ยากในแง่ ความเป็นมิตรต่อผู้ร่วมพัฒนาและความเหมาะสมเชิงปฏิบัติ
  • git-cinnabar เริ่มต้นจาก โปรเจ็กต์ส่วนตัวนอกเวลางาน ที่เกิดจากความต้องการภายใน Mozilla แต่ก็มีแนวโน้มสูงว่าจะยังคงเป็นเครื่องมือสำคัญต่อไปในช่วงเปลี่ยนผ่าน
    > “ผมไม่ได้เป็นคนจุดไฟ แต่ก็จริงที่ผมเป็นคนราดน้ำมันใส่กองไฟนั้น”

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-05-14
ความคิดเห็นจาก Hacker News
  • ฉันทำงานที่ Mozilla แต่ไม่ได้เกี่ยวข้องกับเครื่องมือ VCS หรือการย้ายครั้งนี้ แค่อยากให้บริบทเพิ่มเติม ตอนนี้ที่เก็บโค้ดอย่างเป็นทางการของ Firefox ได้ย้ายจาก mercurial บน hg.mozilla.org ไปยัง GitHub แล้ว มีผลเฉพาะกับโค้ด ส่วนการติดตาม issue ยังใช้ bugzilla เหมือนเดิม การรีวิวโค้ดและการ land ยังใช้ phabricator และ CI ก็ยังใช้ระบบ taskcluster ต่อไป ในระยะสั้น เซิร์ฟเวอร์ mercurial จะยังซิงก์จาก GitHub เพื่อให้ระบบอัตโนมัติค่อย ๆ ย้ายไปใช้ git backend ได้ mercurial ยังถูกใช้กับที่เก็บ “try” (ที่ใช้รัน CI สำหรับแพตช์ WIP) แต่กำลังค่อย ๆ ถูกซ่อนไว้หลัง abstraction layer และจะย้ายในภายหลัง สำหรับคนที่คุ้นกับที่เก็บเดิม “mozilla-central” จะถูกแมปเป็นชื่อสาขามาตรฐานของ git คือ “main” และ “autoland” จะถูกแมปเป็นสาขา “autoland” เดิมทีสามารถมีส่วนร่วมกับ Firefox ด้วย git ได้อยู่แล้ว แต่ต้องติดตั้งส่วนขยายชื่อ git cinnabar การต้องเลือกระหว่างเรียนรู้ hg กับใช้ git+ส่วนขยายเป็นอุปสรรคต่อผู้มีส่วนร่วมหน้าใหม่ เพราะคนส่วนใหญ่รู้จัก git แต่ไม่รู้จัก mercurial ตอนนี้ไม่ต้องกังวลเรื่องนั้นอีกแล้ว glandium ผู้เขียน git cinnabar ได้เขียนบล็อกอธิบายบริบทและเหตุผลอย่างละเอียดไว้ตอนประกาศการย้าย สำหรับผู้มีส่วนร่วม ในระยะสั้นแทบไม่มีอะไรเปลี่ยนแปลง การใช้ git แบบปกติกลายเป็น workflow หลักแล้ว นอกนั้นไม่มีอะไรเปลี่ยน ในอนาคตอาจมีการรองรับ workflow แบบ GitHub PR แต่ไม่ได้รวมอยู่ในการเปลี่ยนแปลงครั้งนี้ ส่วน backend เมื่อการย้ายเสร็จ Mozilla จะลดเวลาและความพยายามที่ต้องใช้ในการดูแลโครงสร้างพื้นฐาน VCS ของตัวเองได้ และการทำให้ตรงตามข้อกำหนดด้านประสิทธิภาพและความพร้อมใช้งานของโปรเจ็กต์ขนาดใหญ่นี้ก็เป็นความท้าทายไม่น้อย
    • โดยส่วนตัวฉันคิดว่า Mozilla ตัดสินใจผิดที่ย้ายไปยังแพลตฟอร์มปิดซึ่ง Microsoft เป็นเจ้าของ
    • สงสัยว่าเมื่อ Phabricator ถูกยุติไปแล้ว มีแผนจะหาอะไรมาแทนไหม อยากรู้ว่ากำลังพิจารณา Phorge หรือเปล่า
    • ขอบคุณสำหรับบริบทเพิ่มเติม อยากรู้ว่าปัญหาด้านสเกลหลัก ๆ ที่เจอกับโซลูชันโฮสต์เองคืออะไร
    • อยากถามว่า GeckoView และ Mozilla Android Components จะย้ายไป GitHub ด้วยหรือไม่
    • น่าเสียดายที่ย้ายเฉพาะโค้ดไป GitHub แต่การติดตาม issue ยังอยู่บน bugzilla ข้อดีหลักของการใช้ GitHub คือผู้ใช้จำนวนมากมีบัญชีอยู่แล้วและคุ้นกับแพลตฟอร์ม แต่เมื่อรับ issue เฉพาะผ่าน bugzilla ก็กลายเป็นอุปสรรคต่อการรายงานบั๊กด้วย ฉันเคยเข้าไปที่ bugzilla และ Firefox เพื่อรายงานบั๊กด้าน accessibility บน macOS ต้องหาหน้าเว็บ สมัครสมาชิก และเรียนรู้วิธีใช้ ซึ่งค่อนข้างไม่สะดวก สุดท้ายบั๊กนั้นได้รับการยืนยันแต่ก็ไม่ได้ถูกแก้
  • ดูเป็นการตัดสินใจที่เข้าใจได้จากมุมมองเชิงกลยุทธ์ของ Mozilla รายได้จาก Google อาจลดลง และอาจต้องลดจำนวนพนักงาน แต่ถ้าจะให้การพัฒนา Firefox เดินหน้าต่อ ก็ต้องการการมีส่วนร่วมจากชุมชนมากขึ้น และ GitHub เป็นแพลตฟอร์มสำหรับนักพัฒนาที่เป็นที่รู้จักที่สุด จึงช่วยลดอุปสรรคในการเริ่มต้นได้ คุณอาจไม่พอใจที่ไม่ใช้ GitLab หรืออย่างอื่นแทน GitHub แต่การที่ Firefox ยังพัฒนาต่อได้และตลาดยังมีเอนจินที่แข่งขันกันอยู่ก็เป็นประโยชน์กับทุกคน
    • ฉันไม่คิดว่าคนที่ยอมเลิกมีส่วนร่วมเพียงเพราะใช้ GitHub ไม่ได้จะเป็นผู้มีส่วนร่วมที่มีคุณค่าเป็นพิเศษนัก อาจมีข้อยกเว้น แต่ในโปรเจ็กต์โอเพนซอร์สที่ไม่เล็กน้อยซึ่งฉันเคยมีส่วนร่วม ไม่เคยเจอเลย กลับกัน ฉันคิดว่าการเพิ่มอุปสรรคขึ้นเล็กน้อยยังช่วยคัดกรองผู้มีส่วนร่วมคุณภาพต่ำที่เข้ามาแบบครั้งเดียวได้ด้วย
    • ฉันไม่เข้าใจการจับคู่ gh กับ phabricator เลย จนสุดท้ายเลิกพยายามส่งแพตช์ให้ Firefox ไปเลย ฉันไม่เข้าใจว่าทั้งสองอย่างเชื่อมกันอย่างไร และไม่รู้ว่าจะอัปเดต branch/PR อย่างไร สุดท้ายเลยเลิกพยายาม
    • จากประสบการณ์ส่วนตัวกับ GitLab เมื่อหลายปีก่อน GitLab แสดงชัดเจนว่าไม่ได้สนใจการโฮสต์โปรเจ็กต์โอเพนซอร์สขนาดใหญ่สักเท่าไร และการรองรับ FOSS ก็ทำได้แค่ผ่านโปรแกรมโอเพนซอร์สของเขา กระบวนการนี้ซับซ้อนและมีข้อกำหนดเพิ่มเติมมากมาย ซึ่ง Mozilla น่าจะรับไม่ได้ ตัวอย่างเช่น หากจะใช้ GitLab โปรเจ็กต์โอเพนซอร์สนั้นต้องสละสิทธิ์ในการแก้ไข/ฟอร์ก GitLab FOSS เวอร์ชันของ GitLab เอง ซึ่งเป็นปัญหาร้ายแรงสำหรับทุกโปรเจ็กต์ อาจเป็นไปได้ว่าทนายใส่เงื่อนไขมาตรฐานมาแล้วกลายเป็นแบบนั้น แต่แค่นี้ก็พิสูจน์แล้วว่าเป็นปัญหาใหญ่ ดังนั้น GitLab จึงถูกตัดออก เหลืออย่าง Codeberg เป็นต้น แต่ถ้าต้องการลดอุปสรรคให้ผู้มีส่วนร่วมใหม่ GitHub ซึ่งคนส่วนใหญ่มีบัญชีอยู่แล้วก็เหมาะกว่า
    • แม้การย้ายไป GitHub จะเป็นการเปลี่ยนแปลงทางเทคนิค แต่แก่นจริง ๆ คือการย้ายจาก mercurial ไปสู่ git และคาดว่าปัจจัยทางสังคมน่าจะมีอิทธิพลต่อการตัดสินใจทางเทคนิคนี้
    • ฉันคิดว่าคนที่ผ่านอุปสรรคการเริ่มต้นไม่ได้ ก็ไม่ควรรายงานบั๊กด้วย และก็เช่นเดียวกันกับการแก้โค้ด
  • เป็นเรื่องดีที่การมีส่วนร่วมกับ Firefox ได้จัดการหนี้เทคนิคสำคัญไปเสียที ตอนฉันลองเมื่อหลายปีก่อน mercurial ใช้เวลาหลายชั่วโมงในการ clone ที่เก็บ และก็ไม่มีการรองรับ git อย่างเป็นทางการ จึงต้องใช้การรองรับ git แบบไม่เป็นทางการถึงจะทำงานได้สะดวก ตอนนั้นเอกสารก็แย่มาก จนทำให้ต้อง build ทุกอย่างใหม่โดยไม่จำเป็น
  • สงสัยว่าทำไมถึงเลือกใช้ org ชื่อ mozilla-firefox แทนที่จะใช้ mozilla org เดิม
    • น่าจะเพราะกฎการเข้าถึงต่างกัน หรือไม่ก็ต้องการแยกจาก org เดิมเพื่อป้องกันไม่ให้อัตโนมัติบางอย่างไปกระทบส่วนอื่น
    • ฉันก็คิดว่าเป็นคำถามที่ดีมาก
  • สงสัยว่าแหล่งที่มาของ “Firefox Moves to GitHub” คืออะไร อาจเป็นแค่มิเรอร์ก็ได้ Linux ก็มีมิเรอร์บน GitHub เหมือนกัน (แก้ไขภายหลัง: แนบแหล่งที่มาแล้ว)
    • ฉันก็คิดแบบเดียวกัน จริง ๆ แล้ว workflow ที่ตั้งไว้บน GitHub มีแค่ปิด PR พร้อมข้อความตอบกลับอัตโนมัติเท่านั้น
  • Firefox Mobile (Fenix) เคยใช้ GitHub มาก่อน แล้วไม่นานมานี้เพิ่งย้ายไปยังที่เก็บ mercurial mozilla-central ของ Mozilla ตอนนี้ทั้งเวอร์ชันเดสก์ท็อปและมือถือก็อยู่บน GitHub แล้ว ส่วน issue ยังอยู่บน bugzilla ทำให้ใช้ประโยชน์จากการค้นหาที่ดี การเรียกดูซอร์ส และความคุ้นเคยกับ git บน GitHub ได้ ในฐานะอดีตผู้มีส่วนร่วมของ Firefox และ Thunderbird ฉันใช้การค้นหาในเครื่องมากกว่าการค้นหาบนไซต์ mozilla-central มาก ระหว่างพัฒนาก็ใช้การค้นหาใน IDE แต่การค้นหาบนเว็บไซต์ที่ใช้ง่ายเป็นสิ่งที่ผู้มีส่วนร่วมใหม่จะยินดีต้อนรับ
    • ในทางกลับกัน ฉันคิดว่า searchfox เป็นเครื่องมือนำทางโค้ดที่ดีที่สุดเท่าที่เคยใช้มา มีความสามารถอย่างการนำทางข้ามภาษา การ blame ที่เปิดอยู่ตลอดเวลา และอีกหลายอย่าง ทั้งยังเร็วและเบากว่า GitHub มาก หวังว่าจะมีโปรเจ็กต์อื่นใช้เครื่องมือนี้ได้มากขึ้น และคงเสียดายถ้ามันหายไป
    • ฉันรู้สึกว่าคุณภาพของการเรียกดูซอร์สบน GitHub แย่ลงอย่างหนักในช่วงหลัง ๆ มีการโหลดแบบ asynchronous (ต้องใช้ js) พอเครือข่ายไม่เสถียรก็พัง และแม้แต่การค้นหาในหน้าก็เสียหาย การปรับโฉม issue/PR ช่วงหลังก็ถือเป็นการถอยหลัง และถ้าใช้ uBlock Origin ก็ค้นหา PR ไม่ได้
  • คิดว่าเป็นการเปลี่ยนแปลงที่ดี แต่สงสัยว่าทำไมถึงสร้าง org ใหม่แทนที่จะใช้ github.com/mozilla org เดิม
    • ไม่รู้เหตุผลโดยละเอียด แต่มีหลายส่วนที่ต้องแยกกันในระดับ org ตัวอย่างเช่น SSO ใช้ได้เฉพาะทั้ง org เท่านั้น ดังนั้น repo ของ Firefox อาจต้องมีการยืนยันตัวตน/การตั้งค่าผู้ใช้ที่ต่างจาก repo หลักของ Mozilla โดยสิ้นเชิง
    • Mozilla มีหลาย org อยู่แล้ว
    • เดาว่าเป็นเพราะ Conway’s Law
    • GitHub มีแค่ระดับ org หรือ repo เท่านั้น ไม่มีระดับที่สูงกว่านั้น การตั้งค่าหลายอย่าง (SSO, สิทธิ์การเข้าถึง, การตั้งค่าร่วม ฯลฯ) ถูกใช้ในระดับ org ดังนั้นการสร้าง org ใหม่จึงมักเป็นวิธีแก้ที่สะอาดที่สุด แม้จะไม่สะดวกก็ตาม (ถ้าเป็น GitLab ก็สามารถสร้าง namespace อย่าง Firefox และอย่างอื่นภายในอินสแตนซ์เดียวหรือ org เดียวได้)
  • รู้สึกแปลกที่องค์กรอย่าง Mozilla ใช้โฮสติ้งภายนอกอย่าง GitHub เข้าใจได้ถ้าเป็นโปรเจ็กต์เล็กของคนคนเดียว แต่การบังคับให้ผู้มีส่วนร่วมต้องมีบัญชีบริการภายนอกนั้นไม่ค่อยเป็นมิตร
    • ถ้าเป็นโปรเจ็กต์โอเพนซอร์ส ฉันคิดว่านี่เป็นเรื่องดี เพราะทำให้เปิดกว้างต่อทุกคน สร้างสภาพแวดล้อมที่มีการมองเห็นและมีส่วนร่วมได้ง่าย
  • เท่าที่ฉันจำได้ สาขา “master” คือ mozilla-central ตอนนี้มี “main” กับ “autoland” เลยสงสัยว่าคืออะไร และสาขาไหนเทียบเท่ากับ mozilla-central เดิม
    • ฉันไม่ใช่นักพัฒนา Firefox แต่ “main” น่าจะเท่ากับ mozilla-central และ “autoland” ก็เป็นสาขาที่มีอยู่ข้าง ๆ กันมาตั้งแต่ก่อน เป็นที่ที่ commit จะเข้ามาก่อน
  • หวังว่า bugzilla จะยังคงอยู่ แม้จะเป็นแบบอ่านอย่างเดียวก็ตาม เว็บเป็นแพลตฟอร์มที่ถูกต่อเติมแบบ “ad-hoc” มาตลอด ดังนั้นเหตุผลมากมายในอดีตยังคงอยู่แค่ใน bugzilla เท่านั้น แม้แต่เหตุผลว่าทำไมเว็บไซต์หรือเบราว์เซอร์ที่หายไปแล้วจึงทำพฤติกรรมบางอย่าง ก็ตรวจสอบได้จากที่นี่เท่านั้น
    • bugzilla ยังคงเป็นตัวติดตามบั๊กของ Firefox ไม่มีแผนเปลี่ยนแปลง (จะไม่ใช้ GitHub issue)
    • bugzilla ยอดเยี่ยมมาก และเป็นผลิตภัณฑ์ที่ล้ำยุคเกินสมัย ฉันยังคิดว่าแม้แต่ตอนนี้ก็ยังไม่มีตัวติดตามบั๊กแบบโฮสต์เองตัวไหนที่อยู่ในระดับใกล้เคียงกัน