Bazel 유지관리 담당자를 위한 가이드

<ph type="x-smartling-placeholder"></ph> 문제 신고 소스 보기 1박 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Bazel 오픈소스 프로젝트의 유지관리자를 위한 가이드입니다.

Bazel에 기여하고 싶다면 Bazel을 사용하세요.

이 페이지의 목표는 다음과 같습니다.

  1. 유지관리 담당자 역할 수행 프로젝트 기여에 대한 정보 소스 프로세스입니다
  2. 커뮤니티 참여자와 프로젝트 간의 기대치 설정 관리 담당자입니다.

Bazel의 핵심 참여자 그룹은 오픈소스 프로젝트의 여러 측면을 관리할 수 있습니다. 이는 다음과 같습니다.

  • 출시 프로세스: Bazel의 출시 프로세스를 관리합니다.
  • 그린팀: 건강한 규칙 및 도구 생태계 조성
  • 개발자 경험 정원사: 외부 참여 장려 및 검토 개발 워크플로우를 더욱 개방적으로 만드는 데 도움이 됩니다.

출시

지속적 통합

다음 페이지에서 Bazel의 CI 인프라에 대한 그린 팀 가이드를 읽어보세요. bazelbuild/continuous-integration 저장소

문제의 수명 주기

  1. 사용자가 문제 템플릿 해당 광고 항목은 검토되지 않은 문제가 있을 수 있습니다.
  2. 개발자 환경 (DevEx) 하위 팀 순환 멤버는 있습니다.
    1. 문제가 버그 또는 기능 요청이 아닌 경우 DevEx 회원은 일반적으로 문제를 종료하고 사용자를 StackOverflow 및 bazel-discuss 질문에 대한 가시성이 높아진다는 것입니다
    2. 문제가 커뮤니티(예: rules_apple)를 게시하고, DevEx 회원이 이 문제를 전달합니다. 올바른 저장소로 푸시합니다
    3. 문제가 모호하거나 누락된 정보가 있는 경우 DevEx 회원이 다음을 수행합니다. 사용자에게 문제를 다시 할당하여 추가 정보를 계속됩니다. 이 문제는 일반적으로 사용자가 올바른 옵션을 선택하지 않는 경우 발생합니다. 문제 템플릿 {: .external} 또는 불완전한 정보를 제공합니다.
  3. 문제를 검토한 후 DevEx 회원은 문제에 즉시 주의를 끌 수 있습니다. 있는 경우 P0 우선순위 라벨 및 팀 리드 목록의 소유자
  4. DevEx 구성원이 untriaged 라벨과 정확히 1개의 팀을 할당합니다. 라벨을 지정합니다.
  5. 또한 DevEx 구성원은 정확히 하나의 type: 라벨(예: type: bug)을 할당합니다. 또는 문제 유형에 따라 type: feature request를 선택합니다.
  6. 플랫폼별 문제의 경우 DevEx 회원은 하나의 platform: 라벨을 할당합니다. 예를 들어 Mac 관련 문제의 경우 platform:apple입니다.
  7. 문제의 우선순위가 낮으며 새로운 커뮤니티에서 처리할 수 있는 문제인지 여부 기여자인 경우 DevEx 구성원이 good first issue 라벨을 할당합니다. 이 단계에서 문제는 미해결 미해결 풀에 진입합니다. 문제에 대해 자세히 알아보세요.

각 Bazel 하위팀은 자신이 소유한 라벨에 따라 모든 문제를 분류합니다. 가급적이면 . 하위팀에서 문제를 검토 및 평가한 후 할 수 있습니다. 팀 라벨의 소유자인 경우 이 섹션을 참조하세요. 에서 자세한 내용을 확인하세요.

문제가 해결되면 종료할 수 있습니다.

pull 요청의 수명 주기

  1. 사용자가 pull 요청을 만듭니다.
  2. 여러분이 Bazel 팀의 일원이고 자신의 지역에 대해 PR을 보내는 경우, 팀 라벨을 할당하고 최적의 모델을 리뷰어입니다.
  3. 그렇지 않으면 일일 분류 중에 DevEx 구성원이 팀 라벨 및 라우트를 위한 팀의 기술 리드 (TL)가 필요합니다.
    1. TL은 PR을 검토할 다른 담당자를 선택적으로 지정할 수 있습니다.
  4. 지정된 검토자는 PR을 검토하고 표시됩니다.
  5. 승인된 경우 검토자는 PR의 커밋을 Google 추가 테스트를 위한 내부 버전 제어 시스템 Bazel은 모든 PR 커밋을 내부 테스트 도구 모음입니다. 이러한 이유로 Google에서는 PR을 직접 병합하지 않습니다.
  6. 가져온 커밋이 모든 내부 테스트를 통과하면 커밋이 스쿼시됩니다. GitHub로 다시 내보냅니다
  7. 커밋이 마스터에 병합되면 GitHub가 자동으로 PR을 닫습니다.

팀에서 음반사를 소유하고 있습니다. 어떻게 해야 하나요?

하위팀은 자신이 소유한 라벨의 모든 문제를 분류해야 합니다. 1주일에 한 번 정도

문제

  1. 팀 라벨 및 untriaged 라벨로 문제 목록을 필터링합니다.
  2. 문제를 검토합니다.
  3. 우선순위 수준을 식별하고 라벨을 지정합니다.
    1. 다음과 같은 경우 DevEx 하위팀에서 이미 이 문제의 우선순위를 지정했을 수 있습니다. P0 필요한 경우 우선순위를 다시 지정합니다.
    2. 각 문제에 정확히 1개의 우선순위 라벨이 있어야 합니다. 만약 P0 또는 P1입니다.
  4. untriaged 라벨을 삭제합니다.

bazelbuild에 있어야 함 조직에게 권한을 부여해야 라벨을 추가하거나 삭제할 수 있습니다.

pull 요청

  1. 팀 라벨로 pull 요청 목록을 필터링합니다.
  2. 진행 중인 pull 요청을 검토합니다.
    1. 선택사항: 검토를 받기 위해 할당되었지만 적합하지 않은 경우 적절한 검토자를 다시 할당하여 코드 검토를 수행합니다.
  3. pull 요청 생성자와 협력하여 코드 검토를 완료합니다.
  4. PR을 승인합니다.
  5. 모든 테스트를 통과하는지 확인합니다.
  6. 패치를 내부 버전 제어 시스템으로 가져오고 내부 있습니다.
  7. 내부 패치를 제출합니다. 패치가 제출되고 성공적으로 내보내면 GitHub에서 PR을 자동으로 종료합니다.

우선순위

다음과 같은 우선순위 정의는 유지관리자가 분류하는 데 사용됩니다. 있습니다

  • P0 - 심각한 손상 Bazel 출시 (릴리스 후보 제외)가 서비스 중단, Bazel 개발에 심각한 영향을 미치는 서비스 중단 살펴보겠습니다 여기에는 새 출시 버전에 도입된 회귀로 인해 호환되지 않거나 제대로 작동하지 않는 브레이킹 체인지가 변경사항 정책 실질적인 해결 방법이 없습니다.
  • P1 - 심각한 결함 또는 향후 출시에서 해결되어야 할 기능 또는 Bazel 프로젝트 개발을 포함하여 많은 사용자에게 영향을 미치지만 실용적인 해결 방법이 있습니다. 일반적으로 즉각적인 조치가 필요하지 않습니다. 포함 현재 분기의 로드맵에 계획되어 있습니다
  • P2 - 결함 또는 기능 현재 이 문제를 해결하기 위해 노력하고 있지 않습니다. 게시 문제 보통 Bazel 버전에서 제공하는 버전으로, Bazel 버전에서 해결 방법이 있거나 간단한 해결 방법이 있습니다.
  • P3 - 바람직한 경미한 버그 수정하거나 개선할 수 있습니다 Bazel 로드맵에서 우선순위가 없거나 하지만 커뮤니티 제공을 권장합니다.
  • P4 - 우선순위가 낮은 결함 요청한다고 가정해 보겠습니다 또한 더 많은 사용자가 영향을 받는 경우 우선순위를 다시 지정할 수 있습니다.
  • 아이스박스
    • 현재 처리할 시간이 없거나 기부를 수락해야 합니다 이러한 문제는 Google에서 종료하여 아무도 작업을 하지 않지만 충분한 인력이 영향을 받았거나 자원을 줄 수 있어야 합니다 언제든지 댓글을 달거나 반응을 추가할 수 있습니다. 이러한 문제에 액세스할 수 있습니다

팀 라벨

새로운 문제의 경우 팀을 위해 category: * 라벨을 지원 중단했습니다. 라벨을 지정합니다

여기에서 전체 라벨 목록을 확인하세요.