Google, 일부 소스 코드의 Git 태그 배포를 Google Drive 요청 방식으로 대체

Google은 일부 소스를 Git 태그로 공개하는 대신 Google Forms 신청 후 Google Drive의 tarball 접근 권한을 부여하며, GrapheneOS에 따르면 최근 처리 기간이 수 시간에서 수 주로 늘어남 tarball에는 기존과 같은 소스가 담기지만, Android 도구가 전제하는 Git 저장소 구조와 리비전을 사용할 수 없어 개발 흐름이 불편해짐 GrapheneOS는 수정에 적합한 형태의 소스를 합리적인 기간 안에 제공하지 않아 GPLv2를 위반한다고 보지만, GPLv2에 명시적인 제공 기한이 없다는 반론도 있음 Google은 서명된 Git 태그를 게시하거나 접근 권한 부여를 자동화할 수 있으나, 현재는 GrapheneOS가 사전 포팅과 테스트에 필요한 모든 Beta 태그를 매번 요청해야 함 지연은 주로 Pixel 지원에 영향을 주며, GrapheneOS는 Motorola용 주요 Android 릴리스를 미리 준비하고 전체 AOSP Git 저장소를 직접 호스팅할 계획임 Git 태그에서 Google Drive로 바뀐 배포 절차 Google은 일부 소스 코드의 배포 방식을 Git 태그 게시에서 Google Forms 신청 후 Google Drive 파일 접근 권한을 받는 절차로 바꿈 Drive로 옮기기 전부터 릴리스 태그를 게시하기에 앞서 전체 이력을 단일 커밋으로 스쿼시하기 시작함 Google Drive의 tarball에는 Git으로 제공하던 것과 정확히 같은 소스 코드가 들어 있지만, 접근과 활용 과정은 여러 단계에서 더 불편해짐 초기에는 신청 후 보통 몇 시간 안에 tarball 접근 권한을 받을 수 있었으나, 최근에는 답변까지 수 주가 걸리는 경우가 많아짐 Android 개발 흐름과 맞지 않는 형식 Android 도구는 소스 코드를 Git 저장소로 다루며, 빌드 시스템도 Git 리비전을 사용함 Git 리비전을 사용할 수 없을 때를 위한 메타데이터 파일 기반 대체 경로가 있으며, Google도 해당 파일을 제공함 GrapheneOS는 이력을 제거하더라도 기존처럼 소스를 여러 저장소로 나누고 Git 태그를 붙여야 수정에 적합한 형태가 된다고 봄 사람이 양식 제출을 검토해 파일별 권한을 부여하는 대신 Google이 선택할 수 있는 방법은 다음과 같음 Git에 서명된 태그 게시 파일이 아닌 폴더 단위로 접근 권한 부여 Google Drive 방식을 유지하되 권한 부여 자동화 현재 구조에서는 한...