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

Nightly · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

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

Bazel에 기여하려면 Contributing to Bazel을 대신 읽어보세요.

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

  1. 프로젝트의 기여 절차에 관한 관리자의 정보 소스 역할을 합니다.
  2. 커뮤니티 기여자 및 프로젝트 관리자 간에 기대치를 설정합니다.

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

  • 출시 프로세스: Bazel의 출시 프로세스를 관리합니다.
  • 그린팀: Bazel CI 상태를 모니터링하고 중단을 보고합니다.
  • 개발자 환경 관리자: 외부 기여를 장려하고, 문제 및 pull 요청을 검토하고, 개발 워크플로를 더 개방적으로 만듭니다.

출시

지속적 통합

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

문제 수명 주기

  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 구성원은 Mac 관련 문제의 경우 platform:apple과 같은 platform: 라벨을 하나 할당합니다.
  7. 문제의 우선순위가 낮고 새로운 커뮤니티 기여자가 해결할 수 있는 경우 DevEx 구성원은 good first issue 라벨을 할당합니다. 이 단계에서 문제는 분류되지 않은 공개 문제 풀에 입력됩니다.

각 Bazel 하위팀은 소유한 라벨의 모든 문제를 분류합니다(가급적 주간 기준) . 하위팀은 문제를 검토 및 평가하고 가능한 경우 해결 방법을 제공합니다. 팀 라벨의 소유자인 경우 이 섹션 에서 자세한 내용을 확인하세요.

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

Pull 요청 수명 주기

  1. 사용자가 pull 요청을 만듭니다.
  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인 경우 적극적으로 해결되고 있다고 가정합니다.
  4. untriaged 라벨을 삭제합니다.

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

Pull 요청

pull 요청 (PR)은 외부 기여자가 Bazel에 가치를 더하는 주요 방법입니다. 오픈소스 프로젝트이므로 PR이 적시에 효율적으로 검토되고 처리되도록 하는 것이 중요합니다.

  • 분류

    awaiting-review 라벨과 팀 라벨이 있는 수신 PR을 정기적으로 검토합니다. 이는 로테이션 또는 정기 분류 회의를 통해 수행할 수 있습니다. 각 PR은 영업일 기준 7일 이내에 초기 응답을 받을 것으로 예상합니다.

  • 응답

    • PR이 적절해 보이면 승인하고 awaiting-PR-merge 라벨을 적용합니다. gTech팀에서 PR을 CL로 가져옵니다.
    • 그렇지 않으면 의견을 남기고 awaiting-review 라벨 을 awaiting-user-response 라벨로 바꿉니다. PR 작성자가 응답하면 DevEx 하위팀에서 라벨을 정기적으로 업데이트합니다.
    • 주요 변경사항이 있는 PR의 경우 설계 문서 또는 문제에 관한 사전 논의를 요청하는 것이 좋습니다.

  • 종료

    리소스가 제한되어 있으므로 Bazel 표준을 충족하지 않거나 검토 또는 유지관리할 수 없는 PR을 종료하는 것이 중요합니다.

    • PR이 Bazel의 목표와 일치하지 않으면 설명을 포함하여 종료합니다.
    • PR이 너무 크고 복잡하면 더 작은 부분으로 나누도록 요청하여 종료합니다.
    • PR 코드 품질이 Google 표준을 충족하지 않으면 설명을 포함하여 종료합니다.
    • 향후 코드 유지관리 비용이 너무 높으면 설명을 포함하여 종료합니다.
    • PR이 오랫동안 사용자 응답을 기다리고 있으며 기여자가 응답하지 않은 경우 30일 후에 PR이 자동으로 오래된 것으로 표시되고 30일 후에 종료됩니다.

    PR을 종료할 때는 정중하게 종료 이유를 설명하세요.

우선순위

관리자는 우선순위에 관한 다음 정의를 사용하여 문제를 분류합니다.

  • P0 - Bazel 출시 (출시 후보 제외)를 사용할 수 없게 만드는 주요 기능 중단 또는 Bazel 프로젝트 개발에 심각한 영향을 미치는 서비스 중단입니다. 여기에는 상당수의 사용자를 차단하는 새 출시에서 도입된 회귀 또는 호환되지 않는 주요 변경사항이 포함됩니다(주요 변경사항 정책을 준수하지 않음). 실용적인 해결 방법은 없습니다.
  • P1 - 다음 출시에서 해결해야 하는 중요한 결함 또는 기능이거나 Bazel 프로젝트 개발을 포함하여 많은 사용자에게 영향을 미치는 심각한 문제이지만 실용적인 해결 방법이 있습니다. 일반적으로 즉각적인 조치가 필요하지 않습니다. 수요가 많고 이번 분기 로드맵에 계획되어 있습니다.
  • P2 - 해결해야 하지만 현재 해결하고 있지 않은 결함 또는 기능입니다. 출시된 Bazel 버전의 중간 수준의 라이브 문제 로, 향후 출시에서 해결해야 하는 사용자에게 불편을 초래하거나 쉬운 해결 방법이 있습니다.
  • P3 - 영향이 적은 바람직한 사소한 버그 수정 또는 개선사항입니다. Bazel 로드맵 또는 임박한 출시에는 우선순위가 지정되지 않지만 커뮤니티 기여는 권장됩니다.
  • P4 - 종료될 가능성이 낮은 우선순위가 낮은 결함 또는 기능 요청입니다. 영향을 받는 사용자가 더 많은 경우 우선순위를 다시 지정할 수 있도록 열어둘 수도 있습니다.

팀 라벨

새 문제의 경우 팀 라벨을 사용하는 대신 category: * 라벨이 지원 중단되었습니다.

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