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

Báo cáo vấn đề Xem nguồn Nightly/3}

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

Nếu bạn đang 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 đơn vị bảo trì cho quy trình đóng góp của dự án.
  2. Đặt kỳ vọng giữa những người đóng góp trong cộng đồng và người duy trì dự án.

Nhóm cộng tác viên cốt lõi của Bazel có các nhóm phụ chuyên 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 làm vườn trải nghiệm của nhà phát triển: Khuyến khích sự đóng góp từ bên ngoài, đánh giá các vấn đề và lấy 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 cởi 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 Green 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 vấn đề bằng cách chọn một trong các 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 tham gia chương trình xoay vòng nhóm phụ Trải nghiệm 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 để tăng mức độ hiển thị của câu hỏi.
    2. Nếu vấn đề thuộc một trong những 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 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. Điều 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 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 P0 P0 và một chủ sở hữu trong danh sách các trưởng nhóm.
  4. Thành viên DevEx sẽ gán nhãn untriaged và chính xác một nhãn nhóm để định tuyến.
  5. Thành viên DevEx cũng chỉ định đúng 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 sẽ gán một nhãn platform:, chẳng hạn như platform:apple cho các vấn đề dành riêng cho Mac.
  7. Nếu vấn đề có mức độ ưu tiên thấp và một cộng tác viên mới trong cộng đồng có thể 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 chưa được phát hiện.

Mỗi nhóm phụ của Bazel sẽ phân loại tất cả vấn đề theo nhãn họ sở hữu, tốt nhất là theo 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, chúng tôi 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 nhóm Bazel và gửi một quảng cáo PR về khu vực của riêng mình, bạn có trách nhiệm chỉ định nhãn cho nhóm của mình 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 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. Bản tóm tắt có thể chỉ định một người khác phụ trách đánh giá PR (không bắt buộc).
  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 PR được phê duyệt hoặc bị loại bỏ.
  5. Nếu được phê duyệt, nhân viên đánh giá sẽ nhập(các) cam kết của PR vào hệ thống quản lý phiên bản nội bộ của Google để kiểm thử thêm. Vì Bazel cũng là 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ả cam kết PR dựa trên bộ kiểm thử nội bộ. Đây là lý do chúng tôi không hợp nhất các hoạt động PR một cách trực tiếp.
  6. Nếu xác nhận (commit) đã nhập vượt qua mọi kiểm thử nội bộ, thì xác nhận đó sẽ được thu gọn và xuất trở lại GitHub.
  7. Khi lệnh xác nhận hợp nhất thành kênh chính, GitHub sẽ tự động đóng PR.

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 họ sở hữu, tốt nhất là theo tuần.

Vấn đề

  1. Lọc danh sách vấn đề theo nhãn nhóm và nhãn untriaged.
  2. Kiểm tra vấn đề.
  3. Xác định mức độ ưu tiên và gán nhãn.
    1. Vấn đề này có thể đã được nhóm phụ DevEx ưu tiên nếu đó là P0. Hãy ưu tiên lại 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 sẽ giả định rằng vấn đề đó đang được tích cực xử lý.
  4. Xoá nhãn untriaged.

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

Yêu cầu kéo

  1. Lọc danh sách các yêu cầu lấy dữ liệu theo nhãn của nhóm.
  2. Xem xét các yêu cầu lấy dữ liệu chưa xử lý.
    1. Không bắt buộc: Nếu bạn được chỉ định xem xét nhưng mã đó không phù hợp, hãy chỉ định lại người đánh giá thích hợp để thực hiện quy trình xem xét mã.
  3. Hãy làm việc với người tạo yêu cầu lấy dữ liệu để hoàn tất quá trình xem xét mã.
  4. Phê duyệt PR.
  5. Đảm bảo rằng tất cả các bài kiểm thử đều thành công.
  6. Nhập bản vá vào hệ thống quản lý phiên bản nội bộ và chạy tính năng 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, thì 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 đơn vị bảo trì sử dụng để phân loại các vấn đề.

  • P0 – Chức năng bị hỏng nghiêm trọng khiến bản phát hành Bazel (trừ các ứng viên phát hành) không sử dụng được hoặc một dịch vụ bị lỗi gây ảnh hưởng nghiêm trọng đến quá trình phát triển dự án Bazel. Bao gồm cả các lượt hồi quy được đưa ra 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 một 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 vẫn có một giải pháp thiết thực. Thường không yêu cầu hành động ngay lập tứ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 khắc phục nhưng hiện chúng tôi chưa nghiên cứu. Mức độ trung bình của vấn đề đang diễn ra trong phiên bản Bazel được phát hành, gây bất tiện cho người dùng cần được 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 – Tính năng nâng cao hoặc bản sửa 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 hay bất kỳ bản phát hành sắp tới nào, nhưng chúng tôi khuyến khích cộng đồng đóng góp.
  • P4 – Lỗi hoặc yêu cầu về tính năng có mức độ ưu tiên thấp không có khả năng bị đóng. Cũng có thể được để mở nếu có thể có mứ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 xử lý và thời gian nhận 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ý chúng, 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 chúng nếu có đủ số người bị ảnh hưởng và nếu chúng tôi có nguồn lực để xử lý chúng. Như thường lệ, bạn có thể thoải mái nhận xét hoặc thêm phản ứng về các vấn đề này ngay cả khi đã đóng trang.

Nhãn của nhóm

  • team-Android: Các vấn đề đối với 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 Console
  • team-Configurability: Các vấn đề mà nhóm Khả năng định cấu hình gặp phải. 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 hiện có
  • team-Core: Skyframe, truy vấn bazel, BEP, phân tích cú pháp các tuỳ chọn, bazelrc
    • Thông tin liên hệ: haxorz
  • team-Documentation: Các vấn đề về 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à quá trình xử lý macro: nhãn, gói(), chế độ hiển thị, khối cầu
  • team-Local-Exec: Các vấn đề liên quan đến Nhóm thực thi (Cục bộ)
  • team-OSS: Các vấn đề mà nhóm Bazel OSS gặp phải: cài đặt, quy trình phát hành, đóng gói của Bazel, trang web, cơ sở hạ tầng tài liệu
  • team-Performance: Các vấn đề về nhóm Hiệu suất Bazel
  • team-Remote-Exec: Vấn đề liên quan đến 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 chạy, thao tác, cấu phần phần mềm
    • Thông tin liên hệ: comius
  • team-Rules-CPP / team-Rules-ObjC: Các vấn đề đối với quy tắc C++/GOAL-C, bao gồm cả logic quy tắc gốc của Apple
  • team-Rules-Java: Các vấn đề đối với các quy tắc Java
  • team-Rules-Python: Các vấn đề đối với các quy tắc Python gốc
  • team-Rules-Server: Các vấn đề đối với quy tắc phía máy chủ đi kèm với Bazel
    • Thông tin liên hệ: comius
  • team-Starlark-Integration: Tích hợp Bazel không phải API Bazel + Starlark. Bao gồm: cách Bazel kích hoạt trình phiên dịch Starlark, Stardoc, chèn nội dung tích hợp, mã hoá ký tự. Không bao gồm: Vấn đề về ngôn ngữ BUILD hoặc .bzl.
  • team-Starlark-Interpreter: Các vấn đề đối với trình phiên dịch Starlark (mọi vấn đề trong java.net.starlark). Các vấn đề về BUILD và .bzl API (thể hiện việc tích hợp của Bazel với Starlark) sẽ xảy ra trong team-Build-Language.

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

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