Release Planning - Revision history

Maechlin: /* Development on CARC */

2021-11-06T06:09:08Z

Development on CARC

Maechlin at 00:03, 22 October 2021

2021-10-22T00:03:41Z

Maechlin at 00:03, 22 October 2021

2021-10-22T00:03:14Z

Maechlin at 00:02, 22 October 2021

2021-10-22T00:02:43Z

Maechlin at 00:02, 22 October 2021

2021-10-22T00:02:09Z

Maechlin at 00:01, 22 October 2021

2021-10-22T00:01:19Z

Maechlin: Created page with "== 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 pjmaech..."

2021-10-22T00:00:53Z

Created page with "== 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 pjmaech..."

New page

== 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:
*[https://github.com/billtron/pycsep_git_tutorial Savran Git Tutorial]

== 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: [https://github.com/SCECcode/UCVMC/wiki/Installation-From-Source-Code Install Wiki]
*[https://strike.scec.org/scecpedia/UCVM_Install 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?

← Older revision		Revision as of 00:03, 22 October 2021
Line 102:		Line 102:
	Toolbox documentation should describe the steps off analysis in a pedagogical, narrative		Toolbox documentation should describe the steps off analysis in a pedagogical, narrative
	fashion, with example data that users can load to follow along with and understand the documentation.		fashion, with example data that users can load to follow along with and understand the documentation.
		+
		+
		+	== UCVM Implements Multiple Test Types: ==
		+	# Functional tests – Unit Tests essential core ucvm functions
		+	# Integration Tests – Test utilities including meshing, layer searches, gtls, and performance
		+	# Model Tests - Each velocity model has tests showing expected results for some points
		+	# Example program - Examples programs and scripts showing working examples of ucvm capabilities.
		+	# Acceptance tests – Confirm results on users system. Maybe union of funcational, integration, and model tests.
		+
		+
		+	== Standardized Testing Plan ==
		+
		+	# Unit Testing – test a small functional units
		+	# Regression Testing – ensure a fixed bug remains fixed
		+	## Core system regression tests
		+	##Model specific regression tests
		+	# Integration Testing – CI test suites
		+	## Tests run after each commit
		+	## Tests run after pull request
		+	# Performance and Benchmarking Tests
		+	# Acceptance Testing
		+	## Tests provided with models that show expected results
		+	## Tests provided with pull request that confirm the changes
		+	## Tests that confirm a new release must pass
		+	## Tests that software performs correctly on user environment
		+
		+	== Recommended Basic Software Practices: ==
		+	# Training on Software Practices
		+	# Code in a Code Repo
		+	# Automated Testing
		+	# Persistent ID for software versions

← Older revision		Revision as of 00:03, 22 October 2021
Line 83:		Line 83:
	* METADATA - Software metadata (CodeMeta), Citation File (CFF), "references" (dependencies)		* METADATA - Software metadata (CodeMeta), Citation File (CFF), "references" (dependencies)
	* PROJECT DOCUMENTATION - Rationale, teams, governance, community (contact, code of conduct)		* PROJECT DOCUMENTATION - Rationale, teams, governance, community (contact, code of conduct)
		+
		+	== Where Documentation Lives ==
		+	Documentation lives where the source code lives! (This is never in an email, chat, or similar!)
		+
		+	Conceptual Documentation:
		+	* Requirements
		+	* Projects
		+	Hands-on documentation
		+	* How-tos, getting started
		+	* Templates for issues, pull/merge
		+	* Contribution guidelines
		+	Reference documentation
		+	* API
		+	* Tests
		+	* Metadata
		+
		+	== Toolbox Documentation: ==
		+	Toolbox documentation should describe the steps off analysis in a pedagogical, narrative
		+	fashion, with example data that users can load to follow along with and understand the documentation.

← Older revision		Revision as of 00:02, 22 October 2021
Line 55:		Line 55:
	# Make a contribution		# Make a contribution
	# Pull request		# Pull request
		+
		+
		+	== How we want it Cited: ==
		+	* Example Citation:
		+	* Example Acknowledgements:
		+	* Example Reference:
		+
		+	== Basic Recommendations: ==
		+	# Make source code publicly accessible
		+	# Make software easy to discover by providing software metadata via a popular community registry (Examples of community registries of software metadata are bio.tools (Ison et al., 2016), (Ison et al., 2016) biojs.io (Corpas et al.,2014; Gómez et al., 2013) and Omic Tools (Henry et al., 2014) in the life sciences and DataCite (Brase, n.d.) as a generic metadata registry for software as well as data.
		+	# Adopt a license and comply with the license of third party dependencies
		+	# Define clear and transparent contribution, governance and communications processes (For instance the Galaxy project’s website describes the team’s structure, how to be part of the community, and their communication channels.)
		+
		+	== Types of Documentation with axis: ==
		+	* help learning – help working
		+	* theoretical knowledge – practical knowledge
		+	# tutorials - learning oriented
		+	# how-to guides – task-oriented
		+	# Background/Concept explanations – understanding-oriented
		+	# technical reference – information-oriented
		+
		+	== DOCUMENTATION TYPES ==
		+	* CODE DOCUMENTATION - Semantic identifiers, comments, API, engineering, dependencies, requirements
		+	* USER DOCUMENTATION - How to get, run, use the software; parameters, data model, etc.; license
		+	* MAINTENANCE DOCUMENTATION - How to build, release, review code, publish
		+	* DEVELOPER DOCUMENTATION - How to contribute, contribution templates (issues, pull/merge requests)
		+	* METADATA - Software metadata (CodeMeta), Citation File (CFF), "references" (dependencies)
		+	* PROJECT DOCUMENTATION - Rationale, teams, governance, community (contact, code of conduct)

← Older revision		Revision as of 00:02, 22 October 2021
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

← Older revision		Revision as of 00:01, 22 October 2021
Line 25:		Line 25:
	# what does it look like?		# what does it look like?
	# how set it up?		# how set it up?
		+
		+	== Science Code Manifesto Elements: ==
		+	# Code
		+	# Copyright
		+	# Citation
		+	# Credit
		+	# Curation

@@ Line 6: / Line 6: @@
 * ssh -o "ServerAliveInterval 60" username@discovery.usc.edu
 * cd /project/scec_608/maechlin/dev
-* git clone https://github.com/pjmaechling/ucvm.git
+* git clone https://github.com/sceccode/ucvm.git
 * adding codemeta.json file.
 * add Contributors.MD file.