คู่มือนี้มีไว้สำหรับผู้ดูแลโปรเจ็กต์โอเพนซอร์ส Bazel
หากต้องการมีส่วนร่วมใน Bazel โปรดอ่านการมีส่วนร่วมใน Bazel แทน
วัตถุประสงค์ของหน้านี้มีดังนี้
- เป็นแหล่งข้อมูลที่เชื่อถือได้ของผู้ดูแลสำหรับกระบวนการมีส่วนร่วมในโปรเจ็กต์
- กำหนดความคาดหวังระหว่างผู้มีส่วนร่วมในชุมชนกับผู้ดูแลโครงการ
กลุ่มผู้มีส่วนร่วมหลักของ Bazel มีทีมย่อยเฉพาะเพื่อจัดการแง่มุมต่างๆ ของโปรเจ็กต์โอเพนซอร์ส ได้แก่
- กระบวนการเผยแพร่: จัดการกระบวนการเผยแพร่ของ Bazel
- ทีมสีเขียว: พัฒนาระบบนิเวศของกฎและเครื่องมือให้มีประสิทธิภาพ
- ผู้ดูแลประสบการณ์ของนักพัฒนาซอฟต์แวร์: ส่งเสริมให้ผู้อื่นมีส่วนร่วม ตรวจสอบปัญหาและคำขอดึงข้อมูล และทำให้เวิร์กโฟลว์การพัฒนาของเราเปิดกว้างมากขึ้น
การเปิดตัว
การรวมอย่างต่อเนื่อง
อ่านคู่มือของทีม Green สําหรับโครงสร้างพื้นฐาน CI ของ Bazel ในที่เก็บรวบรวม bazelbuild/continuous-integration
วงจรของปัญหา
- ผู้ใช้สร้างปัญหาโดยเลือกเทมเพลตปัญหารายการใดรายการหนึ่ง แล้วปัญหาดังกล่าวจะเข้าสู่กลุ่มปัญหาที่ยังไม่ผ่านการตรวจสอบ
- สมาชิกในทีมย่อยประสบการณ์ของนักพัฒนาซอฟต์แวร์ (DevEx) จะตรวจสอบปัญหา
- หากปัญหาไม่ใช่ข้อบกพร่องหรือคำขอฟีเจอร์ สมาชิก DevEx มักจะปิดปัญหาและเปลี่ยนเส้นทางผู้ใช้ไปยัง StackOverflow และ bazel-discuss เพื่อให้คำถามได้รับการแสดงผลมากขึ้น
- หากปัญหาอยู่ในที่เก็บกฎใดที่เก็บกฎใดที่ชุมชนเป็นเจ้าของ เช่น rules_apple สมาชิก DevEx จะโอนปัญหานี้ไปยังที่เก็บที่ถูกต้อง
- หากปัญหาไม่ชัดเจนหรือมีข้อมูลขาดหายไป สมาชิก DevEx จะส่งปัญหากลับไปให้ผู้ใช้เพื่อขอข้อมูลเพิ่มเติมก่อนดำเนินการต่อ ซึ่งมักเกิดขึ้นเมื่อผู้ใช้ไม่ได้เลือกเทมเพลตปัญหาที่ถูกต้อง หรือให้ข้อมูลไม่ครบถ้วน {: .external}
- หลังจากตรวจสอบปัญหาแล้ว สมาชิก DevEx จะตัดสินใจว่าปัญหาดังกล่าวต้องได้รับการดำเนินการในทันทีหรือไม่ หากเป็นเช่นนั้น หัวหน้าทีมจะกำหนดป้ายกำกับP0 สำคัญและเจ้าของจากรายชื่อหัวหน้าทีม
- สมาชิก DevEx จะกำหนดป้ายกํากับ
untriaged
และป้ายกํากับทีม 1 รายการสําหรับการกำหนดเส้นทาง - สมาชิก DevEx จะกำหนดป้ายกำกับ
type:
เพียง 1 รายการ เช่นtype: bug
หรือtype: feature request
ตามประเภทของปัญหา - สำหรับปัญหาเฉพาะแพลตฟอร์ม สมาชิก DevEx จะกำหนดป้ายกำกับ
platform:
รายการเดียว เช่นplatform:apple
สำหรับปัญหาเฉพาะ Mac - หากปัญหามีลำดับความสำคัญต่ำและสมาชิกชุมชนคนใหม่สามารถแก้ไขได้ สมาชิก DevEx จะกำหนดป้ายกำกับ
good first issue
ในขั้นตอนนี้ ปัญหาจะเข้าสู่กลุ่มปัญหาที่ยังไม่จัดการ
ทีมย่อยของ Bazel แต่ละทีมจะจัดประเภทปัญหาทั้งหมดภายใต้ป้ายกำกับที่ตนเป็นเจ้าของ โดยควรทำเป็นรายสัปดาห์ ทีมย่อยจะตรวจสอบและประเมินปัญหา รวมถึงให้วิธีแก้ปัญหา (หากเป็นไปได้) หากคุณเป็นเจ้าของป้ายกำกับทีม โปรดดูข้อมูลเพิ่มเติมในส่วนนี้
เมื่อปัญหาได้รับการแก้ไขแล้ว คุณจะปิดปัญหานั้นได้
วงจรของคำขอพุล
- ผู้ใช้สร้างคำขอดึงข้อมูล
- หากคุณเป็นสมาชิกของทีม Bazel และส่ง PR ไปยังพื้นที่ของคุณเอง คุณมีหน้าที่รับผิดชอบในการกำหนดป้ายกำกับของทีมและค้นหาผู้ตรวจสอบที่เหมาะสมที่สุด
- หรือในระหว่างการจัดประเภทปัญหาในแต่ละวัน สมาชิก DevEx จะกำหนดป้ายกำกับทีมและหัวหน้าทีมเทคนิค (TL) 1 คนเพื่อกำหนดเส้นทาง
- TL อาจมอบหมายให้ผู้อื่นตรวจสอบ PR แทนก็ได้
- ผู้ตรวจสอบที่ได้รับมอบหมายจะตรวจสอบ PR และทำงานร่วมกับผู้เขียนจนกว่า PR จะได้รับอนุมัติหรือถูกยกเลิก
- หากได้รับอนุมัติ ผู้ตรวจสอบจะimportsการคอมมิตของ PR ไปยังระบบควบคุมเวอร์ชันภายในของ Google เพื่อทดสอบเพิ่มเติม เนื่องจาก Bazel เป็นระบบบิลด์เดียวกับที่ใช้ภายในที่ Google เราจึงต้องทดสอบการคอมมิต PR ทั้งหมดกับชุดทดสอบภายใน ด้วยเหตุนี้ เราจึงไม่ผสาน PR โดยตรง
- หากคอมมิตที่นําเข้าผ่านการทดสอบภายในทั้งหมด ระบบจะรวมคอมมิตและส่งออกกลับไปยัง GitHub
- เมื่อผสานคอมมิตลงในต้นทางแล้ว GitHub จะปิด PR โดยอัตโนมัติ
ทีมของฉันเป็นเจ้าของป้ายกำกับ ฉันควรทำอย่างไร
ทีมย่อยต้องจัดลําดับความสําคัญของปัญหาทั้งหมดในป้ายกำกับที่ตนเป็นเจ้าของ โดยควรทำเป็นรายสัปดาห์
ปัญหา
- กรองรายการปัญหาตามป้ายกำกับทีมและป้ายกำกับ
untriaged
- ตรวจสอบปัญหา
- ระบุลําดับความสําคัญและมอบหมายป้ายกํากับ
- ทีมย่อย DevEx อาจจัดลําดับความสําคัญของปัญหาแล้วหากเป็น P0 จัดลําดับความสําคัญใหม่หากจําเป็น
- ปัญหาแต่ละรายการต้องมีป้ายกำกับลำดับความสำคัญเพียงรายการเดียว หากปัญหาเป็น P0 หรือ P1 เราจะถือว่ามีการดำเนินการอยู่
- นำป้ายกำกับ
untriaged
ออก
โปรดทราบว่าคุณต้องอยู่ในองค์กร bazelbuild จึงจะเพิ่มหรือนำป้ายกำกับออกได้
คำขอพุล
- กรองรายการคำขอดึงข้อมูลตามป้ายกำกับทีม
- ตรวจสอบคำขอดึงข้อมูลแบบเปิด
- ไม่บังคับ: หากคุณได้รับมอบหมายให้ตรวจสอบแต่ไม่เหมาะกับหน้าที่ดังกล่าว ให้มอบหมายผู้ตรวจสอบที่เหมาะสมให้ดำเนินการตรวจสอบโค้ดอีกครั้ง
- ทำงานร่วมกับผู้สร้างคำขอดึงเพื่อดำเนินการตรวจสอบโค้ดให้เสร็จสมบูรณ์
- อนุมัติ PR
- ตรวจสอบว่าการทดสอบทั้งหมดผ่าน
- นําเข้าแพตช์ไปยังระบบควบคุมเวอร์ชันภายในและเรียกใช้การส่งภายในล่วงหน้า
- ส่งแพตช์ภายใน หากส่งและส่งออกแพตช์สำเร็จแล้ว GitHub จะปิด PR โดยอัตโนมัติ
ลำดับความสำคัญ
ผู้ดูแลจะใช้คำจำกัดความต่อไปนี้สำหรับลําดับความสําคัญเพื่อคัดแยกปัญหา
- P0 - ฟังก์ชันการทํางานที่สำคัญใช้งานไม่ได้ ซึ่งทําให้รุ่น Bazel (ยกเว้นรุ่นที่พร้อมใช้งาน) ใช้งานไม่ได้ หรือบริการหยุดทํางานซึ่งส่งผลกระทบต่อการพัฒนาโปรเจ็กต์ Bazel อย่างรุนแรง ซึ่งรวมถึงการถดถอยที่เกิดขึ้นในรุ่นใหม่ซึ่งบล็อกผู้ใช้จํานวนมาก หรือการเปลี่ยนแปลงที่ทําให้ใช้งานไม่ได้ซึ่งไม่เป็นไปตามนโยบายการเปลี่ยนแปลงที่ทําให้ใช้งานไม่ได้ ไม่มีวิธีแก้ปัญหาที่ใช้งานได้จริง
- P1 - ข้อบกพร่องหรือฟีเจอร์ที่สำคัญซึ่งควรได้รับการแก้ไขในรุ่นถัดไป หรือปัญหาร้ายแรงที่ส่งผลกระทบต่อผู้ใช้จำนวนมาก (รวมถึงการพัฒนาโปรเจ็กต์ Bazel) แต่มีวิธีแก้ปัญหาที่ใช้งานได้จริง โดยปกติแล้วคุณไม่จำเป็นต้องดำเนินการใดๆ ในทันที มีความต้องการสูงและอยู่ในแผนงานของไตรมาสปัจจุบัน
- P2 - ข้อบกพร่องหรือฟีเจอร์ที่ควรได้รับการแก้ไข แต่เราไม่ได้ดำเนินการในขณะนี้ ปัญหาที่ใช้งานจริงอยู่ในระดับปานกลางใน Bazel เวอร์ชันที่เผยแพร่ซึ่งไม่สะดวกสำหรับผู้ใช้และจำเป็นต้องได้รับการแก้ไขในรุ่นถัดไป และ/หรือมีวิธีแก้ปัญหาง่ายๆ
- P3 - การแก้ไขข้อบกพร่องเล็กน้อยหรือการเพิ่มประสิทธิภาพที่ควรทำและส่งผลไม่มาก ไม่ได้อยู่ในลำดับความสำคัญของแผนงาน Bazel หรือรุ่นที่กำลังจะเปิดตัว แต่เรายินดีรับการมีส่วนร่วมจากชุมชน
- P4 - ข้อบกพร่องหรือคำขอฟีเจอร์ที่มีลำดับความสำคัญต่ำซึ่งไม่มีแนวโน้มที่จะได้รับการแก้ไข นอกจากนี้ยังสามารถเปิดอยู่เพื่อจัดลําดับความสําคัญใหม่ได้หากมีผู้ใช้จำนวนมากขึ้นที่ได้รับผลกระทบ
- ice-box
- ปัญหาที่เราไม่มีเวลาจัดการหรือรับผลงานในขณะนี้ เราจะปิดปัญหาเหล่านี้เพื่อระบุว่าไม่มีผู้ใดกำลังดำเนินการอยู่ แต่เราจะตรวจสอบความถูกต้องของปัญหาเหล่านี้ต่อไปและเปิดปัญหาขึ้นมาใหม่หากมีผู้ได้รับผลกระทบจำนวนมากพอและเรามีทรัพยากรในการดำเนินการ โปรดแสดงความคิดเห็นหรือรีแอ็กชันต่อปัญหาเหล่านี้ได้เสมอ แม้ว่าจะปิดไปแล้วก็ตาม
ป้ายกำกับทีม
team-Android
: ปัญหาสำหรับทีม Android- ติดต่อ: ahumesky
team-Bazel
: ปัญหาทั่วไปเกี่ยวกับผลิตภัณฑ์/กลยุทธ์ของ Bazel- ติดต่อ: sventiffe
team-CLI
: UI ของคอนโซล- ติดต่อ: meisterT
team-Configurability
: ปัญหาสำหรับทีมการกำหนดค่า ซึ่งรวมถึงการกำหนดค่าบิลด์หลักและระบบการเปลี่ยน ไม่รวมการเปลี่ยนแปลงในธงใหม่หรือธงที่มีอยู่- ติดต่อ: gregestren
team-Core
: Skyframe, การค้นหา Bazel, BEP, การแยกวิเคราะห์ตัวเลือก, bazelrc- ติดต่อ: haxorz
team-Documentation
: ปัญหาสำหรับทีมเอกสารประกอบ- ติดต่อ: philomathing
team-ExternalDeps
: การจัดการทรัพยากรภายนอก, Bzlmod, รีโพซิทอรีระยะไกล, ไฟล์ WORKSPACE- ติดต่อ: meteorcloudy
team-Loading-API
: การสร้างไฟล์และการประมวลผลมาโคร: labels, 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 สําหรับเขียนกฎ/แง่มุม: ผู้ให้บริการ, ไฟล์รันไทม์, การดำเนินการ, อาร์ติแฟกต์- ติดต่อ: comius
team-Rules-CPP
/team-Rules-ObjC
: ปัญหาเกี่ยวกับกฎ C++/Objective-C รวมถึงตรรกะกฎของ Apple ดั้งเดิม- ติดต่อ: oquenchil
team-Rules-Java
: ปัญหาเกี่ยวกับกฎ Java- ติดต่อ: hvadehra
team-Rules-Python
: ปัญหาเกี่ยวกับกฎ Python ดั้งเดิม- ติดต่อ: rickeylev
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: *
แล้วหันมาใช้ป้ายกํากับของทีมแทน
ดูรายการป้ายกำกับทั้งหมดได้ที่นี่