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

รายงานปัญหาopen_in_new ดูแหล่งที่มาopen_in_new ตอนกลางคืน · 7.4 ที่ใช้เวลาเพียง 2 นาที 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: รายการเดียว เช่น platform:apple สำหรับปัญหาเฉพาะ Mac ในขั้นนี้ ปัญหาจะอยู่ในกลุ่มเปิดที่ยังไม่ได้นำเข้า ปัญหา

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

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

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

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

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

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

ปัญหา

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

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

คำขอพุล

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

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

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

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

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

• team-Android: ปัญหาสำหรับทีม Android
  • ติดต่อ: ahumesky
• team-Bazel: ปัญหาทั่วไปเกี่ยวกับผลิตภัณฑ์/กลยุทธ์ของ Bazel
  • ติดต่อ: sventiffe
• team-Build-Language: ปัญหาเกี่ยวกับ BUILD, .bzl API และ 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 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) ปัญหาเกี่ยวกับ BUILD และ .bzl API (ซึ่งแสดงถึงการผสานรวมของ Bazel กับ Starlark) ให้ส่งใน team-Build-Language
  • ติดต่อ: brandjon

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

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