ถ้าผมจะสร้าง GitHub ในแบบของตัวเอง

 (matduggan.com)
4 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • forge สมัยใหม่อย่าง GitHub, GitLab, Gitea แม้จะต่างกันในรายละเอียด แต่ล้วนใช้โมเดลแบบ GitHub ร่วมกัน ทว่าแกนหลักของงานจริงกลับเกิดขึ้นในฟีเจอร์ของ forge อย่าง PR, Actions, Issues, Releases มากกว่าใน git
  • forge แบบใหม่ควรมี pre-commit hook แบบบังคับ ที่รันจากระยะไกลและให้ฟีดแบ็กก่อน push ไม่ใช่หลัง commit เพื่อช่วยลด commit วนซ้ำอย่าง Feature, fix, actually fix, asdfasdf
  • การอนุมัติ PR ควรไปไกลกว่าทางเลือกแบบอนุมัติ/ปฏิเสธ และรองรับการอนุมัติแบบอ่อนหรือการทำเครื่องหมายว่าไว้กลับมาดูอีกครั้งแบบ Gerrit รวมถึงให้การเปลี่ยนแปลงเล็ก ๆ ที่ผู้เขียนเป็นผู้ดูแลและ LLM ประเมินว่ามีความเสี่ยงต่ำผ่านได้อย่างยืดหยุ่นขึ้น
  • Stacked PR ควรเป็น ฟีเจอร์ระดับแกนหลัก ของทั้ง forge และ VCS และรีโพสิตอรีในเครื่องควรแทนสถานะทั้งหมดของรีโพสิตอรีได้ ไม่ใช่แค่โค้ดแต่รวมถึงการอนุมัติ PR และ issue ด้วย
  • ชุดที่ต้องการคือ JJ เป็น VCS, forge ใหม่ที่โฮสต์ได้เป็นหน่วยเล็ก ๆ และ Actions ที่รองรับลายเซ็น, SHA, และการทำงานแบบออฟไลน์ แต่ในยุคที่ GitHub ยังเป็นค่าเริ่มต้น ก็ยังไม่มีตัวเลือกทดแทนที่ชัดเจน

ปัญหาของ forge สมัยใหม่

  • GitHub, GitLab, Gitea แม้มีรายละเอียดต่างกัน แต่แทบทั้งหมดเดินตามโมเดลการออกแบบเดียวกัน และใกล้เคียงกับการที่เครื่องมืออื่นย้ายรูปแบบอุตสาหกรรมที่ GitHub วางไว้มาใช้
  • ฟังก์ชันส่วนใหญ่ของ forge ปัจจุบันแทบไม่เกี่ยวข้องกับ git โดยตรง และตัวไคลเอนต์ก็ห่างไกลจากวิธีใช้งานจริง
  • git เป็นระบบควบคุมเวอร์ชันแบบกระจายที่เหมาะกับสภาพแวดล้อมอย่างการพัฒนาเคอร์เนล ซึ่งส่งแพตช์ทางอีเมลไปยังผู้ดูแล และผู้ดูแลจะจัดการพื้นที่ของตัวเองพร้อมตัดสินใจว่าจะรวมเข้าหรือไม่ เป็นเวิร์กโฟลว์ที่อาศัยความเชื่อถือสูง
  • แต่ในที่ทำงานส่วนใหญ่ git ใกล้เคียงกับการเป็นแค่วิธี pull/push โค้ดจากรีโพสิตอรีที่เก็บอยู่ใน forge กลาง และงานสำคัญเกิดขึ้นใน forge
    • Pull Request กลายเป็นเครื่องมือบังคับใช้ หลักการสี่ตา
    • GitHub Actions ใช้รันทดสอบและ lint บน Pull Request เพื่อตรวจสอบทั้งการทำงานและการปฏิบัติตามข้อกำหนดขององค์กร
    • ตัวตนผู้ใช้ภายใน forge กลายเป็นเกณฑ์สำหรับยืนยันตัวผู้ใช้
    • Issues ใช้ติดตามปัญหาในโค้ด และ Releases ใช้สร้างรีลีสให้ผู้ใช้ดาวน์โหลด
  • ในเวิร์กโฟลว์แบบนี้ ฟีเจอร์ของ forge ที่ครอบบน git มีมากกว่า git เอง ดังนั้นถ้าจะสร้าง forge ใหม่ เหตุผลที่จะต้องผูกติดกับข้อจำกัดของ git ก็ลดลง

ฟีเจอร์ที่อยากได้ใน forge ใหม่

  • ฟีดแบ็กควรมาก่อน commit ไม่ใช่หลัง commit

    • PR ทั่วไปมักมี commit ต่อเนื่องอย่าง Feature, fix, fix, actually fix, please, asdfasdf
    • ถ้าวงจรฟีดแบ็กเกิดหลัง commit ผู้ใช้ก็ต้องทนทุกข์กับการแก้ไปเรื่อย ๆ จนดึก
    • forge ควรมี pre-commit hook แบบบังคับ ที่รันงานจากระยะไกล เพื่อให้ผู้ใช้ได้รับฟีดแบ็กก่อนจะ push

  • การอนุมัติ PR เป็นแบบสองทางเกินไป

    • ตอนนี้ PR มักถูกแบ่งเป็นแค่อนุมัติแล้วหรือยังไม่อนุมัติ แต่การรีวิวโค้ดจริงมีพื้นที่ตรงกลางมากกว่านั้น
    • ปฏิกิริยาแบบมนุษย์อย่าง “ตอนนี้โอเคก่อน เดี๋ยวค่อยจัดการทีหลัง” ก็ควรสื่อผ่านปุ่มได้
    • Gerrit มีโมเดลที่ดีกว่าในเรื่องนี้
    • ถ้าผู้ดูแลอนุมัติแบบอ่อน ก็ควรทำเครื่องหมายไว้เพื่อกลับมาดูอีกครั้งภายหลังได้

  • นโยบาย PR ควรยืดหยุ่นกว่านี้

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

  • Stacked PR ควรเป็นฟีเจอร์ระดับแกนหลัก

    • Stacked PR ทำให้การรีวิวและการทำความเข้าใจง่ายขึ้น
    • มันไม่ควรเป็นแค่ความสามารถเสริมจากเครื่องมือภายนอก VCS แต่ควรถูกปฏิบัติเป็น พลเมืองชั้นหนึ่ง ทั้งใน forge และ VCS

  • forge ไม่ควรพยายามทำทุกอย่าง

    • จำเป็นต้องมีการติดตาม issue แต่บอร์ด Kanban อาจไม่จำเป็น
    • ความจำเป็นของ Wiki ก็ยังน่าสงสัย
    • เครื่องมือที่ใส่ทุกอย่างลงไปสุดท้ายคุณภาพจะตก และแม้จะเพิ่มฟีเจอร์ได้ง่าย แต่ต้นทุนการบำรุงรักษาจะยังเกิดขึ้นต่อไปไม่ว่ามีคนใช้มากน้อยแค่ไหน
    • ถ้ามีใครเริ่มใช้ฟีเจอร์นั้นที่ไหนสักแห่ง ก็จะผูกติดกับมัน

  • หน่วยการโฮสต์ใหญ่เกินไป

    • การดูแล GitHub Enterprise เป็นงานใหญ่ และการดูแล GitLab ก็เป็นภาระที่มากพอสมควร
    • ผลิตภัณฑ์เหล่านี้เป็นระบบซับซ้อนที่มีชิ้นส่วนเคลื่อนไหวจำนวนมาก
    • ควรสร้างหน่วยโฮสต์ย่อยที่เล็กกว่า และเชื่อมมันเข้าด้วยกันเพื่อเป็นองค์กรเดียวได้
    • ไม่จำเป็นต้องเป็น federation ระดับโลก และแม้ต้องสร้างบัญชีแยกตามองค์กรก็ยังได้ แต่ระบบควรยืดหยุ่นพอที่องค์กรจะพูดได้ว่า “Raspberry Pi 12 เครื่องนี้คือองค์กรของฉัน”

  • รีโพสิตอรีในเครื่องควรแทนทั้งรีโพสิตอรี ไม่ใช่แค่โค้ด

    • สำเนาในเครื่องควรแทนทั้งรีโพสิตอรี ไม่ใช่แค่โค้ด แต่รวมถึงการอนุมัติ PR และ issue ด้วย
    • ควรอนุมัติ PR ได้ใน VCS เดียวกับที่ใช้ checkin โค้ด
    • ควรเปิดดู issue ได้เหมือนกับการไล่ดูไฟล์ในเครื่อง

  • ไม่จำเป็นต้องจ่ายต้นทุนการเก็บประวัติทั้งหมดตลอดเวลา

    • ถ้าจะทำงานร่วมกับทีมอย่างเหมาะสมก็ต้องออนไลน์อยู่แล้ว ดังนั้นไม่จำเป็นต้องบังคับให้แบกรับต้นทุนการเก็บทุกอย่างเสมอไป
    • VCS และ forge ควรทำงานร่วมกัน
    • ตอน clone รีโพสิตอรี ควรรับมาแค่ประวัติที่จำกัด และเมื่อพยายามย้อนกลับไปในอดีตก็ค่อยปลุก worker ขึ้นมาเพื่อนำสิ่งที่ต้องใช้จาก VCS
    • ไม่จำเป็นต้องส่งคำขอ clone ขนาดมหึมาไปยัง forge อยู่ตลอด เพียงเพราะสมมติว่าผู้ใช้อาจอยากสร้าง forge ขึ้นมาใหม่จากประวัติโครงการทั้งหมดในสักวันหนึ่ง

  • Actions ควรมีลายเซ็น มี SHA และใช้แบบออฟไลน์ได้

    • Actions มีความสำคัญ จึงควรรองรับ ลายเซ็น, SHA และการใช้งานแบบออฟไลน์
    • หากต้องการ ก็ควรดาวน์โหลด tarball ของทุก action มาเก็บไว้ในรีโพสิตอรีได้ และสั่งระบบไม่ให้ดึง checkout action จากภายนอก แต่ใช้ตัวที่อยู่ในรีโพสิตอรีแทน
    • ถ้าระบุ latest ก็ควรทำงานแบบเปิด PR เพื่อนำ tarball ล่าสุดเข้ามาในรีโพสิตอรี เหมือนกับ Dependabot ในปัจจุบัน
    • หากต้องการ Actions ก็ควรรันบนเครื่องโลคัลผ่าน VCS เดียวกันได้เช่นกัน

มีเครื่องมือที่ทำได้บางส่วนแล้ว แต่ต้องการการผสานกัน

  • มีเครื่องมือจำนวนมากที่ทำข้อกำหนดเหล่านี้ได้บางส่วนอยู่แล้ว
  • สิ่งที่ต้องการคือการนำเครื่องมือเหล่านี้มาผูกเข้าด้วยกันและทำให้มันเข้ากันอย่างเหมาะสม
  • ชุดที่ต้องการคือ JJ เป็น VCS, ระบบใหม่เป็น forge และความคาดหวังว่าผู้ใช้จะสามารถใช้ Raspberry Pi เครื่องเดียวเป็น forge ได้อย่างน่าพอใจไปอีกนาน
  • forge ใหม่ควรถูกออกแบบโดยมีแนวคิดสมัยใหม่อย่าง object storage, shallow clone และคำขอต่อเนื่องจากบอต LLM เป็นศูนย์กลาง

รอยร้าวในยุคที่ GitHub เป็นค่าเริ่มต้น

  • ถ้า GitHub ทำได้ดีอยู่แล้ว ก็คงไม่จำเป็นต้องเขียนภาพฝันแบบนี้
  • GitHub คือค่าเริ่มต้น และการพยายามโน้มน้าวให้คนขยับออกจากค่าเริ่มต้นก็มักใกล้เคียงกับการเสียเวลา
  • ถ้าจะใช้ forge ไปจนถึงปี 2026 ก็ต้องมีเหตุผลที่หนักแน่นมากที่จะไม่เลือกเครื่องมือที่ทุกคนใช้
  • จนไม่นานมานี้ forge อื่น ๆ ก็ยังถูกมองว่าเป็นเพียงของทดแทน มากกว่าจะเป็นตัวเลือกที่อยากได้จริง
  • แต่ forge ขนาดยักษ์เพียงตัวเดียวกำลังพังลง และยังไม่มีผู้ทดแทนถูกสร้างขึ้น
  • คนที่มีเงินกำลังยุ่งกับจรวด คนที่มีรสนิยมกำลังยุ่งกับงานหลัก ส่วนที่เหลือก็เปิด PR ชื่อ asdfasdf ตอนเที่ยงคืน รอการตรวจจากบอต และตั้งคำถามว่าเมื่อไหร่กันที่เครื่องมือที่ใช้ทั้งวันถึงเลิกถูกสร้างมาเพื่อผู้ใช้

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

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

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Hacker News

  • มีคนวิจารณ์ว่า การอนุมัติ PR เป็นอะไรที่แบ่งขาวดำเกินไป ซึ่งฟังดูขัดแย้งกันเอง เพราะการอนุมัติ PR คือการให้สิทธิ์ สุดท้ายจึงหนีไม่พ้นที่จะเป็นค่าแบบบูลีน จะรวมโค้ดได้หรือไม่ได้ก็มีแค่สองทาง
    สิ่งที่พูดกันตรงนี้ดูจะเป็นกลไกช่วยให้รู้สึกสบายใจขึ้นเล็กน้อย เวลาต้องอนุมัติโค้ดที่ตัวเองไม่ชอบ พร้อมแนวคำพูดอย่าง “ไว้ค่อยกลับมาดูอีกที...” มากกว่า แค่เปิดตั๋วใหม่ขึ้นมาก็พอ

    • Gerrit มีตั้งแต่ -2 ถึง +2
      -2: เป็นไอเดียที่ไม่ดี อย่าทำ
      -1: เป็นไอเดียที่ดี แต่ยังต้องปรับปรุง
      +1: ดูดี แต่ยังไม่มีความรู้หรือสิทธิ์พอจะอนุมัติ
      +2: อนุมัติ
    • อยากให้มีปุ่มที่พูดได้ว่า “3 commit นี้อนุมัติและรวมได้เลยตอนนี้ ส่วนอีก 2 commit นี้ต้องแก้ใหม่”
    • บางครั้งโค้ดได้รับการอนุมัติแล้วแต่ยังไม่ถูก merge ในกรณีนี้แอดมินอาจเพิ่มการเปลี่ยนแปลงแล้ว apply แบบแมนนวล และใส่ผู้เขียน PR เป็นผู้ร่วมเขียนของ commit ที่เปลี่ยนแปลงนั้นได้ด้วย
    • ปัญหาที่ใหญ่กว่าดูจะเป็นเรื่องที่ GitHub แยกขาดจากระบบติดตาม issue มากเกินไป ต้องคอยซิงก์กันด้วยมืออยู่ตลอด ภาระตรงนี้หนักมาก และถึง Linear จะช่วยได้ระดับหนึ่งก็ยังไม่ใช่สิ่งที่เหมาะที่สุด
    • จะบอกว่า “จะรวมโค้ดได้หรือไม่ได้ก็มีแค่สองทาง” งั้นหรือ ดูท่าคงไม่ใช่พวก intuitionist

  • ที่บอกว่า “Y ก็ทำได้บางส่วน” นั้นก็จริง แต่ tangled.org ทำได้เกือบทั้งหมดจริง ๆ

    1. ใช้ JJ เป็นระบบควบคุมเวอร์ชัน: tangled รองรับ stacked PR ผ่าน jj change-id https://blog.tangled.org/stacking ตัว tangled เองก็สร้างด้วยวิธีนี้เยอะมาก: https://tangled.org/tangled.org/core/pulls
    2. เป็น forge ที่รันบน Raspberry Pi ได้นาน ๆ: อันนี้ก็ทำได้ git server shim เบามาก เป็นแค่ชั้น XRPC บน git repository กับฐานข้อมูล sqlite3 มีคนรันบนบอร์ด RISC-V ที่มี RAM 512MB ด้วย
    3. Actions สำคัญและควรรันบนเครื่องโลคัลได้: มองว่าความต้องการนี้คลาดเป้าไปนิด งานทำให้ปิดล้อม รันได้ทุกที่ และรองรับ cross-build โดยทั่วไปควรเป็นหน้าที่ของระบบ build มากกว่า ถ้าสามารถ “ยกระดับ” ผล build แบบนั้นเข้ามาในตัว forge ได้ก็น่าจะดีมาก
    • แปลกใจที่มีการพูดถึง Raspberry Pi สำหรับโฮสต์ข้อมูลสำคัญของ workflow เมื่อก่อนฉันเจอปัญหา SD card พังมาเยอะมาก เลยสงสัยว่าตอนนี้ใช้ไดรฟ์ NVME กันหรือยัง
    • ใช่ นั่นเป็นหน้าที่ของระบบ build แต่ปัญหาที่คนอยากแก้ด้วย Actions ที่รันโลคัลได้ ส่วนใหญ่ไม่ใช่ตัว build ล้มเหลวเอง แต่เป็นเรื่องการรวมระบบทั้งหมด
      อย่างนิยาม YAML, secret, คำสั่งที่รันจริงเป๊ะ ๆ, การกู้คืนเครื่องมือและ cache ทำอย่างไร ระบบ build อาจช่วยได้บางส่วน แต่ primitive ที่ GHA ให้มานั้นอ่อนมาก สุดท้ายก็วนกลับไปเป็นปัญหาว่าต้องไปรันทั้งระบบที่อื่น ทำให้ระบบแบบนี้มักต้องอาศัยการลองผิดลองถูก
    • ใช่ และยิ่งกว่านั้นคืออยากขยายแนวคิดเรื่อง hermetic build ให้รันได้ง่ายทั้งบนเครื่องตัวเองหรือที่ไหนก็ตามที่มีทรัพยากรประมวลผล
      ปัญหาพื้นฐานที่กำลังพูดถึงคือการวนลูปที่มีทั้งการแก้ไข, commit, network call ปนกันไป แล้วคอยรันจนกว่า CI จะเขียว ซึ่งทรมานมาก วิธีที่ดีที่สุดในการเลี่ยงลูปนี้คืออย่าเขียนบั๊กเลย! ล้อเล่นนะ
    • ทั้ง Radicle และ Tangled พลาดประเด็นสำคัญ ทั้งคู่ทำมาเพื่อการทำงานร่วมกันแบบสาธารณะ แล้ว private repository จะทำอย่างไร? ผู้ใช้จำนวนมากมี side project และใช้ GitHub private เพื่อการนั้น
      พอคนเรียนรู้ GitHub แล้วก็มักเริ่มโปรเจกต์สาธารณะบน GitHub ด้วย ถ้ายังไม่เปิดให้สร้าง private repo สำหรับ side project ได้ ก็ยากจะถูกใช้อย่างแพร่หลาย สิ่งที่คนต้องการคือสร้าง private repo แล้วหายไปหลายเดือน กลับมาก็ยังมีมันรออยู่เหมือนเดิม
    • ว้าว การรองรับ jujutsu ของ Tangled คือสิ่งที่กำลังหาอยู่พอดี สุดสัปดาห์นี้คงหมดไปกับการเซ็ต self-hosting

  • ถ้าอยาก clone มาแค่ประวัติที่จำกัดและค่อยดึงข้อมูลเก่าเพิ่มเมื่อจำเป็น ให้ใช้ blobless clone
    git clone --filter=blob:none
    มันจะดึง history มาก่อน แล้วค่อยดึง blob เมื่อจำเป็น GitHub มีบทความดี ๆ อยู่: https://github.blog/open-source/git/get-up-to-speed-with-par...

  • เมื่อวิธีแก้กลายเป็นตัวปัญหา ก็เป็นจังหวะของ disruptive innovation ช่วงนี้มีคนพูดเรื่องนี้เยอะพอสมควร และก็สงสัยว่าก่อนที่ GitHub จะปรับทิศทางใหม่ หนึ่งในทางเลือกใหม่ ๆ ที่โผล่มาจำนวนมากจะมีสักรายที่ได้แรงส่งหรือไม่

    • ผมว่าปัญหาคือ Microsoft ทุ่มสุดตัวกับ AI ไปแล้ว ไม่มีทางถอย และ GitHub ก็หนีผลกระทบนี้ไม่พ้น
      ฝั่งประชาสัมพันธ์ของ Microsoft คงบอกว่า AI คือคำตอบของทุกอย่าง แต่ในโลกจริงปัญหาเดิม ๆ จะยังวนกลับมา แม้ outage ของ GitHub จะไม่ได้เกี่ยวกับ AI โดยตรง แต่เพราะกลยุทธ์ของ Microsoft เปลี่ยนไปแล้ว การตัดสินใจส่วนใหญ่ก็จะถูกจัดให้สอดคล้องกับการควบคุมจากบนลงล่างที่มี AI เป็นศูนย์กลางอยู่ดี workflow ของคนใช้ GitHub จะพังไหม สำหรับ Microsoft น่าจะเป็นแค่เรื่องรอง ๆ และปัญหานั้นจะโผล่กลับมาเรื่อย ๆ อาจเงียบไปสัก 3 เดือนได้ แต่ไม่นานก็คงมีดราม่าใหม่ว่า GitHub กำลังเสื่อมอีกแน่นอน Ghostty คงไม่ใช่รายสุดท้าย จะมีทางเลือกใหม่เกิดขึ้นไหมก็น่าสนใจ แต่ทางเลือกเหล่านั้นก็ห้ามห่วย เพราะหลายเว็บไซต์ตอนนี้ก็แย่อยู่พอควร
    • ผมกำลังสร้างเครื่องมือของตัวเองอยู่ และคิดว่าคนอื่นก็ควร สร้างเครื่องมือของตัวเอง เช่นกัน
      อนาคตเราอาจไม่ได้รับซอฟต์แวร์แบบเสียเงินหรือโอเพนซอร์ส แต่จะได้ชุดเอกสารความต้องการสำหรับ code forge คล้ายสูตรอาหาร แต่ละคนก็เอาไปอบเอง แล้วปรับให้เข้ากับงานและรสนิยมของตัวเอง

  • คิดว่ายังมีช่องว่างตลาดสำหรับ บริการ git ที่เรียบง่ายกว่านี้ สิ่งที่ต้องการมีแค่ remote host สำหรับ push โปรเจกต์ให้คนอื่นเห็น ไม่ได้อยากได้ PR หรือ Actions อะไรพวกนั้น
    ถ้ามีฟีเจอร์ “release” สำหรับอัปโหลด binary asset ที่ build จากเครื่องโลคัลได้ก็คงดี ส่วน fork ก็ให้คน clone repository แล้วอัปขึ้นเป็นโปรเจกต์ใหม่เองก็ได้

    • ถ้าปิดฟีเจอร์ที่ไม่ต้องการ มันก็แก้ได้หลายอย่างไม่ใช่หรือ? เมื่อกี้ผมเพิ่งดูอินสแตนซ์ Forgejo ของตัวเอง มีตัวเลือกปิด Code, Projects, Releases, Packages, Actions, Issues, PRs, Wikis แยกตาม repository ได้
    • https://sr.ht/
    • งั้นก็กลับไปใช้ cgit กันอีกครั้งหรือ?

  • ข้อเสนอที่ว่าเอาข้อมูลรีวิวไปเก็บใน git repository เหมือนซอร์สด้วยนั้นฟังดูน่าเชื่อพอสมควร
    ถ้าตั้ง branch แยกต่อรีวิวโดยใช้คำนำหน้าที่รู้กันอยู่แล้ว ก็ทำได้ง่ายมาก แต่ namespace ของ branch ปกติคงจะรกอย่างรวดเร็ว อาจใช้ git namespaces เพื่อแยกจาก namespace หลัก หรือมี branch พิเศษอย่าง .reviews ที่เก็บแค่ commit ID ปลายทางของแต่ละ review branch ก็ได้ ถ้ามีใครสนใจมากพอจนทำสเปกกับ implementation ที่ใช้งานได้จริงออกมา คนก็อาจเริ่มรับไปใช้ เหตุผลที่ GitHub กับ forge หลายแห่งไม่เลือกแนวนี้น่าจะเป็นเพราะ metadata ของการรีวิวเป็นคุณค่าของแพลตฟอร์ม ถ้าใคร ๆ ก็ใช้เครื่องมือโลคัลที่อยากใช้มาทำ code review ของคนอื่นได้ ก็จะลด vendor lock-in ลง แต่อีกด้านหนึ่งก็อาจมีเหตุผลอื่น เช่น access control หรือกรณีรีวิวข้าม repository ที่อยากเก็บ metadata ของรีวิวไว้อีก repository หนึ่ง

    • เมื่อก่อนก็มีความพยายามแบบนี้อยู่บ้าง ตอนที่ผู้คนยังแคร์การทำงานแบบออฟไลน์และส่งต่อหลังบันทึกอยู่[1] อย่าง Bugs Everywhere[3], git-appraise[4] ที่เก็บข้อมูลไว้ใน namespace “notes” ที่คนไม่ค่อยรู้จักของ Git[5], และ git-bug[6] ที่ทุกวันนี้โผล่ในกระทู้แนวนี้บ่อยกว่าสิ่งอื่นมาก
      ถ้าดูเฉพาะการเข้าถึงแบบอ่านอย่างเดียว ข้อมูลรีวิวของ Gerrit ก็เข้าถึงผ่าน Git ได้จริงด้วย[7] ถ้าเป็นรีวิว ABCDE แทนที่จะดึง ref หมายเลขปกติใต้คำนำหน้านั้น ก็ให้ pull refs/changes/DE/ABCDE/meta แทน และก็มีคนทำให้เข้าถึงผ่าน Git notes ได้ด้วย[8] Fossil SCM ที่ขึ้นชื่อเรื่อง SQLite ก็ทำแบบนี้กับตัวติดตามบั๊กในตัว[9] แต่ที่มันไม่ดังนักก็เพราะอุบัติเหตุทางประวัติศาสตร์ที่ Git เป็นฝ่ายชนะ และเพราะมันเป็นสิ่งที่ไม่เป็นมิตรอย่างมากกับการ rewrite history ซึ่งคนใช้ Git ทำกันบ่อย กลับมาที่เรื่องการทำงานบน Git อีกครั้ง เวลาอยากสร้าง data type สวย ๆ จริง ๆ แล้วคุณต้องมี custom merge strategy และการรองรับของ Git เองก็ยังต้องห่อเพิ่มอีกมากกว่าจะทำให้ลื่นไหล ตัวอย่างที่ผมรู้ว่าไปได้ดีคือการติดตามตำแหน่งของ git-annex[10] แต่นั่นก็ยังเป็นโปรเจกต์ Haskell ขนาดใหญ่พอสมควร porcelain ที่มีอยู่แข็งทื่อเกินไป
      [1] ขอ PGP replacement ที่เหมาะกับงานนั้นได้ไหม? ขออย่างเดียวคือเลิกบอกว่ามันไม่มีอยู่จริงหรือบอกให้ฉันเลิกใช้สักที[2]
      [2] https://news.ycombinator.com/item?id=44239804
      [3] https://github.com/aaiyer/bugseverywhere
      [4] https://github.com/google/git-appraise
      [5] https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coo..., https://news.ycombinator.com/item?id=44345334 (579 points, 146 comments)
      [6] https://github.com/git-bug/git-bug
      [7] https://gerrit-review.googlesource.com/Documentation/note-db...
      [8] https://gerrit.googlesource.com/plugins/reviewnotes/+/refs/h...
      [9] https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki
      [10] https://git-annex.branchable.com/

  • ผมชอบ workflow ของ Gerrit ที่รีวิวความต่างแทนการใช้ PR มาก แต่เมื่อเทียบกับของอย่าง gitea แล้ว มันขาดฟีเจอร์อื่น ๆ ที่ผู้คนคาดหวังจาก git hosting เช่น issue, การวางแผนโปรเจกต์ ฯลฯ เลยดูยากที่จะโน้มน้าวคนจำนวนมาก
    ถ้ามีแพลตฟอร์มรีวิว diff ดี ๆ แบบ Phabricator ก็คงดี น่าเสียดาย

    • แล้วทำไม Gitea ถึงไม่เพิ่มสิ่งนั้นล่ะ? ของอื่นมันก็มีครบแล้ว ไม่เข้าใจว่าทำไม forge พวกนี้ถึงชอบหยุดอยู่แค่การเป็นร่างโคลนของ GitHub แล้วไม่ก้าวไปไกลกว่านั้น

  • ผมคิดว่าควรใช้ RFC2822 เป็นรูปแบบพื้นฐานสำหรับเก็บข้อความทั้งหมด ไม่ว่าจะเป็น PR, คอมเมนต์รีวิว, issue และเวลาจะแสดงข้อความก็ค่อยตกแต่งด้วย CommonMark
    metadata ทั้งหมดใส่ไว้ใน header ได้ และเชื่อมข้อความเข้าหากันด้วย header Message-ID/In-Reply-To/References การใช้รูปแบบที่นิยามชัดเจนแบบนี้ทำให้คุณเลือกได้ว่าจะเก็บและส่งข้อความทั้งหมดอย่างไร จะใส่ใน git repository, ใช้อีเมล หรือวิธีอื่นที่เหมาะสมก็ได้ สำหรับ code review ส่วนตัวผมคิดว่า Gerrit ดีกว่า GitHub และเจ้าอื่น ๆ มาก ส่วน CI อยากให้แยกออกไปให้มากที่สุด และมีแค่ hook สำหรับเริ่ม pipeline, แสดงผลลัพธ์ และตัดสินว่าจะอนุญาตให้ merge หรือไม่

    • ผมว่าความน่าสนใจอย่างหนึ่งของ GitHub คือมัน รวม code review, การสำรวจซอร์ส, การติดตามตั๋ว, CI ทั้งสี่อย่างเข้าด้วยกัน
      มันไม่ได้เก่งเป็นพิเศษในทั้งสี่ด้าน แต่เก่งเรื่องการผูกทุกอย่างไว้ด้วยกัน ผมเห็นด้วยว่า Gerrit มีโมเดล code review ที่ดีกว่า แต่ถ้าไม่มีอีกสามชิ้นที่เหลือก็ยังไม่เป็นผลิตภัณฑ์ แม้แต่ตอนที่ผมใช้ Gerrit ทุกวันใน Google ก็ยังหงุดหงิดกับการเชื่อมต่ออันหละหลวมระหว่างการค้นหาโค้ด, code review และ CI ขณะที่เครื่องมือภายในของ Google อย่าง Google3/Critique/Forge กลับผูกทุกอย่างเข้าด้วยกันได้ดีกว่ามาก

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

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

  • ตอนที่ Microsoft เข้าครอบ GitHub ก็มีหลายคนหงุดหงิดอยู่แล้ว แต่ในความเป็นจริงทางเลือกต่าง ๆ มักไม่ค่อยดีนัก Sourceforge ทำ issue ทีไรน่ารำคาญไม่รู้จบ ส่วน GitLab แม้จะดีกว่า Sourceforge แต่ผมก็ยังไม่ชอบสร้าง issue ที่นั่น Codeberg เหมือนเพิ่งเปลี่ยน UI ไปไม่นานนี้ แต่ก็ยังใช้งานยากอยู่มาก
    สิ่งที่ GitHub ทำได้ดีในช่วงแรกคือ UI และการโฟกัสที่การทำเรื่องต่าง ๆ ให้คนที่ใช้ GitHub ทำได้ง่ายหรืออย่างน้อยก็ง่ายขึ้น แต่ก็ไม่ได้ทำดีไปหมด ผมว่า support ด้าน wiki แย่มาก แย่จนแทบไม่เคยใช้เลย ปัญหาใหญ่มากจริง ๆ สำหรับผมคือเรื่อง ผลประโยชน์ทางการค้า หรือก็คือผลประโยชน์ส่วนตัว Microsoft เป็นแค่ตัวอย่างหนึ่ง ปัญหานี้มีแทบทุกเว็บไซต์แนวเดียวกัน ผมเคยยกกรณีการถก issue เกี่ยวกับยูทิลิตี้ backdoor ของ xz และผมก็ร่วมคุยด้วย วันถัดมา Microsoft ลบทุกอย่างออกหมด จะเป็น Microsoft หรือเจ้าของ repository ก็ไม่สำคัญ ประเด็นคือคนคนเดียวสามารถเซ็นเซอร์ข้อมูลที่อาจมีประโยชน์ได้ง่ายเกินไป การสนทนาใน issue นั้นมีประโยชน์และมันถูกเซ็นเซอร์ เท่าที่จำได้ ข้อมูลตอนนั้นไม่ได้ถูกกู้กลับมาทั้งหมด อาจมีใคร mirror ไว้ แต่ผมไม่เห็นลิงก์ นี่แสดงให้เห็นว่า การควบคุมจากบนลงล่าง อาจเป็นพิษได้จริง ๆ พูดตามตรง คุณจะไว้ใจ Microsoft ได้แค่ไหน? เราต้องการสิ่งที่กระจายศูนย์ ทำงานได้เสถียร มี UI เริ่มต้นที่ดี และมี workflow ที่เรียบง่าย หรืออย่างน้อยก็เป็น workflow ที่ดี อีกทั้งต้องเลี่ยงสถานการณ์ที่ผู้เล่นเอกชนจับทุกคนเป็นตัวประกันด้วย ผมไม่รู้เลยว่าจะแก้อย่างไร และอาจต้องใช้หลายแนวทางพร้อมกัน เว็บเปลี่ยนไปแล้ว และโดยเฉพาะผลประโยชน์ส่วนตัวของบริษัทยักษ์ใหญ่ในช่วง 10–15 ปีที่ผ่านมา ทำให้ทุกอย่างแย่ลงมาก มันต้องเปลี่ยน

    • ปัญหาคือการ ให้บริการผลิตภัณฑ์แบบ SaaS มีค่าใช้จ่ายสูงมาก
      บริษัทยักษ์ใหญ่จ่ายต้นทุนนี้ได้ แต่ถึงนักพัฒนาจำนวนมากที่งบไม่เยอะจะรวมตัวกัน ก็ไม่มีเงินพอจะทำสิ่งเดียวกันได้ ดังนั้นโปรเจกต์เชิงพาณิชย์แบบไหนก็ตาม สุดท้ายก็เลี่ยงยากที่จะเอนเอียงไปสนับสนุนผลประโยชน์ของบริษัทยักษ์ใหญ่มากกว่าคนทั่วไป