1 karl 1.1 <html>
2
3 <head>
4 <meta http-equiv="Content-Language" content="en-us">
5 <meta name="GENERATOR" content="Microsoft FrontPage 5.0">
6 <meta name="ProgId" content="FrontPage.Editor.Document">
7 <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
8 <title>PEP</title>
9 </head>
10
11 <body>
12
13 <p align="center"><b><font size="4">PEGASUS Enhancement Proposal (PEP)</font></b></p>
14 <p><b>PEP #:</b> 1</p>
15 <p><b>TITLE:</b> Pegasus Project Enhancement Proposals - Guidelines and the Approval
16 Process</p>
17 <p><b>Version:</b> $Revision$</p>
18 <p><b>Authors:</b> Karl Schopmeyer, Mike Day, Denise Eckstein</p>
19 <p><b>State: </b>Draft</p>
20 <p><b>Type: </b>Process</p>
21 <p><b>Vote:</b></p>
22 karl 1.1 <p><b>Created: </b>27 July 2002</p>
23 <p><b>Version History:</b></p>
24 <p>1.0 Draft 27 July 2002 K. Schopmeyer</p>
25 <p>1.1 Draft 7 August 2002, K. Schopmeyer - Clean up comments from earlier
26 discussions.</p>
27 <h2>Abstract: </h2>
28 <p>This document describes the requirements for a Pegasus Enahncement Proposal (PEP)
29 document including the format requirements, editorial process, and review
30 process to get these documents approved.</p>
31 <h2>What is a PEP?</h2>
32 <p>A Pegasus Enhancement Proposal is the core document for implementation of changes in
33 the Pegasus environment. It defines the request for an enhancement/change to
34 Pegasus and provides the place where the status of
35 the approval and implementation of the change can be recorded.</p>
36 <p>This is the single point where changes are defined, approved, and recorded
37 for Pegasus except for bugs. It is the objective of the Pegasus steering committee that
38 all changes to Pegasus be controlled by either 1) PEP or 2) Bugzilla number for
39 bug fixes in the future. In the future, each new version of Pegasus is
40 really a list of PEPs.</p>
41 <h2>Types of PEP Documents</h2>
42 <p>We envision three types of documents:</p>
43 karl 1.1 <ol>
44 <li>Project definition PEP that define a new or significantly updated feature or
45 implementation of Pegasus. A PEP is not the design documentation for the
46 project. It provides information necessary to allow adequate review of
47 the proposed project and make decisions about its integration, time frame,
48 priority , etc. It allows the project to be approved and for the
49 integration of the project into the pegasus development.</li>
50 <li>An informative PEP that describes a design issue, or provides general
51 guidelines or information to the Pegasus community.</li>
52 <li>Process PEP defines Pegasus process, process changes, etc. The
53 definitions in this type of PEP can be mandatory on the community as defined
54 in the document (example, this document).</li>
55 </ol>
56 <h2>The Project LifeCycle for a PEP</h2>
57 <p>The project for a feature change goes through three stages: approval,
58 implementation, and integration.</p>
59 <p>A project starts when a PEP is submitted to the Pegasus project. Proposals are submitted by emailing
60 PEPsto the Pegasus PEP Editor. Whoever
61 proposes a project is responsible for making sure it is properly implemented. A
62 proposal without a committed implementer cannot be approved.</p>
63 <p>The Editor is responsible for numbering them, marking them with draft status,
64 karl 1.1 putting them into the CVS and announcing the availability of the document on the
65 Pegasus mailing list with a definition of the review period defined and the date
66 for steering committee review and vote</p>
67 <p>Project approval is done through community review and the approval of the
68 Pegasus steering committee. The approval of the steering committee is the final
69 authority on the disposition of all PEPs. A review schedule will be maintained
70 for PEPs in the approval process and a means for communicating comments.</p>
71 <p>The second phase of a project is implementation. The proposer is responsible
72 for the implementation, either doing it himself/herself or arranging for someone
73 else to do it. The implementation may be done either as part of the trunk CVS or
74 separately depending on the characteristics of the change and the possible
75 impact on other components of the prjoect</p>
76 <p>The third phase of a project is integrating the results back into the
77 official Pegasus CVS release. This is a two step process, 1)
78 integrating the change back into the repository, 2) validating the change on ALL
79 maintained Pegasus platforms.</p>
80 <p>For Pegasus approved developers with direct write access to the Pegasus CVS
81 repository this is done by submitting the changes to CVS and documenting the
82 commit with a commit message to the CVS COMMIT Mailing list. This commit
83 message must include:</p>
84 <p>1. The PEP number.</p>
85 karl 1.1 <p>2. The Modules Changed.</p>
86 <p>3. Definition of the testing performed. At the least ALL changes must
87 be completely tested on one platform before they are submitted to CVS.
88 Completely testing is defined as executing the complete test suite defined in
89 the Pegasus Test Suite defined through the PEGASUSCOMPLETETEST option of the top
90 level Pegasus make file. Please do not submit changes to CVS until they
91 have been through this set of changes.</p>
92 <p>We understand that not all developers have access to all Pegasus platfroms.
93 Therefore, there is a second step to the integration process, testing by the
94 platform maintainers. Part of the role of being a Pegasus platform
95 maintainer will be to regularly test Pegasus using the PEGASUSCOMPLETETEST and
96 to submit the results of those tests to the Pegasus test results maintainer so
97 that an up-to-date state of the operational status of the Pegasus platform can
98 be maintained.</p>
99 <h2>PEP Status</h2>
100 <p>The status field in the PEP document defines the current status of a PEP.
101 This field will be maintained by the PEP editor as the status changes. The
102 defined status today are: </p>
103 <ol>
104 <li> <i>Draft</i> - Document in draft but not yet submitted to the community
105 or steering committee.</li>
106 karl 1.1 <li> <i>Active</i> - Documented in the process of review and approval</li>
107 <li> <i>Accepted - </i>Project accepted by the steering committee</li>
108 <li> <i>Deferred - </i>Project deferred for future review by the steering
109 committee</li>
110 <li> <i>Final - </i>Approved project. At this point, the PEP should include
111 not only the definition of the project but planning information such as dates
112 for completion and an indication which version of Pegasus it will be
113 integrated into.</li>
114 <li> <i>Rejected - P</i>roject rejected by the steering committee. Note
115 that rejected projects may be resubmitted at some future time if the
116 conditions for the project or the objectives of Pegasus were interested in the
117 project.</li>
118 <li> <i>Withdrawn</i> - Project withdrawn from the approval process. It may be
119 submitted later.</li>
120 </ol>
121 <h2>Maintaining Viewing and Commenting on PEP Documents</h2>
122 <p>The PEP is a public document maintained in public space on the Pegasus
123 development web site. </p>
124 <p>The actual PEP documents will be maintained in the Pegasus CVS project and
125 CVS will be used to provide revision control, distribution and viewing of the
126 documents. The Changes proposals will be maintained in the pegasus/doc/PEP
127 karl 1.1 directory.</p>
128 <h2>PEP Format</h2>
129 <p>PEP documents are to be written in HTML with the general format defined
130 below:</p>
131 <p><i>PEP Number</i> - This is a number assigned by the PEP editor when the
132 document is first submitted.</p>
133 <p><i>Title </i>- a short descriptive title for the document</p>
134 <p><i>Version</i> - This will be maintained by CVS and displayed in the
135 document using the CVS $Revision$ variable</p>
136 <p><i>Author(s)</i> - Names and Email address of authors</p>
137 <p><i>Type</i> - Defines the type of the PEP (project, informational, process)</p>
138 <p><i>State</i> - Defines the current status of the document. Allowed values are
139 Draft, Active, Accepted, Deferred, Final, Rejected and Withdrawn. This list will
140 be influenced by the finalization of the workflow definition for PEPs.</p>
141 <p><i>Vote</i> - The current state of voting for the PEP. Allowed values are <i>
142 Pending</i>, <i>In progress</i>, <i>Done</i> and <i>No voting</i>. The latter is
143 used to indicate a PEP which doesn't require a vote, for example and
144 informational PEP. This information will be provided by the PEP editor.</p>
145 <p><i>Documentation References:</i> Reference to design and other
146 documentation on the project. Note that this documentation will normally not
147 exist when the original documentation is submitted but throughout the life of
148 karl 1.1 the proposed change.</p>
149 <p><i>Definition of the Project</i> - This is the meat of any PEP. Project definition
150 PEPs should describe the objectives, and characteristics and schedule of any
151 feature. The definition of the project should be detailed enough to allow adequate
152 discussion and review of the proposal. The objective is to provide a project
153 management level of information, not the complete design documentation on the
154 project.<br>
155 <br>
156 <i>Rationale</i> - The rationale fleshes out the specification by describing
157 what motivated the design and why particular design decisions were made. It
158 should describe alternate designs that were considered and related work.
159 The rationale should provide evidence of consensus within the community and
160 discuss important objections or concerns raised during discussion.</p>
161 <p><i>Discussion</i> - Additional information from discussions, decisions of the
162 steering committee, etc. can be recorded here.</p>
163 <p>Please use the PEPOutline.htm document defined in the Pegasus PEP archive as
164 the template for all PEP documents. This will help with the automation of
165 indexing, status changes, etc. as the process develops.</p>
166 <p>NOTE: There is a single document maintained in the Pegasus CVS (pegasus/doc/PEPS/PEPOutline.htm)
167 that is a template for PEPs to make preparation easier.</p>
168 <h2>Documentation References</h2>
169 karl 1.1 <p>A number of other open source projects including Apache, TCL, Python have
170 adopted similar documentation schemes and these were used as part of the basis
171 for this definition.</p>
172 <p>See:</p>
173 <ul>
174 <li>The Aparche web site - http://www.apache.org</li>
175 <li>TCL TIPS site at <a href="http://www.tcl.tk/cgi-bin.tct/tip/">
176 http://www.tcl.tk/cgi-bin/tct/tip</a>/</li>
177 <li>Python project management web site at
178 <a href="http://www.python.org/peps/">http://www.python.org/peps/</a></li>
179 </ul>
180 <p> </p>
181 <p> </p>
182 <p> </p>
183 <p> </p>
184
185 </body>
186
187 </html>
|
Return to
PEP1.htm
CVS log
Up to [Pegasus] / pegasus / doc / peps