모두가 OpenXLA에 기여할 수 있으며 Google은 모두의 기여를 소중하게 생각합니다. 다음과 같은 여러 가지 방법으로 참여할 수 있습니다.
OpenXLA 토론 포럼의 질문에 답변 (openxla-discuss)
OpenXLA 문서 개선 또는 확장
OpenXLA 코드베이스에 기여
OpenXLA를 기반으로 빌드된 더 광범위한 라이브러리 생태계에 위와 같은 방법으로 기여
OpenXLA 프로젝트는 Google의 오픈소스 커뮤니티 가이드를 준수합니다.
시작하기 전에
기여자 라이선스 계약에 서명
이 프로젝트에 대한 기여에는 기여자 라이선스 계약 (CLA)이 포함되어야 합니다. 귀하 (또는 귀하의 고용주)는 기여에 대한 저작권을 보유합니다. 이는 Google이 프로젝트의 일부로 귀하의 기여를 사용하고 재배포할 수 있는 권한을 부여하는 것뿐입니다.
귀하 또는 현재 고용주가 이미 Google CLA에 서명했다면 (다른 프로젝트의 경우라도) 다시 서명할 필요가 없습니다.
현재 계약을 확인하거나 새로 서명하려면 <https://cla.developers.google.com/>을 방문하세요.
윤리 강령 검토
이 프로젝트는 Tensorflow 윤리 강령을 따릅니다.
후원 절차
개발자 가이드
코드 가져오기, 빌드, 테스트 실행, 변경사항 제출을 포함하여 OpenXLA용 개발 환경을 설정하는 방법에 관한 가이드는 개발자 가이드를 참고하세요.
코드 표준
코딩 스타일: Google의 코드 스타일 가이드를 따릅니다. 특히 C/C++ 및 Python 가이드를 참고하세요. 제출된 모든 코드는 이러한 스타일 가이드를 엄격히 준수해야 합니다.
간소화된 변경: Google의 엔지니어링 관행을 따릅니다. 특히 압축 변경사항 작성 가이드를 참고하세요. 이렇게 하면 검토 가능성이 향상되어 코드를 병합하는 속도가 크게 향상되고 의도하지 않은 변경의 부작용이 발생할 가능성이 줄어듭니다. 변경사항이 많아도 이를 좀 더 점진적인 변경으로 나누는 전략이 많이 있습니다.
테스트 범위: 모든 변경사항에는 적절한 단위 테스트가 포함되어야 합니다. 단위 테스트는 특정 하드웨어 (CPU, GPU 등) 타이밍에 의존해서는 안 되며 확정적 및 집중 테스트를 위해 모의 테스트와 가짜 테스트를 자유롭게 사용해야 합니다. 현재 테스트하기 어려운 기존 코드를 확장하려는 변경사항은 테스트 가능성을 적절하게 개선해야 합니다.
이점을 명확하게 이해할 수 있도록 모든 변경사항에는 변경사항 제목에 적절한 벤치마크 결과가 포함되어야 합니다.
코드 내 규칙에 확신이 없을 때는 항상 기존 코드를 검토하고 OpenXLA에 이미 있는 패턴을 따르는 것이 좋습니다.
검토 절차
프로젝트 구성원이 제출한 항목을 포함하여 모든 제출물은 검토가 필요합니다. 이를 위해 GitHub pull 요청이 사용됩니다. pull 요청 사용에 대한 자세한 내용은 GitHub 도움말을 참조하세요.
검토 전에 코드가 위에 나열된 모든 표준을 준수해야 합니다. 이는 선택사항이 아니며 변경사항을 적시에 수락할 수 있도록 검토를 요청하기 전에 제출자가 코드가 준수하는지 확인하는 것이 중요합니다.
모든 테스트를 통과해야 합니다. 테스트가 손상되었고 문제가 빌드 환경 또는 변경사항과 관련이 없는 경우 유지관리 담당자에게 문의하세요.
검토 과정에서 범위가 늘어나지 않도록 하세요. 이는 제출자와 검토자 모두의 책임입니다. 변경사항이 너무 커지기 시작하면 여러 변경사항으로 분할하는 것이 좋습니다.
변경사항이 병합되기 전에 Google 및 기타 하드웨어 공급업체 내부의 코드를 사용하는 내부 테스트를 거칩니다. 공개 CI에서 포착하지 못하는 내부 테스트 실패가 발생하면 검토 프로세스에 단계가 추가될 수 있습니다. 변경사항을 검토하는 Google 직원은 모든 내부 테스트 실패를 전달하고 수정해야 하는 사항을 설명합니다.
자주 묻는 질문(FAQ)
"이 인프라 변경은 제 PR과 관련이 없습니다. 왜 이렇게 해야 하나요?"
XLA팀에는 전담 인프라팀이 없으므로 도우미 라이브러리를 빌드하고 기술 부채를 피하는 것은 우리 모두의 몫입니다. Google은 이를 XLA 변경의 정기적인 작업으로 간주하며, 모든 사용자가 참여할 것으로 예상됩니다. Google은 일반적으로 코드를 작성할 때 필요에 따라 인프라를 구축합니다.
XLA 검토자는 개발자가 작성한 PR과 함께 일부 인프라를 구축하거나 PR을 대폭 변경하도록 요청할 수 있습니다. 이 요청은 불필요하거나 변경하려는 변경사항과 직각을 이루는 것처럼 보일 수 있습니다. 이는 구축해야 하는 인프라의 규모와 이에 대한 검토자의 기대치가 일치하지 않기 때문일 수 있습니다.
기대치가 일치하지 않아도 괜찮습니다. 이는 프로젝트를 처음 시작할 때 당연한 일입니다. 때로는 오래된 직원들에게도 그런 일이 일어납니다. 이전에 작업한 프로젝트는 기대가 다를 수 있습니다. 이것도 괜찮습니다. 예상되는 문제입니다. 그렇다고 해서 두 프로젝트 중 하나의 접근 방식이 잘못된 것은 아닙니다. 서로 다른 방식일 뿐입니다. 다른 모든 검토 의견과 함께 인프라 요청을 받으면 이 프로젝트에 대해 예상되는 결과를 배우실 수 있습니다.
"향후 PR에서 고객님의 의견을 전달해도 될까요?"
PR의 인프라 요청 (또는 기타 대규모 요청)과 관련하여 자주 묻는 질문은 원래 PR에서 변경해야 하는지 또는 향후 PR의 후속 조치로 변경할 수 있는지 여부입니다.
일반적으로 XLA는 PR 작성자가 후속 PR로 리뷰 댓글을 처리하는 것을 허용하지 않습니다. 검토자가 특정 PR에서 다루어야 할 무언가를 결정하면 일반적으로 작성자는 요청된 내용이 큰 변경사항일지라도 해당 PR에서 이를 해결할 것으로 예상합니다. 이 표준은 Google 내부와 외부적으로도 적용됩니다.
XLA가 이 접근 방식을 취하는 데에는 몇 가지 이유가 있습니다.
신뢰: 검토자의 신뢰를 얻는 것이 핵심 구성요소입니다. 오픈소스 프로젝트에서 참여자는 원하는 대로 나타나거나 사라질 수 있습니다. PR이 승인된 후에는 검토자가 약속한 후속 조치가 실제로 완료되었는지 확인할 방법이 없습니다.
다른 개발자에게 미치는 영향: XLA의 특정 부분을 다루는 PR을 보냈다면 다른 사람들이 같은 부분을 보고 있을 가능성이 높습니다. Google이 PR에 기술 부채를 허용하는 경우 후속 조치를 제출할 때까지 이 파일을 보고 있는 모든 사용자가 이 부채의 영향을 받습니다.
검토자 대역폭: 후속 조치 변경을 연기하면 이미 과부하된 검토자에게 여러 가지 비용이 발생합니다. 후속 조치를 기다리는 동안 검토자가 첫 번째 PR이 무엇인지 잊어버려 다음 검토가 더 어려워질 수 있습니다. 또한 검토자는 예상되는 후속 조치를 추적하여 실제로 후속 조치가 이루어지도록 해야 합니다. 원래 PR과 실제로 수직이 되도록 변경하여 다른 검토자가 검토할 수 있도록 변경할 수 있다면 대역폭 문제는 덜 됩니다. 저희의 경험에 의하면 이러한 경우는 드뭅니다.