...
In the past, for major DSpace releases, a release candidate is generated. In order for the release candidate to be tested, host institutions needed to install, deploy and test the release candidate on their own network. This process can provide a valuable verification of installation and migration instructions, but it also imposes a significant burden on each host institution that participates in the test. This burden lengthens the window of time required to conduct system testing.
What is required?
- Donor to fund the creation of 3 new publicly-accessible DSpace instances
- If cost is prohibitive, we could prioritize the DSpace 6 instance.
- Volunteer to manage the cloud instances within the operational budget (bandwidth, compute, etc)
- Creation of an automated code deployment process to update the instance based on changes to an active code branch.
- Changes could deploy on merge or could be re-deployed on a set schedule
- Creation of an automated data refresh process to keep content fresh and stable
- Similar to what is done for demo.dspace.org
- Creation of a mechanism for executing command line processes
- In the most recent 6.1 release, bugs were introduced into these batch processes. As part of a testathon, users should be able to validate the results of specific command line tasks.
Related Conversations
- DCAT Meeting August 2017
- DSpace Developer Meeting 2017-08-09
- The log of this conversation was truncated. See notes below.
...