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

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

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

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

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

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

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

การเปิดตัว

• 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: หนึ่งป้าย เช่น platform:apple สำหรับปัญหาที่เฉพาะเจาะจงกับ Mac ในขั้นตอนนี้ ปัญหาจะเข้าสู่กลุ่มปัญหาที่เปิดอยู่ซึ่งยังไม่ได้จัดประเภท

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

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

วงจรของคำขอ Pull

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

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

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

ปัญหา

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

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

Pull Request

1. กรองรายการคำขอผสานรวมตามป้ายกำกับของทีม
2. ตรวจสอบคำขอพุลที่เปิดอยู่
   1. ไม่บังคับ: หากคุณได้รับมอบหมายให้ตรวจสอบแต่ไม่เหมาะสม ให้มอบหมายผู้ตรวจสอบที่เหมาะสมเพื่อทำการตรวจสอบโค้ด
3. ทำงานร่วมกับผู้สร้าง Pull Request เพื่อทำการตรวจสอบโค้ดให้เสร็จสมบูรณ์
4. อนุมัติคำขอส่งโค้ด
5. ตรวจสอบว่าการทดสอบทั้งหมดผ่าน
6. นำเข้าแพตช์ไปยังระบบควบคุมเวอร์ชันภายในและเรียกใช้ presubmit ภายใน
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: ปัญหาเกี่ยวกับ API ของ BUILD, .bzl และ Stardoc
  • ติดต่อ: brandjon
• team-Configurability: ปัญหาสำหรับทีมที่ดูแลการกำหนดค่า
  • ติดต่อ: gregestren
• team-Core: ปัญหาสำหรับทีมหลัก
  • ติดต่อ: haxorz
• team-Documentation: ปัญหาสำหรับทีมเอกสารประกอบ
  • ติดต่อ: communikit
• team-ExternalDeps: การจัดการการขึ้นต่อกันภายนอก, 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) ปัญหาเกี่ยวกับ BUILD และ .bzl API (ซึ่งแสดงถึงการผสานรวมของ Bazel กับ Starlark) จะอยู่ใน team-Build-Language
  • ติดต่อ: brandjon

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

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