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

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

หากคุณต้องการสนับสนุน Bazel โปรดอ่านการมีส่วนร่วมใน Bazel แทน

หน้านี้มีวัตถุประสงค์เพื่อ

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

กลุ่มผู้มีส่วนร่วมหลักของ Bazel มีทีมย่อยที่ใช้จัดการด้านต่างๆ ของโปรเจ็กต์โอเพนซอร์สโดยเฉพาะ ได้แก่

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

การเปิดตัว

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

อ่านคำแนะนำของทีม Green เกี่ยวกับโครงสร้างพื้นฐาน CI ของ Bazel ในที่เก็บการสร้างแบบเบเซล/การผสานรวมอย่างต่อเนื่อง

วงจรของปัญหา

  1. ผู้ใช้สร้างปัญหาโดยใช้เทมเพลตปัญหาและส่งกลุ่มของปัญหาที่ยังไม่ได้ตรวจสอบเข้ามา
  2. สมาชิกในการหมุนเวียนทีมย่อยประสบการณ์นักพัฒนาซอฟต์แวร์ (DevEx) จะตรวจสอบปัญหา
    1. หากปัญหานั้นไม่ใช่ข้อบกพร่องหรือคำขอฟีเจอร์ สมาชิก DevEx มักจะปิดปัญหาดังกล่าวและเปลี่ยนเส้นทางผู้ใช้ไปยัง StackOverflow และ Bazel-discuss เพื่อให้มองเห็นคำถามได้ชัดเจนขึ้น
    2. หากปัญหาอยู่ในที่เก็บกฎแห่งใดแห่งหนึ่งที่ชุมชนเป็นเจ้าของ เช่น rules_apple สมาชิก DevEx จะโอนปัญหานี้ไปยังที่เก็บที่ถูกต้อง
    3. หากปัญหาไม่ชัดเจนหรือมีข้อมูลไม่ครบ สมาชิก DevEx จะมอบหมายปัญหากลับไปให้ผู้ใช้เพื่อขอข้อมูลเพิ่มเติมก่อนดำเนินการต่อ กรณีนี้มักเกิดขึ้นเมื่อผู้ใช้ไม่ได้ทำตามเทมเพลตปัญหา
  3. หลังจากตรวจสอบปัญหาแล้ว สมาชิก DevEx จะตัดสินใจว่าต้องตรวจสอบปัญหาดังกล่าวทันทีหรือไม่ หากมี พวกเขาจะกำหนดป้ายกำกับP0 P0 และกำหนดเจ้าของจากรายการของหัวหน้าทีม
  4. สมาชิก DevEx จะกำหนดป้ายกำกับ untriaged และป้ายกำกับทีม 1 รายการสำหรับการกำหนดเส้นทาง
  5. สมาชิก DevEx ยังกำหนดป้ายกำกับ type: เพียง 1 รายการ เช่น type: bug หรือ type: feature request ตามประเภทของปัญหา
  6. สำหรับปัญหาเฉพาะแพลตฟอร์ม สมาชิก DevEx จะกำหนดป้ายกำกับ platform: 1 รายการ เช่น platform:apple สำหรับปัญหาเฉพาะของ Mac ในขั้นตอนนี้ ปัญหาจะเข้าสู่กลุ่มปัญหาที่ยังไม่ได้แก้ไข

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

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

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

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

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

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

ปัญหา

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

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

ดึงคำขอ

  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: การจัดการทรัพยากร Dependency ภายนอก, Bzlmod, ที่เก็บระยะไกล, ไฟล์ WORKSPACE
  • team-Local-Exec: ปัญหาสำหรับทีมปฏิบัติการ (ในพื้นที่)
    • ข้อมูลติดต่อ: meisterT
  • team-OSS: ปัญหาสำหรับทีม Bazel OSS: การติดตั้ง, ขั้นตอนการเผยแพร่, แพ็กเกจ Bazel, เว็บไซต์, โครงสร้างพื้นฐานของเอกสาร
  • team-Performance: ปัญหาสำหรับทีม Bazel Performance
    • ข้อมูลติดต่อ: meisterT
  • team-Remote-Exec: ปัญหาสำหรับทีมปฏิบัติการ (ระยะไกล)
    • รายชื่อติดต่อ: coeuvre
  • team-Rules-CPP: ปัญหาสำหรับกฎ C++ รวมถึงตรรกะของกฎ Apple
    • รายชื่อติดต่อ: oquenchil
  • team-Rules-Java: ปัญหาสำหรับกฎ Java
  • team-Rules-Python: ปัญหาสำหรับกฎ Python แบบเนทีฟ
  • team-Rules-Server: ปัญหาสําหรับกฎฝั่งเซิร์ฟเวอร์ที่มาพร้อมกับ Bazel
  • 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: * เพื่อใช้ป้ายกำกับของทีมแทน

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