-
Notifications
You must be signed in to change notification settings - Fork 1
/
criteria.html
36 lines (36 loc) · 1.66 KB
/
criteria.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
<HTML>
<TITLE>
Criteria for inclusion in the LSB
</TITLE>
<BODY>
<BL>
<LI>
A stable Standard must exist. The standard itself should be versioned, and
new releases should not be released too frequently (6 months is probably a
minimum time between releases). Frequent releases often indicates a lack of
maturity or an incompletness of the standard. The standard must be published
and be reasonable easy to obtain. It is preferable that the standard be
freely available, but nominal charges are acceptable. If published on the
web it should be published at a location that it likely to remain stable.
Personal web space on an ISP or employers website is often not sufficiently
stable.
<LI>
A Sample Implementation must exist. Code needs to be in the hands of the
people that will be using it. The code should have accumulated some runtime
on it to shake out any bugs. It would be premature to adopt a spec for code
that hasn't been proven.
<LI>
A Test suite must exist. A significant aspect of the LSB is the ability to
measure a system or an application and prove that it conforms to the
specification. Test suites are the foundation of this ability. Exceptions
to this rule have been made as part of the bootstrapping process of the
LSB, but future exception will be fewer and farther apart.
<LI>
There must be a demonstrated need. A component must be of general use,
which can be demonstrated by its use in multiple pakages. Typically, it
isn't a good investment of time to specify an API which is only used by
one or two programs. ISV requirements as mentioned above in 2b) will help
us be proactive in this area.
</BL>
</BODY>
<HTML>