Wiki code for Template for interface "contract"

Hide Line numbers
1: {{{
2: 
3: @(#)contract    1.7 @(#) /shared/sac/arc/ARC-Templates/contract [1.7 06/07/26]
4: 
5: [This is a template for the Contract associated with Contracted
6: interfaces (i.e. Contracted Consolidation Private, Contracted
7: Project Private, etc).  It must be tailored for each use, and
8: be approved as part of the case approving the interfaces.  Remove
9: the explanatory text in square brackets before using this template.
10: 
11: This is NOT a legal contract; it is simply a mechanism used to specify
12: the details of an unusual dependency between two components that is not
13: allowed under the normal rules set forth in the interface taxonomy.]
14: 
15: 	CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES
16: 
17: 0.  Number:
18:     [The number is assigned by the ARC CASE owner, and has the format
19:     CASE-sequence within case; for example, PSARC/2006/952-01.
20:     Sequence begins at 01 in each case.]
21: 
22: 1.  This contract is between
23: 	a SUPPLIER of INTERFACES and
24: 	a CONSUMER of those INTERFACES,
25:     both of whom are entities within Sun Microsystems, Incorporated.
26: 
27:     [It is suggested that the SUPPLIER create an alias of
28:     the form
29: 	    "contract-yyyy-ccc[-nn]@..."
30:     that is prepopulated with both the SUPPLIER and CONSUMER(s)
31:     of this contract to be used as the basis for communication]
32: 
33: 2.  The SUPPLIER (definer and/or implementor) is identified by the following:
34:     Product or Bundle:
35:     Consolidation:
36:     Department or Group:
37:     Bugtraq Category/SubCategory:
38:     Responsible Manager:
39: 
40: 3.  The CONSUMER is identified by the following:
41:     Product or Bundle:
42:     Consolidation:
43:     Department or Group:
44:     Bugtraq Category/SubCategory:
45:     Responsible Manager:
46: 
47:     [There may be multiple CONSUMERS listed here, if the conditions
48:      for the contract are identical for all]
49: 
50:     [The consumer(s) listed above MUST be Company internal ~-- DO NOT have
51:      a person or group from an outside company as consumer.  We only
52:      expose Contracted interfaces outside of Sun if a Sun internal
53:      entity acts as the CONSUMER and manages the relationship with
54:      the external company with regards to these interfaces.  To
55:      expose an interface externally, fill in the section 7b below.
56: 
57:      This document is intended to be an architectural management
58:      tool and not a legal contract, and care must be taken to reinforce
59:      this distinction before exposing this document to partners or
60:      customers.]
61: 
62: 4.  The INTERFACES are:
63:     [List interfaces with their basic stability levels, for example
64:     Consolidation Private, not Contracted Consolidation Private.]
65: 
66: 5.  The ARC controlling these INTERFACES is:
67: 
68: 6.  The CASE describing (Exporting) these INTERFACES is:
69: 
70: 7.  The following SPECIAL ARRANGEMENTS are made which modify the rules
71:     imposed by the stability levels listed in section 4 above:
72: 
73:     [Indicate all that apply by changing the N to a Y and fill in blanks
74:     as applicable...]
75: 
76:         [Paragraph used to control changes to External interfaces.]
77: _N_ 7a. Although the stability level doesn’t normally restrict it,
78:         SUPPLIER promises to only modify INTERFACES in an incompatible
79: 	way as follows:
80: 		[describe conditions, e.g. "minor release"]
81: 
82:         [Paragraph used to expose interfaces privately to partners.]
83: _N_ 7b. Although the stability level doesn’t normally allow it, CONSUMER will
84:         expose INTERFACES to a PARTNER, which is external to Sun, namely:
85: 		Name of Company:
86: 		Name of Department or Group within Company:
87: 		Responsible Manager:
88: 
89:         [Paragraph used to expose interfaces across consolidations.]
90: _N_ 7c. Although the stability level doesn’t normally allow it, CONSUMER will
91:         import INTERFACES from a separate consolidation.
92: 
93:         [Paragraph used to mandate notification before interfaces change.]
94: _N_ 7d. If SUPPLIER decides to change (including replace or remove) any
95: 	portion of the INTERFACES, SUPPLIER will notify CONSUMER of the
96: 	proposed new version, no later than the application for ARC
97: 	approval of the new version.
98: 	If SUPPLIER and CONSUMER are contained in the same consolidation,
99: 	they have the option of arranging for simultaneous conversion
100: 	to the new interfaces.  If this is not possible, or if they are
101: 	not in the same consolidation, then SUPPLIER will either make best
102: 	effort to work with CONSUMER so that CONSUMER can detect which
103: 	version of INTERFACES is being supplied, or else SUPPLIER will
104: 	make best effort to supply both old and new versions of
105: 	INTERFACES.
106: 	If SUPPLIER cannot make both versions of INTERFACES available,
107: 	and SUPPLIER and CONSUMER cannot devise a method whereby
108: 	CONSUMER can detect which version of INTERFACES is being
109: 	supplied, and the old version of CONSUMER will not run with the
110: 	new version of SUPPLIER, then either the EOL process must be
111: 	followed by SUPPLIER, or else a major release of SUPPLIER will
112: 	be required, or the change will not be allowed.
113: 
114: 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make
115:    best effort to accommodate such changes, which shall then be
116:    treated in accordance with paragraph 7 above.
117: 
118: 9. Notwithstanding paragraphs 7 and 8, a change to any portion
119:    of the INTERFACES shall be regarded as a completely new set of
120:    INTERFACES which require both ARC approval and execution of
121:    a new contract.
122: 
123: 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be
124:     handled as follows:
125:     [In particular, include whether the SUPPLIER will inform the
126:     CONSUMER or obtain approval of the change from the CONSUMER.]
127: 
128: 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as
129:     follows:
130: 
131: 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as
132:     follows:
133: 
134: 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be
135:     tested as follows:
136: 
137: 14. SUPPLIER and CONSUMER agree that this contract can be terminated as
138:     follows:
139: 
140: 15. This contract is not valid until "signed" via agreement from the
141:     SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by
142:     this contract.  E-mail agreement to the contract should be archived
143:     in the mail archive of CASE; verbal agreement to the contract
144:     should be noted in the meeting minutes.  This contract remains
145:     valid until superseded or invalidated.
146: 
147: For SUPPLIER:			Date:
148: For CONSUMER:			Date:
149: For ARC:			Date:
150: 
151:     A copy of this contract shall be deposited in the CASE directory as
152:     "contract-" or in a "contracts" subdirectory.
153: 
154: 16. (Not to be filled in until superseded or invalidated.)
155:     This contract was superseded or invalidated by CASE:
156:     For ARC:			Date:
157: 
158: }}}
OpenSolaris

Top Menu

Wiki code for Template for interface "contract"

Search

Collectives

Community Group

Project

User Group

Subsites

Community Group arc Pages
