คู่มือนี้มีไว้สำหรับผู้ดูแลโปรเจ็กต์โอเพนซอร์ส 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:
1 ป้าย เช่นplatform:apple
สำหรับปัญหาเฉพาะของ Mac - หากปัญหามีลำดับความสำคัญต่ำและสมาชิกชุมชนคนใหม่สามารถแก้ไขได้ สมาชิก DevEx จะกำหนดป้ายกำกับ
good first issue
ในขั้นตอนนี้ ปัญหาจะเข้าสู่กลุ่มปัญหาที่ยังไม่จัดการ
ทีมย่อยของ Bazel จะตรวจสอบปัญหาทั้งหมดตามป้ายกำกับที่ตนเป็นเจ้าของ หากเป็นไปได้ ทุกสัปดาห์ ทีมย่อยจะตรวจสอบและประเมินปัญหา รวมถึงระบุ หากเป็นไปได้ หากคุณเป็นเจ้าของป้ายกำกับทีม โปรดดูส่วนนี้ เพื่อดูข้อมูลเพิ่มเติม
เมื่อปัญหาได้รับการแก้ไขแล้ว คุณจะปิดปัญหานั้นได้
วงจรของคำขอพุล
- ผู้ใช้สร้างคำขอดึงข้อมูล
- หากคุณเป็นสมาชิกของทีม Bazel และส่งการประชาสัมพันธ์ไปยังพื้นที่ของคุณ คุณต้องรับผิดชอบในการกำหนดป้ายกำกับของทีมและค้นหาสิ่งที่ดีที่สุด ผู้ตรวจสอบเนื้อหา
- มิฉะนั้น ระหว่างการคัดแยกรายวัน สมาชิก DevEx จะมอบหมาย
ป้ายกำกับทีม และหัวหน้าด้านเทคนิค (TL) ของทีมสำหรับการกำหนดเส้นทาง
- TL อาจมอบหมายให้บุคคลอื่นตรวจสอบ PR
- ผู้ตรวจสอบที่ได้รับมอบหมายจะตรวจสอบ PR และทำงานร่วมกับผู้เขียนจนกว่า PR จะได้รับอนุมัติหรือถูกยกเลิก
- หากได้รับอนุมัติ ผู้ตรวจสอบจะนำเข้าสัญญาผูกมัดของการประชาสัมพันธ์ไปยัง ระบบควบคุมเวอร์ชันภายในสำหรับการทดสอบเพิ่มเติม เนื่องจาก Bazel เป็นบิลด์เดียวกัน ที่ใช้เป็นการภายในที่ Google เราต้องทดสอบการดำเนินการ PR ทั้งหมดกับ ชุดทดสอบภายใน นี่คือเหตุผลที่เราไม่ผสาน PR โดยตรง
- หากคอมมิตที่นําเข้าผ่านการทดสอบภายในทั้งหมด ระบบจะรวมคอมมิตและส่งออกกลับไปยัง GitHub
- เมื่อผสานคอมมิตลงในต้นทางแล้ว GitHub จะปิด PR โดยอัตโนมัติ
ทีมของฉันเป็นเจ้าของป้ายกำกับ ฉันควรทำอย่างไร
ทีมย่อยต้องคัดแยกปัญหาทั้งหมดในป้ายกำกับที่ตนเองเป็นเจ้าของ แนะนำให้ทำเป็นรายสัปดาห์
ปัญหา
- กรองรายการปัญหาตามป้ายกำกับของทีมและป้ายกำกับ
untriaged
- ตรวจสอบปัญหา
- ระบุลําดับความสําคัญและมอบหมายป้ายกํากับ
- ทีมย่อยของ DevEx อาจให้ความสำคัญกับปัญหานี้ไปแล้วหากเป็น หน้า 0 จัดลําดับความสําคัญใหม่หากจําเป็น
- ปัญหาแต่ละรายการต้องมีป้ายกำกับลำดับความสำคัญเพียงรายการเดียว หากมี ปัญหาคือระดับ P0 หรือ P1 ที่เราถือว่ากำลังดำเนินการอยู่
- นำป้ายกำกับ
untriaged
ออก
โปรดทราบว่าคุณต้องอยู่ในองค์กร bazelbuild จึงจะเพิ่มหรือนำป้ายกำกับออกได้
คำขอพุล
- กรองรายการคำขอพุลตามป้ายกำกับทีม
- ตรวจสอบคำขอพุลที่เปิดอยู่
- ไม่บังคับ: หากคุณได้รับมอบหมายให้ตรวจสอบแต่ไม่เหมาะกับหน้าที่ดังกล่าว ให้มอบหมายผู้ตรวจสอบที่เหมาะสมให้ดำเนินการตรวจสอบโค้ดอีกครั้ง
- ทำงานร่วมกับผู้สร้างคำขอดึงเพื่อดำเนินการตรวจสอบโค้ดให้เสร็จสมบูรณ์
- อนุมัติ PR
- ตรวจสอบว่าการทดสอบทั้งหมดผ่าน
- นำเข้าแพตช์ไปยังระบบควบคุมเวอร์ชันภายในและเรียกใช้ ที่ส่งล่วงหน้า
- ส่งแพตช์ภายใน หากส่งและส่งออกแพตช์สำเร็จแล้ว GitHub จะปิด PR โดยอัตโนมัติ
ลำดับความสำคัญ
ผู้ดูแลจะใช้คำจำกัดความต่อไปนี้สำหรับลําดับความสําคัญเพื่อคัดแยกปัญหา
- P0 - ใช้งานไม่ได้มาก ฟังก์ชันที่ทำให้รุ่น Bazel (ไม่รวมรุ่นที่เผยแพร่) ไม่สามารถใช้งานได้ หรือบริการล่มที่ส่งผลต่อการพัฒนา Bazel อย่างรุนแรง ซึ่งรวมถึงการถดถอยที่เกิดขึ้นในรุ่นใหม่ซึ่งบล็อกผู้ใช้จํานวนมาก หรือการเปลี่ยนแปลงที่ทําให้ใช้งานไม่ได้ซึ่งไม่เป็นไปตามนโยบายการเปลี่ยนแปลงที่ทําให้ใช้งานไม่ได้ ไม่มีวิธีแก้ปัญหาที่ใช้งานได้จริง
- P1 - ข้อบกพร่องร้ายแรง หรือ ที่ควรระบุในรุ่นถัดไป หรือปัญหาร้ายแรงที่ ส่งผลต่อผู้ใช้จำนวนมาก (รวมถึงการพัฒนาโครงการ Bazel) มีวิธีแก้ปัญหาเชิงปฏิบัติ โดยปกติแล้วไม่จําเป็นต้องดําเนินการใดๆ ในทันที ใน เป็นที่ต้องการอย่างมาก และได้วางแผนไว้ในแผนกลยุทธ์ของไตรมาสปัจจุบันแล้ว
- P2 - ข้อบกพร่องหรือฟีเจอร์ที่ควรได้รับการแก้ไข แต่เราไม่ได้ดำเนินการในขณะนี้ ปัญหาที่ใช้งานจริงอยู่ในระดับปานกลางใน Bazel เวอร์ชันที่เผยแพร่ซึ่งไม่สะดวกสำหรับผู้ใช้และจำเป็นต้องได้รับการแก้ไขในรุ่นถัดไป และ/หรือมีวิธีแก้ปัญหาง่ายๆ
- P3 - ข้อบกพร่องเล็กๆ น้อยๆ ที่ไม่พึงประสงค์ แก้ไขหรือปรับปรุง ซึ่งมีผลกระทบเพียงเล็กน้อย ไม่ได้ให้ความสำคัญกับแผนงานของ Bazel หรือ ผลงานที่ใกล้จะเปิดตัว แต่เราขอแนะนำให้การสนับสนุนของชุมชน
- P4 - ข้อบกพร่องที่มีลำดับความสำคัญต่ำ หรือคำขอฟีเจอร์ที่ไม่น่าจะปิดได้ นอกจากนี้ยังสามารถเปิดอยู่เพื่อจัดลําดับความสําคัญใหม่ได้หากมีผู้ใช้จำนวนมากขึ้นที่ได้รับผลกระทบ
- กล่องน้ำแข็ง
- ปัญหาที่เราไม่มีเวลาจัดการหรือ ระยะเวลายอมรับการสนับสนุน เราจะปิดปัญหาเหล่านี้เพื่อระบุว่า ไม่มีใครทำงานนั้นอยู่ แต่จะตรวจสอบความถูกต้องของบัญชี กลับมาใช้ใหม่เมื่อมีผู้คนได้รับผลกระทบมากพอ และถ้าเราต้อง ในการจัดการกับทรัพยากรเหล่านั้น และเช่นเคย โปรดแสดงความคิดเห็นหรือรีแอ็กชันต่อปัญหาเหล่านี้ได้แม้ว่าจะปิดไปแล้วก็ตาม
ป้ายกำกับทีม
team-Android
: ปัญหาสำหรับทีม Android- ติดต่อ: ahimesky
team-Bazel
: ปัญหาทั่วไปเกี่ยวกับผลิตภัณฑ์/กลยุทธ์ของ Bazel- ติดต่อ: sventiffe
team-CLI
: UI ของคอนโซล- ติดต่อ: meisterT
team-Configurability
: ปัญหาสำหรับทีมการกำหนดค่า ประกอบด้วย: การกำหนดค่าบิลด์หลักและระบบการเปลี่ยน ไม่รวมการเปลี่ยนแปลงในธงใหม่หรือธงที่มีอยู่- ติดต่อ: gregestren
team-Core
: Skyframe, การค้นหา Bazel, BEP, การแยกวิเคราะห์ตัวเลือก, bazelrc- ติดต่อ: haxorz
team-Documentation
: ปัญหาสำหรับทีมเอกสารประกอบ- ติดต่อ: philomathing
team-ExternalDeps
: การจัดการทรัพยากร Dependency ภายนอก, 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) ปัญหาเกี่ยวกับ API ของ BUILD และ .bzl (ซึ่งแสดงถึงการผสานรวมของ Bazel กับ Starlark) เกิดขึ้นในteam-Build-Language
- ติดต่อ: brandjon
สําหรับปัญหาใหม่ เราเลิกใช้งานป้ายกํากับ category: *
แล้วหันมาใช้ป้ายกํากับของทีมแทน
ดูรายการป้ายกำกับทั้งหมดได้ที่นี่