forked from E4S-Project/E4S-Project.github.io
-
Notifications
You must be signed in to change notification settings - Fork 0
/
policies.html
193 lines (150 loc) · 15.4 KB
/
policies.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
<!DOCTYPE html>
<html lang="en">
<head>
<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-3DB1WP6Q3G"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-3DB1WP6Q3G');
</script>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>E4S - Policies</title>
<!-- CSS -->
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Josefin+Sans:300,400|Roboto:300,400,500">
<link rel="stylesheet" href="assets/bootstrap/css/bootstrap.min.css">
<link rel="stylesheet" href="assets/font-awesome/css/font-awesome.min.css">
<link rel="stylesheet" href="assets/css/animate.css">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="stylesheet" href="assets/css/style_perso.css">
<!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
<script src="https://oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js"></script>
<![endif]-->
<!-- Favicon and touch icons -->
<link rel="shortcut icon" href="assets/ico/favicon.png">
<link rel="apple-touch-icon-precomposed" sizes="144x144" href="assets/ico/apple-touch-icon-144-precomposed.png">
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="assets/ico/apple-touch-icon-114-precomposed.png">
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="assets/ico/apple-touch-icon-72-precomposed.png">
<link rel="apple-touch-icon-precomposed" href="assets/ico/apple-touch-icon-57-precomposed.png">
</head>
<body>
<!-- Top content -->
<div class="top-content">
<!-- Top menu -->
<nav class="navbar navbar-inverse" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-target="#top-navbar-1">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="index.html">E4S</a>
</div>
<!-- Collect the nav links, forms, and other content for toggling -->
<div class="collapse navbar-collapse" id="top-navbar-1">
<ul class="nav navbar-nav">
<!--MENU START-->
<li><a href="index.html">Home</a></li>
<li><a href="events.html">Events</a></li>
<li><a href="about.html">About</a></li>
<li><a href="DocPortal.html">Product DocPortal</a></li>
<li><a href="Deployments.html">Deployments</a></li>
<li><a href="policies.html">Community Policies</a></li>
<li><a href="contact.html">Contact</a></li>
<li><a href="join.html">Join</a></li>
<li><a href="faq.html">FAQ</a></li>
<li><a href="documentation.html">Documentation</a></li>
<li><a class="btn btn-link-3" href="download.html">Download</a></li>
<!--MENU END-->
</ul>
</div>
</div>
</nav>
</div>
<!-- Features -->
<div class="features-container section-container">
<div class="container">
<div class="row">
<div class="col-sm-12 features section-description wow fadeIn">
<h2>E4S Community Policies</h2>
<p><strong>Version 1</strong></p>
<div class="divider-1"><div class="line"></div></div>
</div>
</div>
<div class="row">
<div class="col-sm-12 features section-description ">
<div align=left>
<p>The <a href="https://e4s-project.github.io/"><em>Extreme-scale Scientific Software Stack</em></a> (E4S) and its related Software Development Kits (SDKs) are light-weight organizational elements intended to enhance collaboration and coordination across independently-developed products to provide an enhanced high-performance software stack.</p>
<p>E4S Community Policies are membership criteria for a product to become an E4S member package. This version of the policies was arrived at by the ECP SDK team, including representation from Programming Models and Runtimes, Development Tools, Math Libraries, Data and Vis, and Software Ecosystem and Delivery, and after considering multiple rounds of feedback from across ECP ST. The starting point for the majority of the policies was taken from the existing <a href="http://xsdk.info/policies/"><em>xSDK Community Policies</em></a>.</p>
<p><em><strong>E4S Membership Criteria</strong></em></p>
<p>The policies below are criteria for E4S membership. To qualify for E4S membership, a package must demonstrate compatibility with each of these policies. Under special circumstances, a package may be granted an exception to a policy. </p>
<p><strong>P1</strong> <em>Spack-based Build and Installation</em> Each E4S member package supports a scriptable <a href="https://spack.io/"><em>Spack</em></a> build and production-quality installation in a way that is compatible with other E4S member packages in the same environment. When E4S build, test, or installation issues arise, there is an expectation that teams will collaboratively resolve those issues.</p>
<p> </p>
<p><strong>P2</strong> <em>Minimal Validation Testing</em> Each E4S member package has at least one test that is executable through the E4S validation test suite (<a href="https://github.com/E4S-Project/testsuite"><em>https://github.com/E4S-Project/testsuite</em></a>). This will be a post-installation test that validates the usability of the package. The E4S validation test suite provides basic confidence that a user can compile, install and run every E4S member package. The E4S team can actively participate in the addition of new packages to the suite upon request.</p>
<p> </p>
<p><strong>P3</strong> <em>Sustainability</em> All E4S compatibility changes will be sustainable in that the changes go into the regular development and release versions of the package and should not be in a private release/branch that is provided only for E4S releases.</p>
<p> </p>
<p><strong>P4</strong> <em>Documentation</em> Each E4S member package should have sufficient documentation to support installation and use.</p>
<p><strong>P5</strong> <em>Product Metadata </em>Each E4S member package team will provide key product information via metadata that is organized in the <a href="https://e4s-project.github.io/DocPortal.html"><em>E4S DocPortal</em></a> format. Depending on the filenames where the metadata is located, this may require <a href="https://github.com/E4S-Project/E4S-Documenter/blob/master/README.md"><em>minimal setup</em></a>.</p>
<p><strong>P6</strong> <em>Public Repository</em> Each E4S member package will have a public repository, for example at GitHub or Bitbucket, where the development version of the package is available and pull requests can be submitted.</p>
<p><strong>P7</strong> <em>Imported Software</em> If an E4S member package imports software that is externally developed and maintained, then it must allow installing, building, and linking against a functionally equivalent outside copy of that software. Acceptable ways to accomplish this include (1) forsaking the internal copied version and using an externally-provided implementation or (2) changing the file names and namespaces of all global symbols to allow the internal copy and the external copy to coexist in the same downstream libraries and programs. This pertains primarily to third party support libraries and does not apply to key components of the package that may be independent packages but are also integral components to the package itself.</p>
<p> </p>
<p><strong>P8</strong> <em>Error Handling</em> Each E4S member package will adopt and document a consistent system for signifying error conditions as appropriate for the language and application. For e.g., returning an error condition or throwing an exception. In the case of a command line tool, it should return a sensible exit status on success/failure, so the package can be safely run from within a script.</p>
<p> </p>
<p><em><strong>P9</strong></em> <em>Test Suite</em> Each E4S member package will provide a test suite that does not require special system privileges or the purchase of commercial software. This test suite should grow in its comprehensiveness over time. That is, new and modified features should be included in the suite.</p>
<p><em><strong>Future Revision E4S Community Policies</strong></em></p>
<p>The policies below are being considered for future revisions of the E4S Community Policies. These policies require further refinement or planning prior to adoption. The topics that these policies address provide information about likely subject areas for E4S policies going forward.</p>
<p>Note: FP stands for “future policy”</p>
<p><strong>FP1</strong> <em>Portability</em> Each E4S member package team will make a best effort at portability to common platforms. Depending on the function of the member package, considerations may include operating systems, compiler toolchains, architectures and accelerators. Lack of support for configurations should be denoted in appropriate Spack packages when possible.</p>
<!--<p>including standard Linux distributions, common compiler toolchains, and different architectures and accelerators. Consider: self assessed portability score/metric - OS, GPU, etc?</p>-->
<p><strong>FP2</strong> <em>Flexible Test Selection Support</em> Each E4S member package will support the ability to specify that specific tests will be run for a given system allocation limit on execution time and node configuration resources. Particular use cases include the ability to a) run a subset of the test suite to complete within a few hours on standard workstation-level hardware b) be runnable in batch-only environments, that is, systems that require the use of PBS or other submission scripts. </p>
<p> </p>
<p><strong>FP3</strong> <em>Dependency Version Tracking</em> Each E4S member package will document the versions of packages with which it can work or upon which it depends, in Spack. Similarly, incompatible versions of packages should also be appropriately tracked in Spack. The developers of E4S member packages will coordinate the needed versions of various packages for each E4S release.</p>
<p><strong>FP4</strong> <em>Memory Testing</em> Each E4S member package makes it possible to run their test suite under Valgrind in order to test for memory corruption issues. NOTE: The SDK team is planning to refine this policy so as to not specifically single out Valgrind.</p>
<p><strong>FP5</strong> <em>Comprehensive Test Suite</em> Each E4S member package will provide a comprehensive test suite that can be run by users and does not require special system privileges or the purchase of commercial software. </p>
<p><strong>FP6</strong> <em>Documentation</em> Each E4S member package should have sufficient documentation to support installation, use, and further development, as assessed periodically by its community of peers.</p>
<p><strong>Library Policies: Apply to linkable libraries and similar products</strong></p>
<p>Note: FLP stands for “future library policy”</p>
<p><strong>FLP1 </strong><em>User-managed Exception Handling</em> Each E4S member library package will have no hardwired calls to abort, exit, or MPI_Abort(). Also, no package should have hardwired print statements for error conditions. Each package should document which error codes/exceptions are recoverable, which may result in lost resources (for example, unfreed memory), and which indicate that the process may be in an undefined or totally broken state (for example, after a segmentation violation). It is the responsibility of the calling routine not to simply continue the computation when a “hard” error is returned; the calling routine will likely, by default, call an abort, but again that should be possible to override.</p>
<p><strong>FLP2</strong> <em>User-managed I/O Control</em> No package should have hardwired print or I/O statements that cannot be turned off through a programmatic interface; output should never be hard-wired to stdout or stderr. It is recommended that packages provide a way for users to turn on output and allow them to direct where it goes. Also, packages may print to stdout by default but only on one process (i.e., root rank “0”). But packages may also be completely silent by default (and require that users turn on outputting in the appropriate way). </p>
<p> </p>
<p><strong>FLP3</strong> <em>Symbols and Namespacing</em> Each E4S member package will use a limited and well-defined symbol, macro, library, and include file name space. For example, there should be no publicly visible include files such as utils.h, or packages named libutil.a or macros named YES or TRUE. Namespacing of include files can be handled either by prepending each include file with a package name, for example <XXXmat.h>, or by placing and referencing all include files in a subdirectory with a package name, for example <XXX/mat.h>. Note that using a -I/XXX/ and referencing via <mat.h> would not be acceptable namespacing.</p>
<p><strong>FLP4</strong> <em>Memory Leaks</em> Each E4S member package will free all system resources it has acquired as soon as they are no longer needed, including closing open files, freeing memory, freeing MPI communicators, and freeing MPI data types created by the package. In particular, it is important that E4S compatible code not have any growing memory leaks (such as leaking memory during every timestep). Any resources created by the package that should be freed by the user, rather than by the package, must be fully documented. <strong>Note: Exceptions are permitted for situations where other software quality considerations are more important. </strong> </p>
</div>
</div>
</div>
</div>
</div>
<!-- Footer -->
<footer>
<div class="container">
<div class="row">
<div class="col-sm-12 footer-copyright">
Created for <a href="https://e4s-project.github.io">The Extreme-scale Scientific Software Stack (E4S) Project</a> by <a href="https://maherou.github.io/">Michael A. Heroux</a>
</div>
<div class="col-sm-12 footer-copyright">
<a href="credit.html">Attribution</a> - Derived from a design by Quentin Petit
</div>
</div>
</div>
</footer>
<!-- Javascript -->
<script src="assets/js/jquery-1.11.1.min.js"></script>
<script src="assets/bootstrap/js/bootstrap.min.js"></script>
<script src="assets/js/jquery.backstretch.min.js"></script>
<script src="assets/js/wow.min.js"></script>
<script src="assets/js/retina-1.1.0.min.js"></script>
<script src="assets/js/scripts.js"></script>
<!--[if lt IE 10]>
<script src="assets/js/placeholder.js"></script>
<![endif]-->
</body>
</html>