Hướng dẫn cho nhà bảo trì sản phẩm Bazel

Báo cáo sự cố Xem nguồn

Đây là hướng dẫn cho những nhà bảo trì dự án nguồn mở Bazel.

Nếu bạn muốn đóng góp cho Bazel, vui lòng đọc bài viết Đóng góp cho Bazel.

Mục tiêu của trang này là:

  1. Đóng vai trò là nguồn đáng tin cậy của nhà bảo trì cho quy trình đóng góp của dự án.
  2. Đặt ra kỳ vọng giữa những người đóng góp cho cộng đồng và người duy trì dự án.

Nhóm người đóng góp nòng cốt của Bazel có các nhóm phụ chuyên trách để quản lý các khía cạnh của dự án nguồn mở này. Đó là:

  • Quy trình phát hành: Quản lý quy trình phát hành của Bazel.
  • Nhóm xanh: Phát triển một hệ sinh thái các quy tắc và công cụ lành mạnh.
  • Người làm vườn trải nghiệm dành cho nhà phát triển: Khuyến khích nội dung đóng góp của bên ngoài, xem xét các vấn đề và thu thập yêu cầu, đồng thời làm cho quy trình phát triển của chúng tôi trở nên rộng mở hơn.

Bản phát hành

Tích hợp liên tục

Hãy đọc hướng dẫn của Nhóm Xanh về cơ sở hạ tầng CI của Bazel trên kho lưu trữ bazelbuild/tích hợp liên tục.

Vòng đời của một vấn đề

  1. Người dùng tạo ra một vấn đề bằng cách chọn một trong các mẫu vấn đề và vấn đề đó sẽ được chuyển vào nhóm các vấn đề chưa được xem xét.
  2. Một thành viên trong nhóm phụ trách Trải nghiệm cho nhà phát triển (DevEx) sẽ xem xét vấn đề này.
    1. Nếu vấn đề không phải là lỗi hoặc yêu cầu về tính năng, thì thành viên DevEx thường sẽ đóng vấn đề và chuyển hướng người dùng đến StackOverflow và thảo luận để nắm rõ hơn về câu hỏi.
    2. Nếu vấn đề thuộc về một trong các kho lưu trữ quy tắc do cộng đồng sở hữu, chẳng hạn như rules_apple, thì thành viên của DevEx sẽ chuyển vấn đề này sang đúng kho lưu trữ.
    3. Nếu vấn đề không rõ ràng hoặc thiếu thông tin, thành viên DevEx sẽ giao lại vấn đề cho người dùng để yêu cầu thêm thông tin trước khi tiếp tục. Vấn đề này thường xảy ra khi người dùng không chọn đúng mẫu vấn đề {: .external} hoặc cung cấp thông tin không đầy đủ.
  3. Sau khi xem xét vấn đề, thành viên của DevEx sẽ quyết định xem có cần chú ý ngay lập tức hay không. Nếu có, họ sẽ chỉ định nhãn mức độ ưu tiên P0 và chủ sở hữu từ danh sách các trưởng nhóm.
  4. Thành viên DevEx chỉ định nhãn untriaged và đúng một nhãn nhóm để định tuyến.
  5. Thành viên DevEx cũng chỉ định chính xác một nhãn type:, chẳng hạn như type: bug hoặc type: feature request, tuỳ theo loại vấn đề.
  6. Đối với các vấn đề riêng của nền tảng, thành viên DevEx chỉ định một nhãn platform:, chẳng hạn như platform:apple cho các vấn đề riêng của Mac.
  7. Nếu vấn đề có mức độ ưu tiên thấp và có thể được một người đóng góp cộng đồng mới giải quyết, thì thành viên DevEx sẽ chỉ định nhãn good first issue. Ở giai đoạn này, vấn đề sẽ chuyển vào nhóm các vấn đề chưa giải quyết.

Mỗi nhóm phụ của Bazel sẽ phân loại mọi vấn đề theo các nhãn mà họ sở hữu, tốt nhất là phân loại theo tuần. Nhóm phụ sẽ xem xét và đánh giá vấn đề rồi đưa ra giải pháp nếu có thể. Nếu bạn là chủ sở hữu của một nhãn nhóm, hãy xem mục này để biết thêm thông tin.

Khi vấn đề đã được giải quyết, bạn có thể đóng vấn đề đó.

Vòng đời của một yêu cầu kéo

  1. Người dùng tạo một yêu cầu lấy dữ liệu.
  2. Nếu là thành viên của một nhóm Bazel và gửi quảng cáo cho khu vực của mình, bạn có trách nhiệm chỉ định nhãn nhóm và tìm người đánh giá phù hợp nhất.
  3. Nếu không, trong quá trình phân loại hằng ngày, thành viên của DevEx sẽ chỉ định một nhãn nhóm và trưởng nhóm kỹ thuật (TL) của nhóm để định tuyến.
    1. Người phụ trách quan hệ công chúng có thể tuỳ ý chỉ định một người khác xem xét PR.
  4. Người đánh giá được chỉ định sẽ xem xét PR và làm việc với tác giả cho đến khi bài đánh giá được phê duyệt hoặc bỏ qua.
  5. Nếu được phê duyệt, người đánh giá nhập(các) cam kết của quan hệ công chúng vào hệ thống kiểm soát phiên bản nội bộ của Google để thử nghiệm thêm. Vì Bazel cũng là hệ thống xây dựng được sử dụng nội bộ tại Google, nên chúng tôi cần kiểm thử tất cả các thay đổi về quan hệ công chúng với bộ kiểm thử nội bộ. Đây là lý do chúng tôi không hợp nhất trực tiếp các mối quan hệ công chúng với nhau.
  6. Nếu cam kết đã nhập vượt qua tất cả các thử nghiệm nội bộ, thì cam kết đó sẽ được nén và xuất trở lại GitHub.
  7. Khi cam kết hợp nhất thành chính, GitHub sẽ tự động đóng PR.

Nhóm của tôi có một hãng thu âm. Tôi cần làm gì?

Các nhóm phụ cần phân loại tất cả các vấn đề trong nhãn họ sở hữu, tốt nhất là phân loại theo tuần.

Vấn đề

  1. Lọc danh sách các vấn đề theo nhãn nhóm và nhãn untriaged.
  2. Xem xét vấn đề.
  3. Xác định mức độ ưu tiên và chỉ định nhãn.
    1. Vấn đề có thể đã được nhóm phụ DevEx ưu tiên nếu đó là P0. Đặt lại mức độ ưu tiên nếu cần.
    2. Mỗi vấn đề cần có đúng một nhãn ưu tiên. Nếu một vấn đề là P0 hoặc P1, chúng tôi cho rằng vấn đề đó đang được xử lý.
  4. Xoá nhãn untriaged.

Lưu ý rằng bạn cần phải thuộc tổ chức bazelbuild để có thể thêm hoặc xoá nhãn.

Yêu cầu kéo

  1. Lọc danh sách yêu cầu kéo theo nhãn của nhóm.
  2. Xem xét yêu cầu lấy dữ liệu mở.
    1. Không bắt buộc: Nếu bạn được chỉ định xem xét nhưng không phù hợp, hãy chỉ định lại người đánh giá thích hợp để tiến hành xem xét mã.
  3. Hãy làm việc với trình tạo yêu cầu lấy dữ liệu để hoàn tất quy trình xem xét mã.
  4. Phê duyệt quan hệ công chúng.
  5. Đảm bảo mọi kiểm thử đều đạt.
  6. Nhập bản vá vào hệ thống kiểm soát phiên bản nội bộ và chạy các lần gửi lại nội bộ.
  7. Gửi bản vá nội bộ. Nếu bản vá gửi và xuất thành công, GitHub sẽ tự động đóng PR.

Mức độ ưu tiên

Các định nghĩa sau đây về mức độ ưu tiên sẽ được các trình bảo trì sử dụng để phân loại các vấn đề.

  • P0 – Chức năng bị hỏng chính khiến bản phát hành Bazel (trừ các bản phát hành đề xuất) không sử dụng được hoặc dịch vụ bị ngừng hoạt động ảnh hưởng nghiêm trọng đến sự phát triển của dự án Bazel. Điều này bao gồm các lần hồi quy trong một bản phát hành mới chặn một số lượng người dùng đáng kể hoặc một thay đổi có thể gây lỗi không tương thích và không tuân thủ Chính sách về thay đổi có thể gây lỗi. Không có giải pháp thực tế nào.
  • P1 – Lỗi hoặc tính năng nghiêm trọng cần được giải quyết trong bản phát hành tiếp theo, hoặc vấn đề nghiêm trọng ảnh hưởng đến nhiều người dùng (bao gồm cả việc phát triển dự án Bazel), nhưng có một giải pháp thiết thực. Thường thì bạn không cần phải làm gì ngay. Đang có nhu cầu cao và được lên kế hoạch trong lộ trình của quý hiện tại.
  • P2 – Lỗi hoặc tính năng cần được xử lý nhưng chúng tôi hiện chưa xử lý. Kiểm duyệt sự cố trực tiếp trong một phiên bản Bazel đã phát hành. Vấn đề này gây bất tiện cho người dùng cần phải giải quyết trong bản phát hành sau này và/hoặc có một giải pháp đơn giản.
  • P3 – Sửa hoặc nâng cao các lỗi nhỏ mà bạn mong muốn có tác động nhỏ. Không được ưu tiên trong lộ trình của Bazel hoặc bất kỳ bản phát hành sắp tới nào. Tuy nhiên, chúng tôi khuyến khích đóng góp của cộng đồng.
  • P4 – Lỗi có mức độ ưu tiên thấp hoặc yêu cầu về tính năng ít có khả năng bị đóng. Bạn cũng có thể duy trì trạng thái mở để có khả năng được ưu tiên lại nếu có nhiều người dùng bị ảnh hưởng hơn.
  • hộp đá
    • Các vấn đề mà chúng tôi hiện không có thời gian giải quyết cũng như không có thời gian để chấp nhận khoản đóng góp. Chúng tôi sẽ đóng những vấn đề này để cho biết rằng không có ai xử lý các vấn đề này, nhưng sẽ tiếp tục theo dõi tính hợp lệ của các vấn đề này theo thời gian và khôi phục các vấn đề này nếu có đủ người bị ảnh hưởng và nếu chúng tôi có tài nguyên để xử lý các vấn đề này. Như thường lệ, bạn có thể nhận xét hoặc thêm biểu tượng cảm xúc cho những vấn đề này ngay cả khi đã đóng.

Nhãn đội

  • team-Android: Các vấn đề về nhóm Android
  • team-Bazel: Các vấn đề chung về sản phẩm/chiến lược của Bazel
  • team-CLI: Giao diện người dùng bảng điều khiển
  • team-Configurability: Các vấn đề liên quan đến nhóm Khả năng định cấu hình. Bao gồm: Cấu hình bản dựng cốt lõi và hệ thống chuyển đổi. Không bao gồm: Các thay đổi đối với cờ mới hoặc cờ hiện tại
  • team-Core: Skyframe, bazel query, BEP, phân tích cú pháp tuỳ chọn, bazelrc
    • Thông tin liên hệ: haxorz
  • team-Documentation: Các vấn đề đối với nhóm Tài liệu
  • team-ExternalDeps: Xử lý phần phụ thuộc bên ngoài, Bzlmod, kho lưu trữ từ xa, tệp WORKSPACE
  • team-Loading-API: XÂY DỰNG tệp và xử lý macro: nhãn, gói(), chế độ hiển thị, glob
  • team-Local-Exec: Nhóm Các vấn đề đối với việc thực thi (cục bộ)
  • team-OSS: Các vấn đề liên quan đến nhóm Bazel OSS: cài đặt, quy trình phát hành, đóng gói Bazel, trang web, cơ sở hạ tầng tài liệu
  • team-Performance: Các vấn đề liên quan đến nhóm Hiệu suất của Bazel
  • team-Remote-Exec: Các vấn đề đối với nhóm Thực thi (Từ xa)
  • team-Rules-API: API để viết các quy tắc/khía cạnh: trình cung cấp, tệp runfile, thao tác, cấu phần phần mềm
    • Thông tin liên hệ: comius
  • team-Rules-CPP / team-Rules-ObjC: Vấn đề về các quy tắc C++/Objective-C, bao gồm cả logic quy tắc gốc của Apple
  • team-Rules-Java: Vấn đề về quy tắc Java
  • team-Rules-Python: Vấn đề về quy tắc Python gốc
  • team-Rules-Server: Vấn đề liên quan đến quy tắc phía máy chủ có trong Bazel
    • Thông tin liên hệ: comius
  • team-Starlark-Integration: Tích hợp Bazel + Starlark không phải API. Bao gồm: cách Bazel kích hoạt trình thông dịch Starlark, Stardoc, chèn sẵn, mã hoá ký tự. Không bao gồm: Các vấn đề về ngôn ngữ BUILD hoặc .bzl.
  • team-Starlark-Interpreter: Vấn đề về trình thông dịch Starlark (bất kỳ nội dung nào trong java.net.starlark). Các vấn đề về BUILD và .bzl API (thể hiện việc Bazel tích hợp với Starlark) trong team-Build-Language.

Đối với những vấn đề mới, chúng tôi đã ngừng sử dụng nhãn category: * và thay bằng nhãn nhóm.

Xem danh sách đầy đủ các nhãn tại đây.