คู่มือสำหรับผู้บำรุงรักษา Bazel

นี่คือคู่มือสำหรับผู้ดูแลโปรเจ็กต์โอเพนซอร์ส Bazel

หากต้องการมีส่วนร่วมใน Bazel ให้อ่านหัวข้อ การมีส่วนร่วมใน Bazel แทน

วัตถุประสงค์ของหน้านี้มีดังนี้

1. เป็นแหล่งข้อมูลที่เชื่อถือได้สำหรับผู้ดูแลเกี่ยวกับกระบวนการมีส่วนร่วมในโปรเจ็กต์
2. กำหนดสิ่งที่ผู้มีส่วนร่วมในชุมชนและผู้ดูแลโปรเจ็กต์จะได้รับ

กลุ่มผู้มีส่วนร่วมหลักของ Bazel มีทีมย่อยที่ทำหน้าที่จัดการส่วนต่างๆ ของโปรเจ็กต์โอเพนซอร์ส ซึ่งได้แก่

• กระบวนการเผยแพร่: จัดการกระบวนการเผยแพร่ของ Bazel
• Green Team: ตรวจสอบสถานะ CI ของ Bazel และรายงานการหยุดทำงาน
• Developer Experience Gardeners: สนับสนุนการมีส่วนร่วมจากภายนอก ตรวจสอบ ปัญหาและ Pull Request รวมถึงทำให้เวิร์กโฟลว์การพัฒนาของเราเปิดกว้างมากขึ้น

การเผยแพร่

• Playbook การเผยแพร่
• การทดสอบการเปลี่ยนแปลงในเครื่องด้วยโปรเจ็กต์ดาวน์สตรีม

การรวมอย่างต่อเนื่อง

อ่านคู่มือของ Green Team เกี่ยวกับโครงสร้างพื้นฐาน CI ของ Bazel ในที่เก็บ bazelbuild/continuous-integration

วงจรของปัญหา

1. ผู้ใช้สร้างปัญหาโดยเลือกเทมเพลตปัญหาอย่างใดอย่างหนึ่ง แล้วระบบจะนำปัญหาดังกล่าวไปรวมไว้ในกลุ่มปัญหาที่เปิดอยู่ซึ่งยังไม่ได้รับการตรวจสอบ
2. สมาชิกในทีมย่อย Developer Experience (DevEx) ที่หมุนเวียนกันจะตรวจสอบปัญหา
   1. หากปัญหาไม่ใช่ข้อบกพร่อง หรือคำขอฟีเจอร์ สมาชิก DevEx มักจะปิดปัญหาและเปลี่ยนเส้นทางผู้ใช้ไปยัง StackOverflow และ bazel-discuss เพื่อให้ คำถามได้รับการมองเห็นมากขึ้น
   2. หากปัญหาอยู่ในที่เก็บกฎที่ชุมชนเป็นเจ้าของ เช่น rules_apple สมาชิก DevEx จะ โอนปัญหานี้ ไปยังที่เก็บที่ถูกต้อง
   3. หากปัญหาไม่ชัดเจนหรือมีข้อมูลไม่ครบถ้วน สมาชิก DevEx จะกำหนดปัญหาให้กับผู้ใช้เพื่อขอข้อมูลเพิ่มเติมก่อนดำเนินการต่อ ซึ่งมักเกิดขึ้นเมื่อผู้ใช้ไม่ได้เลือก เทมเพลตปัญหา ที่ถูกต้อง {: .external} หรือให้ข้อมูลไม่ครบถ้วน
3. หลังจากตรวจสอบปัญหาแล้ว สมาชิก DevEx จะตัดสินว่าปัญหาดังกล่าวต้องได้รับการดำเนินการในทันทีหรือไม่ หากต้องดำเนินการ สมาชิกจะกำหนดป้ายกำกับลำดับความสำคัญ P0 priority และเจ้าของจากรายชื่อหัวหน้าทีม
4. สมาชิก DevEx จะกำหนดป้ายกำกับ untriaged และป้ายกำกับทีม 1 รายการสำหรับการกำหนดเส้นทาง
5. นอกจากนี้ สมาชิก DevEx ยังกำหนดป้ายกำกับ type: 1 รายการ เช่น type: bug หรือ type: feature request ตามประเภทของปัญหา
6. สำหรับปัญหาที่เฉพาะเจาะจงกับแพลตฟอร์ม สมาชิก DevEx จะกำหนดป้ายกำกับ platform: 1 รายการ เช่น platform:apple สำหรับปัญหาที่เฉพาะเจาะจงกับ Mac
7. หากปัญหามีความสำคัญต่ำและผู้มีส่วนร่วมในชุมชนรายใหม่สามารถดำเนินการได้ สมาชิก DevEx จะกำหนดป้ายกำกับ good first issue ในขั้นตอนนี้ ปัญหาจะถูกนำไปรวมไว้ในกลุ่มปัญหาที่เปิดอยู่ซึ่งยังไม่ได้รับการตรวจสอบ

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

เมื่อปัญหาได้รับการแก้ไขแล้ว คุณจะปิดปัญหาได้

วงจรของ Pull Request

1. ผู้ใช้สร้าง Pull Request
2. หากคุณเป็นสมาชิกของทีม Bazel และส่ง PR ไปยังพื้นที่ของคุณเอง คุณมีหน้าที่รับผิดชอบในการกำหนดป้ายกำกับทีมและค้นหาผู้ตรวจสอบที่ดีที่สุด
3. ไม่เช่นนั้น สมาชิก DevEx จะกำหนดป้ายกำกับทีม 1 รายการ และหัวหน้าฝ่ายเทคนิค (TL) ของทีมสำหรับการกำหนดเส้นทางในระหว่างการตรวจสอบประจำวัน
   1. TL อาจกำหนดให้ผู้อื่นตรวจสอบ PR ก็ได้
4. ผู้ตรวจสอบที่ได้รับมอบหมายจะตรวจสอบ PR และทำงานร่วมกับผู้เขียนจนกว่าจะได้รับอนุมัติหรือยกเลิก
5. หากได้รับอนุมัติ ผู้ตรวจสอบจะนำเข้า คอมมิตของ PR ไปยังระบบควบคุมเวอร์ชันภายในของ Google เพื่อทำการทดสอบเพิ่มเติม เนื่องจาก Bazel เป็นระบบบิลด์เดียวกันกับที่ใช้ภายใน Google เราจึงต้องทดสอบคอมมิต PR ทั้งหมดกับการทดสอบภายใน นี่คือเหตุผลที่เราไม่ผสาน PR โดยตรง
6. หากคอมมิตที่นำเข้าผ่านการทดสอบภายในทั้งหมด ระบบจะบีบอัดคอมมิตและส่งออกกลับไปยัง GitHub
7. เมื่อคอมมิตผสานเข้ากับมาสเตอร์ GitHub จะปิด PR โดยอัตโนมัติ

ทีมของฉันเป็นเจ้าของป้ายกำกับ ฉันควรทำอย่างไร

ทีมย่อยต้องตรวจสอบปัญหาทั้งหมดในป้ายกำกับที่ทีมเป็นเจ้าของ โดยควรทำทุกสัปดาห์

ปัญหา

1. กรองรายการปัญหาตามป้ายกำกับทีมและ ป้ายกำกับ untriaged
2. ตรวจสอบปัญหา
3. ระบุระดับความสำคัญและกำหนดป้ายกำกับ
   1. ทีมย่อย DevEx อาจกำหนดลำดับความสำคัญของปัญหาไว้แล้วหากเป็น P0 กำหนดลำดับความสำคัญใหม่หากจำเป็น
   2. ปัญหาแต่ละรายการต้องมีป้ายกำกับลำดับความสำคัญ 1 รายการ หากปัญหาเป็น P0 หรือ P1 เราจะถือว่ามีการดำเนินการกับปัญหาดังกล่าวอยู่
4. นำป้ายกำกับ untriaged ออก

โปรดทราบว่าคุณต้องอยู่ในองค์กร bazelbuild organization จึงจะเพิ่มหรือนำป้ายกำกับออกได้

Pull Request

Pull Request (PR) เป็นวิธีหลักที่ผู้มีส่วนร่วมภายนอกเพิ่มคุณค่าให้กับ Bazel ในฐานะโปรเจ็กต์โอเพนซอร์ส เราจึงต้องตรวจสอบและจัดการ PR อย่างทันท่วงทีและมีประสิทธิภาพ

• การตรวจสอบ

  ตรวจสอบ PR ที่เข้ามาเป็นประจำด้วยป้ายกำกับ awaiting-review และป้ายกำกับทีม คุณสามารถทำได้โดยการหมุนเวียนกันหรือจัดการประชุมตรวจสอบเป็นประจำ เราคาดหวังว่า PR แต่ละรายการจะได้รับการตอบกลับเบื้องต้นภายใน 7 วันทำการ

• การตอบกลับ

  • หาก PR ดูดี ให้อนุมัติและกำหนดป้ายกำกับ awaiting-PR-merge ทีม gTech จะนำเข้า PR เป็น CL
  • ไม่เช่นนั้น ให้แสดงความคิดเห็นและแทนที่ป้ายกำกับ awaiting-review ด้วยป้ายกำกับ awaiting-user-response ทีมย่อย DevEx จะอัปเดตป้ายกำกับเป็นประจำหากผู้เขียน PR ตอบกลับ
  • สำหรับ PR ที่มีการเปลี่ยนแปลงที่สำคัญ ให้พิจารณาขอเอกสารการออกแบบหรือการสนทนาก่อนหน้านี้ในปัญหา

• การปิด

  เนื่องจากมีทรัพยากรจำกัด เราจึงต้องปิด PR ที่ไม่เป็นไปตามมาตรฐานของ Bazel หรือเราไม่มีความสามารถในการตรวจสอบหรือดูแลรักษา

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

  เมื่อปิด PR โปรดใช้คำพูดที่สุภาพและอธิบายเหตุผลในการปิด

รายการสำคัญ

ผู้ดูแลจะใช้คำจำกัดความต่อไปนี้สำหรับลำดับความสำคัญในการตรวจสอบปัญหา

• P0 - ฟังก์ชันการทำงานหลักหยุดทำงานซึ่งทำให้การเผยแพร่ Bazel (ไม่รวมเวอร์ชันทดสอบ) ใช้งานไม่ได้ หรือบริการหยุดทำงานซึ่งส่งผลกระทบอย่างรุนแรงต่อการพัฒนาโปรเจ็กต์ Bazel ซึ่งรวมถึงการเกิดปัญหาซ้ำที่เกิดขึ้นในมาใหม่ซึ่งบล็อกผู้ใช้จำนวนมาก หรือการเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบซึ่งไม่เป็นไปตาม นโยบาย การเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบ ไม่มีวิธีแก้ปัญหาเฉพาะหน้าที่ใช้ได้จริง
• P1 - ข้อบกพร่องที่สำคัญหรือ ฟีเจอร์ที่ควรได้รับการแก้ไขในการเผยแพร่เวอร์ชันถัดไป หรือปัญหาที่ร้ายแรงซึ่ง ส่งผลกระทบต่อผู้ใช้จำนวนมาก (รวมถึงการพัฒนาโปรเจ็กต์ Bazel) แต่มี วิธีแก้ปัญหาเฉพาะหน้าที่ใช้ได้จริง โดยปกติแล้วไม่จำเป็นต้องดำเนินการในทันที เป็นที่ต้องการอย่างมากและวางแผนไว้ในแผนงานของไตรมาสปัจจุบัน
• P2 - ข้อบกพร่องหรือฟีเจอร์ ที่ควรได้รับการแก้ไข แต่เรายังไม่ได้ดำเนินการในขณะนี้ ปัญหาที่เกิดขึ้นจริงระดับปานกลางใน Bazel เวอร์ชันที่เผยแพร่แล้วซึ่งทำให้ผู้ใช้ไม่สะดวกและต้องได้รับการแก้ไขในการเผยแพร่เวอร์ชันในอนาคตและ/หรือมีวิธีแก้ปัญหาเฉพาะหน้าที่ง่าย
• P3 - การแก้ไขข้อบกพร่องเล็กน้อยที่พึงประสงค์ หรือการปรับปรุงซึ่งมีผลกระทบเล็กน้อย ไม่ได้กำหนดลำดับความสำคัญไว้ในแผนงานของ Bazel หรือการเผยแพร่เวอร์ชันที่กำลังจะมาถึง แต่เราสนับสนุนการมีส่วนร่วมจากชุมชน
• P4 - ข้อบกพร่องที่มีลำดับความสำคัญต่ำ หรือคำขอฟีเจอร์ซึ่งไม่น่าจะได้รับการแก้ไข นอกจากนี้ คุณยังสามารถเก็บปัญหาไว้เพื่อกำหนดลำดับความสำคัญใหม่ได้หากมีผู้ใช้ได้รับผลกระทบมากขึ้น

ป้ายกำกับทีม

• team-Android: ปัญหาสำหรับทีม Android
  • ติดต่อ: ahumesky
• team-Bazel: ปัญหาทั่วไปเกี่ยวกับผลิตภัณฑ์/กลยุทธ์ของ Bazel
  • ติดต่อ: meisterT
• team-CLI: UI ของคอนโซล
  • ติดต่อ: meisterT
• team-Configurability: ปัญหาสำหรับทีม Configurability รวมถึง: การกำหนดค่าบิลด์หลักและระบบการเปลี่ยนผ่าน ไม่ รวมถึง: การเปลี่ยนแปลงแฟล็กใหม่หรือที่มีอยู่
  • ติดต่อ: gregestren
• team-Core: Skyframe, การค้นหา bazel, BEP, การแยกวิเคราะห์ตัวเลือก, bazelrc
  • ติดต่อ: haxorz
• team-Documentation: ปัญหาสำหรับทีมเอกสาร
• team-ExternalDeps: การจัดการการขึ้นต่อกันภายนอก, Bzlmod, ที่เก็บระยะไกล, ไฟล์ WORKSPACE
  • ติดต่อ: meteorcloudy
• team-Loading-API: ไฟล์ BUILD และการประมวลผลมาโคร: ป้ายกำกับ, package(), การมองเห็น, glob
  • ติดต่อ: brandjon
• team-Local-Exec: ปัญหาสำหรับทีม Execution (Local)
  • ติดต่อ: meisterT
• team-OSS: ปัญหาสำหรับทีม Bazel OSS: การติดตั้ง, กระบวนการเผยแพร่, การแพ็กเกจ Bazel, เว็บไซต์, โครงสร้างพื้นฐานของเอกสาร
  • ติดต่อ: meteorcloudy
• team-Performance: ปัญหาสำหรับทีม Bazel Performance
  • ติดต่อ: meisterT
• team-Remote-Exec: ปัญหาสำหรับทีม Execution (Remote)
  • ติดต่อ: coeuvre
• team-Rules-API: API สำหรับการเขียนกฎ/แง่มุมต่างๆ: ผู้ให้บริการ, runfiles, การดำเนินการ, อาร์ติแฟกต์
  • ติดต่อ: pzembrod
• team-Rules-CPP / team-Rules-ObjC: ปัญหาสำหรับกฎ C++/Objective-C รวมถึงตรรกะกฎ Apple ดั้งเดิม
  • ติดต่อ: pzembrod
• team-Rules-Java: ปัญหาสำหรับกฎ Java
  • ติดต่อ: hvadehra
• team-Rules-Python: ปัญหาสำหรับกฎ Python ดั้งเดิม
  • ติดต่อ: rickeylev
• team-Rules-Server: ปัญหาสำหรับกฎฝั่งเซิร์ฟเวอร์ที่รวมอยู่ใน Bazel
  • ติดต่อ: pzembrod
• team-Starlark-Integration: การผสานรวม Bazel + Starlark ที่ไม่ใช่ API รวมถึง: วิธีที่ Bazel ทริกเกอร์อินเทอร์พรีเตอร์ Starlark, Stardoc, การแทรกบิลต์อิน, การเข้ารหัสอักขระ ไม่ รวมถึง: ปัญหาเกี่ยวกับภาษา BUILD หรือ .bzl
  • ติดต่อ: brandjon
• team-Starlark-Interpreter: ปัญหาสำหรับอินเทอร์พรีเตอร์ Starlark (ทุกอย่างใน java.net.starlark) ปัญหาเกี่ยวกับ BUILD และ .bzl API (ซึ่งแสดงถึง การผสานรวม ของ Bazel กับ Starlark) จะอยู่ใน team-Build-Language
  • ติดต่อ: brandjon

สำหรับปัญหาใหม่ เราได้เลิกใช้ป้ายกำกับ category: * และใช้ป้ายกำกับทีมแทน

ดูรายการป้ายกำกับทั้งหมดได้ที่นี่ ที่นี่