리눅스에 패치 업로드 하기
이 저작물은 크리에이티브 커먼즈 [저작자표시-동일조건변경허락 2.0 대한민국 라이선스]에 따라 이용할 수 있습니다.
지난 10월 11일~12일, 서울시 JW marriott 호텔에서 Korea Linux Forum 2012 행사가 있었습니다.
여러가지 좋은 발표와 강의, 대담등이 있었습니다만, Write and submit your first Linux kernel patch 라는 제목의, 리눅스 staging 트리를 관리하는 Greg Kroah-Hartman 의 발표는 개인적으로 가장 인상깊은 발표 중 하나였습니다.
발표 능력도 인상깊었고, 발표 내용 또한 상당히 유익했기에, 한국어로 해당 발표의 내용을 한글 문서로 정리해 보는 것은 리눅스에 컨트리뷰션을 하고자 하는 많은 한국 개발자에게 도움이 될 수 있지 않을까 싶어 문서로 정리해 봅니다.
Greg Kroah-Hartman 의 발표 문서는 https://github.com/gregkh/kernel-tutorial에서 얻을 수 있으며, 해당 발표 동영상은 http://www.youtube.com/watch?v=XXix80GCvpo 에서 확인 할 수 있습니다.
동영상은 안타깝게도 오디오 상의 문제로 상태가 좋지만은 못합니다. 같은 주제로 Greg이 한 몇년 전의 다른 발표 동영상들도 Youtube에 있으니, 그걸 보는 것도 좋을 것 같습니다.
FOSDEM 2010 에서 있었던 같은 주제의 발표 동영상을 추천합니다.
2년 전 발표라 조금 다른 부분도 있지만, 전체적 내용은 같더군요.
http://www.youtube.com/watch?v=LLBrBBImJt4
엄청나게 많은 분들이 리눅스를 사용하고 있고 또한 굉장히 많은 분들이 리눅스를 개발자로써 사용하고 있습니다. 이 과정에서 리눅스의 많은 문제점들을 마주하게 되고 수정하게 되지만, 이걸 upstream에 보내는 건 또한 쉬운 일이 아니지요.
치명적인 문제를 찾거나 엄청난 개선을 했고, 세상의 많은 이들에게 도움을 주기 위해 이를 upstream - 리누스 토발즈가 직접 관리하는 메인 소스코드 저장소 - 에 보내고자 하지만, reject 되는 경우가 많습니다. 하지만 대부분은 리눅스의 개발 프로세스, 패치를 보내는 과정과 주의할 점 등을 몰랐기 때문인 경우라고 합니다. 사실 그걸 모르니 패치를 보내지 못하는 경우도 많구요.
이 문서는 리눅스에서 발견한 문제를 수정하고 이 수정 내용을 어떻게 패치로 만들어서 upstream의 리눅스에 적용되도록 하는지 알아봅니다.
이를 위해, 가장 사소하지만 중요한, 코딩 스타일이 잘못된 파일들을 수정하고 이걸 패치로 만들어서 보내는 과정을 함께 진행해 보겠습니다.
전체 워크플로를 크게 정리하면 이렇습니다.
- 소스코드 받아오기(개발환경 구축)
- 문제점 발견
- 문제점 수정, 확인
- 패치 만들기
- 패치 보내기
소스 코드 받아오기
대부분의 오픈소스 개발방식을 사용하는 프로젝트가 그렇듯이, 리눅스 또한 다양한 트리와 브랜치를 이용해 개발되고 있습니다.따라서, 올바른 소스 트리에서 코드를 받아오고, 올바른 소스 트리로 패치를 보내는 것이 필요한데요.
리눅스의 경우, 다음 버전에 머지되기를 기다리는 패치를 위해 linux-next 트리가 존재합니다. 아주 특수한 경우가 아니라면 모든 패치는 이 트리로 업로드 하는 것이 좋겠습니다.
먼저, 해당 트리의 코드를 가져와야겠죠. git clone을 쓰는 것도 하나의 방법이겠구요. 패치 하나만 만들어 보고 끝낼 게 아니라 이미 특정 트리의 소스코드를 clone해서 쓰고 있다면, remote로 linux-next를 추가하고 fetch 해서 쓰는 걸 권장합니다.
linux-next 트리의 저장소 주소는 다음과 같습니다.
| git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git |
단순히
| $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git |
으로 소스코드를 가져올 수 있구요,
앞서 설명했듯 이미 특정 트리를 clone해서 저장소를 만들어 두신 상태라면, 다음과 같은 명령으로 linux-next를 remote에 추가하고 소스코드를 가져와 작업 디렉토리를 구성할 수 있습니다.
| $ git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git $ git fetch linux-next $ git fetch --tags linux-next |
그리고, 소스코드를 가져온 지 오래되었을 경우에는 다음과 같은 명령으로 업데이트를 해야겠죠.
| $ git remote update |
구글의 kernel.org 공식 미러
kernel.org 에서 소스코드를 받는 건 아무래도 조금 느린 면이 있는데요, 구글에서는 https://kernel.googlesource.com/ 에서 kernel.org 의 미러(mirror)를 제공하고 있으며, 이 서비스는 세계 각지의 구글 데이터 센터를 이용하기 때문에 상당히 빠른 속도를 보인다고 합니다. 해당 서비스에 대한 구글의 공지글은 다음 링크를 따라가면 볼 수 있습니다.http://google-opensource.blogspot.kr/2012/04/worldwide-mirrors-of-gitkernelorg.html
여기를 이용할 경우, 위의 명령어들에서 linux-next 트리의 git 저장소 주소를 https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
로 변경해 주시면 되겠습니다.
구글의 미러에 대한 정보는 이호민님(https://plus.google.com/u/0/118040095502884745897/about)께서 알려주셨습니다. 다시 한번 감사 말씀 드립니다 :)
문제점 찾기
일단 문제점이 있어야 수정을 하겠죠.문제점은 직접 발견할 수도, 남들이 찾고 이야기한 걸 참고할 수도 있겠는데요. 다양한 방법이 있겠습니다. 메일링 리스트를 구독할 수도 있겠고, 이슈 트래킹 시스템을 이용할 수도 있겠죠.
아래는 커널 버그질라 페이지입니다. 최신 커널에 대한 내용으로 업데이트 되어 있지 않다고 합니다만, 잘 찾아보면 재미있는 버그를 찾을 수도 있을 겁니다.
https://bugzilla.kernel.org/query.cgi?format=advanced
그리고, 다음 링크를 따라가시면 메인 커널 메일링 리스트를 확인할 수 있습니다.
http://vger.kernel.org/vger-lists.html#linux-kernel
하지만, 처음 컨트리뷰션을 하려 마음 먹었을 때 하기 쉬운 실수 중 하나가, 처음부터 거대한 패치를 하려 하는 경우라고 합니다. 물론 여러분의 패치는 훌륭하고 그걸 upstream에 넣으면 세상을 위한 큰 도움이 되겠지만, 실제로 그 패치를 프로젝트에 머지해야할 메인터너(maintainer) 입장에선 그렇지많은 않다는 이야기죠. 대부분은 패치를 한두개만 올리고는 더이상 패치를 보내지 않는다고 합니다. 메인터너 입장에선 이를 감안할 때, 커다란 수정 내용의 패치를 함부로 머지하면, 해당 패치를 보냈던 사람이 더이상 해당 부분을 관리하지 않으면 그로 인한 문제도 크다는 거죠. 따라서, 메인터너와의 '신뢰'를 얻는 게 중요하다고 합니다.
따라서, 여기선 심각한 문제가 아니라 일단 간단하게 따라해 볼 수 있고, 그렇지만 중요한 문제점을 찾아가 보겠습니다.
코딩 스타일입니다.
코딩 스타일이 얼마나 사소해보이지만 심각한 문제인지에 대해선 따로 이야기 하지 않겠습니다 ;)
아시다시피 리눅스는 엄격한 코딩 스타일이 있지만, 여러가지 이유로 지켜지지 않는 파일들도 많다고 하며, 이런 것들을 수정해 주는 건 큰 도움이 될 수 있겠죠.
리눅스 소스코드에는 코딩 스타일을 검사해 주는 툴, checkpatch.pl 이 scripts/ 디렉토리 아래에 있습니다. 이걸 이용해 다음과 같은 명령으로 검사할 수 있습니다.
| ./scripts/checkpatch.pl [--terse] --file <검사할 파일 경로> |
--terse 옵션은 검사 결과를 각각 한줄씩으로 나타내라는 옵션이구요. 옵션은 이외에도 많으며, 다음의 명령으로 사용법을 볼 수 있습니다.
| ./scripts/checkpatch.pl --help |
예를 들어 drivers/staging/csr/csr_framework_ext_types.h 를 <검사할 파일 경로>에 넣으면, 다음과 같이 코딩 스타일을 어긴 내용을 알려줍니다.
| drivers/staging/csr$ ../../../scripts/checkpatch.pl --terse --file csr_framework_ext_types.h csr_framework_ext_types.h:5: ERROR: code indent should use tabs where possible csr_framework_ext_types.h:6: ERROR: code indent should use tabs where possible csr_framework_ext_types.h:8: ERROR: code indent should use tabs where possible csr_framework_ext_types.h:9: ERROR: code indent should use tabs where possible csr_framework_ext_types.h:28: ERROR: open brace '{' following struct go on the same line csr_framework_ext_types.h:29: WARNING: please, no spaces at the start of a line csr_framework_ext_types.h:30: WARNING: please, no spaces at the start of a line csr_framework_ext_types.h:34: ERROR: open brace '{' following struct go on the same line csr_framework_ext_types.h:36: WARNING: please, no spaces at the start of a line csr_framework_ext_types.h:37: WARNING: please, no spaces at the start of a line csr_framework_ext_types.h:40: WARNING: do not add new typedefs csr_framework_ext_types.h:41: WARNING: do not add new typedefs csr_framework_ext_types.h:42: WARNING: do not add new typedefs csr_framework_ext_types.h:47: ERROR: open brace '{' following struct go on the same line csr_framework_ext_types.h:48: WARNING: please, no spaces at the start of a line csr_framework_ext_types.h:49: WARNING: please, no spaces at the start of a line csr_framework_ext_types.h:50: WARNING: please, no spaces at the start of a line csr_framework_ext_types.h:53: WARNING: do not add new typedefs csr_framework_ext_types.h:54: WARNING: do not add new typedefs csr_framework_ext_types.h:55: WARNING: do not add new typedefs total: 7 errors, 13 warnings, 63 lines checked |
7개의 error와 13개의 warning을 찾았습니다.
이 파일을 수정하고 패치를 만들어 보내 보겠습니다.
참고로, 이 파일은 제가 수정해서 이미 패치를 보냈으니, 만약 해당 패치가 머지된다면 이 문서를 보고 해당 파일에 같은 명령어를 실행할 경우 다른 결과가 나올 수도 있을 겁니다 ;)
여담이지만, Korea Linx Forum 2012의 'Write and submit your first Linux kernel patch' 세션의 경우, Greg Kroah-Hartman은 이와 같이 코딩 스타일을 수정해야 할 파일의 목록을 종이 조각에 인쇄해 와서, 사람들에게 이 종이 조각을 하나씩 나눠주더군요. 1주일 내로 수정해서 패치를 작성해 보내 보라고 말입니다 ;)
문제점 수정하기
문제점 수정은 각자 편한 방법으로 진행하면 되겠습니다. 여기선 코딩 스타일을 수정하면 되니, 저는 제게 익숙한 vim 편집기로 수정을 진행하겠구요.토픽 브랜치(topic branch) 만들기
수정을 하기 전에 topic branch를 만드는 게 좋습니다. git 에서는 브랜칭의 비용이 굉장히 적기 때문에, 이렇게 작업하는 걸 선호하고, 리눅스 메인터너들도 이걸 선호할테니, 이 방법을 씁시다.이제부터 git 사용이 나올텐데, git에 대한 자세한 내용을 알고 싶다면 다른 문서나 책을 보시는 게 좋겠습니다. Pro Git 라는 책(http://git-scm.com/book)을 개인적으로 추천합니다.
토픽 브랜치에 대해 더 알고 싶다면, http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt 등의 문서를 참고하세요.
다음의 명령으로 현재 브랜치들의 목록과 자신이 위치한 브랜치를 알 수 있습니다.
| $ git branch * master |
그리고, 다음의 명령으로 패치를 만들 브랜치를 만들고, 바로 그리로 이동합니다.
| $ git checkout -b fix_csr_codingstyle M drivers/staging/csr/csr_framework_ext_types.h Switched to a new branch 'fix_csr_codingstyle' |
다시 브랜치 목록과 자신이 위치한 브랜치를 확인해 보면...
| $ git branch * fix_csr_codingstyle master |
정상적으로 브랜치가 생성되고 해당 브랜치로 이동했습니다.
수정을 마치고 나서 checkpatch를 돌려보면...
| drivers/staging/csr$ ../../../scripts/checkpatch.pl --terse --file csr_framework_ext_types.h csr_framework_ext_types.h:38: WARNING: do not add new typedefs csr_framework_ext_types.h:39: WARNING: do not add new typedefs csr_framework_ext_types.h:40: WARNING: do not add new typedefs csr_framework_ext_types.h:50: WARNING: do not add new typedefs csr_framework_ext_types.h:51: WARNING: do not add new typedefs csr_framework_ext_types.h:52: WARNING: do not add new typedefs total: 0 errors, 6 warnings, 60 lines checked |
대략 위와 같은 결과가 나왔군요. warning이 좀 남았지만, 일단 간단한 수정만으로 만족하겠습니다.
빌드해보기
이제 본격적으로 패치를 만들어보기 시작해야 할텐데요, 먼저 수정 내용은 제대로 되었다는 걸 확실히 해야겠죠.빌드는 제대로 되는지, 증상은 제대로 수정되었는지 확인해 봅시다.
빌드는 다음의 명령처럼 해당 모듈만 빌드해 볼 수도 있겠지만, 전체 커널을 다시 빌딩해보고 실행해서 문제가 제대로 수정되었음을 확실히 해야겠죠.
| make M=drivers/staging/csr |
패치 만들기
이제, 패치를 만들어 보겠는데, 리눅스는 git로 관리되는 만큼, 너무나도 간단하고 쉽습니다.git status
git status 명령은 현재 수정한 내용을 보여줍니다.| $ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: drivers/staging/csr/csr_framework_ext_types.h # no changes added to commit (use "git add" and/or "git commit -a") |
git add
다음 명령을 통해 수정한 파일을 commit할 것임을 알립니다.| $ git add drivers/staging/csr/csr_framework_ext_types.h |
git commit
이제, commit합니다.| $ git commit |
commit 메세지 작성할 에디터가 뜨겠죠.
commit 메세지 또한 중요한데요. 먼저 수정한 모듈과 수정한 내용을 짧게 제목으로 정리하고, 한줄을 그냥 띄운 후, 그 아래(세번째 줄)에 자세한 설명을 적어 줍니다.
git log 명령을 통해 남들은 어떻게 쓰는지 알 수 있겠구요.
아래는 제가 쓴 commit 메세지입니다.
| staging: csr: fix coding style Fix coding style of csr_framework_ext_types.h Signed-off-by: SeongJae Park <sj38.park@gmail.com> |
마지막 줄에 Signed-off-by 라는 부분이 눈에 띌 텐데요, Signed-off-by는 개발자들이 해당 commit에 다는 증명서로, 다음과 같은 의미를 띕니다.
- 내가 이 수정 사항을 만들었다; 또는
- 기존 작업 내용과 잘 호환되는 라이센스 하에 이 수정 사항을 만들었다;
- 또는 앞의 두가지와 이 세번째 항목에 의해 내가 이 수정 사항을 받았으며, 내가 이에 대해 어떤 수정을 가하진 않았다.
- 이 commit은 public 하다.
git format-patch
분산 버전 관리 시스템을 사용하지 않은 사람은 조금 헷갈릴 수도 있겠습니다. git과 같은 분산 버전 관리 시스템은 각 개발자가 사용하는 컴퓨터 파일 시스템 위에 독립된 저장소를 만드는 것이기 때문에, 앞서 행한 commit은 자신의 파일 시스템 위의 독립된 저장소에 commit한 것이지, 네트웍 상에 존재하는 메인 저장소로 commit 한 것이 아닙니다.이제, 리눅스 메인터너들이 많이 쓰는 형식의 패치를 만들어 봅시다.
간단히, 다음의 git format-patch 명령으로 패치를 만들 수 있습니다.
| $ git format-patch master..HEAD 0001-staging-csr-fix-coding-style.patch |
소스코드를 땡겨온 후 아무 변경도 가하지 않은 master 브랜치와, 현재 HEAD가 가리키고 있는(우리가 위치해 있는), topic 브랜치 사이의 commit들을 이용해 패치 파일을 만들고, 생성한 패치 파일의 파일명을 보여 줍니다.
드디어 패치를 만들었습니다.
이제, 이 파일만 메인터너에게 보내면 됩니다.
패치 보내기
패치를 보낼 사람 찾기
먼저, 패치를 누구에게 보낼지 알아야겠죠. 기왕이면 착하고 똑똑한 메인터너에게 보내야겠지만, 수정한 부분을 관리하는 메인터너에게 보내야 할 것입니다.수정한 파일의 메인터너를 찾는 툴도 리눅스 소스코드에 있습니다. 다음의 명령을 이용합니다.
| $ ./scripts/get_maintainer.pl 0001-staging-csr-fix-coding-style.patch Greg Kroah-Hartman <gregkh@linuxfoundation.org> (supporter:STAGING SUBSYSTEM,commit_signer:3/4=75%) devel@driverdev.osuosl.org (open list:STAGING SUBSYSTEM) linux-kernel@vger.kernel.org (open list) |
devel@driverdev.osuosl.org가 적당하겠군요.
git 메일 설정
git는 패치 파일을 메일로 쓰는 것도 도와줍니다.하지만, 이를 위해선 다음 명령어로 git-email을 설치해야 합니다. 이미 설치하셨다면, 설치할 필요 없겠죠.
| $ sudo apt-get install git-email |
그리고, 메일 설정을 해주는데요. git가 메일을 보낼 수 있도록, smtp 서버 등을 설정 해야 합니다. gmail을 이용한다면 다음과 같이 설정하면 됩니다.
| $ git config --global sendemail.smtpserver smtp.gmail.com $ git config --global sendemail.smtpserverport 587 $ git config --global sendemail.smtpencryption tls $ git config --global sendemail.smtpuser <본인의 이메일 주소> |
이렇게 설정하면 git을 이용해 메일을 보낼 때 git이 gmail 패스워드를 입력하라고 프롬프트를 띄워주는데요.
만약 그것도 귀찮다면 다음과 같이 패스워드도 설정할 수 있습니다.
| $ git config --global sendemail.smtppass your_password |
하지만, 보안을 위해선 패스워드는 저장하지 않는 게 좋지 않겠나 싶습니다.
메일 보내기
이제, 다음의 명령을 이용해 메일을 보냅니다.| $ git send-email --to <보낼 곳 메일 주소> |
몇가지 질문이 나오는데 잘 읽고 답하도록 하며, y/n 등의 선택지가 나오지 않는 건 그냥 엔터로 기본값을 사용하도록 설정합니다. 대부분 엔터/y로 귀결될 겁니다.
앞서 작성한 메일의 경우, 다음과 같은 명령으로 보낼 수 있겠습니다.
| $ git send-email --to devel@driverdev.osuosl.org *.patch 0001-staging-csr-fix-coding-style.patch Who should the emails appear to be from? [SeongJae Park <sj38.park@gmail.com>] Emails will be sent from: SeongJae Park <sj38.park@gmail.com> Message-ID to be used as In-Reply-To for the first email? (mbox) Adding cc: SeongJae Park <sj38.park@gmail.com> from line 'From: SeongJae Park <sj38.park@gmail.com>' (body) Adding cc: SeongJae Park <sj38.park@gmail.com> from line 'Signed-off-by: SeongJae Park <sj38.park@gmail.com>' From: SeongJae Park <sj38.park@gmail.com> To: devel@driverdev.osuosl.org Cc: SeongJae Park <sj38.park@gmail.com> Subject: [PATCH] staging: csr: fix coding style Date: Tue, 16 Oct 2012 16:15:42 +0900 Message-Id: <1350371742-831-1-git-send-email-sj38.park@gmail.com> X-Mailer: git-send-email 1.7.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Cc list above has been expanded by additional addresses found in the patch commit message. By default send-email prompts before sending whenever this occurs. This behavior is controlled by the sendemail.confirm configuration setting. For additional information, run 'git send-email --help'. To retain the current behavior, but squelch this message, run 'git config --global sendemail.confirm auto'. Send this email? ([y]es|[n]o|[q]uit|[a]ll): y Password: OK. Log says: Server: smtp.gmail.com MAIL FROM:<sj38.park@gmail.com> RCPT TO:<devel@driverdev.osuosl.org> RCPT TO:<sj38.park@gmail.com> From: SeongJae Park <sj38.park@gmail.com> To: devel@driverdev.osuosl.org Cc: SeongJae Park <sj38.park@gmail.com> Subject: [PATCH] staging: csr: fix coding style Date: Tue, 16 Oct 2012 16:15:42 +0900 Message-Id: <1350371742-831-1-git-send-email-sj38.park@gmail.com> X-Mailer: git-send-email 1.7.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Result: 250 2.0.0 OK 1350371762 y5sm10389071pav.36 |
기다리기
이제, 지루한 기다림의 시간입니다. 패치는 세계 각지에서 엄청난 양이 쏟아지므로, 메인터너들이 메일을 바로 보지는 못할 겁니다. 이 문서를 작성하며 보낸 패치에 대해서도 아직 어떤 답장이나 연락도 없습니다.운이 좋으면 빠르게, 없다면 좀 천천히 연락이 올겁니다.
중요한 패치인데 답이 너무 느리다면 정중히 해당 메인터너에게 메일을 보내 보는 것도 좋은 방법입니다.
피드백 받고 보내기
메일을 보내면 생각보다 빨리 피드백을 받습니다. 오자가 섞인 패치를 실수로 보낸 적 있는데, 이틀만에 이를 지적당했고, 약 일주일만에 머지됐습니다!
문제가 있어 보이면 그에 대해 발견한 사람들이 바로바로 피드백을 줍니다.
이에 대해서는 적당히 정말 잘못됐다면 시인하고 새로운 패치를 만들어 보내고, 그쪽 문제제기가 잘못되었다면 오해가 있는 것 같다고 정중하게 잘 말합시다. 적당히 강경하고 적당히 인정하는 자세가 필요하겠죠. 분명한 건, 다들 훌륭한 커널을 만들려 노력하고 있다는 것 같습니다.
문제가 있어 보이면 그에 대해 발견한 사람들이 바로바로 피드백을 줍니다.
이에 대해서는 적당히 정말 잘못됐다면 시인하고 새로운 패치를 만들어 보내고, 그쪽 문제제기가 잘못되었다면 오해가 있는 것 같다고 정중하게 잘 말합시다. 적당히 강경하고 적당히 인정하는 자세가 필요하겠죠. 분명한 건, 다들 훌륭한 커널을 만들려 노력하고 있다는 것 같습니다.
순수 문자로만 메일 보내기
한가지 유의할 점은, 리눅스 메일링 리스트로 gmail에서 답장을 그냥 보내면, 아래와 같은 전송 실패 메세지가 도착합니다.
본문에 html이 섞여 있다는 건데요. 이건 gmail의 메일 작성창에 Rich formatting이 기본으로 켜져 있어서입니다. 패치 보낼 땐 git send-email이 알아서 잘 해줬지만, gmail 기본 입력창은 Rich formatting이 켜져 있어서 내부적으로 html을 섞습니다.
gmail 입력창 바로 위의 Plain text 를 클릭해 plain text(html 등이 섞이지 않은 순수한 문자)로 메일 본문이 작성되도록 합시다.
쥐메일이 아니라도 비슷한 상황이 있을 수 있을 겁니다.
| Delivery to the following recipient failed permanently: linux-kernel@vger.kernel.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 Content-Policy reject msg: The message contains HTML subpart, therefore we consider it SPAM or Outlook Virus. TEXT/PLAIN is accepted.! BF:<U 0.494653>; S1753440Ab2JPHiz (state 17). |
본문에 html이 섞여 있다는 건데요. 이건 gmail의 메일 작성창에 Rich formatting이 기본으로 켜져 있어서입니다. 패치 보낼 땐 git send-email이 알아서 잘 해줬지만, gmail 기본 입력창은 Rich formatting이 켜져 있어서 내부적으로 html을 섞습니다.
gmail 입력창 바로 위의 Plain text 를 클릭해 plain text(html 등이 섞이지 않은 순수한 문자)로 메일 본문이 작성되도록 합시다.
쥐메일이 아니라도 비슷한 상황이 있을 수 있을 겁니다.
머지 완료 메세지
위의 과정을 잘 거치고 인내와 토론을 잘 했다면, 머지 되었음을 다음과 같은 이메일로 통보 받습니다.| This is a note to let you know that I've just added the patch titled staging: csr: csr_framework_ext_types.h: fix coding style to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. |
X나 좋군요!?
참고자료
- Greg Kroah-Hartman의 Korea Linux Forum 2012 발표자료(https://github.com/gregkh/kernel-tutorial)
- Greg Kroah-Hartman의 Korea Linux Forum 2012 발표 동영상(http://www.youtube.com/watch?v=XXix80GCvpo) - 음향에 문제가 좀 있습니다.
- Greg Kroah-Hartman의 FOSDEM 2010 비슷한 주제 발표 동영상(http://www.youtube.com/watch?v=LLBrBBImJt4)
- kernel.org 버그질라(https://bugzilla.kernel.org/query.cgi?format=advanced)
- 커널 메일링 리스트(http://vger.kernel.org/vger-lists.html#linux-kernel)
- Pro Git(http://git-scm.com/book)
- Topic branch에 대한 문서 중 하나(http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt)
- Documentation/HOWTO
- Documentation/development_process
