Daily PETSc testing output
Following PETSc development
The default branch in the PETSc repository is named master.
It contains all features and bug fixes that are believed to be stable and will be in the next release.
Users developing software based on recently-added features in PETSc should follow
$ git clone https://bitbucket.org/petsc/petsc $ cd petsc $ git pull # to get updates
Features that are still experimental will be in the next branch.
To use these features, and perhaps influence their design, follow
next and discuss your concerns on the petsc-dev mailing list or by commenting on commits. After cloning, use
$ git checkout next $ git pull # to get updates
git checkout master to get back to the more stable version.
Production users can follow the maint branch, which contains the latest maintenance release plus any additional bug fixes. It should always be more stable than the latest tarball.
Contributing to PETSc
By submitting code, the contributor gives irretrievable consent to the redistribution and/or modification of the contributed source code as described in the PETSc open source license. http://www.mcs.anl.gov/petsc/petsc-dev/CONTRIBUTING
Please read the code standards chapter of the developer guide before sending patches. http://www.mcs.anl.gov/petsc/developers/developers.pdf
Suggestions for a smooth review of your contributed code:
- If adding features, include tests which cover them.
- Test your changes by running with valgrind (use
--download-mpichto obtain a valgrind-clean MPI implementation).
- Test your changes with non-standard configurations of PETSc (in particular,
- If your contribution can be logically decomposed into 2 or more separate contributions, submit them in sequence instead of all at once.
PETSc Development Workflow
If you have direct write (push) access to the PETSc repository, you should be familiar with our development workflow. We use a simplified version of the
next workflow used by the Linux kernel developers. This allows parallel development of multiple features at the same time while preserving a stable
master branch. The model is explained in gitworkflows(7) (but we do not currently use a
"Git commands are like irregular verbs in a foreign language: there’s no all-encompassing logic to them, you just have to memorize which words you need for each thing you want to express."
"Git is TeX, what we need is someone to come along and produce LaGit and thus make it usable."
"Git is the perl of revision control systems."
"A mistake most beginning git users make is thinking git is a complete revision control system; it is not. Git, plus an organized mailing list that people actually respond to action items on, plus a rigid set of stylized bookkeeping done by each developer, plus a tyrannical manager of the entire software development process is a complete revision control system."