데비안 문제 (1) - unstable,
데비안 문제 (2) - 새 패키지 큐와 FTP 마스터 에 이어..
데비안 메인테이너가 된다는 건 무엇을 말하는 걸까? free software project에서 보기 드문
복잡한 테스트를 거쳐서 "DD"가 되면 "@debian.org" 메일 주소를 가지고 있으며, 데비안 머신에 계정을 이용할 수 있고, debian-private 메일링 리스트에서 공개되지 않은 플레임^H^H^H메세지를 읽을 수 있고 (3년 후 공개된다),
각종 투표에 한 표를 행사할 수 있다. 하지만 '메인테이너'란 말 그대로 패키지의 메인테인 권한을 갖는 게 가장 큰 부분이다.
데비안 프로젝트가 이렇게 발전한 데는, 배포판을 다루고 있다는 점과 패키지 시스템이 잘 만들어져 있다는 점이 큰 몫을 했다. 각각을 패키지 단위로 쪼개고 각 패키지를 한 명의 메인테이너에게 배정할 수 있기 때문에 (
패키지의 Maintainer: 필드가 있다는 점) 데비안의 scalability에 큰 영향을 미쳤다. 세계 어디에 1000명이나 되는 개발자가 한 가지 목표를 위해 참여하고 있는 OSS 프로젝트가 있을까? 물론 패키지 사이에 복잡한 상호관계가 (의존, 충돌 등등) 있긴 하지만 다른 사람이 어떤 작업을 하고 있는지 거의 몰라도 패키지를 만드는 데는 문제가 없는 경우가 많다. 그래서 보면 패키지 한 두개만을 담당하면서 메일링 리스트도 거의 읽지 않고 자기만의 세계에 빠져서 그 패키지만 업데이트하는 걸로 메인테이너를 유지하는 사람들도 꽤 있다.
이 데비안의 scalability와 패키지간의 독립성이 갖는 장점이 조금씩 상처를 받게 된 건 최근인 것 같다. 먼저 사람 수가 몇배가 넘게 늘었고, 리눅스에서 돌아가는 프로그램들이 의존성을 두려워하지 않는다. 과거에는 그야말로 라이브러리라고는 libc에만 의존하는 프로그램이 상당수였고, 기껏해야 bdb를 사용하고 X 프로그램이래봐야 X11, 조금 복잡하면 Xt/Xaw를 사용하는 정도로 의존성을 늘이는 데 주저하는 경향이 있었지만 요즘은 그렇지 않다. 서슴치 않고 라이브러리를 이용한다. 이제는 메인테이너들 사이에 긴밀한 협조가 필요하다.
그런데 종종 메인테이너가 시간이 없거나, 실력이 부족하거나, 아니면 성격이 괴팍하다고 밖에 볼 수 없는 이유로 협조가 제대로 되지 않는 일이 발생한다. 오랜 시간동안 메인테이너가 응답하지 않아서 버그 수정이 제대로 되지 않는 일이야 흔한 일이고, 버그를 수정하지 못하는 경우도 많다. 이런 상황이 벌어졌을 때 나름대로 도움을 요청하거나 "NMU 해 버려"라고 하는 아량을 가졌다면 괜찮은데 그것도 아니고 질질 끄는 상태가 되기도 한다. 또 정말 "나쁜" 메인테이너는 "그게 왜 버그냐. 건드리지 마"식으로 일관하는 사람도 분명 있다. 사람 사는 곳이야 어디나 괴팍한 사람도 있게 마련이지만, 그런 일이 발생했을 때 특정 패키지, 특히 중요한 패키지 몇개가 다른 패키지를 따라가지 못하는 상황에 빠지면 난감하기 짝이 없다. (예를 들어 보면, 데비안의 GDM 패키지는 다른 gnome 패키지처럼 유기적으로 움직이지 않는다.)
이러한 강력한 메인테이너쉽은 제도적인 근거도 있다.
constitution 3.1에 규정된 바에 따르면 "An Individual Developer may make any technical or nontechnical decision with regard to their own work". 물론 이 권한을 override할 수 있는 권한이
테크니컬 커미티에게 있다: "The Technical Committee may ask a Developer to take a
particular technical course of action even if the Developer does
not wish to; this requires a 3:1 majority. For example, the
Committee may determine that a complaint made by the submitter of a
bug is justified and that the submitter's proposed solution should
be implemented." 하지만 커미티의 이 권한 행사는 실제적으로 이루어지기 힘들다. 3:1 의견이 나오기도 쉽지 않은 일이지만, constitution 규정이 만들어진 이후로 수십배로 커진 데비안의 규모에 따라 그만큼 늘어난 각종 갈등에 대응하기도 어렵다. 실제로 지금까지 커미티가 결정한 사항도 라이센스 문제이거나,
debian-policy의 명백한 위반처럼 사안이 명확하고 어떻게 결정해야 할 지도 명확한 것 외에는 개발자의 권한을 오버라이드하는 경우는 찾아볼 수 없다. 정답이 명확하지 않은 각종 정책적인 결정사항에 대해서는 그냥 패키지 담당 메인테이너에 따라 결정될 가능성이 99.99%이다.
아마도 우분투처럼 모든 패키지를 소스컨트롤하고, 모든 개발자에게 쓰기 권한을 주는 일은 데비안에서는 일어나지 않을 것 같다. 하지만 어떤 식으로든 메인테이너의 "패키지 소유"는 좀 약화시킬 필요가 있다. 실제로 패키지에 Uploaders: 필드가 구현되서 여러명이 권한을 가지는
Co-maintenance 방법도 있고 (실제로 잘 이용하고 있음), 스스로 권한을 축소시키는
Low Threshold NMU 방법도 있었다. 링크는 잊어버렸지만, 일단 etch 릴리스한 다음에 개인의 권한에 대해 constitution 개정을 시도하겠다는 제안도 있었다. (실현은 어려울 것 같지만)
일단 나도 이러한 데비안의 "지나친 메인테이너쉽" 문제를 개선하는데 조금이라도 기여하기 위해.. 메인테인하고 있는 모든 패키지를
alioth 등 데비안의 소스컨트롤에 등록할 예정이다. 그리고 가능하다면 원하는 모든 사람들에게 커미트 권한과 업로드 권한을 부여한다. 이 정도가 현재 할 수 있는 일이다. (내 하드 디스크에서 계속 소스 관리하기가 피곤해서이기도 하고...)
![[frdm] Support SFLC](http://www.softwarefreedom.org/img/support-sflc.png "Software Freedom Law Center"){kind=small}
