1 .\" Copyright (c) 1989 The Regents of the University of California.
2 .\" All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\" notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\" notice, this list of conditions and the following disclaimer in the
11 .\" documentation and/or other materials provided with the distribution.
12 .\" 3. Neither the name of the University nor the names of its contributors
13 .\" may be used to endorse or promote products derived from this software
14 .\" without specific prior written permission.
16 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
17 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
18 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
19 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
20 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
21 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
22 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
23 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
24 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
25 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
28 .\" @(#)3.t 5.1 (Berkeley) 4/17/91
33 Once the decision has been made to halt development
34 and begin release engineering,
35 all currently unfinished projects are evaluated.
36 This evaluation involves computing the time required to complete
37 the project as opposed to how important the project is to the
39 Projects that are not selected for completion are
40 removed from the distribution branch of the source code control system
41 and saved on branch deltas so they can be retrieved,
42 completed, and merged into a future release;
43 the remaining unfinished projects are brought to orderly completion.
47 are released in three steps: alpha, beta, and final.
48 Alpha and beta releases are not true distributions\(emthey
50 Alpha releases are normally available to only a few sites,
51 usually those working closely with
53 More sites are given beta releases,
54 as the system is closer to completion,
55 and needs wider testing to find more obscure problems.
56 For example, \*(b3 alpha was distributed to about fifteen
57 sites, while \*(b3 beta ran at more than a hundred.
59 Alpha Distribution Development
61 The first step in creating an alpha distribution is to evaluate the
62 existing state of the system and to decide what software should be
63 included in the release.
64 This decision process includes not only deciding what software should
65 be added, but also what obsolete software ought to be retired from the
67 The new software includes the successful projects that have been
70 and elsewhere, as well as some portion of the vast quantity of
71 contributed software that has been offered during the development
74 Once an initial list has been created,
75 a prototype filesystem corresponding to the distribution
76 is constructed, typically named
78 This prototype will eventually turn into the master source tree for the
80 During the period that the alpha distribution is being created,
82 is mounted read-write, and is highly fluid.
83 Programs are created and deleted,
84 old versions of programs are completely replaced,
85 and the correspondence between the sources and binaries
86 is only loosely tracked.
89 who are helping with the distribution are free to
90 change their parts of the distribution at will.
92 During this period the newly forming distribution is
93 checked for interoperability.
95 in \*(b3 the output of context differences from
97 was changed to merge overlapping sections.
98 Unfortunately, this change broke the
100 program which could no longer interpret the output of
106 program had originated outside Berkeley,
108 had to coordinate the efforts of the respective authors
109 to make the programs work together harmoniously.
111 Once the sources have stabilized,
112 an attempt is made to compile the entire source tree.
113 Often this exposes errors caused by changed header files,
114 or use of obsoleted C library interfaces.
115 If the incompatibilities affect too many programs,
116 or require excessive amounts of change in the programs
118 the incompatibility is backed out or some backward-compatible
119 interface is provided.
120 The incompatibilities that are found and left in are noted
121 in a list that is later incorporated into the release notes.
122 Thus, users upgrading to the new system can anticipate problems
123 in their own software that will require change.
125 Once the source tree compiles completely,
126 it is installed and becomes the running system that
128 uses on its main development machine.
129 Once in day-to-day use,
130 other interoperability problems become apparent
132 When all known problems have been resolved, and the system has been
133 stable for some period of time, an alpha distribution tape is made
137 The alpha distribution is sent out to a small set of test sites.
138 These test sites are selected as having a
139 sophisticated user population, not only capable of finding bugs,
140 but also of determining their cause and developing a fix for the problem.
141 These sites are usually composed of groups that are contributing
142 software to the distribution or groups that have a particular expertise
143 with some portion of the system.
145 Beta Distribution Development
147 After the alpha tape is created,
148 the distribution filesystem is mounted read-only.
149 Further changes are requested in a change log rather than
150 being made directly to the distribution.
151 The change requests are inspected and implemented by a
153 staff person, followed by a compilation of the affected
154 programs to ensure that they still build correctly.
155 Once the alpha tape has been cut,
156 changes to the distribution are no longer made by people outside
159 As the alpha sites install and begin running the alpha distribution,
160 they monitor the problems that they encounter.
161 For minor bugs, they typically report back the bug along with
163 Since many of the alpha sites are selected from among the people
166 they often have accounts on, and access to, the primary
169 Thus, they are able to directly install the fix themselves,
172 when they have fixed the problem.
173 After verifying the fix, the affected files are added to
174 the list to be updated on
177 The more important task of the alpha sites is to test out the
178 new facilities that have been added to the system.
179 The alpha sites often find major design flaws
180 or operational shortcomings of the facilities.
181 When such problems are found,
182 the person in charge of that facility is responsible
183 for resolving the problem.
184 Occasionally this requires redesigning and reimplementing
185 parts of the affected facility.
188 the alpha release of the networking system did not have connection queueing.
189 This shortcoming prevented the network from handling many
190 connections to a single server.
191 The result was that the networking interface had to be
192 redesigned to provide this functionality.
194 The alpha sites are also responsible for ferreting out interoperability
195 problems between different utilities.
196 The user populations of the test sites differ from the user population at
198 and, as a result, the utilities are exercised in ways that differ
199 from the ways that they are used at
201 These differences in usage patterns turn up problems that
202 do not occur in our initial test environment.
204 The alpha sites frequently redistribute the alpha tape to several
205 of their own alpha sites that are particularly interested
206 in parts of the new system.
207 These additional sites are responsible for reporting
208 problems back to the site from which they received the distribution,
211 Often these redistribution sites are less sophisticated than the
212 direct alpha sites, so their reports need to be filtered
213 to avoid spurious, or site dependent, bug reports.
214 The direct alpha sites sift through the reports to find those that
215 are relevant, and usually verify the suggested fix if one is given,
216 or develop a fix if none is provided.
217 This hierarchical testing process forces
218 bug reports, fixes, and new software
219 to be collected, evaluated, and checked for inaccuracies
220 by first-level sites before being forwarded to
222 allowing the developers at
224 to concentrate on tracking the changes being made to the system
225 rather than sifting through information (often voluminous) from every
228 Once the major problems have been attended to,
229 the focus turns to getting the documentation synchronized
230 with the code that is being shipped.
231 The manual pages need to be checked to be sure that
232 they accurately reflect any changes to the programs that
234 Usually the manual pages are kept up to date as
235 the program they describe evolves.
236 However, the supporting documents frequently do not get changed,
237 and must be edited to bring them up to date.
238 During this review, the need for other documents becomes evident.
240 during this phase of \*(b3 that it was decided
241 to add a tutorial document on how to use the socket
242 interprocess communication primitives.
244 Another task during this period is to contact the people that
245 have contributed complete software packages
250 in previous releases to see if they wish to
251 make any revisions to their software.
253 the new software has to be obtained,
254 and tested to verify that it compiles and runs
255 correctly on the system to be released.
256 Again, this integration and testing can often be done by the
257 contributors themselves by logging directly into the master machine.
259 After the stream of bug reports has slowed down
260 to a reasonable level,
262 begins a careful review of all the changes to the
263 system since the previous release.
264 The review is done by running a recursive
266 of the entire source tree\(emhere, of
269 All the changes are checked to ensure that they are reasonable,
270 and have been properly documented.
271 The process often turns up questionable changes.
272 When such a questionable change is found,
273 the source code control system log is examined to find
274 out who made the change and what their explanation was
276 If the log does not resolve the problem,
277 the person responsible for the change is asked for an explanation
278 of what they were trying to accomplish.
279 If the reason is not compelling,
280 the change is backed out.
281 Facilities deemed inappropriate in \*(b3 included new options to
282 the directory-listing command and a changed return value for the
285 the changes were removed from the source before final distribution.
286 Although this process is long and tedious,
287 it forces the developers to obtain a coherent picture of the entire set of
288 changes to the system.
289 This exercise often turns up inconsistencies that would
290 otherwise never be found.
292 The outcome of the comparison results in
293 a pair of documents detailing
294 changes to every user-level command
296 Bug Fixes and Changes
298 and to every kernel source file.
300 Changes to the Kernel
302 These documents are delivered with the final distribution.
303 A user can look up any command by name and see immediately
305 and a developer can similarly look up any kernel
306 file by name and get a summary of the changes to that file.
308 Having completed the review of the entire system,
309 the preparation of the beta distribution is started.
310 Unlike the alpha distribution, where pieces of the system
311 may be unfinished and the documentation incomplete,
312 the beta distribution is put together as if it were
313 going to be the final distribution.
314 All known problems are fixed, and any remaining development
316 Once the beta tape has been prepared,
317 no further changes are permitted to
319 without careful review,
320 as spurious changes made after the system has been
322 are unlikely to be caught.
324 Final Distribution Development
326 The beta distribution goes to more sites than the
327 alpha distribution for three main reasons.
328 First, as it is closer to the final release, more sites are willing
329 to run it in a production environment without fear of catastrophic failures.
330 Second, more commercial sites delivering
332 derived systems are interested in getting a preview of the
333 upcoming changes in preparation for merging them into their
335 Finally, because the beta tape has fewer problems,
336 it is beneficial to offer it to more sites in hopes of
337 finding as many of the remaining problems as possible.
338 Also, by handing the system out to less sophisticated sites,
339 issues that would be ignored by the users of the alpha sites
342 The anticipation is that the beta tape will not require
343 extensive changes to either the programs or the documentation.
344 Most of the work involves sifting through the reported bugs
345 to find those that are relevant and devising the minimal
346 reasonable set of changes to fix them.
347 After throughly testing the fix, it is listed in the update log for
351 is responsible for doing the update of
353 and ensuring that everything affected by the change is rebuilt and tested.
354 Thus, a change to a C library routine requires that the entire
357 During this period, the documentation is all printed and proofread.
358 As minor changes are made to the manual pages and documentation,
359 the affected pages must be reprinted.
361 The final step in the release process is to check the distribution tree
362 to ensure that it is in a consistent state.
363 This step includes verification that every file and directory
364 on the distribution has the proper owner, group, and modes.
365 All source files must be checked to be sure that they have
366 appropriate copyright notices and source code control system headers.
367 Any extraneous files must be removed.
368 Finally, the installed binaries must be checked to ensure that they correspond
369 exactly to the sources and libraries that are on the distribution.
371 This checking is a formidable task given that there are over 20,000 files on
372 a typical distribution.
373 Much of the checking can be done by a set of programs set to scan
374 over the distribution tree.
375 Unfortunately, the exception list is long, and requires
376 hours of tedious hand checking; this has caused
379 more comprehensive validation programs for use in our next release.
381 Once the final set of checks has been run,
382 the master tape can be made, and the official distribution started.
385 we usually take a brief vacation before plunging back into
386 a new development phase.