Development:Contributor Overview

From Camino Wiki
Jump to navigation Jump to search

This page will be one of the main pages of the dev-wiki; it will walk a new contributor through the process in an overview fashion, pointing to the detailed information on each part in the separate docs, e.g. building/setting up your dev environment, choosing a bug, coding, getting reviews.

Things in the lists below the text are the pages we should link to

We should also see if there's anything useful on, either for this page itself or for the subpages we're going to refer to; this page is intended to replace

This page is not complete.


Welcome to Camino. Interested in becoming a contributor? We're glad to have you on board. This page documents some basic information on how to make the leap from Camino fan to Camino dev, from getting Camino built, to picking out bugs to fix, to getting patches written and checked in. Even if you've contributed to Mozilla-based projects before, you may find this information useful, as much of it is Camino-specific.

Setting up your development environment

Like most complex pieces of software, the Mozilla project requires a flexible build system, which is not always straightforward. Unlike many open-source projects, ./configure; make does not suffice. Similarly, Camino, which embeds the cross-platform Gecko engine in a Cocoa application, depends on a somewhat hybrid build system; in other words, unlike other Cocoa apps, simply opening Xcode and clicking build won't produce a complete Camino application.

While this may seem daunting at first, the system is quite logical and there's very little effort involved in making it work. Gecko is built entirely using UNIX-style makefiles, and the Camino application code can be built either via makefiles or with Xcode once Gecko has been built (for the curious, this provides an overview of the Mozilla build system from a technical perspective).

Setting up your development environment entails installing the latest Xcode and appropriate SDKs, installing the three third-party dependencies, setting up your build options, and pulling cvs and building. The following documents will guide you through these steps.

Choosing a bug

All decisions concerning which bugfixes and features should be implemented in Camino are made in the bugzilla bug-tracking database, on, channel #camino (or during weekly meetings in #camino-mtg), or during annual Camino face-to-face meetings.

  • Something that bothers you, something on good first bugs, something that needs to be fixed...

Good First Bug vs. Triage Priority

The "Good First Bugs" list is a list of "bugs" (problems or feature requests) that are good entry points for new Camino developers, not necessarily a list of the bugs that need to be fixed most urgently. A bug's priority is determined (roughly) by the severity field, the priority field (used generally by developers to prioritize lists of bugs assigned to them), the target milestone, and the blocking flags. For instance, bugs with a target milestone of Camino 1.6 are generally most important at the moment, and ones with higher severity (or a camino1.6+ or camino1.6? flag) are the most important of those.

Working on a bug

  • When to take a bug, and how to do it (some of this is in the existing cbo dev pages)
  • Bugs with status NEW whose assignees are either and are fair game
  • Ask first before taking a bug with status NEW with any other assignee, or before taking a bug with status ASSI.

Coding a fix

Text, text, text

Getting Code Review and Checkin

Text, text, text

Links and Recommended Reading

  • Stuff from the sidebars in cbo/development (below)
  • Anything else?


  1. <a href="/development/" accesskey="I">Contributor Introduction</a>
  2. <a href="/development/programming/" accesskey="P">Programming</a>
  3. <a href="/development/build/" id="current" accesskey="B">Build Instructions</a>
  4. <a href="/development/roadmap/" accesskey="R">Roadmap</a>
  5. <a href="/development/structure/" accesskey="T">Team Structure</a>


Recommended Reading