The different repositories and their usage
The CVS repository for the main server
The Critical Team maintains a CVS repository of the current status of the main server. This has no direct connection to the other repositories and is more or less a backup to the repository on git.cacert.org.
This repository is the "master of what is". Only Critical Team has access to this one.
The GIT repository on git.cacert.org ("CAcert repository")
This repository is the "master of what should be".
Ideally the "release" branch should be identically to the CVS repository, but it is normal that they have temporary differences1.
This repository is maintained by the Software Assessment Team, but read access is public. Write access currently requires that the Software Assessor has SSH access to git.cacert.org.
The Software Assessors should synchronize this repository with the GitHub repository as they see it useful. So, the release branch should be merged into the GitHub repository after a patch has been applied. Probably it also makes sense to merge bug-branches from the GitHub repository into the CAcert repository once the development has made some progress, for example when testing is started.
Just in case that something very bad should happen to the GitHub repository, this is the backup to start over again.
The GIT respository at github.com ("GitHub repository")
The GitHub repository is the repository for everyday use.
Everyone can fork this repository, make some changes and then send a pull request to get their changes merged in. Senior members of the Software Development Team, as well as the Software Assessors, can commit directly into CAcert's repository and can therefor handle pull requests.
If you want to increase your chance of getting your pull request merged please consider this hints:
No pull request without bug number. The CAcert bugtracker system at https://bugs.cacert.org is the primary place to report and discuss bugs, extensions and change requests. Before you start working on code, create an issue at the bugtracker. Or select an open issue which still needs work...
Don't work on the release branch. The release branch is reserved for the Software Assessors. Development should be done in a branch based on the current release branch and named "bug-<IssueNumber>" (or similar).
Before commiting a pull request, consider doing a rebase of your bug branch. Especially if your development needs a bit more time, there is the chance that the release branch has changed in the meantime. If this has happened please consider to rebase your branch to the new release branch. This makes it considerably easier for Software Assessors to merge your branch for testing or releasing.
Only one issue per branch. A branch should only contain changes needed to fix one specific issue. If you want to deviate from this recommendation be sure to include extensive comments in your changes what the additional change is good for and why it is necessary. Remember, Software Assessors really hate having to guess about the intention of code parts!
Include comments. Even if you have only code for one issue in your branch, comments are usually a great idea! Just imagine that the Software Assessors are not half as brilliant as you are, and so need all the guidance you can give them to understand the code.
Software Assessors and senior developers
Hints for Software Assessors
These hints mainly cover the usage of GIT...
Synchronize the two repositories
Create a local clone of one repository, this becomes the "origin" remote: git clone ssh://git-dev.cacert/var/cache/git/cacert-devel.git
Add the other repository as second remote: git remote add github https://github.com/CAcertOrg/cacert-devel.git
Checkout a branch from one (in this example the second) repository: git checkout -b bug-1234 --track github/bug-1234
Push the branch into the other repository: git push origin bug-1234
... for example when a patch has been sent off to Critical, but is not yet applied (1)