Git 저장소 안에 이슈 데이터를 넣는 분산 버그 트래커 git-bug, 저자는 로드맵 공개하며 전업 고려

GitHub 이슈 트래커를 git 자체에 내장한 것 같아서 흥미롭네. 대체 GitHub이 git에 집어넣은 게 얼마나 많은 거야 ㅋㅋ

fossil-scm에서 본 듯한 접근인데, 꽤 좋아 보임.

왜 이 이름에 이 기능인 프로젝트가 전에 없었나 싶다. 근데 'git bug'가 기능 요청까지 추_TRACK하기엔 좀 어색해서 이름이 아쉬움. 버그만 아주 잘 추적하고 기능 로드맵은 다른 곳에 두는 게 그거대로 자연스러울 수도?

로고가 무당벌레라 결국 다 맞아떨어짐 ㅋㅋ

Bugzilla가 30년 가까이 'bug'로 기능을 추적해 왔는데 아무 문제 없었음. 명칭이 그렇게 제약이 되는 것 같지도 않다.

나중에 풀 리퀘스트까지 넓힐 생각이라 CLI 명령 자리도 비워둬야 하는데, 'git bug bug' 옆에 'git bug pr'이 놓이면 좀 우습겠더라. 이름 짓기 어렵다 ㅠ

커널 레시피 컨퍼런스에서 이번 주에 Konstantin Ryabitsev가 b4와 cgit의 git-bug 지원을 시연했음. b4 문서랑 kernel.org cgit 포크 링크도 있음. cgit에 업스트림 보낸 거임?

몇 달 전에 Epiq이라는 비슷한 게 올라왔었는데, 십수 년 전 분산 버그 트래커 붐 때 겪은 구조적 문제들을 기억하는 글이 있음. 이번 건에도 해당하는지 확인해 볼 만함.

rotsit이라는 걸 내가 만들었는데 그 목록 중 첫 항목 빼고는 다 다루고 있음. 브랜치에 이슈를 묶는 건 그 브랜치에서 해결 상태를 확인하게 하려는 게 목적임. 브랜치와 독립적으로 저장하면 어느 브랜치에서 깨졌는지 메타데이터를 또 넣어야 해서.

분산 버그 트래커는 꽤 많이 나왔는데, 막상 제대로 돌아가는 건 없었음. Matej Čepl 씨 글이 10년 넘었는데 상황이 별로 안 나아졌다고 함.

저자인데 관심 고마움. 단기 로드맵은 웹 UI가 GitHub OAuth 같은 외부 인증을 받게 하거나 git 원격 엔드포인트를 노출하는 쪽임. 신원은 블루스키의 did:plc에 뿌리를 두는 방식으로 재작업해서 저장소 간 공유가 자연스럽게 되게 하고, 풀 리퀘스트와 CI까지 넓혀서 자체 호스팅 가능한 로컬 우선 포지를 만들 생각. 전업으로 할지 진지하게 고민 중이라 조언 환영함.

GitSocial 만드는 사람인데, 이게 인상 깊다. 의견 좀 들어보고 싶음.

전업 조건으로는 엔터프라이즈 티어에 보장 지원을 붙이는 방법이 있는데, 실제론 수익화가 엄청 어려울 듯. 개발자한테 팔지 말고 상사한테 팔라는 말이 있듯이 고객이 굳이 돈을 안 쓸 타입이라. 기부나 크리에이터 중심 모델이 오히려 맞을 수 있음.

깃 메타데이터로 변경을 추적하는 다른 시스템이랑 같이 쓸 생각은? 예를 들어 Gerrit은 코드 리뷰와 체인지 히스토리도 전부 git에 넣는데, 전부 한 저장소에 모을 수 있으면 꽤 땡김.

코드 리뷰도 순수 git으로 되는 google/git-appraise가 있고, 나는 git bug를 쓰다가 티켓을 마크다운 에디터로 못 고치는 게 아쉬워서 ticketry를 직접 만듦.

티켓은 접근성이 생명인데 이런 방식은 걸림돌이 너무 많아 보임. 출입 장벽이 1이라도 있으면 사람들이 안 넣고, 사실상 중앙집중형이 진짜 이상적 케이스라고 봄.

동의함. 그래서 웹 UI가 곧 OAuth/OIDC를 받게 해서 일반 버그 트래커 경험을 그대로 호스팅·복제 가능하게 할 예정. 그러면서도 기존 포지가 못 하는 워크플로는 유지되는 게, 분산 트래커가 실전에서 통하게 하는 핵심이 될 듯.

'임베디드'라는 표현이 좀 그렇다는 생각임. git-bug는 $PATH에서 찾아지는 git 명령 규칙을 따르는 거라, 플러그인 방식으로 직접 적재된 걸 임베디드라 보기는 어렵다. 'Git에 완전히 통합됐다' 정도가 덜 혼란스러움.