We are at that moment in the release cycle where knowing at least a little bit about the release cycle is in order. I do better when I have an image or symbol to work with so I created the above graphic.
I went with the image of a nautilus shell for two reasons. One, it is pretty and I like it as a visual and two, it is an interesting symbol of a process that is continually growing and expanding but also has to house the nautilus and keep it safe while constant construction is occurring.
The main spiral represents the master branch of the code, the red arrow indicating the direction of its progress based upon the path it has traveled until that point. The curved intermediate walls (called sutures, I believe) represent the release-branches. The release of Grizzly is coming up in April and is represented above by the green wall/release-branch. Prior to Grizzly was Folsom, in blue, and Essex, in orange.
We just went through code freeze and I do believe breaking off the master branch to create the first release candidate is imminent. After the release candidate is broken off, pushing patches for bug fixes gets interesting.
When in doubt of how to submit patches with gerrit, contact the project leader for the project in question. My basic understanding is that the bugs submitted against the release candidate need the patch applied first to the master branch and the backported to the milestone-proposed branch. Again, talk to the project lead to ensure you are using the correct gerrit commands for the patch to apply to the correct branch: master or milestone-proposed.
I will be working my way through this process for the first time, so this post might go through an edit or two as my understanding matures.
Thanks for supporting this GNOME OPW intern,