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

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

นี่คือคู่มือสำหรับผู้ดูแลโครงการโอเพนซอร์ส Bazel

หากคุณกำลังมองหาวิธีร่วมให้ข้อมูลกับ Bazel โปรดอ่านการมีส่วนร่วมใน Bazel แทน

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

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

กลุ่มผู้สนับสนุนหลักของ Bazel ได้ทุ่มเท เพื่อจัดการด้านต่างๆ ของโครงการโอเพนซอร์ส ได้แก่

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

การเปิดตัว

การรวมอย่างต่อเนื่อง

อ่านคู่มือของทีม 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
  • team-Bazel: ปัญหาทั่วไปเกี่ยวกับผลิตภัณฑ์/กลยุทธ์ของ Bazel
  • team-Build-Language: ปัญหาเกี่ยวกับ BUILD, .bzl API และ Stardoc
  • team-Configurability: ปัญหาสำหรับทีมกำหนดค่า
  • team-Core: ปัญหาสำหรับทีมหลัก
  • team-Documentation: ปัญหาสำหรับทีมเอกสารประกอบ
  • team-ExternalDeps: การจัดการทรัพยากร Dependency ภายนอก, Bzlmod, ที่เก็บระยะไกล, ไฟล์ WORKSPACE
  • team-Local-Exec: ปัญหาสำหรับทีมดำเนินการ (ในพื้นที่)
  • team-OSS: ปัญหาสำหรับทีม Bazel OSS: การติดตั้ง กระบวนการเผยแพร่ บรรจุภัณฑ์ Bazel เว็บไซต์ โครงสร้างพื้นฐานของเอกสาร
  • team-Performance: ปัญหาสำหรับทีม Bazel Performance
  • team-Remote-Exec: ปัญหาสำหรับทีมดำเนินการ (ระยะไกล)
  • team-Rules-CPP: ปัญหาเกี่ยวกับกฎ C++ รวมถึงตรรกะกฎของ Apple เอง
  • team-Rules-Java: ปัญหาของกฎ Java
  • team-Rules-Python: ปัญหาเกี่ยวกับกฎ Python แบบเนทีฟ
  • team-Rules-Server: ปัญหาของกฎฝั่งเซิร์ฟเวอร์ที่รวมอยู่ใน Bazel
  • team-Starlark-integration: การผสานรวม Bazel + Starlark ที่ไม่ใช่ API รวมถึงวิธีที่ Bazel ทริกเกอร์ล่าม Starlark, Stardoc, การแทรกในตัว การเข้ารหัสอักขระ ไม่รวมถึงปัญหาเกี่ยวกับภาษา BUILD หรือ .bzl
  • team-Starlark-interpreter: ปัญหาสำหรับอินเทอร์พรีเตอร์ของ Starlark (ทุกอย่างใน java.net.starlark) ปัญหาเกี่ยวกับ API ของ BUILD และ .bzl (ซึ่งแสดงถึงการผสานรวมของ Bazel กับ Starlark) เกิดขึ้นใน team-Build-Language

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

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