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

문제 신고 소스 보기 Nightly · 8.2 · 8.1 · 8.0 · 7.6 · 7.5

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

Bazel에 기여하려면 대신 Bazel에 기여하기를 참고하세요.

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

  1. 프로젝트의 참여 프로세스에 관한 유지관리자의 정보 소스로 사용됩니다.
  2. 커뮤니티 참여자와 프로젝트 유지관리자 간의 기대치를 설정합니다.

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

  • 출시 프로세스: Bazel의 출시 프로세스를 관리합니다.
  • Green Team: 규칙과 도구의 건강한 생태계를 구축합니다.
  • 개발자 환경 가드너: 외부 참여를 장려하고, 문제 및 풀 리퀘스트를 검토하며, 개발 워크플로를 더 개방적으로 만듭니다.

출시

지속적 통합

bazelbuild/continuous-integration 저장소에서 Bazel의 CI 인프라에 관한 Green팀의 가이드를 읽습니다.

문제의 수명 주기

  1. 사용자가 문제 템플릿 중 하나를 선택하여 문제를 만들면 검토되지 않은 미해결 문제 풀에 추가됩니다.
  2. 개발자 환경 (DevEx) 하위 팀 회전의 구성원이 문제를 검토합니다.
    1. 문제가 버그가 아니거나 기능 요청이 아닌 경우 DevEx 회원은 일반적으로 문제를 종료하고 사용자를 StackOverflow 및 bazel-discuss로 리디렉션하여 질문을 더 잘 노출합니다.
    2. rules_apple과 같이 커뮤니티에서 소유한 규칙 저장소 중 하나에 속하는 문제인 경우 DevEx 회원이 올바른 저장소로 이 문제를 트랜스퍼합니다.
    3. 문제가 모호하거나 정보가 누락된 경우 DevEx 회원은 계속하기 전에 사용자에게 문제를 다시 할당하여 추가 정보를 요청합니다. 이는 일반적으로 사용자가 올바른 문제 템플릿{: .external}을 선택하지 않거나 불완전한 정보를 제공하는 경우에 발생합니다.
  3. DevEx 회원은 문제를 검토한 후 즉시 처리해야 하는 문제인지 결정합니다. 해당하는 경우 P0 우선순위 라벨과 팀장 목록에서 소유자를 할당합니다.
  4. DevEx 회원은 라우팅을 위해 untriaged 라벨과 정확히 하나의 팀 라벨을 할당합니다.
  5. DevEx 회원은 문제 유형에 따라 type: bug 또는 type: feature request와 같은 type: 라벨을 정확히 하나 할당합니다.
  6. 플랫폼별 문제의 경우 DevEx 회원이 하나의 platform: 라벨을 할당합니다(예: Mac 관련 문제의 경우 platform:apple).
  7. 문제가 우선순위가 낮고 신규 커뮤니티 참여자가 해결할 수 있는 경우 DevEx 회원이 good first issue 라벨을 할당합니다. 이 단계에서 문제는 분류되지 않은 미해결 문제 풀에 포함됩니다.

각 Bazel 하위 팀은 소유한 라벨 아래의 모든 문제를 분류하며, 가능하면 매주 분류합니다. 하위 팀에서 문제를 검토하고 평가한 후 가능한 경우 해결 방법을 제공합니다. 팀 음반사 소유자인 경우 이 섹션 에서 자세히 알아보세요.

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

풀 요청의 수명 주기

  1. 사용자가 풀 요청을 만듭니다.
  2. Bazel팀의 구성원이며 담당 영역과 관련된 PR을 보낼 경우 팀 라벨을 할당하고 적합한 검토자를 찾는 것이 담당자의 책임입니다.
  3. 그렇지 않은 경우 일일 분류 중에 DevEx 회원이 라우팅을 위해 하나의 팀 라벨과 팀의 기술 책임자 (TL)를 할당합니다.
    1. TL은 원하는 경우 PR 검토를 다른 사람에게 할당할 수 있습니다.
  4. 할당된 검토자는 PR을 검토하고 승인되거나 삭제될 때까지 작성자와 협력합니다.
  5. 승인되면 검토자는 추가 테스트를 위해 PR의 커밋을 Google의 내부 버전 관리 시스템으로 가져옵니다. Bazel은 Google에서 내부적으로 사용하는 것과 동일한 빌드 시스템이므로 모든 PR 커밋을 내부 테스트 모음으로 테스트해야 합니다. 이것이 PR을 직접 병합하지 않는 이유입니다.
  6. 가져온 커밋이 모든 내부 테스트를 통과하면 커밋이 스쿼시되고 GitHub로 다시 내보내집니다.
  7. 커밋이 마스터에 병합되면 GitHub에서 PR을 자동으로 종료합니다.

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

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

문제

  1. 팀 라벨 및 untriaged 라벨을 기준으로 문제 목록을 필터링합니다.
  2. 문제를 검토합니다.
  3. 우선순위 수준을 파악하고 라벨을 할당합니다.
    1. P0인 경우 DevEx 하위 팀에서 이미 우선순위를 지정했을 수 있습니다. 필요한 경우 우선순위를 다시 지정합니다.
    2. 각 문제에는 우선순위 라벨이 하나씩만 있어야 합니다. 문제가 P0 또는 P1인 경우 Google에서 적극적으로 작업 중이라고 가정합니다.
  4. untriaged 라벨을 삭제합니다.

라벨을 추가하거나 삭제하려면 bazelbuild 조직에 있어야 합니다.

Pull 요청

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

우선순위

다음 우선순위 정의는 유지보수자가 문제를 분류하는 데 사용됩니다.

  • P0 - Bazel 출시 (출시 후보 제외)를 사용할 수 없게 만드는 심각한 기능 장애 또는 Bazel 프로젝트 개발에 심각한 영향을 미치는 다운된 서비스 여기에는 상당수의 사용자를 차단하는 새 버전에서 도입된 회귀나 브레이킹 체인지 정책을 준수하지 않는 비호환 브레이킹 체인지가 포함됩니다. 실용적인 해결 방법은 없습니다.
  • P1 - 다음 출시에서 해결해야 하는 심각한 결함 또는 기능이거나 Bazel 프로젝트 개발을 비롯한 많은 사용자에게 영향을 미치는 심각한 문제이지만 실용적인 해결 방법이 있습니다. 일반적으로 즉각적인 조치가 필요하지 않습니다. 수요가 많고 현재 분기 로드맵에 계획되어 있습니다.
  • P2 - 해결해야 하지만 현재 작업하고 있지 않은 결함 또는 기능입니다. 출시된 Bazel 버전의 중간 정도의 실시간 문제로, 향후 출시에서 해결해야 하거나 간단한 해결 방법이 있습니다.
  • P3 - 영향이 작은 바람직한 사소한 버그 수정 또는 개선사항 Bazel 로드맵이나 임박한 출시에 우선순위가 지정되지는 않지만 커뮤니티 참여를 권장합니다.
  • P4 - 종료될 가능성이 낮은 우선순위가 낮은 결함 또는 기능 요청입니다. 더 많은 사용자에게 영향을 미칠 경우 재우선순위를 지정할 수 있도록 열어 둘 수도 있습니다.
  • ice-box
    • 현재 처리할 시간이 없거나 참여를 수락할 시간이 없는 문제입니다. 이러한 문제는 아무도 작업하고 있지 않다는 것을 나타내기 위해 종료하지만 시간이 지남에 따라 유효성을 계속 모니터링하고 충분한 사용자가 영향을 받고 처리할 리소스가 있는 경우 다시 살립니다. 언제나 그렇듯이 종료된 문제에 대해서도 댓글을 남기거나 리액션을 추가해 주세요.

팀 라벨

새 문제의 경우 category: * 라벨이 지원 중단되고 팀 라벨이 대체되었습니다.

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