มหากาพย์ Bzr ที่เป็น Emacs ที่สุด

 (thanosapollo.org)
2 คะแนน โดย GN⁺ 12 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในปี 2008 Emacs พิจารณา Git และ Bazaar เป็นตัวเลือกถัดจาก CVS และในการทดสอบประสิทธิภาพ Git เร็วกว่าแบบทิ้งห่าง
  • Richard Stallman ยืนยันเลือก Bazaar เพราะเป็น แพ็กเกจ GNU และการถกเถียงเชิงเทคนิคก็ไม่อาจเปลี่ยนการตัดสินใจได้
  • ระหว่างปี 2008–2012 ขณะที่ GitHub เติบโต ผู้มีส่วนร่วมกับ Emacs ต้องเรียนรู้ Bazaar เพื่อส่งแพตช์ และในปี 2012 Canonical ก็ปลดทีมพัฒนาออก
  • ในปี 2013 ภาวะการดูแลรักษา Bazaar ที่ชะงักงันและบั๊กของ สาขา ELPA ทำให้เกิดการถกเถียงขึ้นอีกครั้ง และสุดท้าย ELPA ก็ย้ายไปใช้ Git
  • ในปี 2014 หลังงานย้ายระบบของ Eric S. Raymond เสร็จ Emacs ก็ย้ายไป Git แต่ทันทีหลังจากนั้นก็เผยให้เห็นปัญหาว่าผู้มีส่วนร่วมหลักหลายคนต้องเริ่มเรียนรู้ Git ใหม่

ปี 2008: Git เร็วกว่า แต่ Bazaar ถูกเลือก

  • เดือนมีนาคม 2008 Emacs พยายามย้ายจาก CVS ไปสู่เครื่องมือควบคุมเวอร์ชันที่ทันสมัยกว่า โดยตัวเลือกสุดท้ายเหลือ Git กับ Bazaar
    • Git เป็นเครื่องมือที่ Linus Torvalds สร้างขึ้นเพื่อ Linux kernel
    • Bazaar เป็นโครงการ GNU ที่ Canonical ดูแลรักษา
  • ใน emacs-devel มีการถกเถียงยาว 236 ข้อความ และนักพัฒนาหลายคนได้ทดสอบประสิทธิภาพของทั้งสองเครื่องมือ
    • Andreas Schwab ประเมินว่า bzr log ใช้เวลาเริ่มทำงานเกิน 1 นาที จน “ช้าถึงขั้นใช้งานไม่ได้เลย”
    • David Kastrup มองว่าในขณะที่ git log ทำงานแทบจะทันที Bazaar กลับดูเหมือนควรจะเร็วกว่านั้น เพราะมันรับข้อมูลการคัดลอก ย้าย และเปลี่ยนชื่อไฟล์อย่างชัดเจน
  • ตัวเลขจริงก็แสดงให้เห็นชัดเจนว่า Git เหนือกว่า
    • git log | head -1 ใช้เวลา 0.012 วินาที ขณะที่คำสั่งเดียวกันบน Bazaar ใช้ 21.5 วินาที
    • การคอมมิตที่เปลี่ยนไฟล์เดียว Git ใช้ 0.08 วินาที ส่วน Bazaar ใช้ 17 วินาที
  • Stefan Monnier ซึ่งเป็นผู้ดูแลหลักในเวลานั้น มองว่าประเด็นสำคัญไม่ใช่ว่า Bazaar เร็วหรือช้ากว่า Git แต่ถ้า Emacs จะย้ายระบบ มันต้อง “เร็วพอ” อย่างน้อย bzr diff ไม่ควรใช้เวลาหลายวินาที
  • Jonathan Lange นักพัฒนา Bazaar จาก Canonical เสนอขั้นตอนสำหรับการ checkout ครั้งแรกโดยใช้ wget, tar, bzr init-repo, bzr branch, bzr pull --remember ร่วมกัน
    • ขั้นตอนนี้ยาวและต้องทำด้วยมืออย่างเห็นได้ชัดเมื่อเทียบกับ git clone

การตัดสินใจว่าต้องใช้เครื่องมือของ GNU

  • มีคนถามผู้ดูแลและผู้ตัดสินใจของ Emacs ว่า “ยังต้องการข้อมูลอะไรเพิ่มอีกเพื่อให้เชื่อว่า bzr ไม่ใช่เครื่องมือที่เหมาะสม ณ ตอนนี้”
  • Richard Stallman ตอบว่าการเลือกนี้ไม่ใช่การตัดสินใจเฉพาะหน้า แต่เป็น การตัดสินใจระยะยาว และแทนที่จะตัดสินใจชั่วคราวที่ย้อนกลับได้ยาก ควรรออีกไม่กี่เดือนให้ผู้พัฒนา Bazaar ปรับปรุงก่อน
  • ในข้อความอีกฉบับ Stallman ย้ำชัดว่า “คำถามนี้จบแล้วและมีการตัดสินใจแล้ว เราจะใช้ GNU Bzr เพราะมันเป็นแพ็กเกจ GNU”
  • เมื่อต้องเผชิญกับข้อท้วงติงว่าข้อถกเถียงทางเทคนิคกำลังถูกลบล้างด้วยการตัดสินใจทางการเมือง Stallman ตอบด้วยหลักการที่ว่าแพ็กเกจ GNU ควรสนับสนุนกันเอง เพราะจะทำให้ระบบ GNU โดยรวมทำงานได้ดีขึ้น
  • เมื่อถูกถามว่า “ทำไมไม่ทำให้ Git เป็นส่วนหนึ่งของระบบ GNU” เขาตอบว่าสามารถรวม Git เข้ามาในระบบ GNU ได้ แต่ไม่น่าที่นักพัฒนา Git จะอยากให้ Git กลายเป็นแพ็กเกจ GNU
  • แม้จะมีผลทดสอบในปี 2008 การถกเถียง 236 ข้อความ และขั้นตอนอ้อมค้อมจากพนักงาน Canonical ผลลัพธ์ก็ไม่เปลี่ยน และ Emacs ก็เลือก Bazaar เพราะเป็น แพ็กเกจ GNU

ปี 2008–2012: การขยายตัวของ Git กับภาระการใช้ Bazaar

  • ระหว่างที่ GitHub เปิดตัวในปี 2008 และเติบโตอย่างรวดเร็ว ผู้มีส่วนร่วมกับ Emacs กลับต้องเรียนรู้ Bazaar ซึ่งแทบไม่ได้ใช้ที่อื่น เพื่อจะส่งแพตช์ได้
  • ใน emacs-devel มีเธรดเกี่ยวกับปัญหา Bazaar โผล่ขึ้นมาซ้ำแล้วซ้ำเล่า
    • “Help me unstick my bzr, please”
    • “Can NOT bzr the emacs repos (may be bzr has a memory leak)”
  • ในปี 2012 Canonical ปลดทีมพัฒนา Bazaar
  • หลังจากนั้น สถานะการดูแลรักษา Bazaar ก็กลายเป็นภาระที่หนักขึ้นในกระบวนการพัฒนา Emacs

ปี 2013: การดูแลรักษาที่ชะงักงันและการถกเถียงเรื่อง Git อีกครั้ง

  • เดือนมีนาคม 2013 หนึ่งปีหลังจากการพัฒนา Bazaar แทบหยุดนิ่ง John Wiegley ถามอีกครั้งว่า Emacs จะย้ายไปใช้ Git ได้หรือไม่
    • การพัฒนา Bazaar แทบอยู่ในภาวะหยุดชะงัก
    • บั๊กสำคัญที่กระทบการพัฒนา Emacs เช่นในคลัง ELPA ค้างอยู่ใน bug tracker มาหลายปีโดยไม่ได้รับการแก้ไข
  • การถกเถียงครั้งนี้ก็กินไปเกือบ 200 ข้อความ
  • ปฏิกิริยาแรกของ Stallman คือผู้ดูแล Bazaar กำลังแก้บางบั๊กอยู่ และเขาเองก็เพิ่งขอให้แก้บั๊กของสาขา ELPA ไปเมื่อวันก่อน จึงอยากให้เวลาอย่างสมเหตุสมผล
  • Dmitry Gutov ถามกลับว่าบั๊กนี้มีอายุ 1.5 ปี แล้ว แบบนี้ยังไม่ช้าเกินไปหรือ
  • Stallman กล่าวว่าเขากำลังพยายามประเมินว่า Bazaar ยังได้รับการดูแลรักษาอย่างมีประสิทธิภาพหรือไม่ และยอมรับว่าเขาอยากได้คำตอบว่า “ใช่”
  • Joakim Verona มองว่าชุมชน Bazaar ให้ความช่วยเหลือดีมาก แต่มีทั้งบั๊กและแพตช์ที่เป็นที่รู้กันอยู่แล้วจำนวนมาก ซึ่งบางส่วนก็ส่งโดยนักพัฒนา Emacs เอง แต่ก็ยังไม่ถูกรวม upstream มาหลายปี
  • Stallman ตอบว่าเขาไม่มีเวลาอ่าน mailing list ของ Bazaar และ mailing list ด้านพัฒนาที่เขาอ่านมีเพียง emacs-devel เท่านั้น
  • เมื่อถูกถามว่าผู้ใช้ Bazaar ควรมีสิทธิออกเสียงในการตัดสินว่า Bazaar ได้รับการดูแลรักษาดีพอหรือไม่ เขาตอบว่าแม้ข้อมูลที่เกี่ยวข้องจะมีประโยชน์ แต่การให้ผู้ใช้มี “สิทธิออกเสียง” เป็นเรื่องไม่เหมาะสม

คำวิจารณ์ของ Karl Fogel และปัญหาเรื่องการมอบอำนาจ

  • Karl Fogel ผู้เขียน Producing Open Source Software และหนึ่งในนักพัฒนา Subversion ยุคแรก วิจารณ์วิธีตัดสินของ Stallman และการไม่มีการมอบอำนาจ
  • Fogel มองว่าถ้า Stallman ไม่มีเวลาติดตามสถานการณ์การพัฒนา Bazaar อย่างใกล้ชิด เขาก็ยากจะประเมินได้อย่างมีความสามารถว่า Bazaar ยังเป็นตัวเลือกที่ดีสำหรับ Emacs หรือไม่
  • เขาโต้แย้งว่าถ้าไม่มีทั้งเวลาและพลังทางความคิดสำหรับการประเมินแบบนี้ ก็ควร มอบอำนาจให้ผู้ดูแล Emacs
  • Fogel มองว่าการไปถามคนคนเดียวเกี่ยวกับบั๊กเดียว ไม่สามารถเป็นตัวชี้วัดแทนสุขภาพของโครงการได้ และคนอื่น ๆ ในเธรดก็ได้ทำการตรวจสอบอย่างละเอียดกว่านั้นไปแล้ว
  • Stallman ตอบว่าเป็นเพราะ “มีเรื่องที่สำคัญกว่า Emacs เป็นเดิมพัน”
    • ประเด็นสำคัญคือถ้าโครงการตัวแทนของ GNU เลิกใช้เครื่องมือ GNU จะส่งสัญญาณแบบใดไปยังแพ็กเกจ GNU อื่น ๆ
  • Fogel จึงย้ำอีกครั้งว่า Stallman ควรใช้เวลาประเมินสถานะการดูแล Bazaar ให้เพียงพอจะเชื่อถือได้ หรือไม่ก็มอบหมายให้คนที่ทำได้
  • Stallman ตอบเพียงว่าเขามีแผนอยู่แล้วและกำลังดำเนินการ แต่ไม่ได้บอกแผน รายละเอียด กำหนดเวลา หรือการมอบอำนาจใด ๆ

ELPA ย้ายไป Git ก่อน

  • ในการถกเถียงปี 2013 Stefan Monnier บอกว่าเขาไม่ได้สนใจมากว่าจะใช้ Bazaar ต่อหรือจะเปลี่ยนไปใช้ Git, Monotone, Darcs, Mercurial, OpenCM หรือ Fossil
  • สำหรับ Stefan สิ่งสำคัญเร่งด่วนคือทำให้ สาขา ELPA หลุดพ้นจาก Bazaar
    • เพราะ Bazaar จัดการสาขา ELPA ได้ไม่ถูกต้อง
  • Leo Liu ชี้ว่าโครงการ GNU ส่วนใหญ่ไม่ได้ใช้ Bazaar
  • เขามองว่าการใช้เวลาไปแก้บั๊กของ Bazaar อาจเป็นประโยชน์ต่อ Bazaar แต่เป็นความสูญเสียต่อ GNU โดยรวม
    • หาก 20% ของเวลาว่างของอาสาสมัครต้องหมดไปกับการต่อสู้กับ Bazaar ต้นทุนก็สูงพอจะทำให้คนไม่อยากเข้าร่วมโครงการ GNU
  • ปลายปีนั้น Stefan Monnier ย้าย สาขา ELPA ที่พังอยู่บน Bazaar ไปใช้ Git
    • สาขา ELPA มีบั๊กที่ทำให้เกิด conflict ระหว่าง checkout และไม่เหลือใครที่จะแก้ได้แล้ว
    • Stefan มองว่าแม้ระบบสองเครื่องมือแบบ Git สำหรับ ELPA และ Bzr สำหรับ trunk จะไม่น่าพอใจ แต่ก็ไม่มีทางออกอื่น
    • เขาย้ำว่าไม่ควรขยายการเปลี่ยนแปลงนี้ไปเป็นการถกเถียงเรื่องข้อดีข้อเสียของ Git กับ Bazaar หรือการย้าย trunk ไป Git
  • เมื่อ ELPA ย้ายไป Git แล้ว ก็กลายเป็นฐานให้เกิดคำถามถัดมาว่า “ถ้า Git ดีพอสำหรับ ELPA แล้ว ทำไมจะไม่ดีพอสำหรับ trunk”

ปี 2014: งานย้ายระบบของ Eric S. Raymond และการย้ายจริง

  • เดือนสิงหาคม 2014 Eric S. Raymond เตรียมสคริปต์สำหรับการแปลงคลัง Emacs ไว้พร้อมแล้ว
  • เขาระบุในข้อความนี้ ว่า งานยากทั้งหมดเสร็จแล้ว และต้องการเพียงการแจ้งล่วงหน้าราว 8 ชั่วโมงก่อนกดปุ่ม
  • การย้ายจริงเกิดขึ้นใน พฤศจิกายน 2014
  • วันที่ 13 พฤศจิกายน ESR ส่งข้อความหกคำว่า “Commits are open. Have at it.”
  • การเปลี่ยนผ่านนี้ถูกบางคนอธิบายว่า heroic
  • หลังผ่านการถกเถียง 236 ข้อความในปี 2008, เกือบ 200 ข้อความในปี 2013, การดูแลของ Stefan, ปัญหา Bazaar ที่เกิดซ้ำ และระบบควบคุมเวอร์ชันที่ตายไปแล้ว ในที่สุด Emacs ก็ย้ายไป Git

หลังการย้าย: แม้แต่ผู้มีส่วนร่วมหลักก็ต้องเริ่มเรียน Git ใหม่

  • ในช่วงไม่กี่วันหลังการย้าย มีการเปิดเผยว่าผู้มีส่วนร่วมหลักจำนวนมากไม่เคยใช้ Git มาก่อน
  • ใน emacs-devel จึงมีเธรดถามวิธีใช้ Git ต่อเนื่องกัน
    • “This Is The Git Help Mailing List”
    • “git pull fails with merge conflicts. How can this possibly happen?”
    • “A simple git workflow for the rest of us”
    • “need help adjusting workflow to git”
    • “Good book on Git”
    • “Obscure error/warning/information message from git pull” ต่อเนื่องไปถึง 124 ข้อความ
  • เบื้องหลังที่ทำให้นักพัฒนาซึ่งทำงานกับโปรแกรมแก้ไขข้อความสำคัญมานาน ต้องมาถามคำถามพื้นฐานเรื่อง Git ก็คือ ช่วงเวลาที่ Emacs ยังอยู่กับ Bazaar ในขณะที่โลกภายนอกย้ายไปใช้ Git กันหมดแล้ว

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

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

 
GN⁺ 12 시간 전
ความคิดเห็นจาก Lobste.rs

  • ถ้าทำงานในโปรเจ็กต์ที่ rms เป็นคนนำ คงรู้สึกเหมือนจะ เสียสติจริงๆ

    • อ้อ ตอนนี้แฟลชแบ็กจาก why-cooperation-with-rms-is-impossible.au กลับมาเลย

  • เป็นประวัติศาสตร์ที่น่าทึ่งจริงๆ นานมาแล้วฉันเคยดูบรรยายที่มหาวิทยาลัยแห่งหนึ่งซึ่ง Mark Shuttleworth อธิบาย Bazaar ต้นฉบับ และไอเดียเรื่องระบบควบคุมเวอร์ชันแบบกระจายนั้นก็น่าสนใจมาก
    หลังจากนั้นก็มี bzr เวอร์ชันเขียนใหม่ออกมา และฉันก็อินมาก
    รู้สึกว่ามันสมเหตุสมผลกว่า Git มาก เลยทุ่มเวลาให้โปรเจ็กต์นี้อยู่หลายปี ทั้งร่วมคุยในเมลลิงลิสต์ ทำปลั๊กอิน และยังพยายามเขียนอัลกอริทึมเปรียบเทียบความต่างของโค้ดใหม่เป็น C เพื่อให้เร็วขึ้นด้วย
    สุดท้ายก็เห็นชัดว่า Git คือผู้ชนะ แต่กว่าจะยอมรับได้ก็ใช้เวลานานพอสมควร

  • จากสรุปนี้ ดูเหมือนว่า Richard Stallman ยังห้ามไม่ให้โปรเจ็กต์ Emacs ย้ายไป Git จนถึงปี 2013 หลังจากนั้นมีการบอกว่า Emacs ย้ายไป Git เป็นสองขั้นในปลายปี 2013 และปลายปี 2014 แต่หลังต้นปี 2013 ก็ไม่มีการพูดถึง Stallman อีกเลย
    เขาสนับสนุน Bazaar มาหลายปี แล้วหลังจากนั้นในเธรดเมลลิงลิสต์เขาไม่ได้โพสต์ข้อความคัดค้านแรงๆ อีกเลยจริงหรือ? หรือว่าระหว่างนั้นเขาสูญเสียอำนาจเหนือโปรเจ็กต์ Emacs ไปแล้ว?
    ในเธรดปี 2014 ที่ลิงก์ไว้ ฉันไม่เห็นอีเมลที่มีชื่อเขาเลย แต่อาจมีเธรดอื่นที่ไม่ได้ลิงก์ไว้ก็ได้ ตอนแรกฉันนึกว่านี่เป็นช่วงที่ Stallman ลาออกจากอะไรบางอย่างเพราะประเด็นถกเถียง แต่ก็ไม่ใช่ คงนึกสลับกับเรื่องอื่น Wikipedia บอกว่า Stallman ออกจาก Free Software Foundation ในปี 2019 และก็ไม่ได้ออกจาก GNU Project ด้วย

  • ฉันไม่ค่อยแน่ใจว่าต้องมีอะไรถึงจะทำให้โปรเจ็กต์หนึ่งกลายเป็น GNU project อย่างเป็นทางการ เป็นเพราะไลเซนส์หรือเปล่า? Git กับ Linux ต่างก็เป็น GPLv2-only ส่วน Bazaar เป็น GPLv2+ หรือเป็นเรื่องการโอนลิขสิทธิ์? เรื่องการโฮสต์อย่างรีโพซิทอรี ตัวติดตามปัญหา เมลลิงลิสต์ ฯลฯ? หรือเป็นชื่อที่มีคำนำหน้า “GNU” ซึ่งทำหน้าที่เหมือนตรารับรอง?
    ดูเหมือนว่าจะมีเส้นแบ่งสำคัญอะไรบางอย่างอยู่แน่ๆ แต่ฉันไม่ค่อยเข้าใจว่ามันคืออะไรและทำไมมันถึงสำคัญ
    แล้วก็ยังมี ข้อผิดพลาดต่างกันหนึ่งคำ ซ้ำๆ อีกด้วย:

    On November 13th, ESR posted a seven-word message:

    Commits are open. Have at it.

    [...]

    Six years of debate, [...] and it ended with seven words.
    อ้า พลาดโอกาสทองในการทำให้สมมาตรไปเลย

    • หมายถึงซอฟต์แวร์ที่ถูกระบุไว้อย่างชัดเจนว่าอยู่ภายใต้ GNU นี่คือรายการ: https://www.gnu.org/software/software.html#allgnupkgs
    • ในคำว่า “bazaar” มีตัวอักษร a อยู่กี่ตัว? :)

  • ราวๆ ปี 2014 ฉันเคยพยายามจะทำอะไรบางอย่างกับ mysql แต่สุดท้ายล้มเหลวอยู่ทั้งวันแค่กับการ clone รีโพซิทอรีและ checkout รีลีสบรานช์ ก่อนจะยอมแพ้ ตอนนี้รู้สึกอายน้อยลงไปมากแล้ว
    ก่อนหน้านั้นฉันใช้ CVS, Subversion และ Mercurial มาหลายปี เลยคิดว่าเป็นปัญหาที่เครือข่ายหรือคอมของตัวเอง จนกระทั่งมาอ่านบทความนี้ถึงได้รู้ว่า benchmark จริงของ bzr แย่ขนาดนั้น และทั้งที่ Canonical ใช้ bzr หนักมาก ก็ยัง ปลดทีม bzr ไปแล้วด้วย
    หลายปีต่อมา ตอนที่ฉันกลับไปทำงานอีกอย่างกับ mysql มันย้ายไป Git แล้ว และเพราะไม่ติดตั้งแต่ก่อนเริ่ม ฉันเลยได้ทำงานที่น่าสนใจจริงๆ

    Since I had no interesting books to read today, nor interesting films to watch, I decided to scavenge for the most intriguing content one can find online. I ended up reading the Linux kernel mailing lists, but those discussions seemed to be 18+, so I settled for the comparatively civil emacs-devel.
    นี่คือ ข้อความปฏิเสธความรับผิดชอบ แบบ “ไม่ครับ บทความนี้ไม่ได้เขียนโดย AI” ที่ยอดเยี่ยมที่สุดเท่าที่ฉันเคยเห็น

  • เป็นบทความที่ยอดเยี่ยม ฉันอยากเห็นมาตลอดว่าดราม่าใน เมลลิงลิสต์ แบบนี้ดำเนินไปอย่างไร แต่ไม่เคยกล้ากระโดดเข้าไปเองเลย การเล่าเรื่องและการคัดข้อความมาประกอบทำได้ดีมาก

  • สรุปประวัติศาสตร์ที่สับสนออกมาได้สนุกดี แต่อดคิดไม่ได้ว่าชื่อเรื่องน่าจะเป็น “The Most Bzr Emacs Saga” มากกว่า “The Most Emacs Bzr Saga” ไหม
    ถึงจะไม่ใช่ว่าใช้ “Emacs” เป็นคำคุณศัพท์ไม่ได้เลย แต่ก็ยังฟังแปลกอยู่ดี

  • Bazaar คือ ระบบควบคุมเวอร์ชัน ตัวแรกที่ฉันเคยใช้ ตอนนั้นฉันเพิ่งเริ่มเข้าสู่โลก Linux ผ่าน Ubuntu และ Canonical ก็ใช้ Launchpad สำหรับโฮสต์ซอร์สโค้ด
    ก่อนหน้านั้นฉันไม่เคยเอาโค้ดขึ้นที่ไหนเลย แต่พอใช้ Launchpad กับ Bazaar แล้วมันก็ดูเท่มาก แน่นอนว่าโปรเจ็กต์ของฉันเล็กเกินกว่าจะรู้สึกถึงปัญหาเรื่องประสิทธิภาพใดๆ