필자가 이전에 작성한 패치가 어느 경로를 따라 mainline
에 입성하게 되는지 궁금하기도 하고 stable
이나, rc
, merge window
, backport
, LTS
등등 이해가 안되는 용어도 너무 많아서 이참에 제대로 정리해서 개념을 잡으려 한다.
Development Cycle
) 커널 개발자들은 대략적으로 두 달 혹은 세 달이라는 시간을 기준으로 하여 major kernel
을 출시(release
)한다:
버전 | 날짜 |
---|---|
5.0 | 2019년 03월 03일 |
5.1 | 2019년 05월 05일 |
5.2 | 2019년 07월 07일 |
5.3 | 2019년 09월 15일 |
5.4 | 2019년 11월 24일 |
5.5 | 2020년 01월 24일 |
매 5.x release
를 major kernel release
라 부르는데 여기에는 새로운 기능, 내부 API 변경, 그 밖의 다양한 변경 사항 들이 포함된다. 통상적인 release
는 수십만 줄의 코드 변경에 따른, 13,000 개 가량의 변경 사항들이 포함된다. 5.x
는 리눅스 커널 개발의 최첨단(최전방) 이며 커널은 핵심 변경 사항을 주기적으로 통합하는 롤링 릴리즈 개발 모델을 사용한다.
여기서 말하는 롤링 릴리즈 개발 사이클이란,
major kernel release
에 대한 것이다. 따라서 한 사이클이 끝났다? 그럼 다음 버전의major kernel
이 출시(release)된 것이다. 그리고 이 과정을 무한히 반복한다.
Merge Window
각각의 release
는 패치들이 병합되어 완성된다는 단순한 규칙에 따라, 개발 사이클은 merge window
의 개방(open)으로 시작 된다. 이때부터는 충분히 안정적이라 여겨지는 코드(이는 커널 개발 커뮤니티에서 승인받은)가 mainline
커널로 병합된다. 새로운 개발 사이클을 위한, 대량의 변경 사항들이 — 이를 "patch"
혹은 "changeset"
이라 부른다 — 이 기간 동안에 병합되는데, 매일 1,000 개에 달하는 변경사항들이 병합된다.
덧붙여 말하자면,
merge window
기간 동안 통합되는 변경 사항 들은 하늘에서 뚝 떨어진게 아니다. 이러한 변경사항은 통합 이전부터 수집되고 테스트된 것이다. 여기에 대해선 이후에 자세히 설명하려 한다.
merge window
는 대략적으로 2주간 지속되며, 시간이 다 되면 Linus Torvalds
는 merge window
가 폐쇄됐음을 선언(close)하고, 첫 번째 "rc"
(release candidate; 릴리즈 후보자, 유보자) 커널을 출시한다. 이 "rc"
커널은 5.6
이 될 예정 인데, "merge window"
가 끝남에 따라 만들어진 이 릴리즈는 "5.6-rc1"
이라 불린다. -rc1
릴리즈는, 새로운 기능들의 병합이 성공적으로 이뤄졌으며, 이때부터는 다음 커널(5.6
)을 위한 안정화 작업이 시작됨을 뜻한다.
RC Kernel
(Release Candidate) 다음 6주부터 10주에 동안 mainline
에는 문제를 수정하는 패치만 제출되야 한다. 때로는 중요한 변경 사항이 허용되기는 하지만 그런 일은 매우 드물다. merge window
밖에서 새로운 기능을 병합하려는 개발자에게는 불친절한 반응이 돌아오는 경향이 있다. 이러한 일반 규칙에 따라, 만일 새로운 기능을 병합하려는데 merge window
를 놓쳤다면, 가장 좋은 방법은 다음 개발 사이클까지 기다리는 것이다. (예외적인 상황은, 기존에는 지원하지 않았던 하드웨어에 대한 드라이버 개발이다. 만일 이러한 드라이버가 트리 내의 코드를 건드리지 않는다면, 이들은 다른 곳에 영향을 주지 않으므로 어느 시점에서든 안전하게 추가될 수 있다.)
mainline
에 대한 수정이 이뤄질수록, 패치 속도는 점차 느려지게 된다. Linus 는 새로운 -rc
커널을 대략 일주일마다 출시하는데, 일반적으로 커널이 충분히 안정적이라고 간주될 때까지 -rcN
시리즈가 진행되며 이는 통상 -rc6
에서 -rc9
즈음에 끝나게 되며 마지막에 최종 릴리즈가 완성된다. 여기까지 왔다면, 전체 프로세스가 다시 시작된다.
5.4
버전의 개발 사이클가 어떻게 진행됐는지를 살펴보자 (2019년):
날짜 | 버전 | 비고 |
---|---|---|
09월 15일 | 5.3 stable release | merge window 개방(open) |
09월 30일 | 5.4-rc1 | merge window 폐쇄(close) |
10월 06일 | 5.4-rc2 | - |
10월 13일 | 5.4-rc3 | - |
10월 20일 | 5.4-rc4 | - |
10월 27일 | 5.4-rc5 | - |
11월 03일 | 5.4-rc6 | - |
11월 10일 | 5.4-rc7 | - |
11월 17일 | 5.4-rc8 | - |
11월 24일 | 5.4 stable release | 다시 merge window 개방 |
개발자들은 언제 개발 사이클을 마감하고, stable release
를 출시하는가? 가장 주된 평가 방식은 이전 릴리즈의 회귀 목록이다. 버그가 없다면 좋지만, 버그가 없더라도 기존의 시스템을 망가트린다면 이는 특히 심각하게 취급된다. 이러한 이유로 회귀를 일으키는 패치는 바람직하지 않게 여겨지며 안정화 기간 동안 원래대로 되돌릴 가능성이 높다.
개발자들의 목표는 알려진 모든 회귀 문제를 stable release
출시 이전에 수정하는 것이다. 하지만 실제로는 이렇게 완벽하게 처리되기는 무척 어렵다. 프로젝트 자체가 워낙 거대하기 때문에 너무나 많은 변수가 존재하기 때문이다. 그렇다고 최종 릴리즈를 연기하면 문제는 더 심각해진다. 왜냐하면 다음 merge window
를 기다리는 변경 사항들은 계속 쌓여갈 것이고 이는 다음 개발 사이클에서 더 많은 회귀 문제를 발생 시키기 때문이다. 따라서 대부분의 5.x 커널은 기존에 알려진 몇 가지 회귀 문제를 가지지만 심각한 문제가 없기를 희망한다.
stable release
일단 stable release
가 만들어지면, 이에 대한 유지 관리는 Greg Kroah-Hartman
의 "stable team"
으로 넘어간다. stable team
은 stable release
에 대한 업데이트를 주기적으로 출시하며 이는 5.x.y
와 같은 형식으로 버전을 붙인다. 릴리즈의 업데이트를 위해선, 패치가 (1) 중대한 문제를 수정해야 하며, (2) 다음 개발 커널의 메인라인에 이미 병합되어 있어야 한다.
이렇게 다음
mainline
으로부터 패치를 끌어와서 이전 버전을 업데이트하는 방식을 백포팅(back-porting) 한다고 한다.
stable release kernel
은 일반적으로 초기 릴리즈 이후 다음 개발 사이클 하고도 약간의 시간 동안 안정화 업데이트를 받는다. 5.2
커널의 히스토리를 보면 이해가 쉬울 것 같다 (2019):
07월 07일 | 5.2 stable release |
07월 14일 | 5.2.1 |
07월 21일 | 5.2.2 |
07월 26일 | 5.2.3 |
07월 28일 | 5.2.4 |
07월 31일 | 5.2.5 |
... | ... |
10월 11일 | 5.2.21 |
5.2.21
이 최종 stable
업데이트이다. 5.3
의 release
가 09월 15일이므로 merge window
가 폐쇄된 이후로 2주 정도 더 업데이트되고 중단 되었다.
LTS
(Long term support) 커널 일부 커널은 "long term" kernel
로 지정되며 더 긴 시간동안 지원을 받게 된다. 다음의 링크를 통해 장기 지원 커널의 버전과 이를 관리하는 메인테이너 목록을 확인할 수 있다:
https://www.kernel.org/category/releases.html
어떤 커널이 장기 지원될지는 메인테이너의 순전히 메인테이너에 의해 좌우지된다. 어떤 커널이 장기 지원될지는 알 수 없고 알려진 계획도 없다.
https://www.kernel.org/doc/html/latest/process/2.Process.html
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#netdev-faq
https://stackoverflow.com/questions/30268332/why-does-the-linux-kernel-repository-have-only-one-branch
https://www.kernel.org/category/releases.html
https://www.kernel.org/doc/html/latest/process/2.Process.html#next-trees
https://cyber93.tistory.com/158
https://ko.wikipedia.org/wiki/롤링_릴리즈
https://en.wikipedia.org/wiki/Regression_testing
https://ko.wikipedia.org/wiki/백포팅