-
Notifications
You must be signed in to change notification settings - Fork 0
archive The source code control commit policy
This document outlines the commit policy developers absolutely must follow when committing code to the source repository.
- Andrew Beekhof
- Christine Caulfield
- Steven Dake
- Jerome Flesch
- Jan Friesse
- Jim Meyering
- Fabio M. Di Nitto
- Ryan O'Hara
- Angus Salkeld
- Fabien Thomas
No developer other then Steven Dake should commit any change to the tags branch. This repository is used to tag a specific version of the software for upstream consumption.
No developer other then Steven Dake should commit any change to the flatiron branch. This branch is not meant for any development. Only ports from trunk should be merged into this tree.
Any developer may commit a change to this branch under the following condition:
- The patch has been mailed to the mailing list and has atleast one reviewed acknowledgment
- The patch has been submitted for review for at least 1 work day. Work days are defined as days occurring between Monday through Friday (GMT-7).
- The patch does not break the build on Linux platforms.
- Patches that address portability should be tested on various platforms before commit. Ask community members to test the patch on their platforms in this case please.
If you are interested in updating or modifying the wiki website, please mail Steven Dake (sdake@redhat.com). He will add you as a writer to the wiki website if you have shown interest in the project.
Developers earn source code commit access by posting patches to the mailing list and joining the developer community in furthering the goals of the Corosync Cluster Engine. An invitation will be extended and a process must be followed to gain a Fedora commit account. If you feel you have earned commit access, please mail Steven Dake (sdake@redhat.com) to discuss further.
The purpose of this policy is to:
- Evolve the trunk branch as rapidly as possible by spreading write access among many developers.
- Lock down all commits to stable branches to ensure an extremely high level of peer review for the stable changes.