Revision 140183 of Hacking Firefox

  • 리비전 슬러그: Hacking_Firefox
  • 리비전 제목: Hacking Firefox
  • 리비전 아이디: 140183
  • 제작일시:
  • 만든이: Babyworm
  • 현재 리비전인가요? 아니오
  • 댓글 /* Knowing where to ask for help */
태그: 

리비전 내용

만일 여러분이 `C++ 의 신` 정도의 능력이 있으시다면, 이 부분을 보실 필요가 없을 것입니다. 심지어 (좀 심하게 말하자면) front-end를 해킹하는 것은 여러분이 봐야할 적당한 페이지가 아닙니다만, 우리는 항상 더 많은 사람들이 리뷰하고, 코드를 작성하는 것을 도와줄 것이 필요합니다 building up the platform. Front-end를 해킹하는 것은 코딩 기술 뿐만 아니라 사용자 인터페이스에 대한 직감과 더불어 비판에 잘 견딜 수 있어야 합니다. 여하튼, front-end를 찔러보는 건 상대적으로 쉬운 일입니다. C++/JavaScript/XML 에 대한 기본을 충분히 알고 있다면, XPCOM이나 그 관련된 것에 대하여 샅샅히 알고 있지 않더라도 시작하는데는 충분합니다. 자! 이제, 중요한 것부터 시작합니다.


기본에서부터 시작하기

해킹을 시작하기 전에 우선 Bugzilla에 대하여 알아야 할 필요가 있습니다. 다른 사람에게 "나는 firefox를 해킹하고 싶다"고 이야기하는 것 이전에 선별/QA/버그찾기를 위하여 몇주 혹은 그 이상의 기간을 보낼줄 아는 것은 최소한 할수 있어야 합니다. 프로젝트가 어떻게 수행되는지 알아보는 것, 어떤 것에 대하여 선별하는지 배우는 것, 그리고 이 과정에서 배운 것들을 초기 선별 과정에 적용시키는 것은 검토와 체크인을 통하여 여러분의 방법을 찾는데 크게 도움을 줍니다. 여러분께서 닥치는대로 어떤 부분을 선택하여 작업을 시작하는 것은 일반적으로 최선의 선택은 아닐 것입니다. 어떤 부분이 잘 갖추어져 있는지, 어떤 부분이 추가적으로 필요한지 잘 살펴보시는 것이 해킹을 시작하는데 있어서 좋은 시작이 될 것입니다.

Build the Fox

I could rehash what’s been better-written by others, but I won't. Start with the generic instructions here, make sure you use CVS trunk, and get the beast built. You need to be able to make this work before you attempt to take the next step. Yes, it isn’t trivial to build anything from Mozilla CVS, but if you can't figure it out even with help, you're probably not ready yet. I can go from "never compiling anything" to "building on Win32" in an hour or so.

소스 코드의 구조

자! 다음 질문은 "어디에 프로그램과 front-end 코드가 있나요?" 입니다. Firefox의 관련 코드는 여기에 있으며, 일반적인 front-end toolkit은 여기에 있습니다. (여러분의 CVS tree에서 이것은 각각 <tt>mozilla/browser</tt> 과 <tt>mozilla/toolkit</tt> 입니다.)

Picking bugs to work on

Votes matter. Sort of. Sometimes its a simple matter to make it happen too, and if there's low-hanging fruit, pick it. Other times, bugs with "good first bug" in the status whiteboard are good places to go to find your way around. And, of course, stuff that annoys you is good too. Lots of good personal satisfaction involved there.

도움을 얻을 수 있는 곳

많은 개발자들이 있는 Mozilla IRC server는 여러분께서 어떤 문제를 풀어내지 못할때 조언을 받을 수 있는 좋은 장소입니다. 하지만, 다른 사람을 귀찮게 하기전에 우선 다른 좋은 장소들(lxr/bonsai/Google (그리고, 이 위키페이지))에서 답을 얻기 위해서 최선을 다하십시요. 만일 "UI가 어떤식으로 보이나요?"와 같은 질문이라면 Mike Connor나 Firefox peer에 물어보는 것이 가장 좋을 것이며, 이건 여러분의 사례를 같이 논의할 준비가 되었다는 것이겠습니다.

Changing the user experience

If you're thinking of implementing a feature request, or changing behavior that will affect the user experience, it's best for everyone concerned to get feedback before you start. Talk to Ben Goodger, Mike Connor, or one of the other Firefox peers, and get reaction or adjustments. If they say its a no, you've just saved yourself a lot of stress and resentment (based on how people who don’t follow this role have reacted to review- in the past).

리비전 소스

<p>만일 여러분이 `C++ 의 신` 정도의 능력이 있으시다면, 이 부분을 보실 필요가 없을 것입니다. 심지어 (좀 심하게 말하자면) front-end를 해킹하는 것은 여러분이 봐야할 적당한 페이지가 아닙니다만, 우리는 항상 더 많은 사람들이 리뷰하고, 코드를 작성하는 것을 도와줄 것이 필요합니다 <a class="external" href="http://www.mozilla.org/contribute/hacking/first-bugs/">building up the platform</a>. Front-end를 해킹하는 것은 코딩 기술 뿐만 아니라 사용자 인터페이스에 대한 직감과 더불어 비판에 잘 견딜 수 있어야 합니다. 
여하튼, front-end를 찔러보는 건 상대적으로 쉬운 일입니다. C++/<a href="ko/JavaScript">JavaScript</a>/<a href="ko/XML">XML</a> 에 대한 기본을 충분히 알고 있다면, <a href="ko/XPCOM">XPCOM</a>이나 그 관련된 것에 대하여 샅샅히 알고 있지 않더라도 시작하는데는 충분합니다. 
자! 이제, 중요한 것부터 시작합니다. 
</p><p><br>
</p>
<h3 name=".EA.B8.B0.EB.B3.B8.EC.97.90.EC.84.9C.EB.B6.80.ED.84.B0_.EC.8B.9C.EC.9E.91.ED.95.98.EA.B8.B0"> 기본에서부터 시작하기 </h3>
<p>해킹을 시작하기 전에 우선 <a class="external" href="https://bugzilla.mozilla.org/">Bugzilla</a>에 대하여 알아야 할 필요가 있습니다. 다른 사람에게 "나는 firefox를 해킹하고 싶다"고 이야기하는 것 이전에 선별/<a href="ko/QA">QA</a>/버그찾기를 위하여 몇주 혹은 그 이상의 기간을 보낼줄 아는 것은 최소한 할수 있어야 합니다. 프로젝트가 어떻게 수행되는지 알아보는 것, 어떤 것에 대하여 선별하는지 배우는 것, 그리고 이 과정에서 배운 것들을 초기 선별 과정에 적용시키는 것은 
검토와 체크인을 통하여 여러분의 방법을 찾는데 크게 도움을 줍니다. 
여러분께서 닥치는대로 어떤 부분을 선택하여 작업을 시작하는 것은 일반적으로 최선의 선택은 아닐 것입니다. 어떤 부분이 잘 갖추어져 있는지, 어떤 부분이 추가적으로 필요한지 잘 살펴보시는 것이 해킹을 시작하는데 있어서 좋은 시작이 될 것입니다.
</p>
<h3 name="Build_the_Fox"> Build the Fox </h3>
<p>I could rehash what’s been better-written by others, but I won't. Start with the generic instructions <a href="ko/Build_Documentation">here</a>, make sure you use CVS trunk, and get the beast built. You need to be able to make this work before you attempt to take the next step. Yes, it isn’t trivial to build anything from Mozilla CVS, but if you can't figure it out even with help, you're probably not ready yet. I can go from "never compiling anything" to "building on Win32" in an hour or so.
</p>
<h3 name=".EC.86.8C.EC.8A.A4_.EC.BD.94.EB.93.9C.EC.9D.98_.EA.B5.AC.EC.A1.B0"> 소스 코드의 구조 </h3>
<p>자! 다음 질문은 "어디에 프로그램과 front-end 코드가 있나요?" 입니다. 
Firefox의 관련 코드는 <a class="external" href="http://lxr.mozilla.org/mozilla/source/browser/">여기</a>에 있으며, 
일반적인 front-end toolkit은 <a class="external" href="http://lxr.mozilla.org/mozilla/source/toolkit/">여기</a>에 있습니다. 
(여러분의 CVS tree에서 이것은 각각 <tt>mozilla/browser</tt> 과 <tt>mozilla/toolkit</tt> 입니다.)
</p>
<h3 name="Picking_bugs_to_work_on"> Picking bugs to work on </h3>
<p>Votes matter. Sort of. Sometimes its a simple matter to make it happen too, and if there's low-hanging fruit, pick it. Other times, bugs with "good first bug" in the status whiteboard are good places to go to find your way around. And, of course, stuff that annoys you is good too. Lots of good personal satisfaction involved there.
</p>
<h3 name=".EB.8F.84.EC.9B.80.EC.9D.84_.EC.96.BB.EC.9D.84_.EC.88.98_.EC.9E.88.EB.8A.94_.EA.B3.B3"> 도움을 얻을 수 있는 곳 </h3>
<p>많은 <span class="plain">개발자들</span>이 있는  <a class="external" href="irc://irc.mozilla.org">Mozilla IRC server</a>는 여러분께서 어떤 문제를 풀어내지 못할때 조언을 받을 수 있는 좋은 장소입니다. 
하지만, 다른 사람을 귀찮게 하기전에 우선 다른 좋은 장소들(lxr/bonsai/Google (그리고, 이 위키페이지))에서 답을 얻기 위해서 최선을 다하십시요. 
만일 "UI가 어떤식으로 보이나요?"와 같은 질문이라면 Mike Connor나 <a class="external" href="http://www.mozilla.org/projects/firefox/review.html">Firefox peer</a>에 물어보는 것이 가장 좋을 것이며, 이건 여러분의 사례를 같이 논의할 준비가 되었다는 것이겠습니다.
</p>
<h3 name="Changing_the_user_experience"> Changing the user experience </h3>
<p>If you're thinking of implementing a feature request, or changing behavior that will affect the user experience, it's best for everyone concerned to get feedback before you start. Talk to Ben Goodger, Mike Connor, or one of the other <a class="external" href="http://www.mozilla.org/projects/firefox/review.html">Firefox peers</a>, and get reaction or adjustments. If they say its a no, you've just saved yourself a lot of stress and resentment (based on how people who don’t follow this role have reacted to <i>review-</i> in the past).
</p>
현재 리비전 복원