Development/Branches

Our git repository has several branches:


 * master - the main development branch
 * libreoffice-X-Y - release branch, suited to release the X.Y product line (like libreoffice-3-4)
 * libreoffice-X-Y-Z - release branch, suited to release the concrete version (like libreoffice-3-4-0, to release 3.4.0)
 * integration/dev300_mXYZ - integration branch, to merge code from OpenOffice.org, or elsewhere [obsolete]
 * feature/NAME - topic (feature) branch, to develop a feature without changing any other branch
 * private/$GERRITUSERNAME/NAME private test branches etc.
 * distro/NAME/VERSION used by some linux distributions to manage additional patches
 * ports/PLATFORM/VERSION used for unofficial community ports, e.g. Doug's macOS 10.5 PPC port
 * aoo/trunk tracking commits at Apache OpenOffice (notes maintained by Caolán McNamara)

feature branches
The topic branches have the rules set by the maintainer of that; they are supposed to live for a short time, and are merged into master sooner or later. They may be re-based by their owners.

The master and release branches have more general rules, see below.

master

 * Anything can be committed or merged into it (of course as long as the author did her best to make sure it builds and does not break the tests; running "make check" is recommended to ensure that)
 * No review required, but it's possible to ask for review by pushing to gerrit (recommended for inexperienced developers)

libreoffice-X-Y

 * Branch created with the first beta
 * Only fixes go in, no features
 * Exception for the late features: 3 approvals from people with different affiliation than the original author
 * No review required while in beta stage/until creation of first release candidate
 * 1 review from a reviewer other than the author required after the last beta
 * the best way to get patches reviewed is to "git cherry-pick -x" a commit from the "master" and push it to gerrit (use "git cherry-pick -Xignore-all-space -x" if you get conflicts, but you think you should not)
 * Any source of the patch goes - be it a patch sent to the mailing list, pasted via pastebin, a cherry-pick from master, or cherry-pick from any other branch
 * The reviewer pushes to the branch [unless the reviewer and author agree on something else ;-)] with the appropriate Signed-off-by: tag [use the "-s" option of git commit or git cherry-pick ;-)] (or just "submit" in gerrit which adds Reviewed-by tag)
 * No merges back to anything

libreoffice-X-Y-Z

 * Branch created with the "semifinal" RC (see the release plan)
 * Preferably just translation or blocker fixes
 * 2 additional reviews [Q: wouldn't actually just 1 additional be enough?]
 * Only cherry-picking from libreoffice-X-Y, the 2nd reviewer pushes
 * No merges back to anything