The master branch
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 master:
$ git clone https://gitlab.com/petsc/petsc$ cd petsc$ git pull # to get updates
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.
Hints for Developers
We use labels to track related groups of activities. To follow labels (such as GPU or DMNetwork) go to https://gitlab.com/petsc/petsc/-/labels and click Subscribe on the right side of the table. All merge requests and issue submissions should supply appropriate labels.
For MR the test pipeline status is displayed near the top of the MR page
Please report all "odd" errors in the testing that don't seem related to your branch in issue #360.
Check the current current threads to see if it is listed and add it there, otherwise create a new thread
Also put a message like "This is related to CI (#360)", in your MR/issue than it will automatically appear in the #360 discussion, which helps to track what's going on at the moment.
Note that the retry button does NOT use any changes to the branch when it retries, it retries exactly what it previous tried. To test a fix on one or several specific systems: push the branch and start a new pipeline, immediately cancel that pipeline and select individual jobs to retry (using the little retry button to the right of job name).
For errors that occur in the cloud testing you can use
docker run -it --rm -v $(pwd):/build jedbrown/mpich-ccache bash
which will drop you into a container with the PETSc repository as the working directory in the container.
Submit merge requests for suggestions on design etc
You do not need to test the code before submitting
Make sure to select WIP at the top of the MR page
select the additional label Workflow:Request-For-Comment
There is also a button Add a task list (next to numbered list) if you edit any Markdown-supporting text area. You can use this to add task lists to a WIP MR.
Merge request review process
It is the submitters responsibility to track the progress of the MR and insure it gets merged to master (or maint). If the pipeline tests detect problems it is the submitters responsibility to fix the errors.
Gitlab merge requests (MR) use "threads" to track discussions on MR. This allows Gitlab and reviewers to track what threads are not yet resolved
When introducing a new topic (thread) in reviewing a MR make sure you submit with Start thread and not Comment green buton.
When responding to a thread make sure to use Reply box for that thread, do not introduce a new thread or a comment.
The submitters must mark threads as resolved as they fix the related issue.
If the submitter feels the MR is not getting reviewed in a timely manner they may Assign ((upper right corner of the screen) to potential reviewers and request in the discussion these same people to review by @ mentioning them.
When the merge has been approved, all the tests work, and all the threads have been resolved the submitter must set a label to Workflow:Ready-For-Merge and assign (upper right corner of the screen) the MR to Satish so he can merge it.
Hints for reviewers
It is possible to supply suggested changes for a MR that submitters can simply click to accept, saving time for both developers and reviewers. Often this is better than just typing the suggestion into comment box and hoping the submitter will understand it and transcribe it correctly into the MR. The material below on how to provide such suggestions was provided by Vaclav Hapla @haplav.
Add a comment to some line within the region you want to change (usually the last line)
Click , you get
You can alter the line
The suggestion is relative to the commented line. You can do a multi-line change by altering -0+0 to something else. - are lines before, + are lines after the current (commented) line
Notes on setting up test machines for PETSc gitlab-CI
This is for developers who are donating time on their systems for PETSc testing.
Have ccache installed and in the path
Have both python 2 and 3 installed, both with cpython
Have X11 including the libraries installed
Have an OpenGL set of libraries installed
Insure your machine has sufficient swap space, if that is low you may see tests killed with signal 9 by the OS
If you are using a licensed compilers make sure the license server is fast enough to serve the source code and example compiles.
It is generally preferable to compile and link code on local disk as opposed to using a NFS mount.