Policies

xSDK community

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.3.0, Nov 6, 2017

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.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 (ALCFNERSC, 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.