linukbank 에서 얻은 건데요, 전 무슨말인지...(초보라서)
리누스 커널 패치 아무거나 안받아
[리눅스뱅크 2001-01-08]
2.4.x 패치들에 대한 방침을 명확히해 이에 혼란스러워하는 사람이 없었으
면한다.(리누스 토발즈)
리누스가 2.4.0 patchs submission policy(패치 제출 방침)를 공개했습니
다.
----------------------------------
2.4.x 패치들에 대한 방침을 명확히해 이에 혼란스러워하는 사람이 없었으
면합니다.어떤 사람들(패치제작자들)은 '2.4.x가 나왔으니 쉴 수 있겠구
나 놀러가자'라고 생각하는 것처럼 보이기도 합니다.
그렇지 않습니다.
리눅스 커널은 흥미로운 릴리스 패턴을 가지고 있습니다. 보통 .0릴리스
는 상당히 훌륭했고(대체적으로), .1은 나빴습니다. 다시 .5버전까지와
야 .0의 안정성을따라잡게 되죠.
왜일까요? '릴리스해야해 그 패치는 좀 기다려'라는 필터를 통과하지 못
한, 대기상태의 수많은 패치들이 있는데, 안정 트리의 초기에 몇몇 이런
패치들이 반영되면 안좋은 결과가 나오기도 하기때문입니다.
이번엔 이런 혼란을 피하기 위해 2가지 가이드라인을 만들었습니다.
- 나는 기본적으로 내게 보내진 모든 패치를 주말에 몰아뒀다가 작업할 겁
니다.몇칠씩 걸리는 지루한 패치 생각을 안하렵니다.
- 받은 패치는 순서에 따라 이것이 진짜로 버그를 수정한 것인지뿐아니라
이 버그들이 심각하고 진짜로 문제를 일으키는 것인지에 관해 상당수준의
토의를 거치게 됩니다.
명백히 패치의 사이즈도 문제가 됩니다 만약 5줄의 확실한 버그픽스를 만
들 수 있으면 그렇게 하십시요. 150라인에 걸친 깨끗한 픽스를 만들려고
는 하지 마시고요.
2.4.0은 당분간 전보다 적은 패치들이 가해질 것입니다.닌 패치들을 적용
시키기 전에 기본 2.4.x 인프라스트럭처가 바위처럼 단단한지 절대적인 확
신을 얻었으면 합니다.
이제 내 ChangeLog는 다음과 같은 모습을 할 것 입니다.
- Don't drop a megabyte off the old-style memory size detection
- remember to UnlockPage() in ramfs_writepage()
- 3c59x driver update from Andrew Morton
사람들이 패치를 제게 보내기전에 자신에게 이 패치가 절대적으로 지금 적
용돼야하는지 아니면 몇개월 더 기다려도 되는지 생각해보길 바랍니다.
패치를 만들었는데 이 패치가 다음 레드햇/수세/데비안등등 배포판에 포함
되지 않으면 어떻게 될까 스스로 물어보기 바랍니다.진짜로 큰 문제인가?
아니라면 전보다 큰 문제를 야기하는 패치를 다루어야겠죠.
내 체인지로그가 짧고 간결하다면 우리모두 좋아할 겁니다. 만약 2.4.1버
전이 2.4.0버전보다 훌륭하게 만들어지면 이는 훌륭한 새 전통이 시작됐
기 때문일 겁니다.
그리고 2.5.x에 대해 내가 2.4.x를 다른 누군가에게 기쁜 마음으로 넘겨
주기전까지는 시작하지 않습니다.
전례를 보면 적어도 몇달은 걸렸습니다. 2.2.x시리즈에서 2.3.0까지는 약
4달, 2.0.0에서 2.1.x는 약 네달반정도.
제게 패치를 보내기전에 재차 생각해주세요. 내게 패치를 보낼땐 릴리스
매니저처럼 생각할 수 있도록 해보시고 당장 적용해야하는 이유를 설명해
주세요
지겨운 다음 몇달간이 기대됩니다. The more boring, the better.
---------------------
음 이제 허접한 커널버전은 안나오나요..-.-;; 다음은 원문입니다. 위에
번역한
것중 중복되거나 중요치 않다고 생각되는(제가생각하기에)말은 뺐습니다.
그리고 제목은 스포츠 신문처럼 )
Subject Linux-2.4.x patch submission policy
Date 6 Jan 2001 101702 -0800
From torvalds@transmeta.com (Linus Torvalds)
To linux-kernel@vger.kernel.org
I thought I'd mention the policy for 2.4.x patches so that nobody
gets confused about these things. In some cases people seem to
think that "since 2.4.x is out now, we can relax, go party, and
generally goof off".
Not so.
The linux kernel has had an interesting release pattern usually the
.0 release was actually fairly good (there's almost always
_something_ stupid, but on the whole not really horrible). And
every single time so far, .1 has been worse. It usually takes until
something like .5 until it has caught up and surpassed the stability
of .0 again.
Why? Because there are a lot of pent-up patches waiting for
inclusion, that didn't get through the "we need to get a release
out, that patch can wait" filter. So early on in the stable tree,
some of those patches make it. And it turns out to be a bad idea.
In an effort to avoid this mess this time, I have two guidelines
- I've basically thrown away all patches sent to me so far, and I
will continue to do so at least over the weekend. I'm not going to
bother thinking about patches for a few days.
- In order for a patch to be accepted, it needs to be accompanied by
some pretty strong arguments for the fact that not only is it
really fixing bugs, but that those bugs are _serious_ and can cause
real problems.
Obviously, the size of the patch matters too if you can make an
obvious fix in 5 lines, do it. Don't try to make a clean fix that
fixes the problem the clever way in 150 lines.
In short, releasing 2.4.0 does not open up the floor to just about
anything. In fact, to some degree it will probably make patches
_less_ likely to be accepted than before, at least for a while. I
want to be absolutely convicned that the basic 2.4.x infrastructure
is solid as a rock before starting to accept more involved patches.
Right now my ChangeLog looks like this
- Don't drop a megabyte off the old-style memory size detection
- remember to UnlockPage() in ramfs_writepage()
- 3c59x driver update from Andrew Morton
The first two are true one-liners that have already bitten some
people (not what I'd call a showstopper, but trivially fixable stuff
that are just thinkos). The third one looks like a real fix for
some rather common hardware that could do bad things without it.
Now, I'm sure that ChangeLog will grow. There's the apparent fbcon
bug with MTRR handling that looks like a prime candidate already,
and I'll have people asking me ....... 기사전체내용보기