Difference between revisions of "Release Planning"
From SCECpedia
Jump to navigationJump to search| Line 32: | Line 32: | ||
# Credit | # Credit | ||
# Curation | # Curation | ||
| + | |||
| + | |||
| + | == Steps To Software Product: == | ||
| + | # Create citable, definitive version of software with doi, license, and repository. | ||
| + | # Define reference publication used to cite software. | ||
| + | # Define software as reference implementation of a method, and define a set of approved software acceptance/regression tests that can be used to establish a software implements that “method”. | ||
| + | # Create software maintenance organization with commit authority for pull requests and approval process for change requests, and process of approving new releases. | ||
| + | # Establish software community through registrations, newsletters, activity, regular calls, regular meetings, define community and roles. | ||
| + | |||
| + | == Adoption of Fork and Pull Git Repo Model == | ||
| + | * Use the model used by the majority of open-source projects (including pyCSEP). | ||
| + | * The “maintainer” of the shared repo assigns rights to “Collaborators” | ||
| + | * Collaborators do not have push access to main (upstream) repo | ||
| + | * Core development teams accepts (PRs) from collaborators, reviews them, then merges them into main repo | ||
| + | |||
| + | == Contributor Process: == | ||
| + | Working with shared projects on GitHub | ||
| + | # Fork the repository | ||
| + | # Clone your forked copy | ||
| + | # Sync your personal repo with shared repo | ||
| + | # Git merge/git rebase | ||
| + | # Make a contribution | ||
| + | # Pull request | ||
Revision as of 00:02, 22 October 2021
Contents
Fork and Pull Development
Using the fork and pull method, start with fork of sceccode/ucvm.git into personal repo. Then, to do development on CARC, plan to clone pjmaechling/ucvm.git for development. Set git upstream to original repo sceccode/ucvm.git to keep in sync with that repo. Follow Instruction for setting upstream here:
Development on CARC
- ssh -o "ServerAliveInterval 60" username@discovery.usc.edu
- cd /project/scec_608/maechlin/dev
- git clone https://github.com/pjmaechling/ucvm.git
- adding codemeta.json file.
- add Contributors.MD file.
- add MODULES.md file to explain how CARC load modules are configured to work
- Follow UCVM installation instructions: Install Wiki
- Install Notes on Discovery
Compiling
- the source directory /project/scec_608/maechlin/dev/ucvm
- the installation directory /project/scec_608/maechlin/ucvm_bin
When someone is looking at your project, they want to know:
- what is it?
- how good the code is?
- how much support is available?
- what’s included?
- what does it look like?
- how set it up?
Science Code Manifesto Elements:
- Code
- Copyright
- Citation
- Credit
- Curation
Steps To Software Product:
- Create citable, definitive version of software with doi, license, and repository.
- Define reference publication used to cite software.
- Define software as reference implementation of a method, and define a set of approved software acceptance/regression tests that can be used to establish a software implements that “method”.
- Create software maintenance organization with commit authority for pull requests and approval process for change requests, and process of approving new releases.
- Establish software community through registrations, newsletters, activity, regular calls, regular meetings, define community and roles.
Adoption of Fork and Pull Git Repo Model
- Use the model used by the majority of open-source projects (including pyCSEP).
- The “maintainer” of the shared repo assigns rights to “Collaborators”
- Collaborators do not have push access to main (upstream) repo
- Core development teams accepts (PRs) from collaborators, reviews them, then merges them into main repo
Contributor Process:
Working with shared projects on GitHub
- Fork the repository
- Clone your forked copy
- Sync your personal repo with shared repo
- Git merge/git rebase
- Make a contribution
- Pull request
