As an initial step in creating the xSDK, we have written two draft community policies to help address challenges in interoperability and sustainability of software developed by diverse groups at different institutions.
xSDK community package policies [click here]– version 0.4.0, July 27, 2018
A set of mandatory policies (including topics of configuring, installing, testing, MPI usage, portability, contact and version information, open source licensing, namespacing, and repository access) that a software package must satisfy in order to be considered xSDK compatible. This designation informs potential users that the package can be easily used with other xSDK libraries and components. Also presented are recommended policies (including topics of public repository access, error handling, freeing system resources, and library dependencies), which are encouraged but not required.
- changes in version 0.4.0, July 27, 2018:
- Split policy M4 into 2 parts: M4 (portability to common platforms) and new policy R6 (package should document the versions of packages with which it can work on on which it depends)
- Revision to policy M7: language about open source licensing requirements
- New section on history of policies and summary of changes, misc minor edits
- changes in version 0.3.0, Nov 6, 2017: added 2 new policies (M15 and M16), changed naming convention to follow xSDK release number, minor typo edits
- changes in version 0.3, Dec 2, 2016: clear definition of xSDK member packages, misc minor edits
Provide feedback on draft community policies; please comment directly in the following Google doc: next draft: xSDK community package policies
xSDK community installation policies: GNU Autoconf and CMake options [click here] – version 0.3.0, Nov 6, 2017
A standard subset of configure and CMake options for xSDK and other HPC packages in order to make the configuration and installation as efficient as possible on standard Linux distributions and Mac OS, as well as on target machines at DOE computing facilities (ALCF, NERSC, and OLCF).
- changes in version 0.3.0, Nov 6, 2017: minor typo edits, changed naming convention to follow xSDK release number
- changes in version 0.2, Dec 19, 2016: requiring a ‘smoke test’ (policy #12), misc minor edits
Provide feedback on draft community policies; please comment directly in the following Google doc: next draft: xSDK community installation policies
History and impact of xSDK community policies
Prior to the xSDK effort, a user of multiple libraries could not reliably compile and link some of the representative libraries into a single executable because of unversioned, incompatible third-party header files, namespace collisions, and other inconsistencies, as discussed here. To overcome such difficulties, developers of all founding xSDK packages worked to determine these community policies. All xSDK packages fully implemented these policies in the current xSDK release.
Impact of xSDK community policies:
- Improved code quality, usability, access, and sustainability;
- Informing potential users that an xSDK member package can be easily used with other xSDK libraries and components;
- Providing a foundation for work on performance portability and deeper levels of package interoperability, as needed by next-generation scientific applications.
Join the xSDK community
We are actively soliciting contributions to the xSDK and feedback on draft xSDK community policies. Please comment on xSDK policies directly in the above Google docs; see the FAQ page for information on how to contribute packages.