명색이 커널 코드를 분석한다고 덤벼든 개발자(저 말입니다..;;;)가 Linux Kernel 의 버전관리가
어떻게 이루어지는지를 정확히 모르고 있었네요.
mainline 과 rc 버전 stable 버전 등이 Community 에서 어떻게 관리되는지가 갑자기 궁금해져서
Linux Kernel 의 개발자 Community 에 올라온 Guide 문서를 좀 읽어보고 블로그에 정리한 내용을 여기에 옮깁니다.
물론 iamroot 의 대부분 회원들은 이미 알고 계신 내용이겠지만, 저 같이 뒷북치기 좋아하는 분들에게
혹시 도움이 되실까 하여 공유합니다. ^^;;;
혹시라도 제가 영문해석을 잘못하여 사실과 다르게 이해한 것도 있을 수 있으니 그런 부분이 있다면 지적바랍니다.
==================
버전관리가 어떻게 이루어지는지를 이해하면 Linux Kernel 의 개발 Process 를 어느정도 이해할 수 있기 때문에
Kernel 을 공부하는 개발자의 상식으로라도 알아두는 것이 좋겠다.
Linux Kernel 개발 process 에 참여하고 싶거나 관심이 있는 개발자라면 아래의 Link 를 유심히 읽어볼 것을 권장한다.
개발자들이 Linux Kernel 의 개발 Process 를 반드시 이해하고 참여하도록 유도하기 위한 문서이다.
이러한 Process 를 이해하지 못한 상태에서 참여한 개발자들이 Community 의 분위기를 해치거나 악영향을 줄
가능성이 있기 때문에 사전에 이에 대한 Guide 를 제시한 셈이다.
http://www.linuxfoundation.org/content/how-participate-linux-community-0
오늘 나는 이 문서의 내용중에서 특히 기본적으로 알고 있어야할 Linux Kernel 의 Versioning 에 관해 요약해보려고 한다.
Linux Kernel 의 버전 관리가 이전에 비해서 좀더 복잡해진 가운데, 릴리즈 주기가 약 3 개월 단위로 짧아진 것은
버전관리 Process 가 그만큼 효율적으로 잘 정립되어 있기 때문이 아닌가 싶다.
참고로, 포스팅을 하고 있는 2014/06/26 일 현재 Linux Kernel 의 최신 Stable 버전은 3.15.1 이며, 2.6.x 버전에서
3.x 버전으로 넘어온 것은 2011 년이다. (이는 Linux Kernel 의 Open 20 주년을 기념하기 위해 버전을 올린 것이라고 한다.)
https://www.kernel.org/#sthash.knwFcmhG.dpuf 에 방문해보면 아래와 같이 몇 가지 종류의
릴리즈 버전들이 존재하는 것을 확인할 수 있다.
위의 버전들이 무엇인가를 이해하려면 아래의 4 가지 종류의 릴리즈 버전의 생성 Process 를 알고 있어야 한다.
- Mainline
- rc (개발버전)
- Stable
- Longterm
Mainline 은 그 유명한 리누스 토발즈가 관리하는 개발 버전의 Main Tree 이다.
Git 을 통해 관리되는데 SVN 을 기준으로 말하면 Linux Kernel 코드의 Trunk 라고 할 수 있다.
즉, 모든 Linux Kernel 버전 Tree 의 기준이자 시발점이 된다.
Mainline 은 버전이 3.X 처럼 두 자리가 된다.
리누스 토발즈가 약 2 주 동안 Merge Window 를 열어놓으면 개발자 Community 에서 Accept 되는 모든 변경 사항들이
Mainline 에 Merge 된다.
Merge Window 라는 것은 Community 의 개발자들이 Maintainer(코드 관리권한을 부여받은 Community 개발자)를 통해
Linux Kernel Mainline 에 새로운 변경들을 Merge 할 수 있는 기간이 시작되었다는 것을 의미하는 용어이다.
즉, 리누스 토발즈가 Merge Window 를 Open 했다고 공표한 기간에만 Mainline 에 변경들이 Maintainer 를 통해 Merge 될 수 있다. Merge Window 가 닫히면 버그가 아닌 이상 더 이상의 변경들은 Merge 될 수 없다.
리누스 토발즈가 Merge Window 의 종료를 선언하면 그 때의 Linux Kernel 버전이 곧 rc1 이 된다.
만약 Mainline 이 3.12 였다고 가정하고, 그 이전의 최종 Stable 버전이 3.12.20 이었다면, 이번 Merge Window 가
닫힌 직후의 버전은 곧 3.12.21-rc1 이 되는 것이다.
(위의 그림은 3.15 에서 3.16 으로 넘어가는 단계라서 3.16-rc2 로 한 것 같다.)
이는 3.12.21 이라는 Stable 버전을 만들기 위한 첫번째 개발 버전이라는 의미라고 보면 되겠다.
Merge Window 가 닫혔다고 곧바로 Stable 버전이 되는 것은 아니고, 6~10 주 동안은 Bug Fix 등과 같은 변경 사항이
Mainline 에 적용될 수 있다.
이러한 변경이 적용되면서 rc2, rc3 와 같이 rc 버전이 올라간다.
보통은 이 기간에 Bug Fix 만이 허용되지만, 예외적으로 기존에 지원하지 않던 H/W 를 지원하는 Driver 를 추가하거나하는
것들은 허용될 수 있다. 이는 기존의 기능들에 해를 끼쳐 퇴화시키는 일(regression)이 없기 때문이다.
보통 r6 ~ r9 정도 되면 해당 개발버전이 어느정도 안정화되었다고 판단하고 3.12.21 이라는 버전으로 Stable 버전을 릴리즈한다.
Stable 버전이 릴리즈되면 이 때부터는 리누스 토발즈가 관리하는 것이 아니라 별도의 Stable Team 에서 관리를 맡게 된다.
Stable Team 은 3.12.21.5 와 같이 4 자리까지 사용하여 3.12.21 Stable 버전에 대한 Update 를 관리해나갈 수 있다.
이렇게 Update 의 대상이 되는 것은 심각한 Bug 이면서 Mainline 에 이미 적용된 것들에만 해당된다.
보통 6 개월 정도 이런 update 릴리즈과정을 거친 후, 그 이후부터는 유지보수가 해당 Kernel 버전을 이용하는
Distributor 의 책임이 된다.
앞에서 리누스 토발즈가 마치 Mainline 에 대한 Merge 들을 모두 관리하는 것처럼 언급했는데, 사실 이는 불가능한 일이다.
엄청나게 많은 변경량을 혼자 확인하고 관리하는 것이 가능하겠는가 ?
이 때문에 Linux Kernel 의 코드 관리는 마치 군대계급처럼 철저하게 Tree 형태의 관리 계급이에 의해 이루어진다.
Network, Memory Management, File System 등 subsystem 관리자(Maintainer)들이 자신의 계급(Level)에 맞는
범위를 관리하게 된다. 그리고, 이러한 관리는 철저하게 신뢰에 바탕을 두고 이루어진다.
Longterm 버전은 말 그대로 이전 버전들 중에서 오랜 기간동안 계속해서 유지관리가 될 버전들을 말한다.
longterm 버전을 따로 관리하지 않으면 개발자들이 다양한 stable 버전들에 대해 수정하고자 하는 욕구가 사그라들 것이 분명하다.
그래서, 특정 버전을 longterm 버전으로 지정해두고 이에 대한 관리가 오랜기간 지속될 수 있도록 한 것 같다.
Linux Kernel 의 코드 관리에 있어서 Maintainer 의 역할은 절대적이라고 할 수 있다. 각자 자신이 맡은
영역에 대한 전문가여야하는 것은 물론이고, 코드의 Merge 에 대해서 무한한 열정과 책임을 가진 사람이어야하지 않을까 싶다.
Kernel 개발자들은 이러한 Maintainer 의 존재를 알고 있어야 함은 당연하고, 혹시라도 특정 Kernel 버전의
특정 부분에 대한 질의나 문제점을 찾았을 경우에는 전체 Linux Kernel Mailing List 에 포스팅을 할 것이 아니라 ,
어떤 방법으로든 해당 Maintainer 를 찾거나 그 분야의 Mailing List 에 한정하여 포스팅을 하는 것이 좋을 것이다.
댓글 4
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
공지 | [공지] IAMROOT 19차 커널 스터디 오리엔테이션 (zoom 접속 안내) [5] | 문c(문영일) | 2022.05.07 | 2476 |
공지 | [공지] IAMROOT 18차 커널 스터디 오리엔테이션 안내 [마감] [2] | 문c(문영일) | 2021.05.17 | 2052 |
공지 | 커널 스터디를 위한 문c 가이드입니다. [10] | 문c(문영일) | 2021.04.27 | 7954 |
1097 | 세미나비 정산 [2] | 백창우 | 2009.04.05 | 7912 |
1096 | 넥서스 프라임 + 아이스크림 샌드위치 [3] | 김용욱 | 2011.10.07 | 7911 |
1095 | 새로 개설하는 스터디 | 백창우 | 2009.04.27 | 7897 |
1094 | 창우님 고생이 많으세요. [1] | 장동일 | 2010.02.22 | 7886 |
1093 | 메신져에 아무도 안들어 오시네요. [2] | 백창우 | 2006.07.15 | 7880 |
1092 | 재미난 이슈거리 [3] | 백창우 | 2011.10.24 | 7804 |
1091 | 창우님 수고 많으십니다. [3] | 맥주 | 2010.02.17 | 7767 |
1090 | 커널 스터디 진행중인 모임은 없나요? [1] | 신재호 | 2011.03.11 | 7708 |
1089 | SW Maestro 모집 공고 [1] | 백창우 | 2012.04.17 | 7683 |
1088 | GCC 2차 세미나 입금 받도록 하겠습니다. [8] | 백창우 | 2009.04.27 | 7682 |
1087 | 안녕하세요. [1] | 이훈 | 2011.03.06 | 7652 |
1086 | 가입인사 드립니다. [3] | 김세라 | 2011.08.30 | 7647 |
1085 | 문의 사항들 정리 [6] | 백창우 | 2009.04.30 | 7640 |
1084 | 첫모임 장소 [16] | 문대혁 | 2010.03.29 | 7637 |
1083 | 안녕하세요 ㅋ [3] | 정성욱 | 2010.03.24 | 7629 |
1082 | 세미나실 문의 [5] | 백창우 | 2010.03.24 | 7608 |
1081 | GCC 세미나 자료 [3] | 백창우 | 2009.04.06 | 7595 |
» | Linux Kernel 의 버전관리 [4] | 이동표(구름과비) | 2014.06.26 | 7550 |
1079 | 안녕하세요. [1] | 한택수 | 2010.02.21 | 7531 |
1078 | 세미나를 슬슬 준비해볼까 합니다. ^^ [14] | 백창우 | 2011.07.10 | 7521 |
.
좋은 내용 공유 감사드립니다.