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

Nightly · 9.1 · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

Đây là hướng dẫn dành cho người duy 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 thay thế.

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

  1. Đóng vai trò là nguồn thông tin đáng tin cậy của người duy trì về quy trình đóng góp cho dự án.
  2. Đặt ra 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 người đóng góp 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.
  • Nhóm Green: 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ụ.
  • Nhóm Developer Experience Gardeners: 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 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 một vấn đề bằ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 chưa được xem xét.
  2. Một thành viên trong nhóm phụ Developer Experience (DevEx) sẽ xem xét vấn đề đó.
    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ó khả năng hiển thị cao hơn về câu hỏi.
    2. Nếu vấn đề thuộc 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 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 vấn đề đó lại 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 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 mức độ ưu tiên P0 priority và một chủ sở hữu từ danh sách 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 đú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 đề 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ẽ được đưa 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 đề trong các 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 một 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 kéo.
  2. Nếu bạn là thành viên của một nhóm Bazel và gửi yêu cầu kéo đối với khu vực của riêng bạn, thì bạn có trách nhiệm chỉ định nhãn nhóm và tìm người xem xét 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) của nhóm để định tuyến.
    1. TL có thể tuỳ ý chỉ định người khác xem xét yêu cầu kéo.
  4. Người xem xét được chỉ định sẽ xem xét yêu cầu kéo và làm việc với tác giả cho đến khi yêu cầu kéo được phê duyệt hoặc bị loại bỏ.
  5. Nếu được phê duyệt, người xem xét sẽ nhập(các) cam kết của yêu cầu kéo 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 là hệ thống xây dựng giống nhau đượ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 cam kết của yêu cầu kéo đối với bộ thử nghiệm nội bộ. Đây là lý do chúng tôi không hợp nhất trực tiếp các yêu cầu kéo.
  6. Nếu cam kết đã nhập vượt qua tất cả các bài kiểm thử 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 vào nhánh chính, GitHub sẽ tự động đóng yêu cầu kéo.

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ả các vấn đề trong các 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 đề có thể đã được nhóm phụ DevEx ưu tiên nếu đó là vấn đề 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 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ý.
  4. Xoá nhãn untriaged.

Xin lưu ý rằng bạn cần phải thuộc tổ chức bazelbuild organization để 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 nhóm.
  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 chỉ định xem xét nhưng không phù hợp với việc đó, hãy chỉ định lại người xem xét thích 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 việc xem xét mã.
  4. Phê duyệt yêu cầu kéo.
  5. Đảm bảo rằng tất cả các bài kiểm thử đều đạt.
  6. Nhập bản vá vào hệ thống quản lý 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á được gửi và xuất thành công, thì GitHub sẽ tự động đóng yêu cầu kéo.

Mức độ ưu tiên

Người duy trì sẽ sử dụng các định nghĩa sau đây về mức độ ưu tiên để phân loại 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 dịch vụ bị ngừng hoạt động gây ả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ác lỗi hồi quy được giới thiệu trong một bản phát hành mới chặn một số lượng lớn người dùng hoặc một thay đổi mang tính đột phá không tương thích không tuân thủ chính sách Thay đổi mang tính đột phá. Không có giải pháp tạm thời thực tế.
  • P1 – Lỗi hoặc tính năng quan 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ả quá trình phát triển dự án Bazel), nhưng có một giải pháp tạm thời thực tế. Thông thường, bạn không cần phải 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ý. Sự cố trực tuyến ở mức độ vừa phải trong phiên bản Bazel đã 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 trong tương lai và/hoặc có một giải pháp tạm thời dễ dàng.
  • P3 – Bản sửa lỗi nhỏ hoặc cải tiến đáng mong muố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 hoặc yêu cầu về tính năng có mức độ ưu tiên thấp và khó có khả năng được đóng. Bạn cũng có thể giữ trạng thái mở để có khả năng ưu tiên lại nếu có nhiều người dùng bị ảnh hưởng hơn.
  • ice-box
    • Các 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 đó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ó nguồn lực để xử lý các vấn đề đó. Như mọi khi, bạn có thể thoải mái bình luận hoặc thêm phản ứng vào các vấn đề này ngay cả khi đã đóng.

Nhãn nhóm

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

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