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

นี่คือคำแนะนำสำหรับผู้ดูแลโปรเจ็กต์โอเพนซอร์ส Bazel

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

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

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

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

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

การเปิดตัว

• Playbook สำหรับการเผยแพร่
• การทดสอบการเปลี่ยนแปลงในเครื่องกับโปรเจ็กต์ปลายทาง

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

อ่านคู่มือของทีม Green เกี่ยวกับโครงสร้างพื้นฐาน CI ของ Bazel ในที่เก็บ bazelbuild/continuous-integration

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

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

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

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

วงจรของคำขอ Pull

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

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

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

ปัญหา

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

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

คำขอพุล

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

• การคัดกรอง

  ตรวจสอบคำขอ Pull Request ที่เข้ามาเป็นประจำโดยใช้ป้ายกำกับ awaiting-review และป้ายกำกับของทีม ซึ่งสามารถดำเนินการได้โดยใช้การหมุนเวียนหรือการประชุมการคัดกรองตามปกติ เราคาดหวังว่าแต่ละ PR จะได้รับการตอบกลับเบื้องต้นภายใน 7 วันทำการ

• การตอบกลับ

  • หากคำขอให้ผสานรวมดูดีแล้ว ให้อนุมัติและใช้awaiting-PR-merge ป้ายกำกับ ทีม gTech จะนำเข้า PR เป็น CL
  • หากไม่ถูกต้อง โปรดแสดงความคิดเห็นและแทนที่ป้ายกำกับ awaiting-review ด้วยป้ายกำกับ awaiting-user-response ทีมย่อย DevEx จะ อัปเดตป้ายกำกับเป็นประจำหากผู้เขียน PR ตอบกลับ
  • สำหรับ PR ที่มีการเปลี่ยนแปลงที่สำคัญ ให้ลองขอเอกสารการออกแบบหรือ การสนทนาก่อนหน้านี้ในปัญหา

• การปิด

  เนื่องจากมีทรัพยากรจำกัด เราจึงจำเป็นต้องปิดคำขอส่งที่ไม่ได้มาตรฐานของ Bazel หรือคำขอส่งที่เราไม่มีความสามารถในการตรวจสอบหรือบำรุงรักษา

  • หาก PR ไม่สอดคล้องกับเป้าหมายของ Bazel ให้ปิด PR พร้อม คำอธิบาย
  • หากคำขอส่งรวมมีขนาดใหญ่และซับซ้อนเกินไป ให้ปิดคำขอส่งรวมนั้นพร้อมขอให้แบ่งคำขอส่งรวมออกเป็นส่วนย่อยๆ
  • หากคุณภาพของคำขอเปลี่ยนแปลงไม่เป็นไปตามมาตรฐานของเรา ให้ปิดคำขอเปลี่ยนแปลงพร้อม คำอธิบาย
  • หากค่าใช้จ่ายในการบำรุงรักษาโค้ดในอนาคตสูงเกินไป ให้ปิดด้วย คำอธิบาย
  • หาก PR รอการตอบกลับจากผู้ใช้เป็นเวลานานและผู้ร่วมให้ข้อมูลไม่ได้ตอบกลับ ระบบจะทำเครื่องหมาย PR เป็น ล้าสมัยโดยอัตโนมัติหลังจากผ่านไป 30 วัน และปิดหลังจากผ่านไปอีก 30 วัน

  เมื่อปิดคำขอให้รวมการเปลี่ยนแปลง โปรดสุภาพและอธิบายเหตุผลในการปิด

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

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

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

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

• team-Android: ปัญหาสำหรับทีม Android
  • ติดต่อ: ahumesky
• team-Bazel: ปัญหาเกี่ยวกับผลิตภัณฑ์/กลยุทธ์ Bazel ทั่วไป
  • ติดต่อ: meisterT
• team-CLI: UI ของคอนโซล
  • ติดต่อ: meisterT
• team-Configurability: ปัญหาสำหรับทีมที่ดูแลการกำหนดค่า ประกอบด้วยการกำหนดค่าบิลด์หลักและระบบการเปลี่ยนผ่าน ไม่รวมถึงการเปลี่ยนแปลงในฟีเจอร์ใหม่หรือฟีเจอร์ที่มีอยู่
  • ติดต่อ: gregestren
• team-Core: Skyframe, bazel query, BEP, options parsing, bazelrc
  • ติดต่อ: haxorz
• team-Documentation: ปัญหาสำหรับทีมเอกสาร
• team-ExternalDeps: การจัดการการขึ้นต่อกันภายนอก, Bzlmod, ที่เก็บข้อมูลระยะไกล, ไฟล์ WORKSPACE
  • ติดต่อ: meteorcloudy
• team-Loading-API: การประมวลผลไฟล์ BUILD และมาโคร: ป้ายกำกับ, package(), visibility, glob
  • ติดต่อ: brandjon
• team-Local-Exec: ปัญหาสำหรับทีมดำเนินการ (ในพื้นที่)
  • ติดต่อ: meisterT
• team-OSS: ปัญหาสำหรับทีม Bazel OSS: การติดตั้ง กระบวนการเผยแพร่ การแพ็กเกจ Bazel เว็บไซต์ โครงสร้างพื้นฐานของเอกสาร
  • ติดต่อ: meteorcloudy
• team-Performance: ปัญหาสำหรับทีมประสิทธิภาพของ Bazel
  • ติดต่อ: meisterT
• team-Remote-Exec: ปัญหาสำหรับทีมดำเนินการ (ระยะไกล)
  • ติดต่อ: coeuvre
• team-Rules-API: API สำหรับเขียนกฎ/ลักษณะ: ผู้ให้บริการ ไฟล์ที่เรียกใช้ได้ การดำเนินการ อาร์ติแฟกต์
  • ติดต่อ: pzembrod
• team-Rules-CPP / team-Rules-ObjC: ปัญหาสำหรับกฎ C++/Objective-C รวมถึงตรรกะกฎของ Apple ดั้งเดิม
  • ติดต่อ: pzembrod
• team-Rules-Java: ปัญหาสำหรับกฎ Java
  • ติดต่อ: hvadehra
• team-Rules-Python: ปัญหาสำหรับกฎ Python ดั้งเดิม
  • ติดต่อ: rickeylev
• team-Rules-Server: ปัญหาเกี่ยวกับกฎฝั่งเซิร์ฟเวอร์ที่รวมอยู่ใน Bazel
  • ติดต่อ: pzembrod
• 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: * เพื่อใช้ป้ายกำกับของทีม แทน

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