Lancaster Consensus

2008년 오슬로에서 개최된 첫번째 Perl QA Hackathon 에서는, Perl 의 품질관리와 툴체인에 관한 모듈의 저자, 메인테이너, 뜻 있는 사람들이 모여서, 몇가지 표준과 관행에 대해서 합의를 이뤘습니다. 이 때 발표된 합의는 Oslo Consensus 라는 이름으로 알려지게 되었습니다.

그로부터 5년인 지난 2013년, Perl QA Hackathon 에서는 5년전과 마찬가지로 여러 전문가들이 모여, 새로이 통일된 견해가 필요해진 몇몇 문제들에 대해서 논의하였습니다.

아래의 결정사항들은 이후의 방침을 나타내는 것이며, 경우에 따라서 구현에 걸리는 시간은 실제 작업을 희망하는 이들의 사정이나 희망자들이 나타날 지의 여하에 달려 있습니다.

툴 체인과 테스트

최소지원 Perl 버젼

앞으로 Perl 툴체인은 2003년 9월에 릴리즈된 Perl 5.8.1 을 대상으로 하게 됩니다. 이에따라서, 툴체인 모듈은 PerlIO나, Perl 5.8 에서 개선된 Unicode 지원을 안심하고 이용할 수 있게 됩니다.

또한, 5.8의 초기의 몇몇 릴리즈에서는 Unicode 관련 버그수정이 상당부분 이뤄졌기 때문에, 툴체인의 유지보수는 추후 최소버젼을 5.8.4 로 올리는 권리를 가지는 것으로 합니다(이는 Solaris 10 에 기본포함된 버젼).

Pure Perl 로 빌드하도록 지정

배포판에 따라서는 XS 버젼과 Pure Perl 버젼을 준비하고, Makefile.PL 이나 Build.PL 을 실행하는 단계에서 어느 것을 선택할 수 있도록 하는 것이 있습니다. 현시점에서는 이 배포판들은 각각의 독자적인 방법으로 유저에게 선택하게 하고 있기 때문에, CPAN 클라이언트나 그 외의 빌트 툴 쪽에서는 이 선택을 자동화시키고 싶은 유저의 욕구를 충족시켜줄 수 없는 상황이었습니다.

앞으로, Makefile.PL 과 Build.PL 의 스펙에서는, 아래처럼 Pure Perl 버젼만 빌드되도록 커맨드라인 옵션이 포함되게 됩니다.

PUREPERL_ONLY=1 (Makefile.PL의 경우)
--pureperl-only (Build.PL의 경우)

이 옵션들은 다른 커맨드라인처럼, PERL_MM_OPT 또는 PERL_MB_OPT 같은 환경변수로 설정해도 됩니다.

배포판 저자는 이 옵션이 존재하는 경우, 설치할 모듈이 (직접, 또는 Inline 모듈을 통해서) XS 를 불러오거나 플랫폼 고유의 코드를 동적으로 생성하지 않아도 되도록 보증해야 합니다. 설치된 파일은 아키텍쳐가 달라도 Perl 버젼이 같다면(어플리케이션을 fatpack 한다든가) 다른 머신으로 복사해도 제대로 동작해야 합니다. 이 조건을 만족시킬 수 없는 경우 Makefile.PL 이나 Build.PL 은 에러로 종료되어야 합니다.

테스트가 어떤 상황에서 실행되었는가(컨텍스트)를 지정하기 위한 환경변수

Oslo Consensus 에서는 테스트할 때의 컨텍스트를 알리는 것으로 AUTOMATED_TESTING 과 RELEASE_TESTING 이라는 두가지 환경변수를 정의했지만, 그 중 AUTOMATED_TESTING 에 대해서는 쉽게 혼동되었습니다. 경우에 따라서는 “유저와의 상호동작을 하지 않는다” 라는 의미로 사용되거나 “시간이 걸리는 테스트를 실행한다” 라는 의미로 사용되어 왔기 때문입니다.

Lancaster 에서는 Dist::Zilla 와 같은 툴이 AUTHOR_TESTING 과 RELEASE_TESTING 을 지금 어떻게 구별하고 있는 지에 대해서도 (짧지만) 논의하였습니다.

배포판의 저자는 앞으로 아래와 같은 내용들을 따라야 합니다.

AUTOMATED_TESTING: 이 환경변수가 참일 경우, 테스트를 실행하고 있는 것은 어떤 자동 테스트 구조이고, 모듈을 설치하고 있지 않다는 것을 의미합니다. CPAN Smoker 는 이 환경변수를 참으로 해야합니다. 또, CPAN 클라이언트는 이 환경변수를 설정해서는 안됩니다.
NONINTERACTIVE_TESTING: 이 환경변수가 참일 경우, 테스트 시에 유저와의 상호동작을 해서는 안됩니다. 테스트의 출력이 표시되지 않거나, 프롬프트에 응답이 돌아오지 않습니다.
EXTENDED_TESTING: 이 환경변수가 참일 경우, 테스트를 실행하고 있는 유저 또는 프로세스는, 끝날 때까지는 불필요하게 시간이 걸리거나 리소스를 필요로하는 옵션으로 테스트를 실행할 계획이 있다 라는 것을 의미합니다. 단, 실행 시의 기능을 테스트하는 것만을 포함해야 합니다.
RELEASE_TESTING: 이 환경변수가 참일 경우, 테스트는 릴리즈 시의 품질관리 프로세스의 일부로써 실행되어야 한다는 것을 의미합니다. CPAN 클라이언트는 이 환경변수를 설정해서는 안됩니다.
AUTHOR_TESTING: 이 환경변수가 참일 경우, 테스트는 저자 개인적인 개발 프로세스의 일부로써 실행된다는 것을 의미합니다. 이런 테스트는 릴리즈 전에 실행되는 지는 알 수 없습니다. CPAN 클라이언트는 이 환경변수를 설정해서는 안됩니다. 배포판의 패키지(ppm, deb, rpm 등)도 이 환경변수를 설정해서는 안됩니다.

이미 CPAN 에서는 이런 환경변수의 설정을 간단하게 사용할 수 있게끔 하는 라이브러리가 두가지 존재합니다.

CPAN Smoker 나 통합 테스터는 자동 테스트를 수행한다는 것을 명시해야 합니다. 그리고 리소스에 따라 다르지만, 시간이 걸리는 테스트도 수행하도록 요구할 수 있습니다.

CPAN 클라이언트는 설정에 따라서 자유롭게 비상호적인 테스트나 시간이 걸리는 테스트를 수행할 수 있습니다.

CPAN Smoker 나 클라이언트는 “설정해서는 안되는” 환경변수에 새로이 명시적으로 값이 설정되어 있는 경우, 그 값을 삭제하면 안됩니다.

Build.PL 스펙의 수정

David Golden 과 Leon Timmermans 는 Build.PL 의 스펙책정에 힘써왔습니다. 이 스펙은 Build.PL 을 사용한 Perl 빌드 툴이 어떻게 동작해야 하는 가를 나타내는 것으로, 필연적으로 Module::Build 에 따르지만, 반드시 Module::Build 의 동작에 완전히 따라야 한다는 것은 아닙니다.

Lancaster 에서는 .modulebuildrc 의 사용법과 의미는 스펙에서 제외되어야 한다고 합의하였습니다.

설치가 끝난 배포판의 데이터베이스

QA Hackathon 의 프로젝트의 하나로 packlist 를 대체하는 어떠한 것을 만드는 것이 있습니다. 설치가 끝난 배포판의 데이터베이스가 있다면, 설치가 끝난 배포판의 간단한 목록이나 제거툴, 설치가 끝난 모듈의 의존그래프의 트래킹 등을 간단하게 할 수 있게 될 겁니다.

Lancaster 에서는 모듈은 수많은 다른 장소에서 설치될 것이기에 그런 데이터베이스는 INC마다 준비할 필요가 있다는 것과 INC 스스로 같은 동작으로 스택에 쌓아올릴 필요가 있다는 것에 합의하였습니다. 즉, INC 에 경로를 추가한다면 데이터베이스가 설치가 끝난 모듈은 변화할 것이라는 것입니다.

또, 이런 데이터베이스 시스템이 코어 이외의 의존모듈을 요구하는 일은 있어서는 안되지만, 권장되는 CPAN 모듈이 설치되어 있는 경우에 확장기능을 제공할 수 있을 것입니다.

그 외의 구현의 자세한 내용에 대해서는 시스템을 설계하는 사람에게 달려 있습니다.

설치 후의 테스트

Hackathon 참가자 안에는 모듈을 설치한 다음에도 그 모듈의 테스트를 실행할 수 있게 하는 시스템에 관심을 가지고 있는 사람들이 여럿 있었습니다. 예를들어 의존모듈을 업그레이드함으로써 모듈이 깨지지 않았는가 확인하거나, 전체 정합성을 테스트하기 위한 것입니다.

Lancaster 에서는 그런 테스트를 수행할 경우, 테스트 중에 배포판 안의 모든 파일을 이용할 수 있게 해야합니다. 즉, 테스트는 배포판의 tarball 이 있는 디렉토리에서 실행되지 않으면 안되는 것으로 합의하였습니다. 또, 그런 테스트는 make test-installed 나 Build test-installed 라는 새로운 make 혹은 Build 타겟을 사용해서 실행해야 합니다. 이 타겟들은 make test 나 Build test 에 해당하지만, INC 에는 blib 을 추가하지 않도록 해야 합니다. 그리고 prove 어플리케이션을 사용해서는 안됩니다.

또, 그런 테스트 시에는 INC 에 의한 모듈을 저장하거나 숨기는 방법도 존중할 필요가 있다는 것도 합의하였습니다. PERL5LIB 을 설정하면 “설치된” 배포판이 변할 가능성이 있고, 그에 따라서 어느 테스트가 실행되어야 하는지도 바뀔 수 있기 때문에 설치가 끝난 배포판의 데이터베이스와 연계할 것을 권장합니다.

그 외의 구현의 자세한 내용에 대해서는 배포판의 디렉토리 내용을 처음 설치할 때에 저장하거나, CPAN/BackPAN 에서 다시금 가지고 오는 것을 포함해서 시스템을 설계하는 사람에 달려 있습니다.

META 파일의 스펙

“provides” 필드

CPAN::Meta::Spec 의 provides 필드는 “file” 키를 필수요소로 하고 있지만, 동적으로 생성되는 패키지의 경우, 그 의미가 명확하지 않았습니다. Lancaster 에서는 “file” 키는 그 패키지가 유래하는 배포판의 디렉토리 안에 있는 실제 파일을 참조해야야 한다고 합의하였습니다(그 파일이 .pm 파일이거나 .PL 파일이거나 또는 그 외의 동적으로 생성되는 파일인가 상관없이).

“conflicts” 개선

Lancaster 에서는 의존모듈 정보(prerequisite) 데이터에 포함된 conflicts 키의 이미 알려진 문제에 대해서도 몇가지 간단하게 의논하였습니다.

어찌되었든 대부분의 개발자가 원하는 것은, 어떤 특정 모듈을 설치하면 다른 특정 버젼의 모듈을 깬다고 알려져 있는(예를 들어 Foo 를 2.0 으로 업그레이드 하면 3.14 보다 낮은 모든 Bar 가 깨지는) 것을 나타내는 방법입니다.

이 문제의 개선에 흥미를 가지고 있는 쪽에서는, x_breaks 또는 유사 커스텀키를 사용하며, CPAN 클라이언트는 이를 지원하기 위한 패치를 받아서 프로토타입을 만드는 것을 권장합니다. 실전에서는 충분한 테스트가 끝났다면, 앞으로는 스펙의 버젼3의 후보가 될 수 있습니다.

PAUSE 와 CPAN

PAUSE 에 있는 배포판 레벨의 데이터에 대한 장기적인 목표

의논의 극점에 있는 PAUSE 의 몇가지 문제점으로부터 PAUSE 는 패키지(이름공간) 레벨의 인덱스나 권한 데이터 외에, “배포판” 레벨의 데이터도 유지할 필요가 있다는 것이 명확해졌습니다. 예를들어 지금은 배포판의 권한을 양도하면 모든 패키지의 권한을 양도해야 했지만, 그 대신에 배포판을 단위로 한 권한의 양도가 가능하게 됩니다.

Lancaster 에서는 이것은 장기적인 목표로 적절하다고 보고, 단기적으로는 눈 앞의 문제를 해결하기 위한 다른 제안을 구현하는 것으로 합의하였습니다.

대문자/소문자를 구별하지 않는 패키지의 권한

직접 의논된 것은 아니지만, 추가하고 싶은 내용으로 PAUSE 의 패키지 권한에 대해서는 간간히 대문자 소문자를 묻지 않게 될 예정입니다. 단, 대문자 소문자를 구별하지 않는 파일시스템에서는 설치된 경우에도 인덱스된 모듈은 확실하게 유니크하도록 대문자나 소문자는 보존될 예정입니다.

배포판 이름의 규칙

CPAN 에코 시스템에 속하는 웹 사이트나 툴의 대부분은 “배포판이름” 을 유니크한 식별자로 이용하고 있지만, 지금까지는 그것이 유니크하다는 것을 강제하는 것은 아무것도 없습니다. 유니크하지 않은 것을 허용하는 것은 얼마나 자주 말해도 혼란스럽지만, 최악의 경우는 보안적인 위험이 됩니다.

앞으로, PAUSE 에 업로드될 배포판의 배포판 안에 인덱스된 패키지 이름과 “대응하는” 이름을 가져야합니다. 또, 업로드할 사람은 그 패키지의 권한을 가져야 합니다. 그렇지 않으면, 배포판 전체가 인덱스되지 않습니다.

예를들어, DAGOLDEN 이 Foo-Bar-1.23.tar.gz 을 업로드 하는 경우, 배포판의 이름은 Foo-Bar 로, 그 배포판에는 인덱스 가능한 Foo::Bar 라는 패키지가 있어야 합니다.

CPAN 에는 이런 규칙에 따르지 않는 배포판이 1000건 정도 있지만, 이것들에 대해서는 새로운 규칙의 예외로 합니다. 단, 이 배포판들에 대해서도 배포판 이름을 바꾸거나, 새롭게 .pm 파일을 추가하거나 또는 내부적으로 적절한 이름의 패키지를 도입해서 표준에 맞추는 것을 권장합니다.

예를들어, LWP는 libwww-perl-6.05.tar.gz 로 릴리즈되지만, 만약 그 .pm 파일에 package libwww::perl; 이라는 것이 포함되어 있다면 그 패키지가 인덱스되어 표준에 따르게 됩니다.

기술적으로는 provides 필드를 사용하면 올바른 패키지이름을 META.json 파일의 안에서만 선언하는 것도 가능합니다. 그 경우 “file”의 값은 META.json　으로 해서, 그 패키지를 선언하는 파일이 META.json 이라는 것을 명시해야 합니다.

폐기 모듈이나 협력이 필요한 모듈에 도장을 찍는다

현시점에서는 에서는 CPAN 모듈의 저자가 사망한 경우, 그 사람의 모듈의 권한은 “ADOPTME”라는 가공의 저자에 양도됩니다. 그 모듈을 유지보수하고 싶은 희망자가 있다면, 손들고 나와서 하고 싶다고 요구할 수도 있습니다.

Lancaster 에서는 모듈이 폐기되거나 저자가 책임을 공유한 사람을 찾는 것을 나타내는 경우도 단기적으로는 같은 메커니즘을 사용해야 한다는 것에 합의하였습니다. 단, 저자가 없어진 경우와는 달리 이 경우들은 표시로써 “공동유지보수자” 의 권한을 사용해서, 원저자가 필요에 따라서는 그 표시를 삭제할 수 있게 할 예정입니다.

(장기적으로는 PAUSE에 배포판 레벨의 데이터 모델에 따라, 이 요구에 보다 직접적으로 대처할 수 있을 것이라고 기대하고 있습니다)

CPAN 검색 엔진등의 커뮤니티사이트에서는 이 퍼미션의 표시나 그에 관련된 의미를 이용해서 배포판의 상태를 전달해도 됩니다.

ADOPTME(프라이머리의 경우): 이것은 일반적으로 저자가 죽었다는 것을 나타냅니다. 희망자는 modules@perl.org 경유로 인수를 요구할 수 있습니다.
ADOPTME(공동유지보수자의 경우): 이것은 응답이 없는 것을 확인한 저자를 나타냅니다. 커뮤니티는 패키지에 이 표시를 붙일 때에는 인수된 경우와 마찬가지로 (즉, 저자에게 여러번 연락을 취한 다음에, modules@perl.org 경유로 요구한다는) 룰에 따라 제안할 수 있습니다. 희망자는 modules@perl.org 경유로 ADOPTME 모듈 인수를 요구할 수 있습니다. 추가로 기다리는 시간은 필요없습니다.
HANDOFF(공동유지보수자의 경우): 이것은 저자가 영원히 주요 유지보수자의 역할을 다른 사람에게 넘기고 싶다는 것을 나타냅니다.
NEEDHELP(공동유지보수자의 경우): 이것은 저자가 모듈의 유지보수를 도와줄 사람을 찾고 있다는 것으로, 주요유지보수자인 것은 계속하려고 계획하고 있다는 것을 나타냅니다.

ADOPTME 에서 “인수”를 예외로해서 (이것은 modules@perl.org 를 통해야 합니다), CPAN 모듈의 저자는 이 공동유지 권한을 일반적인 PAUSE 인터페이스를 이용해서 관리해야 합니다.

또, CPAN 모듈의 저자는 PAUSE 관리자에게 요구가 있다면 즉시 권한을 양도해도 좋다는 것을 나타내기 때문에, 주요유지보수자 또는 공동유지보수자의 권한을 스스로 ADOPTME 에 양도해도 됩니다.

PAUSE ID 자동등록

역사적으로 PAUSE ID 는 수작업으로 승인되어 왔기에, 등록까지는 종종 꽤 시간이 걸리곤 했습니다. Lancaster 에서는 로봇이나 스팸에 대한 적절한 보호책을 가지고 있다는 전제를 가지고 PAUSE 는 자동승인 시스템으로 옮긴다고 합의하였습니다. 이것으로 PAUSE 도 다른 프로그래밍 언어의 저장소나 오픈 소스 커뮤니티의 사이트와 어깨를 나란히 할 수 있을 것입니다.

또, Lancaster 에서는 사용되지 않고, 활동의 흔적이 없는 PAUSE ID 는 일정기나 후 삭제해서 재이용할 수 있도록 한다라는 것에 합의하였습니다. 구체적으로 말하면, 과거에 몇번인가 업로드한 적이 있는 PAUSE ID 는 삭제해서는 안됩니다(BackPAN 에서는 그 PAUSE ID 에 연결된 파일이 존재하기 때문입니다). 또한 PAUSE ID 에 로그인(또는 rt.cpan.org 등의 프록시를 경유)한다면 충분히 활동의 흔적이 있다고 간주됩니다. 활동의 흔적이 없는 ID 도 PAUSE 에 로그인할 수 있도록 경고하는 메시지도 없이 삭제할 수는 없습니다.

CPAN 배포판의 자동 클린업

CPAN 상의 파일 중, 거의 절반 정도가 5년전의 것이지만, CPAN 모듈의 저자의 대부분은 낡은 배포판을 전혀 삭제하지 않습니다. CPAN 의 크기를 감당하기 위해서, Lancaster 에서는 어떤 조건을 가지고 옛 배포판은 자동적으로 삭제하도록 준비(그리고, 결과적으로 BackPAN 에만 보존하지 않도록 한다)하도록 합의하였습니다.

삭제 대상으로 선택되는 배포판은 적어도 3개의 안정판이 존재해야 합니다. 그 3개의 안정판 중 제일 낡은 것도 더 옛 배포판의 리비젼 중, 5년 전의 것으로 02packages 파일에 인덱스되지 않은 것은 모두 삭제하도록 준비하게 됩니다.

perl의 tarball 은 물론 모두 삭제 대상에서 제외됩니다.

삭제가 준비된 것은 일반적으로 저자에게 통보되며 삭제준비를 취소할 수 있도록 유예기간도 주어집니다.

클린업은 어떤 방법으로 PAUSE ID 가 대상이 된 순으로 수행하고, CPAN 모듈의 저자에게 빈번하게 삭제통지가 간다는 것을 피할 수 있도록 구현할 예정입니다.

모듈 등록

Lancaster 에서는 PAUSE 모듈 등록은 그 유용성을 거의 잃었다는 것에 합의하였습니다. 등록된 것은 일부의 CPAN 모듈이기 때문에 메타데이터(예를들어 “DSLIP”)의 총합제공원이 될 수 없고, 커버되는 정보도 대부분은 META 파일을 통해서 더욱 광범위하게 입수할 수 있기 때문입니다.

Lancaster 에서는 지금이라도 새로운 CPAN 모듈의 저자가 맨 처음 모듈을 등록하려고 할 때에 종종 피드백을 받는다는 이점이 남아있다는 것은 인정하지만, PrePAN 등의 다른 장소 쪽의 새로운 저자에게는 보다 경험을 제공할 수 있다고 생각하고 있습니다. 특히 PrePAN 은 1-2사람의 PAUSE 관리자에게 그치지 않는 커뮤니티의 참가가 있고, (메일링 리스트의 아카이브를 검색하지 않아도) 참고할 만한 예제를 풍부하게 제공하고 있습니다.

그 때문에 Lancaster 에서는 기존의 PAUSE 문서를 변경해서, 조언이 필요한 경우는 PrePAN 에 가도록 새로운 저자에게 (또는 경험을 가진 저자에게도) 안내한다는 것에 합의하였습니다.

가까운 시일안에 PAUSE 는 모듈 등록 데이터베이스를 CPAN 미러에 공개하는 것을 그만둘 예정입니다 ( 인덱스 파일이 있다는 것을 기대하는 CPAN 클라이언트를 부수지 않도록, 인덱스 파일은 남아 있지만, 내용은 비게 될 예정입니다). 평가기간이 끝났다면, 모듈 등록은 아마도 닫히고, 그 기능도 PAUSE 에서 제외될 예정입니다.