사용자 대상 기능을 추가, 변경 또는 삭제하거나 아키텍처가 크게 변경된 경우 개발자는 디자인을 반드시 작성해야 합니다. 검토하고 해당 내용을 검토해야 변경사항을 제출할 수 있습니다.
다음은 중요한 변경사항의 몇 가지 예입니다.
- 네이티브 빌드 규칙 추가 또는 삭제
- 네이티브 규칙의 브레이킹 체인지
- 더 많은 API의 동작에 영향을 미치는 네이티브 빌드 규칙 의미 체계에 대한 변경사항 다른 규칙보다 더 많이
- Bazel의 규칙 정의 API 변경사항
- Bazel이 다른 시스템에 연결하는 데 사용하는 API 변경사항
- Starlark 언어, 시맨틱 또는 API 변경사항
- Bazel 성능 또는 메모리에 광범위한 영향을 미칠 수 있는 변경사항 용도 (좋은 쪽과 나쁜 쪽)
- 널리 사용되는 내부 API 변경사항
- 플래그 및 명령줄 인터페이스 변경
디자인 검토 이유
디자인 문서를 작성할 때 다른 Bazel 개발자와 조율할 수 있습니다. Bazel의 핵심 팀으로부터 조언을 구하세요. 예를 들어 제안서에 BUILD, WORKSPACE 또는 bzl 파일을 수정하려면 Starlark팀을 검토자로 추가하세요. 설계 문서는 제출 전에 다음과 같은 이유로 검토됩니다.
- Bazel은 매우 복잡한 시스템입니다. 겉보기에는 무해해 보이는 로컬 변화가 영향을 받을 수 있습니다
- 팀은 사용자로부터 많은 기능 요청을 받습니다. 이러한 요청은 기술적 타당성뿐만 아니라 요청할 수 있습니다
- Bazel 기능은 핵심 팀 외부의 사람들이 자주 구현합니다. 이러한 기여자는 매우 다양한 수준의 Bazel 전문성을 보유하고 있습니다.
- Bazel팀 자체의 전문성 수준은 다양합니다. 팀원이 하나도 없음 Bazel의 구석구석까지 완벽하게 이해하고 있습니다.
- Bazel의 변경사항은 이전 버전과의 호환성을 고려하여 중단을 피해야 합니다. 있습니다.
Bazel의 디자인 검토 정책은 다음과 같은 가능성을 극대화하는 데 도움이 됩니다.
- 모든 기능 요청은 기준 수준의 조사를 거칩니다.
- 적합한 사람들이 디자인에 대해 평가할 것입니다. 작동하지 않을 수 있습니다.
시작하는 데 도움이 필요하면 Bazel 제안서 저장소. 설계는 진행 중이므로 구현 세부정보는 시간이 지남에 따라 변경될 수 있음 피드백을 제공합니다 게시된 설계 문서에는 초기 설계와 지속적인 변경이 아닙니다. 항상 현재 Bazel 기능에 대한 설명을 참조하세요.
참여자 워크플로
참여자는 디자인 문서를 작성하고 pull 요청을 보내고 제안서 검토자를 요청할 수 있습니다
디자인 문서 작성
모든 디자인 문서에는 다음을 포함하는 헤더가 있어야 합니다.
- 저자
- 마지막 주요 변경 날짜
- 검토자 목록 (한 명만 포함) 수석 검토자
- 현재 상태 (초안, 검토 중, 승인됨, 거부됨, 구현 중, 구현 중)
- 토론 대화목록 링크 (공지 후 추가 예정)
문서는 누구나 읽을 수 있는 Google 문서로 작성할 수 있습니다. 또는 마크다운을 사용하면 됩니다. 아래에서 마크다운 / Google Docs 비교.
사용자에게 표시되는 영향이 있는 제안서에는 이전 버전과의 호환성 (및 필요한 경우 출시 계획)에 미치는 영향
pull 요청 만들기
문서를 추가할 pull 요청 (PR)을 만들어 디자인 문서를 공유합니다. 설계 색인의 한 유형입니다. 추가 마크다운 파일 또는 PR에 대한 문서 링크를 제공하세요.
가능한 경우 리드 검토자를 선택합니다. 다른 검토자를 참조에 포함합니다. 리드 검토자를 선택하지 않으면 Bazel이 담당자가 PR에 하나를 할당합니다.
PR을 만든 후 검토자는 살펴보겠습니다 예를 들어 리드 검토자가 추가 검토자를 제안할 수 있습니다. 누락된 정보를 찾을 수 있습니다. 리드 검토자는 PR을 승인합니다. 검토 절차가 시작될 수 있다고 생각합니다 제안서가 완벽하다는 의미는 아닙니다. 또는 승인될 예정임 제안서에 제안서가 승인되기에 충분한 정보가 포함되어 있고 논의를 시작할 수 있습니다.
새 제안서 발표
공지사항 보내기 bazel-dev인 경우 PR이 제출됩니다.
다른 그룹 (예: bazel-discuss 을 사용하세요.
검토자와 반복
관심 있는 모든 사용자가 제안에 댓글을 달 수 있습니다. 질문에 답하고 제안서를 명확히 하고 우려 사항을 해결합니다.
토론은 공지 대화목록에서 이루어져야 합니다. 제안서가 대신 댓글을 사용할 수 있습니다. 참고로 익명 댓글은 허용됨).
상태 업데이트
반복이 다음에 해당하는 경우 새 PR을 만들어 제안서 상태를 업데이트합니다. 합니다. 동일한 리드 검토자에게 PR을 전송하고 다른 검토자를 참조에 포함합니다.
제안서를 공식적으로 수락하기 위해 리드 검토자는 다른 검토자가 결정에 동의하는지 확인합니다.
첫 공지 후 승인까지 최소 1주일의 간격이 있어야 합니다. 생성할 수 있습니다. 이렇게 하면 사용자가 충분한 시간을 가지고 문서를 읽고 의견을 공유합니다.
제안이 수락되기 전에 구현을 시작할 수 있습니다. 예를 들어 개념 증명 또는 실험입니다 하지만 변경사항을 제출할 수는 없습니다. 검토 완료 전에 표시될 수 있습니다
리드 검토자 선택
리드 검토자는 다음과 같은 도메인 전문가여야 합니다.
- 관련 하위 시스템에 대한 지식이 있음
- 객관적이고 건설적인 피드백을 제공할 수 있는 능력
- 전체 검토 기간 동안 프로세스를 주도할 수 있습니다.
여러 팀의 연락처를 확인해 보세요. 라벨과 함께 사용할 수 있습니다.
마크다운과 Google Docs 비교
둘 다 허용되므로 가장 적합한 방법을 결정하세요.
Google Docs의 이점:
- 시작하기가 쉬우므로 브레인스토밍에 효과적입니다.
- 공동 편집
- 빠른 반복.
- 수정을 제안할 수 있는 간편한 방법입니다.
마크다운 파일 사용의 이점:
- 연결할 수 있는 정리된 URL을 만듭니다.
- 버전에 대한 명시적 기록입니다.
- 링크를 공개하기 전에 액세스 권한을 설정하는 것을 잊지 마세요.
- 검색엔진으로 쉽게 검색할 수 있습니다.
- 미래 경쟁력 확보: 일반 텍스트는 특정 도구를 사용할 수 없음 인터넷 연결이 필요하지 않습니다
- 작성자가 더 이상 존재하지 않더라도 업데이트할 수 있습니다.
- 자동 처리 (작동하지 않는 링크 업데이트/감지, 가져오기, 목록 등).
먼저 Google 문서에서 반복한 다음 후세용 마크다운입니다.
Google Docs 사용하기
일관성을 위해 Bazel 디자인 문서 템플릿을 사용합니다. 필요한 헤더를 포함하고 시각적 개체를 다른 Bazel 관련 문서와 일관성이 있어야 합니다. 이렇게 하려면 파일 > 사본을 만들거나 이 링크를 클릭하여 디자인 문서의 사본을 만듭니다. 템플릿을 참고하세요.
누구나 문서를 읽을 수 있도록 하려면 공유 > 고급 > 변경... '사용 - 링크가 있는 모든 사용자'를 선택합니다. 문서에 댓글을 허용하면 Google 계정이 없어도 누구든지 익명으로 댓글을 달 수 있습니다.
마크다운 사용
문서는 GitHub에 저장되며 GitHub 버전의 마크다운 (사양).
PR을 만들어 기존 문서를 업데이트합니다. 주요 변경사항은 문서 검토자가 검토합니다. 사소한 변경 (오타, 서식 등) 누구나 승인할 수 있습니다.
검토자 워크플로
검토자가 설계 문서를 코멘트하고 검토하고 승인합니다.
일반적인 검토자의 책임
설계 문서를 검토하고 추가 검토 과정을 통과한 설계를 승인합니다.
새 제안서를 받는 경우
- 문서를 빠르게 살펴보세요.
- 중요한 정보가 누락되었거나 디자인이 맞지 않는 경우 언급 프로젝트 목표에도 부합할 수 있습니다
- 추가 검토자를 추천합니다.
- 검토 준비가 완료되면 PR을 승인합니다.
검토 프로세스 중
- 문제가 있는 문제에 대해 디자인 저자와 대화를 나눕니다. 명확한 설명이 필요할 수 있습니다
- 필요하다면 설계를 살펴봤습니다
- 댓글 작성의 전제 조건으로 작성자가 처리해야 할 댓글 결정 승인을 받아야 합니다.
- 'LGTM' 작성 (Looks Good To Me)를 사용하면 현재 상태에 만족하는지 확인합니다
모든 디자인 검토 요청에 대해 이 절차를 따르세요. 디자인 승인 안 함 Bazel이 영향을 받지 않는 경우 설계 색인.
리드 검토자의 책임
구현에 대해 실행 여부를 결정할 책임은 크리에이터에게 있습니다. 설계할 수 있습니다 이 작업을 수행할 수 없는 경우 (대리인에게 PR을 재할당하거나) 버그를 추가 처리를 위한 Bazel 관리자
검토 프로세스 중
- 의견 작성 및 디자인 반복 프로세스가 진행되도록 함 도움이 됩니다.
- 승인에 앞서 다른 검토자의 우려가 문제가 해결되었습니다
모든 검토자의 승인 후
- 메일링 리스트입니다.
- PR에서 상태를 업데이트했는지 확인합니다.
- 제안서 작성자가 보낸 PR을 승인합니다.
디자인 거부 중
- PR 작성자가 PR을 보내야 합니다. 또는 PR을 보내야 합니다.
- PR이 문서의 상태를 업데이트합니다.
- 디자인을 승인할 수 없는 이유를 설명하는 메모를 문서에 추가하세요. 현재 상태를 설명하고, 필요한 경우 다음 단계를 간략하게 설명합니다 (예: '잘못된 다시 제출')을 입력합니다.