-
Notifications
You must be signed in to change notification settings - Fork 564
New Trilinos Developers
When a new person is to begin contributing to Trilinos, they are typically expected to become familiar with and adhere to the policies listed on this wiki, and complete the Trilinos New Developer Process Checklist. The possible exception to this is if someone wishes to submit occasional pull requests against the project and not be deeply involved in the project. Even in this case, it is helpful to be aware of the policies and tools that have been adopted. For example, a pull request that has been tested using the checkin test script or pull request testing will have a better chance of being accepted into the code base than one that is untested, or was tested in other ways.
Thanks to GitHub, anyone can view Trilinos source code, as well as fork the repository and issue pull requests against the primary Trilinos repository (pull requests should be issued against the 'develop' branch, or some other branch negotiated with a Trilinos developer, but never the 'master' branch). Push access is not required to be a Trilinos contributor or developer. According to current policy, whether or when a new Trilinos developer is granted push access is determined by the new developer's mentor. That person will decide if the new developer requires push access, and if so, when they have completed sufficient training to be given push access. When appropriate, the mentor can request push access by sending an email to the Trilinos Framework mail list. Eventually all contributions to Trilinos will be via pull request. This will provide build and test feedback via pull-request testing on multiple platforms as well as easy access to review as needed.
Copyright © Trilinos a Series of LF Projects, LLC
For web site terms of use, trademark policy and other project policies please see https://lfprojects.org.
Trilinos Developer Home
Trilinos Package Owners
Policies
New Developers
Trilinos PR/CR
Productivity++
Support Policy
Test Dashboard Policy
Testing Policy
Managing Issues
New Issue Quick Ref
Handling Stale Issues and Pull Requests
Release Notes
Software Quality Plan
Proposing a New Package
Guidance on Copyrights and Licenses
Tools
CMake
Doxygen
git
GitHub Notifications
Mail lists
Clang-format
Version Control
Initial git setup
'feature'/'develop'/'master' (cheatsheet)
Simple centralized workflow
Building
SEMS Dev Env
Mac OS X
ATDM Platforms
Containers
Development Tips
Automated Workflows
Testing
Test Harness
Pull Request Testing
Submitting a Pull Request
Pull Request Workflow
Reproducing PR Errors
Addressing Test Failures
Trilinos Status Table Archive
Pre-push (Checkin) Testing
Remote pull/test/push
PR Creation & Approval Guidelines for Tpetra, Ifpack2, and MueLu Developers