Confirmed users
63
edits
Firefox Developer Onboarding Tips: Difference between revisions
Jump to navigation
Jump to search
no edit summary
m (Bhearsum moved page Firefox Developer Onboarding to Firefox Developer Onboarding Tips) |
No edit summary |
||
| Line 13: | Line 13: | ||
** stuff you wish you did first, second, third | ** stuff you wish you did first, second, third | ||
* Your learning experiences when you started. | * Your learning experiences when you started. | ||
** Put your developer | ** Put your developer onboarding advice here or link out to your blog, perhaps describing your first few weeks. | ||
=== Where to Ask Questions === | |||
* [http://ask.mozilla.org ask.mozilla.org]. It is new, but still an excellent place for questions. | |||
=== Garvan's Gecko Onboarding Tips === | |||
==== Baby Steps ==== | |||
* [http://codefirefox.com codefirefox.com] | |||
** A series of ~5 min videos covering getting started on the codebase | |||
** The single most important thing for me. My favorite vids: mercurial queues and submitting patches. My prior hg experience was minimal, so this really helped get me up to speed quickly. I am/was an svn guru, which is no use for new life in open source land, where it is all dvcs. | |||
* [https://developer.mozilla.org/en/docs/Simple_Firefox_build Getting the code and compiling] | |||
** Refer to pages for pulling the code, setting up a mozconfig, building with mach build. I can't say I had any problems with this area. I make sure to enable debugging, and disable optimization. You pull, you ./mach build, you ./mach run. Tip: on Linux platforms with python3 as the default, you 'python2 mach build'. | |||
** You will be pulling mozilla-central. You don't push to this directly, you submit patches to bugs. | |||
** hg pull -u && ./mach build => a thing to do periodically when you are stepping away for a bit | |||
* Debugging the code | |||
** I am on OS X, using LLDB. Wasted a ton of time because I didn't read the [https://developer.mozilla.org/en-US/docs/Debugging_Mozilla_with_lldb tip about setting the right lldb init]. The build process uses unified sources (concat cpp files together to reduce # of object files and speed up the build). | |||
** On my own code, I would prefer to just read through it, but on a large confusing codebase -I can think of one :)- I need to step through code, and I need to run it and print functions that are being hit, and try to visualize how the pieces fit together. I don't have time for printf and build, and I don't like setting tons of breakpoints in gdb that print when I know how quickly I can do this in an IDE. I use Xcode a lot for this. | |||
* Editing code | |||
** This is an individual preference. Most use Emacs or Vim. I switch between MacVim and JEdit, but code mostly in Xcode, because I have worked with it since 1.x. | |||
** Browsing/Searching the code base, [http://mxr.mozilla.org mxr] and [http://dxr.mozilla.org dxr] (same thing, 2 approaches). I don't go a day without using these, even though I have code indexing in Xcode. | |||
* [https://wiki.mozilla.org/ReleaseEngineering/TryServer Try Server] | |||
** The answer to the question: How do I test my local changes? | |||
** You will test your code to see if compiles and passes the tests using this. You will need to sign a document to get access (to submit it I took a picture). | |||
** Once you are comfortable, I use a wee script for this (I would try in batches, so I'll change the Try request from time to time). | |||
** I use the [http://trychooser.pub.build.mozilla.org TryChooser Syntax Builder] to create the try string. | |||