로쿠가 개발자 저장소를 GitHub에서 GitLab으로 옮겼습니다

Roku developer repositories moved from GitHub to GitLab

blog.roku.com ▲ 294 댓글 208 cxr

요약

로쿠가 개발 문서와 샘플, 도구 저장소를 모두 GitHub에서 GitLab으로 옮겼습니다.

로쿠 개발자 블로그가 10월 15일 올린 공지입니다. 흩어져 있던 개발자용 저장소를 GitLab 한곳에 모았고, 새 저장소에는 RSG 2.0 SDK의 오픈소스 코드도 들어간다고 밝혔습니다.

왜 중요한가

  • 로쿠 저장소 주소를 따로 저장해 둔 개발자는 직접 새 주소로 고쳐야 합니다.
  • 저장소를 색인해 AI 비서나 코딩 에이전트에 쓰는 경우, 오류 없이 낡은 내용을 내놓을 수 있어 가장 먼저 점검하라고 했습니다.
  • 문서 수정 제안은 접근 요청부터 해야 하고 "Suggest edits" 기능도 없어져 절차가 길어집니다.

핵심 내용

  • 공식 문서와 블로그의 링크는 이미 새 주소로 바꿔 두어 개발자 영향은 적다고 했습니다.
  • 저장소 이름은 그대로라서 github.com/rokudev/저장소 주소가 gitlab.com/rokudev/저장소로 바뀝니다.
  • raw.githubusercontent.com에서 파일을 읽던 파이프라인도 GitLab의 원본 파일 경로로 바꿔야 합니다.
  • 기존 클론은 git remote set-url로, 서브모듈은 .gitmodules 수정 뒤 git submodule sync로 옮기라고 안내했습니다.
  • 빠뜨린 곳은 자기 저장소에서 rokudev를 검색해 하나씩 찾으라고 권했습니다.

HN 반응

  • GitLab이 회사 업무에 더 잘 맞는다는 의견에, 둘 다 써 보면 기능은 거의 같다는 반론이 이어졌습니다.
  • 저장소를 계층으로 묶고 권한을 주기 쉽다는 경험담도 있었지만, 그룹 간 권한 설정과 리뷰어 지정이 번거롭다는 불만도 나왔습니다.

댓글

30개 표시 · 전체 208개
  1. PedroBatista HN

    GitLab은 단점이 많아도 "일반" 회사나 조직의 프로젝트에는 훨씬 잘 맞습니다. 소프트웨어 개발과 그 주변 업무를 하는 사람들이 머릿속에 그리는 모델에 더 가깝고, GitHub처럼 처음부터 "오픈소스 개발자 소셜 네트워크"가 되려고 하지도 않았고요. GitHub는 요즘 들어 마이크로소프트 물이 들어버렸죠. CI나 GitHub Actions 얘기는 꺼내지도 맙시다..

  2. ivanjermakov HN

    "일반" 회사나 조직의 프로젝트에 훨씬 잘 맞습니다

    어째서요? 회사에서 둘 다 써 봤는데 기능상으로는 똑같던데요.

  3. GuB-42 HN

    근본적으로는 둘 다 풀 리퀘스트, 계정 관리, 버그 추적 같은 흔한 기능이 붙은 git일 뿐입니다.

    어느 쪽을 고를지는 세부 사항에서 갈립니다. 사내 네트워크와 얼마나 잘 붙는지, 겉모습이 얼마나 예쁜지, CI/CD 연동 옵션, 전반적인 인기와 커뮤니티 같은 것들이죠. 마지막으로 제가 고를 수 있었을 때는 Gitea를 택했습니다. 성능이 좋았고 필요한 건 다 갖추고 있었거든요.

  4. txtsd HN

    Gitea는 수상쩍기 짝이 없어요. 포크인 Forgejo를 쓰세요. 원래 개발자들이 전부 그쪽으로 넘어갔거든요.

  5. myko HN

    저는 GitLab이 저장소를 계층 구조로 정리하기 훨씬 쉬웠습니다. 권한 설정도 더 쉬워 보였고요.

  6. tyingq HN

    전용 인스턴스나 자체 호스팅으로 쓰면 GitLab은 그룹 간 권한이 형편없습니다. gitlab.com은 최상위 그룹끼리 서로 분리되도록(테넌트가 따로 되도록) 만들어져 있기 때문입니다. 그룹 간 MR 승인, 내장 아티팩트 저장소, 테라폼 모듈 레지스트리, GitLab 컴포넌트 등등이 전부 아주 지저분합니다. 그룹 간에 켜 줘야 하는 세부 허용 설정이 너무 많아요.

  7. IshKebab HN

    맞아요, 같은 생각입니다. 아주 사소한 차이만 있을 뿐이에요.

  8. koolala HN

    회사 네트워크에 직접 설치해서 쓸 수 있다는 게 꽤 중요한 기능 아닌가요? 사내용으로 두는 비공개 브랜치나 프로젝트가 있을 테니까요. 모든 걸 같은 UX로 쓸 수 있고요.

    그런데 이건 꽤 짜증스러워 보이네요: https://docs.gitlab.com/administration/license_usage/

  9. radlad HN
  10. koolala HN

    더 비싼가요?

  11. radlad HN

    GitLab보다요?

    잘 모르겠네요. 가격 페이지를 직접 확인해 보셔야 할 겁니다.

  12. koolala HN

    거기엔 안 나와 있죠? 자체 호스팅으로 상업적으로 쓸 때 말이에요. 둘 중 하나라도 오픈소스였으면 좋겠네요.

  13. quietbritishjim HN

    일부 회사에는 중요하거나 필수이긴 합니다. 하지만 그분이 말한 "머릿속 모델"에 더 잘 맞는다는 얘기가 그런 뜻은 아니었을 거예요.

  14. kart23 HN

    GitLab은 리뷰어 지정이 정말 골칫거리예요. 그룹을 리뷰어로 추가할 수 있게 해 달라는 이슈가 여러 번 올라왔는데, GitLab은 그때마다 우리가 가는 '방향'이 아니라며 닫아버렸어요. 대신 설명란에 /request_review @group을 쓰면 되긴 하는데, 사람마다 개별로 추가되니까 어떤 리뷰어가 어느 그룹 소속인지 알 수 없고, 코드오너 파일 조건을 채우는 그룹이 맞게 들어갔는지도 알 수 없죠. 정말 엉망이에요.

  15. nullpoint420 HN

    GitLab은 오픈소스인가요, 아니면 그 이상한 "코드만 공개된" 프로젝트 중 하나인가요? PR을 보낼 수는 있나요?

  16. tancop HN

    핵심 오픈소스 버전은 IntelliJ처럼 Community Edition이라고 부릅니다. 대부분의 프로젝트는 아무 수식어 없는 이름을 쓰고 Enterprise나 Cloud를 유료 서비스로 두는데, 이걸 보면 감이 오죠.

    기여는 받아 주지만, 유료 기능에 해당하는 것을 무료 버전에 넣는 기여는 받지 않습니다. 엔터프라이즈의 가치가 조금이라도 떨어진다고 보거나 자기들 비전에 어긋난다고 보는 거죠. 확실히 회사가 주도하는 프로젝트이고, Redis나 VSCode 같은 하이브리드도 아닙니다.

  17. stefan_ HN

    솔직히 좋을 때도 있고 나쁠 때도 있습니다. GitLab이 "기능 체크박스 채우기 열풍" 시절에 추가한 쓰레기 같은 것들을 전부 되돌아가서 지우면 크게 좋아질 거예요. 왼쪽 메뉴만 봐도 "Secure", "Deploy", "Operate", "Monitor", "Analyze", "Auto Devops" 같은 것들은 당장 치워서 사람들 앞길에서 비켜 줘야 합니다.

    그리고 감히 말하자면, 대부분의 개발을 코딩 에이전트가 하는 세상에서도 GitLab이 설 자리는 있습니다. 버전 관리와 CI를 맡는 곳이면 충분히 괜찮아요. 그런데 경영진이 어리석어서(애틀라시안이나 GitHub도 마찬가지고요) 자기들이 추론의 오케스트레이터이자 중간상이자 관문이 되어야 한다고 스스로 믿어 버렸습니다. 그들은 그런 존재가 아니고 앞으로도 될 수 없습니다. 그러다 Copilot처럼 그걸 이루겠다고 제품을 망치는 길로 간다면 그걸로 끝일 겁니다.

  18. 1718627440 HN

    "Secure", "Deploy", "Operate", "Monitor", "Analyze", "Auto Devops"

    Deploy에는 릴리스된 버전과 패키지가 들어 있습니다.

    Operate는 Infrastructure as Code용이고요.

    Analyze는 프로젝트와 CI 통계입니다.

    이 중에 지우고 싶은 게 있을 것 같지 않습니다. 꼭 필요한 기능이니까요.

  19. nikau HN

    제 경험으로는 아무도 안 씁니다. 다들 작업 상태와 로그를 볼 수 있는 예쁜 UI만 원하죠.

  20. bob1029 HN

    (이번 이전이 최근 장애 때문이라고 가정하면)

    지금 같은 상황에서는 어디를 가도 풀밭이 오래 푸르지는 않을 것 같습니다.

    GitHub 장애가 대부분 GitHub 엔지니어들이 AI를 쓰기 때문에 생기는 건 아닙니다(한두 건은 그럴 수도 있겠지만요). 장애의 주된 원인은 개발자들이 워크플로에서 훨씬 빠르게 움직일 수 있게 됐다는 사실입니다. 이 제품들을 쓰는 사용자 한 명 한 명이 시스템에 더 무거운 부하를 주고 있어요. 이 수요 증가가 당분간 멈출 것 같지는 않습니다. 저는 시간당 5,000건인 GH API 할당량이 2027년이 되기 전에 반으로 깎인다는 메일이 지금 당장 날아와도 이상하지 않다고 생각합니다.

    셀프 호스팅이나 엔터프라이즈 요금제를 쓰겠다는 게 아니라면, GitLab이 이런 힘에서 어떻게 자유로울 수 있는지 모르겠습니다. 그 두 가지는 GitHub도 제공하고요.

  21. LtWorf HN

    듣기로는 GitHub에 올라온 코드량이 작년 같은 달의 14배라고 합니다.

    대부분은 쓰레기일 게 뻔하죠.

  22. rr808 HN

    참고로 Roku는 폭스에 인수되는 중이라서, 마이크로소프트와의 도덕성 대결에서 어느 쪽도 깨끗하지 않습니다.

  23. otterley HN

    무슨 도덕성 대결이요?

  24. murillians HN

    마이크로소프트는 예전에 좌파 성향의 뉴스 채널 MSNBC(지금은 MSNOW)를 소유했는데, 폭스는 우파 뉴스 채널을 갖고 있으니까요.

  25. Grombobulous HN

    마이크로소프트는 2014년부터 MSNBC 지분을 전혀 갖고 있지 않습니다.

    최근 MSNBC가 MS NOW로 이름을 바꾼 건 NBC와의 관계가 끝났기 때문이고요.

  26. angry_octet HN

    미국인들이 MSNBC를 좌파 성향이라고 하는 게 정말 웃기네요. 오버턴 창이 오른쪽으로 너무 멀리 옮겨가서, 중도우파 기득권 쪽으로 기운 채 뉴스를 전하는 방송이 좌파 취급을 받는 겁니다.

  27. kube-system HN

    무슨 말씀인지는 알겠지만, 그건 정확하지 않습니다. MSNBC/MSNOW도 Fox News도 "한쪽으로 기운 채 보도"하는 게 아니라, 처음부터 대놓고 오피니언 저널리즘입니다. 방송의 대부분이 정치 논평이에요.

  28. pjmlp HN

    미국 관점에서는 유럽의 우파 정당들마저 사회주의자예요. 후기 자본주의가 그만큼 극단적이라는 뜻이죠.

  29. 46283737292 HN

    극단적인 건 전혀 아닙니다. 기분 상하게 했다고, 반대 의견을 냈다고 사람을 죽이는 건 당신네 좌파 기생충들이니까요.

  30. andsoitis HN

    미국 관점에서는 유럽의 우파 정당들마저 사회주의자예요. 후기 자본주의가 그만큼 극단적이라는 뜻이죠.

    미국인들이 독일의 AfD나 프랑스의 국민연합(Rassemblement National)을 좌파로 본다고요? 그건 검증을 버텨 낼 주장 같지 않은데요.

Hacker News에서 보기 ↗