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

รายงานปัญหา ดูแหล่งที่มา

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

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

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

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

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

• กระบวนการเผยแพร่: จัดการกระบวนการเผยแพร่ของ Bazel
• ทีมสีเขียว: พัฒนาระบบนิเวศของกฎและเครื่องมือที่มีประสิทธิภาพ
• นักจัดสวนที่มีประสบการณ์นักพัฒนาซอฟต์แวร์: สนับสนุนให้มีการร่วมให้ข้อมูลจากภายนอก ตรวจสอบปัญหา และดึงคำขอ รวมถึงทำให้เวิร์กโฟลว์การพัฒนาเปิดกว้างมากขึ้น

ผลงาน

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

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

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

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

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

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

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

วงจรของคำขอพุล

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

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

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

ปัญหา

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

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

ดึงคำขอ

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

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

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

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

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

• team-Android: ปัญหาสำหรับทีม Android
  • ติดต่อ: ahimesky
• team-Bazel: ปัญหาทั่วไปเกี่ยวกับผลิตภัณฑ์/กลยุทธ์ของ Bazel
  • ติดต่อ: sventiffe
• team-Build-Language: ปัญหาเกี่ยวกับ BUILD, .bzl API และ Stardoc
  • ติดต่อ: brandjon
• team-Configurability: ปัญหาสำหรับทีมกำหนดค่า
  • ติดต่อ: gregestren
• team-Core: ปัญหาสำหรับทีมหลัก
  • ติดต่อ: haxorz
• team-Documentation: ปัญหาสำหรับทีมจัดทำเอกสาร
  • ติดต่อ: communikit
• team-ExternalDeps: การจัดการทรัพยากร Dependency ภายนอก, Bzlmod, ที่เก็บระยะไกล, ไฟล์ WORKSPACE
  • ติดต่อ: meteorcloudy
• team-Local-Exec: ปัญหาสำหรับทีมดำเนินการ (ในพื้นที่)
  • ติดต่อ: meisterT
• team-OSS: ปัญหาสำหรับทีม Bazel OSS: การติดตั้ง กระบวนการเผยแพร่ บรรจุภัณฑ์ Bazel เว็บไซต์ โครงสร้างพื้นฐานของเอกสาร
  • ติดต่อ: meteorcloudy
• team-Performance: ปัญหาสำหรับทีมประสิทธิภาพ Bazel
  • ติดต่อ: meisterT
• team-Remote-Exec: ปัญหาสำหรับทีมดำเนินการ (ระยะไกล)
  • ติดต่อ: 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) ปัญหาเกี่ยวกับ API ของ BUILD และ .bzl (ซึ่งแสดงถึงการผสานรวมของ Bazel กับ Starlark) เกิดขึ้นใน team-Build-Language
  • ติดต่อ: brandjon

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

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