Without getting into the specifics of any particular release cycle, here's basically how Firefox development for a particular release works.
At the front end of any release cycle is a period of discussion and planning. People talk about the set of features and bugs to be implemented during the coming development cycle. Once a set of features is decided upon, and developers found to work on them, development can begin. All Firefox feature planning should be done in the dev-apps-firefox mailing list/group.
Development occurs over the milestones listed in the section below. The general engineering process applies. Features are proposed and discussed on the mailing lists. Design Documents and User Interface Specifications are created on the Mozilla Wiki. Features are broken into tracking bugs and work is done. All technical discussions should be had in the dev-apps-firefox mailing list/group.
Aside from release candidates, each release typically has four major milestones:
The preliminary alpha contains a developer-centric preview of content in the final release, although it can and likely will change drastically. The "dogfood" designator means that the build should be usable for daily browsing activities, even if there are significant bugs or missing features.
The second alpha should be fundamentally feature complete. Every major feature to be present in the release should have some working version of it in this. There may be bugs. This is also intended for a limited/developer-focused audience.
Features in this release are more or less in the state they will be for the final. This release is for a wider audience and should be of high quality. No new features can be added after this point, they must wait for the next release. At this point development usually branches from the "trunk" so that work can proceed on the next major release.
This release is fully UI complete and has the final set of strings present in it so that localizers can begin creating localizations for the final release. After this point only critical bugs are accepted.
Prior to any release, the bits to be shipped are "baked" (tested with no changes taken for a period of time - which can be very short for alpha releases and very long for final releases). During this time release candidates are used for wider testing and discovery of potential stop-ship bugs before RTM.
During "freeze" periods either before an imminent release or after beta1, drivers begins approving patches for checkin. Only approved patches can be landed during this time. By doing this, drivers helps ensure the quality of the release by preventing late landings of unapproved or risky changes.