Community Software Policies

IDEAS-Watersheds Software Policies (DRAFT)

The IDEAS-Watersheds Software Ecosystem policies are intended to enhance collaboration and coordination across independently-developed products to provide an enhanced high-performance software stack.

  • Each package must support portable installation through Spack. All configuration, build, and installation phases must be specified in a Spack package recipe. Packages should have a build system that is appropriate for the language (e.g.~ CMake, Autoconf, setup.py), and the packages should attempt to follow the best practices and guidelines of the respective environment. For example, a proper configuration phase should be used where relevant (a list of platform-specific makefiles would not be acceptable). It is recommended that packages have a mechanism for ‘smoke’ testing (e.g. make test_install).Packages must not override Spack’s resolved dependencies (as determined by spack spec). For example, if a BLAS library is part of the concretized spack spec, a package cannot silently substitute a different BLAS implementation. The goal of this policy is to enable easy and customizable installation of the package.
  • Each package must provide a comprehensive test suitethat can be run by users and does not require the purchase of commercial software. It is recommended that at least a significant subset of the test suite will complete within a few hourson standard workstation-level hardware. It is also recommended that at least a significant subset of the tests be runnable in batch-only environments, that is, systems that require the use of PBS or other submission scripts.
  • Each package that utilizes MPI must restrict its MPI operations to MPI communicators that are provided to it and not use directly MPI_COMM_WORLD. The package should use configure tests or version tests to detect MPI 3 features that may not be available; it should not be assumed that a full MPI 3 implementation is available. The package can change the MPI error-handling mode by default but should have an option to prevent it from changing the MPI error handling (which may have been set by another package or the application). The package should also behave appropriately regardless of the MPI error handling being used. There is no requirement that the package provide a sequential (non-MPI) version, although this functionality is welcome, too.
  • Each package team must do a “best effort” atportability to common platforms, including standard Linux distributions, and common compiler toolchains such as GNU, Clang,3and vendor compilers.
  • Each package team must provide a documented, reliable way to contact the development team; the mode of contact may be by email or a website. The package teams should not require users to join a generic mailing list (and hence receive irrelevant email) in order to report bugs or request assistance.
  • Each package should respect the decisions made by other previously called packages regarding system resources and settings.For example, each package may provide an API for changing the floating-point exception (FPE) and signal handlers, and even set them in a particular way by default, but there must be a way to prevent the change. Because it is impossible to determine the current state of the FPE and signal handlers and thus restore them to the current state after changing them, it is recommended that the packages adopt a common protocol for pushing and popping FPE and signal handlers.
  • The collaboration has a strong preference for packages to use an OSI-approved, permissive open-source license(e.g., MIT or BSD 3-Clause). All new packages will be required to use such a license. Current packages using other licenses are encouraged to relicense, where possible. Required dependencies must use an OSI-approved license that is considered compatible with the preferred permissive licenses for distribution purposes (see https://en.wikipedia.org/wiki/License_compatibility). Non-critical optional dependencies can use any OSI-approved license.