pgBackRest ไม่ได้รับการบำรุงรักษาอีกต่อไป

• เป็นเครื่องมือสำรองและกู้คืนข้อมูลสำหรับ PostgreSQL ที่ออกแบบมาให้ขยายไปใช้ในสภาพแวดล้อมขนาดใหญ่ได้ แต่ตอนนี้ได้ยุติการบำรุงรักษาแล้ว
• การแก้บั๊ก, การรีวิว PR, การตอบสนองต่อ issue และการพัฒนาฟีเจอร์ใหม่ทั้งหมดได้หยุดลง และเลือกที่จะหยุดอย่างชัดเจนแทนการฝืนดูแลต่อแบบไม่สม่ำเสมอ
• รองรับการสำรองข้อมูลแบบ full, differential, incremental และ block-level backup, การทำงานต่อจากงานที่หยุดค้างไว้, และ delta restore เพื่อให้บันทึกและกู้คืนเฉพาะส่วนที่เปลี่ยนแปลงได้
• มี protocol layer ที่ครอบคลุมทั้งสภาพแวดล้อมแบบ local และ remote รวมถึง multiple repositories และขยายขอบเขตการใช้งานผ่านการเชื่อมต่อ TLS·SSH และ object store ที่เข้ากันได้กับ S3·Azure·GCS
• เป็นเครื่องมือที่มีกลไกประกันความถูกต้องสมบูรณ์ของข้อมูลอย่างกว้างขวาง เช่น checksum, การรอ WAL segment, fsync, การตรวจสอบ page checksum แต่ต่อจากนี้แม้จะมี fork เกิดขึ้นก็จำเป็นต้องสร้างความน่าเชื่อถือขึ้นมาใหม่แยกต่างหาก

---

การยุติการบำรุงรักษาและสถานะของโครงการ

• pgBackRest เป็นเครื่องมือสำรองและกู้คืนข้อมูลสำหรับ PostgreSQL แต่ในตอนนี้ไม่ได้รับการบำรุงรักษาอีกต่อไป
• โครงการได้หยุดการทำงานแล้ว และระบุว่าจะไม่ใช้เวลาไปกับการแก้บั๊ก, รีวิว PR, ตอบสนองต่อ issue หรือพัฒนาฟีเจอร์ใหม่อีกต่อไป
• แม้จะพยายามดูแลต่อหลังจากการสนับสนุนและรูปแบบการจ้างงานเดิมสิ้นสุดลง แต่ก็ไม่สามารถหามาได้เพียงพอทั้ง โอกาสด้านงาน และ การสนับสนุนจากสปอนเซอร์ สำหรับการดูแลโครงการต่อ
• มองว่าการยุติอย่างชัดเจนนั้นดีกว่าการดูแลต่อไปแบบไม่สม่ำเสมอหรือไม่สมบูรณ์
• ในอนาคตอาจมีคน fork ได้ แต่ในกรณีนั้นจะถือเป็นโครงการใหม่ และผู้ดูแลใหม่จะต้องสร้างความน่าเชื่อถือขึ้นมาเองแยกต่างหาก

ฟีเจอร์หลักของโครงการ

• มุ่งเป้าไปที่การสำรองและกู้คืนข้อมูลที่ขยายไปได้ถึงสภาพแวดล้อม PostgreSQL ขนาดใหญ่ และเวอร์ชันเสถียรปัจจุบันคือ v2.58.0
• ออกแบบมาให้ลดต้นทุนด้านการบีบอัดซึ่งมักเป็นคอขวดระหว่างการสำรองข้อมูล โดยใช้การประมวลผลแบบขนานและวิธีบีบอัดอย่าง lz4, zstd
• รองรับการสำรองข้อมูลแบบ full, differential, incremental และไม่ใช่แค่ระดับไฟล์ แต่ยังมี block-level backup เพื่อคัดลอกเฉพาะส่วนที่เปลี่ยนแปลงและประหยัดพื้นที่จัดเก็บ
• สามารถทำการสำรองข้อมูลต่อจากที่หยุดค้างไว้ได้ และตรวจสอบความถูกต้องของไฟล์ที่คัดลอกไปแล้วอีกครั้งโดยเทียบกับ checksum ใน manifest
• ใน delta restore จะลบไฟล์ที่ไม่มีอยู่ในแบ็กอัปออกก่อน จากนั้นเทียบ checksum ของไฟล์ที่เหลือ โดยคงไฟล์ที่ตรงกันไว้ และกู้คืนเฉพาะไฟล์ที่จำเป็น

การทำงานระยะไกลและการออกแบบ repository

• ผ่าน protocol layer ของตัวเอง สามารถทำงานสำรองข้อมูล กู้คืน และ archive ได้ทั้งในสภาพแวดล้อม local และ remote โดยใช้ TLS/SSH สำหรับการเชื่อมต่อระยะไกล
• protocol layer เดียวกันนี้ยังมีอินเทอร์เฟซสำหรับ query PostgreSQL ทำให้สามารถทำงานได้โดยไม่ต้องเชื่อมต่อระยะไกลเข้าสู่ PostgreSQL โดยตรง จึงช่วยเพิ่มความปลอดภัย
• รองรับ multiple repositories ทำให้สามารถมีทั้งที่เก็บข้อมูล local สำหรับการกู้คืนอย่างรวดเร็ว และที่เก็บข้อมูล remote สำหรับการเก็บระยะยาวและเพิ่มความซ้ำซ้อน
• repository ยังสามารถอยู่บน object store ที่เข้ากันได้กับ S3, Azure, GCS ได้ จึงขยายทั้งความจุและระยะเวลาการเก็บรักษาได้มาก
• สามารถเข้ารหัส repository เองได้ จึงปกป้องข้อมูลสำรองได้ไม่ว่าจะเก็บไว้ที่ใด

วิธีรับประกันความถูกต้องสมบูรณ์และความสอดคล้อง

• คำนวณ checksum สำหรับทุกไฟล์ของแบ็กอัป และตรวจสอบซ้ำอีกครั้งตอน restore หรือ verify
• หลังคัดลอกไฟล์เสร็จ จะรอจนกว่า WAL segment ทั้งหมดที่จำเป็นสำหรับทำให้แบ็กอัปอยู่ในสถานะสอดคล้องกันจะมาถึง repository
• ใช้ fsync ในระดับไฟล์และไดเรกทอรีสำหรับทุกงานเพื่อให้มั่นใจในความคงทนของข้อมูล
• หาก PostgreSQL เปิดใช้ page checksum จะตรวจสอบ page checksum ของทุกไฟล์ในการสำรองแบบ full และตรวจสอบเฉพาะไฟล์ที่เปลี่ยนแปลงในการสำรองแบบ differential·incremental
• แม้การตรวจสอบ page checksum จะล้มเหลว แบ็กอัปก็จะไม่หยุด แต่จะทิ้งคำเตือนไว้ว่าหน้าใดล้มเหลว เพื่อให้ค้นหา page-level corruption ได้ตั้งแต่เนิ่น ๆ ก่อนที่แบ็กอัปที่ยังใช้ได้จะหมดอายุ

การจัดการ WAL และการปรับแต่งประสิทธิภาพการกู้คืน

• มีคำสั่งเฉพาะสำหรับ WAL push/get และทั้งสองแบบรองรับการประมวลผลขนานกับการทำงานแบบ asynchronous เพื่อให้ออกแบบมาให้กระทบเวลาตอบสนองของ PostgreSQL ให้น้อยที่สุด
• WAL push จะลบข้อมูลซ้ำโดยอัตโนมัติเมื่อมี WAL segment เดียวกันเข้ามาหลายครั้ง และหากเนื้อหาแตกต่างกันจะเกิดข้อผิดพลาด
• asynchronous WAL push ให้โปรเซสอื่นรับหน้าที่ส่งและบีบอัด WAL segment แบบขนาน จึงมีความสำคัญอย่างยิ่งกับฐานข้อมูลที่มีปริมาณการเขียนสูงมาก
• asynchronous WAL get จะเก็บ WAL queue ที่คลายการบีบอัดแล้ว ไว้ในเครื่อง เพื่อให้ส่งต่อได้ทันที قبل replay และมีประโยชน์มากเป็นพิเศษกับการเชื่อมต่อที่มี latency สูงหรือ storage อย่าง S3
• ทั้ง WAL push และ get จะเปรียบเทียบเวอร์ชันของ PostgreSQL และ system identifier เพื่อตรวจสอบว่าฐานข้อมูลกับ repository ตรงกันหรือไม่ จึงช่วยลดโอกาสในการตั้งค่าตำแหน่ง WAL archive ผิดอย่างมาก

ความยืดหยุ่นในการใช้งานและความเข้ากันได้

• สามารถตั้งนโยบาย backup retention และ archive expiration แยกตามหน่วย full, differential และ WAL ได้ จึงครอบคลุมช่วงเวลาที่ต้องการได้
• สามารถจัดเก็บแบ็กอัปในรูปแบบ PostgreSQL cluster เดิมได้ และหากปิดการบีบอัดพร้อมเปิด hard link ก็สามารถบูต PostgreSQL cluster ขึ้นได้โดยตรงบน snapshot ของ repository
• วิธีนี้เหมาะกับ ฐานข้อมูลระดับเทราไบต์ ที่การ restore แบบดั้งเดิมใช้เวลานาน
• รองรับ tablespace อย่างสมบูรณ์ และระหว่าง restore สามารถย้ายแต่ละ tablespace ไปยังตำแหน่งอื่น หรือ remap ทั้งหมดไปยังตำแหน่งเดียวได้
• รองรับลิงก์ของไฟล์และไดเรกทอรีด้วย ทำให้ระหว่าง restore สามารถคงตำแหน่งเดิม, remap บางส่วนหรือทั้งหมด, หรือกู้คืนโดยแปลงเป็นไฟล์และไดเรกทอรีปกติได้
• รองรับ PostgreSQL 10 เวอร์ชัน โดยครอบคลุมทั้ง 5 เวอร์ชันที่ยังรองรับอยู่ในปัจจุบันและ 5 เวอร์ชันล่าสุดที่ EOL แล้ว เพื่อเผื่อเวลาในการอัปเกรดได้อย่างเพียงพอ

แหล่งข้อมูลอ้างอิงและสถานะผู้สนับสนุน

• User guides
• Command reference
• Configuration reference
• ผู้สนับสนุนปัจจุบันคือ Supabase
• ผู้สนับสนุนในอดีตได้แก่ Crunchy Data, Resonate

[xguru]

มีการอัปเดตเกี่ยวกับเรื่องนี้แล้ว

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

[GN⁺]

ความคิดเห็นจาก Hacker News

• จากโพสต์ที่ผู้เขียนลงใน LinkedIn จะเห็นได้ชัดว่าเขาทุ่มทั้งเวลาและความรักให้กับ pgBackRest มานาน 13 ปี และตอนนี้ก็ตัดสินใจ ยุติการดูแลรักษา แล้ว
  แม้จะเคยมีการสนับสนุนจากบริษัท แต่ก็ยังต้องทุ่มเวลาช่วงกลางคืนและวันหยุดสุดสัปดาห์ลงไปด้วย และหลังจาก Crunchy Data ถูกขายไป เขาก็ยังคงดูแลต่อพร้อมกับพยายามหาตำแหน่งงานที่จะทำสิ่งนี้ต่อได้ แต่ก็ไม่สำเร็จ
  เพื่อเลี้ยงชีพ เขาจำเป็นต้องมองหาโอกาสที่กว้างขึ้น ซึ่งนั่นหมายความว่าเขาไม่สามารถสละเวลาที่จำเป็นสำหรับการบำรุงรักษา แก้บั๊ก รีวิว PR และตอบสนอง issue ได้อีกต่อไป จึงตั้งใจจะ archive repository
• ฉันเคยใช้ pgBackRest ในโปรเจกต์ส่วนตัวได้ดีมาก ถึงขั้นทำคู่มือสำรองและกู้คืน PostgreSQL สำหรับทั้ง local volume และ cloud storage เลย จึงรู้สึกเสียดายที่มันต้องจบลงแบบนี้
  คู่มืออยู่ที่ https://github.com/freakynit/postgre-backup-and-restore-guide และขอขอบคุณมากจริงๆ สำหรับเวลาและความพยายามทั้งหมดที่ทุ่มเทมา
  • ทุกวันนี้ดูเหมือนว่าความคาดหวังเรื่อง AI ก็เป็นอีกปัจจัยที่ทำให้นักพัฒนาต้องรับมือกับ deadline ที่ตึงขึ้นและมีเวลาน้อยลง
    แถมยังมีหลายคนที่เผาเงินไปกับโทเค็น ทำให้ทั้งเงินสำรองและเวลาก็ลดลงไปพร้อมกัน
  • อยากให้โปรเจกต์แบบนี้ไม่หายไปเพียงเพราะขาด การสนับสนุนด้านเงินทุน และรู้สึกว่าความยากลำบากของ OSS ในโลกความเป็นจริงนั้นหนักมาก
• ในที่นี้ไม่ใช่ว่า โมเดลโอเพนซอร์ส ล้มเหลว แต่เป็นเพียงการที่ผู้เขียนหาแรงสนับสนุนทางการเงินต่อไปไม่ได้แล้วจึงต้องเปลี่ยนทิศทาง ซึ่งก็ดูสมเหตุสมผลดี
  ถ้านี่เป็นเครื่องมือระดับโปรดักชันที่มอบคุณค่าจริงในสภาพแวดล้อมเชิงพาณิชย์ ไม่ใช่แค่โปรเจกต์งานอดิเรก ก็ย่อมมีโอกาสที่บริษัทแสวงหากำไรจะเข้ามาเติมช่องว่างนี้
  แต่ผู้ใช้งานก็ต้องกลายเป็นลูกค้าและจ่ายเงินจริง การส่ง bug report กับคำบ่นไปให้ผู้ดูแลที่ทำงานฟรีอยู่เรื่อยๆ นั้นไม่ยั่งยืน
  เราต้องการแนวทางใหม่สำหรับ ความยั่งยืนทางการเงินของ FOSS และดูเหมือนว่าการบริจาคอย่างเดียวคงไม่พอ
  • ไม่ว่าระบบนิเวศแบบไหน ถ้าเราอยากให้มันอยู่รอด เราก็ควร สนับสนุนโดยตรง เอง
    ไม่ว่าจะเป็นร้านในชุมชนหรือโปรเจกต์โอเพนซอร์สก็เหมือนกัน
  • สงสัยว่าผู้เขียนเคยพิจารณาทำสิ่งนี้ให้เป็น ผลิตภัณฑ์แบบเสียเงิน หรือไม่
    แต่สิทธิ์ลิขสิทธิ์อาจกระจายอยู่ในหมู่ผู้มีส่วนร่วมหลายคน จึงอาจต้องจัดการเรื่องสิทธิ์ตามว่ามี ACL หรือไม่และอยู่ภายใต้เขตอำนาจใด รวมถึงอาจต้องมีข้อตกลงเรื่องการแบ่งรายได้ด้วย
• สิ่งที่ผู้คนควรจับตามากกว่าคือฝั่ง การเข้าซื้อกิจการของ Crunchy Data
  ตอนมีการสนับสนุนจากบริษัททุกอย่างยังเดินต่อได้ แต่พอบริษัทถูกขายและเจ้าของใหม่เปลี่ยนลำดับความสำคัญ เครื่องมือโครงสร้างพื้นฐานที่มี 3.8k ดาว ตัวนี้ก็เริ่มสั่นคลอนทันที ผู้ใช้หลายคนอาจไม่เคยรู้เลยว่าแหล่งทุนของเครื่องมือสำรองข้อมูลที่ตัวเองใช้ขึ้นอยู่กับกลยุทธ์ M&A ของคนอื่น
  เพราะแบบนั้นฉันเองก็เริ่มค่อยๆ ย้ายไปใช้ไฟล์ที่ติดตามด้วย SQLite และ git มากขึ้น
  เนื่องจากแม้แต่ managed Postgres stack ก็ยังวางอยู่บนเครื่องมือหลายตัวที่ดูแลโดยผู้คนซึ่งเราไม่รู้สถานะทางการเงินของพวกเขา
  • มันไม่ได้หายไปแบบสมบูรณ์ และอย่างน้อยตอนนี้ก็ยังไม่ใช่สถานการณ์ที่ การสำรองข้อมูลจะหยุดทำงานทันที
    แต่ภาพใหญ่เรื่องโครงสร้างเงินทุนที่เปราะบางนั้นก็ยังเป็นประเด็นจริง
  • แต่ SQLite เองก็ไม่ได้ปลอดภัยจากความเสี่ยงแบบเดียวกันโดยสมบูรณ์ แล้วทำไมถึงมองว่าปลอดภัยกว่าก็ยังน่าสงสัย
• ซอร์สก็ยังอยู่ ดังนั้นแทนที่จะบอกว่าเสียดายอย่างเดียว ก็ยังมีทางเลือกอย่าง fork เอง เพื่อดูแลต่อ หรือจ่ายเงินให้ใครสักคนมารับช่วงดูแล
  และในจังหวะเดียวกันก็ควรกลับไปดูโปรเจกต์ที่เราไม่อยากเสียไป แล้วตั้งค่าการสนับสนุนไว้ตั้งแต่ตอนนี้
  • คิดว่านี่เป็นท่าทีที่ถูกต้อง
    ทุกคนบอกว่าเสียใจ แต่ถ้าเสียใจจริง ก็ควรถามตัวเองก่อนว่า เสียใจถึงขั้นพร้อมบริจาคไหม
• เท่าที่ฉันเห็นระบบนิเวศนี้มา pgBackRest คือโซลูชันที่ดีที่สุดในสาย PostgreSQL backup
  โดยเฉพาะตรงที่มันไม่ได้จริงจังแค่เรื่อง backup แต่ยังรวมถึง การกู้คืนและการตรวจสอบความถูกต้อง ด้วย ซึ่งหาได้ยากมาก และฉันเองก็เคยเจอประสบการณ์แย่หนักในที่ทำงานเพราะละเลยเรื่องนี้
  รายละเอียดอยู่ที่ https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/
  เลยรู้สึกว่านี่เป็นความสูญเสียที่ค่อนข้างใหญ่
• ค่อนข้างน่าตกใจ และฉันเคยมองว่านี่แทบจะเป็น เครื่องมือ backup/recovery หลักของ PG อยู่แล้ว
  เลยสงสัยว่าเมื่อเทียบกับ WAL-G หรือ Barman แล้วเป็นอย่างไร
  https://github.com/wal-g/wal-g
  https://github.com/EnterpriseDB/barman
  • ฉันอาจเทียบแบบแม่นๆ ไม่ได้ แต่เราใช้ Barman มานานและพอใจมาก
    ทุกคืนเราจะสร้าง nightly DB ที่กู้คืนจาก Barman แล้วเอาไปใช้ทั้งสำหรับฝึกอบรมผู้ใช้และทดสอบด้วย เพื่อยืนยันอย่างต่อเนื่องว่า backup ไม่ได้เสียจริงๆ และหลายปีก็ยังไม่มีปัญหา
  • ฉันเป็นหนึ่งใน ผู้ดูแล wal-g และมองว่าในแง่ฟีเจอร์มันเทียบกันได้สบาย
    หลังจากเงียบไปหลายปี ตอนนี้ฉันกลับมาทำฝั่ง managed Postgres อีกครั้ง และหวังว่านอกจาก delta backup ที่ wal-g มีผ่านการเปรียบเทียบบล็อกของตัวเองแล้ว มันจะรองรับ pg17 incremental backup ด้วย
    แล้วก็ควรใช้ daemon mode จริงๆ
    น่าเสียดายที่เครื่องมือคู่แข่งหายไป แต่พื้นที่นี้ยังมีอะไรให้พัฒนาอีกมาก และเวลาที่ Postgres อยากรันบนระบบที่ไม่มี overcommit นั้น C มีข้อได้เปรียบเหนือ Golang อยู่เหมือนกัน
  • แต่ก่อนเราใช้ WAL-E และตอนนี้ก็ใช้ผู้สืบทอดของมันคือ WAL-G อย่างพอใจ
    ตอนประเมินเมื่อราว 9 ปีก่อน ฝั่งนี้ดึงดูดใจกว่า pgBackRest เพราะคุณสมบัติ streaming PITR
  • เข้าใจได้ที่มองว่านี่เป็นเครื่องมือหลัก แต่ก็ทำให้นึกถึงสถานการณ์แบบ https://xkcd.com/2347/
• ฉันใช้ pgBackRest กับ ฐานข้อมูล production ขนาด 2TB ได้อย่างน่าพอใจ และบังเอิญว่าสัปดาห์นี้กำลังจะเอาไปใช้กับ ฐานข้อมูล 8TB ด้วย
  งั้นตอนนี้ทางเลือกที่ใกล้ที่สุดคือ wal-g, barman หรือ databasus กันแน่
  ถึงจะพูดว่าตัวเองแค่เล่นบท DBA แต่จริงๆ แล้วการเลือกนี่สำคัญมาก
  • ฉันเคยใช้ Barman กับ ฐานข้อมูลระดับ 30TB+ และก็ไม่มีอะไรให้บ่นมากนัก
    เผื่อเป็นข้อมูล ฉันทำงานเป็น DBRE
  • ถ้าคุณกำลังสำรองข้อมูล Postgres production ระดับหลายเทราไบต์อยู่ นั่นไม่ใช่แค่ เล่นบท DBA แล้ว แต่ถือว่าคุณทำงานนี้จริงจังอยู่แล้ว
  • ถ้าคอนฟิกของคุณเก็บ backup ไว้บน cloud storage ทางเลือกที่ใกล้ที่สุดน่าจะเป็น Barman ที่เพิ่ม hook scripts เข้าไป
    เอกสารที่เกี่ยวข้องคือ https://docs.pgbarman.org/release/3.18.0/user_guide/hook_scripts.html#hook-scripts-using-barman-cloud-scripts-as-hooks-in-barman
    https://github.com/aiven-open/pghoard ก็ดูน่าสนใจ แต่ฉันยังไม่ได้ลองพิสูจน์ด้วยตัวเอง
  • สงสัยว่ามีใครเคยทำ backup โดยเอา standby ไว้บน ZFS หรือไฟล์ซิสเต็มอื่นที่ทำ snapshot ได้บ้างไหม
  • ฉันไม่เคยใช้ pgBackRest มาก่อนเลย แต่เพิ่งเริ่มเอามันไปใช้กับโปรเจกต์หนึ่งเมื่อ 2 ชั่วโมงก่อน พออ่าน README จบ ทุกอย่างก็อัปเดตไปแล้ว
• pgBackRest เป็นหนึ่งในเทคโนโลยีสำรองข้อมูล PostgreSQL ที่อเนกประสงค์ที่สุด และจากประสบการณ์ของฉัน ผลิตภัณฑ์อื่นยังตามความสามารถของมันไม่ทัน
  ยิ่งทำให้เรื่องนี้น่าเสียดายมากขึ้น และการหาทางเลือกที่ เทียบเท่าด้านฟังก์ชันการทำงาน กับเครื่องมือที่ยอดเยี่ยมนี้คงไม่ง่าย
  ถ้าเป็นไปได้ก็หวังว่านี่จะเป็นการตัดสินใจที่ย้อนกลับได้ ไม่เช่นนั้นก็น่าจะมีทางให้โปรเจกต์ PostgreSQL รับมันเข้าไปใน contrib
• ตอนนี้มันยัง ใช้งานต่อได้ ก็ใช้ต่อไปได้ตามปกติ
  ผู้เขียนเองก็คงอยากให้คนยังใช้มันต่อไป มากกว่าจะรีบทิ้งมันก่อนเวลาที่มันใช้งานไม่ได้จริงๆ
  • และเมื่อถึงตอนนั้นก็คงดีถ้ามีใครสักคนอาสาเป็น ผู้ดูแลคนใหม่
    ไม่แน่ใจว่าจะต้อง fork หรือว่ายังสามารถเข้าไปเป็น contributor ใน repository เดิมแล้วรับช่วงต่อได้