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 1.0.0, February 17, 2023

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 1.0.0, February 17, 2023:
    • Made R1 (must have a public repository) mandatory, merging it into M10.
    • Converted R8 (documentation) to a new mandatory policy (M17).
    • Added new recommended policy requiring a validation test, replacing R1.
    • Added new recommended policy (provide version comparison preprocessor macros), replacing R8.
    • Added wording to M13, clarifying the requirement and providing motivation for the policy.
    • Added clarification to R5, giving rationale for the policy and an example of how to meet the requirement.
    • Minor wording/grammar changes were made to M7 and R2, without changing meaning.
  • Changes in version 0.6.0, October 12, 2020:
    • Added new policy R8 on documentation quality
    • Merged policies M1 and M16 with emphasis on use of Spack as xSDK installer
    • Eliminated installation policies which were included in previous M1, provided a document with xSDK Spack installation guidelines
    • Added new policy M16, which requires an xSDK package to have a configuration option to be built in debug mode, a requirement previously included in the eliminated installation policies
  • Changes in version 0.5.0, June 29, 2019:
    • Added new policy R7, which recommends the inclusion of various information files in the top directory
    • Dropped the requirement in policy M3 to detect MPI 2 features
    • Made various editorial changes in policies R2, M5, M13 and M15 for clarification or to fix typos
  • 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 and 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 open an issue or submit a pull-request:  xSDK Community Policies GitHub Repository

xSDK Spack variant guidelines [click here] – version 0.6.0, October 12, 2020

A standard subset of Spack variants 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).

Provide feedback on draft community policies; please open an issue or submit a pull-request:  xSDK Community Policies GitHub Repository

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.