mozilla

Revision 140178 of Hacking Firefox

  • 리비전 슬러그: Hacking_Firefox
  • 리비전 제목: Hacking Firefox
  • 리비전 아이디: 140178
  • 제작일시:
  • 만든이: Babyworm
  • 현재 리비전인가요? 아니오
  • 댓글 /* 기본에서부터 시작하기 */
태그: 

리비전 내용

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


기본에서부터 시작하기

해킹을 시작하기 전에 우선 Bugzilla에 대하여 알아야 할 필요가 있습니다. 다른 사람에게 "나는 firefox를 해킹하고 싶다"고 이야기하는 것 이전에 선별/QA/버그찾기를 위하여 몇주 혹은 그 이상의 기간을 보낼줄 아는 것은 최소한 할수 있어야 합니다.

Discovering how the project works, learning to sift for what matters, and applying lessons learned in the initial triage process will go a long way to finding your way through reviews and checkin. Picking something you find randomly isn't usually the best thing to start with. Seeing what's well-owned and what needs extra attention is also a good starting point for hacking.

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.

Source code organization

The next problem is "where does the app/front-end code live?" Firefox-specific code lives here, and generic FE toolkit code lives here. (In your CVS tree, it would be <tt>mozilla/browser</tt> and <tt>mozilla/toolkit</tt>, respectively.)

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.

Knowing where to ask for help

#developers on the Mozilla IRC server is a good place to start if you can't figure it out on your own. But exhaust other resources first, like lxr/bonsai/Google (and this wiki) before you bug real people. If it's a "how should the UI look" question, asking Mike Connor or another Firefox peer is probably your best plan, unless you're ready to argue your case.

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><p>Discovering how the project works, learning to sift for what matters, and applying lessons learned in the initial triage process will go a long way to finding your way through reviews and checkin. Picking something you find randomly isn't usually the best thing to start with. Seeing what's well-owned and what needs extra attention is also a good starting point for hacking.
</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="Source_code_organization"> Source code organization </h3>
<p>The next problem is "where does the app/front-end code live?" Firefox-specific code lives <a class="external" href="http://lxr.mozilla.org/mozilla/source/browser/">here</a>, and generic FE toolkit code lives <a class="external" href="http://lxr.mozilla.org/mozilla/source/toolkit/">here</a>. (In your CVS tree, it would be <tt>mozilla/browser</tt> and <tt>mozilla/toolkit</tt>, respectively.)
</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="Knowing_where_to_ask_for_help"> Knowing where to ask for help </h3>
<p><span class="plain">#developers</span> on the <a class="external" href="irc://irc.mozilla.org">Mozilla IRC server</a> is a good place to start if you can't figure it out on your own. But exhaust other resources first, like lxr/bonsai/Google (and this wiki) before you bug real people. If it's a "how should the UI look" question, asking Mike Connor or another <a class="external" href="http://www.mozilla.org/projects/firefox/review.html">Firefox peer</a> is probably your best plan, unless you're ready to argue your case.
</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>
현재 리비전 복원