BazelCon 2022는 11월 16~17일에 뉴욕과 온라인에서 개최됩니다.
지금 등록하기

Bazel 유지관리자 가이드

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

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

Bazel에 기여하려면 Bazel에 참여를 참조하세요.

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

  1. 프로젝트 참여 프로세스의 신뢰할 수 있는 소스 역할을 합니다.
  2. 커뮤니티 참여자와 프로젝트 관리자 간에 기대치를 설정합니다.

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

  • 출시 프로세스: Bazel의 출시 프로세스를 관리합니다.
  • 그린팀: 규칙 및 도구의 생태계를 건전하게 성장시킵니다.
  • 개발자 환경 정원사: 외부 참여를 독려하고, 문제를 검토하고, 요청을 보내며, Google의 개발 워크플로를 더욱 개방적으로 만듭니다.

출시

지속적 통합

bazelbuild/지속적 통합 저장소의 Bazel CI 인프라에 대한 그린팀 가이드를 읽어보세요.

문제의 수명 주기

  1. 사용자가 Issue Template을 사용하여 문제를 만들고 검토되지 않은 미해결 문제의 풀에 들어갑니다.
  2. 개발자 환경 (DevEx) 하위 팀 순환의 구성원이 문제를 검토합니다.
    1. 버그가 아닌 기능 요청이 아닌 경우 DevEx 구성원은 일반적으로 문제를 닫고 사용자를 StackOverflowbazel-discuss로 리디렉션하여 질문을 더 명확하게 볼 수 있습니다.
    2. 문제가 rules_apple과 같이 커뮤니티에서 소유한 규칙 저장소 중 하나에 속하는 경우 DevEx 회원은 이 문제를 올바른 저장소로 전송합니다.
    3. 문제가 모호하거나 정보가 누락된 경우 DevEx 회원은 문제를 사용자에게 다시 할당하여 계속 진행하기 전에 추가 정보를 요청합니다. 이 문제는 일반적으로 사용자가 문제 템플릿을 따르지 않는 경우에 발생합니다.
  3. 문제를 검토한 후 DevEx 회원이 문제에 즉각적인 조치가 필요한지 판단합니다. 이 경우 P0 우선순위 라벨과 팀 리드 목록의 소유자가 할당됩니다.
  4. DevEx 멤버는 라우팅용 untriaged 라벨과 정확히 하나의 팀 라벨을 할당합니다.
  5. DevEx 구성원은 문제의 유형에 따라 정확히 하나의 type: 라벨(예: type: bug 또는 type: feature request)을 할당합니다.
  6. 플랫폼별 문제의 경우 DevEx 멤버가 Mac 관련 문제의 경우 platform:apple과 같은 platform: 라벨을 하나씩 할당합니다. 이 단계에서 문제가 미해결된 미해결 문제의 풀에 들어갑니다.

각 Bazel 서브팀은 소유한 라벨을 기준으로 모든 문제를 선별적으로 분류합니다. 하위팀에서 문제를 검토 및 평가하고 가능한 경우 해결 방법을 제공합니다. 팀 라벨 소유자인 경우 자세한 내용은 이 섹션을 참고하세요.

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

Pull 요청의 수명 주기

  1. 사용자가 pull 요청을 만듭니다.
  2. Bazel팀의 구성원이며 자체 지역에 PR을 보내는 경우 팀 라벨을 할당하고 최적의 뷰어를 찾아야 합니다.
  3. 그렇지 않으면 일일 분류를 진행하는 동안 DevEx 멤버가 팀 라벨 한 개와 라우팅을 위한 팀의 기술 리드 (TL)를 할당합니다.
    1. 팀 리더는 PR을 검토하기 위해 다른 사람을 선택적으로 배정할 수 있습니다.
  4. 할당된 검토자가 PR을 검토하고 승인되거나 삭제될 때까지 작성자와 협력합니다.
  5. 승인되면 검토자가 추가 테스트를 위해 PR 및 PR의 내부 버전 제어 시스템으로 커밋을 가져옵니다. Bazel은 Google 내부에서 사용되는 빌드 시스템과 동일하므로 모든 PR 커밋을 내부 테스트 모음을 대상으로 테스트해야 합니다. 이 때문에 PR을 직접 병합하지 않습니다.
  6. 가져온 커밋이 모든 내부 테스트를 통과하면 커밋이 스쿼시되거나 다시 GitHub로 내보내집니다.
  7. 커밋이 마스터에 병합되면 GitHub가 자동으로 PR을 닫습니다.

저희 팀에서 라벨을 소유하고 있습니다. 어떻게 해야 하나요?

하위팀은 소유한 라벨의 모든 문제를 매주 분류해야 합니다.

Issues

  1. 팀 라벨 untriaged 라벨로 문제 목록을 필터링합니다.
  2. 문제를 검토합니다.
  3. 우선순위 수준을 식별하고 라벨을 할당합니다.
    1. P0이 DevEx 하위 팀에 의해 이미 우선순위가 지정되었을 수 있습니다. 필요한 경우 우선순위를 다시 지정합니다.
    2. 각 문제에는 정확히 하나의 우선순위 라벨이 있어야 합니다. 문제가 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 버전을 보통 상태로 유지합니다.
  • P3 - 사소한 영향을 미치는 것으로 예상되는 사소한 버그 수정 또는 개선사항입니다. Bazel 로드맵 또는 임박한 출시에 우선순위를 두지 않지만 커뮤니티 참여를 권장합니다.
  • P4 - 우선순위가 낮은 결함 또는 기능 요청이 종료될 가능성은 낮음 더 많은 사용자가 영향을 받는 경우 우선순위를 변경할 수 있도록 열린 상태로 유지할 수도 있습니다.
  • 아이스 박스
    • 현재 처리할 문제가 없고 기여를 수락할 시간이 없는 문제 이러한 문제를 해결하여 아무도 작업하고 있지 않음을 나타내지만, 시간이 지남에 따라 지속적으로 유효성을 모니터링하고 충분한 영향을 받는 사람과 이러한 리소스를 처리하기 위한 리소스가 있는 경우 문제를 해결할 예정입니다. 언제나 그렇듯이 닫힌 상태에서도 자유롭게 이 문제에 댓글을 달거나 반응을 추가하세요.

팀 라벨

새로운 문제에서는 category: * 라벨을 지원 중단하고 팀 라벨로 대체했습니다.

라벨의 전체 목록은 여기를 참고하세요.