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

วันที่ รายงานปัญหา ดูแหล่งที่มา ตอนกลางคืน · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

นี่คือคู่มือสำหรับผู้ดูแลโครงการโอเพนซอร์ส 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 ทีมเท่านั้น ป้ายกำกับ [label] สำหรับการกำหนดเส้นทาง
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. หากได้รับอนุมัติ ผู้ตรวจสอบจะนำเข้าสัญญาผูกมัดของการประชาสัมพันธ์ไปยัง ระบบควบคุมเวอร์ชันภายในสำหรับการทดสอบเพิ่มเติม เนื่องจาก Bazel เป็นบิลด์เดียวกัน ที่ใช้เป็นการภายในที่ Google เราต้องทดสอบการดำเนินการ PR ทั้งหมดกับ ชุดทดสอบภายใน นี่คือเหตุผลที่เราไม่ผสาน PR โดยตรง
6. หากคอมมิตที่นำเข้าผ่านการทดสอบภายในทั้งหมด คอมมิตจะถูกบีบ และส่งออกกลับไปยัง GitHub
7. เมื่อคอมมิตดังกล่าวรวมอยู่ในรายการหลัก GitHub จะปิด PR โดยอัตโนมัติ

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

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

ปัญหา

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

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

ดึงคำขอ

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

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

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

• 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 Performance
  • ติดต่อ: 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: * เพื่อให้ทีมช่วยเหลือ ป้ายกำกับ

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