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

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

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

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

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

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

• กระบวนการเผยแพร่: จัดการกระบวนการเผยแพร่ของ Bazel
• Green Team: สร้างระบบนิเวศที่สมบูรณ์ของกฎและเครื่องมือ
• 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 จะกำหนดปัญหาให้กับผู้ใช้เพื่อขอข้อมูลเพิ่มเติมก่อนดำเนินการต่อ ซึ่งมักจะเกิดขึ้นเมื่อผู้ใช้ไม่ได้ทำตาม เทมเพลต ปัญหา
3. หลังจากตรวจสอบปัญหาแล้ว สมาชิก DevEx จะตัดสินใจว่าปัญหาต้องได้รับการแก้ไขทันทีหรือไม่ หากต้องได้รับการแก้ไขทันที สมาชิกจะกำหนดป้ายกำกับลำดับความสำคัญ P0 priority และเจ้าของจากรายชื่อหัวหน้าทีม
4. สมาชิก DevEx กำหนดป้ายกำกับ untriaged และป้ายกำกับทีม 1 ป้ายกำกับสำหรับการกำหนดเส้นทาง
5. สมาชิก DevEx ยังกำหนดป้ายกำกับ type: 1 ป้ายกำกับ เช่น type: bug หรือ type: feature request ตามประเภทของปัญหา
6. สำหรับปัญหาที่เฉพาะเจาะจงกับแพลตฟอร์ม สมาชิก DevEx จะกำหนดป้ายกำกับ platform: 1 ป้ายกำกับ เช่น platform:apple สำหรับปัญหาที่เฉพาะเจาะจงกับ Mac ในขั้นตอนนี้ ปัญหาจะเข้าสู่พูลของ ปัญหาที่เปิดอยู่ซึ่งยังไม่ได้รับการจัดลำดับความสำคัญ

ทีมย่อยแต่ละทีมของ 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

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

ลำดับความสำคัญ

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

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

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

• team-Android: ปัญหาสำหรับทีม Android
  • ผู้ติดต่อ: ahumesky
• team-Bazel: ปัญหาทั่วไปเกี่ยวกับผลิตภัณฑ์/กลยุทธ์ของ Bazel
  • ผู้ติดต่อ: sventiffe
• team-Build-Language: ปัญหาสำหรับ BUILD, .bzl API และ Stardoc
  • ผู้ติดต่อ: brandjon
• team-Configurability: ปัญหาสำหรับทีม Configurability
  • ผู้ติดต่อ: gregestren
• team-Core: ปัญหาสำหรับทีม Core
  • ผู้ติดต่อ: haxorz
• team-Documentation: ปัญหาสำหรับทีมเอกสารประกอบ
  • ผู้ติดต่อ: communikit
• team-ExternalDeps: การจัดการการขึ้นต่อกันภายนอก, Bzlmod, ที่เก็บข้อมูลระยะไกล, ไฟล์ WORKSPACE
  • ผู้ติดต่อ: meteorcloudy
• 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-CPP: ปัญหาสำหรับกฎ C++ รวมถึงตรรกะกฎ Apple แบบเนทีฟ
  • ผู้ติดต่อ: oquenchil
• team-Rules-Java: ปัญหาสำหรับกฎ Java
  • ผู้ติดต่อ: comius
• team-Rules-Python: ปัญหาสำหรับกฎ Python แบบเนทีฟ
  • ผู้ติดต่อ: comius
• team-Rules-Server: ปัญหาสำหรับกฎฝั่งเซิร์ฟเวอร์ที่รวมอยู่ใน Bazel
  • ผู้ติดต่อ: comius
• 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: * และใช้ป้ายกำกับทีมแทน

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