share/doc/papers/relengr/2.t

   1 .\" Copyright (c) 1989 The Regents of the University of California.
   2 .\" All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   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.
  15 .\"
  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
  26 .\" SUCH DAMAGE.
  27 .\"
  28 .\"     @(#)2.t 5.1 (Berkeley) 4/17/91
  29 .\"
  30 .NH
  31 System Development
  32 .PP
  33 The first phase of each Berkeley system is its development.
  34 .SM CSRG
  35 maintains a continuously evolving list of projects that are candidates
  36 for integration into the system.
  37 Some of these are prompted by emerging ideas from the research world,
  38 such as the availability of a new technology, while other additions
  39 are suggested by the commercial world, such as the introduction of
  40 new standards like
  41 .SM POSIX ,
  42 and still other projects are emergency responses to situations like
  43 the Internet Worm.
  44 .PP
  45 These projects are ordered based on the perceived benefit of the
  46 project as opposed to its difficulty;
  47 the most important are selected for inclusion in each new release.
  48 Often there is a prototype available from a group outside
  49 .SM CSRG .
  50 Because of the limited staff at
  51 .SM CSRG ,
  52 this prototype is obtained to use as a starting base
  53 for integration into the
  54 .SM BSD
  55 system.
  56 Only if no prototype is available is the project begun in-house.
  57 In either case, the design of the facility is forced to conform to the
  58 .SM CSRG
  59 style.
  60 .PP
  61 Unlike other development groups, the staff of
  62 .SM CSRG
  63 specializes by projects rather than by particular parts
  64 of the system;
  65 a staff person will be responsible for all aspects of a project.
  66 This responsibility starts at the associated kernel device drivers;
  67 it proceeds up through the rest of the kernel,
  68 through the C library and system utility programs,
  69 ending at the user application layer.
  70 This staff person is also responsible for related documentation,
  71 including manual pages.
  72 Many projects proceed in parallel,
  73 interacting with other projects as their paths cross.
  74 .PP
  75 All source code, documentation, and auxiliary files are kept
  76 under a source code control system.
  77 During development,
  78 this control system is critical for notifying people
  79 when they are colliding with other ongoing projects.
  80 Even more important, however,
  81 is the audit trail maintained by the control system that
  82 is critical to the release engineering phase of the project
  83 described in the next section.
  84 .PP
  85 Much of the development of
  86 .SM BSD
  87 is done by personnel that are located at other institutions.
  88 Many of these people not only have interim copies of the release
  89 running on their own machines,
  90 but also have user accounts on the main development
  91 machine at Berkeley.
  92 Such users are commonly found logged in at Berkeley over the
  93 Internet, or sometimes via telephone dialup, from places as far away
  94 as Massachusetts or Maryland, as well as from closer places, such as
  95 Stanford.
  96 For the \*(b3 release,
  97 certain users had permission to modify the master copy of the
  98 system source directly.
  99 People given access to the master sources
 100 are carefully screened beforehand,
 101 but are not closely supervised.
 102 Their work is checked at the end of the beta-test period by
 103 .SM CSRG
 104 personnel who back out inappropriate changes.
 105 Several facilities, including the
 106 Fortran and C compilers,
 107 as well as important system programs, for example,
 108 .PN telnet
 109 and
 110 .PN ftp ,
 111 include significant contributions from people who did not work
 112 directly for
 113 .SM CSRG .
 114 One important exception to this approach is that changes to the kernel
 115 are made only by
 116 .SM CSRG
 117 personnel, although the changes are often suggested by the larger community.
 118 .PP
 119 The development phase continues until
 120 .SM CSRG
 121 decides that it is appropriate to make a release.
 122 The decision to halt development and transition to release mode
 123 is driven by several factors.
 124 The most important is that enough projects have been completed
 125 to make the system significantly superior to the previously released
 126 version of the system.
 127 For example,
 128 \*(b3 was released primarily because of the need for
 129 the improved networking capabilities and the markedly
 130 improved system performance.
 131 Of secondary importance is the issue of timing.
 132 If the releases are too infrequent, then
 133 .SM CSRG
 134 will be inundated with requests for interim releases.
 135 Conversely,
 136 if systems are released too frequently,
 137 the integration cost for many vendors will be too high,
 138 causing them to ignore the releases.
 139 Finally,
 140 the process of release engineering is long and tedious.
 141 Frequent releases slow the rate of development and
 142 cause undue tedium to the staff.