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

รายงานปัญหาopen_in_new ดูแหล่งที่มาopen_in_new Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

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

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

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

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

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

ปัญหา

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

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

คำขอพุล

1. กรองรายการคำขอพุลตามป้ายกำกับของทีม
2. ตรวจสอบคำขอพุลที่เปิดอยู่
   1. ไม่บังคับ: หากคุณได้รับมอบหมายให้ตรวจสอบแต่ไม่เหมาะสม ให้มอบหมายผู้ตรวจสอบที่เหมาะสมเพื่อทำการตรวจสอบโค้ด
3. ทำงานร่วมกับผู้สร้างคำขอ Pull เพื่อทำการตรวจสอบโค้ดให้เสร็จสมบูรณ์
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: * เพื่อให้ทีมใช้ป้ายกำกับ แทน

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