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

Báo cáo vấn đề Xem nguồn Nightly · 8.0 . 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Đây là hướng dẫn dành cho những người 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 người duy trì trong 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à những người duy trì dự án.

Nhóm cốt lõi của những người đóng góp 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ở. Đó 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 lành mạnh gồm các quy tắc và công cụ.
  • Người chăm sóc trải nghiệm nhà phát triển: Khuyến khích các đóng góp bên ngoài, xem xét các vấn đề và yêu cầu kéo, đồng thời giúp quy trình phát triển của chúng tôi trở nên cởi mở hơn.

Bản phát hành

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

Đọ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/continuous-integration.

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

  1. Người dùng tạo một vấn đề bằng cách sử dụng Mẫu vấn đề và vấn đề đó sẽ được đưa vào nhóm các vấn đề mở 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à bazel-discuss để câu hỏi có thể được nhìn thấy rõ hơn.
    2. Nếu vấn đề thuộc một trong các kho lưu trữ quy tắc thuộc sở hữu của cộng đồng, chẳng hạn như rules_apple, thì thành viên DevEx sẽ chuyển vấn đề này sang kho lưu trữ chính xác.
    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 cung cấp thêm thông tin trước khi tiếp tục. Điều này thường xảy ra khi người dùng không tuân theo Mẫu báo cáo lỗi.
  3. Sau khi xem xét vấn đề, thành viên DevEx sẽ quyết định xem vấn đề có cần được chú ý ngay lập tức hay không. Nếu có, họ sẽ chỉ định nhãn ưu tiên P0 và một chủ sở hữu trong danh sách trưởng nhóm.
  4. Thành viên DevEx chỉ định nhãn untriaged và chính xác một nhãn nhóm để định tuyến.
  5. Thành phầ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, theo loại vấn đề.
  6. Đối với các vấn đề dành riêng cho nền tảng, thành viên DevEx sẽ chỉ định một nhãn platform:, chẳng hạn như platform:apple cho các vấn đề dành riêng cho Mac. Ở giai đoạn này, vấn đề sẽ chuyển vào nhóm các vấn đề mở chưa được phân loại.

Mỗi nhóm phụ Bazel sẽ phân loại tất cả các vấn đề theo nhãn mà họ sở hữu, tốt nhất là hằng tuần. Nhóm phụ sẽ xem xét và đánh giá vấn đề, đồng thờ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 phần 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 yêu cầu lấy dữ liệu

  1. Người dùng tạo một yêu cầu kéo.
  2. Nếu là thành viên của một nhóm Bazel và gửi một yêu cầu thay đổi đối với lĩnh vực của riêng bạn, bạn sẽ chịu 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, một thành viên DevEx sẽ chỉ định một nhãn nhóm và trưởng nhóm kỹ thuật (TL) để định tuyến.
    1. TL có thể chỉ định người khác xem xét PR (không bắt buộc).
  4. Người đánh giá được chỉ định sẽ xem xét nội dung quảng bá và làm việc với tác giả cho đến khi nội dung quảng bá đó được phê duyệt hoặc bị loại bỏ.
  5. Nếu được phê duyệt, người đánh giá sẽ imports (import) (các) thay đổi của PR vào hệ thống kiểm soát phiên bản nội bộ của Google để kiểm thử thêm. Vì Bazel là cùng một hệ thống xây dựng được sử dụng nội bộ tại Google, nên chúng ta cần kiểm thử tất cả các thay đổi PR dựa trên bộ kiểm thử nội bộ. Đây là lý do chúng tôi không trực tiếp hợp nhất các bài đăng tin tức.
  6. Nếu thay đổi đã nhập vượt qua tất cả các bài kiểm thử nội bộ, thay đổi đó sẽ được hợp nhất và xuất trở lại GitHub.
  7. Khi thay đổi được hợp nhất vào nhánh chính, GitHub sẽ tự động đóng yêu cầu thay đổi.

Nhóm của tôi sở hữu một nhãn. Tôi cần làm gì?

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

Vấn đề

  1. Lọc danh sách 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 đề này có thể đã được nhóm phụ DevEx ưu tiên nếu đó là vấn đề P0. Sắp xếp lại mức độ ưu tiên nếu cần.
    2. Mỗi vấn đề cần có đúng một nhãn mức độ ưu tiên. Nếu một vấn đề là P0 hoặc P1, chúng tôi giả định rằng vấn đề đó đang được xử lý tích cực.
  4. Xoá nhãn untriaged.

Xin 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 lấy dữ liệu

  1. Lọc danh sách yêu cầu kéo theo nhãn nhóm của bạn.
  2. Xem xét các yêu cầu kéo đang mở.
    1. Không bắt buộc: Nếu bạn được giao nhiệm vụ xem xét nhưng không phù hợp với nhiệm vụ này, hãy chỉ định lại người đánh giá phù hợp để thực hiện việc xem xét mã.
  3. Làm việc với người tạo yêu cầu kéo để hoàn tất quy trình xem xét mã.
  4. Phê duyệt yêu cầu thay đổi.
  5. Đảm bảo tất cả các bà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 bản gửi trước 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 yêu cầu thay đổi.

Mức độ ưu tiên

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

  • P0 – Chức năng chính bị lỗi khiến bản phát hành Bazel (trừ các bản phát hành đề xuất) không dùng được hoặc dịch vụ bị hỏng ảnh hưởng nghiêm trọng đến quá trình phát triển dự án Bazel. Điều này bao gồm các trường hợp hồi quy được đưa vào bản phát hành mới chặn một số lượng đáng kể người dùng hoặc một thay đổi có lỗi không tương thích không tuân thủ chính sách Thay đổi có 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ó giải pháp thực tế. Thường không yêu cầu hành động ngay lập tức. 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 giải quyết nhưng chúng tôi hiện không xử lý. Vấn đề đang diễn ra ở mức trung bình trong một phiên bản Bazel đã phát hành gây bất tiện cho người dùng và cần được giải quyết trong bản phát hành trong tương lai và/hoặc có giải pháp dễ dàng.
  • P3 – Bạn nên sửa lỗi nhỏ hoặc cải tiến có tác động nhỏ. Không được ưu tiên trong lộ trình 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 các đó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 khó có thể được đóng. Cũng có thể được giữ nguyên để ưu tiên lại nếu có nhiều người dùng bị ảnh hưởng hơn.
  • ice-box
    • Những vấn đề mà chúng tôi hiện không có thời gian xử lý cũng như không có thời gian để chấp nhận các khoản đóng góp. Chúng tôi sẽ đóng các vấn đề này để cho biết rằng không có ai đang xử lý các vấn đề đó, nhưng sẽ tiếp tục theo dõi tính hợp lệ của các vấn đề đó theo thời gian và khôi phục các vấn đề đó 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 đề đó. Như thường lệ, bạn có thể bình luận hoặc thêm biểu tượng cảm xúc vào các vấn đề này ngay cả khi chúng đã đóng.

Nhãn nhóm

  • team-Android: Vấn đề dành cho nhóm Android
  • team-Bazel: Các vấn đề chung về sản phẩm/chiến lược của Bazel
  • team-Build-Language: Các vấn đề về API BUILD, .bzl và Stardoc.
  • team-Configurability: Vấn đề của nhóm Khả năng định cấu hình
  • team-Core: Vấn đề dành cho Nhóm cốt lõi
  • team-Documentation: Vấn đề dành cho 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-Local-Exec: Vấn đề dành cho nhóm Thực thi (Địa phương)
  • team-OSS: Các vấn đề dành cho nhóm OSS Bazel: 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 đề dành cho nhóm Hiệu suất Bazel
  • team-Remote-Exec: Vấn đề của nhóm Thực thi (từ xa)
  • team-Rules-CPP: Các vấn đề về quy tắc 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: Các vấn đề về quy tắc Python gốc
  • team-Rules-Server: Các vấn đề về quy tắc phía máy chủ đi kèm với Bazel
  • 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 nội dung tích hợp, mã hoá ký tự. Không bao gồm: các vấn đề về ngôn ngữ BUILD hoặc .bzl.
  • team-Starlark-interpreter: Các vấn đề về trình thông dịch Starlark (bất kỳ vấn đề nào trong java.net.starlark). Các vấn đề về API BUILD và .bzl (đại diện cho việc tích hợp của Bazel với Starlark) nằm trong team-Build-Language.

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

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