คู่มือสำหรับผู้บำรุงรักษา 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 จะส่งปัญหากลับไปให้ผู้ใช้เพื่อขอข้อมูลเพิ่มเติมก่อนที่จะดำเนินการต่อ กรณีนี้มักเกิดขึ้นเมื่อผู้ใช้ไม่เลือก เทมเพลตปัญหา {: .external} หรือให้ข้อมูลที่ไม่ครบถ้วน
  3. หลังจากตรวจสอบปัญหา สมาชิก DevEx จะตัดสินใจว่าต้องดำเนินการทันทีหรือไม่ หากมี ทีมจะกำหนดป้ายกำกับP0 และเจ้าของจากรายการโอกาสในการขายของทีม
  4. สมาชิก DevEx จะกำหนดป้ายกำกับ untriaged และป้ายกำกับทีมเพียง 1 ป้ายสำหรับการกำหนดเส้นทาง
  5. สมาชิก DevEx ยังกำหนดป้ายกำกับ type: เพียงรายการเดียว เช่น type: bug หรือ type: feature request ตามประเภทของปัญหา
  6. สำหรับปัญหาเฉพาะแพลตฟอร์ม สมาชิก DevEx จะกำหนดป้ายกำกับ platform: 1 รายการ เช่น platform:apple สำหรับปัญหาเฉพาะ Mac
  7. หากปัญหามีลำดับความสำคัญต่ำและผู้ร่วมให้ข้อมูลชุมชนรายใหม่ช่วยแก้ปัญหาได้ สมาชิก DevEx จะมอบหมายป้ายกำกับ good first issue ในขั้นนี้ ปัญหาจะเข้าสู่กลุ่มของปัญหาที่ยังไม่ได้รับการแก้ไข

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

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

วงจรคำขอพุล

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

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

ดึงคำขอ

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

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

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

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

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

  • team-Android: ปัญหาสำหรับทีม Android
    • ข้อมูลติดต่อ: ahumesky
  • team-Bazel: ปัญหาเกี่ยวกับผลิตภัณฑ์/กลยุทธ์ทั่วไปของ Bazel
  • team-CLI: UI ของคอนโซล
  • team-Configurability: ปัญหาสำหรับทีมความสามารถในการกำหนดค่า ประกอบด้วย: ระบบการเปลี่ยนและการกำหนดค่าบิวด์หลัก ไม่รวมถึงการเปลี่ยนแปลงการแจ้งว่าไม่เหมาะสมใหม่หรือที่มีอยู่
    • ข้อมูลติดต่อ: gregestren
  • team-Core: Skyframe, การค้นหาเบเซล, BEP, การแยกวิเคราะห์ตัวเลือก, bazelrc
    • ข้อมูลติดต่อ: haxorz
  • team-Documentation: ปัญหาสำหรับทีมจัดทำเอกสาร
  • team-ExternalDeps: การจัดการทรัพยากร Dependency ภายนอก, Bzlmod, ที่เก็บระยะไกล, ไฟล์ WORKSPACE
  • team-Loading-API: ไฟล์ BUILD และการประมวลผลมาโคร: ป้ายกำกับ, package(), ระดับการเข้าถึง, glob
  • team-Local-Exec: ปัญหาสำหรับทีมปฏิบัติการ (ในพื้นที่)
  • team-OSS: ปัญหาสำหรับทีม Bazel OSS: การติดตั้ง, กระบวนการเผยแพร่, แพ็กเกจ Bazel, เว็บไซต์, โครงสร้างพื้นฐานของเอกสาร
  • team-Performance: ปัญหาสำหรับทีม Bazel Performance
  • team-Remote-Exec: ปัญหาสำหรับทีมปฏิบัติการ (ระยะไกล)
    • การติดต่อ: coeuvre
  • team-Rules-API: API สำหรับการเขียนกฎ/แง่มุม: ผู้ให้บริการ ไฟล์รัน การดำเนินการ อาร์ติแฟกต์
  • team-Rules-CPP / team-Rules-ObjC: ปัญหาสำหรับกฎ C++/Objective-C รวมถึงตรรกะของกฎดั้งเดิมของ Apple
  • team-Rules-Java: ปัญหาสำหรับกฎ Java
  • team-Rules-Python: ปัญหาสำหรับกฎ Python แบบเนทีฟ
    • รายชื่อติดต่อ: rickeylev
  • team-Rules-Server: ปัญหาสำหรับกฎฝั่งเซิร์ฟเวอร์ที่รวมใน Bazel
  • team-Starlark-Integration: การผสานรวม Bazel + Starlark ที่ไม่ใช่ API รวม: วิธีที่ Bazel ทริกเกอร์อินเทอร์พรีเตอร์ของ Starlark, Stardoc, Builtins Injection, การเข้ารหัสอักขระ ไม่มีปัญหาเกี่ยวกับภาษา BUILD หรือ .bzl
  • team-Starlark-Interpreter: ปัญหาสำหรับล่าม Starlark (ทุกอย่างใน java.net.starlark) ปัญหาเกี่ยวกับ BUILD และ .bzl API (ซึ่งแสดงถึงการผสานรวมของ Bazel กับ Starlark) จะอยู่ใน team-Build-Language

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

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