นี่คือคู่มือสำหรับผู้บำรุงรักษาโครงการโอเพนซอร์ส Bazel
หากคุณต้องการสนับสนุน Bazel โปรดอ่านการมีส่วนร่วมใน Bazel แทน
หน้านี้มีวัตถุประสงค์เพื่อ
- ทำหน้าที่เป็นแหล่งข้อมูลที่เชื่อถือได้สำหรับผู้ดูแลรักษาสำหรับกระบวนการสนับสนุนโครงการ
- กำหนดความคาดหวังระหว่างผู้สนับสนุนของชุมชนและผู้ดูแลโครงการ
กลุ่มผู้มีส่วนร่วมหลักของ Bazel มีทีมย่อยที่ใช้จัดการด้านต่างๆ ของโปรเจ็กต์โอเพนซอร์สโดยเฉพาะ ได้แก่
- กระบวนการเผยแพร่: จัดการกระบวนการเผยแพร่ของ Bazel
- ทีมสีเขียว: สร้างระบบนิเวศที่ดีด้วยกฎและเครื่องมือต่างๆ
- นักจัดสวนด้านประสบการณ์ของนักพัฒนาซอฟต์แวร์: ส่งเสริมการมีส่วนร่วมจากภายนอก ตรวจสอบปัญหาและดึงคำขอ และทำให้เวิร์กโฟลว์การพัฒนาของเราเปิดกว้างมากขึ้น
การเปิดตัว
การรวมอย่างต่อเนื่อง
อ่านคำแนะนำของทีม Green เกี่ยวกับโครงสร้างพื้นฐาน CI ของ Bazel ในที่เก็บการสร้างแบบเบเซล/การผสานรวมอย่างต่อเนื่อง
วงจรของปัญหา
- ผู้ใช้สร้างปัญหาโดยใช้เทมเพลตปัญหาและส่งกลุ่มของปัญหาที่ยังไม่ได้ตรวจสอบเข้ามา
- สมาชิกในการหมุนเวียนทีมย่อยประสบการณ์นักพัฒนาซอฟต์แวร์ (DevEx) จะตรวจสอบปัญหา
- หากปัญหานั้นไม่ใช่ข้อบกพร่องหรือคำขอฟีเจอร์ สมาชิก DevEx มักจะปิดปัญหาดังกล่าวและเปลี่ยนเส้นทางผู้ใช้ไปยัง StackOverflow และ Bazel-discuss เพื่อให้มองเห็นคำถามได้ชัดเจนขึ้น
- หากปัญหาอยู่ในที่เก็บกฎแห่งใดแห่งหนึ่งที่ชุมชนเป็นเจ้าของ เช่น rules_apple สมาชิก DevEx จะโอนปัญหานี้ไปยังที่เก็บที่ถูกต้อง
- หากปัญหาไม่ชัดเจนหรือมีข้อมูลไม่ครบ สมาชิก DevEx จะมอบหมายปัญหากลับไปให้ผู้ใช้เพื่อขอข้อมูลเพิ่มเติมก่อนดำเนินการต่อ กรณีนี้มักเกิดขึ้นเมื่อผู้ใช้ไม่ได้ทำตามเทมเพลตปัญหา
- หลังจากตรวจสอบปัญหาแล้ว สมาชิก DevEx จะตัดสินใจว่าต้องตรวจสอบปัญหาดังกล่าวทันทีหรือไม่ หากมี พวกเขาจะกำหนดป้ายกำกับP0 P0 และกำหนดเจ้าของจากรายการของหัวหน้าทีม
- สมาชิก DevEx จะกำหนดป้ายกำกับ
untriaged
และป้ายกำกับทีม 1 รายการสำหรับการกำหนดเส้นทาง - สมาชิก DevEx ยังกำหนดป้ายกำกับ
type:
เพียง 1 รายการ เช่นtype: bug
หรือtype: feature request
ตามประเภทของปัญหา - สำหรับปัญหาเฉพาะแพลตฟอร์ม สมาชิก DevEx จะกำหนดป้ายกำกับ
platform:
1 รายการ เช่นplatform:apple
สำหรับปัญหาเฉพาะของ Mac ในขั้นตอนนี้ ปัญหาจะเข้าสู่กลุ่มปัญหาที่ยังไม่ได้แก้ไข
ทีมย่อย Bazel แต่ละทีมจะคัดแยกปัญหาทั้งหมดภายใต้ป้ายกำกับที่ตนเป็นเจ้าของ โดยทำเป็นรายสัปดาห์ ทีมย่อยจะตรวจสอบและประเมินปัญหา รวมทั้งหาวิธีแก้ไข หากทำได้ หากคุณเป็นเจ้าของป้ายกำกับทีม โปรดดูข้อมูลเพิ่มเติมที่ส่วนนี้
เมื่อปัญหาได้รับการแก้ไขแล้ว จะสามารถปิดปัญหาดังกล่าวได้
วงจรของคำขอพุล
- ผู้ใช้สร้างคำขอพุล
- ถ้าคุณเป็นสมาชิกของทีม Bazel และส่ง PR ไปยังพื้นที่ของคุณเอง คุณมีหน้าที่รับผิดชอบในการติดป้ายกำกับทีมและค้นหาผู้ตรวจสอบที่ดีที่สุด
- หรือในระหว่างการตรวจสอบรายวัน สมาชิก DevEx จะกำหนดป้ายกำกับทีม 1 ป้ายและหัวหน้าฝ่ายเทคนิค (TL) ของทีมสำหรับการกำหนดเส้นทาง
- ทั้งนี้ TL อาจมอบหมายให้บุคคลอื่นตรวจสอบการประชาสัมพันธ์
- ผู้ตรวจสอบที่ได้รับมอบหมายจะตรวจสอบการประชาสัมพันธ์และทำงานร่วมกับผู้เขียนจนกว่าจะได้รับอนุมัติหรือถูกปฏิเสธ
- หากได้รับอนุมัติ ผู้ตรวจสอบจะนำเข้าคอมมิตของ PR ไปยังระบบการควบคุมเวอร์ชันภายในของ Google เพื่อทำการทดสอบเพิ่มเติม เนื่องจาก Bazel เป็นระบบบิลด์เดียวกันกับที่ใช้ภายในที่ Google เราจึงต้องทดสอบสัญญาผูกมัดด้านการประชาสัมพันธ์ทั้งหมดกับชุดทดสอบภายใน นี่คือเหตุผลที่เราไม่รวม PR โดยตรง
- หากคอมมิตที่นำเข้าผ่านการทดสอบภายในทั้งหมด ระบบจะบีบคอมมิตนั้นและส่งออกไปยัง GitHub
- เมื่อคอมมิตผสานเข้ากับต้นฉบับ GitHub จะปิด PR โดยอัตโนมัติ
ทีมของฉันเป็นเจ้าของป้ายกำกับ ควรทำอย่างไร
ทีมย่อยจะต้องตรวจสอบปัญหาทั้งหมดในป้ายกำกับที่ตนเป็นเจ้าของ โดยเฉพาะอย่างยิ่งเป็นรายสัปดาห์
ปัญหา
- กรองรายการปัญหาตามป้ายกำกับของทีมและป้ายกำกับ
untriaged
- ตรวจสอบปัญหา
- ระบุลำดับความสำคัญและกำหนดป้ายกำกับ
- ทีมย่อย DevEx อาจจัดลำดับความสำคัญให้ปัญหาแล้วหากเป็น P0 จัดลำดับความสำคัญใหม่หากจำเป็น
- ปัญหาแต่ละรายการต้องมีป้ายกำกับลำดับความสำคัญ 1 รายการเท่านั้น หากปัญหาเป็น P0 หรือ P1 เราจะถือว่ามีการดำเนินการอย่างต่อเนื่อง
- โปรดนำป้ายกำกับ
untriaged
ออก
โปรดทราบว่าคุณต้องอยู่ใน bazelbuild organization จึงจะเพิ่มหรือนำป้ายกำกับออกได้
ดึงคำขอ
- กรองรายการคำขอพุลตามป้ายกำกับทีม
- ตรวจสอบคำขอพุลที่เปิดอยู่
- ไม่บังคับ: หากคุณได้รับกำหนดให้ตรวจสอบแต่ไม่เหมาะกับการตรวจสอบ ให้มอบหมายผู้ตรวจสอบที่เหมาะสมอีกครั้งเพื่อดำเนินการตรวจสอบโค้ด
- ทำงานร่วมกับเครื่องมือสร้างพุลคำขอเพื่อตรวจสอบโค้ดให้เสร็จสมบูรณ์
- อนุมัติ PR
- ตรวจดูว่าการทดสอบทั้งหมดผ่าน
- นำเข้าแพตช์ไปยังระบบควบคุมเวอร์ชันภายใน และเรียกใช้การส่งล่วงหน้าภายใน
- ส่งแพตช์ภายใน หากแพตช์ส่งและส่งออกสำเร็จ 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- รายชื่อติดต่อ: meteorcloudy
team-Local-Exec
: ปัญหาสำหรับทีมปฏิบัติการ (ในพื้นที่)- ข้อมูลติดต่อ: meisterT
team-OSS
: ปัญหาสำหรับทีม Bazel OSS: การติดตั้ง, ขั้นตอนการเผยแพร่, แพ็กเกจ Bazel, เว็บไซต์, โครงสร้างพื้นฐานของเอกสาร- รายชื่อติดต่อ: meteorcloudy
team-Performance
: ปัญหาสำหรับทีม Bazel Performance- ข้อมูลติดต่อ: meisterT
team-Remote-Exec
: ปัญหาสำหรับทีมปฏิบัติการ (ระยะไกล)- รายชื่อติดต่อ: coeuvre
team-Rules-CPP
: ปัญหาสำหรับกฎ C++ รวมถึงตรรกะของกฎ Apple- รายชื่อติดต่อ: oquenchil
team-Rules-Java
: ปัญหาสำหรับกฎ Java- ติดต่อ: comius
team-Rules-Python
: ปัญหาสำหรับกฎ Python แบบเนทีฟ- ติดต่อ: comius
team-Rules-Server
: ปัญหาสําหรับกฎฝั่งเซิร์ฟเวอร์ที่มาพร้อมกับ Bazel- ติดต่อ: comius
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: *
เพื่อใช้ป้ายกำกับของทีมแทน
ดูรายการป้ายกำกับทั้งหมดได้ที่นี่