▲

포지에서 무엇을 원하시나요?

 (lobste.rs)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • Jujutsu와 다른 버전 관리 시스템 사용자, 주요 포지가 충분히 다루지 않는 순수 Git 워크플로가 논의 대상임
  • 핵심 관심사는 SPA/JS나 서버 렌더링 HTML 같은 구현 방식이 아니라, 저장소가 버전 관리 기능을 어떻게 표현하고 동작시키는지임
  • Tangled, GitHub의 stacked PRs, forgefed 같은 아이디어는 있지만, 설계에 대한 사용자 의견이 모이는 공간은 찾기 어려움
  • stacked PR/MR과 대안적 협업 모델도 포함되며, 기존 포지를 넘어선 버전 관리 경험이 주요 쟁점임
  • 태그, 커밋, 트리, blob 같은 저장소 객체 표시는 포지마다 대체로 비슷하고, 사소한 포맷 차이 외의 논의는 거의 없음

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Lobste.rs 의견들

  • 코드 리뷰 댓글이 저장소 자체의 일부가 아니면 절대 못 씀
    메일링 리스트, 데이터베이스 사일로, HEAD 커밋 해시로 고정되지 않는 별도 계층에 귀중한 과거 맥락을 저장하는 건 근본적으로 GitHub와 같은 종류의 위험임
    Fossil은 이 방향으로 일부 가 있지만 이슈만 다루고 코드 리뷰는 아직 이메일 패치 방식임: https://fossil-scm.org/home/doc/tip/www/contribute.wiki
    일단 이 정보가 버전 관리 시스템 안에 들어오면 그 위에 멋진 웹 UI, RSS 피드, 메일링 리스트를 얹을 수 있음
    두 번째 기능은 머지 큐 내장 지원임. 사소하지 않은 프로젝트에서는 개별 기여자가 main 브랜치에 직접 푸시하면 안 되고, 특정 커밋을 “통합 준비됨”으로 표시하면 봇이 제안된 변경을 직렬화하고 CI를 최적으로 스케줄링하며 main을 검증된 해시로 전진시켜야 함
    세 번째 기능은 Windows, macOS 등 이기종 환경에서 격리된 작업 실행기로서의 CI임: https://gregoryszorc.com/blog/2021/…

    • 추가로 필요한 건 스팸과 악용을 다루는 명확한 접근임
      누구나 계정을 만들고 이슈를 열 수 있어야 하지만 스팸은 없어야 함
      지금 GitHub는 이걸 꽤 잘 해내고 있음. 가끔 스팸을 보지만 악용 신고 후 매우 빠르게 제거됨. 뒤에는 자동화 더미와 실제 사람의 분류 팀이 있을 것 같음
    • 지금 코드 리뷰 댓글을 저장소 안에 보관하는 도구가 있나?
      취미 프로젝트용 “포지”로 Fossil을 살펴보고 있는데, 외부 기여자가 많을 것 같진 않아서 코드 리뷰는 있으면 좋은 정도임
    • 이슈와 풀 리퀘스트를 실제 저장소 안에 넣고 싶지는 않음
      대신 동기화하고, 보내고, 마음대로 질의할 수 있는 SQLite DB를 원함
      git-pr에서 다음 큰 리팩터링으로 작업하려는 건 SQLite DB를 SSH 명령으로 노출하는 것임: ssh pr.pico.sh sql
      SQLite는 필요한 만큼 어디에나 있고 범용적이지만, 포지의 일부로 다루는 사용성이 빠져 있음
    • 코드 리뷰 댓글을 저장소 자체에 넣는 건 정말 흥미로운 아이디어임
      다만 강제 푸시나 스쿼시 머지처럼 기록이 다시 쓰이는 경우에는 댓글이 이후 어디에 “고정”되어 사용자가 찾을 수 있을지 궁금함
      GitHub에서는 그 기준이 Pull Request라서 포함된 커밋이 바뀌어도 토론을 볼 수 있음
      이 시스템도 저장소 안에 저장되는 별도의 PR 개념을 두는 건지, 아니면 더 긴밀히 통합된 무언가를 기대하는 건지 궁금함
    • 이걸 커밋 해시와 어떻게 합칠지, 그리고 저장소 메타데이터가 많이 출렁이는 문제를 어떻게 볼지 잘 모르겠음
      그래도 jj를 잘 쓰고 있으니 실제로는 큰 문제가 아닐 수도 있음

  • Gerrit와 이메일을 둘 다 쓰다 보면 풀 리퀘스트 모델이 가장 지배적인 게 아쉬움
    특히 관리자가 스타일 정도의 사소한 지적을 댓글로 남기기보다 그냥 고치면 될 때 더 그렇고, 기여자는 그런 스타일에 크게 신경 쓰지 않을 가능성이 큼
    그런데 더 아쉬운 건 요즘 점점 많이 쓰고 있는 Darcs나 Pijul에 대해 이메일이 아닌 워크플로가 전혀 없다는 점임
    이메일 대신 XMPP 기반이면 좋겠음. 작업 중인 패치에 대해 실시간 분산 협업을 할 수 있고, 패치셋 하나당 MUC 하나를 두는 식도 가능함
    MUC는 음성 채팅처럼 열리고, 역할, 첨부파일, 반응, 검색, MAM, 조정, 완료 후 tombstoning 같은 기능도 이미 XEP로 정의돼 있음
    구독에는 PubSub를 쓰고 CI 전송 수단으로도 활용할 수 있음
    실용적이려면 전용 클라이언트가 필요하겠지만, 많은 기능은 아무 클라이언트에서도 그냥 동작할 수 있음
    현실적으로는 오래된 연합 기술이 예상 밖으로 확장되는 모습에 최근 끌리고 있는 것에 가까울지도 모름

  • 코드 리뷰와 승인이 병목임
    코드 제출자와의 커뮤니케이션은 지연이 매우 크고, 몇 주나 몇 달이 걸리기도 하며, 신뢰성도 낮음. PR을 올리고 사라지는 사람도 있음
    왕복 상호작용을 전제로 하는 GitHub 모델은 여기서 완전히 무너짐
    리뷰 중에 코드를 직접 수정하고 git-absorb처럼 커밋을 amend할 수 있으면 좋겠음. 오타 같은 사소한 문제로 제출자와 왕복하는 건 시간 낭비이고, GitHub의 Edit Suggestion 해킹은 번거롭고 기록을 어지럽힘
    같은 코드를 다시 리뷰하고 싶지 않음. 한 함수나 한 커밋에만 문제가 있으면 나머지는 미리 승인해 두고, 제출자가 강제 푸시로 고쳤을 때 다시 볼 필요가 없어야 함
    PR 일부만 머지하거나, PR을 닫지 않고 커밋을 제거할 수 있으면 좋겠음. 기능 자체는 원치 않아도 그 기반 작업은 유지할 가치가 있을 때가 있고, 반대로 불필요한 “정리”나 포매팅이 끼어드는 경우도 있음
    원 제출자가 대응하지 않을 때 다른 사람들이 PR에 협업하고 다듬고 문제를 해결할 수 있어야 함. GitHub 모델에서도 이론상 가능하지만 실제로는 다른 PR에 대한 PR을 만드는 숨은 기술에 가깝고, 그 코드와 알림이 대상 프로젝트에는 보이지 않음. 사람들이 포크해서 수정 PR을 올리면 혼란과 머지 충돌만 생김
    제출된 코드가 그럭저럭 괜찮지만 약간의 개선을 원할 때가 많음. 제출자 입장에서는 좋은 마무리 작업을 모두 끝낼 때까지 PR이 인질로 잡힌 느낌이라 답답하고, 관리자 입장에서는 바로 머지했다가 제출자가 사라져 후속 개선이 영영 안 될 위험이 있음. 나중에 정리해야 할 의무를 달고 임시로 머지하는 방법이 있으면 좋겠음. 예를 들어 스테이징 브랜치에는 머지하되 FIXME가 해결되기 전까지 안정 브랜치로 cherry-pick하지 않는 식일 수 있음
    인기 오픈소스 프로젝트에는 프로젝트를 앞으로 나아가게 할 코드 리뷰와 승인을 할 수 있는 사람이 1명뿐인데, 기여하고 서로 돕고 싶어 하는 사람은 500명인 상황이 생김. GitHub 모델은 이 초과 기여자 역량을 전혀 활용하지 못함. 협업을 돕는 대신 위기, 혼란, 성난 집단 압박으로 바꿔버림. 단일 관리자에게 막히지 않고 다른 사람들이 실험하고 프로젝트를 진전시킬 수 있도록 포크 관리와 포크 간 코드 복사를 더 잘 지원해야 하며, 관리자가 여러 포크에서 인기 있고 작동이 검증된 변경을 쉽게 고를 수 있어야 함

    • PR 제출자가 막는 설정을 켜지 않았다면, 저장소 소유자는 PR 브랜치에 직접 푸시할 수 있음
      조직에서는 이 설정이 기본값이었던 것 같지만, 어쨌든 이 경우 강제 푸시로 직접 깔끔하게 수정할 수 있음
      왕복할 가치가 없는 작은 수정에는 항상 그렇게 함
    • 제출자가 느리다고 생각한다면 관리자 응답을 기다릴 때를 겪어보면 됨
      보통 몇 달이나 몇 년 단위로 측정되는 느낌임
      가끔 내가 관리자일 때도 있고, 나 역시 항상 이것보다 빠르지는 않다고 인정함
    • 웹 리뷰 인터페이스가 코드를 직접 수정할 수 없더라도 IDE에 훨씬 가까워지면 좋겠음
      정의로 이동, 시그니처나 문서 주석을 보여주는 hover 팝업 같은 기능을 원함
      브랜치를 체크아웃해서 원하는 편집기에서 리뷰하면 가능하지만, 말했듯 리뷰가 병목임
      여러 PR을 리뷰할 때마다 브랜치를 이리저리 바꾸는 추가 작업이 너무 큼

  • 단일 사용자, 또는 적어도 단일 사용자 모드가 필요함
    왜 https://code.chrismorgan.example/chrismorgan/repository-name 같은 URL을 감수해야 하나? https://code.chrismorgan.example/repository-name이면 되는데
    진심으로 하는 말이고, https://github.com/go-gitea/gitea/issues/11028 을 보면 이런 걸 원하는 사람이 분명히 많음
    Fediverse 계정이 없는 세 가지 주요 이유 중 하나도 주소가 끔찍하다는 점임
    주 이메일 주소처럼 @‌me@‌chrismorgan.info를 쓰면 어떤 사람들에게는 그냥 “@‌me”로 보일 수 있을 것 같고, @‌chrismorgan@‌chrismorgan.info는 보기만 해도 싫음
    이 부분은 ATProto가 아주 잘했음. 도메인 이름은 핸들로 훌륭하고, 여러 사용자가 필요하면 하위 도메인으로 충분함
    공유 포지에서도 하위 도메인을 쓰면 논리적으로 단일 사용자처럼 만들 수 있을 듯함. github.com/chris-morgan 대신 chris-morgan.github.com을 상상해 보면 재미있을 수 있음
    미학은 중요함
    단일 사용자로 가는 건 더 큰 결과도 낳음. Mastodon 같은 걸 단일 사용자용으로 줄여도 여전히 무겁지만, 처음부터 단일 사용자용으로 설계된 Fediverse 프로젝트는 그 용도에 더 잘 맞음
    내 서버를 직접 운영하되 로컬 사용자는 나 하나만이고, 다른 사용자가 있을 가능성 때문에 타협하고 싶지 않음
    이것은 포지들이 쓰는 git 같은 일반 사용자명이 아니라, 일반 SSH처럼 chris라는 사용자명으로 푸시하고 싶다는 뜻이기도 함
    흔히 이해하는 의미의 포지라면 연합은 당연히 필요함. 하지만 각자의 “홈 서버”에는 로컬 사용자가 하나만 있으면 좋겠음

    • 이메일 주소는 어떻게 쓰고 있나?
      자기 이름 도메인을 쓰면 거기서도 비슷한 문제가 있지 않나?

  • 이 주제에 대한 Nesbitt’s article이 마음에 들었음
    특히 다운스트림과의 더 나은 커뮤니케이션이 좋았음

  • 선택한 편집기에서 로컬 코드 리뷰를 할 수 있어야 함
    바꿀 수 없는 글꼴과 끔찍한 구문 강조를 쓰는 둔한 웹 인터페이스에 강제로 갇히고 싶지 않음
    현재는 Neovim용 커스텀 도구로 나란히 비교(diff)를 보기 좋게 만들고, git pr 명령으로 풀 리퀘스트를 체크아웃하는 워크플로를 씀
    하지만 리뷰 댓글을 남기는 것처럼 조금만 더 원해도, 5년 뒤에도 유지될 가능성이 낮은 누군가의 CLI나 GitHub API와 통신하는 도구에 의존하게 됨
    더 정확히는 단지 로컬에서 “실행 가능”한 도구가 아니라, 편집기 등과 로컬에서 통합되는 로컬 우선 도구가 더 필요함
    이게 1급 기능이 되기 어려운 이유는 필요한 노력이 크기 때문임. 하나의 웹 인터페이스는 사용자를 강제함으로써 모든 플랫폼과 편집 환경에서 “동작”하지만, 더 긴밀한 통합은 편집기와 환경이 N개면 통합도 N개가 필요함
    CI도 마찬가지임. 커밋을 브랜치에 푸시하고 15분 동안 잡히길 기다리지 않고, Linux, FreeBSD, macOS에서 테스트를 쉽게 돌리고 싶음
    run-remotely some-command --on freebsd,linux,mac 같은 형태면 됨
    기본적으로 로컬 우선이면서 비중앙화된 CI 시스템이고, 동시에 모든 코드가 머지 전 같은 “승인된” 시스템을 통과하도록 보장하는 단일 진실 공급원으로서의 중앙 시스템도 지원해야 함
    이것은 단순한 ssh user@host command ...를 넘어섬. 소스 코드 복사, 캐싱, 필요한 의존성 설치 등을 포함해 매번 같은 신뢰 가능한 상태를 얻어야 하기 때문임

    • 요즘 비슷한 생각을 하고 있음
      다만 이건 포지 기능은 아니라고 봄. 특정 포지 없이도 쓸 수 있고, 어떤 포지든 호출할 수 있는 작업 실행기 도구로 제공돼야 함
      약간 “드라이버 기반”이어야 한다고 생각함. 같은 작업을 완전히 로컬에서 실행하거나, 원격 시스템으로 보내 작업을 띄우게 할 수 있음. 그 작업은 가상 머신일 수도, 컨테이너일 수도, 직접 실행일 수도 있음

  • Git이 아닌 버전 관리 시스템도 지원해야 함
    이슈, 위키 등을 편한 형식으로 가져오고 내보낼 수 있어야 특정 시스템에 갇히지 않음
    셀프 호스팅도 쉬워야 함

    • Git이 아닌 버전 관리 시스템을 모두 지원하려면 꽤 큰 목록임
      실제로 중요한 일부 범위가 있을 것 같음
      형제 댓글의 Heptapod는 Mercurial용이고, sourcehut, also도 있음
      Fossil은 자체 포지가 있고, SourceForge의 Apache 버전인 allura는 Subversion을 제공함

  • CI 계층에 Bazel스러운 무언가를 제공하는 포지가 있으면 좋겠음
    “CI에서 Bazel을 실행할 수 있다”가 아니라, 사람들이 의존성을 갖춘 좋은 테스트와 빌드 모음을 작성하도록 자연스럽게 유도해서 별 이유 없이 CI 시간을 태우지 않게 하는 형태임
    관련해서 “프로젝트 하나 = 저장소 하나” 모델이 많은 문제를 만들어냈다고 봄
    더 나은 모노레포 지원이라고 표현할 수도 있지만, 기본적으로 CI와 이슈 같은 것들이 “이 디렉터리의 최상위”보다 더 큰 범위로 스코프될 수 있어야 함
    많은 프로젝트가 포지나 CI 이유로 저장소를 쪼개고, 그 상태로 작업하는 건 재미없음
    리뷰어로서 인라인 패치 분할도 원함
    좋다고 생각하는 부분을 선택하고 그 부분만 승인해서 만족스러운 부분을 통합할 수 있게 해 달라는 것임
    스택형 PR은 여전히 너무 무거운 개념이라고 봄
    누군가 “4개 파일을 바꾸고 싶고 이걸 하나의 PR로 본다”고 하면, 리뷰어는 “좋아, 이 2개 파일은 괜찮다”고 말하고 그 변경 묶음을 PR의 별도 부분으로 만들거나, 심지어 그 조각만 별도 커밋으로 머지할 수 있어야 함
    현재의 스택형 PR도 여전히 PR을 원자 단위로 취급함. 대부분의 시스템에서 PR은 너무 무겁다고 느낌

    • 단순한 관찰이지만, JetBrains는 오랫동안 hunk 단위 커밋 허용에 반대했음
      이유는 “그건 파일의 부분집합이므로 컴파일되는지 알 수 없다”는 것이었음
      그 입장에 전혀 동의하진 않지만, 웹 뷰에서 그런 일을 하려면 상당히 조심해야 하므로 이 댓글을 보고 그 생각이 났음
      물론 위쪽 댓글처럼 저장소 소유자라면 선호하는 버전으로 브랜치에 강제 푸시하면 된다는 얘기는 일단 제쳐두고

  • 무노력 CI/CD 설정이 필요함
    make build, make test, make upload만 있으면 됨
    나머지는 makefile에 두게 해주면, 거기서 더 나은 빌드 시스템으로 이어갈 수 있음
    아이디어에서 게시된 실행 산출물까지 2분 이내에 가고 싶음

    • 왜 굳이 버전도 여러 가지인 Make를 써야 하나?
      대부분의 CI/CD 시스템이 하듯 잘 알려진 위치의 설정 파일을 쓰는 대신, 잘 알려진 디렉터리에 잘 알려진 이름의 셸 스크립트 세 개를 두면 됨
      보너스로 Windows 빌드가 필요하면 .bat 파일로 만들 수도 있음
    • 이 방식은 좋지만 아마 의존성 설치 방법이 필요할 것임
      운영체제에 따라 달라질 수 있고, makefile 안에 넣고 싶지 않을 수도 있음
    • 직접 격리를 가져올 수 있는 로컬 우선 CI를 만들고 있음: https://ci.pico.sh
      장점은 모든 작업이 zmx 아래의 자체 pty에서 실행된다는 것임
      실패한 작업에 attach해서 위쪽 화살표와 Enter로 재실행할 수 있음

  • 품질 좋은 데이터가 게시되도록 가드레일이 있는 보안 권고를 원함
    모든 프로젝트가 의미 있는 데이터를 게시할 수 있도록 커밋 중심 생태계가 필요하고, 원하는 프로젝트는 직접 CVE를 발행할 수 있는 통합도 있어야 함

답변달기