This page documents at a very high level how to contribute to ParaView. Please check our developer instructions for a more detailed guide to developing and contributing to the project, and our ParaView Git README for additional information.
The ParaView development cycle is built upon the following components:
Issues identify any issues including bugs and feature requests. In general, every code change should have an associated issue which identifies the bug being fixed or the feature being added.
Merge Requests are collections of changes that address issues.
Labels are labels or tags that can be added and removed to/from issues and/or merge requests to annotate them including indicating their state in the development cycle. See Labels Glossary.
Milestones refer to development milestones such as numbered public releases, or named internal releases.
If you have a bug report or a feature request for ParaView, you can use the issues tracker to report a new issue.
To report an issue.
triage:needinfo
label and add a comment for the reporter soliciting more
information. Once the reporter has provided the necessary information, he/she
should remove the triage:needinfo
label from the issue to notify the
development team.When a developer starts working on an issue, the developer will add the
workflow:active-development
label. Once the development is complete and the issue
resolved, the issue will be closed, and the workflow:active-development
label
will be replaced by workflow:customer-review
. At that point, the reporter can
checkout the latest master
and confirm that the issue has been addressed. If so,
the reporter can remove the workflow:customer-review
label. If the issue was not
addressed then the reporter should reopen the issue or solicit more information
from the developer by adding the triage:needinfo
label.
To keep the number of open issues manageable, we will periodically expire old issues
with no activity. Such issues will be closed and tagged with the label
triage:expired
. Such issues can be reopened if needed.
For every issue, project managers can assign:
project:...
label to indicate which project this issue is necessary for. An issue
may have multiple projects associated with it.priority:...
label to indicate how critical is this issue for the specific
milestone, ranging from priority:required
, priority:important
,
priority:nice-to-have
, and priority:low
. Only one priority label makes
sense at a time.For every issue, developers can assign:
area:...
labels to indicate which area this issue relates to e.g. area:web
,
area:catalyst
, etc.triage:...
labels to indicate issue triage status. triage:confirmed
is added
when the issue has been confirmed. triage:easy
is added for issues that are
easy to fix. triage:feature
is added to issues that are new feature requests.
triage:needinfo
is added to solicit more information from the reporter.triage:needinfo
label on closed issues means the reporter or reviewer is
requesting more information from the developer before the fix can be reviewed.
Please provide such information and then remove the label.workflow:active-development
label should be added to issues under development.Typically, one addresses issues by writing code. To start contributing to ParaView:
Register GitLab Access to create an account and select a user name.
Fork ParaView into your user's namespace on GitLab.
Create a local clone of the main ParaView repository. Optionally configure Git to use SSH instead of HTTPS. Then clone:
$ git clone --recursive https://gitlab.kitware.com/paraview/paraview.git ParaView
$ cd ParaView
The main repository will be configured as your origin
remote.
For more information see: Setup and download instructions
Run the developer setup script to prepare your ParaView work tree and create Git command aliases used below:
$ ./Utilities/SetupForDevelopment.sh
This will prompt for your GitLab user name and configure a remote
called gitlab
to refer to it. Choose the defaults for ParaView Data questions.
For more information see: Setup
Build Paraview and run it.
Edit files and create commits (repeat as needed):
$ edit file1 file2 file3
$ git add file1 file2 file3
$ git commit
Commit messages must be thorough and informative so that reviewers will have a good understanding of why the change is needed before looking at the code. Appropriately refer to the issue number, if applicable.
For more information see: Create a Topic
Push commits in your topic branch to your fork in GitLab:
$ git gitlab-push
For more information see: Share a Topic
Run tests with ctest, or use the dashboard
Visit your fork in GitLab, browse to the "Merge Requests" link on the left, and use the "New Merge Request" button in the upper right to create a Merge Request.
For more information see: Create a Merge Request
Follow the review process to get your merge request reviewed and tested. On success, the merge-request can be merged and closed.
For more information see: Review a Merge Request
When a merge request is closed, any related issue should be closed (if not
closed automatically) and assigned the workflow:customer-review
label to
request a review from the reporter.
Monitor the related issue for any triage:needinfo
label additions to provide
the customer with any details necessary to test the fix.
Our Wiki is used to document features, flesh out designs and host other documentation. We have a ParaView Discourse forum to coordinate development and to provide support.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。