Hướng dẫn bảo dưỡng bazel

Đâ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 phần Đóng góp cho Bazel.

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

  1. Đóng vai trò là bên bảo trì\39; nguồn đáng tin cậy cho quá trình đóng góp của dự án.
  2. Đặt ra kỳ vọng giữa cộng tác viên 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 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.
  • Đội ngũ 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 có kinh nghiệm phát triển: Khuyến khích đóng góp bên ngoài, xem xét các vấn đề và kéo yêu cầu, đồng thời cải thiện quy trình phát triển của chúng tôi để mở rộng hơn.

Bản phát hành

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

Đọc hướng dẫn về cơ sở hạ tầng CI của Bazel’s CI trên kho lưu trữ bazelbuild/liên tục tích hợp.

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

  1. Một người dùng tạo một vấn đề bằng cách sử dụng Mẫu vấn đề và đưa vào danh sách các vấn đề chưa mở chưa được xem xét.
  2. Một thành viên thuộc nhóm xoay vòng Trải nghiệm dành 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 là 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 StackOverflowbazel-Talk để có khả năng hiển thị cao hơn trong câu hỏi.
    2. Nếu vấn đề thuộc về một trong những kho lưu trữ quy tắc do cộng đồng sở hữu, chẳng hạn như rule_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ì thành viên DevEx sẽ chỉ định 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 tuân theo Mẫu vấn đề.
  3. Sau khi xem xét vấn đề, thành viên DevEx sẽ quyết định liệu vấn đề đó có cần ghi chú ngay lập tức hay không. Nếu có, họ sẽ chỉ định nhãn mức độ ưu tiên cho P0 và một chủ sở hữu trong danh sách khách hàng tiềm năng của 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 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, tùy 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 chỉ định một nhãn platform:, chẳng hạn như platform:apple cho các vấn đề dành riêng cho máy Mac. Ở giai đoạn này, vấn đề sẽ được đưa vào nhóm vấn đề chưa được giải quyết.

Mỗi nhóm con Bazel sẽ phân loại tất cả các vấn đề trong 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 đề cũng như cung cấp độ phân giải, 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, vấn đề đó có thể bị đóng.

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 gộp.
  2. Nếu bạn là thành viên của một nhóm Bazel và gửi quan hệ công chúng với khu vực của riêng bạn, bạn sẽ chịu trách nhiệm chỉ định nhãn của nhóm và tìm người đánh giá tốt 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 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. TL có thể tùy ý chỉ định một người khác xem xét PR.
  4. Người đánh giá được chỉ định xem xét PR và làm việc với tác giả cho đến khi tác nhân đó được phê duyệt hoặc bị loại bỏ.
  5. Nếu được phê duyệt, người đánh giá nhập bản cam kết của PR\39 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 thử nghiệm tất cả các cam kết PR so với bộ thử nghiệm nội bộ. Đây là lý do tại sao chúng tôi không hợp nhất trực tiếp PR.
  6. Nếu lượt cam kết đã nhập vượt qua tất cả các lượt thử nghiệm nội bộ, thì lượt cam kết sẽ bị nén và xuất trở lại GitHub.
  7. Khi bản cam kết hợp nhất thành bản 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 con cần phân loại tất cả cá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 các vấn đề theo nhãn của nhóm 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à một P0. Ưu tiên lại nếu cần.
    2. Mỗi vấn đề cần có đúng một nhãn mức độ ưu tiên. Nếu vấn đề là P0 hoặc P1, chúng tôi sẽ xem như vấn đề đó đang được khắc phục.
  4. Xóa nhãn untriaged.

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

Yêu cầu kéo

  1. Lọc danh sách các yêu cầu lấy thông tin theo nhãn của nhóm.
  2. Xem xét các yêu cầ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 với bài đánh giá đó, hãy chỉ định lại người đánh giá thích hợp để 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 việc xem xét mã.
  4. Phê duyệt PR.
  5. Đảm bảo rằng tất cả các thử nghiệm đều vượt qua.
  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 yêu cầu gửi lại nội bộ.
  7. Gửi bản vá nội bộ. Nếu bản vá này gửi và xuất thành công, PR sẽ tự động đóng GitHub.

Thứ tự ưu tiên

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

  • P0 – Chức năng chính bị hỏng khiến bản phát hành Bazel bị loại bỏ (trừ các ứng cử viên phát hành) không sử dụng được hoặc một dịch vụ bị gián đoạn ả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 hồi quy được đưa vào bản phát hành mới chặn một số lượng người dùng đáng kể hoặc thay đổi có thể gây lỗi không tương thích không tuân thủ chính sách Thay đổi đột phá. Không có giải pháp thực tế nào.
  • P1 – Lỗi nghiêm trọng hoặc tính nă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ả sự phát triển của dự án Bazel), nhưng vẫn có một giải pháp thiết thực. Thường thì bạn không cần làm gì ngay. Nhu cầu cao và được lập 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ý. Vấn đề trực tiếp ở mức trung bình trong phiên bản Bazel đã phát hành, gây bất tiện cho một người dùng cần được giải quyết trong một bản phát hành trong tương lai và/hoặc có một giải pháp dễ dàng.
  • P3 – Sửa lỗi hoặc cải thiện một số lỗi nhỏ mong muốn có tác động nhỏ. Không ưu tiên cho các 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 – 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. Cũng có thể tiếp tục mở để ưu tiên ưu tiên lại nếu có thêm người dùng bị ảnh hưởng.
  • ice-box
    • Các vấn đề mà chúng tôi hiện chưa có thời gian xử lý cũng như không có thời gian để chấp nhậ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 đang nỗ lực giải quyết 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 chỉ số này theo thời gian và phục hồi nếu số người bị ảnh hưởng và nếu chúng ta có khả năng xử lý các vấn đề đó. Như thường lệ, vui lòng bình luận hoặc thêm phản ứng vào những vấn đề này ngay cả khi bạn đã đóng cửa.

Nhãn nhóm

  • team-Android: Các vấn đề cho nhóm Android
  • team-Bazel: Các vấn đề chung về chiến lược/sản phẩm của Bazel
  • team-Build-Language: Các vấn đề về API BUILD, .bzl và Stardoc.
  • team-Configurability: Vấn đề đối với nhóm Cấu hình
  • team-Core: Vấn đề đối với nhóm cốt lõi
  • team-Documentation: 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-Local-Exec: Nhóm Vấn đề về quá trình thực thi (Địa phương)
  • team-OSS: Các vấn đề cho 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: Vấn đề đối với nhóm Hiệu suất của Bazel
  • team-Remote-Exec: Nhóm vấn đề về Nhóm thực thi (Điều khiển từ xa)
  • team-Rules-CPP: Vấn đề đối với quy tắc C++, bao gồm cả logic quy tắc gốc của Apple
  • team-Rules-Java: Vấn đề đối với quy tắc Java
  • team-Rules-Python: Vấn đề đối với quy tắc gốc của Python
  • team-Rules-Server: Các vấn đề liên quan đến quy tắc phía máy chủ đi kèm với Bazel
  • team-Starlark-integration: Tích hợp API Bazel + Starlark. 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ã hóa 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 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 (đại diện cho việc tích hợp Bazel với Starlark) sẽ chuyển sang 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à nhãn của nhóm.

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