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

รายงานปัญหาopen_in_new ดูซอร์สโค้ดopen_in_new รุ่น Nightly · 8.0 7.4 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 รายการสําหรับการกำหนดเส้นทาง
5. สมาชิก DevEx จะกำหนดป้ายกำกับ type: เพียง 1 รายการ เช่น type: bug หรือ type: feature request ตามประเภทของปัญหา
6. สำหรับปัญหาเฉพาะแพลตฟอร์ม สมาชิก DevEx จะกำหนดป้ายกำกับ platform: รายการเดียว เช่น platform:apple สำหรับปัญหาเฉพาะ Mac ในขั้นตอนนี้ ปัญหาจะเข้าสู่กลุ่มปัญหาที่ยังไม่จัดการ

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

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

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

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

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

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

ปัญหา

1. กรองรายการปัญหาตามป้ายกำกับทีมและป้ายกำกับ untriaged
2. ตรวจสอบปัญหา
3. ระบุลําดับความสําคัญและมอบหมายป้ายกํากับ
   1. ทีมย่อย DevEx อาจจัดลําดับความสําคัญของปัญหาแล้วหากเป็น P0 จัดลําดับความสําคัญใหม่หากจําเป็น
   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 - ข้อบกพร่องหรือคำขอฟีเจอร์ที่มีลำดับความสำคัญต่ำซึ่งไม่มีแนวโน้มที่จะได้รับการแก้ไข นอกจากนี้ยังสามารถเปิดอยู่เพื่อจัดลําดับความสําคัญใหม่ได้หากมีผู้ใช้จำนวนมากขึ้นที่ได้รับผลกระทบ
• ice-box
  • ปัญหาที่เราไม่มีเวลาจัดการหรือรับผลงานในขณะนี้ เราจะปิดปัญหาเหล่านี้เพื่อระบุว่าไม่มีผู้ใดกำลังดำเนินการอยู่ แต่เราจะตรวจสอบความถูกต้องของปัญหาเหล่านี้ต่อไปและเปิดปัญหาขึ้นมาใหม่หากมีผู้ได้รับผลกระทบจำนวนมากพอและเรามีทรัพยากรในการดำเนินการ โปรดแสดงความคิดเห็นหรือรีแอ็กชันต่อปัญหาเหล่านี้ได้เสมอ แม้ว่าจะปิดไปแล้วก็ตาม

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

• 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
  • ติดต่อ: 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: * แล้วหันมาใช้ป้ายกํากับของทีมแทน

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