Lines Matching +full:make +full:- +full:git +full:- +full:archive
16 ----------------------------------
29 ----------------------------------
46 ----
56 여러분이 특정 아키텍쳐의 low-level 개발을 할 것이 아니라면
61 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
62 - "Practical C Programming" by Steve Oualline [O'Reilly]
63 - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
84 ---------
90 :ref:`Documentation/process/license-rules.rst <kernel_licensing>` 에 설명되어
97 https://www.gnu.org/licenses/gpl-faq.html
101 ----
112 :ref:`Documentation/admin-guide/README.rst <readme>`
121 :ref:`Documentation/process/coding-style.rst <codingstyle>`
127 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
131 - Email 내용들
132 - Email 양식
133 - 그것을 누구에게 보낼지
146 https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
148 :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
152 - 서브시스템 shim-layer(호환성을 위해?)
153 - 운영체제들간의 드라이버 이식성
154 - 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것)
160 :ref:`Documentation/process/security-bugs.rst <securitybugs>`
165 :ref:`Documentation/process/management-style.rst <managementstyle>`
173 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
178 :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
183 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
195 make pdfdocs
196 make htmldocs
201 make latexdocs
202 make epubdocs
205 ---------------------
237 것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며
245 -------------
251 - 리누스의 메인라인 트리
252 - 여러 메이저 넘버를 갖는 다양한 안정된 커널 트리들
253 - 서브시스템을 위한 커널 트리들
254 - 통합 테스트를 위한 linux-next 커널 트리
262 - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
264 몇 주 동안 linux-next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는
265 데 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은
266 https://git-scm.com/ 에서 참조할 수 있다)를 사용하는 것이지만 순수한
268 - 2주 후에 -rc1 커널이 릴리즈되며 여기서부터의 주안점은 새로운 커널을
273 드라이버(혹은 파일시스템)는 -rc1 이후에만 받아들여진다는 것을 기억해라.
276 있지 않기 때문이다. -rc1이 배포된 이후에 git를 사용하여 패치들을 Linus에게
279 - 새로운 -rc는 Linus가 현재 git tree가 테스트 하기에 충분히 안정된 상태에
280 있다고 판단될 때마다 배포된다. 목표는 새로운 -rc 커널을 매주 배포하는
282 - 이러한 프로세스는 커널이 "준비(ready)"되었다고 여겨질때까지 계속된다.
295 세개의 버젼 넘버로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 해당
303 -stable 트리들은 "stable" 팀<stable@vger.kernel.org>에 의해 관리되며 거의 매번
306 커널 트리 문서들 내의 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
307 파일은 어떤 종류의 변경들이 -stable 트리로 들어왔는지와
313 다양한 커널 서브시스템의 메인테이너들 --- 그리고 많은 커널 서브시스템 개발자들
314 --- 은 그들의 현재 개발 상태를 소스 저장소로 노출한다. 이를 통해 다른 사람들도
321 대부분의 이러한 저장소는 git 트리지만, git이 아닌 SCM으로 관리되거나, quilt
323 파일에 나열되어 있다. 대부분은 https://git.kernel.org 에서 볼 수 있다.
333 통합 테스트를 위한 linux-next 커널 트리
340 https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
342 이런 식으로, linux-next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤
343 변경이 가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 linux-next
348 ---------
350 메인 커널 소스 디렉토리에 있는 'Documentation/admin-guide/reporting-issues.rst'
357 --------------------
378 ---------------
384 http://vger.kernel.org/vger-lists.html#linux-kernel
401 http://vger.kernel.org/vger-lists.html
412 하나를 받아 두번 받는 것에 익숙하여 있으니 mail-header를 조작하려고 하지
420 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` 에
434 ----------------------
440 - 비판
441 - 의견
442 - 변경을 위한 요구
443 - 당위성을 위한 요구
444 - 침묵
454 - 여러분의 패치가 아무 질문 없이 받아들여지기를 기대하는 것
455 - 방어적이 되는 것
456 - 의견을 무시하는 것
457 - 요청된 변경을 하지 않고 패치를 다시 제출하는 것
474 ------------------------------------
480 - "이것은 여러 문제들을 해결합니다."
481 - "이것은 2000 라인의 코드를 줄입니다."
482 - "이것은 내가 말하려는 것에 관해 설명하는 패치입니다."
483 - "나는 5개의 다른 아키텍쳐에서 그것을 테스트 했으므로..."
484 - "여기에 일련의 작은 패치들이 있으므로..."
485 - "이것은 일반적인 머신에서 성능을 향상함으로..."
489 - "우리는 그것을 AIX/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀림없다..."
490 - "나는 20년동안 이것을 해왔다. 그러므로..."
491 - "이것은 돈을 벌기위해 나의 회사가 필요로 하는 것이다."
492 - "이것은 우리의 엔터프라이즈 상품 라인을 위한 것이다."
493 - "여기에 나의 생각을 말하고 있는 1000 페이지 설계 문서가 있다."
494 - "나는 6달동안 이것을 했으니..."
495 - "여기에 5000 라인 짜리 패치가 있으니..."
496 - "나는 현재 뒤죽박죽인 것을 재작성했다. 그리고 여기에..."
497 - "나는 마감시한을 가지고 있으므로 이 패치는 지금 적용될 필요가 있다."
517 ------------------------
570 -----------------
578 -----------------
585 - 변경이 왜 필요한지
586 - 패치에 관한 전체 설계 접근(approach)
587 - 구현 상세들
588 - 테스트 결과들
605 ----------
619 메인테이너: Greg Kroah-Hartman <greg@kroah.com>