คู่มือสำหรับผู้บำรุงรักษา 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. หากได้รับอนุมัติ ผู้ตรวจสอบจะนำเข้าการคอมมิตของ PR ไปยังระบบควบคุมเวอร์ชันภายในของ Google เพื่อทำการทดสอบเพิ่มเติม เนื่องจาก Bazel เป็นระบบบิลด์เดียวกันกับที่ใช้ภายใน Google เราจึงต้องทดสอบคอมมิตคำขอแก้ไขทั้งหมดกับชุดการทดสอบภายใน ด้วยเหตุนี้เราจึงไม่ผสานรวมคำขอ Pull โดยตรง
6. หากคอมมิตที่นำเข้าผ่านการทดสอบภายในทั้งหมด ระบบจะบีบอัดคอมมิต และส่งออกกลับไปยัง GitHub
7. เมื่อผสานรวมการคอมมิตเข้ากับมาสเตอร์แล้ว GitHub จะปิด PR โดยอัตโนมัติ

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

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

ปัญหา

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

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

Pull Request

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

• การคัดกรอง

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

• การตอบกลับ

  • หากคำขอรวมการเปลี่ยนแปลงดูดีแล้ว ให้อนุมัติและใช้awaiting-PR-merge ป้ายกำกับ ทีม gTech จะนำเข้า PR เป็น CL
  • หรือแสดงความคิดเห็นและแทนที่ป้ายกำกับ awaiting-review ด้วยป้ายกำกับ awaiting-user-response ทีมย่อย DevEx จะ อัปเดตป้ายกำกับเป็นประจำหากผู้เขียน 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: * เพื่อให้ทีมใช้ป้ายกำกับ แทน

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