2.6.32 merge plan Sep 16, 2009

http://lkml.org/lkml/2009/9/15/471

2.6.32를 위한 merge plan이 발표되었습니다. by Andrew Morton.
것이 의미하는 것은 그 동안 mm tree에서 잘 성숙되어 온 patch들중,
Andrew Morton과 Subsystem maintainer들에 의해 어떤 patch들을
이번에 mainline으로 밀어 넣을 것인지를 결정하는 일입니다.

밀어 넣어진 patch들 또한 rc1~rc8 or rc9이 될 때 까지 약 3개동안 mainline
tree에서 테스트를 거치게 됩니다.

이번 2.6.32를 위한 patch들 중 특이한 점은 memory management patch들이
대거 포함되었다는 겁니다. 즉, 속된 말로 잘 되면 대박, 못되면 쪽박이 될 수도 있습니다.
(제가 개발팀장이라면 2.6.32 커널은 되도록 피하라고 지시할 것 같습니다.)

memory management 쪽의 패치가 많을 수 있었던 것은 “후지쯔 가이”들,
즉 일본인들이 mm 쪽의 개발에 부지런히 참여했었고,
늘상 부지런하던 Hugh, Rik, Mel, 그리고 VFS layer에 주로 놀던 Wu의 mm 참여,
반대로 mm쪽에서 많은 활약을 하던 Nick의 VFS layer로의 이동.
그리고 한국의 hobbyist정도가 정도가 바쁘게 움직인 덕입니다. ^^

그럼 3달동안 어떤 regression들이 생기는 지 두고 보기로 하죠.

꼬랑지)

MM쪽의 패치를 만들어 나가는 과정은 약간 복잡합니다.
물론 다른 쪽도 얼마든지 복잡해 질 수 있지만, MM쪽은 시스템에 critical한
변경을 가하는 것이기 때문에, 하나의 패치에도 여러 사람들이 관계하게 됩니다.
먼저, 최초 문제의 목격자 reporter(Reported-by),
그 문제를 풀기 위한 패치의 저자(signed-off-by),
패치를 review해주는 리뷰어(Reviewed-by)
패치에 대한 승인을 해주는 영향력 있는 인물들의 승락(Acked-by)
패치를 test해주는 테스터(Tested-by),
등이 관계합니다 이밖에도 Andrew Morton은 해당 패치의 관계자들,
즉 그 패치에 대해서 argue가 있었던 사람이나 해당 패치를 꼭 알고 해야
하는 사람들을 patch description에 Cc하곤 합니다.
MM쪽은 이렇듯 하나의 패치를 만들기 위해 많은 사람들이 작업을 하게 되며,
관계하게 됩니다.

아 그리고 mm tree가 Memory Management Tree가 아닙니다.
쓰고 나니 mm tree가 그럼 무엇의 약자냐고 물어보는 이가 있어 부연합니다.
mm tree는 memory management의 약어이긴 합니다.
하지만 mm tree의 기능은 더 이상 mm만 care하지 않는다는 것입니다.
mm tree는 memory management 뿐만이 아니라 다양한 subsystem들도 포함하며,
마치 예전 홀수 버젼의 test version이라고 생각하시면 대충 맞습니다.
참고로 mmtom은 "MM of the moment or MM of the minute"의 약어입니다.
Andrew도 잊어먹었다고 하더군요.