Guix가 Codeberg로 옮긴 뒤 1년

 (guix.gnu.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Guix는 10년 넘게 Savannah와 이메일 기반 Debbugs로 운영하던 협업 방식을 2025년 Codeberg로 옮기며, 연간 400명 이상이 참여하는 프로젝트의 기여 진입점을 크게 바꿈
  • 전환은 2024년 12월 도입한 Guix Consensus Document 절차의 첫 실전 사례였고, GCD 002는 두 달 논의 끝에 2025년 5월 초 발효됨
  • 기존 이메일 워크플로는 Emacs, mumi, qa.guix.gnu.org 같은 도구 덕분에 숙련자에게 효율적이었지만, 900명이 응답한 설문에서는 기여자에게 장애물로 자주 지목됨
  • Codeberg 이전 뒤 작성자 수와 신규 작성자 수는 늘었지만, 2025년 6월의 일시적 피크를 빼면 뚜렷한 Codeberg 효과는 확인하기 어려움
  • 풀 리퀘스트가 매월 500개 이상 열리며 백로그가 커지고 있어, CI 공백·서명 요구·리뷰 부담을 줄이는 일이 Guix의 다음 실무 과제로 남음

이메일 기반 협업에서 Codeberg로 이동

  • Guix는 2025년 Codeberg로 소스 코드 호스팅, 이슈 추적, 풀 리퀘스트를 이전함
    • 이전에는 10년 넘게 Savannah에 코드를 호스팅함
    • 버그 보고와 패치는 이메일로 처리하고 Debbugs 인스턴스로 추적함
    • 매년 400명 이상이 코드에 기여하는 프로젝트라 전환 자체가 큰 변화였음
  • 기존 핵심 기여자들은 이메일 워크플로에 익숙했고, Emacs용 Debbugs 패키지나 고급 이메일 클라이언트로 효율적으로 일함
    • Debbugs는 수백 줄 Perl 코드와 이메일 표준·연합 구조에 기대는 반면, Forgejo 같은 웹 포지는 Go 의존성이 많은 더 큰 시스템임
  • 이메일 흐름 주변에는 이미 보조 도구도 자리 잡고 있었음
    • mumi는 Debbugs용 웹 인터페이스를 제공함
    • Quality Assurance service는 이메일 패치 시리즈를 Git 브랜치에 자동 적용하고, 해당 브랜치에서 패키지를 빌드함
  • 2025년 1월 공개된 첫 사용자·기여자 설문에는 900명 이상이 응답했고, 기여자들은 이메일 워크플로를 기여의 장애물로 자주 꼽음

GCD 002로 진행한 합의 기반 결정

  • Guix에는 결정을 내릴 “benevolent dictator”가 없었고, 2024년 12월 Guix Consensus Document process를 도입함
  • GCD 절차는 단순 투표보다 합의 형성을 목표로 함
    • 제안 작성자는 참여자들과 함께 제안을 조정해야 함
    • 참여자는 단순 반대 대신 자신의 필요와 이를 반영할 구체적 변경을 제안해야 함
    • 최종안에는 support, accept, disapprove로 입장을 표시함
  • GCD 002는 2025년 2월 Codeberg 이전 제안으로 제출됨
    • 논의는 절차상 최대 기간인 두 달 동안 진행됨
    • Guix 팀 구성원 3분의 2가 숙의에 참여함
    • 참여자 중 72%는 support, 나머지 28%는 accept를 선택함
    • disapprove는 없었고, 제안은 2025년 5월 초 발효됨
  • 오래 기여한 일부 구성원은 웹 우선으로 보이는 워크플로가 이메일보다 비효율적이라고 느꼈고, 이메일 기반 인프라 일부를 포기하는 점도 꺼림
  • 더 넓은 커뮤니티와 접점이 생기고 개발자 경험이 개선될 가능성이 전환을 뒷받침함
  • 자유 소프트웨어 기반 포지와 비영리 단체 Codeberg e.V.가 호스팅하는 포지를 선호한 점은 큰 논쟁을 만들지 않았고, Guix의 지향과도 맞았음

단계적 전환과 예상보다 컸던 CI 공백

  • Codeberg 전환은 GCD 합의대로 점진적으로 진행됨
    • 메인 저장소는 2025년 5월 25일 이전됨
    • 이전 저장소는 현재도 미러로 남아 있음
    • 기존 이슈·패치 트래커는 2026년 1월 1일까지 유지됨
    • 이후 Codeberg 이슈와 풀 리퀘스트가 유일하게 지원되는 메커니즘이 됨
    • 과거 버그 보고와 패치는 온라인에서 접근 가능함
  • 합의 논의 과정에서 만든 계획 덕분에 전환 시 큰 문제나 예상 밖 상황은 적었음
  • Codeberg e.V. 직원과 자원봉사자의 서비스 품질은 좋았고, 간헐적 다운타임은 보통 짧고 명확히 공지됨
  • 브라우저 밖 워크플로를 선호하는 기여자에게는 Emacs 인터페이스 개선이 도움이 됨
  • 충분히 예측하지 못한 문제는 풀 리퀘스트용 지속적 통합이었음
    • qa.guix.gnu.org에서 이메일 패치를 빌드하던 기능은 Codeberg로 포팅되지 않음
    • 몇 달 동안 리뷰어가 풀 리퀘스트가 문제를 만들지 않는지 직접 확인해야 했고, 지속 가능한 상태가 아니었음
  • 2025년 9월 Cuirass 인스턴스가 pulls.ci.guix.gnu.org에 구축돼 풀 리퀘스트를 빌드하기 시작함
    • 처음에는 qa.guix.gnu.org보다 제약이 많아 임시방편으로 여겨짐
    • 현재 패키지는 단일 아키텍처용으로 빌드됨
    • 신규 기여자는 guix-cuirass-bot이 풀 리퀘스트에 남기는 성공·실패 결과를 바로 볼 수 있음

기여 흐름은 늘었지만 백로그도 커짐

  • 2024년 5월부터 2026년 5월까지 메인 브랜치 커밋 수를 기준으로 보면, Guix의 커밋 속도는 계속 “높음”과 “매우 높음” 사이에 머무름
  • 커밋 속도만으로는 변화가 잘 드러나지 않아, 월별 커밋 작성자 수·커미터 수·신규 커밋 작성자 수가 더 유용한 지표가 됨
  • 월별 작성자 수와 신규 작성자 수는 계속 증가함
    • Codeberg 이전 직후인 2025년 6월에는 작성자 수와 신규 작성자 수 모두 피크가 있었음
    • 그 외 기간의 성장은 2025–2026년 구간과 2024–2025년 구간이 비슷함
    • Guix는 계속 신규 기여자를 끌어들이지만, 뚜렷한 Codeberg 효과는 크지 않았음
  • 월별 커미터 수 증가는 작성자 수 증가보다 완만했고, 이는 커미터가 더 많은 기여를 처리하고 있음을 시사할 수 있음
  • 풀 리퀘스트 데이터는 Codeberg의 Forgejo API로 수집됨
  • 매월 500개가 넘는 풀 리퀘스트가 열리고 병합 속도도 높지만, 유입보다 약간 낮아 백로그가 계속 증가함
    • 현재 열린 풀 리퀘스트는 전체 6,459개 중 약 639개로 약 10%임
    • 비교 대상으로 든 Nixpkgs는 전체 473k개 중 열린 풀 리퀘스트가 12k개로 약 2.5%임
    • Guix의 백로그는 과도한 마찰이나 불충분한 CI 피드백 때문일 수 있음
  • Guix는 각 커밋이 승인된 커미터의 서명을 받아야 함
    • Nixpkgs를 포함한 많은 프로젝트처럼 Merge 버튼만 누르는 방식이 아님
    • 병합하는 사람이 변경을 적용하고 서명할 책임을 져야 함
    • Guix는 개발자 편의성과 사용자 보안 사이에서 소프트웨어 공급망 보안을 택함
    • 이 비용을 줄일 수 있을지는 아직 확인이 필요함

Codeberg에서 더 잘 드러나는 협업

  • Codeberg 이전 뒤 프로젝트 활동은 더 가시적이 됨
  • CI 결과가 풀 리퀘스트 안에 직접 나타나 기여자가 즉시 확인할 수 있음
  • Guix 팀은 Codeberg 팀으로 구현됨
    • 팀 범위는 CODEOWNERS 파일에 명시됨
    • 해당 범위의 담당자가 자동으로 호출됨
    • 봇은 team-python 같은 라벨을 붙여 이슈와 풀 리퀘스트를 라벨로 필터링할 수 있게 함
  • 해당 라벨이 붙은 이슈에서 팀이 알림을 받지 못하는 문제는 불편한 점으로 남아 있음
  • 이슈와 풀 리퀘스트 사이의 상호 참조, 마일스톤 같은 기능도 협업에 도움이 되는 것으로 보임

남은 인프라 과제와 Codeberg와의 관계

  • Guix 인프라는 더 많은 도움이 필요함
    • pulls.ci.guix.gnu.org의 빌드 성능을 높여야 함
    • x86이 아닌 아키텍처 빌드도 가능하면 좋음
    • Cuirass에는 여러 한계가 있고, 일부는 예정된 1.4.x 시리즈에서 해결 중임
    • pulls.ci.guix.gnu.org는 여전히 패키지 중심이며, 적절할 때 시스템 테스트도 실행할 수 있으면 좋음
  • 패키저 워크플로도 개선 여지가 있음
  • Guix는 Codeberg 서버에 과도한 부하를 만들지 않고 저장소 사용량도 주시해야 함
    • Codeberg 서버에 과도한 부하를 준 사례가 있었음
    • Guix의 단일 포크가 Codeberg의 새 사용자별 750MiB 할당량을 넘을 수 있음
  • 해결책으로 신규 기여자가 AGit workflow를 사용해 풀 리퀘스트를 만들도록 요구하는 방안이 있음
    • AGit은 Guix 기여자 사이에서 이미 인기가 있음
    • 다만 익숙한 일반 풀 리퀘스트 워크플로보다 덜 친숙해 “다운그레이드”로 보는 사람도 있음
    • Gentoo 사례처럼 “AGit fork” 아이콘을 추가하면 발견 가능성을 높일 수 있음
  • Guix Foundation은 감사와 지원의 표시로 Codeberg e.V.의 지원 회원이 되기로 투표함
  • Forgejo와 이를 Guix에서 설정하는 서비스를 추가하는 풀 리퀘스트가 제출됨
    • 선언적 구성과 재현 가능한 포지 배포가 Guix 안에서 가능해지는 방향임

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • Codeberg 이전과 관련된 실제 프로젝트 지표를 보니 아주 흥미로움. 개인적으로는 GitHub를 떠나야 할 이유가 너무 많아서 Codeberg가 새로운 GitHub가 되길 바라지만, 나는 자체 Forgejo 서버로 옮겼고 지금은 모든 저장소의 백업 대상으로 Codeberg를 쓰고 있음

    • 좋은 뜻으로 한 말인 건 알지만, 모든 것이 Codeberg로 몰리기보다는 여러 개의 독립 포지가 ForgeFed로 서로 통신하는 쪽이 더 낫다고 봄
      새로운 오픈소스 중심 허브가 또 필요하진 않음
    • 현재 Forgejo가 이런 역할을 감당할 만큼 충분히 확장된다고 보진 않음. Codeberg 쪽이 할 수 있는 만큼 하고 있고 나아지길 바라지만, 시간이 걸릴 것 같음
    • 개인적으로 하는 작업은 결국 전부 Fossil로 옮겼고, 다른 사람에게 공개하고 싶은 것들은 자체 Fossil 서버를 세웠음
      지금까지 아주 좋았고 git보다 확실히 선호함. 요즘 기준으로 그 허들이 아주 높은 건 아니지만

  • Codeberg를 쓰기 시작하고 나서 정말 짜증났던 건, git 연동을 제대로 지원하는 도구가 거의 없고 사실상 GitHub / GitLab 전용인 경우가 대부분이라는 점임

    • magit forge 쓰는 입장에서는 눈물 남

  • 예전 이슈·패치 추적기를 2026년 1월 1일까지 유지하다가 그 뒤에는 Codeberg 이슈와 풀 리퀘스트만 지원하게 했다는 부분이 이해되지 않음
    기여자 상당수가 새 흐름을 싫어한다면 왜 강제로 바꾸는지 모르겠고, 여러 흐름을 허용하는 데 숨은 비용이 있는지도 궁금함. 왜 모두에게 같은 방식을 강제해야 하는지 의문임
    사소한 트집이지만 Codeberg에 유급 직원이 여러 명 있는 것 같지는 않았고, 내가 알기로는 한 명뿐이었음. 수정: 작년 12월에 두 번째 직원을 추가했다고 함

답변달기