V8 커미터와 리뷰어의 책임

V8 리포지토리에 커밋할 때, 다음 지침을 준수해야 합니다 (https://dev.chromium.org/developers/committers-responsibility에서 수정됨):

1. 변경 사항과 리뷰 요청된 패치에 적합한 리뷰어를 찾으세요.
2. 변경 사항을 적용하기 전후에는 IM 또는 이메일을 통해 이용 가능하도록 하세요.
3. waterfall을 확인하며 변경 이후 모든 봇이 초록색으로 변할 때까지 감시하세요.
4. TBR 변경(To Be Reviewed)을 적용할 때 변경하는 코드의 소유자에게 알리세요. 일반적으로 리뷰 이메일을 보내면 됩니다.

요약하자면, 프로젝트를 위해 올바른 일을 하세요. 코드 커밋을 위해 가장 쉬운 방법이 아니라, 무엇보다도: 최선의 판단을 사용하세요.

질문하는 것을 두려워하지 마십시오. v8-committers 메일링 리스트에 메시지를 보내면 즉시 이를 읽고 도움을 줄 사람이 항상 있습니다.

여러 리뷰어가 있는 변경 사항

때때로 여러 리뷰어가 관련된 변경 사항이 있을 수 있습니다. 이는 여러 책임 영역과 전문 지식 때문에 때로는 여러 사람이 변경 사항에 대해 알아야 하기 때문입니다.

문제는 일부 지침 없이 이러한 리뷰에서는 명확한 책임이 주어지지 않을 수 있다는 것입니다.

변경 사항에 대한 유일한 리뷰어라면 좋은 리뷰를 해야 한다는 것을 알 수 있습니다. 리뷰어가 세 명 이상이면, 가끔 다른 사람이 리뷰의 일부를 꼼꼼히 검토했을 것이라고 가정할 수 있습니다. 때로는 모든 리뷰어가 이렇게 생각하기도 하며 변경 사항이 적절히 리뷰되지 않는 경우도 있습니다.

다른 경우, 일부 리뷰어가 패치에 대해 “LGTM”이라고 말하면서, 다른 리뷰어들은 아직 변경 사항을 기대하는 경우가 있습니다. 저자는 리뷰 상태에 혼란을 느낄 수 있으며 일부 패치는 리뷰어 중 한 명이 추가 변경을 기대했음에도 커밋된 적이 있습니다.

동시에, 리뷰 과정에 많은 사람이 참여하고 진행 상황을 체크하도록 권장하고 싶습니다.

이 과정을 명확히 하기 위한 몇 가지 지침은 다음과 같습니다:

1. 패치 작성자가 한 명 이상의 리뷰어를 요청할 경우, 리뷰 요청 이메일에서 각 리뷰어의 책임이 무엇인지 명확히 해야 합니다. 예를 들어 이메일에 이렇게 작성할 수 있습니다:

   - Larry: 비트맵 변경 사항
   - Sergey: 프로세스 해킹
   - 다른 모두: 참고(FYI)

2. 이 경우, 멀티프로세스 변경에 대한 정보를 알고 싶기 때문에 리뷰 리스트에 있을 수 있지만 주 리뷰어가 아니며 작성자나 다른 리뷰어들이 모든 차이에 대한 상세한 리뷰를 기대하지 않을 것입니다.

3. 리뷰에 여러 사람이 포함되어 있고 작성자가 (1)을 하지 않았다면, 상세한 리뷰를 원하지 않는 경우 작성자에게 자신이 맡아야 할 부분을 물어보세요.

4. 작성자는 체크인하기 전에 리뷰어 리스트의 모든 사람에게 승인을 받아야 합니다.

5. 명확한 리뷰 책임이 없는 리뷰자들(예: 드라이브 바이 리뷰)은 매우 응답성이 뛰어나야 하며 리뷰를 지연시키지 않아야 합니다. 패치 작성자는 그들에게 망설임 없이 요청할 수 있어야 합니다.

6. 리뷰 중에 FYI로 간주되는 경우 세부적으로 리뷰를 하지 않았거나 전혀 리뷰하지 않았지만 패치에 문제가 없는 경우 이를 명시하세요. “rubber stamp” 또는 “ACK”라는 표현을 사용할 수 있습니다. 이렇게 하면 실제 리뷰어들이 당신이 그들의 일을 대신 처리했다고 생각하지 않으며, 패치 작성자는 당신의 추가 피드백을 기다릴 필요가 없음을 알게 됩니다. 이렇게 하면 모든 사람이 루프 안에 유지되면서 명확한 소유권과 상세한 리뷰가 가능하길 바랍니다. 일부 변경 사항은 관심이 없는 변경 사항을 빠르게 “ACK” 처리할 수 있어, 작성자는 당신의 피드백을 기다릴 필요가 없어져 변경 사항 속도가 빨라질 수도 있습니다.