howto

linux 内核源代码

리스트들을 사용할 때는 올바른 예절을 따를 것을 유념해라.
대단하진 않지만 다음 URL은 리스트(혹은 모든 리스트)와 대화하는 몇몇 간단한
가이드라인을 가지고 있다.
         http://www.albion.com/netiquette/

여러 사람들이 여러분의 메일에 응답한다면 CC: 즉 수신 리스트는 꽤 커지게
될 것이다. 아무 이유없이 CC에서 어떤 사람도 제거하거나 리스트 주소로만
회신하지 마라. 메일을 보낸 사람으로서 하나를 받고 리스트로부터 또
하나를 받아 두번 받는 것에 익숙하여 있으니 mail-header를 조작하려고 하지
말아라. 사람들은 그런 것을 좋아하지 않을 것이다.

여러분의 회신의 문맥을 원래대로 유지해야 한다. 여러분들의 회신의 윗부분에
"John 커널해커는 작성했다...."를 유지하며 여러분들의 의견을 그 메일의 윗부분에
작성하지 말고 각 인용한 단락들 사이에 넣어라.

여러분들이 패치들을 메일에 넣는다면 그것들은 Documentation/SubmittingPatches에
나와있는데로 명백히(plain) 읽을 수 있는 텍스트여야 한다. 커널 개발자들은
첨부파일이나 압축된 패치들을 원하지 않는다. 그들은 여러분들의 패치의
각 라인 단위로 코멘트를 하길 원하며 압축하거나 첨부하지 않고 보내는 것이
그렇게 할 수 있는 유일한 방법이다. 여러분들이 사용하는 메일 프로그램이
스페이스나 탭 문자들을 조작하지 않는지 확인하라. 가장 좋은 첫 테스트는
메일을 자신에게 보내보고 스스로 그 패치를 적용해보라. 그것이 동작하지
않는다면 여러분의 메일 프로그램을 고치던가 제대로 동작하는 프로그램으로
바꾸어라.

무엇보다도 메일링 리스트의 다른 구독자들에게 보여주려 한다는 것을 기억하라.


커뮤니티와 협력하는 법
--------------------

커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이
받아들여질 패치를 제출하게 되면 그 패치의 기술적인 이점으로 검토될 것이다.
그럼 여러분들은 무엇을 기대하고 있어야 하는가?
 - 비판
 - 의견
 - 변경을 위한 요구
 - 당위성을 위한 요구
 - 고요

기억하라. 이것들은 여러분의 패치가 커널로 들어가기 위한 과정이다. 여러분의
패치들은 비판과 다른 의견을 받을 수 있고 그것들을 기술적인 레벨로 평가하고
재작업하거나 또는 왜 수정하면 안되는지에 관하여 명료하고 간결한 이유를
말할 수 있어야 한다. 여러분이 제출한 것에 어떤 응답도 있지 않다면 몇 일을
기다려보고 다시 시도해라. 때론 너무 많은 메일들 속에 묻혀버리기도 한다.

여러분은 무엇을 해서는 안되는가?
 - 여러분의 패치가 아무 질문 없이 받아들여지기를 기대하는 것
 - 방어적이 되는 것
 - 의견을 무시하는 것
 - 요청된 변경을 하지 않고 패치를 다시 제출하는 것

가능한한 가장 좋은 기술적인 해답을 찾고 있는 커뮤니티에서는 항상
어떤 패치가 얼마나 좋은지에 관하여 다른 의견들이 있을 수 있다. 여러분은
협조적이어야 하고 기꺼이 여러분의 생각을 커널 내에 맞추어야 한다. 아니면
적어도 여러분의 것이 가치있다는 것을 중명하여야 한다. 잘못된 것도 여러분이
올바른 방향의 해결책으로 이끌어갈 의지가 있다면 받아들여질 것이라는 점을
기억하라.

여러분의 첫 패치에 여러분이 수정해야하는 십여개 정도의 회신이 오는
경우도 흔하다. 이것은 여러분의 패치가 받아들여지지 않을 것이라는 것을
의미하는 것이 아니고 개인적으로 여러분에게 감정이 있어서 그러는 것도
아니다. 간단히 여러분의 패치에 제기된 문제들을 수정하고 그것을 다시
보내라.


커널 커뮤니티와 기업 조직간의 차이점
-----------------------------------------------------------------
커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의
문제를 피하기 위한 목록이 있다.
  여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 :
    - "이것은 여러 문제들을 해겹합니다."
    - "이것은 2000 라인의 코드를 제거합니다."
    - "이것은 내가 말하려는 것에 관해 설명하는 패치입니다."
    - "나는 5개의 다른 아키텍쳐에서 그것을 테스트했슴으로..."
    - "여기에 일련의 작은 패치들이 있슴음로..."
    - "이것은 일반적인 머신에서 성능을 향상시킴으로..."

  여러분들이 말할 때 피해야 할 좋지 않은 것들 :
    - "우리를 그것을 AIT/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀립없다..."
    - "나는 20년동안 이것을 해왔다. 그러므로..."
    - "이것은 돈을 벌기위해 나의 회사가 필요로 하는 것이다."
    - "이것은 우리의 엔터프라이즈 상품 라인을 위한 것이다."
    - "여기에 나의 생각을 말하고 있는 1000 페이지 설계 문서가 있다."
    - "나는 6달동안 이것을 했으니..."
    - "여기에 5000라인 짜리 패치가 있으니..."
    - "나는 현재 뒤죽박죽인 것을 재작성했다. 그리고 여기에..."
    - "나는 마감시한을 가지고 있으므로 이 패치는 지금 적용될 필요가 있다."

커널 커뮤니티가 전통적인 소프트웨어 엔지니어링 개발 환경들과
또 다른 점은 얼굴을 보지 않고 일한다는 점이다. 이메일과 irc를 대화의
주요수단으로 사용하는 것의 한가지 장점은 성별이나 인종의 차별이
없다는 것이다. 리눅스 커널의 작업 환경에서는 단지 이메일 주소만
알수 있기 때문에 여성과 소수 민족들도 모두 받아들여진다. 국제적으로
일하게 되는 측면은 사람의 이름에 근거하여 성별을 추측할 수 없게
하기때문에 차별을 없애는 데 도움을 준다. Andrea라는 이름을 가진 남자와
Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅스 커널에서
작업하며 생각을 표현해왔던 대부분의 여성들은 긍정적인 경험을 가지고
있다.

언어 장벽은 영어에 익숙하지 않은 몇몇 사람들에게 문제가 될 수도 있다.
언어의 훌륭한 구사는 메일링 리스트에서 올바르게 자신의 생각을
표현하기 위하여 필요하다. 그래서 여러분은 이메일을 보내기 전에
영어를 올바르게 사용하고 있는지를 체크하는 것이 바람직하다.


여러분의 변경을 나누어라
------------------------

리눅스 커널 커뮤니티는 한꺼번에 굉장히 큰 코드의 묶음(chunk)을 쉽게
받아들이지 않는다. 변경은 적절하게 소개되고, 검토되고, 각각의
부분으로 작게 나누어져야 한다. 이것은 회사에서 하는 것과는 정확히
반대되는 것이다. 여러분들의 제안은 개발 초기에 일찍이 소개되야 한다.
그래서 여러분들은 자신이 하고 있는 것에 관하여 피드백을 받을 수 있게
된다. 커뮤니티가 여러분들이 커뮤니티와 함께 일하고 있다는 것을
느끼도록 만들고 커뮤니티가 여러분의 기능을 위한 쓰레기 장으로써
사용되지 않고 있다는 것을 느끼게 하자. 그러나 메일링 리스트에 한번에
50개의 이메일을 보내지는 말아라. 여러분들의 일련의 패치들은 항상
더 작아야 한다.

패치를 나누는 이유는 다음과 같다.

1) 작은 패치들은 여러분의 패치들이 적용될 수 있는 확률을 높여준다.
   왜냐하면 다른 사람들은 정확성을 검증하기 위하여 많은 시간과 노력을
   들이기를 원하지 않는다. 5줄의 패치는 메인테이너가 거의 몇 초간 힐끗
   보면 적용될 수 있다. 그러나 500 줄의 패치는 정확성을 검토하기 위하여
   몇시간이 걸릴 수도 있다(걸리는 시간은 패치의 크기 혹은 다른 것에
   비례하여 기하급수적으로 늘어난다).

   패치를 작게 만드는 것은 무엇인가 잘못되었을 때 디버그하는 것을
   쉽게 만든다. 즉, 그렇게 만드는 것은 매우 큰 패치를 적용한 후에
   조사하는 것 보다 작은 패치를 적용한 후에 (그리고 몇몇의 것이
   깨졌을 때) 하나씩 패치들을 제거해가며 디버그 하기 쉽도록 만들어 준다.

2) 작은 패치들을 보내는 것뿐만 아니라 패치들을 제출하기전에 재작성하고
   간단하게(혹은 간단한게 재배치하여) 하는 것도 중요하다.

여기에 커널 개발자 Al Viro의 이야기가 있다.
    "학생의 수학 숙제를 채점하는 선생님을 생각해보라. 선생님은 학생들이
    답을 얻을때까지 겪은 시행착오를 보길 원하지 않는다. 선생님들은
    간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고
    마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다.

    커널 개발도 마찬가지이다. 메인테이너들과 검토하는 사람들은 문제를
    풀어나가는 과정속에 숨겨진 과정을 보길 원하진 않는다. 그들은
    간결하고 멋진 답을 보길 원한다."

커뮤니티와 협력하며 뛰어난 답을 찾는 것과 여러분들의 끝마치지 못한 작업들
사이에 균형을 유지해야 하는 것은 어려울지도 모른다. 그러므로 프로세스의
초반에 여러분의 작업을 향상시키기위한 피드백을 얻는 것 뿐만 아니라
여러분들의 변경들을 작은 묶음으로 유지해서 심지어는 여러분의 작업의
모든 부분이 지금은 포함될 준비가 되어있지 않지만 작은 부분은 벌써
받아들여질 수 있도록 유지하는 것이 바람직하다.

또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들을 포함하는
패치들은 받아들여지지 않을 것이라는 점을 유념하라.

변경을 정당화해라
-----------------

여러분들의 나누어진 패치들을 리눅스 커뮤니티가 왜 반영해야 하는지를
알도록 하는 것은 매우 중요하다. 새로운 기능들이 필요하고 유용하다는
것은 반드시 그에 합당한 이유가 있어야 한다.


변경을 문서화해라
-----------------

여러분이 패치를 보내려 할때는 여러분이 무엇을 말하려고 하는지를 충분히
생각하여 이메일을 작성해야 한다. 이 정보는 패치를 위한 ChangeLog가 될
것이다. 그리고 항상 그 내용을 보길 원하는 모든 사람들을 위해 보존될
것이다. 패치는 완벽하게 다음과 같은 내용들을 포함하여 설명해야 한다.
  - 변경이 왜 필요한지
  - 패치에 관한 전체 설계 접근(approach)
  - 구현 상세들
  - 테스트 결과들

이것이 무엇인지 더 자세한 것을 알고 싶다면 다음 문서의 ChageLog 항을 봐라.
   "The Perfect Patch"
    http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt




이 모든 것을 하는 것은 매우 어려운 일이다. 완벽히 소화하는 데는 적어도 몇년이
걸릴 수도 있다. 많은 인내와 결심이 필요한 계속되는 개선의 과정이다. 그러나
가능한한 포기하지 말라. 많은 사람들은 이전부터 해왔던 것이고 그 사람들도
정확하게 여러분들이 지금 서 있는 그 곳부터  시작했었다.




----------
"개발 프로세스"(http://linux.tar.gz/articles/2.6-development_process) 섹션을
작성하는데 있어 참고할 문서를 사용하도록 허락해준 Paolo Ciarrocchi에게
감사한다. 여러분들이 말해야 할 것과 말해서는 안되는 것의 목록 중 일부를 제공해준
Randy Dunlap과 Gerrit Huizenga에게 감사한다. 또한 검토와 의견 그리고
공헌을 아끼지 않은 Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen,
Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard에게도 감사를 전한다.
그들의 도움이 없었다면 이 문서는 존재하지 않았을 것이다.



메인테이너: Greg Kroah-Hartman <[e-mail]>